Archive

Posts Tagged ‘CO’

How Syteline handles multi-currency transactions

January 16th, 2011 No comments

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)

Assigning field value in a Syteline Form, based on another field value entered. (1)

February 17th, 2010 No comments

In Syteline form, quite often, you would need to assign some field value, base on another field value entered.

Business case:

Let say in Customer Order, for certain payment terms, you would not allow partial shipment.  So in the CO header form, when user select certain payment term, you want the system automatically uncheck the “Ship Partial” check box.

Syteline Technical Components:

Inline Script, Event Handler

Solution

In Syteline 7 & 8, there is quite a few differ ways to accomplish this.  The first one we are going to discuss here is to use Inline Script.

1)      In Customer Order Form, for form component: TermCodeEdit, add a data change event: TermChange.  And the event handler will call an Inline Script

2)      The Inline Script:

Option Explicit On

Option Strict On

Imports System

Imports Microsoft.VisualBasic

Imports Mongoose.IDO.Protocol

Imports Mongoose.Scripting

Namespace SyteLine.GlobalScripts

Public Class EvHandler_TermChange_0

Inherits GlobalScript

Sub Main()

if ThisForm.PrimaryIDOCollection.GetCurrentObjectProperty(“TermsCode”) = “128” then

ThisForm.PrimaryIDOCollection.SetCurrentObjectPropertyPlusModifyRefresh _

(“ShipPartial”, “0”)

end if

ReturnValue = “0”

End Sub

End Class

End Namespace

This script will assign the ShipPartial to 0, when user select TermsCode = 128.

DO and Consolidate Invoice

March 24th, 2009 No comments

Syteline Delivery Orders are always handled by Consolidate Invoice.

1) Shipment can be tied to a DO during the shipping process. 
2) Shipment can also be put into a DO after the shipping process.  Just open that DO and add the shipment record to that DO.
3) DO invoicing will be always under the consolidate invoice.
4) After the invoice being printed, before the invoice post, if need to change the invoice date, change inv-hdr.inv-date, inv-hdr.ship-date; and change the arinv.inv-date and arinv.due-date.

Applying Open Credit and Debit

February 24th, 2008 2 comments

Open Credits and Debits

Any credit memo created in SyteLine from a credit return or price adjustment invoice will automatically be created as an open credit.  Debit memos created by price adjustment will also be open.  Only when creating a credit or debit through AR you are given the opportunity to dictate which posted invoice the transaction is to be applied to at the time of creation.

To “clear up” open credits, debits and payments in Accounts Receivable Posted Transactions the open items must be applied to one or more invoices.  Credit memos and debit memos cannot be selected for payment and therefore can remain on an aging report as an open balance causing some amount of trouble in reporting as well as causing aging reports and other reports to take longer to run.

The reapplication process for each transaction type will be addressed individually.

Credit and Debit Memos – One to one

To reapply a credit or debit memo to a single invoice navigate to the AR Posted transactions screen and follow these steps.  Prior to doing the steps for reapplication review the transactions for the customer and determine in advance where you want to apply the credits.

  • Put focus (cursor) on the credit/debit memo to be applied.
  • View the detail for this transaction.  Depending upon the version you are running this may be a check box, double click, or tab.
  • In the field labeled Invoice enter the invoice number this credit is to be applied to.
  • Save.

If you have an open credit and an open debit for the same absolute amount apply them to the same invoice.  If you want these items to drop off your aging immediately apply them to a paid invoice.  Providing the debit and credit are for the same absolute amount the net change to the value of the invoice will be zero.

Credit Memos and Open Payments – Applied to Multiple Invoices

In the case where there is one credit memo that needs to be spread over multiple invoices or if only a portion of a credit memo is to be applied to an invoice follow these steps.

  • Navigate to A/R Posted Transactions.
  • Put focus on the target credit.  Note the number appearing for this transaction in the Chk/Ref column.
  • Navigate to Customer Payments.  Enter a payment for the customer under discussion.  In the Check Number field enter the Chk/Ref number you just looked up.
  • SyteLine should give you a display in the Description field that says Reapplication of Open Credit.
  • Be aware the date that SyteLine returns will be the date the open credit was created.  This date should be overridden and changed to the current date in order to keep historical aging reports accurate.
  • Apply the credit as if it was a check, using all standards and procedures you have in place for AR cash receipts.
  • You can leave an open remainder if desired.

Removing or hiding applied items

Once all of the open credits, debits and payments have been applied to the appropriate invoices you may want to have them drop off your aging and posted transaction screen.  This can be accomplished by running either Activate/Deactivate Posted Transactions or Delete A/R Posted Transactions.

End User Type

February 24th, 2007 No comments

The End User Type allows you to assign G/L Accounts, specific to a type of customer and provide an additional reporting functionality.  You have the ability to use Unit Codes 3 and or 4 to identify different categories.  For example, Unit Code 3 can be used to break out Sales separately, 1000 could represent Domestic, and 2000 could represent International.

The use of End User Types will provide additional sales information to the ledger.  You will be able to see not just sales of a product type but sales of a product type to a customer type.

This screen will add End User Type and define what account numbers are to be used for reporting purposes.

To Define End User Type:

ScreenShot002

End User Type: Create a code to represent this end user –  6 alpha/numeric positions. (i.e.Intl)

Description:  Full definition of end user type – 15 alpha/numeric positions.

Enter the G/L Account numbers that applies for each category.  Typical implementations will use the default accounts for Accounts Receivable, Sales, and COGS.

Enter the appropriate Unit Code in unit code 3 or 4

Note:   Unit Code 2 is to remain blank on this screen.   Leaving UC2 blank will  allow SyteLine to use the default Unit Code 2 extension as defined in Distribution Accounts for the product being sold.

To Update Customer Master File with End User Type:

ScreenShot003

Distribution Accounts

Sales of a product in the FG-100 product code to a customer in the DSTRB end user type category would result in GL trx that looked like this:

Acct                       UC2       UC3

11000                                    1000                                       $100

40000                    0001       1000                                                       $100