Here is the way to check a form’s mode in script.

If Instr(1, ucase(ThisForm.Caption), “(FILTER IN PLACE)”) > 0  Then
ReturnValue = “-1”
Exit Sub
End If

General Concept:

• Customer amounts will be stored in the customer’s currency. This effects CO, Estimating, and AR.
• Vendor amounts will be stored in the vendor’s currency. This effects PO and AP.
• Cash accounts in Bank Reconciliation may be stated in non-domestic currencies. When receiving customer payments or making vendor payments we may specify the payment with either domestic currency or the customer/vendor currency.
• All journal. Ledger, inventory ( price & cost) and shop floor amounts are always stated in domestic currency.

NOTE: Therefore when amounts are posted into journals they are translated.

PO & AP:

• Gain/Loss – When exchange rates increase over time (foreign currency per one unit of domestic currency), we record a gain and when exchange rates decrease, we record a loss.
• Entry – PO header & line/release casts are entered and stored in the vendor’s currency. Whenever these amounts are defaulted from the Item master, they are converted using the current exchange rate.
• Receiving – At receiving time, we record the amount received, cost, and exchange rate. We post domestic amounts to the journal using this exchange rate.

Account Numbers Posted (PO Dist):

• Debit- Inventory account
• Credit- Vouchers Payable

Generating Voucher (PO) & Posting Vouchers (AP) – When we create the voucher record, we store any change in exchange rate from Receiving time to voucher generation time as a distribution. The voucher is stored in the Vendor’s currency. When the Voucher is Posted, domestic amounts are posted to the journal and vendor amounts are put on the Posted Transactions record along with the exchange rate that was used for posting.

Account Numbers Posted (AP Dist):

• Credit – Accounts Payable
• Debit- Vouchers payable

Payment – Payments may be entered in either Domestic Amount or Vendor’s amount based upon the currency code of the Bank Code you select for the payment. When the payment is posted, domestic amounts get posted to the journal, and vendor amounts are put on the Posted Transaction record. At payment posting time, we perform a mini-gain/loss for the voucher and any payments or adjustments to that voucher. All of the Posted transactions tied to the voucher will be “upgraded” to the new exchange rate
Account Numbers Posted (AP Dist):

• Credit – Cash account (Payment Amt @ new rate)
• Debit – Accounts Payable (Voucher Amt @ old rate)

Voucher’s Gain/Loss posted to either Loss (Debit) or Gain (Credit)

CO & AR:

• Gain/Loss- When exchange rates decrease over time ( foreign currency per one unit of domestic currency), we record a gain and when exchange rates increase, we record a loss.
• Entry- CO header and line prices are entered and stored in the customer’s currency. Whenever these
  amounts are defaulted from the item master, they re converted using the current exchange rate.
• Shipping- At shipping time, we record the amount shipped, price, and exchange rate. We post domestic amounts to the journal using this exchange rate.

Account Numbers Posted (CO Dist):

• Debit – Cost of Good Sold
• Credit – Inventory

Invoice Printing (CO) Posting (AR) – When we create the invoice record, we store any change in exchange rate from Shipping time to invoice printing time as a distribution. The invoice is stored in the Customer’s currency. When the Invoice is Posted, domestic amounts are posted to the journal and customer amounts are put on the Posted Transaction record along with the exchange rate that was used for posting.

Account Numbers Posted (AR Dist):

• Credit – Sales (Invoice @ Old rate)
• Debit – Accounts Receivable (Invoice @ new rate)

Payment – Payments may be entered in either Domestic Amount or Customer’s amount based upon the currency code of the Bank Code you select for the payment. When the payment is posted, domestic amounts get posted to the journal, and customer amounts are put on the Posted Transaction record. At payment time, we perform a mini-gain/loss for the invoice and any payments, debits or credits to that invoice. All of the Posted transactions tied to the invoice will be “upgraded: to the new exchange rate.

Account Number Posted (AR Dist):

• Debit – Cash (Payment Amt @ new rate)
• Credit _ Accounts Receivable ( Invoice Amt @ old rate)

Difference to currency Loss (Debit) or Gain Account (Credit)

Gain/Loss Utility

At various times, users may wish to recognize any outstanding Gains or Losses. They may run this utility and specify either AR,AP or both.

AR – We process all Posted A/R Transactions and upgrade them to the current exchange rate. For each invoice that has a gain or loss, we post the amount to Accounts Receivable and the Gain or Loss Account.
AP- We process all outstanding PO Receipts (received but not yet vouchered) and upgrade them to the current exchange rate. For each record that contains a gain or loss. We post the amount to Vouchers payable and the Gain or Loss Account.

We process all unposted vouchers and upgrade them to the current exchange rate. For each voucher that has a gain or loss, we post the amount to Vouchers Payable and the Gain or Loss Account.

Gain/Loss Accounts:

• Users establish account records for Gains and Losses.
• The Gain Account is always used to record gains due to exchange rate changes.
• The Loss Account is always used to record losses due to exchange rate changes.

Currency Master:
SyteLine contains a currency master file where all currencies are maintained. Users may enter an unlimited number of date & time stamped currency exchange rates. They may also back-date these rates by entering a past date. There are two exchange rates entered. The Buying rate is used exclusively in PO and AP. The selling rate is used exclusively in CO, Estimating, and AR.

Financial Statements:

Users are able to print Financial Statements in different currencies. Prior to SYMIX 4.0, they could only accomplish this when they were consolidating multiple divisions. The “final” Financial statement would be printed in the currency of the division running the report. The exchange rates used to convert the data were the ones stored in the division running the report. Now in V 4.0, users can choose which currency they wish to print their financial statements in. The exchange rates used to print the report are the rates stored in the database that contains the ledger records being processed. The translations are for display purposed only. No posting of any kind takes place & no gain or loss is calculated.
Translations are defined for each line of the financial statement. Users choose to use the Buying or Selling Exchange rate. They choose a translation method: None ( no translation), Spot ( historic rate for each transaction), Current ( current exchange rate), Average Period ( weighted average exchange rate in effect for the accounting period for each transaction), End of Period ( exchange rate in effect at the end of the accounting period for each transaction)

Basically, this is handled through a 3-Step Process. Cut the check to the vendor, designating it as an Open payment. Receive and voucher the purchase order. Reapply the open payment against the voucher generated. Below are the steps for handling this process.

The process for handling Deposits or Pre-Payments to Vendors is as follows:

1. In the A/P Payment form, add a new record for the vendor
On the Payment Distribution form, select type “Open”
If Purchase Order Number is known, you can link the PO to this Open Payment. When check is printed, it will update the Prepaid Amount field on the Purchase Order Header.
Note: The account that defaults for the Open Payment comes from the default “Deposit Acct” from the Accounts Payable Parameter. This account change be overridden if needed.
Print and Post the check as normal.

2. When purchase order is received, generate voucher as normal from the Generate A/P Transactions form
Perform Voucher Posting to post the voucher to vendors A/P Posted Transaction Details

3. Reapply the Open Payment to voucher generated from Purchasing.
Determine the original check number of the deposit or pre-payment. (This can be found on the A/P Posted Transaction Detail form).
Open A/P Payment form
Enter a new record for the vendor, flag the record as “Reapplication”
Enter the original check number in the check number field
System will automatically recognize this as a “Reapplication”. The original amount should default in the payment amount. Save.
Either through Quick or Distribution, select the voucher/vouchers where the deposit or pre-payment needs applied against. Save.
Go to the A/P Check Printing/Posting form and perform Final Register and Post
Journal entries will be created reversing the amount from the “Deposit” account and applying it against “Accounts Payable” account

NOTE: Open Payments should NEVER be applied to vouchers via the A/P Posted Transaction Details form. Journal entries are not created from this form.

A refund check has been received from a vendor and you need to enter it into SyteLine, the following are the steps that you should take to complete this process:

1) Go to Customer Maintenance and add a new customer record with the Vendor’s information.
2) In AP, you currently have a voucher and a payment on this vendor record. At this point, you need to decide whether or not you want this refund reflected in AP Posted Trans. If you’ll never repay this and don’t want the vendor’s balance due to increase, then you won’t enter any transactions on the AP side.
On the other hand, if you will eventually pay them back this amount, then you’ll want to adjust that payment amount, so that this refund is reflected on the voucher. In order to do that, you want to go to Vouchers and Adjustments and create an adjustment voucher against the voucher number, for the amount of the refund (should be a positive amount).
3) If you created an adjustment voucher in step (2), then you’ll need to process Voucher Posting to post that adjustment. If you didn’t, proceed to step (4).
4) In AR, create an invoice for the amount of the refund, using the new customer number that you created.
5) Perform Invoice Posting.
6) In Customer Payments, enter a payment for the new customer number, using the check # and the amount on the refund check.
7) Use Check Posting to post the payment.
Now AR has a zero balance.

Recurring Vouchers are designed to handle repetitive vouchers each month, where basically, only the Invoice Date, Distribution Date and Due Date change each month. The steps to set up a Recurring Voucher are as follows:

1. Open Recurring Vouchers form (in SL4, SL5 and SL6 go to Vendor – Recurring Vouchers) New (or add)
   Enter the Vendor Number
   Voucher (allow system to assign the next voucher number)
   Distribution Date (defaults to current date. This date will be designated at time of Recurring Voucher Generation for new vouchers)
   Invoice Date (this is the date of the month that will be used for subsequent vouchers generated)
   Due Date (automatically calculates based on terms of vendor and invoice date)
   Purchase Amount (the amount of the voucher that will be generated each month)
   NOTE: This amount may be updated after the recurring voucher has been generated if needed. If amount is updated, the distribution amount will also need to be updated
2. Voucher Distribution
   Add the necessary distributions to fully distribute the Purchase Amount of this voucher

With the steps above, you have created your template voucher. You can now generate this voucher for a new month as needed. The steps to generate the Recurring Voucher are as follows:

• Open A/P Recurring Voucher Generation (in SL4, SL5 and SL6 go under Vendor – A/P Activities – Recurring Voucher Generation)
• Select the range of vendors who have recurring vouchers created, or leave blank to generate for all vendors
• Enter new month of voucher (example, you created the recurring voucher in February, and want to create a voucher for March. The new month would be 03)
• Enter new voucher year (this will only occur when generating vouchers for January)
• Enter Distribution Date (this will be date the voucher will be posted in the GL)
  Process

NOTE: You can review and update these vouchers in A/P Vouchers and Adjustments prior to posting.

In Syteline, when you pay for a purchase from a vendor with a credit card, you want to be able to show the purchase under the Purchase Vendor, but the payment will need to be remitted to the Credit Card Vendor.  How to handle this in Syteline?

A possible solution is to create a Bank Code for Credit Card. The cash account should be some type of clearing account. You will need to add a bank rec for type “Check” to set the starting check number for this new bank code. Receive and voucher the purchase order as normal. Post the voucher. Go into A/P Payments and add a payment record for the vendor using the Credit Card Bank Code. Either go to Quick and select the voucher that was paid by credit card, or go to Distributions and add the voucher there. Process A/P Check Printing and Posting. Add a manual voucher for the Credit Card vendor for the total amount. Use the same clearing account for the distribution on this manual voucher.

This way, the vendors purchases YTD remain in tact, and the payment is actually remitted to the Credit Card vendor.

This is about Progress version of Syteline, on how multi-currency works in Financial Statements.

FINANCIAL STATEMENTS
The exchange rate table (could be local or global) normally used by the database from which the Financial Statement is being printed will be used for the translations. Therefore, unless Current Rate translation is to be used on all accounts, the exchange rates in the Corporate database would best be entered correctly throughout the fiscal year, even if no translations are needed between those currencies until the financial statements are printed. Alternatively, exchanged rates may be entered and back-dated (e.g.,;, for subsidiaries acquired in the middle of the year), assuming a sufficient rate history has been stored correctly elsewhere (e.g.,’, on paper or in the new subsidiary’s system).
FINANCIAL STATEMENT OUTPUT
gl/calc-bal.p:
If None translations is requested, calculate balance as it is done currently.
If Current Rate translations is requested, calculate balance as above, then find current exchange rate and translate and round to the Corporate’s currency.
If End of Period translations is requested, translate each pertot.amt at its end of period exchange rate, and translate the remaining ledger amounts at each one’s end of period exchange rate. Then round the final balance.
If Average Period rate translation is requested, proceed like End of Period, but use the following formula to calculate the average exchange rate for each period.
Avg. Rate = (SUM(Rate * Effective Time))/
( Length of Period)
where Effective Time is the amount of time during which the rate was in effect during the period ( in seconds), and length of Period is also in seconds.
For speed, you may want to calculate, before starting through the sequence lines, the average buying and selling rates for all periods appearing on the report ( if any sequence lines use this method), and save them in a workfile or array for use here.
If Spot Rate translation is requested, DO NOT USE pertot records. Translate each ledger amount at the exchange rate in effect on its Transaction Date. Round the final balance.
We Process all posted transactions and upgrade them to the current exchange rate. For each voucher that has a gain or loss, we post the mount to Accounts payable and the Gain or Loss Account.
FINANCIAL STATEMENTS
Users are able to print Financial Statements in different currencies. Prior to SYMIX 4.0, they could only accomplish this when they were consolidating multiple divisions. The “final” Financial statement would be printed in the currency of the division running the report. The exchange rates used to convert the data were the ones stored in the division running the report. Now in V4.0, users can choose which currency they wish to print their financial statements in. The exchange rates used to print the report are the rates stored in the database that contains the ledger records being processed. The translations are for display purposes only. No posting of any kind takes place & no gain or loss is calculated.
Translations are defined for each line of the financial statement. Users choose to use the Buying or Selling Exchange rate. They choose a translation method: None ( no translations), Spot (historic rate for each transaction), Current ( current exchange rate), Average Period (weighted average exchange rate in effect for the accounting period for each transaction), End of Period (exchange rate in effect at the end of the accounting period for each transaction)

I have been trapped on this more than one time.  In order for a method call validator to work, the return value has to be bigger than 5.  This is clearly state in the WinStudio document: “If the method returns a value less than 5, WinStudio passes the validation. Otherwise, WinStudio fails the validation. The values 1 through 4 are used for warnings.”

All the standard Syteline Validators are using return value 1, so you would naturally copy that logic, and have it kept pumping on your face.  The value 1 through 4 are reserved for system use.  For customization developer like you and me, we have to be taller than 5.

Today I have waste two hours on this.  I knew it can not be 1, because I was trapped on this about a year ago.  But I forgot what the exact value benchmark is.  I was putting a value 4 on it.  And keep searching other area for error.  Finally I checked back into the document and found out again the magic number 5.  What a fool. 

I think this is one of the FAQ question for T-SQL programmer, and here is some quick sample 

Last Day of Previous Month

SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE()),0)) 

Last Day of Current Month

SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0))

Last Day of Next Month

SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+2,0))

Show name of the month:

select datename (mm, date_field)

Or if you want to only show the first three letters of the month:

select left(datename (mm, date_field), 3)

From out of box Syteline, the pull down list of customer# field is sorted by customer#.  The same thing happens to the vendor# field.  Many Syteline users would prefer that the pull down list is sorted by customer name / vendor name in alphanumeric order, especially when you have hundreds customers/vendors.

Syteline Application Case

Change the sorting of Customer#/Vendor# pull down list, from Customer#/Vendor# to Customer Name/Vendor Name.

Syteline Technical Components

Component class, List Source

Customization Solution

The pull down list of a field is usually controlled by the component class that the field inheritance.

Get into the design mod of the form, example like RMA form.  Click the Customer field, then, in component property sheet, locate the Inheritance, Component Class.  Open the component class “RMACustomerZero”

Open the List Sources

Click the “Filter etc.” button

Enter “Name” in OrderBy field.

Then click OK all the way back.  Save the form.  Now, try the pull down list, it is now sorted by name in alphanumeric order.