Sunsystems - 6.4.xSunSystems Financials

SunSystems Financials
Release 6.4.x
Copyright © 2022 Infor
Important Notices
The material contained in this publication (including any supplementary information) constitutes and contains
confidential and proprietary information of Infor.
By gaining access to the attached, you acknowledge and agree that the material (including any modification,
translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest
therein, are the sole property of Infor and that you shall not gain right, title or interest in the material (including
any modification, translation or adaptation of the material) by virtue of your review thereof other than the
non-exclusive right to use the material solely in connection with and the furtherance of your license and use
of software made available to your company from Infor pursuant to a separate agreement, the terms of which
separate agreement shall govern your use of this material and all supplemental related materials ("Purpose").
In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain
such material in strict confidence and that your use of such material is limited to the Purpose described above.
Although Infor has taken due care to ensure that the material included in this publication is accurate and
complete, Infor cannot warrant that the information contained in this publication is complete, does not
contain typographical or other errors, or will meet your specific requirements. As such, Infor does not assume
and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity
which is caused by or relates to errors or omissions in this publication (including any supplementary
information), whether such errors or omissions result from negligence, accident or any other cause.
Without limitation, U.S. export control laws and other applicable export and import laws govern your use of
this material and you will neither export or re-export, directly or indirectly, this material nor any related
materials or supplemental information in violation of such laws, or use such materials for any purpose
prohibited by such laws.
Trademark Acknowledgements
The word and design marks set forth herein are trademarks and/or registered trademarks of Infor and/or
related affiliates and subsidiaries. All rights reserved. All other company, product, trade or service names
referenced may be registered trademarks or trademarks of their respective owners.
Publication Information
Release: Infor SunSystems 6.4.x
Publication Date: September 7, 2022
Document code: sunsystems_6.4.x_ssfinolh__en-us
Contents
Contents
Contacting Infor........................................................................................................................11
Chapter 1: Financials overview...................................................................................................12
Chapter 2: A Quick Guide to Allocating Transactions After Posting.................................................14
Chapter 3: Entering journals and transactions..............................................................................15

Introducing Ledger Entry.................................................................................................................................15
Analyzing transactions.................................................................................................................................15
Entering the correct codes...........................................................................................................................16
Journal totals and balances........................................................................................................................16
Understanding the Ledger Entry forms...........................................................................................................16
The Ledger Entry Menu and Toolbar...........................................................................................................17
The Ledger Entry Command Buttons..........................................................................................................19
Selecting the Ledger Entry Form for a Journal Type..................................................................................20
Entering and posting a journal........................................................................................................................20
A Quick Guide to Entering a Journal............................................................................................................20
Entering the Journal Details........................................................................................................................22
Entering Journal Notes................................................................................................................................29
Entering Multi-Currency Journals...............................................................................................................30
Allocating transactions during Ledger Entry..............................................................................................32
Reviewing and amending a journal.............................................................................................................37
Posting or holding a journal.........................................................................................................................44
Understanding more about selected journal details.................................................................................48
Reversing and copying journals...................................................................................................................52
Using the provisional ledger............................................................................................................................58
What are Provisional Transactions?............................................................................................................59
Entering Provisional Transactions..............................................................................................................60
Amending Provisional Transactions............................................................................................................60
SunSystems Financials | 3
Contents
Deleting Provisional Transactions...............................................................................................................62

Making Provisional Transactions Permanent.............................................................................................62
Using Post Provisional Journals..................................................................................................................63
Posting Withheld Taxes....................................................................................................................................63
Temporarily Grouping Ledger Data.................................................................................................................64
Reporting Transactions....................................................................................................................................64
Chapter 4: Authorizing Transactions............................................................................................65
Understanding the Authorization Process......................................................................................................65
What Transactions Require Authorization?....................................................................................................66
Creating and reviewing authorization sets.....................................................................................................67
Marking Transactions for Authorization......................................................................................................67
Reviewing the authorization sets for an originator....................................................................................68
Reviewing an Authorization Set...................................................................................................................68
Running the Authorization Audit Trail.........................................................................................................69
Reviewing the Authorization Audit Headers...............................................................................................70
The steps required to authorize transactions.................................................................................................71
Selecting Transactions for Authorization....................................................................................................71
Authorizing a Set of Transactions................................................................................................................72
Rejecting Transactions Awaiting Authorization..........................................................................................72
Understanding the authorization intray.....................................................................................................73
Chapter 5: Matching and allocating transactions..........................................................................74
What is Matching?............................................................................................................................................74
What Matching and Allocation Facilities are Available?.................................................................................75
What is Instalment Checking?.........................................................................................................................76
Account Allocation...........................................................................................................................................77
Understanding the Account Allocation Forms............................................................................................79
Balancing the Allocations............................................................................................................................86
Using Account Allocation.............................................................................................................................90
Matching transactions using account allocation........................................................................................98
Splitting transactions.................................................................................................................................104
Posting Allocations.....................................................................................................................................111
Transaction Matching....................................................................................................................................113
Selecting Accounts and Transactions for Matching.................................................................................114
Defining the Transaction Matching Criteria..............................................................................................115
Contents
Applying Discounts in Transaction Matching............................................................................................116

Matching in the Transaction Currency......................................................................................................117
Using Transaction Matching......................................................................................................................117
Allocation Markers.........................................................................................................................................120
What Allocation Markers are Available?....................................................................................................120
Updating the Allocation Markers Manually...............................................................................................122
Which Allocation Markers Must Balance?..................................................................................................122
Naming the Allocation Markers.................................................................................................................123
Updating Allocation Markers in Ledger Entry...........................................................................................124
Chapter 6: Importing ledger entries...........................................................................................125
Understanding Ledger Import.......................................................................................................................125
Dealing with Errors in Ledger Import........................................................................................................127
Reporting on the Import Process...............................................................................................................128
Editing Ledger Import Files........................................................................................................................129
Importing Multi-Currency Transactions....................................................................................................130
Running Ledger Import..................................................................................................................................130
The steps to manually import journals.....................................................................................................130
Loading transactions from Order Fulfilment................................................................................................139
Loading Transactions from Ledger Interface............................................................................................139
Extracting Ledger Interface transactions..................................................................................................140
Using the Ledger Posting Control Desk.....................................................................................................140
Entering the Generate Ledger Batch Parameters.....................................................................................141
Chapter 7: Generating payments and receipts............................................................................144
How are Payments Generated?.....................................................................................................................144
Understanding Payment Run....................................................................................................................145
Preparing for a Payment or Collection Run..............................................................................................146
Understanding the Payment Run Details Report......................................................................................147
Authorizing Payments................................................................................................................................148
Overriding the Currency Rates for Payments and Collections.................................................................149
Generating payments using Payment Run...................................................................................................149
Initiating a Payment Run............................................................................................................................150
Using Payment Run....................................................................................................................................151
Paying Transactions Immediately.............................................................................................................156
Analysis Consolidation and Interaction with Business Rules..................................................................157
Contents
Voiding a System Generated Payment......................................................................................................159

Generating payments using Control Desk....................................................................................................162
Initiating a Payment Run from a Control Desk.........................................................................................162
Stamping Payment Transactions..............................................................................................................163
What are Manual Payment Overrides?......................................................................................................163
Entering Manual Payment Overrides.........................................................................................................165
Selecting and Reviewing Transactions for Payment....................................................................................165
Creating a Payment Set (Saved Set)..........................................................................................................166
Removing Transactions from a Payment Set............................................................................................166
Splitting a Transaction within a Payment Set...........................................................................................167
Sending a Payment Set for Payment or Authorization.............................................................................167
Using the Selection - Payment Selection and Review Form....................................................................168
Collecting customer payments......................................................................................................................168
What is the Payment Collection Run?.......................................................................................................169
Preparing for a Payment or Collection Run..............................................................................................169
Initiating a Payment Collection Run..........................................................................................................171
Using Payment Collection Run..................................................................................................................172
Payment documents......................................................................................................................................176
What Payment Documents are Available?................................................................................................177
Producing Payment Documents................................................................................................................179
Using Payment Documents.......................................................................................................................180
Printing on Special Stationery...................................................................................................................181
Assigning Payment Document Reference Numbers.................................................................................181
Account Documents.......................................................................................................................................182
Producing Account Documents.................................................................................................................183
Using Account Documents.........................................................................................................................183
Chapter 8: Maintaining budgets.................................................................................................185
Entering Budget Values..................................................................................................................................185
Reallocating budgets.................................................................................................................................187
Manual budget entry..................................................................................................................................187
Predefining budget transactions...............................................................................................................188
Generating budgets in a spreadsheet.......................................................................................................188
Chapter 9: Intercompany posting..............................................................................................189
Understanding the Intercompany Posting Process.....................................................................................189
Contents
Intercompany Posting Workflow Example...................................................................................................189

Intercompany Posting Status........................................................................................................................193
Chapter 10: Re-allocating costs and revenue..............................................................................194
Understanding the Corporate Allocations Run............................................................................................194
Validating Corporate Allocations..................................................................................................................195
Running an Allocation....................................................................................................................................196
Chapter 11: Financials inquries.................................................................................................199
Account inquiry..............................................................................................................................................200
Performing an Account Inquiry..................................................................................................................200
Using Account Inquiry to Extract Transactions onto the Control Desks In-Tray.........................................200
Performing a Ledger Archive Inquiry.............................................................................................................201
Performing a Journal Inquiry........................................................................................................................201
Account balance inquiry................................................................................................................................202
Performing an Account Balance Inquiry...................................................................................................202
Performing an Intercompany Awaiting Posting Inquiry...............................................................................202
Performing an Intercompany Posting History Inquiry.................................................................................203
Performing an Intercompany Journals Received Inquiry............................................................................203
Using the Inquiry Results Forms....................................................................................................................204
Viewing Summarized Currency Totals..........................................................................................................205
Viewing the Financials Inquiry Results..........................................................................................................205
Printing the Results of a Ledger Inquiry........................................................................................................206
Viewing Voucher Numbering.........................................................................................................................206
View latest voucher numbering.....................................................................................................................207
View voucher numbering gaps......................................................................................................................207
Chapter 12: Financials Transaction Lists and Report Writer Reports.............................................209
Financials Transaction Listings.....................................................................................................................210
Producing an Account Listing....................................................................................................................211
Producing an Account Listing with Archived Transactions......................................................................212
Producing a Journal Listing.......................................................................................................................212
Producing the Journal Postings Audit Report..........................................................................................214
Printing Held Journals...............................................................................................................................215
Printing Payment Transactions.................................................................................................................215
Trial balance...............................................................................................................................................216
Aged Analysis Reports................................................................................................................................218
Contents
Daybook Listing..........................................................................................................................................220
Tax Reporting.................................................................................................................................................224
Setting Up User Defined Tax Reporting.....................................................................................................225
Setting Up the Standard Tax Reports........................................................................................................227
Setting Up the Business Rules for Tax Reporting......................................................................................227
Running Tax Reporting...............................................................................................................................228
Entering the Tax Reporting Transaction Selection Criteria.....................................................................229
Producing financial reports...........................................................................................................................231
Producing a Financial Analysis Report......................................................................................................231
Producing a Financial Statement..............................................................................................................232
Producing a Financial Table Report..........................................................................................................233
Reporting on Assets.......................................................................................................................................234
Producing the Asset Register Report.........................................................................................................234
Producing the Asset Status Report............................................................................................................235
Chapter 13: Managing fixed assets.............................................................................................237
Entering Asset Transactions..........................................................................................................................237
The effect of depreciation locking.............................................................................................................238
The effect of depreciation locking combined with adjustments to gross value.....................................238
Manually posting a depreciation amount.................................................................................................238
Running the depreciation calculation...........................................................................................................239
Closed or suspended accounts..................................................................................................................240
Multi-currency depreciation......................................................................................................................240
Depreciation exceptions............................................................................................................................240
Calculating depreciation............................................................................................................................240
Depreciation calculation consolidation....................................................................................................242
Performing an Asset Inquiry..........................................................................................................................242
Enhanced depreciation..................................................................................................................................243
Selecting assets for reduction depreciation.............................................................................................243
Running the Reduction Depreciation........................................................................................................244
Selecting assets for advanced depreciation.............................................................................................246
Running the advanced depreciation calculation......................................................................................246
Calculating Advanced and Reduction Depreciation.................................................................................249
Asset Disposal.................................................................................................................................................249
Determining the disposal period...............................................................................................................250
What are the disposal postings?................................................................................................................250
Contents
Selecting a group of assets for disposal....................................................................................................250

Disposing of Assets.....................................................................................................................................251
What is Asset Part Disposal?......................................................................................................................252
Disposing of part of the quantity of an asset............................................................................................255
Chapter 14: Reconciliation Manager..........................................................................................257
Running Reconciliation Manager..................................................................................................................258
Selecting Transactions for Reconciliation................................................................................................259
Understanding the Reconciliations Transaction Lists..............................................................................260
Tailoring the Reconciliations Transaction Lists........................................................................................261
Hiding or Displaying Reconciled Transactions.........................................................................................261
Finding Transactions in Reconciliation Manager......................................................................................262
Generating Transactions in Reconciliation Manager...............................................................................262
Reconciliation Manager Generate.............................................................................................................263
Splitting Transactions in Reconciliation Manager....................................................................................264
Posting Exchange Differences from Reconciliation Manager..................................................................264
Reporting on Reconciled Transactions.....................................................................................................265
How Does Auto-Reconcile Work?...............................................................................................................266
Reconciliation Profiles...................................................................................................................................269
Defining a New Reconciliation Profile.......................................................................................................270
Setting Up Reconciliation Profiles.............................................................................................................270
Reconciliation Accounts................................................................................................................................275
Setting up Reconciliation Accounts..........................................................................................................276
Chapter 15: Withholding tax......................................................................................................278
What is Withholding Tax?...............................................................................................................................278
Overview of Calculating and Recording Withholding Tax............................................................................279
What are the Withholding Tax Cumulative Totals?...................................................................................279
Where is the Withholding Tax Rate Defined?............................................................................................280
Setting up the Withholding Tax reference data............................................................................................280
Withholding Tax Types...............................................................................................................................281
Defining calculation rules..........................................................................................................................284
Adding and Maintaining the Cumulative Tax Time Frames.....................................................................287
Defining Withholding Tax Exemptions......................................................................................................287
How is Withholding Tax Calculated?.........................................................................................................288
What Transactions are Generated for Withholding Tax?..........................................................................289
Contents
Voiding Withholding Tax Transactions......................................................................................................290
Contacting Infor
Contacting Infor
If you have questions about Infor products, go to Infor Concierge at https://concierge.infor.com/ and create
a support incident.
The latest documentation is available from docs.infor.com or from the Infor Support Portal. To access
documentation on the Infor Support Portal, select Search > Browse Documentation. We recommend that
you check this portal periodically for updated documentation.
If you have comments about Infor documentation, contact documentation@infor.com.
Financials overview
Chapter 1: Financials overview
SunSystems Financials is an integrated accounting system.

It provides these functions in a single, combined ledger:
• General Ledger
• Accounts Payable/Purchase Ledger
• Accounts Receivable/Sales Ledger
• Client Ledger
• Budgeting
• Corporate Allocations
• Consolidation
• Project/Job Costing
• Report Writers
Using the system is simple yet advanced enough to meet a wide range of accounting requirements. You
control all the accounting structures, entry types, processing rules and reporting functions and you can tailor
them to fit your business requirements.
SunSystems Financials maintains all of your accounting details within a single, integrated ledger. You do not
require separate receivables and payables ledgers, project ledger, or fixed asset register.
These functions are provided in a single, combined ledger:
• General Ledger
• Accounts Payable/Purchase Ledger
• Accounts Receivable/Sales Ledger
• Client Ledger
• Budgeting
• Corporate Allocations
• Consolidation
• Project/Job Costing
• Report Writers
Single ledger integration and the real-time processing ensures that all accounts are always up to date and in
balance. It also avoids the requirement for data duplication and reduces the possibility of error. The single
source of financial data means that reports and inquiries always reflect an accurate position.
All ledger entries are held in the single ledger for as long as you require. You can attach multiple analysis
codes to each entry, to each account, and to several other useful data entities. These analysis codes allow
you to extract and report on your data in many different ways, according to your business requirements. You
have complete control over the analysis codes, and reporting structures. The single ledger environment
Financials overview
allows you to report across all ledgers, accounts, accounting periods and analysis codes, at any level, as
required.
Dual-Base Currency
SunSystems Financials provides dual-base currency processing throughout the entire accounting suite.
These currency facilities provide full euro-compliance and enable GAAP processing and reporting.
A Quick Guide to Allocating Transactions After Posting
Chapter 2: A Quick Guide to Allocating Transactions After

Posting
Use Account Allocations (ACA) to match selected transactions that have already been posted to an account.
For example, you can use it to match a payment transaction to the transactions it has paid. You can also use
it to amend selected transaction details.
Note: You can select the allocations for matching using a control desk. This replaces the first 3 steps below.
Carry out the following steps to allocate transactions:
1 From SunSystems select Account Allocations (ACA).
Note: There may be many different account allocation menu commands, each of which is a tailored
version of Account Allocations.
The Selection Criteria for Account Allocation form is displayed.
2 Specify the allocation batch selection details.
3 Click Extract to select the transactions that meet the selection criteria.
4 If there are several allocation forms available, then Find Form List is displayed and you must select the
form you require.
5 The Account Allocations form is displayed, listing all of the transactions selected for allocation.
6 If you wish to match transactions, you must set the appropriate allocation marker on the transactions
to be matched. You can:
a Fully match selected transactions.
b Split and partially match a transaction.
You can enter the first letter of the allocation marker you require to set it. For example, you can enter T
to set the To Be Allocated marker.
You can view the allocation totals to check that the allocations balance.
7 If you wish to amend selected transaction details, you can use this form to:
a Amend a transaction's details.
b Amend the allocation marker on all selected transactions, or on a selected range of transactions.
This option can be used to fully allocate a number of transactions at once.
8 To enter additional text, from the Action menu select Standard Text.
9 When you have made all of the required allocations and amendments, select the relevant Post By currency.
The posting process may calculate and apply discount, write on or write off an imbalance, or post a gain
or loss exchange difference journal to balance the allocations.
Entering journals and transactions
Chapter 3: Entering journals and transactions
Ledger Entry (LEN) is the core online facility used to enter and post transactions to the Financials ledger.
Introducing Ledger Entry

Ledger Entry (LEN) is the core online facility used to enter and post transactions to the Financials ledger.
It is a powerful and flexible facility that enables you to enter the simplest, or most complex transactions, in
the most appropriate format.
SunSystems includes several powerful tools, including Form Designer that can be used to produce different
versions of the Ledger Entry form to meet the requirements of different types of transaction. These specific
Ledger Entry forms may be defined as individual menu commands from the SunSystems menu.
You can enter different types of journals using Ledger Entry (LEN), by selecting the appropriate journal type.
The appearance of the Ledger Entry form may change if the journal type uses a different form layout to the
one currently displayed.
A wide range of facilities are available to help you enter your ledger transactions. For example, journal presets
can provide default field values, skeleton journal lines, and prompt you to enter the appropriate information.
At any stage, you can view the transactions you have entered in the current journal. You can also use menu
options to show the totals of transactions entered in each currency, for each period, or for each transaction
reference.
If the Authorization facility is enabled for the ledger, some types of journals may require authorization. Once
these journals balance they are automatically held until they have authorized, at which stage they are posted
automatically.
You can post transactions to any period and date, unless restrictions have been imposed in Ledger Setup
(LES) or in the Operator Group.
Ledger Entry also allows you to match transactions using Online Allocation.
Analyzing transactions
You can enter up to ten analysis code details on each transaction.
The analysis codes required for a particular transaction will depend on the journal type and ledger account.
Default analysis codes can be provided by a journal preset.
Entering the correct codes

During Ledger Entry, you are required to enter a variety of codes, including account codes, asset codes, and
analysis codes. Any of these codes may be preset for particular journal types.
If not, SunSystems offers tools to help you select the correct codes:
• A Query button is available on all reference fields which lists the available codes and allows you to search
for and select the code you require.
• You can also use Navigation options to scroll through the existing codes to find you code you require.
Journal totals and balances

While entering a journal, running totals of debits and credits, and the difference between the two totals, are
displayed in the top right of the screen.
You can only post a batch when the debit and credit transactions, for each period, balance.
During Ledger Entry you can also display the balance of the account entered on the current transaction. The
account balance displayed excludes other unposted transactions but includes any debits or credits entered
in earlier lines of the current journal.
Understanding the Ledger Entry forms

Ledger Entry (LEN) is used to enter journal details online.
Although this is a single Financials function it is extremely powerful and flexible. The appearance and use of
the Ledger Entry form can change dynamically to meet the requirements of a particular type of journal.
The Financials menu can include several different Ledger Entry commands, each supporting a different type
of journal or transaction. For example, separate options to enter local currency cash receipts, currency receipts,
adjustments, accruals, general journals, asset additions and so on.
If a Ledger Entry menu command does not refer to a particular journal type, you are prompted to enter one.
Note: All of the topics that discuss Ledger Entry (LEN) refer to the layout and terminology that appears on
the default Ledger Entry (LEN) forms delivered with the system.
Ledger Entry Form Styles

The Ledger Entry (LEN) input form can be tailored to your organization's requirements using SunSystems
Form Designer (FRD). For example, you could use Form Designer (FRD) to create a form that matched one of
your existing input documents. SunSystems is delivered with several default ledger entry forms, and in general
they can be categorized into three form styles:
• form style, for example the Basic Ledger Entry (LEN) form, D_LEBF
• grid style, for example the Basic Ledger Entry (LEN) Grid form, D_LEBG
• combined form and grid style, for example the Ledger Entry Multi-Currency Combined, D_LEMC.
The form that is displayed for ledger entry depends on the form code associated with the journal type that
you select after you select Ledger Entry (LEN).
Ledger Entry Form Functions

The Ledger Entry (LEN) form includes a number of different functions. These are accessed from menu
commands or toolbar buttons at the top of the form. Some more important functions are also included as
command buttons at the bottom of the form.
Journal Transaction Fields Available

Although the Ledger Entry form can appear in different styles, it will still contain many of the same fields.
There is a fixed set of fields that can be entered on each ledger journal line. The Ledger Entry form you select
only displays the fields that are included in the form definition. The fields that appear and the layout of the
form are determined by the form associated with the journal type you select. The form is identified in Form
Name using Journal Types (JNT).
For example, if you are entering a local currency invoice the form definition might not display the transaction
currency fields but might include the payment related fields. Whereas, if you are entering an adjustment
journal, a different form might be used that displays neither the currency nor payment details, if they are not
required.
The Ledger Entry Menu and Toolbar

The Ledger Entry (LEN) form contains a number of specific functions required to enter, amend, view and
post journals.
These functions can be accessed from the Action menu.
The Action menu commands are briefly explained below, and any corresponding toolbar button is identified.
Menu Com- Sub-Menu Command Tool- Use

mand bar But-
ton
Totals Currency Totals - Base Displays the totals in base currency
Currency
Currency Totals - Transac- Displays the totals in transaction currency
tion Currency
Currency Totals - Re- Displays the totals in second base or reporting cur-
port/Second Base Currency rency
Currency Totals - Fourth Displays the totals in fourth currency

Currency
Journal Totals Displays the totals for all journal lines
Reference Totals Displays the totals of transactions for the current
journal reference
Allocation Totals Displays the total of the allocated transactions
Post Post Posts the journal, providing it satisfies the validation

rules
Post Provisional Posts the journal to the Provisional ledger, providing
it satisfies the validation rules
Balances Account Balance Check - Displays the account balance details, in base curren-
Base Currency cy, for the account on the current line
Account Balance Check - Displays the account balance details, in reporting
Report/Second Base Ccy or second base currency, for the account on the
current line
Period Balances Displays the debit and credit totals for each account-
ing period to which transactions are being posted
in the journal
Transaction Balances Displays the debit and credit totals, for each trans-
action reference in the journal
Options Goto - First Ref Displays the first journal line for the first journal
reference
Goto - Previous Ref Displays the first journal line for the previous journal
reference
Goto - Next Ref Displays the first journal line for the next journal
reference
Goto - Last Ref Displays the first journal line for the last journal
reference
Amend Presets Allows you to apply a different journal preset
Amend Reference Allows you to amend the current journal reference
New Reference Allows you to enter a journal line for a new journal
reference
Create Without Presets Allows you to enter the journal without applying the
journal presets associated with the journal type
Line Go To - First Displays the first journal line
Go To - Prev Displays the previous journal line
Go To - Next Displays the next journal line
Go To - Last Displays the last journal line
New Line Allows you to enter a new journal line
Amend Allows you to amend a selected journal line
Examine Allows you to view a selected journal line

Delete Allows you to delete a selected journal line
Standard Text Allows you to enter standard text
New Jour- Allows you to select a different journal type for a

nal Type new journal, after you have posted the current
journal
Recall Provi- Allows you to recall a provisional journal
sional
View Held Allows you to view and select a held journal
Journals
Cancel Jour- Allows you to discard the current journal details
nal
Hold Places the current journal on hold
View Displays the entire journal

Report Allows you to print the current journal details
Online Allo- Allows you to allocate the journal transactions

cation
The Ledger Entry Command Buttons

The Ledger Entry (LEN) form contains these command buttons at the bottom of the form.
You need to use several of these, or the corresponding menu commands or toolbar buttons, to enter and post
a journal.
These buttons are briefly explained below, and the corresponding toolbar button is identified.
Command Button Toolbar But- Use

ton
OK Validates and accepts the current journal line
Cancel Discards the details for the current journal line
Post Posts the journal, providing it is in balance and satisfies the
validation rules
Hold Places the journal on hold
New Line Allows you to enter a new journal line for the current journal
reference
New Reference Allows you to enter a new journal line, with a new reference
New Journal Type Allows you to select a different journal type for a new journal,
after you have posted the current journal
Exit Leaves the Ledger Entry form and returns to the menu
Selecting the Ledger Entry Form for a Journal Type

When you select a journal type, the Form Name identified in Journal Types (JNT) is used to determine the
Ledger Entry form to display. If a default form has not been identified for the journal type, the list of Ledger
Entry forms that can be used for the journal type is displayed, so that you can select the form you want to
use.
1 Run Ledger Entry (LEN). The Ledger Entry - Journal Type form is displayed.
2 Select a journal type.
3 Optionally specify a user as the journal source.
4 Click OK.
5 If a default Ledger Entry form has not been selected for the journal type you have chosen, the Find Form
list is displayed.
6 Identify and select the appropriate form for the journal type.
7 Click OK to display the form.
Entering and posting a journal

Ledger Entry (LEN) is used to enter journal details online.
The Post command posts valid journals to the financial ledger.
A Quick Guide to Entering a Journal

These steps are required to enter a journal using Ledger Entry (LEN).
Note: These steps are provided as a guide. The exact steps required to enter a journal depend on the form
layout, journal type and journal presets that apply.
1 From SunSystems select the appropriate Ledger Entry input command.
Note: If a journal type has not been specified in Ledger Entry, you are prompted to enter it.
Note: If a form has not been associated with the journal type, you are asked to select the appropriate
Ledger Entry form.
2 If necessary, select the Business Unit. This may have been preset automatically.
3 If required, select the Journal Type, click OK or press Return.
The form layout may change at this stage, depending on whether a specific Form Name is associated
with the journal type.
Note: If a form has not been associated with the journal type, you are asked to select the appropriate
Ledger Entry form.
4 If necessary, enter your Operator Id. This may have been preset automatically.
5 Enter the Transaction Reference, click OK or press Return.
This reference may apply to one or more journal lines. A journal may contain a number of different
transaction references. The journal may be forced to balance by transaction reference.
6 Enter the remaining journal line details, pressing Tab to move between fields where necessary.
Depending on the form layout, you enter these details in individual fields on the screen, or in a grid.
If journal presets have been defined for the journal type, any preset field values appear automatically.
7 When you have entered the journal line details, click OK to validate these. If the details are correct, the
journal line is added to the journal. This updates the journal totals displayed at the top of the form. Other
Ledger Entry functions display different totals and balances.
If the details are not correct, an error message appears identifying the problem. The cursor is positioned
automatically on the incorrect, or required, field.
8 You can allocate the journals lines to existing transactions for the same account, if required. During the
allocation process you can generate settlement discounts, tax on settlement discounts, and currency
gains/losses. The account allocation form appears automatically if this option has been requested in the
journal preset.
9 If the journal line is for a creditor, debtor, or client account type, and a payment schedule has been
configured and assigned to the related Supplier or Customer record then this transaction line is split into
several transactions, or instalments. Each instalment is generated with a different due date to enable
the staging of payments or collections.
10 Click New Line to enter another journal line, unless the Create Without Pause option is set for the journal
type. Alternatively, click New Reference to enter a new journal line for a different transaction reference.
11 When you have entered all of the journal lines, you may review and amend any of the journal details
before you post it.
12 When you are satisfied the journal is correct, click Post to post it to either the permanent or provisional
ledger.
You can only post a journal when it meets all of the balancing rules.
If you are unable to post a journal for any reason, you can place it on hold. Held journals are reselected
from the Action menu by selecting View Held Journals.
If the journal requires authorization, the Authorization Batch Comment dialog appears and you can
enter a note or comment to assist the authorizer. When you click the journal is placed on hold
automatically.
Entering the Journal Details

Ledger Entry (LEN) is used to enter journal details online. The form contains all, or some, of the following
details, depending on the journal type and form layout.
Note: The fields have been separated into logical groups to make this topic more usable. Not all of these
fields may appear on a particular Ledger Entry form, they may appear in a different order and be grouped
in different ways on some Ledger Entry forms:
• Journal Identifying Details
• Standard Line Details
• Additional Line Details
• Payment Terms
• Multi-Currency
• Asset Details
1 Specify this information for Journal Identifying Details:
Journal Type
The type of journal or ledger transaction you want to enter, as defined in Journal Types (JNT). The
journal type must not have a Status of Closed or Suspended.
Note: You can link a journal type to a payment profile to pay a transaction immediately after it is posted.
Business Unit
The business unit to which the journal is posted. This may be preset.
Operator Code
Your initials, department code or any other code you want use to identify the originator of this journal.
The Force Journal Source option in Ledger Setup (LES) determines whether this is set automatically
to the id of the operator creating or posting the journal or must be entered manually.
2 Specify this information for Standard Line Details:

Transaction Reference
A reference to the accounting or business transaction, normally from the originating document, for
example, the invoice number.
Line Number
The line number is automatically incremented within the current transaction reference. If you want to
view, amend or delete a line, you enter the line number and, if relevant, the line number suffix to identify
the transaction you require.
Accounting Period
Postings are made to the period entered here. The default accounting period is the current period, unless
preset otherwise. You can only post to periods that fall within the open period range specified in Ledger
Setup (LES).
Transaction Date
The date that applies to this transaction. This defaults to the date on the preceding line for the current
transaction reference, or the current date. You can select another date by entering it manually or choosing
it from calendar that appears when you click the down arrow.
You can only post to dates that fall within the open date range specified in Ledger Setup (LES).
Account Code
A valid account code, created using Chart of Accounts (COA), to which the amount on this line is posted.
You cannot select a closed account. If you select a suspended account a warning appears but you can
continue and post to the account.
A prompt may have been preset to help you enter the correct code, or the account code may be preset
and appear automatically. Alternatively, the type of account may have been preset which forces you to
enter a particular type of account, for example, a creditor/payables or balance sheet account.
Description
A description of the business transaction. The default for this field is the descriptive name of the journal
type you are using. If you prefer, you can over-type this.
The Description Per Line option in Journal Types (JNT) determines whether or not you must enter
something in this field. If the option is set to No Default Description, then you must enter a description
on each line. If it is set to Default Description - Override per Reference, you may enter a new description
each time the transaction reference changes. If it is set to Default Description - Override per Line,
you may enter a different description on each line. If you do not enter a different description the Journal
Name is used as the default.
The description can also be preset to be the account code or account name using Journal Presets (JNP).
Base Amount
• In a single currency environment, this is the amount of the transaction. If the amount is in whole
units, you can omit the decimal point and decimal places. The format of amounts, including the
number of decimal places, decimal separator, and thousand separator, depends on the Business
Unit Setup.
The amount may be preset, or calculated automatically from another journal line. You can select
an option in the Debit/Credit field to automatically set this to a balancing amount.
Note: In a multi-currency environment, it may also be calculated from another currency value. This is
described later in the Multi-Currency section below.
If you are using over commitment or over expenditure budget checking you are warned if the amount
entered on this line exceeds the remaining budget for the account.
Debit/Credit
The Debit/Credit marker determines whether the amount is debited or credited to the chosen account.
Alternatively, you can select a balancing option to automatically set the Amount and Debit/Credit
marker to the value required to balance:
• the journal as a whole
• the transactions for the transaction reference on the current line
• the transactions for the period referenced on the current line.
If you have used different transaction currencies on different journal lines, or if you have entered any
journal lines with exchange rates that differ from the current daily or period rates, then multiple balancing
transaction lines may be generated in order to balance all of the different currency values used. In this
case, the generated balancing lines share the same line number, but each is given a separate line number
suffix (as displayed in the second box of the Line Number field).
Ledger Analysis Codes

Up to ten ledger analysis codes can be entered on a ledger transaction. Analysis codes can only be
entered for analysis dimensions that have been assigned to the ledger transactions entity. The analysis
codes required, and whether they are mandatory or optional, depends on the journal type and the
account referenced on the journal transaction. The codes may be preset using journal presets.
Only valid analysis codes can be entered, as defined using Analysis Codes (ANC), unless the analysis
dimension has been defined to allow non validated codes.
Click the Query button alongside an analysis dimension to select the valid analysis codes for each
analysis dimension from the Find Analysis Code form.
Note: Any analysis dimensions that are initially not available for data entry (due to the defined rules
such as being prohibited by the account), become available for editing after you complete the current
journal line. However, if you subsequently enter any details in these fields, the system still applies the
same checks as before, and prohibits entry of any analysis not allowed under the defined rules.
Note: If you use an analysis dimension that has been defined as the transaction sequence dimension,
the code must be numeric.
3 Specify this information for Additional Line Details:

Value Date
For cash transactions, as defined by the Posting Journal Type field of Journal Types (JNT), only. The
date on, or past, which the transaction can be allocated.
Instalment Date
The instalment date for the transaction, if this posting is one of several instalments due. This is only
required if Instalment Checking is enabled on Ledger Setup (LES) and the instalment date is being
checked
Instalment Number
The instalment number for the transaction, if this posting is one of several instalments due. This is only
required if Instalment Checking is enabled on Ledger Setup (LES) and the instalment number is being
checked.
Allocation Marker
You can set the allocation marker for the journal during ledger entry by using this field. Forced journal
listings and documents will then be produced depending on the allocation marker setting. Once a
particular transaction has been printed, its allocation marker is incremented by one.
Memorandum Amount
You can enter a memorandum amount for this journal line. This may be a non-financial value associated
with the journal line, for example a quantity or headcount. You cannot enter a memo value if the
Non-Currency Value Post Rule in Business Unit Setup is set as 0-Undefined, or the Memo Post Rule
Override field in Journal Types (JNT) is set as 0-Undefined.
Note: If you enter a memorandum amount in Ledger Entry when Asset Quantity is in use, this could
affect the number of assets recorded on the Asset Register.
Standard Text
You can add standard text to this journal line, by selecting Action > Line > Standard Text.
Journal Notes
Identifies if there are any journal notes associated with this journal line. Select Action > Line > Notes to
create and assign journal notes to this journal.
Second Reference
You can enter a Second Reference for each journal line, if you are not using the Second Reference for
Voucher Numbering.
Note: If Second Reference is required, it must also have been previously included in the Ledger Entry
form using Form Designer (FRD).
Additional Fields
You can record additional information in each journal line, such as supplementary references or related
dates, providing these additional fields have been previously defined in Additional Fields Setup (AFS).
Note: Any additional fields required must also have been previously included in the Ledger Entry form
using Form Designer (FRD).
4 The following fields identify the payment related details for the journal transaction. Therefore, they are
only required if the transaction relates to a purchase or sales transaction, for example an invoice or credit
note. A set of payment terms can be used to determine many of these details. A payment terms code can
be entered manually for the transaction, or the customer or supplier payment terms is used. Specify this
information for Payment Terms:
Due Date
The date the transaction is due to be paid, or by which payment should have been received. If payment
terms apply, this date may be calculated automatically. Alternatively, you can enter the due date
manually.
If the Override Ageing/Discounts option is set for the journal type, the transaction date is copied to the
due date and this overrides any calculated or entered date. This is used to request an immediate payment.
Terms Code
The payment terms code to apply to the transaction. This can determine selected dates and discount
terms. If this is left blank, the payment terms code assigned to the supplier or customer is used.
Document Date 1-4

Four document dates can be held on each transaction. They can be printed on payment documents or
used by the Reporting facilities. These dates may be determined by the payment terms, or they can be
entered manually.
Prefix 1-4
The prefix and numbers associated with up to four associated documents.
Discount Date 1/Percentage

The first discount due date and percentage settlement discount available if payment is made by this
date. These details may be determined by the payment terms, or they can be entered manually.
discount date and overrides any calculated date.
Discount Date 2/Percentage

A second discount due date and percentage settlement discount available if payment is made by this
date. If the first discount due date is missed, these second discount details are considered. These details
may be determined by the payment terms or can be entered manually.
discount date and overrides any calculated date.
Late Payment Date/Percentage

If the payment terms are exceeded, you may want to charge interest on the late payment. You can identify
the late payment date and interest rate percent. These details can be calculated from the payment
terms, or entered manually.
Note: This information is held for information only on the transaction and is not used to automatically
calculate an interest charge.
Interest Date/Percentage
You may want to charge interest on the transaction amount in which case you can specify the interest
date and interest rate percent. These details can be calculated from the payment terms, or entered
manually.
Note: This information is held for information only on the transaction and is not used to automatically
calculate an interest charge.
5 Four currency values can be entered, or calculated automatically, for a transaction. The values to be
entered or calculated depend on the business unit setup and posting rules, any journal type or account
posting overrides, and any journal presets.
Fifth currency values cannot be entered, but a fifth currency code can be derived from the account or
the Business Unit Setup at the time the transaction is created. This will allow fifth currency values to be
calculated on an ad-hoc basis in reporting.
Note: At least one daily or period currency rate must have been defined for any currencies you reference
in the journal.
6 The following transaction currency details may be required in a multi-currency environment. Some of
the details may be preset by the journal preset. The Value 2 Currency Post Rule set in Business Unit
Setup determines whether these details must be entered manually, or are calculated automatically if
they are not entered.
Note: Transaction currency values cannot be entered if Value 2 Other Currency Post Rule in Business
Unit Setup is set as Undefined, or Transaction Post Rule Override for this value in Journal Type (JNT)
is set as Unused.
Specify this information for Transaction Currency:
Transaction Currency Code
The currency code for the transaction currency. This code may be provided by a journal preset, or default
to the currency code set for the account.
Transaction Currency Rate

The currency rate used to convert the value in this currency into the pivot currency. The rate may be
provided by a journal preset. Otherwise, it defaults to the rate set in Currency Daily Rates (CND) or
Currency Period Rates (CNP).
You can enter a different rate for this journal transaction, overriding the default rate. This new rate must
be within the tolerance set.
Transaction Currency Amount

The transaction amount, expressed in the transaction currency. This value can be entered manually. If
the Calculated if not entered option is chosen as the Other Currency Post Rule in Business Unit
Setup, this amount is calculated from one of the other transaction values.
Debit/Credit
This determines whether the amount is a debit or a credit. Alternatively, you can select a balancing
option to automatically set the Amount and Debit/Credit marker to values that balances the journal,
transaction or period.
7 The following base currency details are mandatory. Some of the details may be preset by the journal
preset. The Base Currency Post Rule set in Business Unit Setup determines whether these details must
be entered manually, or are calculated automatically if they are not entered.
Specify this information for Base Currency:
Base Currency Code
The base currency code is displayed automatically. It is defined in Business Unit Setup and cannot be
changed.
Base Currency Rate

The currency exchange rate used to convert the base currency to the pivot currency. The rate may be
provided by a journal preset. Otherwise, it defaults to the rate set in Currency Daily Rates (CND) or
Currency Period Rates (CNP).
You cannot amend the number of decimal places for the rate.
Base Currency Amount

The amount of the transaction expressed in the base currency. This amount is mandatory. It can be
entered manually, or may be calculated automatically depending on the posting rules.
8 The following currency details reflect either the second base currency or reporting currency for the
transaction, depending on the choice made in Business Unit Setup.
Note: Second Base/Reporting currency values cannot be entered and will not be auto-calculated if:
• Business Unit Setup - Value 3 Currency Post Rule is set as Undefined.
• Journal Type - Base 2 / Rep Post Rule Override is set as Unused.
• Chart of Accounts - Report Conversion Control within the Currency tab is set to No
Specify this information for Second Base/Reporting Currency Code:
Second Base/Reporting Currency Code
The second base or reporting currency code is displayed automatically. It is defined in Business Unit
Setup and cannot be changed.
Second Base/Reporting Currency Rate

The currency exchange rate used to convert the currency to the pivot currency. The rate may be provided
by a journal preset. Otherwise, it defaults to the rate set in Currency Daily Rates (CND) or Currency
Period Rates (CNP).
You cannot amend the number of decimal places for the rate.
Second Base/Reporting Currency Amount

The transaction amount, expressed in the second base or reporting currency, is calculated and displayed
automatically if this currency is in use. You can only enter a reporting currency value, if the Base 2 / Rep
Post Rule Override option is set in Journal Type Setup (Posting Overrides) (JDX). You cannot ever
enter a second base currency value. The following details are only required if the journal transaction
relates to a fixed asset. For example, if an asset has been purchased or sold. These details may be held
on a separate tab.
9 The following fourth currency details may be required if fourth currency has been defined in Business
Unit Setup. Like the transaction currency, the fourth currency can be defined in Business Unit Setup as
Calculated if Not Entered or Only Present if Entered.
Note: Transaction values cannot be entered for the fourth currency if the 4th Currency Posting Rule is
set to Undefined on Business Unit Setup, or within a Journal Type Posting Override for a particular
journal.
Specify this information for Fourth Currency:
Fourth Currency Code
The currency code for fourth currency. This code can be fixed within Business Unit Setup, provided by
a journal preset, or defaulted to the currency code set for the account.
Fourth Currency Rate

The currency rate used to convert the value in the 4th Currency Calculate From field within Business
Unit Setup, to the fourth currency. The rate may be provided by a journal preset. Otherwise, it defaults
to the rate set in Currency Daily Rates (CND) or Currency Period Rates (CNP). You can enter a different
rate for this journal transaction, overriding the default rate. This new rate must be within the tolerance
set.
Fourth Currency Amount

This value can be entered manually. If the Calculated if not entered option is selected as the Other
Currency Post Rule within Business Unit Setup, this value is calculated from the Value defined in the
4th Currency Calculate From field within Business Unit Setup.
10 The following details are only required if the journal transaction relates to a fixed asset. For example, if
an asset has been purchased or sold. These details may be held on a separate tab.
Specify this information for Asset Details:
Asset Code
The asset code created in Asset Records (FAS). You cannot post transactions to an asset with a status
of Disposal. You are warned if you try to post to an asset after the depreciation end period.
Asset Sub Code

A valid subcode for the asset. This is used to determine the analysis code requirements for the transaction,
if any. Asset subcodes are defined using Asset Posting Presets Setup which is accessed from Asset
Records (FAS).
Asset Indicator
Select Initial if the posting is for a new asset, or if you are migrating assets into SunSystems from
another asset register. Otherwise, use Asset Indicator to determine whether this posting updates the
gross value on the asset record, or the accumulated depreciation.
Note: It is not normally recommended to enter depreciation amounts in Ledger Entry, except under
the circumstances described in 'Manually Posting a Depreciation Amount'.
Asset Quantity
You can enter multiple units as a single asset when making fixed asset postings, for example, when
purchasing 100 chairs but recording these as a single asset. Use Memorandum Amount in Ledger Entry
(LEN) to record the number of units.
Note: To record asset quantities in Ledger Entry (LEN), the following configuration must previously
have been defined:
• the Use Asset Quantity option on theGeneral tab in Ledger Setup (LES) must be checked
• the Non-Currency Value Post Rule on the Memo Value tab of Business Unit Setup must not be
set to 0-Undefined
• the Memo Post Rule Override field in Journal Types Setup (Posting Overrides) (JDX) must not
be set to 0-Undefined.
11 Save your changes.
Entering Journal Notes

Journal Notes allow you to add free format text to journal lines, to record any information considered
pertinent but unable to be recorded elsewhere in the system. They can be added, amended, and deleted via
the Journal Notes form which is accessed from the Action menu in:
• Ledger Entry (LEN), by selecting Line > Notes.
• Account Allocations (ACA), by selecting Notes.
• Account Inquiry (ACQ)[Control Desks In-Tray], by selecting Notes.
Up to 99 notes can be added to each journal line.
Journal Notes can be included on reports and statements.
Journal Notes
Journal Line Number
The journal line number to which the note is associated.
Line Number
The line number of the note.
Created By
The operator Id of the person who created the note.
Updated By
The operator Id of the person who last updated the note.
Internal Only
Used to signify if the note is for internal use only. This value can be used in the design of reports to determine
if note text should appear.
Exclusive
Indicates if the note text is exclusive to an individual journal line, or if it applies to all lines.
Note: If a number of journal lines are selected in Account Inquiry, and the notes function is accessed, any
notes added are automatically added against all the lines selected. If one of these journal lines is then
accessed, through whatever means, and a note is amended or deleted, the change is reflected for all the
journal lines, that is, there is only one journal note.
Creation Date
The date when the original note was created.
Updated Date
The date when the note was last updated.
Note Text
Free format note text.
Entering Multi-Currency Journals

A ledger transaction can contain up to four currency values: base currency, transaction currency, second base
/ reporting currency, and fourth currency. Business Unit Setup determines the currencies and posting rules
that apply in your organisation. It also identifies the pivot currency which is the currency via which the base,
transaction and second base/reporting currency values are calculated.
Note: The fourth currency can be calculated from any of the other available currencies, as defined in Business
Unit Setup, and cannot be used as the pivot.
The Business Unit Setup is used in conjunction with a journal type definition to govern the information
required for a multi-currency transaction. You can override your business unit currency posting rules for a
particular journal type using Journal Types (JNT)..
Ledger Entry (LEN) displays, at most, the following currency rate and amount fields (depending on the form
design and posting rules):
• Transaction currency code, rate from pivot, and amount.
• Base currency code, rate from pivot, and amount.
• Second base or reporting currency code, rate from pivot, and amount.
• Fourth currency code, rate from the value from which it is calculated, and amount.
Note: It may also display the memorandum amount
Note: Values in the fifth currency are only ever calculated when required. They are not calculated in Ledger
Entry.
Some of the currency codes and rates required may be preset, if a journal preset applies to the journal type.
Entering the Currency Codes

The base currency code and second base or reporting currency code are fixed for the business unit. Therefore
these codes appear automatically and cannot be changed. The fourth currency code may be fixed for the
business unit, if this has been specified within Business Unit Setup.
Note: For this reason these codes may not even appear on the form.
The transaction currency can vary for each transaction, if an amount can be entered. This code must be
entered. It may be provided by a journal preset. You may, or may not, be able to override the preset code,
depending on whether the presets are enforced. For example, a particular journal type may only be used for
invoices received in Euros and the journal preset defaults the transaction currency to EUR.
The fourth currency can also vary for each transaction and the same rules apply.
A default currency code can also be set for an account, or asset, or it may be derived by Business Rules. This
default code overrides any preset currency code.
Entering the Currency Rates

The currency rates are picked up either from the Currency Period Rates (CNP) or from the Currency Daily
Rates (CND), depending on the Use Daily Conversion Rate setting for the currency in Currency Codes (CNC).
In some cases, the rate may be preset in Journal Presets (JNP). However, if a currency rate is not specified,
the rate from Currency Rate Type defined in Journal Type (JNT) is used. If no Currency Rate Type has been
setup the Default rate type is used. Subsequently if a rate tolerance check is required then the rate type in
Journal Type (JNT) is also used.
Note: At least one daily or period currency rate must have been defined for the currency before you can enter
a transaction in that currency.
If all four currency values are required on a transaction, four rates are entered or displayed. The rate for the
pivot currency is always 1.0. The other rates (values 1, 2, and 3) are the rates required to convert from the
pivot currency into the relevant currency. For example, if the pivot currency is the base currency (GBP) and a
transaction currency of EUR is entered, the GBP to EUR rate is used as the transaction currency conversion
rate.
The fourth currency rate is the rate from the value from which the fourth currency is calculated, as defined
in Business Unit Setup, to the fourth currency itself.
Note: You may want to edit the Ledger Entry forms to suppress the display of the pivot's rate.
Daily or Period Rates

Currency Daily Rates are used if in Currency Codes (CNC) the Use Daily Conversion Rates field is set to Yes,
for either of the selected currencies. If a daily rate has not been defined for the transaction date entered in
the transaction line, or within the days tolerance limit, you cannot enter the currency details.
If daily rates are not in use, then the appropriate period rate from the Currency Period Rates (CNP) record
is used. Several currency period rates may be defined for a currency code. For example, different rates may
apply to particular account ranges and periods, for a single currency code. The system selects the appropriate
conversion rate to apply.
If a rate is not found, Ledger Entry rejects the currency code.
Spot Rates
You can enter a spot rate for a transaction, which is different to the rate held in either Currency Period Rates
(CNP) or Currency Daily Rates (CND). If you enter a spot rate and tolerance checking applies, the rate you
enter is checked to ensure it is within the tolerance set for the original period or daily rate. The difference
between the rate you enter and the predefined conversion rate must be within the tolerance percent. This
prevents you from entering a widely inaccurate rate by mistake.
Note: If you always use spot rates, you may want to define a default period rate with a rate of zero and no
tolerance.
Entering the Currency Amounts

You must provide at least one amount for a transaction. This amount is used, with the currency rates, to
calculate the other transaction amounts. If this amount is not entered in the pivot currency, it is always
converted to the pivot currency first (because the first three currencies are converted via the pivot).
You would normally accept the calculated values. If you amend a calculated value, the conversion rate may
be recalculated accordingly.
Adjusting the Calculated Values

If you enter two values and a rate which do not correspond to each other, the system requests you to change
one of these entries. For example, if you entered a base value of 100.00, a transaction value of 150.00 and a
rate of 2.0, you must alter the rate or one of the two values.
If the calculated rate and values are not those you want to use on the transaction, you should amend the rate
or value to the one you want to see in use. You should also blank out the other value. The system then
recalculates the correct value using the rate provided.
Allocating transactions during Ledger Entry

As you enter a journal using Ledger Entry you can choose to match the unposted journal transactions against
other posted transactions on the same account.
What is Online Allocation?

Online Allocation provides a quick and efficient way of matching transactions as part of the Ledger Entry
(LEN) process. It is particularly useful for entering cash receipts and payments that need to be matched to
existing transactions on your debtor/receivables, creditor/payables, and client accounts. You can, however,
use online allocation to match transactions on all account types.
During the allocation process, you can generate settlement discount transactions, and tax on settlement
discount transactions. You can also generate realized gains/losses adjustment journals to take account of
any differences caused by exchange rate fluctuations.
Note: You can separate the ledger entry and allocation procedures by recording journals in Ledger Entry,
and allocating them later using one of the allocation functions such as Account Allocations (ACA).
The Online Allocation form is very similar to the equivalent form in Account Allocations (ACA).
It provides many of the same allocation processing functions as Account Allocations. These are summarized
below and described in more detail in the linked sections.
Full and Partial Matching

You can match the full amount of a transaction. By default, the journal transactions you are entering and
allocating are marked for full matching.
Alternatively, you can match only part of the transaction value by splitting the transaction.
To help you match transactions, you can sort the transactions by many of the transaction details including
transaction date, period, transaction reference, due date, base amount, transaction amount, allocation
marker, and currency code.
Multi-Currency Matching
You can match transactions in the base currency, the transaction currency, or the fourth currency amount.
At any time, you can display the total debits, total credits, and the total out of balance amounts in any of the
currencies.
Online Allocation automatically calculates any unrealized exchange gains and losses, and generates
transactions to post this to the appropriate gain or loss accounts.
Generating Settlement Discount

If the allocated transactions for debtor, creditor or client accounts do not initially appear to balance in the
base currency, SunSystems checks if any discount applies. Online Allocation calculates the discount due
using the discount terms on the transaction. It checks the matching imbalance against the calculated discount,
and also applies a discount tolerance.
If discount is allowed, the system can post the discount amount to the appropriate discount account, and
calculate and post any tax included in the discount amount.
Amending Transaction Details

You can amend some of the non-monetary details on other transactions for the account.
For example, you can alter the transaction description, entry date and due date. You can also set the allocation
marker on transactions, for example to force or withhold payment of a transaction, or to identify correction
transactions.
Accessing Online Allocation from Ledger Entry

To allocate a journal transaction online in Ledger Entry, select Action > Online Allocation to display the
Online Allocation form.
This online allocation form can be displayed automatically by setting the Automatic Online Allocation option
on a journal line in Journal Presets (JNP). This setting displays the form automatically after the preset line
is entered on Ledger Entry.
You can choose to allocate each line of a journal after you have entered it. Alternatively, if you have a number
of entries for the same account in the journal, you can enter all of these transactions and then activate online
allocation on the last entry for the account.
Allocating Transactions During Ledger Entry

As you enter a journal using Ledger Entry you can choose to match the unposted journal transactions against
other posted transactions on the same account.
When you select online allocation from Ledger Entry (LEN), the Online Allocation form is displayed. This
window displays two groups of transactions for the account referenced on the current journal line in Ledger
Entry. The two groups of transactions appear in different parts of the form:
• The current, unposted journal line you have entered for the account in Ledger Entry appears in the
Journal Transactions section at the top of the form and is automatically marked for allocation.
Note: If you have entered other transactions for the same account in the journal, these are also extracted
for allocation.
• All unallocated transactions posted to the account are extracted for possible matching and listed in the
Extracted Transactions section at the bottom of the form.
Moving Between the Two Transaction Grids

When you first access the form, the Extracted Transactions section of the form is active to enable you to begin
marking transactions for allocation.
You can switch between the two sections of the window by clicking in the relevant area, or from the Action
menu by selecting Switch Grid Focus. For example, you may need to switch to the Journal Transactions
section to split a transaction or reset the allocation marker.
Allocating the Transactions

The journal transactions entered using Ledger Entry are automatically marked To Be Allocated.
In the Extracted Transactions section you must identify the transactions you want to allocate against these
journal transactions and set the allocation marker on these transactions accordingly. All of the matching
options are available, for example:
• To fully allocate a posted transaction in the Extracted Transactions section you would set the marker to
To Be Allocated.
• To allocate only part of the transaction you can assign an Allocation Marker of Split, enter the amount
to be allocated and create another transaction for the remaining, unallocated amount.
Balancing the Allocations

The transactions marked for allocation must balance before the allocations can be saved.
The total debit and credit amounts marked for allocation and any difference between them is displayed at
the top of the form in a particular currency. You can vary this currency using Action > Currency Totals.
Alternatively, you can view the allocation totals in all of the currencies by choosing the Allocation Totals
action.
Additional journal transactions may be generated to balance the allocations:
• Settlement discount transactions and any associated tax adjustment transactions.
• Exchange gain or loss adjustment transactions.
Saving the Allocations

When you have completed the online allocations and they balance, you must save them to return to Ledger
Entry. The save option you select determines the currency that is used to check that allocations balance
correctly.
To save the allocations, from the Action menu select Save and select the appropriate Save By currency
option:
• Select Save By Base to save the allocations balancing by the base currency. Using this option, any currency
exchange differences are calculated on the transaction currency amount, and on the Value 4 amount if
you are using fourth currency.
• Select Save By Transaction to save the allocations balancing by the transaction currency. Using this
option, any currency exchange differences are calculated on the base amount, and on the Value 4 amount
if you are using fourth currency.
• Select Save By Fourth Currency to save the allocations balancing by the fourth currency. Using this
option, any currency exchange differences are calculated on the base amount and on the transaction
currency amount.
Holding a Journal with Online Allocations

If a journal that contains online allocations is not posted immediately but is placed on hold, the allocations
are also held. Because these unposted journal transactions have been allocated against existing posted
transactions, it is important that no other allocations are made against these transactions until the held
journal is posted or deleted.
To ensure this, the status of each transaction with held allocations is set to Allocation in Progress. This
status is reset when the held journal is posted. If the held journal is cancelled, the allocations are also cancelled
and the status reset.
Note: In some exceptional circumstances this status may not be reset correctly, for example as a result of
computer failure. In this case a user with the appropriate data access group authorization can use the Clear
Allocation in Progress option from the Action menu to reset this status for a transaction.
Enabling the Clear Allocation in Progress action

When a transaction is matched using any of the matching facilities, the Allocation in Progress status is set
on the transaction to prevent it being selected for matching by any other user in another session. When the
matching is posted, the status is changed to Matched.
However, if the transactions are placed on hold the Allocation in Progress status remains on the transactions
until the allocations are completed or cancelled.
A transaction can be placed on hold with outstanding allocations in two ways:
• if the allocations were made using the Online Allocation facility and the journal was placed on hold.
• if a multi-part split allocation could not be completed and is suspended.
In some exceptional circumstances the Allocation in Progress status may not be reset correctly, for example
as a result of computer failure. In this case a user with the appropriate data access group authorization can
use the Clear Allocation in Progress action to reset this status for a transaction.
These steps are required to allow an authorized user the right to reset the Allocation in Progress status.
This permission should only be granted to the system administrator to ensure it is not used indiscriminately.
1 From SunSystems, select Form Designer (FRD).
2 Check out and open the form Account Allocation (SAOA1).
3 Select View > Form Actions to list the actions available on the form.
4 In the Specified Operator Groups box, click the Operator Group to be granted permission.
5 In the Available Actions box select Override Locked Acc/Trans and click Enable.
6 Save, close and check in the form.
Contrasting Account Allocation and Online Allocation

Allocating transactions using Online Allocation as part of the Ledger Entry process is very similar to Account
Allocations (ACA). Account Allocations is used to allocate transactions after they have been posted.
When you use Online Allocation you match transactions using the Online Allocation form. Whereas, when
you use Account Allocations you match transactions using the Account Allocation form.
The main differences when you are using Online Allocation are:
• the unallocated transactions are extracted automatically for the account referenced on the journal line,
so the Selection Criteria for Account Allocation form is not required to select the transactions
• the allocations are made on the Online Allocation form instead of the Account Allocation form.
The Online Allocation Form

The most obvious difference between the two functions is that with Online Allocation the current journal
transaction you have entered in Ledger Entry is automatically selected for allocation.
Note: If you have entered several transactions in the journal for the same account they are all selected for
allocation.
These unposted journal transactions appear at the top of the Online Allocation form in the Journal
Transactions section. The allocation marker on these transaction is set automatically to To Be Allocated. If
you were to use Account Allocations to match these transactions you would have to select these transactions
on the Account Allocation form and set the allocation marker manually.
All of the posted, unallocated transactions for the account are also extracted automatically and listed in the
Extracted Transactions section at the bottom of the form. These transactions are displayed in order of the
Transaction Sequence that you define for the journal type in the Online Allocation tab in Journal Type
(JNT).
You must select the matching, posted transactions in the Extracted Transactions section and then set the
allocation markers. If the allocations do not balance, the online allocation function checks to see whether
discount has been taken and can generate the appropriate discount transactions, if required. It also generates
exchange gain or loss adjustments, if necessary.
When you have finished allocating the transactions and they balance, you must select the Save option, rather
than the Post option you select in Account Allocations (ACA).
This is because the allocations and generated transactions are only posted when the journal is posted using
Ledger Entry (LEN). If the journal is not posted for any reason, for example if it is held or cancelled, the
allocations are not made.
Reviewing and amending a journal

There may be times when you need to review all of the journal lines that you have entered for a journal.
Use Ledger Entry (LEN) to review and amend a journal.
Adding New Journal Lines

Ledger Entry (LEN) includes a number of functions that allow you to begin entering a new transaction line
for a journal and each is used in slightly different circumstances.
• You must always click OK, or press Enter, when you have finished entering the details for a transaction.
This validates the transaction and, if all of the mandatory details have been entered and are correct, it
adds the transaction to the journal and updates the journal totals.
If journal presets apply and the Create Without Pause option is set, Ledger Entry automatically clears
the input fields to allow you to enter the next journal transaction. It automatically displays the preset
values for this new line. This continues until you have entered all of the preset lines for the journal. At
this stage you must use one of the other options to add another line, post or hold the journal.
• Click New Line to enter another transaction, with the current journal transaction reference. It clears the
current transaction fields to allow you to enter a new transaction. The cursor is positioned on the first
field without a preset value.
You must use this option, after clicking OK, to enter a new line, unless the Create Without Pause option
applies to the journal preset.
• Click New Reference to enter a new transaction for a new journal transaction reference, within the same
journal type. For example, to enter the next cash receipt in the batch. If journal presets apply to the
journal type, the presets are repeated for the new reference
The cursor is positioned on the Transaction Reference field to allow you to enter all of the details for
this transaction.
• Click New Journal Type to enter an entirely new type of journal. You cannot select this option unless
you have just successfully posted or held any previous journal you entered.
The cursor is positioned at the very top of the form to allow you to select a new journal type. You can
select any valid type, regardless of the style of form it requires. If a different Ledger Entry form is required,
it appears automatically.
Do I Click OK or New Line?

After you have entered a journal line, you must click OK to validate the journal line details and to add the line
to the journal.
If you want to use the same transaction reference when starting a new line in the current journal, then you
must click New Line.
Alternatively, click New Reference to use a new transaction reference.
If journal presets apply and the Create Without Pause option has been set, you must still click OK after each
preset line, but do not need to click New Line. When you click OK the next preset line appears automatically,
providing the details are correct.
However, once you have entered all of the preset lines, the normal entry rules apply within the current
transaction reference. That is, if you want to add another line with the same transaction reference you must
click New Line. If you want to enter lines for a new transaction reference, click New Reference and the preset
lines appear once again.
Checking the Account Balances

As you enter a journal transaction you can use the Account Balances Check facility to see the effect the
journal line has on the account you have entered on the current line. It displays the current (opening) balance
of the account and the closing balance that would result from posting the current transaction. It also includes
any previous transactions for the same account in the journal.
You can view the account balance in either the base currency or the second base or reporting currency, if this
is being used.
To display the account balance details in Ledger Entry, select Action > Balances > Account Balance Check
and the appropriate command, depending on the currency you want to view.
This produces a display window with this information:
Opening Balance
The current account balance. It does not include unposted transactions.
Transaction Credits
The total of all credits entered in this journal for this account, up to and including the current line. It ignores
lines that have been deleted, or are unused.
Transaction Debits
The total of all debits entered in this journal for this account, up to and including the current line. This ignores
any lines that have been deleted, or are unused.
Closing Balance
The total of the three previous values and is the account balance that would result from posting the journal.
Checking the Journal Totals and Balances

Ledger Entry (LEN) calculates the following journal totals as you enter journal lines:
• Journal totals
the total debit and credit values for all transactions in the journal, regardless of accounting period,
excluding memo values
• Reference totals
the total debit and credit values of the transactions for each journal reference, regardless of accounting
period
In a multi-currency environment it calculates these totals in each of the currencies in use within your business
unit: base currency, transaction currency, reporting/second base currency, and fourth currency.
The journal totals appear on the Ledger Entry form, usually in the top right corner. They are displayed in the
base currency by default. You can use the menu commands or toolbar buttons to display these totals in one
of the other currencies, and to display the totals for the current journal reference rather than the journal as
a whole.
A journal can contain transactions that post to different accounting periods. The transactions for each
accounting period must balance before the journal can be posted. Therefore, Ledger Entry also calculates
the journal transaction totals by accounting period, in the base currency only. These period balances can
also be displayed at any time.
Viewing the Currency Totals

To display the Ledger Entry form totals in a different currency, select Action > Totals > Currency Totals and
one of the following commands:
• Base Currency
• Transaction Currency
• Report/Second Base
• Fourth currency.
The total debit and credit amounts are displayed in the appropriate currency. If the totals are not equal, the
Out of Balance by amount is also displayed.
Note: The business unit balancing rules control determine whether the non-base currencies must balance.
Viewing the Journal Totals

To display the debit and credit totals for the journal as a whole, select Action > Totals > Journal Totals. The
totals and out of balance amount appear in the totals area at the top of the form. This is the default option.
Note: The journal totals are displayed in the currency selected from Action > Totals > Currency Totals.
Viewing the Current Journal Reference Totals

A journal can contain transactions with different journal reference numbers. The balancing rules may force
these transactions to balance for each reference before the journal can be posted.
To display the debit and credit totals for the current journal reference, select Action > Totals > Reference
Totals. The totals and out of balance amount appear in the totals area at the top of the form.
Note: The journal reference totals are displayed in the currency selected from Action > Totals > Currency
Totals.
Viewing All Journal Reference Totals

To display the debit and credit totals for all of the journal references in the journal, select Action > Balances
> Transaction Balances. The totals and out of balance amounts, by reference, appear in a separate dialog.
Note: The journal reference totals are displayed in the currency selected from Action > Totals > Currency
Totals.
Viewing the Period Balances

A journal can contain transactions posting to different accounting periods. The journal can only be posted if
the transactions for each period are in balance.
To display the debit and credit totals for each accounting period, select Action > Balances > Period Balances.
The totals and out of balance amounts, by period, appear in a separate dialog.
Balancing the Journal

A journal can only be posted if it is in balance. If you try to post a journal and it is out of balance, Ledger Entry
(LEN) displays an error message.
Note: If the Automatic option was selected for Base Currency Amount Balancing in Business Unit Setup,
Ledger Entry forces the journal to balance by posting the balancing amount automatically to one of the
balancing accounts selected for the business unit.
You may need to balance the transactions:
• within the journal as a whole.
• for an accounting period.
• for each transaction reference, journal type, transaction date, or any of the ten transaction analysis
dimensions, depending on the Balance By option in Ledger Setup (LES).
In a multi-currency environment, you may also need to balance the transaction currency amounts, if any of
the other transaction currency balancing options are set to Manual in Business Unit Setup.
If you are unsure of which part of the journal is out-of-balance, you can use the Totals and Balances options
on the Action menu to help you.
Once you have identified the amount of imbalance, you should try to identify the reason for this and amend
the journal to correct the problem. You may need to:
• amend the amount on a journal line. If you amend one currency value, the remaining values are
recalculated automatically.
• amend the accounting period, date, journal reference, or analysis codes on selected journal lines,
depending on the Balance By selection.
• enter additional journal lines.
• remove incorrect journal lines.
If you are unable to balance the journal, you should place it on hold while you investigate the problem further.
Note: SunSystems includes a Balance Override function that can be used as a last resort. This function is
not available from any of the forms delivered with SunSystems and must be added to a form via Form Designer
prior to use. It must be used with appropriate caution and access restrictions.
Reviewing Journal Lines

There may be times when you need to review all of the journal lines that you have entered for a journal.
Reviewing the Journal Lines in a Grid Form

If the Ledger Entry form you are using includes a grid, this contains all of the ledger transactions. You can
scroll up and down the grid to view the transactions, or scroll across the grid to display the transaction details.
Depending on the design of the form you may be able to:
• amend any of the details for a journal line by updating the information directly in the grid.
• click on a line in the grid to display the journal line details in separate fields on the form where they can
be amended.
Reviewing the Journal Lines By Reference

If the Ledger Entry form you are using displays only one journal line, and you want to display all of the journal
lines by transaction reference, select Action > View.
The transactions are displayed in a separate, View Transactions, dialog. All of the journal lines entered for
the current transaction reference are listed. You can use the First, Previous, Next and Last buttons, or
corresponding navigation buttons, to view the journal lines for any other transaction references in the current
journal.
The balancing details for the journal as a whole are displayed at the top of the dialog.
Click Close to close this dialog and return to Ledger Entry (LEN).
Selecting Journal Lines

You can use the normal navigation buttons and options to select and view different journal lines. These
options are also included on the menu and are summarized below:
Menu Command Toolbar Button Displays

First the first journal line.
Previous the previous journal line.
Next the next journal line.

Last the last journal line.
Selecting a Transaction Reference

A journal can contain transactions for one or more transaction references. If you have more than one reference
in a journal, you can select a particular reference from the Action > Options > Go To commands. These are
listed below:
Menu Command Displays

First Reference the first journal line, for the first transaction refer-
ence.
Previous Reference the first journal line, for the previous transaction
reference.
Next Reference the first journal line with the next transaction refer-
ence.
Last Reference the first journal line with the last transaction refer-
ence.
Amending Journal Lines

You can use Ledger Entry (LEN) to amend any of the details for a journal line before it is posted. You can
amend the details while you are initially entering the journal. Or you can place the journal on hold and return
to the journal and amend selected details at a later time.
If the journal you want to amend was placed on hold, or posted as provisional, you must first retrieve the
journal by selecting View Held Journals or Recall Provisional option from the Action menu. You can also
retrieve provisional transactions using Recall Provisional Journals (PRJ).
Once a journal has been posted to the ledger, you can only amend some of the journal details. This is to ensure
the integrity of the ledger is maintained.
Amending a Journal Line Prior to Posting

Note: These steps cannot be used to amend the Transaction Reference.
Journal lines are amended using Ledger Entry (LEN) as part of the journal entry process.
To amend any journal line details:
1 Access the journal line you want to amend. Select Action > Line > Go to to page through the journal lines,
or click on the journal line in the grid, if its available.
Alternatively, select Action > Line > Amend to select a specific journal reference and line number. In the
pop-up dialog, enter the transaction reference and line number of the journal transaction you want to
amend and click OK. Then confirm your choice to display the journal line details in the input fields.
If you cannot access these Action menu options, it is probably because the form is still in journal input
mode. You should click Cancel.
2 Click in the field you want to amend and enter the new or revised details.
3 Click OK to save the revised journal line details and update the totals accordingly, if necessary.
Amending a Journal Transaction Reference

The journal transaction reference is the only journal field you cannot alter from the Action menu by selecting
Line > Amend. This is because the reference is used to identify the journal and it must be updated on more
than one journal line. A specific Ledger Entry function is provided to allow you to amend this.
To alter the journal reference:
1 Select Action > Options > Amend Reference to display a selection dialog.
2 If necessary, enter the reference in the Existing Transaction Reference field.
3 Enter the new reference in the New Transaction Reference field.
4 Click OK.
Deleting Journal Lines

You can delete journal lines using Ledger Entry (LEN) at any time before the journal is posted. Once a journal
has been posted to the ledger, you cannot delete any journal lines. This is to ensure the integrity of the ledger
is maintained.
Note: If you want to remove an entire, unposted, journal you should cancel the journal.
To delete a journal line:
If you haven't clicked OK to add the journal line to the journal, click Cancel.
If you have added the journal line to the journal:
1 Select Action > Line > Delete to display a selection dialog.
2 Enter thetransaction reference and line number of the journal transaction you want to delete and click
OK.
3 Then confirm your choice to delete the journal line.
Note: The journal line you have deleted is marked as deleted and the line value is removed from the
journal totals. However, the journal line remains in the system until the journal is posted or removed.
For example, if you place the journal on hold and recall it at a later time, the deleted journal line still
appears on the journal input form with a comment on the line deleted alongside the line number.
Cancelling a Journal
You can only cancel, or remove, unposted journals.
If you wish to cancel a posted journal you should enter another journal to reverse out the original and set the
allocation marker on all of the journal transactions to Correction.
If you want to remove a journal that you have entered, but not posted, in Ledger Entry (LEN), select Action
> Cancel Journal. You are asked to confirm that you do want to cancel the journal. You can elect to place the
journal on hold.
If the unposted journal you want to remove has already been placed on hold, you can use the Clear Journal
action on Ledger Entry Held Journals (LEH).
Selecting a Transaction or Field

When you select any of the following options from the Action menu on Ledger Entry, a small dialog appears
asking you to enter additional information to identify the transaction or field you want to amend or delete.
• Options > Amend Presets
• Options > Amend Reference
• Line > Amend
• Line > Delete
• Recall Provisional.
Printing the Unposted Journal Details

You can use the Report command in Ledger Entry (LEN) to print the details of the current, unposted journal.
Note: The Journal Listing prints the details of a journal that has been posted to the ledger. This report can
be produced automatically by setting the Force Journal Listing option in Ledger Setup (LES).
Posting or holding a journal

The Post command posts valid journals to the financial ledger.
You can hold journals before posting them.
Posting a Journal
The Post command posts valid journals to the financial ledger. They are either posted as permanent postings
or provisional postings, depending on the Provisional Postings option in Ledger Setup (LES).
Note: If the Provisional Postings option is set to Optional, you can choose to post the journal transactions
as either permanent or provisional postings. Provisional postings must be made permanent at a later stage.
To post a journal using Ledger Entry (LEN), select Action > Post.
Ledger Entry checks that the journal meets all of the validation rules.
If the journal passes all of the validation, it is posted to the ledger. A journal number is assigned automatically
and appears briefly at the bottom of the form.
If a transaction sequence number and registration date are being assigned automatically, these are also
displayed alongside the journal number.
A journal listing can be produced automatically after any posting, or only after main or provisional ledger
postings, depending on the Force Journal Listing option chosen in Ledger Setup (LES).
Holding or Cancelling an Unposted Journal

If the journal does not pass the validation, the following message appears: Journal not posted, it will be
held?
You have three choices:

• Cancel - select this to return to Ledger Entry and correct the problem.
• No - select this to discard the journal details completely. Another message appears asking you to confirm
your choice to clear the journal.
• Yes - select this to hold the journal.
Correcting Errors
However careful you are, mistakes can be made when entering transactions.
The section 'Correcting Mistakes After Posting', outlines the amendments you can make to transactions which
have been posted.
Holding a Journal to Delay Posting

You can hold journals before posting them. There are many reasons why a journal might be held, for example:
• The journal does not balance, perhaps it is time for lunch or you need to investigate a problem with the
journal details
• You do not have the authority to post the journal and it must be approved by a supervisor operator.
Holding a Journal
To hold the current journal on Ledger Entry (LEN), select Action > Hold.
Alternatively a journal can be placed on hold by:
• The journal posting process, if the journal cannot be posted.
• The Ledger Import process.
• The multipart split transaction option in Account Allocation.
• The Authorization process, if the journal type requires authorization.
Printing Held Journals

Held journals are not included in general Financials reports. However, you can print the held journals using
the Held Journals Listing.
Authorizing Journals
If the Authorization Required flag has been set for a journal type, any journals entered or imported for this
journal type must go through the authorization process before they can be posted.
When journals with these journal types are entered using Ledger Entry or Ledger Import, they are
automatically placed on hold with an authorization status of Authorization Requested.
If you are entering the journal using Ledger Entry (LEN), the Authorization Batch Comment dialog appears
when you choose to Post the journal. This identifies the authorization set (batch) reference and allows you
to enter a comment or note for the authorizer. When you click on OK the journal is held automatically and
the transactions are sent for authorization.
These journals cannot be recalled in Ledger Entry, amended or posted, until they have been through the
authorization process.
If a journal is authorized it is posted automatically, providing it is still in balance.
If a journal is rejected during authorization it can be recalled using Ledger Entry and amended. In this case
it must pass through the authorization process again before it can be posted. Alternatively, it can be cleared
from the Ledger Hold tables.
Recalling a Held Journal

When you hold a journal it is placed on the held journal file. You can list the held journals and recall a selected
journal using Ledger Entry Held Journals (LEH), or the View Held Journals option in Ledger Entry (LEN).
A journal is only removed from the held journal file under the following circumstances:
• if the journal is recalled and posted.
• if the journal is recalled and deleted.
Note: You can also hold a transaction multipart split. These split transaction details appear as held journals
with a Journal Type of Split.
1 Access Ledger Entry Held Journals (LEH) directly from SunSystems. Alternatively, if you are currently
using Ledger Entry (LEN), from the Action menu select View Held Journals.
2 A list of the held journals appears. Each journal is identified by a Reference number that is displayed to
the left of the Journal Type. The No of Transactions field identifies the size of the journal. The Journal
Source identifies the person who entered the journal, that is the Operator Id.
3 Click on the journal you want to reselect for processing.
4 Select Action > Select Held Jnl to reselect the journal for processing. If the journal was held during
Ledger Entry, the journal details reappear in the Ledger Entry form and you can amend and post the
journal. Alternatively, if the journal is not required, you can choose to cancel it. If the Journal Type is
SPLIT, the journal was placed on hold by Account Allocations (ACA) and contains an incomplete multipart
transaction split. In this case, when you choose the Select Held Jnl option, the split transaction details
are redisplayed on the Manual Ledger Allocation Multipart Split form to allow you to complete the
transaction split.
5 Alternatively, select Action > Clear Journal from to remove the journal.
Correcting Mistakes After Posting

However careful you are, mistakes can be made when entering transactions. This section describes how you
can make corrections while maintaining a proper audit trail.
Supervisor Authorization
Until a journal is posted, all of the transaction details can be amended or deleted.
If you want to add a separate procedure to authorize journals when they are entered, you can use the journal
hold file to save journals until they are approved by another operator. You can retrieve held journals and,
once authorized, they can be posted. Held transactions are treated as unposted, and are therefore not included
in general reports.
Making Simple Amendments

Once a journal has been posted you can change the description, due date, and transaction analysis codes for
a posted transaction using Account Allocations (ACA), assuming you have the necessary permission.
In addition to correcting errors, amending analysis is particularly useful if, for example, you reorganise your
cost centre structure. The Amend in Account Allocation option in Analysis Dimensions (AND) allows you
to specify whether analysis codes can be amended after posting. You can control access to this facility via
operator groups, which are maintained using Security Console or User Manager.
You can also change allocation markers. You can set the allocation marker to:
• Allocated
• Reconciled
• Correction
• Force Payment
• Withhold Payment
• 0-9 for numeric allocations.
Transactions can be de-allocated subsequent to posting in Account Allocations. All changes made in Account
Allocations must be posted before they are written to the ledger.
Amending Critical Transaction Information

Account Allocations does not allow you to amend the transaction date, transaction reference, debit/credit
marker, and any of the transaction amount details. You can only change these critical details by entering
correction transactions.
This can be done by reversing the incorrect entry and then entering the correct transactions manually in
Ledger Entry (LEN).
To reverse the journal you can either enter the reverse journal manually or use Journal Reversal and Copy
(JRC).
Concealing Correction Transactions

Correction transactions can be identified as such by assigning them with a Correction allocation marker. You
can set this allocation marker using Account Allocations (ACA).
Note: You must set the Correction allocation marker on balancing transactions. This means that you must
set this marker on at least two transactions with values that net to zero.
Transactions which have a Correction marker can be excluded from financial reports. You can use the Report
Corrections option in Ledger Setup (LES) to specify whether correcting transactions are included or excluded
from reports.
Payment Voiding
Payment Voiding (PYV) enables you to cancel or remove payments made in Payment Run or Payment
Collection Run. You select the payment to cancel by identifying the payment reference, usually the cheque
reference.
If a payment reference has not been generated, a dummy reference can be generated in Payment Documents
to enable the transaction to be selected for reversal. You can choose to mark the original transactions that
were paid with a Withhold allocation marker or you can leave the allocation marker blank.
Understanding more about selected journal details

Various tools in Financials can help you to understand selected journal details.
Tools include the Transaction Reference, the automatic calculation of tax and Ledger Entry asset details.
What is the Transaction Reference?

The transaction reference identifies the accounting or business transaction, normally from the originating
document. For example, it might be the invoice number, credit note number, receipt number, folio number
and so on. This reference must be entered on every transaction.
The same transaction reference often applies to one or more lines of the journal. It must be entered on the
first line of a journal. On subsequent lines, the cursor normally skips this field to allow you to enter several
journal lines with the same reference.
A journal can contain journal lines with different references. If you want to enter a new reference within the
current journal, you should click New Reference to begin adding a new line with a new reference.
If the Unique References field in Journal Types (JNT) is selected, the system checks that the reference has
not previously been used for the account to which you are posting. This check is carried out on
debtor/receivables, creditor/payables and client accounts.
You can force a journal to balance for each transaction reference by selecting the Transaction Reference as
the Balance By option in Ledger Setup (LES). This ensures that all of the journal lines with the same transaction
reference balance before you can post the journal.
Which Analysis Codes are Required?

Each journal transaction can contain up to ten analysis codes. Some, or all, of these codes can be predetermined
for a transaction in a variety of ways, or they can be entered manually.
There is no limit to the number of analysis dimensions that can be created in SunSystems. Only analysis
dimensions that have been linked to the Ledger entity using Analysis Structure (ANS) can be referenced on
ledger transactions. In addition, only ten of these can be entered on any one journal transaction.
The Journal Types (JNT) identifies the analysis dimensions that apply to a particular type of journal, and
only these dimensions are prompted for during Ledger Entry (LEN). Journal Presets (JNP) can be used to
predefine default codes for any of these dimensions, for a type of journal.
Analysis requirements can also be defined for particular ledger accounts using Chart of Accounts (COA).
These analysis dimensions override those set for a journal type. As a result, you may be prompted to enter
certain analysis dimensions on one transaction line, and different ones on the next line depending on the
journal type and account code requirements.
Note: If you are using the Fixed Asset Register and entering an asset transaction, the analysis code requirements
are also determined by the asset subcode.
Entering Analysis Codes

If a code has not been preset, you can enter a valid analysis code for a dimension. The analysis codes are
created in Analysis Codes (ANC).
You cannot enter codes that have been flagged with Prohibit Posting in Analysis Codes.
If, in Analysis Dimensions (AND), the Validation Method is set to No Validation for a particular dimension,
then you can enter any code.
Sequence Numbering
Sequence numbers can be applied to transactions automatically and these are held in the Transactions
Dimension analysis dimension identified in Ledger Setup (LES). If transaction sequence codes have been
defined using Ledger Sequences (LEQ) and the Update Sequence field is set to Manual, you are prompted
to enter the sequence number. You must enter a number in the analysis dimension associated with sequence
numbers.
Calculating Tax Automatically

The Financials automatic tax calculation facility can identify the tax portion of a transaction and generate
the appropriate postings to the accounts identified in Tax Details (TXD). In addition, the tax amount can be
apportioned over two tax accounts and the appropriate postings for withholding tax can be identified and
generated.
Conditions for Automatic Tax Calculation

Before any automatic tax calculations are performed on a transaction line, the following conditions must
exist:
• The tax analysis dimension must be identified on Ledger Setup (LES) in the Tax Dimension field
• The tax analysis dimension should be identified as a mandatory analysis code on the appropriate journal
types using Journal Types (JNT)
• The Enable Automatic Tax option must have been set on Journal Types (JNT) for the journal type
• The analysis code for the tax analysis dimension must be entered on the journal line
• The analysis code entered must correspond to a tax details record that has input/output tax accounts
as defined on Tax Details (TXD).
Note: The automatic tax calculations are only performed when you are creating journals using Ledger Entry
(LEN) or Ledger Import (LIM). If you amend a transaction line which triggered the creation of tax journal
lines, the tax lines must be amended manually. That is they are not recalculated automatically. Additionally,
if you delete a journal line, you must manually delete the tax journal lines created from it.
Transactions generated in this way acquire the same journal line number, with a suffix, as the 'base' transaction,
i.e. the transaction line which triggered the tax calculations. Preset lines defined in Journal Presets (JNP)
are therefore not affected by the addition of new lines to the journal.
Linking Payment Terms to Journal Transactions

A journal transaction can contain a number of payment dates and details, for example payment due date,
two discount dates and discount percentages, and up to four document dates. Some, or all, of these payment
details can be determined by the payment terms referenced on the transaction. The payment terms code
you assigned to the appropriate customer or supplier is used by default, or you can enter a payment terms
code onto the transaction manually.
Payment terms are defined using Payment Terms (PYT) and identified by a payment terms code. They consist
of a payment header identifying the general payment terms, and a series of payment term details. Each
payment term detail determines the individual settlement terms that apply to a particular type of transaction
date. For example, one payment term detail might determine the due date which is when the invoice is due
for payment, and another might determine the first discount date and discount percent available the invoice
is paid earlier.
The payment terms that apply to a supplier or customer are referenced on Supplier (SUS) and Customers
(CUS). Each supplier is linked to a creditor/payables or client account, and each customer is linked to a
debtor/receivables or client account. This means that the payment terms are linked to a ledger account
indirectly, via the supplier or customer details.
So, if a journal transaction is entered for a debtor/receivables, creditor/payables or client account, the system
locates the appropriate supplier or customer details and obtains the payment terms. These payment term
rules are then used to calculate the default payment terms details. If payment terms have not been linked to
the customer or supplier, you can enter the payment terms code manually.
A payment terms group can also include a Scheduled Payments code. If it does, then when relevant
transactions are entered to debtor, creditor or client accounts, they are split into instalments with a schedule
of due dates. The specific terms of the schedule are defined using Scheduled Payment Setup (SCH). After
the transaction has been split into instalments, each individual instalment line generated is still subject to
the payment terms associated with calculating document dates, discount dates, and interest dates.
Note: The payment terms are ignored if the Override Ageing/Discounts option is set for the journal type.
This option sets the payment due date and discount dates to the current date to ensure the transaction is
selected for payment immediately.
Amending or Suspending Journal Presets

A journal preset can be assigned to a journal type to predetermine some or all of the journal line details for
a business transaction. A journal preset can predetermine a series of journal lines for a journal, inserting the
appropriate field values where necessary.
If journal presets have been defined, the journal details appear automatically in the appropriate fields on
Ledger Entry (LEN). The cursor skips valid preset fields. A prompt may appear for each field to indicate the
type of information you should enter.
Note: You can choose to prevent operators from changing the values entered by the preset. However, the
values are only forced when a journal is being created; they can be changed when a journal is being amended.
Amending a Preset Field Value

You can amend the preset value for an individual field providing the Force Presets option has not been set
for the journal line in Journal Presets (JNP).
Applying Different Journal Presets

Use the following steps to apply a different set of journal presets to the current journal.
Note: You can only apply a new set of presets on the first line of a journal, after you have entered the transaction
reference.
1 Select Action > Options > Amend Presets to display a selection dialog.
2 Select the appropriate Journal Preset code.
3 Click OK.
Ignoring the Journal Presets

Sometimes you may need to enter a journal without using the journal preset detail set for the journal type.
To do so, select Action > Options > Create Without Presets.
Ledger Entry Asset Details

The SunSystems Fixed Assets module uses Ledger Entry (LEN) to record asset transactions on the ledger;
including depreciation, revaluation, acquisition, and disposal transactions.
The asset code and asset subcode identify the asset to be updated by the transaction. You cannot post
transactions to an asset with a status of Disposal. You are also warned if you try to post to an asset after the
depreciation end period.
The asset indicator determines whether the Ledger Entry transaction amount updates the gross value, initial
value or accumulated depreciation value for the asset.
When a ledger transaction updates an asset, it also updates the last depreciated period, if applicable, and
the date of the last transaction for the asset.
If you are using asset quantities you can enter a quantity for this asset transaction in the Memo Amount.
You can preset the asset code, subcode or asset indicator using Journal Presets (JNP).
The asset code and subcode govern the analysis codes prompted for. An asset subcode is defined using asset
posting presets on Asset Records. Associated analysis codes are placed in the analysis fields.
Reversing and copying journals

Use Journal Reversal and Copy (JRC) to select one or more journals and repost them either as reversals, or
as duplicate copies, without having to re-enter any details in Ledger Entry (LEN).
You can also use this function to reverse payments or collections generated by Payment Run (PYR) or Payment
Collection Run (PYC) respectively.
Selecting Journals for Reversal and Copy

as duplicate copies, without having to re-enter any details in Ledger Entry (LEN). You can also use this function
to reverse payments or collections generated by Payment Run (PYR) or Payment Collection Run (PYC)
respectively.
You can reverse or copy more than one journal simultaneously, provided that all of the journals selected are
of the same journal type.
If you are copying a journal, you can duplicate the original information (except for certain fields that must be
automatically overwritten to retain an audit trail), and optionally modify certain items such as date, period,
and operator Id.
If you are reversing a journal, the original information is replicated, except that the credits are switched to
debits and vice versa. Certain other fields must be automatically overwritten to retain an audit trail. You can
optionally modify certain parts of the journal data such as date, period, and operator Id.
If you are reversing a payment or payment collection, then in addition to a journal reversal, this facility can
also reverse the allocation indicator assigned to the invoice or credit note transaction that was originally paid
by the source payment journal.
If you are reversing a withholding tax transaction and the calculation type is cumulative, the cumulative
amount and the cumulative tax is reduced accordingly.
The generated journal is given an identifier when it is posted to the ledger to classify it appropriately as a
journal reversal, journal copy, or payment reversal.
Fields that are Not Necessarily Duplicated in the Generated Journal

The automatically generated reversal lines are identical to the originating transaction lines in every respect
other than for the following:
• Debit and Credit markers (interchanged for journal reversals and for payment reversals)
• Transaction Date (optionally different)
• Period (optionally different)
• Entry Date (system date)

• Audit tracking information (Originated Date, Originated By, Modified Date (Before Posting), Modified By
(Before Posting), Modified Date (After Posting), Modified By (After Posting), Permanent Posting Date,
Permanently Posted By)
• Allocation Markers
• Allocation tracking information (Operator Id of allocating person, Allocation Reference, Allocation Period
and Allocation Date) still to be applied
• Journal and line numbers
• Voucher Number (if applicable).
Conditions for a Journal to be Eligible for Copying

For a journal or a group of journals to be eligible for copying, it must fulfil the following conditions:
• Each journal selected must balance
• All selected journals must have the same journal type
• The journal type must not be SYSTM, that is, a system generated journal
• The journal type must have a status of either Open or Hidden
• Journals must not be part of a saved set or an authorization batch.
Note: If you are copying or reversing a journal that has the Unique References option set in the Journal
Type (JNT), you must first switch off this option, that is, uncheck the Unique References check box for the
journal type.
Conditions for a Journal to be Eligible for Reversal

For a journal or a group of journals to be eligible for reversal, it must fulfil the following conditions:
• All selected journals must have the same journal type
• The journal type must not be SYSTM, that is, a system generated journal
• The journal type must have a status of either Open or Hidden
• None of the transaction lines in the journal must be allocated with balancing allocation indicators
(Allocated, Paid, or Correction)
Conditions for a Journal to be Eligible for Payment Reversal

For a journal or a group of journals to be eligible for payment reversal, it must fulfil the following conditions:
• All selected journals must have the journal type SYSTM, as Payment Run and Payment Collection Run both
generate system journals
• All journal lines posted to customer or supplier accounts must be allocated with the Paid allocation
indicator
• All journal lines posted to accounts other than customers and suppliers (such as bank) must not be
allocated with balancing allocation indicators (Allocated, Paid or Correction)
• All of the source invoice or credit note transaction lines that were originally paid by the source payment
journal (that is, by Payment Run or Payment Collection Run) must have the allocation indicator of Paid
Reversing or Copying a Journal

The following steps describe how to generate journal reversals or copies based on one or more journals
posted to the ledger:
1 Select Journal Reversal and Copy (JRC) from SunSystems.
2 The Selection - Journal Reversal & Copy form is displayed. Enter the appropriate criteria to select a
range of journals for review.
3 Click OK. The Financials - Journal Inquiry form is displayed with a grid of all the journal lines that meet
your criteria. Scroll up or down to find the journal you want to reverse or copy.
4 Select the lines pertaining to the journal you want to reverse or copy. To do this, highlight the relevant
lines by holding the Control key down on the keyboard whilst clicking the button to the left of each
required journal line. Alternatively, if it is a contiguous range of journal lines, you can click and drag the
mouse down the left side of all the required lines.
If you do not select all the lines of a journal, the other lines are automatically located and selected, in order
to reverse or copy the whole journal.
1 Click Review. The Control Desks In-Tray form is displayed, with a grid of the selected journal lines.
2 In the Report Process control, select one of the following as required:
• Journal Copy
• Journal Reversal
• Payment Reversal.
3 Click OK. The Journal Reversal and Copy form is displayed.
4 Complete the required fields and click Post.
If the posting is successful, the journal number is displayed in the status bar. If a batch of journals is
posted, the journal number displayed is the first successfully posted journal in the batch.
5 Click OK and Exit to finish the process.
Alternatively, if any errors are found, they are displayed in a grid. You can reselect the lines and continue
from step 6 above, modifying any details as necessary in the Journal Reversal and Copy form.
Entering the Journal Reversal and Copy details

as duplicate copies, without having to re-enter any details in Ledger Entry (LEN). You can also use this
function to reverse payments generated by Payment Run (PYR) or Payment Collection Run (PYC).
After selecting Journal Copy, Journal Reversal or Payment Reversal as the Report Process, the Journal
Reversal and Copy form is displayed. This Help topic describes the fields that you must complete before
posting the generated journal.
Journal Reversal and Copy Form

1 Specify this information:
Journal Type
Display only. The type of journal selected for copying or reversal.
Journal Number From and To

Display only. The range of journal numbers (first and last inclusive) tagged in the inquiry screen for
copying or reversal.
Note: Any journal numbering gaps within the selected range are not displayed.
Data Selection
Allocation Marker for Reversal
Determines which allocation indicator is to be applied to the journal lines when generating the reversal
or copy. This applies to both the source journal lines and the generated journal lines.
The allocation indicators are:
Report Process Allocation Indicators Default Allocation Indicator

Journal Copy 0-9 Marker, Blank Allocation Marker Blank Allocation Marker
Journal Reversal Allocated Only, Corrections Only, Blank Corrections Only
Allocation Marker
Payment Reversal Allocated Only, Correction Only Corrections Only
Note: Journal Reversal and Payment Reversal provide facilities to speed up error corrections. The
allocation indicator Correction is recommended because it indicates that the transactions are balanced
and closed. The Report Connection setting in Ledger Setup excludes the Correction transactions from
financial reports. This avoids double-counting the debit and credit totals while maintaining an accurate
audit trail.
Allocation Marker for Orig Invoice

Only used for Payment Reversals. This determines which allocation indicator is to be applied to purchase
invoices or credit notes that were originally paid by the source journal, and therefore the allocation
indicator is changed on those transactions from Paid to whatever you specify in this option.
The allocation indicators are:
• 0-9 Marker
• Blank Allocation Marker
• Withheld Only.
The default allocation indicator is Withheld Only. This indicates that further review is required before
the invoices are included in the payment process. If this is ignored and the invoices are included in the
payment process without correction then further errors will occur.
Note: The default allocation indicators for Allocation Marker for Reversal and Allocation Marker for
Orig Invoice are set by the report process. Different allocation indicators are used for different reporting
purposes. Overriding the default allocation indicator by revising the default value on forms is not
recommended as there is no guarantee it will work.
Transaction Date
Enter the date you want to be registered on the generated journal as the transaction date.
Use Original Transaction Date

Set this option to Yes if you want to copy the transaction date from the originating journal to the generated
journal. In this case, the Transaction Date field is ignored.
Accounting Period
Enter the accounting period you want to post the generated journal in.
Use Original Period

Set this option to Yes if you want to copy the accounting period from the originating journal to the
generated journal. In this case, the Accounting Period field is ignored.
Use Originator Id and Date

Set this option to Yes if you want to copy both the originator Id and date from the originating journal to
the generated journal. Otherwise, set it to No to use your operator Id and the current system date for the
generated journal.
Ignore Reversal in Next Period

Set this option if you want to ignore the Reverse Next Period setting from the Journal Type (JNT).
Suppress Business Rules

Set this option to Yes if you want the generated journal to be posted circumventing all checks performed
by Business Rules. This allows you, for example, to reverse a journal erroneously posted to an account
code that has subsequently been restricted using Business Rules. If this option is set to No and you want
the generated journal to be posted to be checked by Business Rules, the Event Profile (EVP), must
include the call point, End of Journal Line and the Posting Type must be, Post if No Errors Found.
Transaction Reference Prefix

Enter up to 5 characters, alpha, numeric or alphanumeric, if you want the generated journal to include
a prefix on the Transaction Reference.
Transaction Reference Suffix

Enter up to 5 characters, alpha, numeric or alphanumeric, if you want the generated journal to include
a suffix on the Transaction Reference.
Posting Details
Posting Type
This determines whether or not the generated transactions are posted, and whether they can be posted
if they contain errors. Three options are available:
• Validate only - if this option is selected the transactions are validated but not posted.
• Post - if this option is selected the transactions are validated, balancing transactions are generated
to balance the journal if necessary and the journal is posted.
• Post if No Errors Found - if this option is selected the transactions are validated and, providing
there are no errors, posted. This can be overridden for an imbalance by using the Posting Allow
Balance Trans setting described below.
Posting Report Format

The report format to use for reporting the details of the validation, or the posting of the reversal or copy.
Posting Write to Hold

This option validates the generated journals and stores them as held journals on the Journal Hold file.
This provides an additional level of posting control because they then need to be released from hold
and posted. If this option is left unchecked, the journals are validated and posted as provisional or
permanent postings.
Provisional Posting
If the Provisional Postings option in Ledger Setup (LES) is Optional and this option is also set, the
generated transactions are validated and/or posted as provisional transactions. If this option is not set,
the generated transactions are validated and/or posted as permanent transactions.
Posting Allow Balance Trans

This option allows the system to generate and post balancing transactions if there is an imbalance in
the base amount or in any of the currency values that require Amount Balancing, as determined on the
Business Unit Setup. The option is only effective when Posting Type (described above) is set to Post
if No Errors Found.
Use this option in conjunction with Post if No Errors Found if you want to permit an imported journal
to be posted even if it is unbalanced, whilst nevertheless preventing the journal from being posted if it
contains other errors, such as prohibited analysis codes, closed accounts, dates, or periods.
If this option is set, any generated balancing adjustments are treated in one of two ways depending on
the cause of the imbalance:
• For an imbalance due to a currency conversion rounding difference, the adjustment transaction is
posted to the corresponding Balancing Account identified on Business Unit Setup Value 1, Value
2, Value 3 or Value 4 tab, depending on the currency value being adjusted (providing that the
rounding difference is within the threshold for that currency value, also specified on the Business
Unit Setup).
For an imbalance to be considered as due to a currency conversion rounding difference, the journal
must balance in at least one of the currency values.
• For all other imbalances, the balancing transaction is posted to the Base Suspense Account, the
Transaction Suspense Account or the Reporting Suspense Account (specified on the Error
Suspense Accounts tab), depending on the currency value being adjusted.
If this option check box is unchecked, imbalances are treated as errors that prevent the journal from
being posted.
Report Errors Only

Set this option to only report on transactions that contain substitutions, or which have been rejected.
Leave this blank to report on all of the transactions.
Allow Over Budget

This option overrides the budget controls and allows transactions to be posted if they exceed the available
budget.
Post to Suspended Accounts

If this is set, transactions can post to ledger accounts with a status of Suspended. If not, a transaction
posting to a suspended account is treated as an error.
Error Suspense Accounts

Base Suspense Account
The account code to which the balancing adjustment is posted if the base currency journal values do
not balance, and the imbalance exceeds the currency Rounding Threshold for Value 1.
Additionally, if you set the Posting Type option on the Posting Details tab to Post, and a journal
transaction line is rejected, this account is used to post the rejected transaction. For example, if the
account code on a journal transaction is invalid, or an analysis code is prohibited, this account is used
as the substitution.
Transaction Suspense Account

The account code to which the balancing adjustment is posted if the transaction currency journal values
do not balance, and the imbalance is not a currency conversion rounding difference.
Note: In order for balancing adjustments to be generated and posted in the transaction currency, the
Amount Balancing option must be set to Manual on the Value 2 tab of the Business Unit Setup.
Reporting Suspense Account

The account code to which the balancing adjustment is posted if the second base or reporting currency
journal values do not balance, and the imbalance exceeds the currency Rounding Threshold for Value
3.
Note Text
Enter the text relating to the journal copy or reversal. If you are reversing a journal, this field is mandatory.
Using the provisional ledger

The provisional ledger is the term used to describe the provisional transactions that are posted to the ledger
as temporary, or draft postings.
You can use Ledger Entry (LEN) to enter, amend and recall provisional journals. Post Provisional Journals
(PPT) is used to select a group of provisional transactions and make them permanent.
What are Provisional Transactions?

Provisional transactions are posted to the ledger as temporary, or draft postings.
You can amend these transactions and report on them, but they do not form part of the true financial accounts
and reports until they are posted as permanent transactions on the ledger. Permanent postings cannot be
amended.
This facility is designed to cater for Italian and similar accounting standards and is also known as a rough
book or prima nota posting facility.
The ability to post provisional transactions in the ledger is determined by the Provisional Postings field in
Ledger Setup (LES). There are three choices available:
• Prohibited - if this option is set all transactions are treated as permanent postings and provisional postings
are not allowed.
• Mandatory - if this option is set all ledger transactions are posted as provisional postings automatically.
• Optional - if this option is set you are given the option to post ledger transactions as provisional or
permanent when you enter or generate journals.
Your operator group permissions may also restrict the posting options available. These are maintained using
Security Console or User Manager. See also Security Console or User Manager Help for more information.
Provisional transactions are entered manually using Ledger Entry (LEN) in the same way as any other journal.
The only difference is that the journal transactions are posted as provisional rather than permanent
transactions. See 'Entering Provisional Transactions'.
Provisional transactions can be recalled for amendment and permanent posting using Recall Provisional
Journals (PRJ) and Ledger Entry (LEN). Once an individual provisional posting is recalled, it can be posted
as a permanent entry using the Post option. See 'Amending Provisional Transactions'.
Provisional Transactions can be deleted, using Ledger Entry (LEN). You can either delete an entire provisional
journal, or delete ranges or groups of transaction lines within the journal. See 'Deleting Provisional
Transactions'.
A range of provisional postings can be posted permanently using Post Provisional Journals (PPT). Only
those journals that were posted as provisional can be selected.
Note: You can also use Daybook Listing (DYL), Tax Reporting (TXR) or Post Provisional Journals (PPT)
to permanently post selected transactions.
Provisional transaction sequence numbering

Another feature associated with provisional postings, but which can be used independently, is the ability to
assign sequence numbers to transactions.
This is a useful feature which helps to ensure data integrity. Two types of sequence number can be assigned:
• transaction sequence numbers which are assigned when transactions are posted. These can be assigned
to provisional transactions when they are posted as provisional, or only when they are posted as permanent
postings. This is determined by the Hard Posting Only option on Ledger Setup (LES).
• daybook sequence numbers which are assigned when transactions are printed on the Daybook Listing
(DBL) and the provisional transactions are changed to permanent postings.
The journal reference on recalled provisional transactions cannot be amended. This ensures that the sequence
numbering within registration date is maintained.
You can also record a registration date using Ledger Sequences (LEQ), which overrides the normal entry
date for a journal with a 'user defined' date stamp.
Balancing transactions by reference

The ability to force transactions to balance by reference is another feature associated with provisional
transaction processing, but which can be used independently.
This facility is selected by choosing Transaction Reference as the Balance by option in the Ledger Setup
(LES).
Entering Provisional Transactions

A provisional journal is entered manually using Ledger Entry (LEN) in the same way as any other journal.
The only difference is that the journal transactions are posted as provisional rather than permanent
transactions. This means they can be amended but may be excluded from account balances and financial
reports until they become permanent transactions.
You can use Recall Provisional Journals (PRJ) to select provisional transactions that you want to amend,
or if you already know the journal number you recall it directly in Ledger Entry (LEN) by selecting Action >
Recall Provisional.
Provisional transactions can be deleted, using Ledger Entry (LEN). You can either delete an entire provisional
journal, or delete ranges or groups of transaction lines within the journal.
To enter and post provisional transactions in the ledger, the Provisional Postings field in Ledger Setup (LES)
must be set to either Mandatory or Optional. If provisional postings are optional, when you choose to post a
journal in Ledger Entry you are asked whether you want to post the transactions as provisional or permanent.
Provisional postings can also be made by the other SunSystems functions that generate ledger transactions,
for example Payment Run (PYR). Again, if provisional postings are optional, you must choose to post the
transactions as either provisional or permanent transactions.
Note: At some stage you must make the provisional ledger entries permanent.
Amending Provisional Transactions

A provisional journal can be amended manually using Ledger Entry (LEN). However, first you must recall the
provisional journal from the ledger. There are two ways to recall a provisional journal, as follows:
• From SunSystems, use the Recall Provisional Journals (PRJ) function.
• In Ledger Entry select Action > Recall Provisional.
If you do not know the journal number use Recall Provisional Journals (PRJ) to select the journal from a
list of provisional transactions, or if you already know the journal number, recall it directly in Ledger Entry
(LEN) by selecting Action > Recall Provisional.
Provisional Transactions can also be deleted using Ledger Entry (LEN), and similarly to amending, you must
first recall the provisional journal you want to delete from the ledger.
Recall Provisional Journals (PRJ)

You can use Recall Provisional Journals (PRJ) to display a list of provisional transactions, and select one
for amending.
When you use Recall Provisional Journals (PRJ), you can specify selection criteria to limit the list of provisional
transactions displayed, in order to help search for the particular journal you want to amend.
To recall a provisional journal:
1 Select Recall Provisional Journals (PRJ).
2 In the Selection - RECALL PROVISIONAL TRANSform, specify the criteria to filter the list of provisional
transactions displayed in order to help you locate your particular journal. Click OK.
3 The results are displayed on the Financials-Journal Inquiry form, listing all of the provisional transactions
that meet the criteria you specified in step 2. The results are summarized as one line per journal, however,
you can expand each journal to display its individual lines by using Action > Explode, or Action > Explode
Alll.
4 Select the journal you want to amend, and click Recall Provisional.
5 The Find Form List is displayed, with a list of available Ledger Entry forms. This is because when you
select a provisional journal for amending, the Ledger Entry function needs to use a form in which you
can edit the journal. Select a ledger entry form and click OK.
6 Change the journal transaction details in the normal way.
7 Post the journal to save the changes. A message appears indicating that the journal has been re-posted.
Recalling Provisional Transactions from within Ledger Entry

You can also use Ledger Entry (LEN) to recall a provisional journal.
Note:
• You must know the journal number to be able to recall the transactions from within Ledger Entry.
• If provisional posting is optional, you can change the journal transactions from provisional to permanent
postings at this stage, if required.
To recall a provisional journal from within Ledger Entry:
1 Select one of the Ledger Entry forms.
2 From the Action menu, choose Recall Provisional to display the Journal Processing dialog.
3 Enter the journal number in the Provisional Journal Number field and click OK.
The journal is recalled and the details of the first transaction appear on the Ledger Entry form.
4 Change the journal transaction details in the normal way.

5 Post the journal to save the changes. A message appears indicating that the journal has been re-posted.
Deleting Provisional Transactions

In order to delete a provisional journal, or certain transactions within it, you must first recall the provisional
journal via Ledger Entry (LEN), using the same steps described in 'Amending Provisional Transactions'.
Once you have recalled the provisional journal in Ledger Entry (LEN), select Action > Line > Delete to display
the Journal Processing dialog. You can use an '*' asterisk to represent all transaction references or all lines
within a transaction reference, or any combination of these, as described in the following sections:
To Delete an Entire Provisional Journal

Enter an '*' asterisk in the Transaction Reference field, and click OK. You must confirm that you want to
delete the entire journal.
To Delete All Lines of a Specific Transaction Reference in a Provisional Journal

Enter the specific reference in the Transaction Reference field and an '*' asterisk in the Range field, and click
OK. You must confirm that you want to delete the selected journal lines.
To Delete only Certain Lines of a Specific Transaction Reference in a Provisional Journal

Enter the specific reference in the Transaction Reference field and the required line number(s) in the Range
field, and click OK. You must confirm that you want to delete the selected journal lines.
You can use any of the following example formats to delete ranges or groups of line numbers:
• 1-3 to indicate a range of line numbers, from 1 to 3
• 1,3,5 to indicate individual lines numbered 1, 3 and 5
• 1-3,6,9 to indicate a range of 1 to 3, and also individual lines 6 and 9.
Note: If you are entering multiple lines to be deleted, use a comma as the delimiter between the line numbers.
Making Provisional Transactions Permanent

SunSystems Financials provides several different methods for you to make provisional postings permanent.
You can use Post Provisional Journals (PPT) to select a group of provisional transactions and make them
permanent.
You can run either of the following standard Financials reports and set the required option to make any
provisional postings included on the report permanent:
• Daybook Listing (DYL) by setting the Definitive Request field.
• Tax Reporting (TXR) by setting the Print Final option.
You can also make the transactions in a provisional journal permanent by recalling the provisional journal
and posting them permanently in Ledger Entry (LEN).
Note: If sequence numbers are being assigned to ledger transactions, the number can be assigned when the
provisional transactions are posted as provisional or permanent transactions.
Using Post Provisional Journals

Post Provisional Journals (PPT) allows you to change a group of provisional postings into permanent
postings, in one process.
If sequence numbers are being assigned to provisional postings when they become permanent, they are
generated at this stage.
To make a group of provisional transactions permanent:
1 Access Post Provisional Journals (PPT) to display the standard document format print request form.
The Document Format Code at the top of this form determines the type of provisional posting report
to be produced.
2 Select the document format PPT1, enter the remaining print request details and click OK.
Posting Withheld Taxes

Legislation in a number of countries allows for tax to become payable on the receipt date, rather than the
invoice date. A notional tax liability is calculated on the invoice and is posted to a notional tax account. When
a receipt is recorded for the invoice, the notional tax amount is posted to the actual tax account, when it
becomes due.
Post Withheld Taxes (PWT) allows you to identify transactions for a range of accounts. It selects the allocated
invoices and receipts within the range, and moves the tax amount from the notional account to the actual
account.
You can specify a range of gross accounts, and enter the notional or original tax suspense account code(s)
used. This function allocates the credit value on the tax suspense account and posts an allocated balancing
debit to the same account. This effectively cancels the original tax posting. A balancing credit is then generated
and posted to the actual tax account specified on this form.
Sequencing can be applied to system generated transactions, including those generated by Post Withheld
Taxes.
Post Withheld Taxes does not perform the allocation of debit to credits.
Note: If you are using expenditure checking, you should note that transactions are posted by Post Withheld
Taxes even if budgets are exceeded.
1 Use Post Withheld Taxes to identify the gross, notional and actual tax accounts.
2 Select Action > Post to generate and post the tax transactions.
Temporarily Grouping Ledger Data

Where no other suitable selection criteria exists, ledger transactions can be temporarily grouped into 'saved
sets'. This allows these transactions to be selected easily for further processing or viewed on inquiries.
Transactions can be added to an existing saved set, or removed from a set. In addition, a saved set can be
removed once it is no longer required.
Only the creator of the saved set can update or delete the saved set. If the creator is a member of a user team,
all members within that team can update or delete the saved set.
To create a saved set:
1 Use a control desk filter to extract the ledger transactions you want to group onto the Control Desks
In-Tray.
2 Select the Report Process of Saved Set Process and click OK.
3 Providing none of the selected transactions have already been included in an existing saved set, the
Saved Set Details dialog appears. It displays with the next sequential Saved Set Number, Operator
Code, User Name, Team Name, Date/Time Last Updated, and Comment, a free text area for any
comments. You must enter some comments and click OK to create the saved set.
4 A confirmatory message is displayed. Click OK.
Reporting Transactions
SunSystems includes a number of different types of transaction listing.
• Journal Listings report transactions, and provide a basic audit trail reporting. You can force the printing
of a journal listing each time a journal is posted by choosing one of the Force Journal Listing options in
Ledger Setup (LES).
• Daybook Listing is similar to Journal Listing, allowing you to design your own basic audit trail reports.
You can, however, sequence transactions by date and period.
• Account Listings report transactions within account and are useful audit and checking reports.
• Payment Listing lists particular payment transaction details but it can also be used to list the transactions
associated with any type of journal or journal source
Each of the transaction input options, Ledger Entry (LEN), Ledger Import (LIM), and Account Allocations
(ACA), allow you to report transactions before posting using the Report action. You can design your own
reports for use with each of these forms using Report Designer.
In addition, a report is produced for each of the procedures within SunSystems that automatically generates
transactions.
Depending on your selections, the Financials report writers can also report transaction details in addition to
the summary totals.
Note: Held transactions are treated as unposted, and are therefore not included in general reports. You can
list these transactions on the Held Journal Listing.
Authorizing Transactions
Chapter 4: Authorizing Transactions
When a user enters or selects a group of transactions for processing, some of these transactions may require
authorization.
These transactions are grouped into an authorization set and marked as awaiting authorization. The
authorization set is then passed through each stage of the authorization process that applies.
Understanding the Authorization Process

When a user enters or selects a group of transactions for processing, some of these transactions may require
authorization.
These transactions are grouped into an authorization set and marked as awaiting authorization. The
authorization set is then passed through each stage of the authorization process that applies.
The Authorizer
The transactions are sent for the first stage of authorization required and are placed on the authorizer's
Authorization In Tray (AUT). The authorizer is able to review the set of transactions on the in tray and either
authorize it or reject it. The authorizer must enter a valid password to be able to authorize the set.
If the set of transactions is rejected by the authorizer, it returns to the originator or to the authorizer for a
previous authorization stage. When an authorizer rejects transactions, a financial rejection code is used to
identify the reason for the rejection.
If the set of transactions is authorized, the set moves to the next step in the authorization process. It either
moves on to the authorizer for the next level of authorization required, or if it is fully authorized, it is given
the status of Complete, and processed.
The processing that takes place depends on the function that triggered the authorization requirement. For
example, if the transactions were journals held by Ledger Entry or Ledger Import, when they are fully
authorized they are posted automatically (providing they still balance).
The authorizer is any member of the user team assigned to the authorization stage. The transactions requiring
authorization are placed in the Authorization In Trays of all the users in the user team. This helps to ensure
that a set of postings is not held up if, for example, one person in the team is absent.
Note: Authorizers are not alerted to the fact that new transactions are awaiting their authorization, hence
they must check their authorization in-tray frequently.
The Originator
The user that generates the transactions awaiting authorization is referred to as the originator of the
authorization set.
The Authorization Originators In-Tray (AOT) lists all of the authorization sets created by a particular operator.
This way, users can see the status of all the transactions they have generated that require authorization.
When a rejected authorization set is displayed, it must be deleted before it can be modified in the appropriate
function, such as ledger entry. Transactions that have been authorized and posted are no longer displayed.
Note: Originators are not alerted when their transactions are authorized or rejected, hence they must check
their originator in-tray frequently.
What Transactions Require Authorization?

Authorization is permitted in the A Ledger only and can apply to the transactions entered into, or selected
for, any of following Financials processes:
• Payments
• Ledger Entry/Ledger Import
• Matching/Allocations.
When you use any of these processes and authorization is enabled, Financials checks the authorization stages
that have been set up for the appropriate process to see whether any of the transactions you are working
with require authorization.
If the transactions do need authorization, they are placed in an authorization set and automatically sent to
the default authorizer for the first stage of authorization required. The transactions are given a status of
Authorization in Progress.
Payment Authorization
If authorization is enabled, all of the transactions selected for payment are checked to verify if authorization
is required. Payment Run checks each authorization stage that has been defined for the Payments stage type
to see whether the transactions meet the filter requirements for the stage. If they do, the transactions are
grouped into an authorization set and sent for authorization.
If the total of the transactions selected for payment exceeds the Payment Limit for the run, these transactions
also require authorization.
Note: The Payment Limit is the total amount that can be paid by payment run without authorization. It does
not apply to the individual payments produced by a payment run. So, if the Payment Limit is 100 GBP and
the transactions selected for payment will produce two payments of 99 GBP each, the transactions will require
authorization because the total of the payment run is over 100.
If Financials is being used as a broker ledger, authorization may also be required for any transactions selected
for payment that have been funded. For example, if a transaction with a Withheld allocation marker has been
selected for payment thus breaking the pay as paid rule.
Account Allocations
If you are using Account Allocations, or any of the other matching functions, some transactions may require
authorization before they can be matched. For example, this may be required if the difference between the
transactions you are matching exceeds the matching tolerance percentages/values.
If Financials is being used as a broker ledger, authorization may also be required for transactions where:
• the Funding status is set in the Allocation Code, either because a transaction with a Withheld allocation
marker is being matched, or because a broken billing link has caused the Funding status to be set.
• the allocation code/marker is being updated.
Ledger Entry / Ledger Import

A journal being entered using Ledger Entry or Ledger Import requires authorization if the Authorization
Required option has been set for the journal type.
Creating and reviewing authorization sets

If transactions need authorizing then they are included in an authorization set.
The user that marks the transactions for authorization is referred to as the originator of the authorization set.
The transactions remain in the same set throughout the authorization process. The originator adds any
relevant information to the set and then it is assigned an Authorization Set Reference number.
An authorizer reviews the transactions in an authorization set before authorizing them, using the Authorization
Inquiry form.
After authorization, It is possible to review the details of transactions that have been authorized by running
the Authorization Audit Trail.
Marking Transactions for Authorization

When the system identifies a set of transactions that require authorization before they can be processed any
further, it displays the Authorization Batch Comments dialog. This allows you to enter information you
would like to be available to the authorizer to help the authorization process.
For example, if the transactions have been selected for payment and the payment is for a specific purpose,
you may want to note this.
Note: The originator's comment is preserved on the authorization set throughout its progress through the
authorization stages, even if each authorizer attaches their own additional comments.
The dialog displays the Authorization Set Reference. This number is automatically assigned to the group
of transactions requiring authorization. The transactions remain in the authorization set throughout the
authorization process.
You can enter any text you require in the Comment box and then click OK to assign it to the set of transactions.
The user that marks the transactions for authorization is referred to as the originator of the authorization set.
The Authorization Originators In-Tray filter lists the authorization sets created by an originator and allows
the originator to view the details of the set, or delete an authorization set.
Reviewing the authorization sets for an originator

An operator may mark many different sets of transactions for authorization and may want to view the status
of these authorization sets.
The Authorization Originators In-Tray (AOT) lists the authorization sets created by an originator, and allows
you to view the details of the set. It also allows you to delete an authorization set, for example if the transactions
no longer need to be processed and therefore no longer require authorization.
If an authorization set has been rejected, the reason for the rejection is displayed. The originator in tray allows
you to recall the rejected set into Ledger Entry, for example, to modify certain details, and to resubmit a
rejected set for authorization.
Using the Authorization Originators In-Tray

1 Select Authorization Originators In-Tray (AOT) from SunSystems to display the Selection - ORIGINATOR
INTRAY form.
2 Enter the originator's operator code. Only authorization sets created by this operator are listed.
3 Click OK to extract the authorization sets.
4 These sets are listed on the Authorization Headers form.
5 To view the transactions in a set, double click on the Authorization Set Reference field to drill down to
the authorization set details.
Reviewing an Authorization Set

The Authorization Inquiry form lists all of the transactions included in an authorization set. This dialog can
be accessed by:-
• selecting Authorization Details (AUL) from SunSystems.
• drilling down on the authorization set reference from both the Authorization Originators In-Tray and
the Authorization In-Tray. To display the Authorization Inquiry form, double-click the authorization
set reference field on either of these in trays.
Authorization Inquiry
The following fields are displayed on the Authorization Inquiry:
Authorization Set Reference

The unique identifier assigned to the set of transactions. This is assigned when the transactions are initially
identified as requiring authorization on the Authorization Batch Comments dialog.
Authorization Set Line Number

The unique line number assigned to the transaction in the authorization set.
Assigned Authorizer
The operator Id of the user currently assigned as the authorizer.
Account Code
The account referenced on the transaction.
Trans Accounting Period

The accounting period referenced on the transaction.
Trans Transaction Date

The transaction date entered on the transaction.
Trans Journal Number

The journal number assigned to the transaction. You can drill down on this to view the other transactions in
the journal on the Journal Inquiry form.
Trans Journal Line Number

The journal line number assigned to this transaction
Running the Authorization Audit Trail

It is possible to review the details of transactions that have been authorized by running the Authorization
Audit Trail which can be accessed by selecting Authorization Audit Trail (AAT) from SunSystems. It lists all
the transactions that have been authorized depending on the criteria selected.
The Selection - AUTHORIZATION AUDIT TRAIL form is displayed, which contains the following:
Date/Time Last Updated From/To
The date and time range when the authorization set was last updated.
User Team Code From/To

The range of User Team Codes required to authorize the set of transactions.
Authorization Status
The range of current statuses of the authorization set. This may be: Awaiting Authorization, Rejected,
Complete, Awaiting Re-Authorization, Authorization Deleted.
Last Authorizer From/To

The operator id range of the users that last authorized the set.
Current Originator From/To

The operator Id range of the users that marked the transactions for authorization. This is the operator that
entered the transactions or selected them for processing.
Assigned Authorizer From/To

The range of operators to whom the authorization set is currently assigned for authorization.
Last Rejection Code From/To

The range of financial rejection codes assigned to the authorization set, if it has been rejected.
Reviewing the Authorization Audit Headers

The Authorization Audit Headers form displays the following columns fields:
Assigned Authorizer
The operator Id assigned as the default user required to authorize this set of transactions.
Authorization Set Reference

The unique identifier assigned to the set of transactions awaiting authorization. This is assigned when the
transactions are initially identified as requiring authorization on the Authorization Batch Comments dialog.
Authorization Status
The current status of the authorization set. This may be: Awaiting Authorization, Rejected, Complete, Awaiting
Re-Authorization, Authorization Deleted.
Comment
Any comments entered for the authorization set when it was created.
Current Authorization Stage

If the authorization set is awaiting authorization, this is the authorization stage for which this authorization
is required. An authorization set may need to be authorized by more than one stage.
Current Originator
The operator Id of the user that marked the transactions for authorization. This is the operator that entered
the transactions or selected them for processing.
Date/Time Last Update

The date and time the authorization set was last updated.
Last Authorizer
The operator id of the user that authorized the set at the previous authorization stage, if applicable.
Last Rejection Code

The financial rejection code assigned to the authorization set, if it has been rejected.
Last Rejection Comments

Any comments entered when the authorization set was rejected.
User Team Code

The user team required to authorize the set of transactions.
The steps required to authorize transactions

The transactions that require authorization are automatically recognised by Financials. The operator who
entered or selected these transactions, referred to as the authorization originator, is prompted to enter
comments and the transactions are automatically marked as awaiting authorization.
The set of transactions is then placed on the Authorization In-Tray for the default authorizer.
Note: Authorizers are not alerted to the fact that new transactions are awaiting their authorization, hence
they must check their authorization in-tray frequently.
The following steps are required to authorize a set of transactions awaiting authorization:
Note: You must log into Financials using an Operator id that is a member of an authorization user team to
be able to carry out the following steps.
1 Select Authorization In Tray (AUT) from SunSystems.
The Selection - AUTHORIZATION IN TRAY form is displayed.
2 Enter the User Team Code of the authorizer.
3 In the Assigned Authorizer fields enter one or more operator Ids of Authorizers whose authorization sets
you want to review.
4 Click OK to list the relevant sets of transactions awaiting authorization on the Authorization In Tray.
Selecting Transactions for Authorization

The Authorization In Tray (AUT) form is used to extract the sets of transactions that are awaiting authorization
by a member of a selected user team and display them on the Authorization In Tray.
You can only use this function if you are a member of a user team, and can only select user teams for which
you are a member.
1 Select the Authorization In Tray (AUT) option from SunSystems to display the Selection-AUTHORIZATION
INTRAY form.
2 If necessary amend the user team and operator code. Only sets of transactions awaiting authorization
by any member of this team are displayed.
3 Click OK.
4 Enter any run-time selection parameters required on the selection form, if it is displayed. This allows you
to further restrict the sets of transactions you want to select.
5 Click OK.
6 The sets of transactions awaiting authorization for the chosen user team, that match the selection criteria
if entered, are listed on the Authorization In Tray. You can authorize or reject each set of transactions,
as required.
Authorizing a Set of Transactions

The Authorization Accept dialog is displayed when a valid authorizer chooses the Authorize or Authorize
All, actions on the Authorization In Tray (AUT). This is required to authorize the selected transactions.
Number of Extracted Records
This displays the number of transactions selected for authorization.
Password
The authorizer must enter a valid password to authorize the transactions.
Note: If the authorizer specifies an invalid password three times, the authorizer's password is revoked
and the authorizer will not be able to authorize further transactions. The authorization password can
be reset by an administrator in Security Console or User Manager.
Comment
Any additional notes or comments the authorizer wants to enter for the authorization set.
Rejecting Transactions Awaiting Authorization

The Authorization Reject dialog appears when a valid authorizer chooses the Reject or Reject All actions
on the Authorization In Tray (AUT). This is required if the authorizer wants to reject the authorization request.
When an authorizer rejects transactions, a financial rejection code is used to identify the reason for the
rejection, and a comment can be added for any additional information.
If the originator belongs to one or more user teams, the Choose Originator Operator dialog is then displayed.
This allows the authorizer to assign the rejected transactions back to the originator (by default) or to a different
operator in the same user team as the originator.
An originator can view rejected authorization sets on the Authorization Originators In-Tray.
1 The Authorization Reject dialog contains the following fields:
Number of Extracted Records
This displays the number of transactions selected for authorization.
Rejection Code
Select the code that identifies the reason the set of transactions has been rejected. Rejection codes are
defined using Financial Rejection Codes Setup (FJC).
Comment
Any additional notes or comments the authorizer wants to enter for the authorization set.
2 The Choose Originator Operator dialog contains the following fields:
User Team Code

If the originator belongs to more than one user team, select the code that identifies the user team to
which you are assigning the rejected transactions. If the originator only belongs to one user team, then
this field is for display only.
Operator Code
Select the code that identifies the operator to whom you are assigning the rejected transactions. The
originator's operator code is shown by default.
Comment
Display only. The comment that was entered by the originator against this authorization set.
Understanding the authorization intray

The Authorization In Tray can be accessed by selecting Authorizations (AUT) from SunSystems.
It lists all of the sets of transactions that require authorization by a member of the user team identified on
the Authorization In Tray.
Using the Authorization In Tray

The following steps describe how to use the Authorization In Tray:
1 From the main SunSystems menu, select Authorizations (AUT).
2 The Selection - AUTHORIZATION INTRAY form is displayed. Enter the User Team Code for the Assigned
Authorizer.
3 Enter the operator Id of the user whose authorization sets you want to review.
4 Click OK.
The Authorization Headers form is displayed, with a grid listing the authorization sets currently assigned
to the relevant authorizer.
Matching and allocating transactions
Chapter 5: Matching and allocating transactions
Matching is the process of linking one or more related transactions on an open item account, to 'close' the
transactions. This process is also referred to as account allocation.
To match, or allocate transactions, you set an allocation marker on the transactions to indicate the matched
status.
What is Matching?
Matching is the process of linking one or more related transactions on an open item account, to 'close' the
transactions. This process is also referred to as account allocation. To match, or allocate transactions, you
set an allocation marker on the transactions to indicate the matched status.
For example, when an invoice is posted to a debtor/receivables account it is entered as an open, unallocated,
transaction on the account. In a simple case, if the invoice is paid in full with a single payment, two steps are
required to record the payment fully:
• A payment transaction must be posted to the debtor account to reduce the debtor's balance
• The payment and invoice transactions on the debtor's account must be matched together to indicate
that the invoice has been paid.
To match the payment against the invoice you would set the allocation marker to To Be Allocated on the
payment and invoice transactions. Then, when the allocations are posted, the allocation marker on each
transaction is changed to Allocated.
The transactions posted to open item accounts remain in the system until they are allocated. That is until
the transaction contains a matched allocation marker. There are four 'matched' allocation markers: Allocated,
Paid, Correction or Reconciled.
On debtor/receivables, creditor/payables, and client accounts it is particularly important that the transactions
are matched correctly to prevent paid transactions being treated as unpaid.
If the Authorization facility is enabled, some transactions selected for matching may require authorization
before they can be matched.
If instalment checking has been enabled in Ledger Setup (LES), the matching processes ensure that cash is
matched against the instalments in either instalment number or instalment date sequence.
Matching can be more involved than simply matching two corresponding items. You may need to:
• match several transactions together on the account. For example, you may need to allocate one payment
to many different invoice and credit transactions on the account.
• split a transaction into two to be able to match it correctly. For example, you may have received a payment
for only part of an original transaction and need to split the original transaction into two transactions.
• generate additional transactions to record the difference between the 'matched' transactions, for example
to record settlement discounts or currency exchange differences.
Note: If SunSystems Financials is being used as a broker ledger, cash posting transactions contain a Value
Date and can only be selected for matching on or after this date is reached.
Matching in SunSystems
SunSystems Financials provides several different methods for matching transactions:
• Online allocation - allows you to allocate a transaction as part of the Ledger Entry process.
• Account Allocations - allows you to manually allocate transactions on a single, selected account.
• Transaction Matching - allows you to allocate the transactions on several accounts, using predefined
matching rules.
• Reconciliation Manager - allows you to match entries both automatically according to predefined match
criteria, or manually.
Note: When you generate or collect payments automatically using Payment Run (PYR) and Payment
Collection Run (PYC), the payment transactions are generated, posted, and matched against the items being
paid automatically. The only exception to this is if the Non Match of System Payments option is set in Ledger
Setup (LES) and a user has elected to mark paid transactions as Paid Unmatched.
What Matching and Allocation Facilities are Available?

Within SunSystems you can match or allocate transactions online in Ledger Entry (LEN); or, once transactions
have been posted, by using Account Allocations (ACA), Transaction Matching (TRM) or Reconciliation
Manager (RCM).
Allocating During Manual Ledger Entry

If you use Online Allocation, you can match transactions at the same time as you enter them onto your ledger.
For example, if you are entering a cash receipt onto a debtor/receivables account, you can immediately match
the cash to the invoices and credits that have been paid.
Online allocation is often the most efficient way to match transactions, particularly cash receipts or manual
payments.
You can use a journal preset to automatically display the online allocation form as part of the ledger entry
process.
Allocating After Ledger Entry

There are times when you need to carry out the allocation process as a separate step, after all of the
transactions have been entered onto the ledger. For example, if you are posting an unidentified receipt from
a bank statement, you cannot allocate it online as part of the cash input process. In this case, once you have
posted the miscellaneous receipt, you must identify the customer and items that have been paid. Then you
can allocate the cash transaction to the corresponding invoice and/or credit transactions on the customer's
debtor/receivables account.
SunSystems provides the following methods of matching transactions after they have been posted to the
ledger:
• Account Allocations (ACA) allows you to manually allocate selected transactions on an account
• Transaction Matching (TRM) allows you to allocate transactions on several accounts using predefined
matching criteria
• Reconciliation Manager (RCM) allows you to match entries both automatically according to predefined
match criteria, or manually.
Note:
• Account Allocations also allows you to amend some of the details available on a transaction, in particular
the allocation marker and payment term details. See 'What Transaction Details can be Amended Using
Account Allocation'.
• All of the matching functions perform additional tasks when Financials is being used as a broker ledger,
to meet the Pay as Paid requirements. When linked transactions are matched and posted the matching
processes automatically find any other transactions with the same intra-transaction link and release
these for payment.
What is Instalment Checking?

SunSystems Instalment Checking is one of the optional facilities available and is particularly useful when you
are using Financials as a broker ledger in a Pay As Paid environment. If a client is paying premiums in several
instalments, the instalment checking facility is used by the matching processes to produce warnings if payment
transactions are not matched to the outstanding instalments in the correct order.
Instalment checking can ensure the individual instalment transaction lines are matched in either instalment
date or instalment number order. The date or instalment number must be included on the transaction lines
which are loaded via Ledger Import or entered on Ledger Entry.
Instalment checking is enabled in Ledger Setup (LES) where you can choose to match the instalment
transactions by either instalment date or instalment number.
If Instalment checking is enabled, the matching processes check either the instalment date or instalment
number on transactions selected for matching. It generates a warning if there is an unmatched line with the
same transaction currency code and a transaction reference with those same first 'n' characters (where n is
set in Instalment Check Length field on Ledger Setup) or an earlier Instalment Date or Number.
This warning message does not prevent you from matching the selected transactions.
Note: When using transaction reference, if an unmatched transaction exists with an earlier date or number
than the transaction being matched, the program will complete the matching process and indicate on the
report that an earlier instalment exists.
An Instalment Checking Example

The Instalment Check Length field is set to 4.
Account Tx Ref Instalment No. Amount

64001 AAAA12 1 GBP 100 DB
64001 AAAA13 2 GBP 60 DB
64001 AAAB14 1 GBP 50 CR
A payment is received for GBP 60 and you attempt to match this against the second transaction above (Tx
Ref AAAA13/Instalment 2). This is rejected because there is an unmatched transaction with the same instalment
matching reference (AAAA) and an earlier instalment number.
Account Allocation
Account Allocations (ACA) is used primarily to match transactions on an account.
For example, a debtor/receivables payment transaction can be allocated or matched to the original invoice.
You can fully match a group of transactions, and you can split a transaction if you need to match against only
part of the transaction value.
Account Allocations can determine whether settlement discount has been taken and post the discount and
any tax on the discount automatically. It can also generate and post any currency exchange differences caused
by fluctuating exchange rates.
Account Allocations also allows you to:
• change the allocation marker on a transaction, for example to reconcile the transaction, indicate the
processing status of the transaction, mark it for immediate payment, or withhold it from payment.
• alter the transaction analysis codes, description, entry date, payment terms code, due date and other
payment related details.
Note: If budget checking at analysis code level is used, any amendment to analysis codes via Account
Allocations is not reflected in the budget check values and therefore any future postings may not be compared
against the correct value.
When you use Account Allocations you perform some of the following steps, each of which is described
briefly below:
• Extract Account Transactions for Allocation
• Display the Transaction Details
• Amend Transaction Details
• Match the Transactions
• View the Allocation Balancing
• Post the Allocations, Discount and Exchange Differences.
Extract Account Transactions for Allocation

The first step in the process is to select the transactions you want to allocate, or amend, on an account. The
Account Allocations Extract facility provides powerful selection criteria for you to choose the transactions
you require.
You can specify ranges of accounting period, transaction date, journal type, journal source, transaction
reference, entry date, allocation marker, and transaction analysis codes to identify the transactions you wish
to select. You can also select transactions based on the currency codes, amounts and debit/credit indicator.
The transaction selection criteria are entered using the Selection Criteria for Account Allocation form.
Display the Transaction Details

All of the transactions extracted for allocation or amendment are displayed on the Search Results - Account
Allocation form.
You can change the sequence in which the transactions are displayed using the Sort option.
Note: The FULL version of Account Allocations displays all of the details available on a transaction, not all
of which can be amended. Other versions of the Account Allocations form display only some of the transaction
details. For example, the PAYMENTS version of Account Allocations only allows you to update the payment
details on a transaction and so only displays those details.
Amend Transaction Details

The transaction details you can amend are displayed in highlighted columns on the Search Results - Account
Allocation form. You can alter the allocation marker, description, payment due date and other payment
details. You can also amend the transaction analysis codes which allows you to correct any analysis mistakes
or reanalyze existing transactions.
You can use theAction All option to change the allocation marker on a group of transactions. This is useful if
you have used the Extract facility to select transactions that all require the same allocation marker. For
example if you need to withhold a set of transactions from payment.
Match the Transactions

When you match, or allocate, transactions you are linking together related transactions to 'close' them and
allow them to be removed from the system by Ledger Cleardown (LCL). The matched transactions must
balance which means the total of the allocated debit transactions must equal the total of the allocated credit
transactions.
You can fully match a transaction by allocating the entire transaction value. To fully match a transaction you
set the allocation marker to To Be Allocated.
Alternatively, you can partially match a transaction by splitting a single transaction into two transactions,
one of which is allocated and the other left unallocated. To partially match a transaction, you set the allocation
marker on the original transaction to Split and enter the amount to be allocated.
As you mark transactions for allocation, the transaction values are added into allocation totals maintained
by the system. The transactions marked for allocation must balance before you can post amendments.
View the Allocation Balancing

The transactions you match must balance before the allocations can be posted. To be in balance, the total
of the debit and credit transactions marked for allocation must net to zero. In addition, the transactions
marked with some allocation markers must balance separately.
To help you balance the allocations, Account Allocations maintains and displays useful totals. It displays
the overall debit and credit allocation totals, and any difference, in any of the currency values in use.
In addition, it displays the debit and credit allocation totals for the allocation markers that must balance
separately.
Note: In a multi-currency environment, the currency balancing rules also apply as defined in Business Unit
Setup.
Post the Allocations, Discount and Exchange Differences

When you have marked the required transactions for allocation, you use the Post option to update the
transactions. If the allocations balance, the transactions are allocated. The allocation reference, allocation
date and allocation period are all recorded on the transactions.
Sometimes the transactions you have matched together do not balance. This may simply be because you
have selected the wrong group of transactions for matching. Or it may be because:
• settlement discount has been taken on some of the transactions which has caused an imbalance.
• different exchange rates apply to the matched transactions which has caused an imbalance in one or
more of the currency values.
The system calculates any discount due on transactions and determines whether or not this is allowed. It
takes any authorized discounts automatically, and also allows you to apply an imbalance as discount.
Account Allocations automatically caters for both of these situations. When you choose to Post an allocation
that is out of balance it checks whether the out-of-balance amount could be settlement discount or an
exchange difference.
If the differences are within the tolerances allowed for discount, it generates and posts the discount. If the
allocation remains out of balance, and discount was allowed, you can choose to post the imbalance as
additional discount.
If the difference is caused by a currency fluctuation or rounding difference, it applies the currency balancing
rules and may generate and post a realized exchange difference or rounding adjustment transaction
automatically. Otherwise, you are forced to balance the allocations manually.
Alternatively, you can choose to manually enter and post an additional journal to balance the allocations.
Understanding the Account Allocation Forms

Account Allocations (ACA) is a particularly powerful SunSystems function that enables you to match
transactions. It can also be used to amend a variety of transaction details.
Because it can be used for different purposes, you may find there are several versions of the Account
Allocations form available. These versions may be displayed separately on the SunSystems menu. Alternatively,
when you run Account Allocations (ACA) you may be prompted to select a form on the Find Form List.
The following versions of Account Allocations are provided with the standard SunSystems Financials product:
Account Allocation Menu Shortcut Form characteristics

Form
FULL AAFULL Displays all transaction details, allows you to allocate transactions
and update any of the amendable transaction details.
ALLOCS AAAMEND Displays only limited transaction details and only allows you to
amend the allocation marker and transaction description.
Therefore, it restricts you to allocating transactions only.
PAYMENT AAPAY Displays transaction payment details and only allows you to
amend these. You cannot use this version to allocate transactions.
ANALYSIS AAANLS Displays limited transaction details and only allows you to amend
the description and transaction analysis codes
The Account Allocation Forms and Dialogs

The different versions of Account Allocations always include the following two forms:
• the Selection Criteria for Account Allocation form which is used to select the transactions you wish to
allocate or amend
• the Search Results - Account Allocation form which lists the selected transactions and allows you to
match transactions and/or amend transaction details.
The Search Results - Account Allocation form can display the following dialogs, depending on the
circumstances:
• Split Transactions dialog if you assign the Split allocation marker to a transaction or choose the Signed
Split command
• Allocation Multipart Split dialog if you select Multipart Split action, and choose the single currency
form.
• Allocation Multipart Split MC dialog if you select either the Multipart Split action and choose the
multi-currency form, or if you select the Currency Split action.
• Allocate All dialog if you select the Action All command
• Allocation Range dialog if you select the Range Allocate command
• Allocation View Totals dialog if you select the Allocation Totals command or are required to apply
discount or generate transactions manually.
• Account Allocation Difference Account Entry dialog if an account code is required to post exchange
difference or discount amounts.
The Account Allocation Toolbar

The Search Results - Account Allocation form contains a number of specific functions required to allocate
and amend transactions. These functions can be accessed from the Action menu.
The Action menu commands are briefly explained below, and any corresponding toolbar button is identified.
Where a function is explained in detail in another topic a link is provided.
Menu Command Sub- Tool- Use

Menu bar
Com- Button
mand
Currency Totals Base Displays the overall allocation totals in base currency
Curren-
cy
Transaction Currency Displays the overall allocation totals in transaction currency
Report/Second Base Displays the overall allocation totals in second base or re-
porting currency
Memo amount Displays the overall allocation totals in memo currency
Fourth Currency Displays the overall allocation totals in fourth currency
Fifth Currency Displays the overall allocation totals in fifth currency
Post Post Updates the transactions and posts any generated transac-
tions as permanent postings
Post Provisional Updates the transactions and posts any generated transac-
tions as provisional postings
Allocation Totals Displays the total of the allocated transactions
Swap window Switches between the sections of the online allocation form
and is only available on the Search Results - Ledger Entry
- Online Allocation form
Action All Allows you to change the allocation marker on selected
transactions
FIrst Displays the first transaction in the allocation grid
Previous Displays the previous transaction in the allocation grid
Next Displays the next transaction in the allocation grid

Last Displays the last transaction in the allocation grid
Sort Ascending Sorts the transactions according to the selected column
Standard Text Allows you to enter standard text
Generate Opens a Ledger Entry session to enable a journal to be

posted
Refresh Re-extracts all of the transactions for the account that sat-
isfy the selection criteria
Clear Allocation in Resets the 'Allocation in Progress' marker set on transac-

Progress tions with pending allocations from held journals.
Note that this is only available if the user belongs to an
authorized data access group.
Signed Split Allows you to split a transaction into two transactions
Multi Split Allows you to split a transaction into several transactions
Currency Split Allows you to split a transaction into several transactions
including different currency values
Find Finds transactions containing a particular value in a select-
ed column.
Range Allocate Allows you to change the allocation marker on a selected
range of transactions
The Account Allocation Command Buttons

Account Allocations (ACA) contains the following command buttons at the bottom of the form. You may
need to use several of these buttons, or the corresponding menu or toolbar options, to allocate transactions.
These buttons are briefly explained below, and the corresponding toolbar button is identified. The functions
are explained in detail in other topics.
Command Button Toolbar Use

Button
OK Validates and accepts the current allocation
Exit Leaves the Account Allocation form and returns to the menu
Post Posts the allocations, providing the allocations balance
Action All Change the allocation marker on a group of transactions

Allocation Totals Displays the allocation balance totals
Text Allows you to enter standard text for the allocation
Sort Resequences the extracted transactions for the selected column
Range Allocate Allows you to change the allocation marker on a selected range
of transactions
Signed Split Allows you to split a transaction into two transactions
Multipart Split Allows you to split a transaction into several transactions
Currency Split Allows you to split a transaction into several transactions includ-
ing different currency values
Clear Allocation in Resets the 'Allocation in Progress' marker set on transactions

Progress with pending allocations from held journals. Note that this is
only available if the user belongs to an authorized data access
group.
Cancel Discards the details for the allocation
How are Transactions Selected for Allocation?

When you use Account Allocations (ACA) to match transactions on an account, your first task is to identify
the account and transactions you want to match. Transactions are selected for allocation using the selection
criteria that you identify on the Selection Criteria for Account Allocation form. This form is displayed when
you access Account Allocations (ACA).
You can use the selection criteria to select transactions based on:
• accounting period, transaction date, ledger entry type, journal source, transaction reference, transaction
analysis code, and entry date.
• the type of transaction value in use within your organization: base currency, transaction currency, second
base/reporting currency, fourth currency, and memorandum value.
• the transaction currency code, transaction value, and debit or credit indicator.
• the allocation marker, for example to include transactions that have already been allocated, or that
reference a particular allocation marker.
Note: As an alternative to the selection criteria provided on the Selection Criteria for Account Allocation
form, you can use a control desk to select the transactions for allocation.
When the transactions have been extracted they appear on the Search Results - Account Allocation form.
You can sort the transactions to display them in a different sequence.
You can display the total of the selected transactions in each of the currencies available.
Provisional Postings
Account Allocations can display provisional transactions as well as permanent transactions. Provisional
transactions are identified as such in the Transaction Status field.
What Transaction Details can be Amended Using Account Allocation?

You can use Account Allocations (ACA) to amend some of the non financial information held on a transaction,
after the transaction has been posted to an account.
This allows you to correct mistakes, for example to amend an incorrect analysis code, to enter missing analysis
codes, or to amend the transaction description.
Account Allocations also allows you to alter payment term details to change the payment due date, or
discount date and discount percentage.
What Transaction Details Can I Change?

You can amend any of the following details:
• Transaction description
• Allocation marker
• Ledger transaction analysis codes
• Payment terms code
• Due date
• Discount 1 date and percentage
• Discount 2 date and percentage
• Interest date and percentage
• Late payment date and percentage
• First document details - date, prefix/number and document number
• Second document details - date, prefix/number and document number
• Payment reference
• Bank code
The transaction details you can amend are displayed in highlighted columns on the Search Results - Account
Allocation form.
Note: You cannot amend the payment related fields of discount, interest, late payment or payment terms on
closed transactions. That is, those with an allocation marker of Correction, Reconciliation, Allocated or
Paid.
Note: You can only amend the analysis codes for an analysis dimension if the Amend in Account Allocation
option is set in Analysis Dimensions (AND).
Note: If you update the payment terms code, you are warned that this alters the due date and discount details
on the transaction.
Changing the Allocation Marker on Individual Transactions

You can change the allocation marker to change the status of the transaction or request particular processing.
For example, you could set the marker to Force to include the transaction in the next payment run, or set it
to Withhold to stop it being selected for payment. You can also change an allocation marker to spaces to
'de-allocate' or 'unpay' a transaction. See 'Updating the Allocation Markers Manually'.
Some allocation markers can only be set on a group of balancing transactions. See 'Which Allocation Markers
Must Balance?'
See 'What Allocation Markers are Available?' for a complete list of the markers and details of how they can
be amended.
Changing the Allocation Marker on Several Transactions

You can use the Action All option to change the Allocation Marker from one code to another, on all of the
appropriate transactions. The system looks for all of the extracted transactions that reference the from marker
and changes the marker to the To marker you have chosen. For example, you may want to change the marker
from Withhold to Not Allocated.
See 'Changing the Allocation Marker on a Group of Transactions' and 'Changing the Allocation Marker on a
Range of Transactions in Account Allocation'.
Changing Provisional Postings

If provisional postings are mandatory, you cannot amend the following transaction details on permanent
postings: entry date, description, and the ledger transaction analysis codes for the Transactions Sequence
Dimension, Daybook Sequence Dimension and Tax Code. See 'Amending Provisional Postings'.
How is Settlement Discount Treated During Allocation?

Account Allocations (ACA), and online allocation as part of the ledger entry process, can automatically
calculate and apply any settlement discount due on the transactions marked for allocation against a single
cash payment on debtor/receivables, creditor/payables or client accounts.
Note: The matching processes will not calculate discount if Write On/Write Off Balancing is enabled in
Business Unit Setup. This feature turns off the automatic discount calculations.
If, when you choose to post or save allocations the allocations do not balance, the posting process calculates
the discount available and includes this in the allocation balancing.
If the allocations still do not balance it checks the discount tolerances. If the remaining out-of-balance amount
is within the discount tolerances, the difference is allowed as additional discount.
If not, the system allows you to decide how to proceed. If the transactions are eligible for discount it allows
you to apply the out-of-balance amount as discount. Alternatively, it allows you to generate and post an
additional, balancing transaction. You can also choose to alter the allocations, for example you might want
to split a transaction.
Note: If tax is to be calculated on settlement discount, this is also calculated at this stage.
Calculating the Discount

The system reviews all of the invoice and credit note transactions selected for allocation. It uses the transaction
payment term details to determine whether discount is allowed, and if so to calculate the discount. In particular
it uses the two discount due dates and discount percentages.
The discount is only calculated automatically when allocating against a single cash payment because it uses
the cash payment date to determine whether or not the discount has been earned.
Note: The payment terms code assigned to the customer or supplier account is displayed in the Account
Details tab on the Search Results - Account Allocation form, depending on the version of this form you are
using. The two discount term days and discount percentages are identified.
The total discount allowed is then compared to the allocation out-of-balance amount. If this discount amount
balances the allocations, the discount journal and the allocations are posted automatically.
If the total available discount is greater than the out-of-balance amount, the discount for each transaction
is reduced on a pro rata basis to achieve a balance. The discount journal and the allocations are posted
automatically.
Reviewing the Discount Tolerances

If, after including the amount of discount allowed, the allocations still do not balance, any discount tolerances
are applied. Discount tolerances are defined in Journal Type (JNT) and can be defined as a percentage
difference and/or a tolerance amount. These tolerances are applied to the difference between the calculated
discount and the amount of discount that appears to have been taken, which is the matching out-of-balance
amount.
If the out-of-balance amount is within the discount tolerance amount or percentage, it is allowed as additional
discount. The discount journal and the allocations are posted automatically.
Manually Applying the Discount

If after applying the discount and the discount tolerances, the available discount is less than is required to
balance the allocations, the matching process does not post the discount journal or the allocations. Instead,
it allows you to choose whether to apply the entire out-of-balance amount as discount, or to balance the
allocations in some other way.
Generating the Discount Transactions

The matching process posts the discount to either the input or output discount account identified in Journal
Type (JNT), depending on whether the discount is on sales or purchase transactions. If the discount account
has not been defined, it prompts you to enter the account code.
Note: If a discount budget is going to be exceeded, you are warned.
Balancing the Allocations

Account Allocations (ACA), and online allocation, ensure that only balanced allocations are posted. These
matching functions apply different balancing rules depending on whether you are allocating in the base or
transaction currency. They also use the currency balancing rules that have been set for the business unit
using Business Unit Setup.
Any matching imbalance is treated as possible discount, unless the Write On/Off Balancing option is enabled
for the business unit.
The business setup balancing rule for a currency determines whether or not the currency values in a journal
must balance and whether the balancing is done automatically by the system or manually by the user. If the
balancing can be done automatically, the business unit setup also contains a rounding threshold that restricts
the amount that can be posted as a balancing adjustment, and identifies the accounts to which the adjustment
can be posted.
These balancing rules determine whether or not a realized exchange difference, or rounding adjustment,
posting is generated and posted automatically to balance the allocations.
Different balancing rules apply in the following environments:
• A single currency environment
• A multi-currency environment.
Note: SunSystems includes a Balance Override function that can be used to post 'unbalanced' allocations.
This function is not available from any of the forms delivered with SunSystems and must be added to a form
via Form Designer (FRD) prior to use. It must be used with appropriate caution and access restrictions.
Balancing Allocations in a Single Currency Environment

In a single currency environment, the allocations must balance in the base currency. There are two base
currency balancing options available for a business unit: Manual or Automatic. This is determined by the Base
Currency Amount Balancing setting in Business Unit Setup.
Manual Balancing
If the Base Currency Amount Balancing setting is Manual, the total debit and credit allocations in the base
currency must balance before the allocations can be posted.
The system attempts to balance the allocations by treating the imbalance as either discount or a write on/off,
depending on whether or not the Write On/Off Balancing feature is enabled.
If the allocations still do not balance because the difference is outside the discount or write on/off tolerances,
you must adjust the allocations manually, or generate and post an additional transaction to balance the
allocations before they are posted.
Automatic Balancing
If the Base Currency Amount Balancing setting is Automatic, the system calculates and posts any discount
allowed or allowable write on/off values.
It then automatically posts a balancing adjustment to balance the allocations, providing the balancing
adjustment value is within the Value 1 Rounding Threshold identified in Business Unit Setup. If the balancing
value is greater than the threshold amount, you must balance the allocations manually.
Balancing Allocations in a Multi-Currency Environment

In a multi-currency environment, you can choose to balance the allocations in any of the currencies that are
valid balancing alternatives. When you post or save the allocations, you must select the Post By currency to
balance by. Typically this is either the base or transaction currency values.
The allocations must balance in the chosen balancing currency before you can post the allocations, regardless
of the balancing rule set for this currency in Business Unit Setup.
Note: This means that if you choose to save the allocations in the transaction currency, the allocations must
balance in that currency before you can post the allocations, even if the Other Currency Amount Balancing
setting in Business Unit Setup is set to None.
The system will attempt to balance the allocations automatically in the balancing currency by treating the
difference as either discount or a write off, depending on whether or not the Write On/Off Balancing feature
is enabled. If the allocations still do not balance because the imbalance is outside of the discount or write
on/write off thresholds, you must balance the allocation manually in this currency.
Once the balancing currency values balance, the Business Unit Setup balancing rules defined for the remaining
currencies in Business Unit Setup are applied.
It begins by checking the non-balancing currency values, that is all of the other variable transaction currencies
in use. For example, if you chose to balance the allocations in the transaction currency it then checks the
base currency values, and fourth currency values if they are in use. If these currency values do not balance,
it applies the balancing rules. Based on the rules it either generates a balancing posting in the appropriate
currency automatically, or forces you to balance the allocations in each currency manually.
Finally, it checks that the fixed currency values balance, that is the second base or reporting currency values,
if they are being used. The balancing rules that apply depend on whether these values are being used as
second base or reporting currency. This also determines whether any automatic posting reflects a currency
exchange difference or a rounding difference.
Balancing in the Base Currency

If you choose to save the allocations in the base currency, the base currency values must balance before the
allocations can be posted. You are forced to balance the allocations manually in the base currency, even if
the Base Currency Amount Balancing setting in Business Unit Setup is set to Automatic.
Once the base currency allocation totals balance the system checks the transaction currency values balance.
If these values balance, the second base/reporting currency values are checked and the allocations are posted.
If the transaction currency values do not balance, the Other Currency Amount Balancing field setting for
the business unit determines how the imbalance is treated.
If the Other Currency Amount Balancing field for the business unit is set to None, the transaction amount
allocation totals are ignored because they do not need to balance.
If the Other Currency Amount Balancing field for the business unit is set to Manual, you must manually
balance the transaction currency values in the journal.
Balancing in the Transaction Currency

If you choose to save the allocations in the transaction currency, the transaction currency values on the
allocated transactions must match before the allocations can be posted.
Note: In this case you must only have allocated transactions with the same transaction currency.
Once the transaction currency allocation totals balance the system checks the allocation totals in the other
currencies. It checks the base currency and fourth currency totals before the second base/reporting currency
totals.
If the base currency allocation totals do not balance, the difference is generated as the realized exchange
difference, regardless of the option set in the Base Currency Amount Balancing field in Business Unit Setup.
This means that there is no tolerance limit on balancing postings that can be made, when manual balancing
has been requested for base currency.
Balancing in the Fourth Currency

You can only choose to save the allocations in the fourth currency if this currency is in use for the business
unit. The fourth currency can be used as a fixed or variable currency.
If you choose to save the allocations in the fourth currency, the fourth currency values on the allocated
transactions must match before the allocations can be posted.
Note: If the fourth currency is defined as a variable currency for the business unit, you must only have allocated
transactions with the same fourth currency.
Once the fourth currency allocation totals balance the system checks the allocation totals in the other
currencies. It checks the base currency and transaction currency totals before the second base/reporting
currency totals.
If the base currency allocation totals do not balance, the difference is typically the realized exchange difference.
How this difference is treated depends on the Base Currency Amount Balancing rule for the business unit.
If the Base Currency Amount Balancing field for the business unit is set to Automatic, and the difference is
within the automatic balancing threshold, the system automatically posts the difference to the realized
exchange gain or loss account. If the Base Currency Amount Balancing field for the business unit is set to
Manual, you are forced to manually balance the allocations in this currency.
Balancing the Second Base/Reporting Currency

You cannot choose to save, and thus balance, the allocations using the second base/reporting currency.
However, once the base and transaction currencies balance for the allocations, the system checks the second
base/reporting currency values, if Value 3 is being used.
If these values balance, the allocations are posted.
If these values do not balance, the difference is treated in different ways depending on whether Value 3 is
being used as a second base currency or a reporting currency, and on the Value 3 Cur Amount Balancing
rule.
If the Value 3 Cur Amount Balancing setting for the business unit is set to Automatic, the difference is posted
automatically. If Value 3 is a second base currency, the difference is posted as a rounding difference to the
balancing account identified on Business Unit Setup. If Value 3 is a reporting currency, the difference is
posted as an exchange difference to the realized gain or loss for the currency.
Writing Off Matching Imbalances

The Write On/Write Off feature provides an alternative method of dealing with imbalances in the matching
functions of Account Allocations, On-line Allocation and Transaction Matching. This feature is enabled or
disabled in Business Unit Setup.
If this feature is enabled any matching imbalance is treated as an amount to be written on or off, rather than
considered as possible discount. Any difference in the amounts in the matching currency is treated as a
write-on/write-off, regardless of which currency has been chosen as the matching currency.
Providing the amount of the imbalance is within the tolerance set in the Business Unit Setup, the difference
is automatically posted to either the Write On Account or Write Off/Net Account, depending on the sign of
the difference. These write off accounts are also identified in the Business Unit Setup and if you do not specify
a Write On account, any difference is always posted to the Write Off/Net account.
The Write On/Write Off Tolerance value is defined for the business unit in the base currency. If the matching
currency is not the base currency, the amount of the imbalance is first converted into the base currency and
then compared against the tolerance.
Once this write-on/write-off posting has been made for the imbalance in the matching currency, the allocation
may still be out of balance in the other currencies. This is caused by fluctuations in the exchange rates and
these differences are treated as exchange differences in the normal way.
Matching on the Fourth Currency

If the allocations are being matched on the fourth currency values and these values do not balance, the
difference is converted into the other currency values using the exchange rates that exist on the cash
transaction. If more than one cash posting has been allocated, an average exchange rate is calculated from
the rates on all of the cash postings. If a cash posting has not been allocated as part of the allocation set, an
error message appears.
The cash transaction is identified by the posting journal type set on each transaction from the journal type.
Note: Authorization may be required to post a write on/off amount that is greater than the tolerance, or if
the exchange rate on the cash posting is out of tolerance.
Using Account Allocation

Account Allocations (ACA) is used primarily to match transactions on an account. You can also use it to:
• amend transaction details.
• control the sequence in which unallocated transactions are displayed for allocation
• find individual transactions in a list of unallocated transactions that are displayed.
A Quick Guide to Allocating Transactions After Posting

Use Account Allocations (ACA) to match selected transactions that have already been posted to an account.
For example, you can use it to match a payment transaction to the transactions it has paid. You can also use
it to amend selected transaction details.
Note: You can select the allocations for matching using a control desk. This replaces the first 3 steps below.
Carry out the following steps to allocate transactions:
1 From SunSystems select Account Allocations (ACA).
Note: There may be many different account allocation menu commands, each of which is a tailored
version of Account Allocations.
The Selection Criteria for Account Allocation form is displayed.
2 Specify the allocation batch selection details.
3 Click Extract to select the transactions that meet the selection criteria.
4 If there are several allocation forms available, then Find Form List is displayed and you must select the
form you require.
5 The Account Allocations form is displayed, listing all of the transactions selected for allocation.
6 If you wish to match transactions, you must set the appropriate allocation marker on the transactions
to be matched. You can:
a Fully match selected transactions.
b Split and partially match a transaction.
You can enter the first letter of the allocation marker you require to set it. For example, you can enter T
You can view the allocation totals to check that the allocations balance.
7 If you wish to amend selected transaction details, you can use this form to:
a Amend a transaction's details.
b Amend the allocation marker on all selected transactions, or on a selected range of transactions.
This option can be used to fully allocate a number of transactions at once.
8 To enter additional text, from the Action menu select Standard Text.
9 When you have made all of the required allocations and amendments, select the relevant Post By currency.
The posting process may calculate and apply discount, write on or write off an imbalance, or post a gain
or loss exchange difference journal to balance the allocations.
Extracting the transactions for allocation

When you select Account Allocations (ACA), the Selection Criteria for Account Allocation form is displayed to
allow you to select the account transactions you want to allocate.
Note: Transactions can be marked for allocation in Ledger Entry (LEN) by setting the Allocation Marker field
in Journal Types (JNT). If this is the case and the journal has not been posted, these transactions are not
available to Account Allocation.
Transactions can be selected for allocation using a control desk as an alternative to using this form.
The following steps are required to select transactions for allocation:
1 Select Account Allocation (ACA) from the main menu in SunSystems.
2 From the Selection Criteria for Account Allocation form, identify the account for which you want to
allocate transactions.
3 Enter any additional selection criteria required to narrow down the transactions that are extracted from
this account for possible matching.
4 From the Action menu, select Accept > Extract to locate the required transactions and present them for
allocation.
5 A dialog appears while the transactions are being extracted and you can press Escape to cancel the
extract, if required.
6 The selected transactions are displayed on the Search Results - Account Allocation form to allow you
to allocate or amend the transactions.
Note: If the account you have chosen for matching is being used by another user, the Allocation in
progress on this account. Retry? message appears. You can click Yes to see whether the account is
now available, or click No to exit and select another account. If you are a user with the appropriate data
access group authorization to be able to clear this lock on the account, an additional dialog appears
asking whether you wish to do so.
Using the Selection Criteria for Account Allocation Form

The Selection Criteria for Account Allocation form is displayed when you select an Account Allocation
form. It is used to select the account transactions you wish to allocate.
The transaction selection criteria is defined on the following tabs on the dialog:
• a General tab which allows you to select transactions based on selected non financial transaction details,
for example accounting period, transaction date, journal type, journal source, or journal number.
• an Amount Range tab which allows you to select transactions based on the financial transaction value
details, for example value type, currency code, transaction value and debit/credit indicator.
• a Transaction Analysis tab which allows you to select transactions according to the transaction analysis
codes.
• a Currency Codes tab which allows you to select transactions for selected transaction currency (value
2) and/or value 4 currencies.
A transaction must meet all of the selection criteria to be presented for allocation.
1 Specify this information on the Selection Criteria for Account Allocation form, within Account
Allocations (ACA), to select the transactions for allocation:
Account Code
The account code for which transactions are to be selected for allocation.
Accounting Period/To/All
The range of accounting periods for which transactions are selected for allocation. If you want to allocate
transactions for all periods, select All. Otherwise, specify the range of accounting periods you require.
You can reduce the number of transactions selected for matching by only selecting those with values
within a selected range, for a particular transaction currency value.
Transaction Date/To/All
The range of transaction dates for which transactions are selected for allocation. If you want to allocate
transactions for all dates, select All. Otherwise, specify the range of accounting dates you require.
Journal Type/To/All
The range of journal types for which transactions are selected for allocation. If you want to allocate
transactions for all journal types, select All. Otherwise, specify the type of journals you require.
Journal Source/To/All
The range of journal source codes for which transactions are selected for allocation. If you want to
allocate transactions for all journal sources, select All. Otherwise, specify the range of journal sources
you require.
Journal Number/To/All
The range of journal numbers for which transactions are selected for allocation. If you want to allocate
transactions for all journal numbers, select All. Otherwise, specify the range of journal numbers you
require.
Transaction Reference/To/All
The range of transaction reference numbers for which transactions are selected for allocation. If you
want to allocate transactions for all transaction references, select All. Otherwise, specify the range of
transaction references you require.
Link Reference 1
The range of Link Reference 1 numbers for which transactions are selected for allocation. If you want
to allocate transactions for all Link 1 references, select All. Otherwise, specify the range of transaction
references you require. If Financials is being used as a broker ledger, this may be used as the Billing Link.
Link Reference 3
The range of Link Reference 3 numbers for which transactions are selected for allocation. If you want
to allocate transactions for all Link 3 references, select All. Otherwise, specify the range of transaction
references you require. If Financials is being used as a broker ledger, this may be used as the Accounting
Link.
Second Reference
The range of Second Reference numbers for which transactions are selected for allocation. If you want
to allocate transactions for all Second References, select All. Otherwise, specify the range of Second
References you require.
Allocation Reference
The range of Allocation Reference numbers for which transactions are selected for allocation. If you
want to allocate transactions for all Allocation References, select All. Otherwise, specify the range of
Allocation References you require.
Entry Date/To/All
The range of entry dates for which transactions are selected for allocation. If you want to allocate
transactions for all dates, select All. Otherwise, specify the range of the dates you require.
Due Date
The range of Due Dates for which transactions are selected for allocation. If you want to allocate
transactions for all dates, select All. Otherwise, specify the range of dates you require.
Allocation Marker
The allocation marker for which transactions are selected for allocation. This defaults to Unallocated
Only but you can select a particular allocation marker, for example, Paid Only or Forced Only.
This is useful if you are using Account Allocations (ACA) to adjust the allocation marker on selected
transactions. For example, you may want to reset the Withhold marker to release transactions for payment.
The following options are available:
• Unallocated Only
• Include All Transactions
• Allocated Only
• Corrections Only
• Paid Only
• Reconciled Only
• 0 Marker - 9 Marker
• Blank Allocation Marker
• Forced Only
• Withheld Only
• Paid Unmatched
Note: Transactions marked as F-Force, W-Withheld, B-Brought Forward and 0-9-Numeric Allocation
Marker are treated as unallocated. Therefore selecting the option Unallocated Only will extract all
transactions with these allocation markers.
Include Revaluations
This determines whether revaluation transactions are selected for allocation. Revaluation transactions
are generated by Ledger Revaluation (LER) to record unrealized exchange gains and losses.
Select Transactions
This determines the type of transactions selected for the report if provisional transactions are allowed.
The following options are available:
• Include All - include all transactions, both provisional and permanent.
• Exclude Provisional - only include permanent postings.
• Provisional Only - only include provisional postings.

Currency Identifier
The type of currency value to be used as the basis for selecting the transactions in the Value field below.
You can choose Base currency (Value 1), Transaction currency (Value 2), Second Base or Reporting
currency (Value 3), Memorandum Value or Currency Value 4. For example, select Transaction Value to
select transactions with the transaction currency values in the selected range.
Value/To/All
The range of transaction values to be selected for allocation. Only transactions with a value for the
chosen currency within this range are selected. Select All to include all values. The Currency Identifier
determines the currency value that is checked.
Credit/Debit Indicator
You can select transactions by either debit or credit indicator. Leave this blank to select debit and credit
transactions.
Dimensions
The analysis dimensions that have been assigned to ledger transactions are listed and you can use any
of these to select transactions for allocation.
Analysis Codes
The range of analysis codes, for the appropriate analysis dimension, to be used to select the transactions.
3 In a multi-currency environment, transactions may have been posted to an account in different transaction
currencies. If this is the case, it may be easier to match these transactions if you only select transactions
entered in a particular currency.
Currency Code/To/All
A valid currency code, or range of codes, for which you want to select transactions for allocation. This
range of currency codes applies to the transaction currency value (value 2). To select transactions with
any value 2 currency, select All.
4th Currency Code/To/All

A valid 4th currency code, or range of codes, for which you want to select transactions for allocation. To
select transactions in any value 4 currency, select All. This option only applies if the 4th currency is
enabled for the business unit as a variable, transaction currency. If you select a 4th currency code range
and a currency code range in the previous field, transactions are only selected if they meet both of these
criteria. For example, you might only wish to select transactions with a Transaction currency of USD and
a 4th Currency code of EUR.
Stopping the Allocation Extract

You can cancel the allocation extract process while it is running by pressing Escape.
Selecting Transactions for Allocation via the Control Desk

Account Allocations (ACA) is used primarily to match transactions on an account. For example, a
debtor/receivables payment transaction can be allocated or matched to the original invoice. It can also be
used to split a transaction into one or more transactions.
You can select the transactions you want to allocate or split and pass them to Account Allocations via a
control desk, instead of running Account Allocations from the SunSystems menu.
The following steps are required to select transactions for matching or splitting from a control desk:
1 Use a control desk filter to extract the transactions you want to match onto the Control Desks In-Tray.
2 In Report Process, select Matching Process or Split Process and click OK.
3 If there are several allocation forms available, the Find Form List appears and you must select the form
you require.
4 The Search Results - Account Allocation form appears listing the transactions selected for allocation
or splitting, for the first account.
Only transactions available for matching are displayed. If you chose transactions on the control desks
in-tray that are paid or already allocated they are not displayed.
Viewing the Transactions Extracted for Allocation

The transactions that are extracted for allocation are displayed in a grid on theSearch Results - Account
Allocation form.
The transactions can be extracted for allocation and displayed on this form in two ways:
• by selectingAccount Allocations (ACA) from SunSystems and selecting the transactions using the
Selection Criteria for Account Allocation form
• by selecting the transactions from a control desk.
The transactions appear in a default sort sequence which you can alter, if required.
The top of this form displays the overall allocation totals. As you allocate transactions, the transaction amounts
are added into the debit or credit total. These can be displayed in each of the transaction currency values.
The form displays all of the details available on a transaction, and some of the account details. Because there
is such a large amount of information, it is displayed on separate tabs on the dialog: Allocation Details,
Account Details, Analysis Details, Extracted Totals and Summary.
Note: There are several different versions of the Account Allocations form available which have been tailored
to particular functions. Some of these forms only display a selection of the transaction details available to
restrict the information you can view or amend and may not include these tabs.
Allocation Details
The Allocation Detailstab displays the transaction details for each transaction extracted for allocation. The
transaction details displayed will depend on the version of the Account Allocations form you are using. For
example, if you are using a tailored matching form it may only display the payment terms because these are
the only fields you are able to change.
The details you can amend are displayed on a white background.
If provisional and permanent postings are being displayed, the posting status of each transaction appears in
Transaction Status.
Account Details
TheAccount Details tab displays selected information for the account, such as the account balance, and for
the payment terms associated with the account. You cannot amend any of this information. It displays the
discount settlement terms and discount percentages, if they have been set in the payment terms.
Analysis Details
The Analysis Details tab identifies the ten analysis dimensions assigned to the account selected for matching.
Note: These are the analysis codes assigned to the ledger account rather than any assigned to the customer
or supplier record.
Extracted Totals
The Extracted Totals tab displays the totals of the transactions selected for allocation, by currency. In a
single currency environment, this is simply the total of all of the transactions in the base currency.
In a multi-currency environment, these default to the totals of the transaction currency values (Value 2), by
currency. For each transaction currency, it displays the totals of the debit and credit transactions entered in
this transaction currency. It also displays the base currency equivalents, the second base / reporting currency
equivalents, and the fourth currency equivalents.
If a fourth currency is being used as a variable transaction currency, you can display the totals for each 4th
currency by clicking List by 4th Currency.
You can redisplay the transaction currency totals by clicking List by Trans Currency.
Summary
The Summary tab displays current year and previous year summary details for those transactions extracted
for allocation. It calculates and displays the total debits and credits by accounting period, for the current and
previous years. It also displays the total debit and credit postings for the current year, the current balance
for the account, and the opening account balance for each year.
These are totals for all of the extracted transactions, regardless of whether or not they are selected for
matching.
Sorting Transactions for Allocation

You can control the sequence in which the unallocated transactions are displayed for allocation. This is
important because it can help to reduce the time it takes for you to identify the matching transactions.
Note: For online allocation using Ledger Entry (LEN), you can predefine the transaction sort sequence in
Journal Types (JNT).
Once the transactions appear in the allocation window, you can alter the default sort sequence using the
Sort option. You can use many of the transaction details to sort the transactions. If a field is not available as
a sort selection, a message appears informing you of this.
1 Click in the column heading of the transaction field you want to use to sequence the transactions. For
example, to sort the transactions by Transaction Reference, click on the Transaction Reference heading.
2 Select Action > Sort Ascending, or click Sort.
Finding Transactions for Allocation

You can find individual transactions within the list of unallocated transactions displayed for allocation. This
is important because it can help to reduce the time it takes you to identify the matching transactions.
1 Click on the column heading of the transaction field you want to use to locate the transaction so that the
entire column is highlighted.
2 Select Action > Find to display the Account Allocation - Selection Criteria for Find dialog.
3 Enter the required selection criteria and click OK.
Note: Selection criteria are case sensitive.
Note: When searching text strings, the entire string must be entered. For example, entering Company
and/or Limited will not retrieve the string Public Limited Company.
Note: If no transactions meet the selection criteria, the transactions are sorted by the selected column
and the first transaction after the selection criteria is highlighted.
Amending Transaction Details using Account Allocation

Account Allocations (ACA), and online allocation as part of Ledger Entry (LEN), allow you to amend some
of the non financial details on a posted transaction. In addition to the allocation marker, it allows you to
amend the transaction description, analysis codes, entry date, due date and other payment term details.
For example, you can change the analysis codes entered on a transaction to correct errors or reanalyze
transactions, or you can amend the payment due date to delay payment of a transaction.
Note: If there is more than one Account Allocationsfunction available on the SunSystems menu, you must
select the one that will enable you to modify the required information.
Note: You can only amend the analysis codes for an analysis dimension if the Amend in Account Allocation
option is set in Analysis Dimensions (AND).
Note: If you update the payment terms code, you are warned that this alters the due date and discount details
on the transaction.
1 Use the Extract facility to identify the transactions you require. You can use the selection criteria to only
select the transactions you wish to amend for the chosen account.
2 Identify the transaction you wish to amend in the transaction list.
3 Enter or select the revised information in the appropriate fields. You can amend more than one field on
a transaction, but can only amend the fields displayed on a white background. For example, to alter the
Due Date enter the new date in the Due Date field.
4 Select Action > Post to save the amendments.
Matching transactions using account allocation

Use Account Allocations (ACA) to match transactions.
Fully Matching Transactions

Account Allocations (ACA), or online allocation as part of Ledger Entry (LEN), can be used to fully match
selected transactions on an account. For example, you can match a cash receipt for a debtor/receivables
account against the invoice and credit note transactions being paid.
If you are using Account Allocation, you must select the transactions you want to match for an account. All
of the selected transactions for the account appear on the Account Allocation form.
Note: If you are using online allocation, the transactions available for matching are selected automatically
and displayed on the Online Allocation form.
You can match any number of transactions together, providing the transaction amounts net to zero.
You might find it easier to find the transactions you require, if you alter the sequence of the transactions.
Note: If SunSystems Financials is being used as a broker ledger, cash posting transactions contain a Value
Date and can only be selected for matching on or after this date. If cash is being matched on a client account,
the true rated flag is set on all of the matched transactions.
When you have allocated the required transactions, post or save the allocations.
Repeat these steps to identify all of the transactions to be allocated. You must allocate at least two transactions
and the total of the allocated transactions must net to zero.
1 Identify a transaction you want to allocate in the transaction list.
2 In the Allocation Marker field, select one of the following allocation markers from the drop down list to
identify the matching status of the transaction, depending on the circumstances:
Allocation marker Description

To Be Allocated to fully allocate the transaction.
Reconciled to indicate that the transaction has been reconciled
Correction to indicate that the transaction is a correction.
3 You can enter the first letter of the allocation marker you require to set it. For example, you can enter T
The Debit or Credit allocation totals at the top of the form are updated with the amount of the allocated
transaction. You can display these totals in a different currency, if required.
These totals are updated after you set the Allocation Marker when you click the mouse.
Note: The transactions marked with some allocation markers must balance independently.
If necessary, use the Allocation Totals command to check the allocations balance.
You may need to partially allocate transactions by splitting them, apply settlement discount or post
exchange difference transactions to balance and post the allocations.
Changing the Allocation Marker on All Transactions in Account Allocation

The Action All option on Account Allocations (ACA) enables you to change the allocation marker on several
transactions at once. It changes the marker from one indicator to another, on all of the extracted transactions
that currently contain the 'from' allocation marker.
For example, you might use Action All to:
• change Unallocated markers to To Be Allocated to allocate all of the unallocated transactions.
• change Withhold markers to spaces to release the transactions for payment.

• change transactions with a 3 Marker to a 4 Marker to indicate the next stage of processing for bills of
exchange.
Note: If you wish to change the marker on a subset of the extracted transactions you may be able to use the
Range Allocation option.
1 Select Extract to identify the transactions you require. You could use the Allocation Marker selection
option to only select transactions with the marker you want to change.
2 Select Action > Action All to display the Account Allocation Allocate All dialog.
3 In From, select an allocation marker. Any transactions extracted for allocation that have this marker are
changed.
4 In To, select the new allocation marker to apply to the chosen transactions.
5 Click OK to find all of the extracted transactions with the From marker, and change the marker to the To
marker chosen.
Changing the Allocation Marker on a Range of Transactions in Account

Allocation
The Range Allocate option in Account Allocations (ACA) enables you to change the allocation marker on a
range of transactions that fulfil criteria you specify.
For example, you might use Range Allocate to:
• release or withhold a group of transactions for payment based on their reference numbers
• allocate a group of transactions for payment, up to a selected total amount.
Note: If you have changed the allocation markers on the wrong transactions, click Cancel to reset the markers
(and reset any other allocations you have made but not posted).
1 Select Extract to identify all the transactions you wish to review on the account.
2 Select Action > Range Allocate to display the Selection Criteria for Range Allocate form.
3 Enter the selection criteria required to identify all of the transactions to which the new allocation marker
applies.
Note: The allocation markers are only changed on the transactions that meet all of the selection criteria
entered.
4 In New Allocation Marker, select the new allocation marker to apply to the chosen transactions.
5 Click OK.
The number of transactions that have been updated is displayed and these transactions appear on the
Search Results - Account Allocation form in a different colour.
Displaying the Allocation Totals by Currency

Account Allocations (ACA), and online allocation as part of Ledger Entry (LEN), only matches transactions
that balance. This means that the total of the debit transactions marked for allocation must equal the total
of the credit transactions marked for allocation. For example, you must allocate the entire value of a payment
received against the corresponding invoice transactions, or split the payment.
To help you balance the transactions you have marked for allocation, the system maintains and displays
useful allocation totals.
It maintains the overall total of all the debit and credit transactions marked for allocation. These allocation
totals are displayed in the top right corner of the allocation form, and are updated automatically as you
allocate transactions. The Out of Balance amount shown must be zero before you can post the allocations.
Note: These totals include the values of any transactions generated for settlement discount and/or exchange
differences.
By default these totals appear in the base currency.
Displaying the Overall Allocation Totals in a Different Currency

To display the overall allocation totals in a different currency, select Action > Totals > Currency Totals and
one of the following commands:
• Base Currency

• Transaction Currency
• Report/Second Base.
The total debit and credit amounts, and any out of balance amount, are displayed in the selected currency.
You can view the allocation totals by allocation marker type using the Allocation Totals command.
Viewing the Allocation Totals

Account Allocations, and online allocation, maintains separate totals for each of the allocation markers you
can set, or unset, that must balance. Select Action > Allocation Totals to view these totals on the Account
Allocation - View Totalsform.
There are two different versions of this dialog available:
• VIEW which only displays the allocation totals
• GENDIS which displays the allocation totals and allows you to post discount amounts or generate
additional postings.
When you select theAllocation Totals command you may be asked to select the appropriate form from the
Find Form List.
The Allocation Totals

Regardless of which version of the Allocation Totals form you choose, it displays the total debits, total credits
and the out-of-balance amount for the transactions marked with each of the allocation markers identified
below. The totals appear on separate tabs and are displayed in the four transaction currencies available.
Allocation View Totals Tab Displays the totals, by currency, of ...

Allocations Transactions marked with To Be Allocated
Reconciliations Transactions marked with Reconciled
Corrections Transactions marked Correction
Paid Transactions marked Paid
The GENDIS Version of Allocation Totals

The GENDIS version of the Allocation Totals form is displayed if the posting process is unable to balance
and post the allocations. It displays an additional Discount tab and includes two commands: Generate using
Ledger Entry and Apply Imbal as a Discount.
It can be used to:
• manually apply the entire allocations imbalance amount as discount.
• generate and post an additional transaction to balance the allocations.
Note: You can only access the commands if the action can be used to balance the allocations.

Applying an Imbalance as Discount During Allocation

If the transactions you have marked for allocation on debtor/receivables, creditor/payables or client accounts
do not initially balance, the difference may be the amount of settlement discount due on the transactions.
When you choose to post or save the allocations and they do not balance, the allocation process calculates
any discount available and uses this to try to balance the allocations.
Note: If the Write On/Write Off Balancing option has been enabled on the Business Unit Setup, the discount
calculations are switched off and the allocation imbalance may be posted to a write off or write on account.
It can only calculate and apply the discount automatically if you are allocating a single cash payment. This
is because it must use the cash payment date to determine whether or not the discount has been earned.
If the transactions were eligible for discount but the discount was not enough to balance the allocations, you
can choose to apply all of the imbalance as discount. This option is provided on the GENDIS version of the
Account Allocation - View Totals form.
This version of the dialog includes a Discount tab that displays useful discount calculation information to
help you determine whether or not the imbalance should be applied as discount.
Note: GENDIS also allows you to generate and post another transaction to the account to balance the
allocations. For example, if the customer has deducted an amount because the goods were damaged in
transit, you may want to enter a credit transaction onto the account.
This form is displayed when you choose to post or save the allocations, if the out-of-balance amount can be
applied as discount.
To display the window at any other time:
1 From the Action menu on theSearch Results - Account Allocation (or Search Results - Ledger Entry -
Online Allocation) form select Allocation Totals.
2 Select the GENDIS form on the Find Form List.
Matching by Transaction Currency

Account Allocations (ACA) allows you to match transactions using the transaction amount rather than the
base currency amount. This is typically required when you have received payment in the transaction currency
and wish to allocate to transactions with the same transaction currency.
To match the payment you should extract the transactions in the normal way. However, you should set the
following Extract selection criteria to only select transactions that reference the appropriate transaction
currency:
• Currency Identifier
Set this to Transaction Value, to only extract transactions that reference the required transaction currency.
• Currency Code/To/All
Set this to the transaction currency code you wish to match on. If the Currency Identifier is set to
Transaction Value, then only transactions with a transaction currency value entered in this currency are
extracted.

Once you have extracted the transactions, you should display the allocation totals in the transaction currency.
To do so, from the Action menu select Currency Totals > Transaction Currency.
You can then allocate the transactions as usual, but based on the transaction currency amounts.
When you post the allocations you must choose to save the allocations in the transaction currency. This
means that the allocations must balance in the transaction currency before you can post them. If these values
do not balance you must manually adjust the allocations to make them balance.
If, once the transaction currency amounts balance, the base currency amounts do not balance, then a gain/loss
transaction may be generated and posted automatically to the specified accounts.
If settlement discount applies, then the conversion rate used on each source transaction is used on any
discount and tax on settlement discount transactions generated.
Posting Exchange Differences During Allocation

If the transactions you have allocated match in one currency but not in the other currencies, the system can
generate a gain/loss posting or rounding difference posting to record this difference and balance the
allocations. For example, if the transaction currency values match on the allocated transactions but the base
currency values do not match, or vice versa, a gain or loss posting may be generated automatically. The same
applies where fourth currency values match on the allocated transactions but the base currency values do
not match, or vice versa, a gain or loss posting may be generated automatically.
Note: The allocation imbalance is only posted automatically in particular circumstances, depending on the
currency balancing rules.
Posting Realized Exchange Differences

A discrepancy between either the base or transaction currency values is posted to the nominated realized
gain, loss or net exchange difference account. The realized exchange difference accounts can be defined for
each currency in Currency Codes (CNC), for particular periods for a currency using Currency Period Rates
(CNP), or for a particular date for a currency using Currency Daily Rates (CND).
You can define separate Realized Gain and Loss accounts and post gains and losses separately. Alternatively,
you can define a single Realized Net or Losses account, to which the net gains and losses are posted.
If both of these accounts are left blank for the currency code and currency period rate, you are prompted to
enter a gain/loss account.
When matching single debits and credits, the analysis codes for the system generated source account and
gain/loss account transactions are taken from the transaction in the matched pair that has the lowest base
value amount. When matching multiple debits and credits, the Manual Ledger Alloc - Analysis Codes form
is displayed for you to enter the required analysis codes for the source account and then the exchange gain/loss
account. The analysis codes available for input on this form are determined by Chart of Accounts (COA) and
Ledger Setup (LES).
Note: For transactions with normal journal types, an optional dimension on the account record means use
the transaction analysis input rules defined for the journal type (as described in 'Setting Up Accounts').
However, since it is impossible to define the analysis requirements on the SYSTM journal type used by Exchange

Gain and Loss processing, a dimension set as Optional on the account record in this context means either
enter a value or leave blank.
If there is a difference between the Value 3 values and Value 3 is used as a Reporting Currency, then the
difference is treated as an exchange difference between either the base or transaction currency, whichever
is the pivot currency.
Posting Rounding Adjustments

If Value 3 is used as a Second Base Currency then the difference is treated as a rounding difference and is
posted to the Value 3 balancing account defined in Business Unit Setup. Again, you can define separate debit
and credit rounding difference account, or a single net rounding difference account. If the account has not
been defined you are prompted to enter it.
Generating Transactions from Account Allocation

Sometimes the imbalance in an account allocation is the result of a missing transaction and you need to post
the transaction to balance the allocations.
You can use the Generate Using Ledger Entry command on theAccount Allocation View Totals dialog to
enter and post the journal. The journal is entered manually using any of the Ledger Entry forms and you can
balance and post the allocations using Ledger Entry - Online Allocation.
1 From the Action menu on the Search Results - Account Allocation form select Generate. This will start
a new Ledger Entry session without closing the Account Allocations session.
2 From the Find Form List select the Ledger Entry form you require, if necessary.
3 Enter and post the journal and exit the Ledger Entry form. You must enter and post a balanced journal
posting the amount of the allocation imbalance to the appropriate debtor, creditor or client account.
4 Return to the Account Allocations session and select Refresh from the Action menu. This action extracts
any new transactions for the account that satisfy the original selection criteria. The transactions appear
at the end of the transaction list.
5 Allocate the appropriate, newly entered transactions to balance the allocation in the normal way.
Splitting transactions
Account Allocations (ACA), and online allocation as part of the Ledger Entry (LEN), can be used to allocate or
match part of a transaction.
This is typically required when you receive an under or over payment for an invoice.
Understanding Transaction splitting

Note: This topic refers to functions that let you match transactions, such as Account Allocations (ACA), and
is not relevant for transaction splitting with the Scheduled Payments functionality.

Account Allocations (ACA), and online allocation as part of the Ledger Entry (LEN), can be used to allocate
or match part of a transaction. This is typically required when you a receive an under or over payment for an
invoice.
Note: You can select the transactions you wish to split from a control desk using the Split Process batch
option on the control desks in-tray.
To match part of a transaction you must split the original transaction into two or more transactions with
different amounts. The total amount of the split transactions must equal the original transaction amount, in
each currency.
The original transaction is either amended, or it is retained unchanged and a correction transaction is generated
to reverse it. This is determined by the Preserve Original Line Values setting in Ledger Setup (LES).
There are several different ways to split a transaction, depending on your requirements:
• Unsigned Split - this is the default split option which splits one transaction into two transactions with
the same debit or credit sign.
• Signed Split - this also splits one transaction into two split transactions but with opposite debit/credit
indicators.
• Multi Split - this allows the original transaction to be split into more than one new transaction, a mixture
of debits and credits if necessary, all of which must total the original transaction value. The transaction
can only be split into the existing currencies referenced on the transaction.
• Currency Split - this split allows the original transaction to be split into more than one new transaction,
and allows the transaction to be split across different transaction currencies (in Value 2 or Value 4).
When you have split a transaction, the new transaction appears immediately above the original transaction
in the allocation transaction list.
Note: The new split transactions are not posted to the ledger until you select the Post action. On posting, if
the original transaction you split was linked to other transactions using Link Reference 2 or a Revaluation
Link, those linked transactions are split in the same proportions automatically.
Preserving the Original Transaction in a Split

The Split facility in Account Allocations (ACA) can be used to split a transaction into one or more new
transactions, totalling the same amount.
The Preserve Original Line Values setting in Ledger Setup (LES) determines whether the transaction you
choose to split, the original transaction, is preserved unchanged, or altered by the split processing.
If the Preserve Original Line Values option is selected, the split transaction processing automatically generates
a offset posting for the full value of the original transaction. The original transaction and its offset are both
assigned the allocation marker of Correction. The split processing also generates two or more new transactions.
The total of these new transactions must equal the original transaction value, in each currency. The new
transactions contain all of the original transaction detail, for example the transaction reference, journal
number, journal type and transaction date.
If the Preserve Original Line Values option is not selected, the original transaction amount is amended and
one or more new split transactions are generated. The total of all these transactions must again equal the
original transaction value.

The new transactions becomes the part of the transaction to be matched and its allocation marker is set to
To Be Allocated automatically. The original transaction identifies the part of the original transaction that
cannot yet be matched. Its allocation marker remains as it was, for example if the transaction you split has
an allocation marker of Force, after the split the unallocated part of the transaction still contains this marker.
Splitting a Transaction into Several Single Currency Transactions

If you select the SINGLE version of the multipart split form, use the following steps to split a transaction.
1 The original amount of the transaction is displayed in the Original Amount field.
2 In the Split Value field, enter a split value and select the appropriate Debit or Credit indicator alongside.
3 In the Description field, enter a description for this split transaction or any other useful information, if
required.
4 Click OK to create the split transaction which appears in the list at the bottom of the form.
The amount that remains to be split appears in the Outstanding field.
5 Repeat steps 3 and 4 to enter each split transaction.
6 If you enter a split value incorrectly, click on the transaction in the list. The transaction details reappear
in the Split Value and Description fields where you can alter them. Then click OK to update them.
7 Click Split Complete to generate the split transactions when you have fully split the original transaction
and the Outstanding field displays zero.
8 Alternatively, click Cancel at any time to abandon the multipart split.
If you cannot complete the split, you can suspend the split details by clicking Hold. This displays the
Hold Multi-Part Split dialog where you enter your reason for the holding the split.
When you complete the split, the new split transactions appear immediately above the original transaction
in the allocation transaction list. The allocation marker is not set of any of the new split transactions.
They all retain the allocation marker of the original transaction. You can set the allocation markers on
these transactions in the normal way, as required.
If the Preserve Original Line Values option is set in Ledger Setup (LES), the original transaction is not
altered. An offset transaction is generated to reverse out the full value of the original transaction. Both
this offset and the original transaction are given allocation markers of Correction. Two new transactions
are generated, one containing the Amount to Allocate value and one containing the Outstanding value
from the split dialog.
Splitting a Transaction into Several Multi Currency Transactions

If you select the MULTI version of the multipart split form, use the following steps to split a transaction.
1 The original amount of the transaction is displayed in the Original Amount fields, in each of the currencies
in use in the business unit.
2 Enter the split transaction value in any of the currencies available to be entered on a transaction and
select the appropriate Debit or Credit indicator for the transaction. The split transaction values in the
remaining currencies are calculated automatically.

You can enter the split value in any of the currencies in use within your business unit. However, you should
use the currency in which you are matching the transactions. The current period currency rate is used
to convert this amount into the other currencies available. Any difference between the original currency
values and the recalculated currency values is posted as currency exchange gain or loss.
3 3. In the Description field, enter a description for this split transaction or any other useful information,
if required.
4 4. Click OK to create the split transaction which appears in the list at the bottom of the form.
The amount that remains to be split appears in Outstanding fields.
5 Repeat steps 3 and 4 to enter each split transaction.
6 5. If you enter a split value incorrectly, click on the transaction in the list. The transaction details reappear
in the transaction entry part of the form where you can alter them. If you want to reset all of the transaction
values to zero, select Reset.
7 Click OK to update the transaction details in the list.
Splitting a Transaction into Two Transactions

There are two transaction split options that allow you to split a single transactions into two separate
transactions:
• the default split option - which splits the original transaction into two transactions with the same debit
or credit sign. For example, you could use it to split a transaction for GBP 100 debit into two transactions,
one for GBP 60 debit and one for GBP 40 debit.
• the signed split option - which splits the original transaction into two transactions with opposite signs,
that is it allows you to set the debit and credit indicator on the split transaction. For example, you could
use this it to split a transaction for GBP 100 debit into two transactions, one for GBP 20 credit and one
for GBP 120 debit.
Both of these options automatically selects the new split transaction for matching by setting the allocation
marker to To Be Allocated, and leaves the allocation marker on the other transaction unchanged.
To split a transaction into two transactions:

1 Identify the transaction to be split in the allocation transaction list.
2 To split into two transactions with different signs (credit and debit), select Action > Signed Split.
3 The Simple Split form is displayed. The original amount of the transaction is displayed in the Original
Amount fields, by currency.
4 In Outstanding Description, enter a reason for the split or any other useful information.
5 If you chose a Signed Split, you can set the Debit or Credit indicator for the new split transaction alongside
the Amount to Allocate.
Note: In a multi-currency environment, you can enter the amount to be allocated in any of the currencies in
use within your business unit. You should use the currency in which you are matching the transactions. The
current period currency rate is used to convert this amount into the other currencies available. Any difference
between the original currency values and the recalculated currency values is posted as currency exchange
gain or loss.

• The difference between the original transaction amount and the amount to be allocated appears in the
Outstanding field. This is the amount of the transaction that remains unallocated and retains the
allocation marker from the original transaction.
• Click OK to split the transaction, or click Cancel to abandon these details.
When you have split the transaction, the new transaction (or transactions) appear immediately above the
original transaction in the allocation transaction list.
The transaction containing the Amount to Allocate value has an allocation marker of To Be Allocated. This
amount is also added to the debit or credit balance totals at the top of the form which identify the total
amounts allocated.
The original transaction contains the outstanding, unallocated amount and retains its original allocation
marker.
Note: If the Preserve Original Line Values option is set in Ledger Setup (LES), the original transaction is
not altered. An offset transaction is generated to reverse out the full value of the original transaction. Both
this offset and the original transaction are given allocation markers of Correction. Two new transactions are
generated, one containing the Amount to Allocate value and one containing the Outstanding value from
the split dialog.
Splitting a Transaction into Multiple Transactions

The Multipart Split option in Account Allocations (ACA) allows you to split a single transaction into several
new transactions, providing the total of these split transactions equals the original transaction value. The
split transactions can include a mixture of debit and credit transactions.
You might use this option if you need to re-analyze the original transaction across several different analysis
codes, or if an original invoice is now being paid in several different instalments.
Note: Multipart Split does not set the allocation marker of any of the split transactions automatically.
There are two different versions of the multipart split function available:
Note:
• SINGLE which is used in a single currency environment to split the original transaction into several
transactions in the same currency
• MULTI which is used in a multi-currency environment to split the original transaction into several different
transactions using the same currencies as the original transaction.
If you need to introduce a new currency onto a split transaction, you must use the Currency Split option.
Therefore, when you select the Multi Split action, you may be asked to select the appropriate form from the
Find Form List.
The MULTI version of the Split form includes more fields. The form is divided into three sections:
• the totals section at the top displays the original transaction value and maintains a running total in the
Outstanding field of the split transactions as you enter them. The split cannot be complete until the
outstanding value is zero.
• the middle section is where you enter the value for each new split transaction, one at a time.
• the bottom section lists the split transactions you have defined.

Selecting the Multi Split Option:

2 Select Action > Multi Split.
3 If the Find Form List appears, select either SINGLE or MULTI depending on your currency environment.
4 Either the single currency or multi-currency versions on the Manual Ledger Allocation Multipart Split
form is displayed.
Adding a New Currency in a Transaction Split

The Currency Split option in Account Allocations (ACA) allows you to split a single transaction into several
new transactions, referencing different transaction currencies. You can only split the variable currencies, that
is the transaction currency value (value 2) and fourth currency value (if it is in use as a variable transaction
currency for the business unit). The system generates balancing transactions in each transaction currency
to balance the transaction currency values, if required.
For example, this feature would allow you to split an original transaction with a transaction currency in USD
and base currency of GBP, into two transactions: one with a transaction value in USD and the other with a
transaction value in EUR. The base currency equivalents of each new transaction must total the base currency
value of the original transaction. Two currency balancing transactions are also generated, one with a USD
transaction currency value only and the other with a EUR transaction currency value to balance the transaction
currencies.
Note: If you wish to split the existing currency values on a transaction, without introducing a new currency
value or altering any of the currencies, use the Multipart Split - MULTI option.
To perform a currency split:
2 Choose Action > Currency Split to display the Account Allocation Split Transactions dialog.
Note: The same dialog appears for a multipart transaction split if you choose the MULTI version on the
Find Form List but the form operates in a slightly different way.
3 The original amount of the transaction is displayed in the Original Amount fields, in each of the currencies
in use in the business unit.
4 Select the fourth currency code for the split transaction, if required, and click OK. All of the split
transactions will reference this fourth currency code.
5 Enter the split currency transaction details. You can enter a revised base currency amount, transaction
or fourth currency amount and/or currency, and memo value as required.
6 In Description, enter a description for this split transaction or any other useful information.
7 Click OK to create the split transaction which appears in the list at the bottom of the form.
The amount that remains to be split appears in the Outstanding fields at the top of the form.
8 Repeat steps 5 to 7 to enter the remaining split transactions.
9 If you enter a split value incorrectly, click on the transaction in the list. The transaction details reappear
in the transaction entry part of the form where you can alter them. If you want to reset all of the transaction
values to zero, select Reset.
Click OK to update the transaction details in the list.

10 Click Split Complete to generate the split transactions when you have fully split the original transaction
and the Outstanding field displays zero.
Alternatively, click Cancel at any time to abandon the currency split.
Note: If you cannot complete the split, you can suspend the split details by clicking Hold. This displays
the Hold Multi-Part Split form, where you enter your reason for the holding the split.
When you complete the split, the new split transactions appear immediately above the original transaction
in the allocation transaction list. The allocation marker is not set of any of the new split transactions. They
all retain the allocation marker of the original transaction. You can set the allocation markers on these
transactions in the normal way, as required.
Holding Split Transactions

If you cannot complete a multipart transaction split, you can suspend the split by placing it on hold. This
enables you to return to it at a later time to complete it.
You hold a multipart transaction split by selecting the Hold option on theAllocation Multipart Split form.
When you click Hold, the Hold Multi-Part Split form is displayed. You should enter the reason for holding
the split and click OK.
The system generates a journal that contains the split transaction details, assigns it a unique journal reference
number and a journal type of SPLIT.
The original transaction that was being split is given a status of Allocation in Progress. This prevents it from
being allocated until the split transactions in the held journal are either completed, or deleted at which point
this status is reset.
The following details are added to the original transaction:
• a Split in Progress flag is set
• the Split By User Id is set to the operator Id of the person who held the split
• theHeld Journal Number that contains the split transactions.
Note: These details can be added to user defined inquiry screens or reports if required.
To complete the multipart split, you must select the held journal using Ledger Entry Held Journals (LEH)
to return to the multipart split form. You can enter additional split transactions or amend the existing split
transactions to complete the multipart split in the normal way.
When you select the Split Complete option the Search Results - Account Allocation form is displayed. It
shows the original transaction and the split transactions. The Allocation in Progress status is removed from
the original transaction.
Note: In some exceptional circumstances this status may not be reset correctly, for example as a result of
computer failure. In this case a user with the appropriate data access group authorization can use the Clear
Allocation in Prog action to reset this status for a transaction.
You must select Post to post the generated split transactions and remove the held journal details.

Multi-Part Multi-Currency Split Example

Consider the following transaction that only contains a fourth currency value of 100 GBP.:
Tx Type V2 Amount V4 Amount Allocation Marker

Original GBP 100 CR
It is split into four transactions with different transaction currencies. Balancing transactions are generated
to balance the transaction currency on each of the new split transactions.
In addition, the original posting is retained and an offset is posted for this, both of which are marked as
Correction transactions.
Tx Type V2 Amount V4 Amount Debit/Credit Allocation

Marker
Original posting 100 GBP CR Correction
Split line 120 USD 60 GBP CR
Split line 80 USD 40 GBP CR
Split line 500 JPY 50 GBP CR
Split line 400 HKD 50 GBP DR
Balancing line 120 USD DR

Balancing line 80 USD DR
Balancing line 500 JPY DR
Balancing line 400 HKD CR
Correction Offset Posting 100 GBP DR Correction
Posting Allocations
When you have allocated the required transactions, you should post or save the allocations.
To post allocations, in a multi-currency environment you must choose the balancing currency. You can either
select the appropriate option from Action > Post, or click the appropriate Post By currency option. The Post
options are:
• Post By Base - post the allocations, balance by base currency
• Post By Transaction - post the allocations, balance by transaction currency
• Post By Fourth Currency - post the allocations, balance by the fourth currency.
Note: If you are using Online Allocation to match transactions during Ledger Entry (LEN), you must select
Save rather than Post. The allocations and generated transactions are posted when the journal itself is posted.

If the allocations do not balance, the posting process attempts to balance the allocations by calculating and
applying settlement discount or writing on or off the imbalance, and posting exchange gains or losses.
When the allocations are correct and in balance, the posting process performs the following tasks:
• It updates the allocation markers on the allocated transactions.
• It changes any other fields that you have amended, for example if you have changed the due date or an
analysis code.
• It posts any settlement discount, and settlement discount tax, transactions generated
• It posts any write on or write off transactions generated
• It posts any realized exchange gain/loss transactions generated
• It assigns the next allocation reference and the latest allocation date and period to the allocated
transactions.
If the account is not available, you are prompted to enter it on the Allocation Different Account Entrydialog.
If the Provisional Postings field in Ledger Setup (LES) is set to Optional, you can choose to post the new
transactions as provisional or permanent postings.
Choosing the Allocations Balancing Currency

In a multi-currency environment, when you save or post allocations, you must choose the balancing currency
to be used to balance the allocations. The matched transactions must balance in the currency you select to
post by or save by.
If you are using Account Allocations (ACA), use the appropriate Post action:
• Post By Base - post the allocations balancing by the base currency. Using this option, any currency
• Post By Transaction - post the allocations balancing by the transaction currency. Using this option, any
currency exchange differences are calculated on the base amount, and on the Value 4 amount if you are
using fourth currency.
• Post By Fourth Currency - post the allocations balancing by the fourth currency. Using this option, any
currency exchange differences are calculated on the base amount and on the transaction currency
amount.
If you are using Online Allocation to match transactions during Ledger Entry (LEN), use the appropriate
Save action. The allocations and generated transactions are posted when the journal itself is posted. The
following Save actions are possible:
• Save By Base - save the allocations balancing by the base currency. Using this option, any currency
• Save By Transaction - save the allocations balancing by the transaction currency. Using this option, any
currency exchange differences are calculated on the base amount, and on the Value 4 amount if you are
using fourth currency.
• Save By Fourth Currency - save the allocations balancing by the fourth currency. Using this option, any
currency exchange differences are calculated on the base amount and on the transaction currency
amount.

Identifying the Allocation Difference Posting Account

The Allocation Difference Account Entry dialog prompts you to enter a missing chart of account code as
part of the Account Allocation posting process. The dialog only appears if the allocation process needs to
post either a discount amount or exchange gain or loss, and does not have the required account.
You may be prompted to enter one of the following account codes:
• Input Discount Account
• Output Discount Account
• Realized Net Gain Account
• Realized Exchange Loss Account
Transaction Matching
If you want to allocate transactions on an account without entering any transactions to the ledger, you can
use Transaction Matching (TRM). This automates the allocation process within the criteria you specify.
Transaction Matching is similar to Account Allocations (ACA) and the online allocation function in Ledger
Entry. It allows you to allocate or match transactions. However, Transaction Matching goes a step further
by enabling you to automate the allocation/matching process.
An account type and range of account codes are entered, and depending on other criteria specified, matching
debit and credit transactions on an account are selected and matched. During the matching process, settlement
discount, tax on settlement discount, and currency exchange gain and loss transactions, can be generated.
Note: If the Allocations Locking Allowed option on Business Unit Setup is set to lock at transaction level,
any transactions that are locked by another user will not be matched. If these transactions were eligible for
matching they are identified on the matching report.
Selecting Transaction and Matching Criteria

You can select transactions for matching by transaction analysis code, currency code, transaction reference,
and allocation marker.
You can also choose up to three match criteria. The same options are available as for selecting transactions.
If you specify three match criteria, all three transaction values must be the same for the transactions to match.
Note: You cannot match transactions purely on amount; you must enter some additional sort of
selection/matching criterion.
Discounting
If you are matching debtor/receivables, creditor/payables, or client accounts, Transaction Matching generates
any settlement discount and tax on settlement discount postings for you. You can specify the account to
which discounts must be posted and discount tolerance limits. If the discount falls outside the tolerance limit,
the transactions are not matched.

Matching Currency Transactions

You can match transactions using either the base currency amount or the transaction currency amount. You
can also choose to match on the memorandum amount.
If you want to match on the transaction currency amounts, you must enter currency code as one of your
match criteria. When you match by transaction currency amount, currency gains or losses may be generated.
Posting and Reporting Transactions

You can choose to post the allocations or simply to report on the allocations. If you choose to post, the
allocated transactions are assigned account specific allocation references.
You can choose to report on any transactions that fall within your selection criteria but remain unmatched
after running Transaction Matching. You can report on all unmatched transactions, unmatched debits,
unmatched credits, or you can specify that no report is required. Additionally you can produce a report of
your matched transactions.
Selecting Accounts and Transactions for Matching

Transaction Matching (TRM) uses match criteria to try to match transactions automatically. You can determine
the accounts and transactions to be considered for matching.
To select the transactions for matching you must first identify the accounts you wish to process. You can
select the accounts by account type and/or account range.
Selecting the Account Type

You can only choose one account type per run. This can be either debtor, creditor, client, profit and loss,
memo, or balance sheet.
If you choose client accounts and you are posting discounts, the system ensures that the larger value is an
invoice and the smaller value a payment. Discount percentages and tolerances are applied to try and match
the transactions.
For debtor accounts, no match is made if a credit value is larger than a debit value. For creditor accounts, no
match is made if a debit value is larger than a credit value.
Selecting the Accounts

You can select a range of account codes within your chosen account type. For example, you may only want
to match transactions for a group of debtors or creditors. Closed and suspended account codes are excluded
from Transaction Matching.
Selecting the Transactions

Within the account type and account range specifications, you can choose up to three additional selection
criteria to restrict the transactions selected for matching, for the accounts.

You must choose at least one selection criterion. A transaction must meet all of the selection criteria to be
considered for matching.
The following selection options are available:
• Currency code
• Transaction reference
• Allocation marker
• Ledger transaction analysis dimension codes 1 to 10
• Link Reference 1 (Billing Link)
• Link Reference 3 (Accounting Link)
• Signing Details
• Posting Reference
• General Description 1 to 25 (Additional Fields)
• General Date 1 to 5 (Additional Fields)
A cutoff period can also be defined, beyond which transactions are not selected.
Defining the Transaction Matching Criteria

Transaction Matching (TRM) allocates transactions automatically by matching selected fields on the
transactions for an account. For each account, Transaction Matching matches together any debit and credit
transactions with the same values.
Note: Zero value transactions can also be matched.
Selecting the Matching Criteria

You can enter up to three additional matching criteria, and Transaction Matching ensures that the transaction
values for these fields are also the same before the transactions are matched. For example, you might want
to ensure the same transaction reference is included on the transactions.
The optional matching criteria fields are:
• Ledger transaction analysis dimension codes 1 to 10
• Currency code
• Transaction reference
• Allocation marker.
For example, if you select ledger analysis code 1, ledger analysis code 2 and currency code as the matching
criteria then, in order to match, the debit and credit transactions must have the same:
• Analysis code values in the first two analysis code fields
• Transaction currency code
• Values.
Discount percentages and tolerances can be allowed to try and match transactions where the values are
slightly different.

Tax Analysis Dimension

If you are generating settlement discount, the system can calculate the tax portion of the discount amount
and post this automatically. In this case, the tax analysis dimension set in Ledger Setup (LES) must be one
of your match criteria.
Applying Discounts in Transaction Matching

Transaction Matching generates settlement discounts in accordance with the settlement terms for an
account. Discounts can be generated for debtor/receivables, creditor/payables and client accounts.
If the transactions on an account match in all other respects but the values are out of balance, Transaction
Matching checks to see if the difference is due to discount. It uses the discount terms for the transaction to
calculate the amount of discount due and checks this against the matching out-of-balance amount. If the
difference is the same as the discount amount, or within the tolerances set for the run, a discount transaction
is generated which balances the transactions.
Input and output discount accounts are identified for the transaction matching run. The input discount
account code is used to post the settlement discount received on creditor/payables accounts or on purchase
transactions on client accounts. The output discount account code is used to post the settlement discount
allowed on debtor/receivables accounts or sales transactions on client accounts. These discount accounts
are not required if you are matching profit and loss, memo, or balance sheet accounts, as settlement discount
is not appropriate to these account types.
If you select client accounts and you are posting discounts, the system also ensures that the larger value is
an invoice and the smaller value a payment. For debtor accounts, no match is made if a credit value is larger
than a debit value. For creditor accounts, no match is made if a debit value is larger than a credit value.
Discount Tolerance
You can enter a discount tolerance amount or percentage in the matching process. If no discount tolerance
is allowed, then the difference between the transaction values must match the discount due according to
the settlement terms exactly, before the allocation proceeds. This could lead to an allocation being rejected
because of a trivial discrepancy between the actual and specified settlement discount.
When the matching process identifies an unbalanced allocation, it first checks the due dates and discount
due dates for the transaction, to ensure that the payment falls within the discount terms. It then calculates
the discount available. If the net of settlement discount amount for the invoice transaction does not match
the receipt, then the discount tolerance is examined. The actual receipt value is added to the expected discount
amount and compared to the invoice amount. If the difference between the two falls within the discount
tolerance, then the discrepancy is deemed to be settlement discount.
Calculating the Tax Portion of the Discount

If you are generating settlement discount, the system can also calculate the tax portion of the discount and
post it to the input and output tax accounts specified on Ledger Tax Calculations. In this case, the tax analysis
dimension set in Ledger Setup (LES) must be one of your match criteria.

The Discount Transactions Generated

For each set of match criteria, the following transactions are generated: the discount value is posted to the
debtor/creditor account and the output or input discount accounts, and the tax portion is posted to the input
and output tax accounts specified in Tax Details (TXD).
Matching in the Transaction Currency

Transaction Matching (TRM) can match the transactions posted to an account by base currency or transaction
currency. This is determined by the Currency Identifier field.
When matching is by transaction currency, the transaction currency values on allocated transactions must
match. If the base currency equivalent values do not match, a currency gain or loss transaction is generated
for the difference. This gain or loss is posted to the realized account codes identified on Transaction Matching.
The Exchange Gain/Loss Post Rule set in Ledger Setup (LES) determines whether a single, net realized
account, or separate gain and loss accounts are required.
When there are system generated transactions resulting from Transaction Matching, analysis is omitted
unless it was selected as a matching criterion. When analysis is used as a matching criterion, the analysis that
was used as the matching criterion is copied.
It is important to remember that if you choose to match by transaction amount, you must select the currency
code as one of the match criteria. You are forced to enter currency code as the third match criteria if it has
not already been selected.
Using Transaction Matching

Transaction Matching (TRM) allows you to allocate or match together transactions on an account and
enables you to automate the allocation/matching process. You define two types of rules for the matching
process:
• selection criteria - which determine the transactions considered for matching
• match criteria - which are the fields that must match for transactions to be allocated together.
You can choose to post the allocations automatically, or to simply report on them. You can also choose to
report on:
• any transactions that fall within your selection criteria and remain unmatched
• all unmatched transactions, unmatched debits, and unmatched credits
• all the matched transactions.
Note: If you are using expenditure checking, the transactions are posted during Transaction Matching even
if budgets are exceeded.
Transactions allocated during Transaction Matching are assigned account specific allocation references.
As part of Transaction Matching, any resulting discount and gain/loss transactions are posted to the ledger.
You can also use Business Rules to set or validate analysis codes on the transactions generated by this
process. To do this, create an Event Profile in Event Profile (EVP) that checks for a Function Code of

Transaction Matching, and use a Call Point of either 00015 Populate or00016 Validate Analysis on System
Generated Transactions.
Currency Identifier
The currency value type to be matched. You can match transactions by base currency, transaction
currency, or fourth currency. If you match by transaction currency, the corresponding base currency
amounts must also be equal before an allocation is made. If the difference is caused by an exchange
gain or loss, a journal is generated automatically to post this difference to the realized gain or loss
account.
Account Type
The type of accounts for which transactions will be selected for matching.
From/To
The account, or range of accounts, to be selected within the account type chosen. Transactions for these
accounts, matching the selection criteria, are considered for matching and allocation. Leave these fields
blank to include all accounts of the chosen type.
Note: Closed and suspended account codes are excluded from Transaction Matching.
Selection 1-3
This option allows you to identify up to three selection criteria which transactions must meet before
they are picked for matching. If you leave all three selection criteria blank, you will select all of the
unmatched transactions for the selected accounts, for periods up to the selected Cutoff Period.
From/To 1-3
A code, or range of codes, within the chosen selection criteria. Transactions are only selected if they
include this range of codes. For example, you may wish to restrict the transactions to those for a range
of analysis codes.
Match Criteria 1-3

You can select up to three different match criteria. The criteria selected will determine the basis for
matching transactions to each other.
Cutoff Period
A cutoff period can be identified beyond which, transactions are not considered for matching. The default
is to select the current period as the cutoff period.
Report Unmatched
This option enables you to determine the reporting detail you require for transactions that have been
selected, but remain unmatched, after a transaction matching run. You can choose not to report the
unmatched transactions at all, to report unmatched debit and credit transactions, only unmatched
debits, or only unmatched credits.
Report Matched
This determines whether or not the transaction matching report identifies the matched transactions.
Post Transactions
This determines whether or not the allocations and any resulting discount and gain/loss transactions
are posted to the ledger. If provisional postings are optional, you can choose to post the transactions
as provisional or permanent.

Input Discount Account

This is the account to which settlement discount generated on creditor/payables accounts, or sales
transactions on a client account, will be posted.
Output Discount Account

This is the account to which settlement discount generated on debtor/receivables accounts, or generated
on purchase transactions on a client account, will be posted.
Discount Tolerance
The discount tolerance identifies the acceptable difference between the amount of discount allowed,
as identified by the settlement terms, and the actual discount amount taken. The tolerance is entered
either in the form 9999.99 to specify a fixed amount tolerance, or in the form 999.99% to specify a
percentage tolerance from the calculated discount. Leave the field blank if no tolerance is required.
Note: Discount only applies if you are matching transactions on debtor, creditor or client accounts.
Realized Difference Account (Gains or Net)

This field is required if you select transaction currency matching in Currency Identifier and you are
posting transactions, rather than reporting on them. When transactions are matched based on transaction
currency, the base currency values must balance. Consequently, gains/losses may be generated.
Currency Identifier is also required if you select base currency matching and Value 3 or Value 4 are
defined to enforce balancing. That is, when the Currency Amount Balancing option is set to Manual or
Automaticon the Value 4 tab, or Automatic on the Value 3 tab of the Business Unit Setup.
The Exchange Gain/Loss Post Rule setting in Ledger Setup (LES) determines the use of this account.
If the Exchange Gain/Loss Post Rule is set to:
• Net Gains and Losses, enter the net realized difference account.
• Gains and Losses Separately, enter the realized gains account. In this case, you must also enter
the Realized Losses Account in the field below.
• Gains Only, or Losses Only, the effect on Transaction Matching is exactly the same as for Gains
and Losses Separately. Therefore, enter the realized gains account, and then enter the Realized
Losses Account in the field below.
You can also enter a '-' hyphen in this field, for the Base or Reporting amount exchange gain/loss to be
posted to the account codes specified in Business Unit Setup. If Value 3 is Second Base Currency, the
balancing account on Business Unit Setup is used. However, the gain/loss difference on the other
currencies is generated into the gain/loss account defined in Currency Codes (CNC), Currency Period
Rates (CNP), Currency Daily Rates (CND), or at run-time entry.
Realized Losses Account

This field is required if you select to match in the transaction currency and the Exchange Gain/Loss
Post Rule in Ledger Setup (LES) is set to Gains only, Losses only, or Gains and Losses Separately.
Any realized exchange losses are posted to this account.
Posting Period
The period to which transactions generated during Transaction Matching are to be posted. Leave this
blank to post to the current period. This is only required, if you selected Yes in the Post Transactions
field.

Allocation Markers
Transactions have an allocation marker set to identify a particular processing requirement or status.
There are several different allocation marker flags available, which have different meanings in the system.
Certain Financials functions set the allocation marker automatically to indicate the processing status of the
transaction.
For example:
• Payment Run (PYR) and Payment Collection Run (PYC) set the marker to Paid (or Paid Unmatched) to
indicate that a transaction has been paid.
• Account Allocations (ACA), the online allocation function of Ledger Entry (LEN), and Transaction
Matching (TRM) set the allocation marker to Allocated when a transaction is matched against another.
• Account Allocations (ACA) can be used to manually set selected allocation markers on a transaction.
A journal type can be defined to set an allocation marker automatically on the transactions in a journal during
Ledger Entry (LEN). For example, you could define a journal type to always set the marker to Force.
You can use Ledger Allocation Indicators (LAI) to change the names of the allocation markers.
For further information on allocation markers see:
• 'What Allocation Markers are Available?' for a list of the allocation markers and a summary of how the
markers can be set or amended.
• 'Updating the Allocation Markers Manually' for information on how to set the allocation markers on
transactions.
• 'Which Allocation Markers Must Balance' for details of the three allocation markers that can only be set
on a balancing group of transactions.
Note: The Allocation Markers are predefined, although you can change their name. A similar set of user
defined codes, referred to as Allocation Codes, can be defined and automatically assigned to transactions by
particular Financials functions. See 'What are Allocation Codes?'
What Allocation Markers are Available?

The following table describes each of the allocation markers available. For each marker, it identifies the other
allocation markers it can be changed to, for example using Account Allocations (ACA). The allocation markers
are identified by single character letter e.g. F = Force.
Allocation Marker Description May be changed to ..

Y-To Be Allocated This marks a transaction as allocated. A transaction is given Not applicable (see A-
(becomes A-Allo- this marker when it is marked for allocated. Allocated)
cated after post-
ing)
A-Allocated This indicates that the transaction has previously been marked space, 0-9, F, W, Y, C,
with To Be Allocated and then posted. R, S

B-Brought For- This marker is used by Payment Run (PYR) if the amount to Y, B, S
ward be paid is discovered to be a debit balance. These transactions
are included in subsequent payment runs until the balance
reverts to a credit. A similar situation arises in Payment Col-
lection Run (PYC), but where the amount to be 'paid' is dis-
covered to be a credit balance.
C-Correction This marker is used to highlight transactions posted in error. space, 0-9, F, W, Y, C,
Transactions with this marker may be excluded from all re- S
ports except Journal Listing and Trial Balance. Use the Re-
port Corrections option in Ledger Setup (LES) to determine
whether these transactions are included in the report.
F-Force This marker identifies transactions to be paid in the next space, 0-9, F, W, Y, C,
Payment Run or Payment Collection Run. R, S
P-Paid This marker identifies transactions that have been paid and space, 0-9, F, W, Y, C
matched by Payment Run and Payment Collection Run. It
cannot be entered manually.
R-Reconciled This marker identifies bank account transactions that have space, 0-9, F, W, Y, C,
been reconciled with the bank statement. R, S
W-Withhold This marker works in reverse to the Force maker. Transactions space, 0-9, F, W, Y, C,
with this marker are excluded from Payment Run and Pay- R, S
ment Collection Run.
0 to 9 These markers are used to indicate the various processing space, 0-9, F, W, Y, C,
stages that a transaction can go through during its lifetime. R, S
They are used primarily for bills of exchange and promissary
notes. Each number represents the stage in the life of the bill.
These markers can be incremented manually or by printing
specific documents. See Document Format (DFS).
Space You can enter a space to remove an existing allocation marker space, 0-9, F, W, Y, C,
from the current transaction. R, S
S-Split (becomes You enter Split on a transaction where you want to split the Not Applicable (see A-
A-Allocated after amount to record a part payment or receipt. Allocated)
posting)
T-Paid Un- This marker identifies manual payment override transactions space, 0-9, F, W, Y, C,
matched generated and paid by Payment Run or Payment Collection R, S
Run. It makes these transactions available for manual
matching using Account Allocations (ACA). This marker
cannot be set manually.

Updating the Allocation Markers Manually

You can set the allocation marker manually on a transaction to reflect a particular status or processing
requirement using Account Allocations (ACA). For example, you can set it to Withhold to prevent a transaction
being selected for payment.
You can set the following markers manually and they can be used to subsequently select transactions for
reporting purposes, or for payment:
• Allocated is used to identify a matched transaction.
• Reconciled is used to highlight bank account transactions that have been reconciled with the bank
statement.
• Force and Withhold identify transactions that are either to be paid immediately or withheld from payment
in Payment Run (PYR) and Payment Collection Run (PYC).
• Correction identifies transactions as internal corrections, and so can eliminate them from financial
reports. You can choose whether to include Correction transactions in financial reports. This is determined
by the Report Corrections option in Ledger Setup (LES).
• Markers 0 to 9 are used to record the processing stage a transaction has reached. For example, where
bills of exchange are used. Numeric markers can be applied to all transactions on debtor, creditor and
client accounts.
You may also wish to reset the allocation marker to blank in some circumstances. For example:
• to remove a Withhold marker to allow a transaction to be selected for payment
• to remove a Paid or Paid Unmatched marker, if the payment for a transaction was voided. Note that you
can set this as part of the payment voiding processing to void a system generated payment.
If you set, or unset, any of the allocation markers that must balance, each marker must be set on a group of
balancing transactions. You can use the Allocation Totals option within Account Allocation to view the
balancing details for each of these markers individually.
Ideally you should use Account Allocations to allocate transactions for a particular reason, by allocating a
single type of marker. For example, you should use it to identify corrections, or identify correction transactions,
or match payments to receipts. This will simplify the allocation balancing.
Which Allocation Markers Must Balance?

The transactions posted to open item accounts remain in SunSystems until they contain a 'matched' allocation
marker. Once a transaction is matched it can be removed from the system by Ledger Cleardown (LCL). These
'matched' allocation markers are always applied to a set of balancing transactions. This is to ensure that
when the cleardown is run, only balancing transactions are removed from the system.
There are three 'matched' allocation markers: Allocated, Paid, Correction.
Allocated
The Allocated marker applies to a set of balancing payment, invoice and credit note transactions on debtor,
creditor or client accounts. This marker indicates that the payment transaction has 'paid' the associated
invoice and credit note transactions.

The Allocated marker is set using any of the SunSystems matching functions. The transactions are initially
marked as either To Be Allocatedor Split, depending on whether the transaction is to be fully or partly
allocated. When the allocations are posted, the allocation marker is set to Allocated.
Paid
The Paid marker also applies to a set of balancing payment, invoice and credit note transactions for debtor,
creditor and client accounts. It indicates that the system generated payment transaction has paid the associated
invoice and credit note transaction. The payment transaction was generated by Payment Run (PYR) or
Payment Collection Run (PYC). This marker is, therefore, only usually set by SunSystems.
Note: The Paid allocation marker can only be removed from balancing transactions using Account Allocations
(ACA). It cannot be set.
Correction
The Correction marker is used to identify a set of balancing transactions that were posted in error. It can be
used to exclude the transactions from reports, except Journal Listing and Trial Balance. You use the Report
Corrections option in Ledger Setup (LES) to determine whether these transactions are included in reports.
This marker can be set using Account Allocations.
Updating the Allocation Markers

You can use Account Allocations (ACA), or online allocation as part of Ledger Entry (LEN), to change the
allocation marker on the transactions you have selected for matching. If you use Account Allocations to set,
or unset, any of the matched allocation markers identified above, each marker must be set on a group of
balancing transactions. You can use the Allocation Totals option to view the balancing details for each of
these markers individually.
Ideally you should use Account Allocations to allocate transactions for a particular reason, by allocating a
single type of marker. For example, you should use it to identify corrections, or identify correction transactions,
or match payments to receipts. This simplifies the allocation balancing.
Naming the Allocation Markers

An allocation marker is a flag that is set on a transaction to indicate its particular status or processing
requirement. You can use Ledger Allocation Indicators (LAI) to alter the name and short heading code for any
of these markers.
This is particularly useful if you are using the numeric markers to indicate the processing status of a transaction,
for example for bills of exchange.
Note: You cannot change the use of a marker using this form. You are only changing the descriptive information
held for each marker.

Ledger Allocation Indicators (LAI)

Allocation Indicator
Select the allocation marker you want to maintain. These are the internal codes for each allocation marker,
as listed above.
Name
The allocation marker name.
Short Heading
A shortened version of the Description to be used instead where space is limited. If you leave this blank it
defaults to the first characters of the Description.
Exclude From Overdue Inv Check

Check this check box if all transactions with this allocation marker are to be excluded from Overdue Invoice
Checking.
Note: The following markers are normally excluded: Paid, Paid Unmatched, Allocated, Reconciled and
Correction.
Updating Allocation Markers in Ledger Entry

Your system may be set up so that specific allocation markers are updated from the Ledger Entry form.
That is, for allocation marker 0 a memo document is produced and the allocation marker is incremented to
1; for allocation marker 5 a credit/debit note document is produced and the allocation marker is incremented
to 6.

Importing ledger entries
Chapter 6: Importing ledger entries
Ledger Import allows you to validate and post journals that have been created by another function rather
than entered manually using Ledger Entry (LEN).
These journals are held as import files and stored in the Ledger Import tables. You can use Ledger Import to
post actual and budget transactions.
Understanding Ledger Import

Ledger Import allows you to validate and post journals that have been created by another function rather
than entered manually using Ledger Entry (LEN). These journals are held as import files and stored in the
Ledger Import tables. You can use Ledger Import to post actual and budget transactions.
Note: If you are using budget checking, you should note that although the ledger is updated, the transactions
are not held for the budgets.
The journals to be imported can be generated by a number of different sources including:
• SunSystems Financials Corporate Allocations.
• SunSystems Order Fulfilment.
• Other software packages.
The transactions must be created as balanced journals, in the required journal transaction format.
One or more journals can be combined into a single import file, or batch, for processing. However, all of the
journals in a file must use the same journal type.
Ledger Import uses a control desk to allow you to select the journals you want to import.
Ledger Import Processing Modes

Ledger Import can be run in two different processing modes: real-time or manual.
When Ledger Import is used to import and post journals in real-time, the journals are passed to Ledger
Import automatically as they are generated by the source system. Ledger Import then validates the journals
and, providing they are correct, posts them. Alternatively, it can place the journals on hold to enable them
to be corrected and posted using Ledger Entry.

When Ledger Import is used to manually import and post journals, the journals are held on the Ledger Import
SQL tables within Financials until you choose to import them. You then manually select the journals you want
to import, and these are passed to Ledger Import for validation and posting.
The journals generated by SunSystems Order Fulfilment and Financials Corporate Allocations can be posted
either in real-time or posted manually.
Ledger Import Validation and Posting

Ledger Import applies the same validation and balancing rules as Ledger Entry to each journal it processes
to ensure that only valid journals are posted.
Each journal type referenced in the import file must have a Status of either Open or Hidden in Journal Type
(JNT).
You can choose to only validate the journals, or to validate and post the journals. When you are posting the
journals, if an error is found in a journal you can choose to either reject the journal or post the error to a
suspense account.
Imported journals can be posted to the actual ledger or to a budget ledger. To post a journal to a budget
ledger, you must select the budget ledger you require on the ledger import run-time parameters.
Using Business Rules for Additional Validations

Business rules can be used to apply any special validation requirements to selected journal fields. For example,
you may want to make certain fields that are optional in Financials, mandatory on the import. You might also
need to apply, for example, the same analysis code validations in both Ledger Import and Ledger Entry.
There are some special circumstances for setting up business rules for Ledger Import. To automatically set
any of the journal fields during the import process, only certain Call Points can be used in the Event Profile.
To validate the target ledger for the import, one specific Call Point must be used in the Event Profile.
Whilst validating details on each transaction line being imported, it is also possible to reference the previous
line imported, for example to ensure a certain field is consistent on all the lines of each journal imported.
However, if you do this it is essential to differentiate between Ledger Imports from Order Fulfilment and other
Ledger Imports (for example, from an external file exported using Transfer Desk). Ledger lines generated by
the Ledger Interface definition within Order Fulfilment are sequenced prior to Ledger Import by sorting on
Transaction Reference / Account Code, so if you reference the previous line, you need to consider this
resequencing. Therefore, to differentiate between the ledger import types, you should use the Journal Header
Creation Type data item in an event profile or rule, which identifies whether the Ledger Import is from Order
Fulfilment or from another source.
Viewing and Selecting Journals for Import

You use a control desk to initiate, control and monitor the Ledger Import processing. The control desk displays
all of the journals on the ledger import tables.
This means that you can use the Ledger Import Control Desk to view journals in any of the following states:
• those awaiting ledger import processing
• those rejected by ledger import with validation errors.

Journal Type Controls

The settings on the journal type also determine how the journals are processed by Ledger Import.
If the transaction being imported refers to a journal type which has the Next Period Reversal field set to Yes,
a reversal for the amount of the transaction is posted to the relevant account in the next period.
If the transactions being imported refer to a journal type which requires authorization, the journal is
automatically placed on hold.
Importing Journals with Unique References

If the transactions being imported are for a journal type whose definition has the Unique References field
set to Yes, and the account to which the transaction is imported is a debtor, creditor, or client type account,
the reference number entered is validated against the ledger. An error is reported if the reference is not unique
for that account.
Dealing with Errors in Ledger Import

Ledger Import applies the same validation and balancing rules as Ledger Entry to each journal it processes
to ensure that only valid journals are posted. As part of the Ledger Import run-time parameters you can choose
to only validate the journals in the selected import file, or to validate and post the journals. If you choose to
post the journals, you can also choose whether you only post each journal if it passes the validation, or whether
you force each journal to post by posting balancing transactions to a suspense account, if necessary.
Any journal errors are identified on the Ledger Import validation report.
Posting If No Errors are Found

You can choose the Post if no errors option in the Post Transactions (On Import) field on the Ledger
Import Run-Time Parameters form to prevent ledger import journals being posted if they contain any errors.
If this option is set, an invalid journal remains on the import tables with a status of Errors Found - Data Not
Posted.
The errors are identified on the Ledger Import validation report and you must edit the journal file to correct
the errors. You can then reselect the journal for import in the normal way. Alternatively, if the journal import
file should not be posted, you can delete the journal from the import tables.
If you want to edit the journal details in Financials, you should set the Post to Hold run-time parameter to
load the invalid journals as held journals in Financials. You can then review, edit, release and post the journals
using Ledger Entry in the same way as any manually held journals.
You can optionally choose to override the Post if no errors option, if the error is caused by a system generated
currency conversion rounding difference.
Forcing Journals with Errors to Post

You can chose the Post option in the Post Transactions (On Import) field on the Ledger Import Run-Time
Parameters form to force the ledger import journals to be posted, even if they contain errors. If this option

is set, the system substitutes any invalid journal details and, if necessary, forces the journal to balance so
that it can be posted.
A journal may contain several different types of error which are treated differently:
• A journal line may have incorrect, or missing, details. In this case Ledger Import substitutes the invalid
details with default valid information. For example, if the account code on the journal line is invalid, it
substitutes the error suspense account. However, if the transaction cannot be corrected it is rejected.
• The journal may be out of balance, in which case:
• If the imbalance is the result of a currency conversion rounding difference, the system generates
and posts a rounding adjustment.
• If the imbalance is not considered to be a rounding difference, the system generates a balancing
transaction that posts to the suspense account for the currency that is out of balance.
Note: When errors are posted to a suspense account you should review the reason for the error and enter
another journal to correct the errors. For example, if the error was caused by a journal line referencing an
invalid account you should identify the correct account and enter a journal which reverses the amount out
of the suspense account and posts it to the correct account.
Posting Rounding Differences

If the transactions in a journal balance in at least one currency but not in all of the required currencies, the
amount of the imbalance is treated as a rounding difference if it is within the Rounding Threshold set for
the currency in Business Unit Setup.
In this case the imbalance amount is posted automatically to the Credit Balancing Account, or Debit/Net
Balancing Account, identified in Business Unit Setup.
Reporting on the Import Process

The Ledger Import Validation Report (FPLI1.srdl) is produced automatically by the Ledger Import process.
This report lists some or all of the journal transactions processed from a selected import file.
The results of the Ledger Import process are summarized on the Ledger Import Validation Report dialog.
This dialog includes a Print action that allows you to view and print the Ledger Import Validation Report.
The Ledger Import Validation Report dialog also allows you to determine the type of transactions to be
included on the report. You can include or exclude:
• valid transactions
• invalid, rejected, transactions
• substituted transactions
• generated transactions.
Identifying the Rejections and Substitutions

Any rejected transactions or transactions with substitutions are clearly identified in the leftmost report
column, alongside the relevant transaction details.

The Transaction Rejected message appears if the transaction has been rejected. The '^' caret character is
printed beneath each field that contains invalid data.
The reasons the transaction was rejected are explained beneath the transaction details alongside the {Rejection}
note.
If a transaction contains invalid data that has been replaced by default valid data, these substitutions are
identified alongside the {Substitution} note beneath the transaction details.
Note: If you are using over expenditure checking, and an imported transaction takes the account over budget,
the posting report highlights this but does not prevent the transaction from being posted.
Selecting the Report Format

You can choose different layouts for the report by changing the setting of the Layout Code field in the
Reporting tab on the Ledger Import Run-Time Parameters.
The following default report layouts are available:
Report designed for: Format Code

Journals generated by Corporate Allocations and posted by Ledger Import. LICOR
This report is stored automatically.
Journals generated by any other system or function and imported using Ledger LIALL
Import.
Note: You can also create new report layouts and change existing report layouts using Report Designer.
Editing Ledger Import Files

Manual Editing
You can import journals to the journal hold file by setting the Post to Hold option in Ledger Import Run-Time
Parameters. This allows you to edit the journal using Ledger Entry (LEN).
Automatic Editing
Some imported items are edited by the Ledger Import process before they are validated:
• If the debit/credit indicator is undefined, it is ascertained from the content of the amount fields. A '-'
minus sign results in a debit.
• If you have chosen to left justify ledger import references in Ledger Setup (LES), all transaction references
are shifted to the left to match the SunSystems Financials format.

Importing Multi-Currency Transactions

All of the multi-currency conversion rules that apply to journals entered manually using Ledger Entry (LEN)
also apply to journals loaded using Ledger Import (LIM).
If all of the currency details are not included on a transaction, for example if only the transaction currency
amount is present, the import process retrieves the currency rates required and calculates the remaining
currency values using the normal currency posting rules for the business unit, or journal type.
If you are using currency rate types and the value conversion is required, but the currency conversion rate is
not included, for example, the base amount and transaction currency code is provided, but the transaction
amount and transaction rate is not, the conversion rate specified on the Currency Rate Type for the Journal
Type is used to calculate the amount values and any subsequent rate tolerances.
Either daily or period exchange rates are retrieved, depending on the currency requirements. If a currency
rate is not found for the currency, date or period, or a Currency Rate Type is not specified in Journal Type
(JNT), the transaction is rejected.
A multi-currency journal being imported must meet the currency balancing requirements defined for the
business unit.
Any rounding differences that arise from currency conversion can be posted automatically to a suspense
account, even if the Post if no errors option is selected. This is determined by the Allow Bal Txns When
Post if not Error option is set on Ledger Import Run-Time Parameters.
Note: Transactions generated by Ledger Revaluation (LER) are ignored for conversion purposes in Ledger
Import. Revaluation transactions are identified as having a journal source of REVAL and journal type of SYSTM.
Running Ledger Import

Ledger Import (LIM) is used to import journal files, and any associated standard text, into SunSystems
Financials.
It can be invoked by the system to automatically post generated journals, for example, to post corporate
allocation journals. It can also be invoked manually to post selected journal import files once they have been
placed on the ledger import file table.
The steps to manually import journals

The following steps are required to use Ledger Import manually to post selected ledger import files:
1 Select Ledger Import (LIM) from SunSystems to list the current ledger import files on the Ledger Import
Control Desk.
2 Select the files to be imported.
3 Select Action > Review to list the selected batches.
4 The selected batches are listed on the Control Desks In-Tray.

Using the Ledger Import Control Desk

The Ledger Import Control Desk allows you to select journal batches to be processed by Ledger Import (LIM).
The control desk lists all of the journal import files currently held on the Ledger Import tables which includes:
• journal batches awaiting validation and posting
• journals that were previously validated and contained errors.
This is identified in the status of each journal.
Click on a journal on the list to select it for ledger import and then click Review. Alternatively, click Review
All to select all of the journals in the list.
Note: You can select a block of journals by dragging the mouse in the selection field.
Note: You can also use the Ledger Import Control Desk to remove journal files from the Ledger Import tables.
Ledger Import Control Desk

Description
A description of the journal import file, as provided by the function that generated by the journal file. For
example, if the journal was generated by Corporate Allocations this contains the pathname and filename
of the import file.
Journal Type
The type of journals included in the import file, as defined using Journal Type (JNT). Only one type of journal
can be contained in an import file.
Last Status
The current processing status of the import file. This is updated by SunSystems as the file is processed.
Created By
The business unit or operator that created the journal import file.
Created Date
The date the import file was added to the Ledger Import tables.
User Id Last Updated

The business unit or operator that last updated the journal import file.
Date/Time Last Updated

The date/time the journal import file was last processed.
Entering the Ledger Import Run-Time Parameters

The Ledger Import Run-Time Parameters form within Ledger Import (LIM) is used to define the import
processing requirements for a selected batch of journals and to initiate the Ledger Import process for that
batch. It can also be used to remove a journal batch from the Ledger Import tables, for example, if it is not
required. The batch of journals is held in a ledger import file.

The Ledger Import Run-Time Parameters form is accessed from the Ledger Import Control Desk via the
Control Desk In-Tray. You use the control desk to select one or more import files for processing. You then
use Ledger Import Run-Time Parameters to set the processing rules and run the import process, for each
import file individually.
The number of files chosen for processing is identified in the Selection n Of n section at the top of the form.
The first file in the Control Desk In-Tray is selected automatically and identified at the top of the form. This
is referred to as the current file or batch.
For example, Selection 1 of 12 indicates that the Control Desk In-Tray contains 12 files awaiting processing
and the first file is the current file.
Once you have entered the import parameters for this current file, and Ledger Import has processed and
POSTED the journal transactions successfully, the next file on the Control Desk In-Tray becomes the current
file selected for processing.
Alternatively, if the current file was processed by Ledger Import but NOT POSTED, this file remains the current
file selected for processing. For example, you may have selected the Validate only processing option and
now want to select the Post processing option. You can use the Next action to select the next file available
on the Control Desk In-Tray, if required.
The Ledger Import Run-Time Parameters form includes the Clear Import File action. This removes the
selected import file from the import tables, for example if it not required.
Note: You cannot return to the previous file in the selection list.
Ledger Import Run-Time Parameters

Transfer File Name
The description of the journal batch import file appears at the top of the window. This is the file you are
currently processing. The status of this file is displayed alongside.
Selection n Of n contains n entries

This identifies the current file selected for processing, the total number of import files selected on the
Control Desk In-Tray, and the number of transactions in the current file, that is, the file identified in the
field above.
For example, 'Selection 3 of 6 contains 8 entries' indicates that the current file selected for processing
is the third file listed on the Control Desk In-Tray. The Control Desk In-Tray contains six import files
and the current file contains eight journal transactions.
Created On/By
The date on which the current journal import file was created and the operator Id of the person who
created the transactions.
Amended On/By
The date on which the current journal import file was last amended and the operator Id of the person
who amended the transactions.

Journal Type
The type of journals contained in the current import file. All of the journals in the import file must reference
this journal type.
Validation
The following error suspense accounts are required by the ledger import process to post any balancing
transactions it generates to compensate for an error, or a journal imbalance exceeding the currency Rounding
Thresholds on the Business Unit Setup.
However, if the imbalance is caused by a currency conversion rounding difference within the Rounding
Thresholds, then the balancing adjustment transaction is instead posted to the corresponding Balancing
Account identified on the Business Unit Setup Value 1, Value 2, Value 3 or Value 4 tab, depending on the
currency value being adjusted.
The following accounts are required regardless of whether or not you choose to post the current import file.
Error Suspense Account
The account code to which the balancing adjustment is posted if the base currency journal values do
not balance, and the imbalance exceeds the currency Rounding Threshold for Value 1.
Additionally, if you set the Post Transactions (On Import) option on the Posting tab to Post, and a
journal transaction line is rejected, this account is used to post the rejected transaction. For example,
if the account code on a journal transaction is invalid, or an analysis code is prohibited, this account is
used as the substitution.
Other Account
The account code to which the balancing adjustment is posted if the transaction currency journal values
do not balance, and the imbalance is not a currency conversion rounding difference.
Note: In order for balancing adjustments to be generated and posted in the transaction currency, the
Amount Balancingoption must be set to Manual on the Value 2 tab of the Business Unit Setup.
Reporting Account
The account code to which the balancing adjustment is posted if the second base or reporting currency
journal values do not balance, and the imbalance exceeds the currency Rounding Threshold for Value
3.
Allow Over Budget

This option overrides the budget controls and allows transactions to be posted if they exceed the available
budget.
Default Posting Period

The period to which any transactions with an invalid or absent accounting period are posted.

Balancing
Balance By
This determines the level at which the journal transactions must balance. If this level of balancing is
required, you can force the transactions to balance by transaction date, transaction reference, or one
of the ten ledger analysis codes.
Allow Bal Txns When Post if no Err

This option allows the system to generate and post balancing transactions if there is an imbalance in
the base amount or in any of the currency values that require Amount Balancing, as determined on the
Business Unit Setup. The option is only effective when the Post Transactions (On Import) option on
the Posting tab is set to Post if no Errors.
Use this option in conjunction with Post if no Errors if you want to permit an imported journal to be
posted even if it is unbalanced, whilst nevertheless preventing the journal from being posted if it contains
other errors, such as prohibited analysis codes, closed accounts, dates, or periods, or violates a business
rule condition.
There are three possible settings for this option:
• Never - imbalances are treated as errors that prevent the journal from being posted.
• Generate Exchange Differences - balancing adjustments are generated for imbalances due to
currency conversion rounding differences, and all other imbalances are treated as errors that prevent
the journal from being posted. Adjustment transactions are posted to the corresponding Balancing
Accounts identified on the Business Unit Setup Value 1, Value 2, Value 3 or Value 4 tab, depending
on the currency value being adjusted (providing that the rounding difference is within the threshold
for that currency value, also specified on the Business Unit Setup).
• Generate Balancing Transactions - for any imbalances detected, balancing adjustments are posted
to the Error Suspense Account, the Other Account or the Reporting Account specified on the
Validation tab, depending on the currency value being adjusted.
For an imbalance to be considered as due to a currency conversion rounding difference, the journal
must balance in at least one of the currency values.
Note: Analysis codes are validated on the system-generated balancing lines, however, the posting rules
for these are not as stringent as for the original transactions being imported. That is, analysis code
violations on the system-generated balancing lines do not prevent transactions from being posted,
however, the violations are mentioned on the import report. For example, a generated balancing line
might have an analysis code missing, for which the analysis dimension is specified as mandatory on the
account. In this case, the balancing transaction is posted to the account with a blank analysis code, and
an appropriate message is written in the import report. This is intended to facilitate 'fine tuning' of your
ledger import process (with respect to balancing, accounts and analysis), whilst not actually preventing
the import file from being posted. If necessary, analysis codes can be subsequently added or amended
using Account Allocations (ACA).
Posting

Post Transactions (On Import)

This determines whether or not the transactions being processed are posted, and whether they can be
posted if they contain errors. Three options are available:
• Validate only - if this option is selected the transactions are validated but not posted.
• Post - if this option is selected the transactions are validated, balancing transactions are generated
to balance the journal if necessary and the journal is posted.
• Post if no Errors - if this option is selected the transactions are validated and, providing there are
no errors, posted. This can be overridden for an imbalance by using the Allow Bal Txns When Post
if no Err setting described above.
Allow Posting to Suspended Accounts

If this is set, transactions can post to ledger accounts with a status of Suspended. If not, a transaction
posting to a suspended account is treated as an error.
Post Provisional
If the Provisional Postings option in Ledger Setup (LES) is Optional and this Post Provisional option
is set, the transactions are validated and/or posted as provisional transactions. If this option is not set,
the transactions are validated and/or posted as permanent transactions.
Post to Hold
This option validates the journals and stores them as held journals on the Journal Hold file. This provides
an additional level of posting control because they then need to be released from hold and posted. If
this option is blank, the journals are validated and posted as provisional or permanent postings.
Ledger Code
The ledger to which the transactions are posted. Select A to post actual journals, or B to K to select one
of the ten available budget ledgers.
Reporting
Layout Code
The document format code that identifies the Ledger Import report required.
Report Only Errors

Set this option to only report on transactions that contain substitutions, or which have been rejected.
Leave this blank to report on all of the transactions.
Note: You can override this choice on the Ledger Import Validation Report form, if required.
Suppr Msgs. for Insignif. Substitutions

If this option is selected, substitution lines for blank accounting periods and transaction dates, and
certain other low level substitutions, are excluded from the Ledger Import report.

Examples of Rejections and Substitutions

Depending on the severity of an error in the ledger import data, the settings of certain options directly affect
how the error is treated.
Major Errors
There are various circumstances in which a line can be considered as containing a major error, for example,
an attempt to post to a closed or non-existent account, or an attempt to use a prohibited or non-existent
analysis code or journal type. Possibly the most common error is the exclusion of an analysis code for an
account that has that dimension set to mandatory.
If you set the Post Transactions (On Import) option to Post, any major error is treated as a reason to reject
the transaction line from the account, and to pass it to the Error Suspense Account you specify. However,
if you set the option to Post if no Errors, the same major errors are considered reasons for rejecting the
transaction and therefore for not posting the ledger import file.
Imbalances
With the Post Transactions (On Import) option set to Post, imbalances in any or all of the currency values
are automatically balanced by a line to the appropriate error suspense account for the value or values
containing the imbalance.
With the option set to Post if no Errors, the handling of imbalances (that is, whether an imbalance is
considered to be an error) depends on the setting of Allow Bal Txns When Post if no Err, described in detail
in the 'Balancing' topic.
Substitutions
When an error is not considered major enough to reject the line, and if the error can be automatically
substituted by a suitable alternative, the transaction line is imported to the correct account and the substitution
made. Such substitutions happen regardless of whether the option is set to Post, or Post if no Errors.
Substitutions are considered either significant or insignificant. In general, the insignificant substitutions can
be ignored, for example when an analysis code is imported in lower case and is substituted with correct code
in upper case.
The following circumstances are common examples of significant substitutions, when the import file contains:
• an analysis code for an account that has that dimension prohibited. The analysis code is replaced by a
null or blank code.
• a date or period out of the open range specified in Ledger Setup (LES). The error is substituted with the
current date or period as appropriate.
• a currency conversion rate missing, but the two values and the currency conversion code are present.
The correct rate is substituted.
• a currency conversion rate included, but incorrect for the two values included in the transaction line.
The correct rate is substituted.
• a currency conversion code, a conversion rate, and the base value are included, but not the transaction
(or other) value. The other value is calculated and substituted.

Understanding the Ledger Import Validation Results

The Ledger Import Validation Report dialog appears automatically after Ledger Import has processed a
journal import file and summarizes the processing results.
These processing results for the import file can be printed on the Ledger Import Validation Report. You can
use the Print options on this dialog to determine the type of transactions that are included on this report.
For example, you may only want to print the rejected transactions.
Click Print to produce the report, or click Exit to return to the Ledger Import Run-Time Parameters dialog
without printing the report.
Ledger Import Validation Results

Description
The description of the journal import file processed. This can be used to identify the filename and path.
Records Input
The number of journal transactions included in the import file.
Records Rejected
The number of journal transactions rejected by the Import process.
Major Substitution Records

The number of journal transactions on which major field substitutions were made by the Import process.
For example, where the account code or accounting period were substituted.
Balancing Records Created

The number of balancing transactions generated to balance the journals in the import file. Different balancing
transactions might be required to balance individual currencies, or if several journals exist in the journal
import file.
Reversal Records
The number of reversal transactions generated for the journal import file.
Records Posted
The number of journal transactions posted by the Import process.
Records Printed
The number of transactions to be printed.
Print Valid Records

The option chosen whether to print valid transactions.
Print Rejected Records

The option chosen whether to print rejected transactions.
Print Substituted Records

The option chosen whether to print transactions on which substitutions were made.
Print Generated Records

The option chosen whether to print generated transactions.

Print Totals
The option chosen whether to print the journal and ledger import file totals.
Clearing Ledger Import files

The Ledger Import tables are used to store journals awaiting posting to Financials.
When a journal is posted by Ledger Import, the journal details are automatically removed from these tables.
You may need to remove journal import files from the tables, for example, if the files have been added to the
import tables in error, or you do not want to post a particular import file.
There are two options available that remove import files from the import tables:
Clear Import File
Removes a selected import file.
Clear Posted Imports

Removes any posted journal import files.
Clearing selected import files

Use Ledger Import (LIM) to remove selected, unposted, import files from the ledger import tables.
Comlete these steps to remove selected import files:
1 Select Ledger Import (LIM) to display the list of ledger import files in the Ledger Import Control Desk.
2 Select the ledger import files to be removed.
3 Select Actions > Review to review the selected files.
4 In Batch Process select Ledger Import Process.
Note: Do not select Clear Posted Files.
5 Click OK to open the Ledger Import Run-Time Parameters form.
6 Complete these steps for each file to be deleted.
a Select ActionsClear Import File.
b Click Yes to delete the import file.
7 Click the exit button twice to return to the Ledger Import Control Desk window.
Clearing posted imports

When Ledger Import posts a batch of journals it automatically deletes the journal transactions from the
ledger import tables. Clear Posted Imports (CPI) removes all of the posted import file headers up to a selected
date from the ledger import tables.
To clear posted import files:
1 Select Clear Posted Imports (CPI) from SunSystems.

2 On the Clear Posted Imports form, enter the following selection parameters to determine the import
files to be removed:
Date/Time Last Updated
The date up to which posted import files are removed.
3 Select All to remove all posted import files.
Clearing Locked Import Files

The Clear In-Progress Import action resets the status of an import file to unlock the file. It does not clear
the import file itself.
An import file may become locked if the Ledger Import process fails, for example, if a computer failure occurs
during the process.
TheClear In-Progress action is only available to authorized users. To be able to use this action you must be
a member of a data access group for which this action has been enabled.
Loading transactions from Order Fulfilment

The SunSystems Order Fulfilment modules can generate and post journals to SunSystems Financials in two
ways: online or batch. If the batch posting method is chosen the posting details are generated and stored,
and must be manually selected for posting to Financials.
Loading Transactions from Ledger Interface

The transactions are selected for posting manually using the Ledger Interface Posting Control Desk. This
function passes the selected journals, via the Control Desks In-Tray, to Ledger Import which posts them
automatically.
The following steps are required to select and post transactions generated from Order Fulfilment:
1 Select Batch Posting to Ledger (BPL) from SunSystems to display the batch selection window.
2 Enter the selection criteria to determine the transactions you wish to post and click OK.
3 The transactions awaiting posting that meet the selection criteria appear on the Ledger Posting Control
Desk.
4 Select the transactions to be posted.
5 Select Action > Review to transfer the selected transactions to the Control Desks In-Tray.

Extracting Ledger Interface transactions

The Ledger Posting Batch Selection filter is used to extract unposted Order Fulfilment transactions onto
the Ledger Posting Control Desk to enable them to be selected for posting to Financials.
The selection fields that appear are determined by a filter created using Filter Designer (FLD) and can be
tailored to meet your specific requirements.
Module Code
The Order Fulfilment module for which you want to select and post transactions to Financials. The
options are: Inventory, Purchasing or Sales.
Entry Date From/To

The range of dates for which transactions are extracted for posting.
Period From/To
The range of accounting periods for which transactions are extracted for posting.
Using the Ledger Posting Control Desk

The Ledger Posting Control Desk displays selected transactions awaiting posting to Financials. These
transactions were generated from Order Fulfilment using the batch posting method in Ledger Interface.
The transactions that appear on this control desk are those that meet the ledger posting batch extract criteria.
The Summarization Breakout set for the Payment Run determines the level at which the relevant Order
Fulfilment transactions are summarized to define a single journal line. The valid options are:
• No Breakout - the postings are not summarized
• Breakout at User Id
• Breakout at Transaction Type
• Breakout at Transaction Reference/Id
• Breakout at Transaction Line Number.
You can choose to post all of these transactions, or only selected transactions, using Action > Review.
Originating User Id
The operator who created the journal transaction.
Posting Date
The posting date generated for the transaction.
Journal Code
The Financials ledger to be updated by the transaction. This is A for the actuals ledger or B to K for one
of the budget ledgers available.

Journal Type
The type of journal to be posted. This is assigned in the Ledger Interface setup. The interface ignores
any journal presets assigned to the journal type.
Period
The accounting period to which the transaction is to be posted.
Ledger Interface Definition

The Ledger Interface code that contains the rules used to generate this transaction for posting.
Originating Transaction Type

The transaction type within Order Fulfilment from which this transaction was generated.
Module Code
The Order Fulfilment module from which this transaction was generated. Options are: Sales, Purchasing
or Inventory.
Originating Transaction Ref

The transaction reference from which this posting transaction was generated. This is not available for
transactions generated from sales invoices, picking lists or dispatch notes.
Originating Transaction Id
The transaction Id from which this posting transaction was generated, if the originating transaction was
a sales invoice, picking list or dispatch note.
Stage Code
The stage in the lifecycle of the originating transaction at which this posting transaction was generated.
For example, order confirmation or goods receipt matching.
Entering the Generate Ledger Batch Parameters

The Generate Ledger Batch window is used to set the Ledger Import processing options to apply when the
journals generated from Order Fulfilment transactions are posted to Financials.
The default settings for these parameters are determined by the Ledger Interface (LIS) setup. If you alter
the default settings in error, you can revert back to these by selecting Revert to Original from the Action
menu.
When you have entered the parameters, select Post from the Action menu, or click Post to initiate the ledger
posting process.
Posting Type
• Post - Post the journals regardless of whether or not they pass the validation rules.
• Post if No Errors Found - Only post the journals if they pass the validation rules. If errors are found,
the posting details can be corrected and the journal(s) reposted using Recover Failed Postings
(RFP).

Posting Write to Hold

Select this to post the journals as held journals in Financials.
Provisional Posting
Select this to post the journals as provisional postings. Leave this blank to post the journals as permanent
transactions. This is only required if provisional postings are optional in Financials.
Posting Allow Balance Trans

Select this to allow the creation and posting of system generated balancing transactions when the Post
Transactions option is set to Post if no Errors Found, if the imbalance has been caused by a system
calculation. For example, if the imbalance is a rounding difference as a result of currency conversion
calculations. If this option is not set, system generated imbalances are treated as errors which prevent
the journal being posted.
Base Suspense Account

The Financials account to which a balancing journal transaction is posted if the balancing adjustment
is required in the base currency. You cannot select a suspended or closed account, or a memo account.
If the account code on a journal transaction is invalid this account is used as the substitution.
Transaction Suspense Account

The Financials account code to which a balancing transaction is posted if the transaction currency journal
values do not balance and the amount of the imbalance is greater than the rounding tolerance. This is
only required if the transaction currency is in use for the business unit. You cannot select a suspended
or closed account, or a memo account.
Reporting Suspense Account

The Financials account code to which a balancing transaction is posted if the second base or reporting
currency journal values do not balance and the amount of the imbalance is greater than the rounding
tolerance. This is only required if the second base or reporting currency is in use for the business unit.
You cannot select a suspended or closed account, or a memo account.
Post Balance By
The additional transaction details for which the journal lines must balance. This imposes an additional
level of balancing, over and above the normal journal balancing requirements. If you do not wish to
impose additional balance conditions select No Extra Balancing. Otherwise select one of the following
options to ensure the journal transactions balance for the selected field: ledger analysis 1 to 10, transaction
date or transaction reference.
Report Errors Only

If this is set, Ledger Import only reports on transactions that contain field value substitutions or which
have been rejected. Leave this blank to report on all of the transactions.
Suppress Substitute Message

If this option is selected, substitution lines for blank accounting periods, transaction dates and other
less significant substitutions are excluded from the Ledger Import report.
Posting Report Format

The document format to be used for the Ledger Import posting report that is produced automatically
when journals are posted to Financials. The document format must have been defined using Document
Formats (DFS).

Allow Over Budget

This allows a journal posting to take a ledger account over budget regardless of any budget checking
controls in place.
Post to Suspended Accounts

Allows the journal transaction to post to a suspended Financials account.

Generating payments and receipts
Chapter 7: Generating payments and receipts
SunSystems Financials generates payments using the Payment Run (PYR) function.
Payment Run produces the payment documents and transactions for the source transactions that you select
for payment.
There are two ways you can select the transactions to be paid by Payment Run:
• using payment profiles
• via a control desk.
How are Payments Generated?

SunSystems Financials generates payments using the Payment Run (PYR) function. Payment Run produces
the payment documents and transactions for the source transactions that you select for payment.
There are two ways you can select the transactions to be paid by Payment Run:
• using payment profiles
• via a control desk.
Payment Profiles
A payment profile contains predefined selection criteria that extract transactions for payment. The selection
criteria can also be modified at run time. A profile also identifies the type of payments you want to produce,
the payment bank and other payment details. You identify the payment profile you want to use when you
run Payment Run (PYR). It then selects the transactions according to the selection criteria and produces the
payments.
Control Desk - Payment Selection and Review

If you select the transactions via a control desk or with Payment Selection and Review (PYS), you can use
a filter to extract the transactions you require. Then from the Control Desks In-Tray, select Payment Process
to pass them to Payment Run. Payment Run then takes over and produces the payment documents and
transactions as normal.
Note: Even if you choose to select the transactions using a control desk, a payment profile is still required by
Payment Run to identify the payment document details.

Understanding Payment Run

Payment Run (PYR) is used to settle selected outstanding transactions on creditor/payables accounts. It
can also settle transactions on client accounts with a credit balance. Payment Run can trigger the creation
of the necessary payment documentation, for example, remittances and cheques. It can also produce a bank
transfer file for electronic transmission.
Payment Run can be initiated from the SunSystems menu, or from a control desk, or from Payment Selection
and Review (PYS) (which is a specific control desk function that allows you to save sets of selected transactions
for review and payment). The method you choose determines how the transactions to be considered for
payment are chosen:
• If you initiate Payment Run from the SunSystems menu, the transactions are selected by the payment
profile you choose, and any run time selection criteria you enter. You can define any number of payment
profiles although only one can apply to a particular payment run. Each profile can contain different
selection criteria, including account selection criteria, currency codes, due dates, and so on.
• If you initiate Payment Run from a control desk, the transactions considered for payment are those
displayed on the control desk in-tray when you initiate the payment run process. A filter is used to extract
the transactions for payment using the selection criteria defined within the filter.
• If you initiate Payment Run by using Payment Selection and Review (PYS), the transactions considered
for payment are those in the payment set (saved set) that you create.
Payment Run does not automatically pay all of the transactions it is presented with for payment. It only pays
those that are eligible for payment according to the many different payment criteria that can apply.
When you initiate Payment Run you must choose a payment profile, even if you run it from a control desk
or from Payment Selection and Review. This is because the payment profile determines other important
payment details including the type of payment output required, and the payment bank details.
Before you initiate a Payment Run, regardless of the method you use, you should identify or define the
payment profile that contains the payment run requirements. You may also want to preview the payment
selections.
Note: If you want to pay a transaction immediately, you can also access Payment Run directly from Ledger
Entry (LEN).
If the Authorization facility is enabled and authorization stages have been defined for payment processing,
Payment Run checks whether the transactions selected for payment require authorization. If they do, the
payment run is suspended until the transactions are fully authorized. When they are fully authorized, the
payment run is completed automatically and all you will need to do is produce the payment documents, if
required.
When you run the Payment Run, you can choose to produce the payment run details report only and use
this to verify that the correct payments are produced. This allows you to review the proposed payments and
make adjustments, if necessary.
What Does the Payment Run Do?

Payment Run performs the following tasks:
• if it has been run from the SunSystems menu, it uses the selection criteria to locate the transactions to
be considered for payment.

• it identifies the transactions eligible for payment.

• it produces a payment run details report that lists or summarizes the account transactions selected for
payment and shows the total number and amount of the payments being generated.
• it optionally produces a warning if the bank accounts will become overdrawn as a result of the payments.
• it optionally produces a warning if a cheque payment exceeds the Cheque Payment Limit set in Ledger
Setup (LES).
• it creates the payment details from which the payment documents are produced, for example cheques
and remittances.
• it generates and posts the ledger transactions required to record the payments, any settlement discounts
taken, and tax adjustments on the discount.
• Alternatively, if the Non Match of System Payments option is set to Yes in Ledger Setup, the payments
and transactions are assigned the allocation marker of Paid Unmatched. This prevents them from being
reselected for payment but allows them to be matched manually using a matching process. An allocation
reference is entered on both sets of transactions but an allocation date is not entered until the transactions
are matched.
• it optionally produces a bank transfer file, if the payment method is Bank.
Note: If you are using over expenditure checking, you should note that transactions are posted during Payment
Run even if budgets are exceeded.
Preparing for a Payment or Collection Run

Before you initiate a payment run, or payment collection run, you must identify the type of transactions you
want to select for payment or collection.
For example, you may want to pay all of the outstanding invoices due for payment by today, or only pay your
most critical suppliers, or only collect payments due in a particular currency.
You can produce the aged analysis reports to analyze the outstanding transactions by due date.
Note: In a multi-currency environment you may need to alter the Currency for Payments setting in Ledger
Setup (LES), depending on whether you want to produce or collect payments in the base currency or in
different transaction currencies.
If you are using payment stamps to group transactions for payment, you must assign the payment stamps
before you pass the transactions through to Payment Run for payment. Payment stamps are assigned via a
control desk.
Before you initiate the payment or payment collection run you must identify the payment profile that is
required. If a profile doesn't exist, you must create it using Payment Profiles (PYP).
Even if you select the transactions for payment via a control desk you must still identify the payment profile
to be used by Payment Run to produce the payment documents.
Previewing the Payments or Collections

You can preview the payments that are produced by a payment or payment collection run to ensure the
correct transactions are paid or collected. This is particularly recommended if you are using a new payment
profile.

To preview the payments or collections, you should set the Post Transactions option to No on Payment Run,
or Payment Collection Run. This produces the payment run details report which lists the transactions selected
for payment or collection.
You can use this report to check that the required payments are produced or collected.
Including or Excluding Transactions for Payment

You can include or exclude transactions for payment or collection by altering various details, depending on
the circumstances.
If you are using a payment profile to select the transactions, you can alter the payment run selection criteria,
for example by adjusting the Base Date for Payment or Base Date for Discount and the payment profile
selection criteria, for example by adjusting the selection ranges, or payment basis.
You can alter selected transaction details, for example to withhold a transaction by setting the allocation
marker or amending the due date.
You can use Account Allocations (ACA) to amend selected transaction details, for example to alter a
transaction's due date or allocation marker. You can also use it to split a transaction, for example if you want
to pay only part of an invoice you would split it according to the value you want to pay. You would also amend
the payment due date to delay the payment of the unpaid part of the invoice.
Note: If discount is allowed on a transaction selected for collection by Payment Collection Run, it is selected
for payment regardless of the payment due and discount due dates, and the discount is always allowed.
Understanding the Payment Run Details Report

The Payment Run Details report is produced automatically by Payment Run (PYR) and Payment Collection
Run (PYC), regardless of the payment run options you choose. This report identifies the payments being
generated or collected, according to the payment run criteria.
This report can be used to preview the results of a payment run by setting the Post Transactions option to
No.
Note: You can also produce the Payment Listing to print the payment transactions posted to selected accounts.
What Appears on the Report?

The report begins by printing the payment run selection details including the base date for payment, payment
date, and any run time selection criteria. It also identifies the payment method being used for the payment
run, for example, cheque, bank or other.
It then identifies each of the accounts selected for payment. For each account it lists the transactions selected
for payment and then prints the total amount being paid for the account. If the Summarize option is set in
Payment Run or Payment Collection Run, the report omits the transactions and only prints the payment
totals for each account.
In a multi-currency environment, the base and transaction currency amounts and transaction currency code
are printed. The report totals are analyzed by currency.

If the payment method is Bank or Other, the report also prints the bank subcode details for each account
including the bank sort code and account code, and the bank transaction reference. These are the supplier
or debtor bank details defined using Bank Details (BNK).
Once all of the accounts have been printed, the report prints the report payment total and then summarizes
the payment run details.
If payment journals are generated and posted, it prints the payment journal number. It then lists the following
totals:
• the number of payments generated
• the total value of the payments generated
• the total amount of discount taken
• the total amount of tax calculated on the discount
• the number of debits outstanding
• the total value of these debits.
Finally the report summarizes the bank account position. It prints the payment bank account number and
name, its balance prior to the payment run, the total value of the payments paid from the bank account, and
the closing account balance.
Authorizing Payments
If the Authorization facility is enabled for the ledger, some transactions may need to be authorized before
they can be paid. Payment Run checks all of the transactions selected for payment to see whether they
require authorization.
It reviews all of the authorization stages that have been defined with a Stage Type of Payments. The transactions
require authorization if they match the filter requirements that have been defined for an authorization stage.
The transactions are grouped into an authorization set and sent for authorization. If more than one stage of
authorization is required for the transactions they are sent in stage number order.
From Payment Run (PYR):
• When the transactions are identified as requiring authorization, the Authorization Batch Comments
dialog is displayed. This is used to mark the transactions for authorization. It identifies the authorization
set reference for the transactions and allows you to enter comments for the authorizer. This dialog is
displayed at the end of the Payment Run process, after you have entered all of the payment run details
and selected the Print action.
From Payment Selection and Review (PYS):
• When the transactions in the payment set (saved set) are sent to the Payment Process from the control
desk in-tray, the Payment Run form is displayed and you must enter the details as with a normal Payment
Run (PYR) before the payment set is sent to the appropriate authorization in-tray.
The payment run is suspended until the transactions are authorized. To preserve the payment request details,
all of the transactions selected for payment in the run are saved into a saved set, or in the case of Payment
Selection and Review (PYS), are retained in their current payment set (saved set). When the transactions
have been fully authorized for payment, the payment run for this set of transactions is completed automatically.

When the payment run is completed all of the payment transactions are posted, the payment files are produced
and the payment run details report is produced. However, if payment documents are required these must
be printed manually using Payment Documents (PYD) in the normal way.
Overriding the Currency Rates for Payments and Collections

Note: To override the currency rates during payments and collections, the Rates Override option must be
set to Yes both in Ledger Setup (LES) and in the Payment Profile (PYP) being used.
The Override Currency Rates form may be displayed during Payment Run (PYR) and Payment Collection
Run (PYC), allowing you to amend the currency exchange rates used in the payment or collection. If you
amend any exchange rates, they must still be within the Rate Tolerance Levels defined on the Ledger Setup
(LES), Currency Period Rates (CNP), or Currency Daily Rates (CND).
Conversion Rate (display-only column)
For each listed currency conversion (from/to combination), this column displays the current conversion rate
as defined in Currency Period Rates (CNP), or Currency Daily Rates (CND).
Conversion Rate (activated column)

Use this field to amend a currency rate if necessary for this payment.
If the current or overridden exchange rates differ from those used on the originating transactions (for example
on the invoices being paid or collected), exchange difference lines are automatically generated in the payment
or collection journal. Each currency exchange difference line created on the supplier or customer side must
be offset by a balancing realized gain or loss on the account(s) nominated for exchange differences. Use the
Realized Gains/Losses Account field(s) to amend the account(s) to which the balancing lines are posted.
To identify the exchange difference generated for each supplier, the same description from the bank account
posting is used as the description for the exchange difference on the supplier account; supplier code and
name.
You must enter the Realized Gains/Losses Account(s) here, and these accounts are used if the corresponding
accounts are not set up on each relevant Currency Code (CNC) record.
Note: This field may be displayed as Realized Gains Account, or Realized Net/Losses Account, or both,
depending on the Exchange Gain/Loss Post Rule setting on the Options tab of Ledger Setup (LES).
Generating payments using Payment Run

Payment Run (PYR) is used to settle selected outstanding transactions on creditor/payables accounts and
on client accounts with a credit balance.
It can trigger the creation of the necessary payment documentation, for example in the form of remittances
and cheques. It can also produce a bank transfer file for electronic transmission. You can optionally use
Payment Selection and Review (PYS) to initially select transactions for payment and save them in a payment
set, before sending them to the payment run.

Initiating a Payment Run

Prior to initiating the payment run, if physical payment documents are to be printed which include a system
generated transaction reference number, for example a cheque number, you should ensure the correct
numbers are assigned.
For example, if you are printing cheques on pre-printed cheque stationery, you must ensure the system begins
with the correct cheque number.
The following steps are required to initiate the Payment Run:
1 Select Payment Run (PYR) from SunSystems.
Note: You are warned if unposted journals exist on the Held Journals File. To review the held journals, select
No at the continue prompt to display the Ledger Entry Held Journals form (LEH). Otherwise, click Yes to
continue with the payment run regardless.
• Select the payment profile and press Enter.
The payment profile details appear on the form and any run time selection are also displayed.
Note: A warning appears if the payment documents for the previous payments generated using this payment
profile have not been printed using the Final Print option. If you choose to continue they will be overwritten
by the payment details generated for this payment run.
• Enter the following payment run form details:
1 Any run time selection criteria requested by the payment profile, and press Enter.
2 The ledger posting account details and press Enter.
• If the payment method is Bank, the Payment Run Bank Transfer dialog appears and you must enter the
bank transfer file details.
• From the Action menu select Amend Consolidation if you want to consolidate the payment transactions
or want to enter analysis codes for the payment transaction.
• From the Action menu select Amend to alter any of the payment run selection details if necessary.
• From the Action menu select Print to initiate the payment process.
Note: If the Authorization facility is enabled and some of the transactions selected for payment require
authorization, the Authorization Batch Comments dialog is displayed. The transactions are placed in an
authorization set and are sent for authorization. The payment processing for these transactions is suspended
until the transactions are authorized. When they are authorized the remaining steps are carried out
automatically.
If the transactions do not require authorization, or if they have been authorized, the payment process continues
as follows:
• The Document Format Runtime Parameters form is displayed, to allow you to control the production
of the payment run details report. Enter the options as required and click OK.
• The payment profile is checked for its Currency Rules settings, as the payment may require conversion
for one or more of the currency values. Depending on the setting of the Override Rates option, the
Currency Rates Override form may be displayed. If so, verify the exchange rates shown for each currency;
modify any as required, enter the Realized Gains/Losses Account(s) and click Print.
• The payment process begins. The payment run details report is produced; the postings are generated if
the Post Transactions option is set to Yes, and the payment files are produced if appropriate.
• If the Post Transactions option is set to Yes and payment documents are required, the Payment
Documents form is displayed. This is used to produce the physical payment documents, for example
remittances and cheques.

Note: If the Withholding Tax facility is in use and Withholding Tax transactions fail to post during the Payment
Run, they must be imported manually using Ledger Import. Once posted successfully Payment Run can be
initiated again.
Using Payment Run

Payment Run (PYR) is used to generate automatic payments for your creditor/payables accounts, or client
accounts with credit balances. When you use payment run you must identify a payment profile. This profile
contains selection criteria that can determine the transactions selected for payment and also controls the
payment production.
Note: If payment run is initiated from a control desk rather than from the SunSystems menu, the transactions
considered for payment are those selected on the control desks in-tray rather than those identified by the
payment profile selection criteria.
If payment run is initiated from the SunSystems menu, it begins by using the payment profile and run time
selection criteria to identify the accounts to be considered for payment. It then uses the criteria to select the
transactions to be paid on these accounts.
Payment run always produces the payment run details report. If Post Transactions is set to Yes, it also
generates and posts the requested payments.
Payment Run (PYR)

1 Open Payment Run (PYR).
Profile Code
The Payment Profile code that determines the selection criteria for the payment run, any run time
selection criteria, and the payment output and posting requirements. This code is defined using Payment
Profiles Setup (PYP). The payment profile must have a Payments/Debits field set to Payments.
Post Transactions
Select Yes to generate and post the payment transactions, produce a payments file, set the allocation
marker to Paid (or Paid Unmatched) on the selected transactions, produce the payment run details
report and optionally produce a bank transfer file. If provisional postings are optional, you can choose
to post the transactions as provisional. If this option is mandatory, then the transactions are always
posted as provisional.
Select No to only produce the payment run details report showing the items selected for payment.
Suppress Report Transactions

Select this option to summarize the transactions on the payment run details report. If this option is not
selected, the payment run details report shows the payment and discount allowed on individual
transactions. If this option is chosen, a summary report is produced showing the total amount selected
for payment from each account.

Base Date for Discount

Transactions are selected for payment if they are eligible for discount on or before this date.
Payment Date
The date to be used as the transaction date for transactions generated during this run. The default is
today's date.
Next Payment Date

The date you expect to run the next payment run using this payment profile. If transactions are still
eligible for the same discount on this date, they will not be selected for this run. Transactions with a
Force allocation marker are selected regardless of the date entered in this field.
Posting Period
The period to which the transactions generated during this run are to be posted. The default is the
current period.
Selections 1-5 From/To

Up to 5 run time selection criteria may be displayed. These criteria are determined payment profile
which is defined using Payment Profiles Setup. For example, you may be asked to enter a range of
accounts and journal sources. A transaction must meet all of these selection criteria to be included in
the payment run.
Bank Details Code

The bank details record, as set up in Bank Details (BNK), for your own bank account. When you enter
a valid bank details code, the Payment Account field (below) displays the relevant chart of accounts
record for your bank account.
This field is mandatory for payments where the Payment Method is set to Bank on the payment profile.
If there is no Bank Details Code on the payment profile, and the Payment Method is set to Bank, then
you must enter it here.
Bank Subcode
The subcode, if used, on the bank details record identified in the field above. Otherwise leave blank.
Payment Account
The chart of accounts code to which the balancing, cash transactions for the payment are to be posted.
It would normally be a bank account. You cannot select a memo account. A default account can be set
for the payment profile.
If you are producing payments in more than one transaction currency, the payment account identified
for each currency in Currency Codes (CNC) is used. If a payment account has not been defined for a
currency, the account you enter here is used.
You may be warned if there are insufficient funds in this account to meet the generated payments.
Input Discount Account (Payment Run)

The chart of accounts code to which the balancing transactions for generated discount taken on debit
transactions are posted. You cannot select a Memo account.

Output Discount Account (Payment Collection Run)

The chart of accounts code to which the balancing transactions for generated discount received on
credit transactions are posted. You cannot select a Memo account.
Payment Run Bank Transfer

The Payment Run Bank Transfer details are required to create a bank transfer file from the payment run.
This form is only displayed if all of the system and run time settings have been set to create a bank transfer
file.
You can use the bank transfer file as input to another application or software package to prepare the
transactions for an automated clearing system, for example BACS.
Bank Payments Processing Date
The date on which the payments are to be processed by the bank. You cannot select a date earlier than
today's date. In the UK, BACS normally requires a date not less than two days earlier and not more than
40 days later than the date of transmission. This date can be reset or overwritten at the time of
transmission.
Default Bank Transaction Ref

This reference indicates to the payee the reason for payment. The supplier's bank details record can
hold a reference. If it does not, the reference entered here is used. You can leave this field blank. A
reference is not mandatory in the UK for BACS.
Ledger Payment Reference

You can enter a reference in this field which is applied to all transactions posted to the payment account.
There is no validation check on the reference entered. You can leave it blank.
Single Payment
Check this check box if you want to generate a single transaction to each payment account for the
suppliers paid from this account in the payment run. This option is necessary if you want to use
consolidation to set or consolidate analysis codes on the collection bank account transaction, as described
below.
Leave this check box unchecked if you want each account paid to be recorded as a separate transaction
in the payment account.
Note: If you use this option you cannot use Payment Voiding to cancel a payment for a single supplier.
Print Link
Select this field if you want to go straight to Payment Documents (PYD) when the payment run has
finished to produce any supporting documents, for example to print remittances.
Bank File Identifier

This code is used as the file extension to the Bank Payment File Name to identify the file for this run.
This defaults to the bank file identifier that was specified in the previous run with the same payment

profile. If this is the first run with the payment profile, it defaults to the bank file identifier specified in
the profile, unless that is blank, in which case it defaults to '01'.
Bank Payments File Path/Name

By default, this option is for display only, showing the file name of the bank transfer file, including the
business unit code and the bank file identifier as the extension. If a file of this name already exists, you
are warned of this and given the choice to overwrite the file or to cancel the Payment Run. Do not
overwrite the file unless you are certain it has been transferred successfully.
If this field is activated, you can enter a different path and file name for the bank transfer file. The path
can be a local drive, for example, c:\folder\, or a network location, for example, //computer01/output.
Network paths are not case sensitive, and can include '/' forward slashes or '\' back slashes. The file
path/name you enter is retained as the default for the next bank payment using this payment profile.
Consolidating and Setting Analysis Codes

In Payment Run, there are three types of analysis consolidation:
• Creditor / Client Analysis Codes consolidation
• Exchange Gain / Loss Analysis consolidation
• Bank Analysis Codes consolidation.
All three types of consolidation refer to ledger analysis codes on the transaction lines generated by Payment
Run, and are described below.
You can also use Business Rules to set or validate analysis codes on the generated transactions. To do this,
create an Event Profile that checks for a Function Code of Payment Run, and use a Call Point of either 00015
Populate or 00016 Validate Analysis on System Generated Transactions.
Consolidation - Creditor / Client Analysis Codes

Click Amend Consolidation to display the Payment Run Consolidation form for the Creditor / Client
Analysis Codes.

Analysis Dimensions
The Payment Run Consolidation form lists the analysis dimensions assigned to the ledger. You can use
this form to split the payment transaction for the payables/creditor account according to the analysis
codes on the original transactions, or to apply new analysis to the payment transactions.
Leave all of the analysis dimensions blank if you want to generate and post a single consolidated payment
transaction to each payables/creditor account for the total amount paid to the creditor. This is the
default option.
Enter '..' against an analysis dimension to generate payment transactions with the same analysis codes
(for that dimension) as the original transactions being paid. This means that there could be several
payment transactions generated for a given creditor, if the original transactions in the creditor account

contain various different analysis codes for a dimension. These analysis codes are also automatically
entered on the corresponding bank account transactions, providing you are not using the Single
Transaction to Payment Account option (described above).
Alternatively, you can enter a specific analysis code for a dimension in order to set that code on the
generated payment transactions.
Note: You cannot use this feature for transaction sequence or daybook codes.
Consolidate Hierarchy
If a principal to principal hierarchy has been defined on the transactions select this option to consolidate
the transactions at each level of the hierarchy.
Consolidation - Exchange Gain / Loss Analysis

Click Exch Gain/Loss Analysis to display the Payment Run Consolidation form for the exchange gain / loss
transaction analysis codes.
Analysis Dimensions
The Payment Run Consolidation form lists the analysis dimensions assigned to the ledger. You can use
this form to assign analysis codes to any exchange gain / loss transactions generated by currency
payments.
Leave all of the analysis dimensions blank if you want to post a single consolidated transaction for each
exchange gain/loss difference generated. This is the default option. Alternatively, you can enter a specific
analysis code for a dimension in order to set that code on any exchange gain / loss transactions.
Consolidation - Bank Analysis Codes

Click Bank Analysis to display the Payment Run Consolidation form for the Bank Analysis Codes.
The purpose of this function is to allow the setting of analysis codes on the bank account transaction where
Single Transaction to Payment Account is defined on the Payment Profile (PYP) or set in the Payment
Run Bank Transfer form.
Note: Where payment is by transaction currency and multiple variable currencies are in use, multiple bank
payment lines are still generated according to those currencies. The payment lines are also summarized
according to the analysis you set, and depending on the settings, multiple grouped lines may also result.


Analysis Dimensions
The Bank Analysis form lists the analysis dimensions assigned to the ledger. You can use this form to
determine analysis on the bank transaction, where the Single Transaction to Payment Account check
box is checked on the Payment Run Bank Transfer form (as described above).
Leave all of the analysis dimensions blank to generate and post a single consolidated transaction to the
payment account for the total amount paid by this run. This is the default option, providing the Single
Transaction to Payment Account option is set.
You can enter a specific analysis code for a dimension in order to set that code on the generated bank
transaction(s).
Additionally you can enter '..' against an analysis dimension to generate bank transactions with the
same analysis codes (for that dimension) as the creditor / client side of the payment transaction. In this
case, it is possible for several bank transactions to be generated, according to the common groupings
of analysis codes.
If you enter '..' for an analysis dimension, in order to copy that dimension's analysis codes from the
creditor / client transaction lines you must first enter an option for the dimension on the Payment Run
Consolidation form for Creditor / Client Analysis Codes. To do this, click Amend Consolidation, as
described above.
Paying Transactions Immediately

There may be times when you need to pay ledger transactions as soon as they are posted to the ledger. For
example, if a supplier has presented an invoice in person that needs to be posted and paid immediately while
he waits.
You can link the Ledger Entry process to the Payment Run process for selected transactions. This enables
you to enter and post the ledger transactions and then pay them immediately.
Linking the Transaction Entry and Payment Processes

You must set up a journal type to identify the transactions that require immediate payment and link the
journal type to a payment profile. Journal Types are defined using Journal Types (JNT) and the payment
profile is entered in the Payment Profile Code field.
Payment profiles are defined using Payment Profiles (PYP).
Immediate payments are typically made by cheque. In this case, the payment profile used to produce these
payments would reference the Payment Method of Cheque.
Note: A supplier is only paid by Payment Run, if the Payment Method that has been set for the supplier on
Supplier (SUS) is the same as the Payment Method identified in Payment Profiles (PYP). Therefore, if you

want to produce an immediate cheque payment for a supplier that is usually paid by bank transfer, you must
temporarily change the supplier's Payment Method on Supplier (SUS).
Entering Transactions and Producing the Immediate Payments

Once you have set up the linked journal type, you can use Ledger Entry to enter the transactions that require
immediate payment. The transactions must be entered using the linked journal type.
If the Due Date is calculated automatically using the payment terms and is set to a future date, you may want
to override this and enter the current date. If not, you will need to adjust the Base Date for Payment in
Payment Run (PYR) to include the transactions for payment.
As soon as the transactions are posted by Ledger Entry, Payment Run (PYR) appears automatically. It
automatically displays the Payment Profile Code referenced on the journal type. Only the transactions that
have just been posted are considered for payment.
You should enter the payment run details and initiate the payment run in the normal way. Payment Run
produces the Payment Listing, generates and posts the payment transactions, and produces the payment
file used to produce the physical payments.
Finally, Payment Documents (PYD) appears automatically to allow you to produce the physical payment
documents, for example, the remittance advice and cheque.
Once the payment document print process has been initiated, the Ledger Entry function reappears to allow
you to enter another journal, if required.
Analysis Consolidation and Interaction with Business Rules

In both Payment Run (PYR) and Payment Collection Run (PYC), there are two options that allow the
consolidation and setting of analysis codes: Amend Consolidation (for the creditor or debtor transaction
line analysis codes), and Bank Analysis (for the payment account or collection account transaction analysis
codes).
You can also use Business Rules to set or validate analysis codes on the transactions generated by Payment
Run and Payment Collection Run. To do this, create an Event Profile that checks for a Function Code of
Payment Run, and use a Call Point of either 00015 Populate or 00016 Validate Analysis on System Generated
Transactions.
Note: If a transaction fails validation by a business rule using call points 0015 or 0016, by default the error
message is not shown in the transaction report. This is because it is not included in the SunSystems sample
reports; therefore, to show the details of such analysis code validation, you must add an appropriate column
for this to the relevant transaction report for the process (payment, collection, and so on.).
The following tables describe how the Amend Consolidation and Bank Analysis options interact with Business
Rules Call Points 00015 and 00016.

Interaction of Amend Consolidation and Business Rules
Amend Consolida- Business Rules Business Allowed Impact

tion Call Point 00015 Rules Call Combina-
- Populate Point 00016 tion
- Validate
Analysis set only Yes No validation against Chart of Accounts
in Amend Consoli- Analysis settings for the creditor or
dation debtor account.
Analysis set only Call point Yes Analysis is validated against Chart of
in Amend Consoli- 16 validates Accounts analysis settings.
dation analysis.
Not used Analysis is set Yes In this scenario Call point 16 is invoked
only via Rules automatically after call point 15, and
analysis is validated against the Chart
of Accounts settings.
Analysis set in Analysis may be Yes (but In this scenario Call point 16 is called
Amend Consolida- further adjust- unlikely). automatically after Call Point 15, and
tion ed via Rules. analysis is validated against the Chart
of Accounts settings. Business Rules are
applied based on the original transac-
tions, but the analysis generated via
Business Rules takes precedence over
that generated via Amend Consolida-
tion.
Interaction of Bank Analysis and Business Rules
Bank Analysis Business Rules Business Allowed Impact

Call Point 00015 Rules Call Combina-
- Populate Point tion
00016 -
Validate
Not used Not used Yes By default analysis is inherited from the
Creditor or Debtor side of the transaction,
that is, from Amend Consolidation, if this
in use.
Analysis set on- Yes Analysis on the bank side becomes sepa-
ly in Bank Analy- rate from analysis on the Creditor or
sis Debtor side. No validation against Chart
of Accounts Analysis settings for the bank
account.

Not used Business Rules Yes - see In this scenario Call point 16 is invoked
are defined. note be- automatically after call point 15, and
low. analysis is validated against the Chart of
Accounts settings.
Analysis set in Business Rules No The Business Rules are ignored and the
Bank Analysis are defined. Bank Analysis settings are definitive.
Note: You can only set analysis on the Bank transaction via Business Rules if the Single Transaction to
Payment Account option is set on Payment Run, or the Single Transaction to Collection Account option
is set on Payment Collection Run.
Interaction of Exchange Gain/Loss Analysis and Business Rules
Exchange Business Rules Business Allowed Impact

Gain/Loss Analysis Call Point 00015 Rules Call Combi-
- Populate Point nation
00016 -
Validate
Not used Not used Yes By default analysis is inherited from the
Creditor or Debtor side of the transaction,
that is, from Amend Consolidation, if this
in use.
Analysis set only in Yes Analysis on the Exchange Gain/Loss side
Exchange becomes separate from analysis on the
Gain/Loss Analysis Creditor or Debtor side. No validation
against Chart of Accounts Analysis settings
for the Exchange Gain/Loss accounts.
Not used Business Rules Yes In this scenario Call point 16 is invoked
are defined. automatically after call point 15, and
analysis is validated against the Chart of
Accounts settings.
Analysis set in Ex- Business Rules No The Business Rules are ignored and the
change Gain/Loss are defined. Exchange Gain/Loss Analysis settings are
Analysis definitive.
Voiding a System Generated Payment

Payment Voiding (PYV) allows you to cancel or reverse selected payments that have been created by Payment
Run (PYR) and to reinstate the paid transactions as unpaid.
Note: If you are using over-expenditure checking, Payment Voiding posts transactions even if budgets are
exceeded.
Note: You can also reverse payment journals using Journal Reversal and Copy (JRC).

Voiding the Payment Transactions

To void the payments, the system generates reversal journals for all of the payment transactions that were
created for the selected payments, including any discount, exchange gain or loss, or tax transactions. It sets
the allocation marker on both the original payment and reversal transactions to Correction. It also sets the
Allocation Code on these transactions according to the code associated with the allocation action of Payment
Voiding, if it has been set.
Reinstating the Original Transactions

In addition to voiding the payments, Payment Voiding also reinstates the transactions that were paid. It sets
allocation marker on these paid transactions to either Unallocated or Withheld, depending on whether or not
they should be re-available for payment.
If accounting links are being used and a payment transaction being voided contains an intra-transaction link,
any transactions that contain the same link reference are also reinstated.
Copying Ledger Analysis from the Payment Transactions

When you post the voiding transactions, as long as the payment method is not for single payments, a message
is displayed giving you the option to include transactions with analysis separately in the reversal. This means
that if the payment being reversed contains several transactions with differing analysis codes, you can choose
to reverse each of these in separate transactions. In this case, each voiding transaction line copies the analysis
codes from the payment transaction being reversed, thus reversing any ledger analysis posted on the payment
transactions. Click Yes to include the analysis on separate reversal transactions, otherwise click No to create
one voiding transaction line with no ledger analysis.
You can also use Business Rules to set or validate analysis codes on the voiding transactions. To do this, create
an Event Profile that checks for a Function Code of Payment Voiding, and use a Call Point of either 00015
Populate or 00016 Validate Analysis on System Generated Transactions.
Note: Regardless of the analysis on the original payment transactions, the analysis codes validated and set
by Business Rules are definitive, and if different, override the original codes. This is because the Business
Rules operate after the voiding process finishes setting analysis codes on the voiding transaction.
Note: If a transaction fails validation by a Business Rule using call points 0015 or 0016, by default the error
message is not shown in the transaction report. This is because it is not included in the SunSystems example
for this to the relevant payment voiding transaction report.
Payment Voiding Properties

Use Payment Voiding (PYV) to enter the details of the system generated payment that you want to void.
When you have entered the details, you are asked whether the payment method was for single payments.
This refers to the payment profile that was used to generate the payment, and if you are not sure, you can
check the profile in the Payments tab in Payment Profiles (PYP). If the payment profile is for cheques or
bank payments, then click No.
To void the payment, you must enter all of the following details on the Payment Voiding (PYV) form, and
then click Print.


Supplier Account Code
The creditor/payables or client account for which a payment is to be voided.
Payment Account Code

The account to which the balancing transaction was posted for the payment to be voided. This is the
account specified in Payment Account in Payment Run (PYR) and is normally a bank account.
If the payment was made in the transaction currency, you should enter the payment account identified
for the currency in Currency Codes (CNC).
Discount Account Code

The account to which any settlement discount was posted for the payment to be voided. This is the
account specified in Input Discount Account in Payment Run (PYR). Leave this field blank if discount
was not taken for this payment.
Payment Reference
The transaction reference of the payment to be voided. This must be entered, otherwise Payment
Voiding will not be able to find the correct transaction to void. This is the reference on the supplier
account.
Note: The payment reference is only assigned to the payment transactions when the payment documents
are produced for the run using the Final Print setting of Final in the document format report parameters.
If a final print run has not been performed for the payments, the payment reference will be blank even
though the payment transactions have been posted. Therefore, before you can void one of these
payments, you must use Payment Documents using the Final print option and Store option to produce
a 'dummy' payment document and assign a reference to the payment.
Post Transactions
This option determines whether or not the void payment transactions are posted to the ledger. If you
choose No, a report is produced identifying the void transactions that would be posted. This allows you
to check you have selected the correct transactions.
Note: If the original payment transactions were posted as provisional postings, you must also post the
void payment transactions as provisional.
Allocation Marker on Voided Transaction

Select the allocation marker you wish to replace the Paid allocation marker of the original transaction.
Select:
• Pay As Paid - if Financials is being used as a broker ledger, to reset the Paid allocation marker to
Unallocated. It also sets the Allocation Code to the code associated with Releasing Payable
allocation action, followed by the code associated with the Payment Voiding allocation action. If
the payment being voided was marked as a Funding payment, this Funding marker is removed.
• Withhold - to prevent the transaction from being selected for payment until the allocation marker
is reset.
• Not Allocated - to replace the Paid allocation marker with the Unallocated marker which makes
the transaction eligible for payment once more.
• Force - to replace the Paid allocation marker with the Force allocation marker, to ensure the
transaction is paid on the next payment run (assuming all other relevant criteria are met).
• 0-9 Marker - to replace the Paid allocation marker with 0 to 9, as appropriate for your payments
procedure.

Note: You can also use Account Allocations (ACA) to amend the payment due date and discount terms
for the transaction.
Generating payments using Control Desk

If you select the transactions via a control desk or with Payment Selection and Review (PYS), you can use
a filter to extract the transactions you require.
Then from the Control Desks In-Tray, select Payment Process to pass them to Payment Run. Payment Run
then takes over and produces the payment documents and transactions as normal.
Note: Even if you choose to select the transactions using a control desk, a payment profile is still required by
Payment Run to identify the payment document details.
Initiating a Payment Run from a Control Desk

Payment Run (PYR) is used to settle selected outstanding transactions on creditor/payables accounts and
on client accounts with a credit balance. It can trigger the creation of the necessary payment documentation,
for example in the form of remittances and cheques. It can also produce a bank transfer file for electronic
transmission.
You can optionally use Payment Selection and Review (PYS) to select transactions for payment in the
Control Desks In-Tray, and save them in a payment set, before sending them to the payment run.
Note: Prior to initiating the payment run, if physical payment documents are to be printed which include a
system generated transaction reference number, for example a cheque number, you should ensure the correct
numbers are assigned. For example, if you are printing cheques on pre-printed cheque stationery, you must
ensure the system begins with the correct cheque number.
Note: A warning appears if the payment documents for the previous payments generated using this payment
profile have not been printed using the Final Print option. If you choose to continue they will be overwritten
by the payment details generated for this payment run.
The following steps are required to initiate the Payment Run from a control desk:
1 Use a control desk filter or Payment Selection and Review (PYS) to extract transactions for the supplier
account you require onto the Control Desks In-Tray.
2 Select the payment profile and press Enter.
3 The payment profile details appear on the form. You must enter the payment run form details required.
You must press Enter after each type of information.
If the payment method is Bank, the Payment Run Bank Transfer dialog appears and you must enter the
bank transfer file details.
4 From the Action menu select Amend Consolidation if you want to consolidate the payment transactions
or want to enter analysis codes for the payment transaction.
5 From theAction menu select Amend to alter any of the payment run details.

6 Finally, from the Action menu select Print to initiate the payment process.
Note: If the Authorization facility is enabled and some of the transactions selected for payment require
authorization, the Authorization Batch Comments dialog appears. The transactions are placed in an
authorization set and are sent for authorization. The payment processing for these transactions is suspended
until the transactions are authorized. When they are authorized the remaining steps are carried out
automatically.
• The standard print request form appears to allow you to control the production of the payment run
details report.
If the Post Transactions option is set to Yes and payment documents are required, the Payment
Documents form appears. This is used to produce the physical payment documents, for example
remittances and cheques.
Stamping Payment Transactions

A payment stamp is used to group together a set of transactions for payment, and ensure all the transactions
involved in the payment are easily identified. It does this by including the same payment stamp on all of the
transactions involved, that is the transactions that have been paid and the payment transaction itself.
Two steps are involved in using this facility:
1 Firstly, you must manually assign a unique payment stamp to the account transactions you want to group
together for payment.
2 Then, when these transactions are selected for payment, Payment Run assigns the same payment stamp
to the cash payment transactions it generates. It produces separate payment documents and payment
transactions for each payment stamp. A payment stamp is a sequential number prefixed by P, for example
P152. The format of this stamp and the next available stamp is determined by the system.
What are Manual Payment Overrides?

The Manual Payment Override facility allows you to post an adjustment to a supplier account, include this
transaction in a payment run, and at the same time automatically reverse the adjustment off the supplier
account to maintain the true account balance. For example, you could enter a manual payment override to
record an invoice that needs to be paid urgently to ensure delivery but has been lost in the post.
The Manual Payment Override facility is only available if it has been enabled in Ledger Setup (LES) and can
only be used by authorized users.
Recording the Manual Payment Override and Offset

A manual payment override transaction is entered for an account using a control desk processing option.
The transaction itself is entered on the Ledger Entry input form, but this form is accessed via the control
desk.
You only need to enter the manual payment override transaction for the selected supplier account. When
you choose to post this transaction the balancing offset transaction is generated automatically. Both

transactions are posted to the supplier account. This ensures the supplier account balance remains correct
and double entry is maintained.
The manual payment override transaction is immediately available for payment. The offset transaction is
automatically assigned an allocation marker of Withheld to ensure it cannot be selected for payment.
Paying the Manual Payment Override Transaction

A manual payment override transaction is included in a payment run for the supplier in the normal way. The
offset transaction cannot be selected because it has an allocation marker of Withheld.
There are, however, some differences in the payment processing that takes place.
The payment transactions are not automatically matched against the transactions selected for payment. The
matching must be performed manually using one of the matching functions of Account Allocations (ACA),
Online Allocation or Transaction Matching (TRM).
Once the manual payment override transaction has been paid by the payment run, the Withheld allocation
marker on the offset transaction is removed automatically.
The payment is generated normally but a normal remittance advice cannot be produced.
Temporary or Permanent Manual Payment Overrides

Manual payment override transactions can be generated as either permanent or temporary transactions to
the supplier account. This determines whether or not the payment override transactions remain 'visible' on
the supplier account once the payment has been generated. This choice is made in Ledger Setup.
If the transactions are treated as permanent, they will always be visible on the account.
If the transactions are treated as temporary, then when the override transaction has been included in a
payment run both this transaction and its offset are assigned an allocation marker of Correction. Transactions
with this marker are not included on management reports or inquiries and therefore become invisible.
Allocations markers are described in detail in 'What are Allocation Markers?' and 'What Allocation Markers
are Available?'.
Recording the Actual Invoice

When the actual invoice or credit note is received, it is posted to the supplier account in the normal way. This
transaction will be offset by the manual payment override offset transaction that remains outstanding on
the supplier account.
When the next payment run is made for the account the offset transaction and the actual transaction will be
selected for payment automatically and will cancel each other out, thus not affecting the next supplier
payment.

Entering Manual Payment Overrides

Manual payment overrides are used to increase or decrease the payment to a supplier by posting an adjustment
transaction to the supplier account. Manual payment overrides are described in detail in 'What are Manual
Payment Overrides?'.
The following steps are required to enter manual payment override transactions:
1 Use a control desk filter to extract the transactions you require onto the Control Desks In-Tray. Typically,
these would be the transactions due for payment for one or more supplier accounts, for which manual
payment override transactions need to be entered.
2 In the Report Process field, select Manual Payment Override and click OK to list the selected transactions
on the Manual Payment Override window. The transactions are grouped and sub-totalled by supplier
account, transaction currency and payment method. This represents the grouping that would apply to
a payment run.
3 Click on one of the selected transactions for the supplier account for which a manual payment override
is required. This transaction's details are used as the basis for the manual payment override transactions.
For example, any payment details and analysis codes that are included on this transaction will be included
on the override transactions generated. Therefore, you should select a transaction that would be included
in the same payment run.
4 Click Manual Payment Override to post an adjustment that will increase the amount outstanding on
the chosen account and thus increase the generated payment. Alternatively, click Manual Deduction
Override to post an adjustment that will decrease the amount outstanding on the account and the
generated payment.
5 The Ledger Entry (LEN) form appears on which you must enter the other manual payment override
transaction details. In addition to entering the normal transaction details you must also attach text to
the transaction.
6 When you have entered all of the manual payment override transaction details, click Post. The offset
transaction is generated automatically and both transactions are posted to the account.
7 The Manual Payment Override window reappears. It includes the new manual payment override
transaction and displays an adjusted supplier sub-total.
8 You can repeat steps 3 to 7 to post additional manual payment override transactions, if required.
9 Click Exit to leave the control desk.
Selecting and Reviewing Transactions for Payment

Payment Selection and Review (PYS) allows you to select transactions and save them in a payment set
(which is one specific application of a saved set). The transactions in the set are marked with a Saved Set
Number.
This function also allows you to select a previously saved payment set, to review it, modify it, and send it to
Payment Run (PYR) for payment or authorization.

Creating a Payment Set (Saved Set)

To create a payment set:
1 From SunSystems, select Payment Selection and Review (PYS)
The Selection - Payment Selection and Review form is displayed.
2 Define the appropriate selection criteria and click OK.
The results are displayed on the Financials Inquiry results form.
3 On Financials Inquiry results form, select the transaction lines to be added to the new payment set. To
do this, hold down the Control key and click each line you want to select, or use the Shift and arrow keys
to select a contiguous group of lines. Click Review.
The transaction lines are displayed on the Control Desks In-Tray form.
4 Select the lines to be processed.
5 For the Report Process action, select Saved Set Process.
The Saved Set Details form is displayed.
A Saved Set Number is assigned automatically.
6 Enter a Comment as appropriate, and click OK to confirm you want to continue with the process.
7 When finished, click Exit to close the Control Desks In-Tray form, and click Re-enter Parameters or
Exit to close the Financials Inquiry form.
Removing Transactions from a Payment Set

To remove selected ledger transactions from an existing payment set:
1 From SunSystems, select Payment Selection and Review (PYS).
2 Enter the appropriate Saved Set Number, and click OK.
The transactions that pertain to that saved set are displayed in the results form.
3 Select the transaction lines to be removed, and click Review.
The Control Desks In-Tray form is displayed.
4 Select the lines again, and select Saved Set Process for the Report Process action.
Providing one or more of the selected lines are part of a saved set, the Saved Set Maintenance form is
displayed.
5 For the Saved Set Function, select Delete Selected Saved Set and click OK.
The 'Do you wish to remove' frame is activated.
6 Select either All instances of this Saved Set Reference to remove the whole saved set, or Selected
Items Only to remove the saved set reference from the transaction line(s) you have previously selected.
Note: This process removes the saved set reference from transactions, and optionally deletes the saved
set details. It does not delete any transactions.

Note: Transactions within a saved set that have subsequently been allocated or no longer fit the saved
set criteria are automatically removed from the saved set.
Splitting a Transaction within a Payment Set

You can split a transaction within a payment set into two transactions, so that only part of the original
transaction amount is retained within the payment set. A new transaction line is generated, containing the
amount you enter to split, and is excluded from the payment set.
Note: The split process uses Account Allocations (ACA) functionality. Therefore, you may be required to
select an appropriate Account Allocation form, and an appropriate Split form during the process, unless
you have previously checked the 'Don't ask me again' check boxes whilst selecting those forms.
The transactions that pertain to that saved set are displayed in the Financials Inquiry results form.
3 Select the transaction line to be split, and click Review.
4 Select the line again, and for the Report Process action, select Split Process.
The manual ledger allocation split process is initiated.
During the manual ledger allocation split, a new transaction line is generated, containing the split amount
you enter, and is excluded from the saved set. The transaction line containing the remainder amount
after the split remains within the saved set.
Sending a Payment Set for Payment or Authorization

The payment set can be sent to the payment process, which uses the same functionality as Payment Run,
except that in this case you are using a payment set to select which transaction are to be considered for
payment. If authorization has been set up for payments, then the saved set can be sent to be authorized.
The transactions that pertain to that saved set are displayed in the Financials Inquiry results form.
3 Click Review All.

4 Select the lines again, and for the Report Process action, select Payment Process.
The Payment Run form is displayed. With the exception of how you have selected the transactions to
be considered for payment, all the normal rules apply for Payment Run.
5 When you have entered details as appropriate on the Payment Run form, click Print to process the
payment.
If authorization is set up so that payments must be authorized, the payment set is sent to the appropriate
user team's Authorization In-Tray. The transactions remain in the saved set until they are authorized
and paid. Otherwise, if authorization is not being used, the transactions are paid and payment documents
generated if appropriate.
When the transactions are paid, the saved set number is automatically removed from all of the paid
transactions.
Using the Selection - Payment Selection and Review Form

The Selection - Payment Selection and Review form allows you to enter criteria for extracting the transactions
to be saved in a payment set, or saved set, so that they can be subsequently reviewed, modified, and paid. It
also allows you to review all the transactions in a payment set that has been previously saved, providing you
know the Saved Set Number.
Payment Selection and Review (PYS)

Account Code From/To
Enter the account or range of accounts from which the transactions are to be extracted. If you are selecting
all the transactions in a saved set, check the Select All check box.
Priority Rating
If you want to filter by priority rating enter it here, otherwise check the Select Blanks check box. A priority
code is used to group customers, suppliers and clients together for any reason.
Allocation Marker
If you want to filter by allocation marker enter it here, otherwise check the Select Blanks check box.
Saved Set Number

To extract all the transactions in a previously saved payment set, enter the saved set number here. Otherwise,
check the Select Blanks check box.
Collecting customer payments

Payment Collection Run (PYC) is used to settle the debit transactions on your debtors/receivables or client
accounts using an automatic bank payment collection facility, such as direct debit.

Payment Collection Run can create the bank payment file required to collect the payments electronically.
It also generates the ledger transactions required to post the payments to the debtors/receivables accounts,
and produces a payments file from which payment related documents can be printed, for example account
statements.
What is the Payment Collection Run?

The type of output produced by Payment Collection Run and the transactions it selects for payment, are
determined by the payment profile you select at run time.
You can use Payment Profiles (PYP) to define any number of profiles. Each profile can contain different
selection criteria, including account selection criteria, currency codes, due dates, and so on.
Before you use Payment Collection Run you should identify or define the payment profile that contains the
payment collection run selection criteria. You may also want to preview the payment collections.
Note: You must ensure the Payments/Debits field is set to Collection to allow the payment profile to be
used by the collection run.
What Does the Payment Collection Run Do?

Payment Collection Run performs the following tasks:
• it uses the selection criteria to locate the transactions due for collection.
• it produces a payment collection run details report that lists or summarizes the account transactions
selected for collection and shows the total number and amount of the collections being generated.
• it creates a payment file that contains all of the payment collection details. This file is used to produce
any payment documents required to support the payment collections.
• it generates and posts the ledger transactions required to record each payment collected on the
debtor/receivables or client accounts, any settlement discounts taken, and tax adjustments on the
discount.
• the payments are allocated against the transactions they are collecting using the allocation marker Paid.
This prevents them being reselected for collection and allows them to be archived. An allocation reference,
period and date are also entered on both sets of transactions.
• it optionally produces a bank transfer file, if the payment method is Bank.
When you run the Payment Collection Run, you can choose to produce the payment run details report only
and use this to verify that the correct payments are being collected.
Preparing for a Payment or Collection Run

Before you initiate a payment run, or payment collection run, you must identify the type of transactions you
want to select for payment or collection.
For example, you may want to pay all of the outstanding invoices due for payment by today, or only pay your
most critical suppliers, or only collect payments due in a particular currency.

You can produce the aged analysis reports to analyze the outstanding transactions by due date.
Note: In a multi-currency environment you may need to alter the Currency for Payments setting in Ledger
Setup (LES), depending on whether you want to produce or collect payments in the base currency or in
different transaction currencies.
If you are using payment stamps to group transactions for payment, you must assign the payment stamps
before you pass the transactions through to Payment Run for payment. Payment stamps are assigned via a
control desk.
Before you initiate the payment or payment collection run you must identify the payment profile that is
required. If a profile doesn't exist, you must create it using Payment Profiles (PYP).
Even if you select the transactions for payment via a control desk you must still identify the payment profile
to be used by Payment Run to produce the payment documents.
Previewing the Payments or Collections

You can preview the payments that are produced by a payment or payment collection run to ensure the
correct transactions are paid or collected. This is particularly recommended if you are using a new payment
profile.
To preview the payments or collections, you should set the Post Transactions option to No on Payment Run,
or Payment Collection Run. This produces the payment run details report which lists the transactions selected
for payment or collection.
You can use this report to check that the required payments are produced or collected.
Including or Excluding Transactions for Payment

You can include or exclude transactions for payment or collection by altering various details, depending on
the circumstances.
If you are using a payment profile to select the transactions, you can alter the payment run selection criteria,
for example by adjusting the Base Date for Payment or Base Date for Discount and the payment profile
selection criteria, for example by adjusting the selection ranges, or payment basis.
You can alter selected transaction details, for example to withhold a transaction by setting the allocation
marker or amending the due date.
You can use Account Allocations (ACA) to amend selected transaction details, for example to alter a
transaction's due date or allocation marker. You can also use it to split a transaction, for example if you want
to pay only part of an invoice you would split it according to the value you want to pay. You would also amend
the payment due date to delay the payment of the unpaid part of the invoice.
Note: If discount is allowed on a transaction selected for collection by Payment Collection Run, it is selected
for payment regardless of the payment due and discount due dates, and the discount is always allowed.

Initiating a Payment Collection Run

Payment Collection Run (PYC) is used to settle the debit transactions on your debtor/receivables or client
accounts using an automatic bank payment collection facility, such as direct debit. It can produce a bank
transfer file for electronic transmission. It can also trigger the creation of any necessary payment
documentation, for example in the form of remittances.
The payment collection run begins by using the payment profile, and run time selection criteria to identify
accounts to be considered for payment. It then uses the criteria to select the transactions on these accounts,
for which payment is to be collected.
You can choose to only print the payment listing by setting the Post Transactions option to No. This allows
you to review the proposed payment and make adjustments, if necessary.
The following steps are required to produce direct debit collection records using Payment Collection Run
(PYC):
1 Select Payment Collection Run (PYC).
You are warned if unposted journals exist on the Held Journals File. To review the held journals, select
No at the continue prompt to display the Ledger Entry Held Journals form (LEH). Otherwise, click Yes
to continue with the payment collection run regardless.
2 Select the payment profile and press Enter.
The profile details appear on the form and any run time selection are also displayed. A warning appears
if the payment documents for the previous payment collections generated using this payment profile
have not been printed using the Final Print option. If you choose to continue they are overwritten by
the payment details generated for this payment collection run.
3 Enter the following payment collection run form details:
• Any run time selection criteria requested by the payment profile, and press Enter.
• The ledger posting account details and press Enter.
4 If the payment method is Bank, the Payment Collection Run Bank Transfer dialog appears and you must
enter the bank transfer file details.
5 Select Action > Amend Consolidation if you do not want to consolidate the payment transactions, or
want to enter analysis codes against the payment transaction.
6 Select Action > Amend if you need to alter any of the payment collection run selection details.
7 Select Action > Print to initiate the payment collection process.
8 The Document Format Runtime Parameters form is displayed, to allow you to control the production
of the payment collection run details report. Enter the options as required and click OK.
9 The payment profile is checked for its Currency Rules settings, as the collection may require conversion
for one or more of the currency values. Depending on the setting of the Override Rates option, the
Currency Rates Override form may be displayed. If so, verify the exchange rates shown for each currency;
modify any as required, enter the Realized Gains/Losses Account(s) and click Print.
10 The payment collection process begins. The payment collection run details report is produced; the
postings are generated if the Post Transactions option is set to Yes, and the payment files are produced
if appropriate.
11 If the Post Transactions option is set to Yes and payment documents are required, the Payment
Documents form is displayed. This is used to produce the physical payment documents, for example
remittances.

Using Payment Collection Run

Payment Collection Run (PYC) is used to settle the debit transactions on your debtor/receivables or client
accounts using an automatic bank payment collection facility, such as direct debit. It can produce a bank
transfer file for electronic transmission.
When you use payment collection run you must identify a payment profile. This profile contains the selection
criteria that determine the transactions selected for payment collection.
A payment collection run begins by using the payment profile and run time selection criteria to identify
accounts to be considered for payment collection. It uses the criteria to select the transactions for which
payments are to be collected on these accounts.
A payment collection run always produces the payment run details report. If the Post Transactions option
is set to Yes, it also generates and posts the requested payment transactions.
Profile Code
The Payment Profile code that determines the selection criteria for the payment collection run. It also
determines any run time selection criteria required. This code is defined using Payment Profiles (PYP).
The payment profile must identify a Payment Method of Bank or Other, and the Payments/Debits field
must be set to Collections.
Post Transactions
Select Yes to generate and post the payment transactions, produce a payments file, set the allocation
marker to Paid on the selected transactions, produce the payment run details report and optionally
produce a bank transfer file. If provisional postings are optional, you can choose to post the transactions
as provisional. If this option is mandatory, then the transactions are always posted as provisional.
Select No to only produce the payment run details report showing the items selected for collection.
Suppress Report Transactions

Select this option to summarize the transactions on the payment run details report. If this option is not
selected, the payment run details report shows the payment and discount allowed on individual
transactions. If this option is chosen, a summary report is produced showing the total amount selected
for collection from each account.
Base Date for Collection

Transactions are selected for payment collection if their due date is on, or before, the date entered in
this field.
Collection Date
The date to be used as the transaction date for the debit transactions generated during this run. The
default is today's date.
Posting Period
The period to which the transactions generated during this run are to be posted. The default is the
current period.
Selections 1-5 From/To

Up to 5 run time selection criteria may be displayed. These criteria are determined by the payment
profile as defined using Payment Profiles Setup. For example, you may be asked to enter a range of

accounts and journal sources. A transaction must meet all of these selection criteria to be included in
the payment collection run.
Bank Details Code

The bank details record, as set up in Bank Details (BNK), for your own bank account. When you enter
a valid bank details code, the Collection Account field (below) displays the relevant chart of accounts
record for your bank account.
This field is mandatory for collections where the Payment Method is set to Bank on the payment profile.
If there is no Bank Details Code on the payment profile, and the Payment Method is set to Bank, then
you must enter it here.
Bank Subcode
The subcode, if used, on the bank details record identified in the field above. Otherwise leave blank.
Collection Account
The chart of accounts code to which the balancing, bank transactions for the collections are to be posted.
It would normally be a bank account. You cannot select a memo account. This account can be set on
the payment profile.
If you are collecting payments in more than one transaction currency, the Collection Account identified
for each currency in Currency Codes (CNC) is used. If a collection account has not been defined for a
Collection Account
The chart of accounts code to which the balancing, bank transactions for the collections are to be posted.
It would normally be a bank account. You cannot select a memo account. This account can be set on
the payment profile.
If you are collecting payments in more than one transaction currency, the Collection Account identified
for each currency in Currency Codes (CNC) is used. If a collection account has not been defined for a
2 The Payment Collection Run Bank Transfer details are required to create a bank transfer file from the
payment collection run. This form is only displayed if all of the system and run time settings have been
set to create a bank transfer file.
You can use the bank transfer file as input to another application or software package to collect the
payments using an automated settlement system.
Specify this information:
Bank Payments Processing Date
The date on which the settlements are to be processed by the bank. You cannot select a date earlier
than today's date. In the UK BACS normally requires a date not less than two days earlier and not more
than 40 days later than the date of transmission. This date can be reset or overwritten at the time of
transmission.
Default Bank Transaction Ref

This reference indicates the reason for payment. The customer's bank details can hold a reference. If it
does not, the reference entered here is used. You can leave this field blank. A reference is not mandatory
in the UK for BACS.

Ledger Payment Reference

You can enter a reference in this field which is applied to all transactions posted to the collection account.
There is no validation check on the reference entered. You can leave it blank.
Single Payment Check this check

Check this check box if you want to generate a single transaction to each collection bank account for
the receivables collected in this run. This option is necessary if you want to use consolidation to set or
consolidate analysis codes on the collection bank account transaction, as described below.
Leave this check box unchecked if you want each account paid to be recorded as a separate transaction
in the collection account.
Note: If you use this option you cannot use Payment Voiding to cancel a receipt from a single customer.
Bank File Identifier

This code is used as the file extension to the Bank File Name to identify the file for this run. This defaults
to the bank file identifier that was specified in the previous run with the same payment profile. If this is
the first run with this payment profile, it defaults to the bank file identifier specified in the profile, unless
that is blank, in which case it defaults to '01'.
Bank File Name

By default, this option is display only, showing the file name of the bank transfer file, including the
business unit code and the bank file identifier as the extension. If a file of this name already exists, you
are warned of this and given the choice to overwrite the file or to cancel the Payment Collection. Do
not overwrite the file unless you are certain it has been transferred successfully.
If this field is activated, you can enter a different path and file name for the bank transfer file. The path
can be a local drive, for example, c:\folder\, or a network location, for example, //computer01/output.
Network paths are not case sensitive, and can include '/' forward slashes or '\' back slashes. The file
path/name you enter is retained as the default for the next bank collection using this payment profile.
Note: In order to enter a file path/name during payment collection run, this field must be activated on
thePayment Collection Run Bank Transfer form. To do this, use Form Designer (FRD) to open the
SAGD44 form; click the Bank File Name control, and set the Enabled property value to True.
3 In Payment Collection Run, there are two types of analysis consolidation:

• Debtor / Client Analysis Codes consolidation
• Bank Analysis Codes consolidation.
Both types of consolidation refer to ledger analysis codes on the transaction lines generated by Payment
Collection Run, and are described below.
You can also use Business Rules to set or validate analysis codes on the generated transactions. To do
this, create an Event Profile that checks for a Function Code of Payment Collection Run, and use a Call
Point of either 00015 Populate or 00016 Validate Analysis on System Generated Transactions.
4 Click Amend Consolidation to display the Payment Collection Run Consolidation form for Debtor /
Client Analysis Codes.
Analysis Dimensions
The Payment Collection Run Consolidation form lists the analysis dimensions assigned to the ledger.
You can use this form to split the payment transaction for the receivables/debtor account according to
the analysis codes on the original transactions, or to apply new analysis to the payment collection
transactions.

Leave all of the analysis dimensions blank if you want to generate and post a single consolidated payment
collection transaction to each receivables/debtor account for the total amount collected from the debtor
in this run. This is the default option.
Enter '..' against an analysis dimension to generate payment collection transactions with the same
analysis codes (for that dimension) as the original receivable transactions being collected. This means
that there could be several payment collection transactions generated for a given debtor, if the original
transactions in the debtor account contain various different analysis codes for a dimension. These
analysis codes are also automatically entered on the corresponding bank account transactions, providing
you are not using the Single Transaction to Collection Account option (described above). Alternatively,
you can enter a specific analysis code for a dimension in order to set that code on the generated payment
collection transactions.
6 Click Exch Gain/Loss Analysis to display the Payment Collection Run Consolidation form for the
exchange gain / loss transaction analysis codes.
Analysis Dimensions
The Payment Collection Run Consolidation form lists the analysis dimensions assigned to the ledger.
You can use this form to assign analysis codes to any exchange gain / loss transactions generated by
currency payments.
Leave all of the analysis dimensions blank if you want to post a single consolidated transaction for each
exchange gain/loss difference generated. This is the default option. Alternatively, you can enter a specific
analysis code for a dimension in order to set that code on any exchange gain / loss transactions.
8 Click Bank Analysis to display the Payment Collection Run Consolidation form for Bank Analysis Codes.
The purpose of this function is to allow the setting of analysis codes on the bank account transaction
where Single Transaction to Collection Account is defined on the Payment Profile (PYP) or set on the
Payment Collection Run Bank Transfer form.
Note: Where payment collection is by transaction currency and multiple variable currencies are in use,
multiple bank lines are still generated according to those currencies. The payment collection lines are
also summarized according to the analysis you set, and depending on the settings, multiple grouped
lines may also result.
Analysis Dimensions
The Bank Analysis form lists the analysis dimensions assigned to the ledger. You can use this form to
determine analysis on the bank transaction, where the Single Transaction to Collection Account check
box is checked on the Payment Collection Run Bank Transfer form (as described above).

Leave all of the analysis dimensions blank to generate and post a single consolidated transaction to the
collection account for the total amount collected by this run. This is the default option, providing the
Single Transaction to Collection Account option is set.
You can enter a specific analysis code for a dimension in order to set that code on the generated bank
transaction(s).
Additionally you can enter '..' against an analysis dimension to generate bank transactions with the
same analysis codes (for that dimension) as the debtor / client side of the collection transaction. In this
case, it is possible for several bank transactions to be generated, according to the common groupings
of analysis codes.
Note: If you enter'..' for an analysis dimension, in order to copy that dimension's analysis codes from
the debtor / client transaction lines you must first enter an option for the dimension on the Payment
Collection Run Consolidation form for Debtor / Client Analysis Codes. To do this, click Amend
Consolidation, as described above.
Payment documents
Payment documents refer to any printed output required to support a payment produced by Payment Run
(PYR) or collected by Payment Collection Run (PYC). This typically includes cheques and remittance advice
but can also include any other type of printed payment schedule or output required.
Payment documents are defined using Report Designer in SunSystems Reporting Services. A document
format is required to link the report executable to the appropriate payment run or payment collection run.
You can produce different types of payment document, for different types of payments. For example, you
might want to produce remittance advice in the appropriate language, and only produce combined
cheque/remittance advice for payments made in the base currency.
You use Payment Documents (PYD) to request the production of the payment documents for a particular
payment run or payment collection run. You can choose to only print the documents for a range of accounts,
a particular currency, a payment method or an account holder. For example, you may need to change the
stationery for different currencies or accounts.
The documents themselves are printed using the standard SunSystems report printing facility. This allows
you to print test documents, print the documents as draft or final output, and reprint the documents.
Note: You can also produce statements or other account related documents to send to your customers or
suppliers. Account documents typically list all, or selected, transactions on an account.
Printing Documents in Another Currency

You can create remittance formats that include foreign currency amounts and currency codes.

The Currency Code field is displayed only if the Currency for Payments field is set to Transaction Currency
in Ledger Setup (LES). In other words, this field only appears if you are generating payments by currency.
What Payment Documents are Available?

SunSystems Financials includes predefined payment documents for cheques and remittance advice notes.
These are formatted using the SunSystems (SRS) Report Designer which means they can be tailored to your
individual organization's requirements. In addition, you can use Report Designer to produce your own
payment documents.
A document format is required for each payment document to identify the report executable (.srdl) and set
the print request options and defaults. The following document formats identify the predefined payment
documents.
Predefined Payment Document Document Format Single Payments Document

Format
Remittances with Cheques attached APD3 APD-S3
Remittances with Bank File APD4
These document formats use the SRS example reports; however, it is recommended that you design your
own reports for payment documents using Report Designer, to incorporate your organization's requirements
and stationery constraints, and so on. You can base your report formats on the SRS example reports.
The document formats listed above can be used to print the payment documents for payment runs with a
Payment Method of Cheque, Bank or Other.
The single payment document format can be used for payment runs with a Payment Methodof Single
Payment. This payment method is used to make miscellaneous payments. These single payment document
formats obtain the payee name from the description field on each transaction. See 'How is the Payment
Method Used?'.
Single payment runs produce a separate payment for each transaction selected for payment, rather than for
each account.
Remittance Advice Details

The predefined, standard remittance advice identifies the supplier or customer name and address, your
organization name and address, the account code and name, and the remittance date at the top of the advice.
It then lists the transactions included in the payment. For each transaction it prints the transaction date,
transaction reference, description, debit or credit amount. Finally, it prints the total payment amount.
If the payment has been produced in the transaction currency, the remittance advice prints the transaction
currency amounts and identifies the currency alongside the payment total. If payments have been produced
in different currencies for the same account, separate remittance advice notes are printed for each currency.
Note: Your organization's name and address is taken from address code 0000000000 which is defined using
Addresses (ADD).

Separate Remittances and Cheques

If you require separate cheques and remittance advice notes, use Report Designer to create the two separate
report formats, based on the FPPD1.srdl example report. Then, you must create two new document formats,
one for cheques only and the other for remittances only.
You should print the remittances first by running Payment Documents (PYD) with your first new document
format. This will print remittance advice notes for all of the accounts selected for payment in Payment Run
(PYR). This includes remittances for any accounts where the transactions selected for payment resulted in a
zero or debit (negative) balance.
After you have printed the remittances, you should print the cheques. You should run Payment Documents
(PYD) selecting your second new document format, and choosing the Reprint and Final Print options.
Combined Remittances and Cheques

If you are using remittance stationery with a tear-off cheque portion, the default SunSystems combined
cheque/remittance format prints the cheque immediately below the associated remittance. If an account
has a zero or debit balance, VOID is printed over the cheque portion.
If a remittance runs over more than one page, VOID is printed over all the cheques except the last. You should
destroy these cheques, and any used for alignment of the stationery in the printer.
Cheque Details
The cheques produced by the default payment documents referenced above use a predefined, sample cheque
layout. This layout prints the payment (document) date followed by the supplier name. Beneath this it prints
the cheque amount in words and then as a number.
If a payment document reference number, for example cheque number, is being printed this appears on
another line below the value line.
When the cheque amount is printed as a value, asterisks are printed before and after the numbers for security,
for example **43,511.65**.
To print the amount in words the value is converted into the following factors of ten and it is assumed that
these factors are preprinted as headings on the cheque stationery:
• Hundred Millions
• Ten Millions
• Millions
• Hundred Thousands
• Ten Thousands
• Thousands
• Hundreds
• Tens
• Units
• Decimals.
The amount that applies to each factor of ten is printed in words, except the Decimals which are printed as
a number.

For example, a value of 43511.65 is printed as follows: Zero Zero Zero Four Three Five One One 65.
Note: You can use document format APD4 to output the cheque details to a separate text file. For example,
you may want to use this file as input to a specialized cheque printing package. The default settings for the
text output from APD4 assume that Post Single Transaction to Payment Account is set to Mandatory within
Payment Profiles (PYP) and this is required for accurate content. The format of the text file, and its name
and location are all determined by Report Designer.
Producing Payment Documents

Payment Run and Payment Collection Run produce a payments file that contains the details of all of the
payments or collections generated in the run. This file can be used to produce physical payment documents
to support the payments or payment collections generated, if they are required.
Payment Documents (PYD) is used to produce these payment documents. This form appears automatically
at the end of a payment run, or it can be run independently from the SunSystems menu.
You can choose to print payment documents for only some of the payments generated. For example, you
may want to print the documents by currency and apply different payment document formats for each.
Note: Regardless of whether or not you print payment documents for a payment run, the payment run has
posted the payment transactions to the ledger to record all of the payments.
The following steps are required to produce the payment documents:
1 If necessary, access Payment Documents (PYD) from SunSystems.
2 Enter or query the payment profile used to generate the payments and press Enter.
3 Enter the range of accounts, currency and selection criteria to determine the payment documents you
want to print, if applicable.
4 Select Action > Print.
The standard document format print request form is displayed to allow you to control the production of
the payment documents.
5 The Document Format Code at the top of this form determines the type of payment documents to be
printed. If a document format code has been entered on the chosen payment profile, it is displayed here
and cannot be changed. However, if a document format code has not been entered on the payment
profile, then the last document format code used to produce payment documents for the chosen payment
profile is displayed. If this is not the document format code you want to use, click Cancel to access this
field and choose the required document format.
6 Enter the remaining print request details. In particular you should pay attention to the following fields:
Request fields Description
Print Options if the Final Print option is not set, a draft version of the documents is
produced. For example, for the predefined formats this inserts the word DRAFT
in large characters at the top of each document.
Print Test Page select this if you are printing on special stationery and want to check the paper
is aligned correctly.

Request fields Description

Document Date this is used as the posting date for the payment transactions and is the date
printed on the remittance and cheque, if applicable.
Data Settings Cheque numbers for Payment Documents - this displays the next cheque number
to be printed and can be used to override this providing the document format
allows this.
Note: If the payment documents to be printed include a system assigned
transaction reference number, for example a cheque number, do not proceed
if you have not set the correct starting reference number.
Using Payment Documents

Payment Documents (PYD) is used to produce the payment documents required to support a Payment Run
(PYR) or Payment Collection Run (PYC).
The Payment Documents form appears automatically at the end of a Payment Run, to allow you to print
the required documents. It can also be run independently, from the SunSystems menu, for example if you
want to print the documents at a later stage or need to reprint the documents.
You can choose to print payment documents for only some of the payments generated. For example, you
may want to print the documents by currency and apply different payment document formats for each.
Payment Documents (PYD)

Payment Profile Code
The code of the payment profile that was selected in the Payment Run (PYR), or Payment Collection Run
(PYC), to produce the payments.

The range of accounts, from the payment run, for which payment documents are printed. To include all
account codes for which payments have been generated, leave these fields blank. Otherwise, enter the
account code or range of account codes for which you want to produce remittances.
Currency Code
The currency code for which you want to print payment documents.
Account Holder
If the payments for several accounts have been consolidated by account holder, enter a valid account holder
code to only print account documents for payments to this account holder.
Payment Method
Select the payment method for which documents are to be printed.

Printing on Special Stationery

Payment documents and statements often need to be printed on preprinted stationery, for example remittance
advices, cheques and statements. When this is the case there are a number of additional printing techniques
you may need to use.
Note: Many of the following print options may be preset by the document format using Document Format
(DFS).
Aligning Stationery
When you are printing onto preprinted stationery it is important that the paper is positioned correctly in the
printer. This is to ensure the details are printed in the correct place on the stationery, for example if the cheque
value is printed in words within preprinted value boxes.
You can use the Print Test Page option in the document format report parameters form to print a test page.
This page contains a series of XXXs wherever information would normally be printed for the appropriate
payment document. This allows you to ensure the details appear in the correct place on the paper.
After a test page has been produced, the document format report parameters form reappears with the default
settings. You can adjust the stationery as necessary and repeat the process, until the alignment is correct.
When you are satisfied, you should select the normal print options.
Assigning Pre-Printed Reference Numbers

If your special stationery includes a pre-printed reference number, for example cheque numbers, you can
use this number as the payment reference on the payment transactions generated.
Reprinting Payment Documents

You can reprint all, or some, of your remittance advices and cheques as many times as you want, until the
next Payment Run with the appropriate payment run rule.
Assigning Payment Document Reference Numbers

SunSystems can optionally generate and assign a unique transaction reference to each payment document
it produces. This transaction reference is updated onto the payment transaction and provides a useful audit
control.
This facility is particularly useful if you are printing documents on pre-numbered stationery, for example if
you are printing cheques where a cheque number has been preprinted on the stationery. It allows you to
ensure the system assigns the correct number to the payment transaction.
Payment document transaction reference numbers are generated if a transaction reference format is identified
for the document format in Document Format (DFS).
The transaction reference format is defined using Transaction References (TRS). This determines the format
of the reference number and how it is generated.

The reference number can be generated automatically as a numbered sequence, for example for cheque
numbers. Alternatively, it can be preset to a constant value.
If a numbered sequence is required, the details are defined and controlled using Number Streams (NSS).
Setting the Reference Number

If transaction reference numbers are being assigned to payment documents, you can use Number Streams
(NSS) to view and set the next number to be used.
For example, if you are printing cheques on preprinted stationery that includes the cheque number, you must
set the Next Sequence Number to identify the first cheque number in the cheque stationery being used for
a payment run.
This next sequence number can be set by the user at run time, before the payment documents are printed,
if the Next Number Override option is set for the payment document on Document Format (DFS).
Note: If you are printing test pages you must still enter the first cheque number available even though this
cheque is voided by the test print.
Updating the Transaction Reference

The transaction reference number that is assigned to a payment document can optionally be stored as the
transaction reference on the payment transactions generated and posted by Payment Run or Payment
Collection Run.
This is controlled by setting the Update Document Details field on Document Format (DFS) for the payment
document to Transaction Reference will be Updated.
Account Documents
An account document lists all, or selected, transactions for an account.
A common example of an account document is a customer statement which lists a customer's outstanding
items. You can produce account documents for any type of account, although normally you print them for
debtor, creditor, or client accounts.
The Account Documents (ACD) function is used to produce account documents for selected account
transactions, in a selected document format. There are two predefined account document formats available,
one for a single currency environment and one for a multi-currency environment. These have been designed
as customer statements. These formats are produced using Report Designer so you can amend them to suit
your own requirements, or define your own alternative layouts.
When you use Accounts Documents (ACD), all of documents are produced using the same document format,
and the documents use each account's default address.
Transactions generated during Ledger Revaluation (LER) are excluded from documents. This means that
the document reflects the amounts due in all of the transaction currencies, at the original entry date.
In addition, any transactions generated by Ledger Cleardown (LCL) are also excluded.

Account Documents summarizes transactions that have the same:

• Transaction Reference
• Journal Number
• Allocation Indicator
• Debit/Credit Indicator
• Currency Code
Producing Account Documents

The Account Documents function is used to produce account documents or other formatted transaction lists
for a selected range of debtors. The transactions to be printed are selected using a predefined control desk.
If you use Account Documents (ACD), the same account document format is used for all of the documents
produced by this function.
The following steps are required to produce the account documents using Account Documents (ACD):
1 Access Account Documents (ACD) from SunSystems and enter the selection criteria to determine the
accounts and transactions to be printed on the documents, and select OK.
2 The selected transactions are listed on the Financial-Account Inquiry control desk window.
3 Highlight the account transactions you want to print on the account documents, and select Action >
Review, or click the Review button. Alternatively select Action > Review All to include all of the
transactions.
4 The selected transactions appear on the Control Desk In-Tray. Select the Print Account Documents
option as the Report Process and click OK.
5 The standard document format parameter request form appears to allow you to control the production
of the documents.
Using Account Documents

The Account Documents (ACD) function is used to select the account transactions to be included on account
documents.
Only open transactions are selected and transactions generated by Ledger Revaluation (LER) or Ledger
Cleardown (LCL) are not selected.
Account Documents (ACD)

Allocation Marker
Transactions can be included with any of the following allocation markers: Not Allocated, Split or To Be
Allocated. Select one or more allocation markers, or select the All option to include transactions with any
of these markers.
Account Type
Select one or more type of account for which documents are to be printed.

Accounting Period From/To

The range of accounting periods for which you want to include transactions on the document. You also select
a future period if required.

The account, or range of accounts, for which you want to produce documents. Leave these fields blank to
select the All option and print documents for all accounts.
Due Date From/To

The due date, or range of due dates, for which transactions are to be included on the documents. Leave these
fields blank to select the All option and include transactions with any due date.
Provisional Posting Status

If provisional postings are optional or mandatory, choose whether or not provisional postings should be
included on the documents.
Authorization in Progress
Select this option to include transactions that are still going through the authorization process.

Maintaining budgets
Chapter 8: Maintaining budgets
Budget values are entered onto accounts as budget transactions, in the same way as ledger transactions are
posted to ledger accounts.
A budget can be held as a total for the year, entered into any of the periods available. Alternatively, the budget
can be spread across the periods in the year.
Entering Budget Values

Budget values are subject to the same journal validation, balancing and posting rules. The budget transactions
are maintained to provide a full budget audit trial.
To use budget checking, you must first set up Budget Check Setup records.
Budget values can be entered onto the budget ledger using any of the following methods:
• Ledger Entry (LEN)
• Ledger Import (LIM)
• Corporate Allocation Run (CAL)
Note: Before you use any of these methods to load budget values, you must use Change Budget (CBG) to
access the budget ledger. The budget ledger is the ledger defined as the Primary Budget Ledger in the
Business Unit Setup.
Budget transactions can be entered onto a budget ledger using Ledger Entry (LEN) in the same way as you
would enter actual transactions. However, you may also prepare your budget file in a spreadsheet package,
and then transfer the data to the budget ledger using Ledger Import (LIM).
Budgets can be as detailed as you require. You can create budgets for individual accounts by posting directly
to these accounts.
If you report against budget on a summary basis, you can enter the budget for a range of accounts in any one
account. For example, if you always report sales accounts as a range, you might set the budget in the first
sales account in the budget ledger.
Budgets can also be entered by analysis code, for example, by department or project. To enter the budget
for an analysis code or analysis code combination, you post a transaction to the budget account for the
appropriate budget amount and reference the analysis codes on the transaction.
If you want to set a budget by analysis code only, you should post the budget to a single account and point
all of the relevant actual accounts to this one budget account.

Maintaining budgets
When entering the budget into the ledger, budget records are created for the unique combination of the
following:
• Account Code - this must be the Budget Check Account defined on the Budget Check Setup.
• Period
• Analysis Code 1 (optional - dependent on the Budget Check Setup)
The above details are taken from the journal when posted. The normal Chart of Account and Journal Type
rules apply, so care must be taken with mandatory, optional, prohibited analysis and so on. Budgets must
be entered in the base currency.
On posting the journal, entries are made in the Primary Budget Ledger, and also in the budgeting tables.
The budgeting tables are used by the budget checking functionality. The Primary Budget Ledger is then
used for reference only.
For purchase orders and purchase invoices, amounts are entered as debit amounts. The following is an
example of a journal entry:
Account Analysis Period Amount D/C

Line creating Budget check ac- Optional Period in which the Budget amount for D
budget check count code budget is entered that period
records
Balancing line Miscellaneous ac- Not rele- Period in which the Budget amount for C
count code vant budget is entered that period
Example 1 of a budget:
Account Period Budget

A 11/2005 USD 100
A 12/2005 USD 150
A 01/2006 USD 200
A 02/2006 USD 100
and so on
A 12/2006 USD 100
B 11/2005 USD 100
B 12/2005 USD 100
B 01/2006 USD 150
and so on

Maintaining budgets
Example 2 of a budget:
Account Period Analysis Code 1 Budget

A 11/2005 Dept A USD 100
A 11/2005 Dept B USD 100
A 12/2005 Dept A USD 150
A 12/2005 Dept B USD 100
A 01/2006 Dept A USD 200
A 01/2006 Dept B USD 200
A 02/2006 Dept A None
A 02/2006 Dept B USD 150
and so on
Reallocating budgets
Budget amounts can be moved between accounts, account and analysis combinations or periods.
A journal is entered to credit the source budget and debit the target budget.
For example, if budget is to be moved from Account A Period 04/2006, to Account B Period 03/2006, the
following journal must be created:
Account Analysis Period Amount D/C

A 04/2006 USD 100 C
Miscellaneous Account 04/2006 USD 100 D
B 03/2006 USD 100 D
Miscellaneous Account 03/2006 USD 100 C
Note: You should not move more than the available budget for that period because you will cause an overspend
against the budget. The available budget is calculated as: available budget = budget - committed expenditure
- actual expenditure.
Manual budget entry

You can use standard journal types to enter budgets.
However, it is advisable to define separate journal types specifically for entering budgets, so that they can
be easily differentiated.

Maintaining budgets
Note: Budget journals are subject to normal double entry controls so you may want to define a budget
suspense account and use this as the account on the balancing postings for all budget journals.
Predefining budget transactions

Journal Presets (JNP) can help you to speed up the entry of budget transactions.
The following may be useful if you want to enter an annual figure and spread it over each period in the financial
year:
1 The first preset line is a nonposting line, on which you enter the annual budget amount.
2 You may define any number of subsequent lines, one for each period, each of which are to be assigned
an equal share of the annual budget. Enter 1R in the Amount field.
3 It is advisable that the line corresponding to the last period of the year acts as a rounding period. Enter
1RU in the Amount field to achieve this.
4 The balancing entry lines for each period can have the Debit/Credit field set to Period. This sets the value
for the line to the period balancing amount, to ensure that entries for each period sum to zero. For a
budget spread over 12 accounting periods, therefore, you have a non-posting line, plus 12 debit and 12
credit posting lines.
Journal presets can cater for budgets that are not spread evenly throughout the year. You can enter the
appropriate ratio to be applied for each period in the Amount field.
Generating budgets in a spreadsheet

Most spreadsheet packages output a file in a format suitable for SunSystems Financials.
You should refer to the Ledger Import for details of the required file layout.

Intercompany posting
Chapter 9: Intercompany posting
Intercompany Posting allows you to post journals across business units and business unit groups.
You can create intercompany entries in Ledger Entry or Transfer desk by using an intercompany journal type.
The Intercompany Posting option within the Intercompany Awaiting Posting Inquiry enables you to post the
transactions from the source business unit to the target business unit.
Some example Intercompany Posting scenarios are as follows:
• Transferring inventory from one company to another
• Recharging expenses
• Selling goods or services
• Cash payments
• Intercompany loans
• Automatic cash receipt and matching in a shared service centre type operation.
Understanding the Intercompany Posting Process

Intercompany Posting journals are posted in Ledger Entry or Ledger Import. Journals are created in the source
business unit and posted to the target business unit. The journal type must be set to use Intercompany
Postings and a Ledger Interface needs to be created to map the journal details between the source and target
business units. Intercompany journals can only be posted to the Actuals Ledger.
If you have selected to use the Intercompany Automatic Posting option in the source journal type, journals
posted in the source business unit via Ledger Entry, Ledger Import or Transfer Desk are automatically posted
to the target business unit. Ledger Interface must be setup to include a credit or debit line to the required
account recognition code to generate the opposite debit or credit line in the target business unit.
Note: Provisionally posted intercompany journals are not automatically posted to the target business unit.
Intercompany Posting Workflow Example

In this scenario a Parent Company makes a payment on behalf of a Subsidiary Company. The Parent Company
is designated as source business unit SU1. The Subsidiary Company is designated as target business unit TU1.

1 In the Subsidiary Company target business unit TU1, select Ledger Interface Account Recognition
Codes (LIA) from the SunSystems menu.
2 Create an Account Recognition Code A01.
3 Select the Business Account Code for the Account Recognition Type.
4 In Business Account Codes (BAC) create the details for the Account Recognition Code A01.
5 In the Misc Analysis Code field enter the source account code.
6 In the Account Code Analysis field enter the target account code.
Misc Analysis Code (source account code) Account Code Analysis (target account code)
SAC01 TAC01
SCASH TAR
7 In the Subsidiary Company target business unit TU1, select Ledger Interface (LIS) from the SunSystems
menu,
8 Create a Ledger Interface Defn Code INCO.
9 Set the Module to Intercompany.
10 In the Batch or Online Posting field select Online.
11 In the Target Ledger field select A.
12 Ensure the Journal TypeBatch field contains a journal that is not an Intercompany Journal Type, for
example FGJ.
13 Select External/Business Line Import Values as the Ledger Interface Value Type.
14 Click Line Details.
15 Setup one detail line to credit the Account Recognition Code A01.
Table 1:
Line Account Recognition Code Debit/Credit

1 A01 Credit
Note: A debit transaction line in the source business unit creates a credit transaction line in the target
business unit. Similarly, a credit transaction line in the source business unit creates a debit transaction
line in the target business unit.
Note: When setting up the Ledger Interface you must ensure that the resulting journals balance by
specifying the correct values for the credits and debits.
16 Match the Value with the corresponding Business Line Import Value.
17 Select the Business Line Import tab.
18 Select the Value tab.
19 Select Business Line Import Value 2 from the Transaction drop down list.
Note: The import value is directly inserted into the target value. Ensure that the source value has the
same currency as the target value. Alternatively map the transaction value from the source transaction
value to insert the transaction currency code.

Table 2:
Value Txn
Business Line Import Value 2
20 If required set the Analysis Suppression or Transfer Data Codes.

21 In the Parent Company source business unit SU1, select Journal Type (JNT) from the SunSystems menu.
22 Create an Intercompany Posting Journal Type INTER.
23 From the Intercompany Type tab select the Intercompany Type checkbox.
24 Enter TU1 as the Target Business Unit Code.
25 Select the Target Ldg Interface Defn Code INCO.
26 Tick the Intercompany Automatic Posting checkbox to automatically post intercompany journals from
the source business unit to the target business unit.
27 In the Parent Company business unit SU1, select Ledger Entry (LEN) from the SunSystems menu.
28 Enter and post a journal using the Intercompany Posting Journal Type INTER.
Table 3:
Journal Journal Transac- Account Transac- Base Debit/Cred-

Line No. Type tion Ref Code tion Curren- Amount it
cy Code
1 INTER ICO1 SAC01 GBP 100 Credit
2 INTER ICO1 SCASH GBP 100 Debit
29 If you have selected Intercompany Automatic Posting in the source business unit Journal Type (JNT),
the journal is automatically posted to the target business unit.
Table 4:

cy Code
1 FGJ ICO1 TAC01 GBP 100 Debit
2 FGJ ICO1 TAR GBP 100 Credit
30 If you have not selected Intercompany Automatic Posting in the source business unit Journal Type
(JNT), when the journal is posted, the data is automatically inserted into the Business Line Import tables
and the Intercompany Posting Status is updated to Awaiting Posting.
31 To post the Intercompany Posting transactions to the Subsidiary Company target business unit TU1,
select Intercompany Awaiting Posting Inquiry.
32 Enter the journal number(s) and click OK to display the Intercompany Posting transactions that have a
status of Awaiting Posting.
33 Select Review or Review All.

34 From the Report Process field select Intercompany Posting.

35 Click OK.
The Intercompany Posting journals are hard posted to the Subsidiary Company target business unit TU1.
36 Use Ledger Interface Line Details to post multiple intercompany journal lines to the target business unit.
37 Setup multiple lines with a credit line to the intercompany account and a debit line to the contra accounts.
Table 5:
Journal Line No. Account Code Debit/Credit

1 TAC01 (target intercompany ac- Credit
count)
2 TAR Debit
38 In this example a debit journal line posted to the intercompany account in the source business unit posts
a credit journal line to the corresponding intercompany account in the target business unit and vice
versa.
You can use a fixed account code or an account recognition code.
39 In the source business unit select Ledger Entry (LEN) from the qu menu.
40 Create the intercompany entries:
Table 6:

cy Code
1 INTER ICO1 SAC01 GBP 100 Credit
2 INTER ICO1 SCASH GBP 100 Debit
41 Extract the journal through Intercompany Awaiting Posting and select only the intercompany account
line (SAC01 100 Credit) to run intercompany posting.
An intercompany journal is generated in the target business unit per the eline details specified in the
target ledger interface.
Table 7:

cy Code
1 FGJ ICO1 TAC01 GBP 100 Debit
2 FGJ ICO1 TAR GBP 100 Credit.
Note: If you are using automatic intercompany posting you can only post the full journal, not selected
journal lines.

Intercompany Posting Status

There are five types of intercompany posting statuses:
• Awaiting Posting - If transactions are posted in the source business unit with an intercompany journal
type, the Intercompany Posting Status is updated to Awaiting Posting. Only the Awaiting Posting status
can be run for the Intercompany Posting process. If the intercompany posting failed validation in the
source business unit, the Intercompany Posting Status remains as Awaiting Posting.
• Posted - If intercompany posting transactions are posted into the target business unit successfully, the
Intercompany Posting Status is updated to Posted in both the source and target business unit. If
transactions are re-posted successfully in the target business unit, for example, hard posted, provisionally
posted, held or batch posted intercompany journals, the Intercompany Posting Status is updated to
Posted in both the source and target business unit.
• Posting Failed - If intercompany posting fails validation in the target business unit, the Intercompany
Posting Status is updated to Posting Failed in the source business unit. Run Recover Failed Posting
(RFP) on the target business unit to correct the journal and re-post or cancel it.
• Sent - If the journal is provisionally posted, held or batch posted intercompany journals in the target
business unit, or if the target journal type enables authorization, the Intercompany Posting Status is
updated to Sent in the source business unit. You can hard post them in the target business unit.
• Cancelled - If you run the Cancel Intercompany Posting process for the transaction in the source business
unit, the Intercompany Posting Status is update to Cancelled. If the failed posting is cleared in Recover
Failed Posting (RFP) in the target business unit, the Intercompany Posting Status is updated to
Cancelled.

Re-allocating costs and revenue
Chapter 10: Re-allocating costs and revenue
You can re-allocate costs and revenue using the Corporate Allocation Run (CAL) and Corporate Allocation
Setup (CAD) functions.
Corporate Allocation Run (CAL) is used to perform an allocation. The allocation is identified by the Allocation
Setup code defined using Corporate Allocation Setup (CAD).
Understanding the Corporate Allocations Run

Corporate Allocation Run (CAL) creates target transactions based on the allocation details defined using
Corporate Allocation Setup (CAD). You can choose a range of periods for which an allocation is to be run.
You can also choose to post, or simply to report on, the results of an allocation run.
The allocation run process validates the allocation rule details.
Allocation Run produces a report which lists all of the allocations made, and indicates if any errors have been
found during processing.
The transactions generated by an allocation are posted by Ledger Import either immediately in real-time,
or at a later stage manually.
If the generated transactions are posted immediately, a Ledger Import report is also produced which shows
the status of the imported transactions.
Note: The allocation marker is ignored when generating target transactions.
Consolidating Source Transactions

When you run an Allocation Run, the source transactions are consolidated where possible, for posting to the
target accounts. Transactions with the same period, currency code and/or analysis codes are automatically
consolidated for posting to the target accounts.
If a range of periods is selected, then the source period is ignored and any period based amounts on the
source or ratio definition are combined for the target postings.

Validating Corporate Allocations

A corporate allocation is validated in two stages:
1 The first stage is to check the combined allocation parameters for consistency. That is, the allocation
setup, allocation source, allocation target and allocation ratio details. If an error is discovered during
this stage, the allocation run is abandoned and the allocation report lists the errors found.
2 The second validation step is carried out for each allocation sequence in the rule. If transactions are
created for posting to the source business unit, then these are verified first.
When the Target Posting field in Corporate Allocation Setup (CAD) is set to Direct, then the target business
unit is checked to ensure that the transactions can be posted automatically by Ledger Import (LIM).
The transaction date for postings generated by Corporate Allocation Run (CAL) is taken from the last date
of the range of source transactions, unless the Posting Detail option is set to All At Transaction Levelin
Corporate Allocation Setup (CAD).
Retaining Information from Source Transactions

Some of the Posting Detail options in Corporate Allocation Setup allow Corporate Allocation Run to create
target source reversal and/or offset transactions from each individual source transaction, rather than combining
the analysis and conversion codes.
If the Posting Detail options in Corporate Allocation Setup are set to All At Transaction Level or Target At
Transaction Level, then the following information may be retained from the source transactions:
Data Taken From May be Changed by

Transaction Date Retained from the source transac- No
tions
Transaction Reference Retained from the source transac- No
tions
Description Retained from the source transac- No
tions
Due Date Retained from the source transac- No
tions
Account Code Retained from the source transac- Target Account field in Corporate Alloca-
tions but not for offsets tion Targets
Period Retained from the source transac- Target Period From/To field in Corporate
tions Allocations Setup, Retain Source Posting
Period field in Corporate Allocation
Sources, also Accounting Period From/To
fields in Corporate Allocation Run
Base Amount and Transac- Retained from the source transac- Value 1 Source and Value 2 Source fields
tion Amount tions in Corporate Allocations Setup can be
set to swap the values, or split using
Corporate Allocation Ratios

Debit/Credit Retained from the source transac- Amount Reversal field in Corporate Allo-
tions cations Setup
Journal Type Retained from the source transac- Retain Journal Type field in Corporate
tions Allocations Setup. The status on the
journal type must be either Open or
Hidden.
Journal Source Retained from the source transac- Retain Journal Source field in Corporate
tions Allocations Setup
Asset Code, Subcode, and Retained from the source transac- Update Assets field in Corporate Alloca-
Asset Value/Depreciation tions tions Setup, and the entries in Corporate
Indicator (Update Method) Allocation Targets
Currency Code Retained from the source transac- Unless swapped in Corporate Allocations
tions Setup
Analysis Codes Retained from the source transac- Unless consolidated or amended by
tions Corporate Allocation Ratios
Journal Number Generated by Ledger Import No
Journal Line Number Generated by Ledger Import No
Allocation Marker blank No
Entry Date and Period Generated by Ledger Import No
Allocation Reference, Date Imported as zero, shown as blank No
and Period
Conversion Rate Generated by Ledger Import No
Provisional Flag Generated by Ledger Import Post Transactions field in Corporate Allo-
cation Run
Posting Date Generated by Ledger Import Post Transactions field in Corporate Allo-
cation Run
Checking for Errors

A Ledger Import report is created for each Corporate Allocation Run, whether or not the transactions are
posted. This report enables you to check individual transactions for errors that may have arisen.
Running an Allocation
Corporate Allocation Run (CAL) is used to perform an allocation. The allocation is identified by the Allocation
Setup code defined using Corporate Allocation Setup (CAD).

An allocation setup can consist of a number of steps which are identified by sequence numbers and run in
sequence number order. You can choose to run all of the sequences for an allocation, or to run a selected
range of sequences.
Note: If the allocation run finds no data to process, but journals have been posted in the period range being
processed, this can be caused if you are using an allocation source or allocation ratio setup that specifies
Change in Balance as the option for Source Amount or Ratio Amount.
Allocation Setup Code
The Allocation Setup code that identifies the allocation you want to run. This must have been defined
using Corporate Allocation Setup (CAD).
Allocation Sequence Number From/To

The range of allocation sequence numbers to be included in the allocation run. If you do not select a
number range, all the allocation sequence numbers are run.
Period From/To
The single period, or range of periods, for which this allocation is to be run. The default is the current
period. This is used in conjunction with the Source Amount chosen on the Allocation Source and
Allocation Ratio, to determine the amount used as the basis for the allocation calculations.
When an allocation is run, the source transactions are consolidated where possible, for posting to the
target accounts. Transactions with the same period, currency code or analysis codes are automatically
consolidated for posting to the target accounts.
If a range of periods is selected, then the source period is ignored and any period based amounts on the
source or ratio definition are combined for the target postings.
Post Transactions
You can select Yes to post the target transactions as part of the allocation run, or No to simply validate
and report on the transactions without posting them. In both cases the Allocation Run and Ledger Import
reports are produced. The Allocation Run report prints all of the allocation details. The Ledger Import
report lists the generated transactions and identifies any validation errors.
If you select Yes and no errors are found, the postings are made in real-time by the Ledger Import process
and a new journal number is generated. This journal number is printed on the Allocation Run report.
If you select No the Allocation Run and Ledger Import reports are produced, but the generated target
transactions are not posted. The first time you run an allocation you should select No to check that the
allocation has allocated the costs to your requirements.
Process as Provisional
You can choose to post the allocation target transactions as provisional, if the Provisional Postings
option in Ledger Setup (LES) is set to Optional.
Allow Balancing Transactions

Select Yes if you want to allow system generated differences to be posted to a suspense account to
ensure the allocations transactions are posted by Ledger Import (LIM). This option is particularly
important in a multi-currency environment to prevent a small currency conversion rounding discrepancy
stopping the journal being posted.
This options sets the Allow Bal Txns When Post if no Err option in Ledger Import. It overrides the Post
if no Error option that prevents posting if errors are found.

Error Suspense Account

If the Allow Balancing Transactions option is selected, this is the suspense account code to which any
balancing adjustments are posted.
Summarize
You can choose to include all of the transactions, for each stage in the allocation process, on the Allocation
Run report or to summarize them and only print the totals on the report.
Import Document Format Code

The document format for the Allocations report you want to produce for the allocation transactions
generated.

Financials inquries
Chapter 11: Financials inquries
The inquiry forms extract and display selected information.

They use filters to determine the information you can view. Financials includes the following predefined
control desk based inquiries:
• Journal Inquiry
• Account Inquiry
• Fixed Asset Inquiry
• Account Balance Inquiry.
These inquiries use predefined filters which are defined using Filter Designer (FLD). You can use Filter
Designer (FLD) to define your own inquiries, or to modify the predefined inquiries.
Note: The Ledger Inquiry option allows you to run any inquiry, including the four predefined inquiries listed
above and any user defined inquiries. You can use the Ledger Inquiry option to view archived transactions
using the Ledger Inquiry - Archive option.
Using the Predefined Inquiries

When you use any of the predefined inquiries, you are unaware that a filter is being used. You are simply
prompted to enter the inquiry selections, for example to choose the account, journal or asset you are interested
in.
Note: You cannot enter negative values in a value field. If you enter an amount range, it is treated as both a
negative and positive value range. For example, if you enter from 100 to 150, transactions are extracted with
a value in the range 100 to 150 or with a value in the range -150 to -100.
Once you have made selections, the data is retrieved and displayed on a form. Again, the information you
see is determined by the filter and result form, and can be modified.
Viewing Related Details

Many of the inquiry result forms can display summarized or detailed information. If the results are summarized
you can use the Explode action to display the details. Alternatively, if detailed information is displayed you
can use the Implode action to summarize the details. For example, the Account Balance Inquiry (ABQ) can
summarize the postings to each account, or summarize the postings to each account by period, or list the
detailed postings by date for each account.
If drill associations have been defined, you can double-click on an item in the display grid to 'drill through'
the data.
For example, if you are viewing the transactions posted to an account you may be able to drill through on:

Financials inquries
• journal number to display all of other transactions in the journal to see which other accounts were
updated by the journal.
• one of the ten available transaction analysis codes to view the description of the analysis code referenced
on the transaction.
Account inquiry
Account Inquiry (ACQ) allows you to display selected, current transactions posted to a particular account.
This inquiry uses a predefined control desk and filter. The account transactions are displayed on the Financials
- Account Inquiry window.
You can print selected transactions on the Ledger Inquiry by Account report.
Performing an Account Inquiry

Note: This inquiry displays current live transactions only. If you wish to view archived and current transactions
you should use the Ledger Inquiry - Archive option available.
1 Select the Account Inquiry (ACQ) option from SunSystems to display the Account Inquiry selection
form.
2 Enter the selection details, explained below. A transaction must meet all of the selection criteria to be
displayed.
3 Click OK to extract the account details.
4 The account transactions appear on the Financials - Account Inquiry window.
5 Double click on any of the following fields to drill down to the related details: Account Code, Journal
Number, Analysis Codes, Saved Set Reference.
Using Account Inquiry to Extract Transactions onto the

Control Desks In-Tray
Account Inquiry extracts and displays ledger transactions for a selected account using a flexible filter. This
filter makes Account Inquiry useful for extracting transactions and passing them through to the control desk
in-tray for further processing.
Once the selected transactions appear on the control desk in-tray they can be processed by many of the
processes that can be initiated from the control desk in-tray, for example, payment processing, or matching.
Note: The Account Inquiry function uses a predefined system filter that was defined using Filter Designer
(FLD). You can use Filter Designer (FLD) to define your own inquiries or extract filters, or to modify the
predefined filters. When you use any of the predefined inquiries, you are unaware that a filter is being used.

Financials inquries
You are simply prompted to enter the inquiry selections, for example to choose the account, journal or asset
you are interested in.
1 Select Account Inquiry (ACQ) from SunSystems to display the Selection - Account Inquiry form.
2 Enter the account transaction selection details to identify the account transactions you require.
3 Click OK to extract the account transactions and list them on the Financials - Account Inquiry window.
4 Select Action > Review to list the selected transactions on the Control Desks In-Tray. Select the
transactions you want to place in the control desks in-tray. You can de-select some transactions at this
stage, if required.
5 Choose a processing option from Report Process and click OK to process these transactions. For example,
choose Matching Process to lists the transactions on the Search Results - Account Allocationwindow.
Performing a Ledger Archive Inquiry

The Ledger Inquiry - Archive option allows you to display the archived and current transactions posted to a
particular account. This inquiry is run using the Ledger Inquiry option by selecting the Ledger Inquiry -
Archive filter type.
Note: You can print the archived and current transactions for an account.
1 Select the Ledger Inquiry option from SunSystems to display the Control Desk Filter Selection form.
2 Select SALQA as the Filter Type Code.
3 Select Archive Inquiry as the Filter Name.
4 Click Run to display the Ledger Archive Inquiry form.
5 Enter the selection details.
6 Click OK to extract the records.
7 The account transactions, including archive transactions, appear on the Ledger Inquiry - Archive window.
Performing a Journal Inquiry

Journal Inquiry (JNQ) allows you to display a range of posted journal transactions. This inquiry uses a
predefined control desk and filter.
You can print selected transactions on the Ledger Inquiry report.
1 Select Journal Inquiry (JNQ) from SunSystems to display the Journal Inquiry selection form.
2 Enter the selection details. A transaction must meet all of the selection criteria to be displayed.
3 Click OK to extract the journal transaction details.
4 The transactions appear on the Financials - Journal Inquiry window.
5 Double click on a field to drill down to the related details, if they are available.

Financials inquries
Account balance inquiry

The Account Balance Inquiry (ABQ) displays the balance for an account, or range of accounts, for a selected
period.
Each account's balance is calculated from the transactions you select for the inquiry. You can select all of the
transactions for a range of periods, or restrict the transactions to those up to a chosen date.
For profit and loss accounts you must enter a range of accounting periods, for example, you may want to
view the balance for a period or for a quarter. For balance sheet accounts, that is, balance forward accounts,
you are only asked to select the To accounting period.
Performing an Account Balance Inquiry

The account balance inquiry displays summarized, consolidated account values. You can use the Explode
control desk facility to break down a total. Different levels of detail may be available. For example, the inquiry
might display an overall account total for a range of periods which can be exploded down into the totals for
each accounting period. In addition, the total for a particular period can be exploded further into a total for
each transaction date within the period.
1 Select the Account Balance Inquiry (ABQ) option from SunSystems to display the Account Balance
selection form.
2 Enter the selection details. A transaction must meet all of the selection criteria to be included in the
account balance calculations.
3 Click OK to extract the account details.
4 The account balance details appear on the Financials Inquiry window.
Performing an Intercompany Awaiting Posting Inquiry

Intercompany Awaiting Posting Inquiry allows you to display a range of intercompany journal transactions
that are currently awaiting posting. This inquiry uses a predefined control desk and filter.
1 Select Ledger Inquiry (LAQ) from the SunSystems menu.
Filter Type Code
Specify SALQ - Financials Inquiry.
Filter Name
Specify Intercompany Awaiting Posting.
3 Click Run to display the Selection - INTERCOMPANY AWAITING POSTING form.

4 Enter the selection details. A transaction must meet all the selection criteria to be displayed.
5 Click OK to extract the intercompany transaction details.

Financials inquries
6 Double-click on a field to drill down to the related details, if they are available.
7 To post the journal(s) into the target business unit, select Review or Review All.
8 Post the intercompany journals to the target business unit:
a In the Report Process field, specify Intercompany Posting.
b Click OK.
9 Alternatively, cancel a journal from being sent to the target business unit:
a In the Report Process field, specify Cancel Intercompany Posting.
b Click OK.
Performing an Intercompany Posting History Inquiry

Intercompany Posting History Inquiry allows you to review the intercompany posting results of each transaction
in the source business unit that has been posted, sent or failed to post to the target business unit. This inquiry
uses a predefined control desk filter.
2 Select Filter Type Code SALQ - Financials Inquiry.
3 Select Filter Name Intercompany Posting History.
4 Click Run to display the Selection - Intercompany Posting History form.
Performing an Intercompany Journals Received Inquiry

Intercompany Journals Received Inquiry allows you to display a range of intercompany journal transactions
that have been successfully received in to the target business unit. This inquiry uses a predefined control
desk and filter.
2 Select Filter Type Code SALQ - Financials Inquiry.
3 Select Filter Name Intercompany Journals Received.
4 Click Run to display the Selection - Intercompany Journals Received form.

Financials inquries
Using the Inquiry Results Forms

Many of the inquiry result forms can summarize the account transaction details, and can display both the
summarized and detailed transaction information. For example, if the inquiry lists the transactions posted
to an account it may be able to summarize them by posting date or by accounting period.
Summarized lines are identified by the (+) plus sign in the ++++ column on the grid. The number of plus signs
displayed indicates the level of summarization. Up to four levels of summarization are available, although a
particular inquiry may not use all of these levels.
1 You can use theExplode, or Explode All, actions to display the details of one or more summarized lines.
You can use the Implode, and Implode All, actions to summarize all or selected details to a selected level.
For example, the Account Balance Inquiry (ABQ) can display the postings for an account at three different
levels of summarization:
• at the first level of summary (+) - a total of the postings by date, within period, for each account.
• at the second level of summary (++) - a total of the postings to each account by period
• at the highest level of summary (+++) - a total of all the postings for each account.
Using Explode
You can highlight a summarized line, or range of summarized lines, and select the Explode action to display
the next level of detail available for each summarization.
For example, if you explode the highest account level summary total, the period totals are listed. You can
then explode a period total to display the date totals or list the detailed transactions.
The Explode All action performs the same function for all of the summarized lines.
Using Implode
You can use the Implode, or Implode All, actions to summarize the detailed information to a particular level.
For example, to summarize to the second level of summarization you would select an existing second level
summary line on the display and select Implode or Implode All to summarize to that level.
Using Drill Down or Drill Around

You can drill down on some of the transaction fields to display related details, depending on the drill
associations that have been defined. Double-click to drill down on a field.
For example, in Account Inquiry (ACQ) you can drill down on the account number for a transaction, to display
any other transactions posted to this account. This uses the standard Account Code Drill which is linked to
the account code field. You can also drill down on one of the transaction's analysis codes to view the analysis
code description and other code details.
Note: If you double click on a field that has not been linked to a particular drill, the Control Desks Drill
Associations dialog appears and prompts you to choose the type of drill you wish to use.

Financials inquries
Viewing Summarized Currency Totals

If financial transactions in a multi-currency environment are reviewed on the Control Desk In-Tray, a Currency
Total action or command may be available. This depends on the display form that is being used by the filter
definition.
You can choose the Currency Totals action to display the Currency Totals dialog. This displays the totals of
the transactions on the in-tray, by currency.
The top of the dialog displays the total of these transactions in the base currency, and the second base or
reporting currency. It also displays the total of any memo values on these transactions.
It then lists the transaction currencies and fourth currencies that are referenced on the transactions and
displays the total of the transactions for each of these currencies.
Viewing the Financials Inquiry Results

The results of a predefined Financials inquiry appear on one of the following forms, depending on the inquiry:
Financials - Account Inquiry

The results of an account inquiry are displayed on the Financials - Account Inquiry window. This window
lists all of the selected transactions posted to a chosen account. It displays selected details for each transaction.
The transactions can be summarized by Transaction Date, Accounting Period and Account and you can
use the Explode and Implode actions to view or the summary or detailed information.
Note: This window is also used to display and select transactions for other Financials functions that use
filters to extract transactions. For example, Tax Reporting (TXR) and Post Provisional Transactions (PPT).
Financials - Journal Inquiry

The results of a journal inquiry are displayed on the Financials - Journal Inquiry window. This window lists
the journal transactions extracted for the selected journal. The transactions can be summarized by Journal,
therefore you can use the Explode and Implode actions to view the single line summary for each journal or
display the detailed journal lines.
Financials - Inquiry
The results of an account balance are displayed on the Financials - Inquiry window. This window lists all of
the selected transactions posted to a chosen account and displays selected details for each transaction. The
inquiry initially displays an overall summary balance for each account or asset. You can use the Explode or
Explode All actions to break this balance down by accounting period, and again to break it down by date.
Financials - Asset Inquiry

The results of a fixed asset inquiry are displayed on the Financials - Asset Inquiry window. This window lists
all of the selected transactions posted to a chosen asset and displays selected details for each transaction.

Financials inquries
The inquiry initially displays an overall summary balance for each account or asset. You can use the Explode
or Explode All actions to break this balance down by accounting period, and again to break it down by date.
Financials - Archive Inquiry

The results of a ledger archive inquiry are displayed on the Financials - Archive Inquiry window. This window
lists all of the selected transactions posted to the chosen accounts, including transactions that have been
archived. It displays selected details for each transaction.
Printing the Results of a Ledger Inquiry

When you have performed an inquiry to investigate particular transactions, you may want to print these
transactions. The transactions you have extracted for the inquiry are held on a control desk. You can review
or some or all of these transactions and print them on the Ledger Inquiry report.
There are two versions of this report: Ledger Inquiry by Account or Ledger Inquiry by Journal. The report
produced depends on the type of inquiry you have run. Both reports print the main transaction details, for
the selected transactions, including the transaction analysis codes. The only difference between the two
reports is the sequence the fields and transactions are printed on the report.
1 Highlight the transactions you want to print on the inquiry window. For example, if you have used Account
Inquiry (ACQ) to view transactions, highlight the transactions on the Financials - Account Inquiry
window.
2 Click Review to list the transactions on the Control Desk In Tray.
3 Select Ledger Inquiry as the Report Process and click OK to produce the report.
Viewing Voucher Numbering

Use View Voucher Numbering (VVN) to inspect the status of the different voucher number streams, or to
view the gaps in the voucher numbering. Click one of the following options as appropriate:
• View latest voucher numbering
• View voucher number gaps.
Voucher Number Streams Detail Lines

This form displays the latest voucher numbers for all of the numbering sequences pertaining to the different
voucher number streams. For example, if the Restart option in Voucher Number Stream Setup (VNS) is set
to Period, a separate sequence is started for each period, and all are displayed for each voucher number
stream. The following columns are displayed in the information grid:
Voucher Sequence Number
Voucher Sequence Number

Financials inquries
Stream Period
Only displayed if the Restart option in Voucher Number Stream Setup (VNS) is set to Period.
Stream Year
Only displayed if the Restart option in Voucher Number Stream Setup (VNS) is set to Year.
Stream Date
Only displayed if the Restart option in Voucher Number Stream Setup (VNS) is set to Daily.
Stream Transaction Reference

Reserved for future use.
Voucher Number Streams Gaps

This form displays all of the numbering gaps pertaining to the different voucher number streams. The first
six columns displayed are the same as those described above, and you can scroll to the right on the grid to
display additional columns relating to the creation and deletion of the transaction line that caused the gap
in the numbering.
View latest voucher numbering

View latest voucher numbering allows you to check the status of the different voucher number streams. This
inquiry uses a predefined control desk and filter.
Journal Class Code From/To
The range of journal class codes for which the voucher number streams are displayed. By default, all journal
class codes are selected.
Stream Period From/To

The range of stream periods for which the voucher number streams are displayed. By default, all stream
periods are selected.
Stream Transaction Refere From/To

The range of stream transaction references for which the voucher number streams are displayed. By default,
all stream transaction references are selected.
View voucher numbering gaps

View voucher numbering gaps allows you to check all of the numbering gaps pertaining to the different
voucher number streams. This inquiry uses a predefined control desk and filter.
Journal Class Code From/To
The range of journal class codes for which the voucher number streams are displayed. By default, all journal
class codes are selected.

Financials inquries
Stream Period From/To

The range of stream periods for which the voucher number streams are displayed. By default, all stream
periods are selected.
Stream Transaction Refere From/To

The range of stream transaction references for which the voucher number streams are displayed. By default,
all stream transaction references are selected.

Financials Transaction Lists and Report Writer Reports
Chapter 12: Financials Transaction Lists and Report Writer

Reports
The ability to provide meaningful information in a suitable and readable format is a vital element of any
financial solution.
SunSystems offers a number of reporting tools to cater for the variety of reports that are required.
Note: All SunSystems reports are produced by the SunSystems Reporting functionality. They are printed or
displayed using Report Manager.
The Types of Financials Reports

There are four classes of reports in SunSystems:
Static Data Reports

Static data reports list information about static data records. For example chart of accounts listings, currency
code lists and so on. These reports can be selected from the SunSystems menu, or produced by selecting the
Report option on the corresponding static data function.
Note: Although the end user has no control over the report content at run time, the report is still produced
so an authorized user can use the Report Designer functionality to alter the format of the report.
Standard System Reports

All of the SunSystems processing functions produce standard audit trail reports. For example, the Corporate
Allocations reports, Ledger Import report and so on. These reports are produced automatically by the
appropriate function and cannot be run independently.
Note: These reports are always requested via a SunSystems function and so a document format is always
required for each of these reports. However, the reports are still produced so an authorized user can use the
Report Designer functionality to alter the format of the report.
User Definable Reports

SunSystems offers a number of user definable reporting options, each one designed to fulfill specific
requirements.
As an end user, you cannot control the appearance of these reports, but you do have control over some
aspects of the reports depending on the report's parameters. For example, the report parameters may allow
you to select the accounts or codes to be included in the report, and the accounting periods required.

The user definable reports can be categorized as follows:

• Financial or management reports, including trial balances and journal listings
• Tax reports
• Consolidation reports
• Documents, including cheques and remittances
• Audit trail reports
• Ageing reports
• Fixed Asset Register reports.
Note: Many of these reports are requested via a SunSystems function and so a document format is always
Financial/Management Reports
SunSystems provides three financial report writers: Financial Analysis, Financial Statements and Financial
Tables. Each offers a variety of features that assist you in preparing reports:
• Financial Analysis is a quick and easy to use report writer. It provides an analysis or view of SunSystems
information, selected and sorted to your specification. It allows you to list transactions included in your
system.
• Financial Statements is similar to Financial Analysis but provides more control over the layout and
content of the report. It is used mainly to present management information such as profit and loss,
balance sheet, and similar reports.
• Financial Tables is similar to Financial Statements in that you have a high degree of control over the
presentation of information on a report. However, it has the additional feature of allowing more flexibility
in specifying the contents of columns on a report. A Financial Tables report can be likened to a matrix.
You must define the reports you require from these financial report writers. Once a report has been defined
it can be produced at any time.
Note: Many of these reports are requested via a SunSystems function and so a document format is always
Financials Transaction Listings

SunSystems Financials includes several types of transaction listing. Transaction listings refer to any report
that includes transaction details, for example, journal listings, account listings and so on.
The transaction listings, like all SunSystems reports, are formatted and printed using the SunSystems reporting
functions. The system includes predefined layouts for these transaction listings, and in some cases provides
alternative layouts. You can use the Report Designer to produce your own transaction listings, if required.

Producing an Account Listing

The Account Listing report identifies the transactions that have been posted to the ledger, by chart of accounts
code. You can include transactions for a range of accounts and accounting periods. You can select a single
account code or range of account codes and a range of accounting periods for which transactions are to be
listed.
SunSystems Financials includes the following example account listings, some of which are tailored to the
chart of accounts and analysis codes used in the PK1 demonstration business unit:
• Account Listing with Analysis for any Business Unit (ALAU) - this report prints the main transaction
details and includes any analysis codes entered on the transactions.
• Account Listing with Analysis for PK1 (ALA) - this report prints the main transaction details and
includes any analysis codes entered on the transactions for the PK1 demonstration database only.
• Account Listing for PK1 (ALPT) - this report prints all of the transaction details for each transaction,
excluding any analysis codes and standard text, for the PK1 demonstration database only.
The account listing reports print the base currency, transaction currency and second base/reporting currency
details for each transaction. Fourth and fifth currency fields are also available to be defined.
Within each account, the transactions are grouped by accounting period and the total postings to each period
are shown in the base and second base currencies. Once all of the transactions have been listed for the
account, for the accounting periods selected, the total of the account transactions is printed, analyzed by
currency. Finally, the report prints the total of all transactions, for all the accounts and periods included on
the report.
You can define account listing reports using the SunSystems Reporting functionality. You can design as many
reports as you want, with each showing the information required.
Account Listing
Business Unit
The business unit to be reported.
Ledger Code
The ledger to be reported.
Accounting Period Opening Balance

The period from which transactions are included in the report. The opening balance printed for balance
sheet accounts is from this period.

The range of accounts to be included in the listing. If you want to include all account codes, click the All
option.
Accounting Period
The period up to which transactions are included in the report. Leave this blank for all periods up to and
including the current accounting period.


The type of transactions to include on the report. This is only required if provisional postings are mandatory
or optional and it allows you to print either provisional or permanent transactions. Select Yes to print only
provisional transactions, No to print only permanent postings or N/A to print all transactions.
Producing an Account Listing with Archived Transactions

The Account Listing example report, FTAL1.srdl, lists the transactions that have been posted to the ledger,
by chart of accounts code. You can include transactions for a range of accounts and accounting periods. You
can select a single account code or range of account codes and a range of accounting periods for which
transactions are to be listed.
The account listing reports print the base currency, transaction currency and second base/reporting currency
Within each account, the transactions are grouped by accounting period and the total postings to each period
are shown in the base and second base currencies. Once all of the transactions have been listed for the
account, for the accounting periods selected, the total of the account transactions is printed, analyzed by
currency. Finally, the report prints the total of all transactions, for all the accounts and periods included on
the report.
You can define account listing reports using Report Designer. You can design as many reports as you want,
with each showing the information required.
Producing a Journal Listing

Journal Listing reports are crucial to your audit trail. SunSystems Financials includes default journal listings
which include the details of an individual journal, or a range of journals. You can select the journals to include
in your listing by type, source, number, or by the date or period in which they were entered.
You should print a journal listing after each Ledger Entry session so that, at the end of an accounting period,
you have a complete record of all journals entered during the period. You can use the Force Journal Listing
setting in Ledger Setup (LES) to produce a journal listing automatically when a journal is successfully posted.
Note: After you have run Ledger Cleardown, some of the journal transactions may be summarized and
cleared down and it may no longer be possible to produce a full journal listing. If you try to print details of a
journal that has been partially, or fully cleared down, the journal listing is incomplete and therefore does not
balance.
There are several example versions of this report provided as standard in SunSystems Financials, some of
which are tailored to the PK1 demonstration business unit:
• Journal Listing with Analysis for any Business Unit (JLAU) - this version prints the main transaction
details, it excludes the payment term details but includes any analysis codes entered on the transactions.
• Journal Listing for PK1 (JL) - this version prints the majority of the transaction details for each
transaction, including the payment terms details but excluding any standard text and analysis codes,
for the PK1 demonstration database only.

• Journal Listing with Analysis for PK1 (JLA) - this report prints the main transaction details, it excludes
the payment term details but includes any analysis codes entered on the transactions, for the PK1
demonstration database only.
• Journal Listing for Unbalanced Journals (JLU) - this report prints the full transaction details and
includes unbalanced journals, for example budget journals.
Note: An unbalanced journal is only posted in extremely unusual circumstances by an authorized user.
The journal listing reports print the base currency, transaction currency and second base/reporting currency
You can use Report Designer to design alternative journal listing reports. You can design as many reports as
you want, with each showing the information required.
Journal Listing
Business Unit
Ledger Code
Journal Number
A journal number, or range of journal numbers, to be included in the listing. Leave this field blank to include
all journal numbers in the listing.
Journal Source
The journal source, or range of source codes, for which journals are included on the report. Leave this field
blank to include all journals in the listing, regardless of the journal source. The journal source typically
identifies the operator who entered the journal.
Journal Type
A journal type, or range of journal types, to be included on the report. Leave this field blank to include all
journal types in the listing.
Accounting Period
If you want to include transactions by accounting period, this is the period, or range of periods, to which
journals must have been posted to be included in the report. Leave this blank to include journals for all
periods.
Entry Date
If you want to select transactions by entry date, this is the specific entry date, or range of dates, for which
journals are included in the report. Leave this blank to include journals for all entry dates.
Entry Period
If you want to include transactions by entry period, this is the period, or range of periods, in which journals
must have been entered to be included in the report. Leave this blank to include journals entered in any
period up to and including the current accounting period.
Some of the journal listings also include the following additional parameters:


The type of transactions to include on the report. This is only required if provisional postings are mandatory
or optional and it allows you to print either provisional or permanent transactions. Enter Yes to print only
provisional transactions, or No to print only permanent postings.
Suppress Transaction
Select No, or leave the field blank, if the report is to show details of permanent transaction. Select Yes to show
only the date, description, and total values of each journal. If you suppress the transactions, the description
of each journal is printed by the journal total line.
Page Break After

Select Yes if you want each journal to start on a new page. Otherwise leave the default field value to print
the journals continuously.
Producing the Journal Postings Audit Report

The Journal Posting Audit Report identifies the journal numbers that have been assigned to journals in the
ledger. A journal number is assigned to a journal when the posting procedure begins. If, for any reason, the
journal is not posted the journal number remains assigned to this journal and is not reused. Therefore, you
can use this report to identify any 'unused' journal numbers, that is journal numbers that do not appear on
the journal listings.
The status shown on the report indicates the current state of the journal. A status of Journal Posted OK (1)
indicates that the journal was posted successfully, a status of Incomplete Journal (0) indicates that it is
being posted. Any other status indicates that the journal was not posted.
Note: This report includes any journals numbers assigned to journals that were not posted.
You can restrict the report to journals by journal type, journal creation date and journal status. The report
prints one line for each journal and includes the following journal audit information:
• The journal number and type
• The last status of the journal
• The date the journal was created
• The SunSystems function used to create the journal
• The operator who created the journals
• The provisional posting indicator.
• The entry period
• The total debits and credits included in the batch, displayed in the base currency only.
Journal Posting Audit Report

Business Unit
Ledger Code

Journal Number
A journal number, or range of journal numbers, to be included in the listing. Leave this field blank to include
all journal numbers in the listing.
Last Status
The status code for which journals are listed on the report.
Journal Type
A journal type, or range of journal types, to be included on the report. Leave this field blank to include all
journal types in the listing.
Date Created
The date, or range of dates, on which journals must have been created to appear on the report.
Printing Held Journals

The Held Journal Listing (REPJNH) reports on the journals in the held journals file. These are journals that
have been entered into the system but not posted.
You can use Report Designer in SunSystems Reporting Services to design alternative journal listing reports.
You can design as many reports as you want, with each showing the information required.
Journal Held Listing (REPJNH)

Business Unit Code
The business unit for which the held journals are to be listed.
Suppress Transactions
Select No, or leave blank, if the report is to show details of each transaction. Select Yes to show only the date,
description, and total values of each held journal. If you suppress the transactions, the description of each
held journal is printed by the journal total line.
Page Break After

If you want each held journal to start on a new page, enter 1. Otherwise leave blank to print the journals
continuously.
Printing Payment Transactions

The Payment Listing enables you to select and list particular payments or other transactions, by account.
It is primarily used to print payment details but it can be used to list the transactions associated with any
type of journal or journal source.
It prints the selected transaction details by account code, and includes the allocation details such as the
allocation marker, allocation reference and allocation date.

Payment Listing is produced using the standard SunSystems Reporting functionality. You can use Report
Designer to design alternative payment listing reports. You can design as many reports as you want, with
each showing the information required.
Payment Listing
The following report parameters are specific to the listing:
Account Code
The account code, or range of codes, to be included in your report. Leave this field blank to include all
accounts.
Allocation Marker
You can choose to report on all transactions, allocated transactions, unallocated transactions, or those
transactions with or a marker of Allocated, Corrected, Paid, Reconciled or 0-9 numeric markers. The allocation
markers Brought Forward, Force, Withheld and 0-9 Numeric are treated as unallocated.
Allocation Reference
The allocation reference, or range of references, you want to include in this listing.
Journal Type
The journal type, or range of journal types, you want to include in this listing.
Journal Source
The journal source, or range of source codes, for which transactions are included on the report. Leave this
field blank to include all transactions in the listing, regardless of the journal source. The journal source
typically identifies the operator who entered the journal.
Accounting Period
Leave these fields blank to select the current period transactions. Otherwise, enter a single period, or the
range of periods you want to include.
Transaction Date
Leave these fields blank to select all transaction dates. Otherwise, enter the single date, or the range of dates
you want to include.
The transaction reference, or range of transaction references, you want to included in this listing.
Trial balance
A trial balance should be printed at the end of each period.
It is a fundamental audit report. You can use Trial Balance (TBL) to produce a standard trial balance report.
You can choose to report on a range of accounting periods or entry dates. The trial balance report shows one
line for each account which reports the following values for the period of the report: the opening balance,
the total debits, the total credits, the net movement for the period, and the closing balance.
If the previous year's net profit and loss is not equal to zero, the balancing figure is printed immediately prior
to the report totals.

You can produce subtotals, based on the setting of Trial Balance Subtotal - Position of Character field in
Ledger Setup (LES).
The trial balance is produced using the SunSystems Reporting functionality. This means that you can design
your own trial balance report, if required.
Producing a Trial Balance
Trial Balance (TBL)

Select By
The Select By setting determines how the transactions are selected for the report. Four options are available:
• Accounting Period - this is the default setting which allows you to include transactions for a range of
accounting periods. If a balance file has been created for the ledger it is used when this option is selected.
• Transaction Date - this option includes transactions for a range of transaction dates.
• Force Generation from Ledger File - ensures the report is produced from the ledger file, rather than
the balance file, while selecting by accounting period.
• Entry Date - this option includes transactions for a range of entry dates.
Accounting Period / Transaction Date / Entry Date From and To

Depending on the option you have chosen for the Select By setting, enter either the date or range of dates,
or the period or range of periods, to be included on the report. If you have chosen to select by Accounting
Period, and only want transactions for the current accounting period, leave these fields blank.
Value Basis
The currency value you want to report on. You can select base currency, second base/reporting currency, or
fourth currency.
Note: You can only select fourth currency if it is being used as a fixed currency.
Summarize Debtor Balances

If this field is set to Yes, the debtor/receivables account balances are totalled and printed as a one line
summary. If debtor accounts are present in different ranges in Chart of Accounts (COA), with other account
types located between the ranges, one summary is printed for each range.
Summarize Creditor Balances

If this field is set to Yes, the creditor/payables account balances are totalled and printed as a one line summary.
If creditor accounts are present in different ranges in Chart of Accounts (COA), with other account types
located between the ranges, one summary is printed for each range.
Summarize Client Balances

If this field is set to Yes, the client account balances are totalled and printed as a one line summary. If client
accounts are present in different ranges in Chart of Accounts (COA), with other account types located
between the ranges, one summary is printed for each range.
Select Transactions
The type of transactions to be included in this report.

Improving Performance Using the Balance File

By summarizing transactions from the ledger or budget file, you can improve the speed with which a trial
balance is produced. The Ledger Balance file contains summaries of the transactions from the ledger file. It
is used by some reports to improve the speed with which the reports are produced.
In Trial Balance, the ledger balance file is used only when it is appropriate to the selections made when you
produce a trial balance. The balance file is used in preference to the ledger or budget file when the following
conditions are met:
• A balance file has been created for the current ledger/budget file.
• Trial Balance is set to select by accounting period. As the balance file does not contain transaction dates,
it cannot be used if you select by transaction or entry date. The Force Generation from Ledger File
allows selection by accounting period and forces the report to be generated from the ledger file.
• Trial Balance is set to include provisional transactions. As the balance file does not differentiate between
provisional and permanent postings, you can only use the balance file when all of transactions are
included in the report, provisional and permanent.
Aged Analysis Reports

Ageing reports sort transactions into ageing bands. You can age the transactions for any type of account, but
the most frequently used aged reports age the transactions for debtors/receivables and creditors/payables
accounts. You might also use an aged report to analyze cash flow.
Note: The standard aged analysis reports display values in the base currency only.
Ageing reports can help you to plan your credit control activity and your payments. An aged debtors/receivables
report shows your customers' outstanding debts to you. An aged creditors/payables report shows your
commitments to suppliers and when you are due to pay them.
On debtor/receivables and creditor/payables accounts, ageing backward tells you how long outstanding
transactions have remained unpaid.
On debtor/receivables accounts ageing forward may be used to project receipts. On creditor/payables
accounts, it is useful for projecting outgoings.
If you select both debtor and creditor accounts and choose a forward ageing report, the report shows your
net cash flow.
The standard ageing reports allow you to age transactions either forward or backward by due date. You can
choose to report in the base currency only, or include the transaction currency.
The due date, by which the transactions are aged, is determined on each transaction from the payment terms.
You can define up to four ageing periods for the report.
SunSystems includes four predefined aged analysis reports:
Aged Analysis - Back Due Date Detail

The Aged Analysis Back Due Date Detail (AAB1D) report ages the selected transactions backward by due
date, and prints the transaction values in the base and transaction currencies.

Aged Analysis - Back Due Date Summary

The Aged Analysis Back Due Date Summary (AAB1S)report ages the selected transactions backward by due
date, and prints the transaction values in the base currency only.
Aged Analysis - Forward Due Base Detail

The Aged Analysis Forward Due Base Detail (AAF1D)report ages the selected transactions forward by due
date, and prints the transaction values in the base and transaction currencies.
Aged Analysis - Forward Due Base Summary

The Aged Analysis Forward Due Base Summary (AAF1S) report ages the selected transactions forward by due
date, and prints the transaction values in the base currency only.
All these reports are produced using the SunSystems Reporting functionality, so you can define your own
ageing reports or modify the layout of these reports, if required.
Producing an Aged Analysis Listing

All of the sample Aged Analysis Listing reports available analyze selected transactions by due date. They use
the transaction due date to age the transactions into one of five ageing periods. The ageing periods can be
forward or backward, depending on the type of aged analysis listing you choose.
All of the standard aged analysis listings use the same parameters, although they are treated differently
depending on whether the report is ageing backward or forward.
Age By Date
The base date from which you want to age transactions. For a backward ageing report, transactions
with a due date on or before this date are selected and analyzed into the appropriate ageing periods.
For a forward ageing report, transactions with a due date on or after this date are analyzed.
Ageing Dates 1-4

Up to four dates used to age the transactions. For a backward ageing report, these dates should be prior
to the Age By Date. For a forward ageing report, these dates should be after the Age By Date.
Each Account on a New Page

If you want each account to start on a new page select Yes. Otherwise, select No.
Account Code
The account, or range of accounts, to be aged. The transactions for these accounts are analyzed into
the appropriate ageing periods on the report.
Account Type
The account type, or range of account types, to be included in the report. For example, you may want
to restrict the report to debtor or creditor accounts. Leave this field blank to include accounts regardless
of the account type.

Allocation Types
The allocation markers to be included in the ageing. Transactions with the selected markers are aged
on the report.
Daybook Listing
The Daybook Listing, as the name implies, is designed to be run daily to print all of the transactions that
have been posted during the day.
Daybook listing reports are designed using the report writing tools which enable you to design your own
daybook listing formats, if required.
The transactions can be sequenced primarily by entry date or transaction date. The report includes totals for
each day, each page, the year-to-date, and at the end of the report.
Using the Daybook Listing with Provisional Transactions

The Daybook Listing (DYL) can report on the provisional transactions. This is particularly important for Italian
users. Italian tax regulations stipulate that transactions must be posted as provisional, before being approved
and converted into permanent transactions.
When the Daybook Listing is run using the Definitive Request option, the provisional postings are changed
to permanent postings.
The page numbering that appears on the Daybook Listing can be made to continue from one report to the
next, when the report is produced with the Definitive Request option set.
Assigning Daybook Sequence Numbers

A seven digit daybook sequence number can be applied to the transactions that are printed on the Daybook
Listing when it is produced with the Definitive Request option set. The daybook sequence number
requirements are defined using Ledger Sequences Setup (LEQ) and Daybook Setup (DYB).
The daybook sequence number assigned to each transaction is stored on the transaction in the daybook
analysis dimension which is specified in Ledger Setup (LES). If a transaction already has a sequence number
applied to it, a new number is not allocated.
Changing Your Daybook Listings

You can use Daybook Setup (DYB) to determine the way Daybook Listing sequences your transactions and
assigns daybook sequence numbers to the transactions. These selections are reflected when you run Daybook
Listing.
When printing daybook listings, you can ensure that no dates are omitted from a sequence of listings and
control any reprints of the listing.

You can also exclude a range of journal types and range of accounts from a daybook listing using the settings
in Daybook Setup (DYB).
Definitive Requests
Printing a definitive request for a daybook listing:
• assigns daybook sequence numbers to transactions.
• permanently posts any provisional transactions which appear in the daybook listing.
• updates the Last Processed Date field in Daybook Setup (DYB).
• inserts the continuous page numbers on the listing and updates the number stream.
• optionally amends the Open Dates in Ledger Setup (LES).
Setting Up the Daybook Listing

Daybook Setup (DYB) enables you to determine the way daybook listings are produced. You can control the
order in which the transactions are printed, exclude transactions for selected journal types and accounts,
and determine how page numbers can be attributed to your listings.
If daybook sequence numbers are to be applied to the transactions you can also determine when a new
sequence number is assigned.
Note: You must set the Definitive Request option to Yes to assign daybook sequence numbers and to set
provisional postings to permanent.
Daybook Listing (DYL) is used to produce a daybook listing report.
Daybook Sequence Code
The sequence number code used for sequencing the transactions and report. If daybook sequence
numbering is required, this must be a Sequence Number Code defined using Ledger Sequence Setup
(LEQ).
If daybook sequence numbering is not required, this defaults to '-' (hyphen).
Start of Current Fiscal Year

The date of the start of the current financial year. This is used to ensure that the Transaction Date range
entered on Daybook Listing is within the current year, and to calculate year-to-date figures.
Prior Yr Adjustment Jnl Type

The journal type used to identify prior year adjustment journals. This is passed to the Daybook Listing
as a report parameter. You can use the SunSystems report writing tools to produce a tailored version of
the Daybook Listing that uses this information, for example, to sort or subtotal these transactions.
Sequence By
The sequence in which the transactions are sorted and printed on the report. A predetermined set of
sort options are available. This is important if daybook sequence numbers are being assigned because
it determines the fields that can be used to control the sequence numbering.

Numbering Method
This identifies the transaction field that determines when the daybook sequence number should change.
The transactions on the listing are sorted according to the Sequence By option, and when the value of
the field chosen here as the Numbering Method changes, the next sequence number is assigned.
If you do not wish to assign daybook sequence numbers, select the No Numbering option.
If daybook sequence numbering is required, the numbering method you can choose depends on the
chosen Sequence By method. The numbering method must be one of the fields identified in the Sequence
By sort sequence. For example, if you choose to sequence the transactions by Transaction Date/Journal
Number, you can only choose Transaction Date or Journal Number as the numbering method. You could
not, for example, choose Transaction Reference as the numbering method.
A daybook sequence number is assigned to each transaction included on the listing. When the field value
you choose as the numbering method changes, the next daybook sequence number is assigned to this
transaction. The transactions are reviewed in the order in which they are printed. This means that the
transaction sort sequence can affect the sequence numbers that are assigned. For example, if you
sequence the listing by Transaction Date/Journal Number/Transaction Reference and choose Transaction
Reference as the numbering method, if the same transaction reference appears in two journals, different
daybook numbers are assigned to each.
Last Processed Date

This is the last date for which transactions were printed on a definitive daybook listing. You must enter
an initial date here before you can produce the Daybook Listing. Once you have entered this date you
should not amend it. It is updated automatically each time you produce the Daybook Listing with the
Definitive Request option set to Yes.
Update Ledger 'Open Date From'

This determines whether the Open dates field in Ledger Setup (LES) and the registration date on Ledger
Sequences (LEQ) are updated when a definitive request for a daybook listing is made.
Suppress 'Out of Balance' msg

This suppresses the Out of Balance message.
Exclude Journal Types From/To

A journal type, or range of journal types, to be excluded from Daybook Listing reports. In many countries
there are statutory regulations governing what must be included in and excluded from daybook listings.
Exclude Account From/To

An account, or range of accounts, to be excluded from Daybook Listing reports. In many countries there
are statutory regulations governing what must be included in and excluded from daybook listings.
Assigning Daybook Sequence Numbers

Daybook sequence numbers can be assigned to transactions that are included on the Daybook Listing when
it is produced with the Definitive Request option set.
The following steps are required to define and apply daybook sequence numbers:

1 Create an analysis dimension to maintain the daybook sequence numbers when they are generated.
Ensure the Validation Method of the dimension is set to No Validation. Analysis dimensions are created
usingAnalysis Dimensions (AND).
2 Assign this analysis dimension to one of ten analysis dimensions used to analyze the Ledger entity (901)
in Analysis Structure (ANS).
3 Identify this analysis dimension in the Daybook Dimension field on Ledger Setup (LES). The daybook
sequence number assigned to each transaction is stored in this analysis dimension on the transaction.
Setting Continuous Daybook Listing Page Numbers

Daybook Listing can be set up to include continuous page numbering. This means that when you produce
a daybook listing, the page numbering continues automatically from the previous daybook listing produced.
Note: These page numbers are only included when you produce a definitive daybook listing. See 'What is the
Daybook Listing?' for a definition of a definitive listing.
A transaction reference is required to store the last used page number. The transaction reference uses a
number stream to automatically increment the page numbers and determine when the number is reset. The
appropriate page number is included on the report by identifying the transaction reference on the document
format for the Daybook Listing.
The following steps are required to insert continuous page numbering on Daybook Listing:
1 Create a number stream to determine the next available page number using Number Streams (NSS).
2 Create a transaction reference format using Transaction References Setup (TRS) and reference this
number stream.
3 Modify the daybook listing document format to identify the transaction reference format and determine
whether or not the user can override the page number at run time. Document formats are updated using
Document Format (DFS) and these details are maintained on the Transaction Reference tab.
Note: If you use the reprint option to reprint a definitive Daybook Listing, you may need to reset the
next available page number either at run time, if this option is available, or using Number Streams (NSS)
to ensure the correct page numbers are reproduced.
Producing a Daybook Listing

Daybook Listing (DYL) shows transactions by reference, which fall within a specified range of entry dates.
You can use Daybook Setup (DYB) to tailor the way daybook listings are produced. You can control the way
transactions are sequenced, how daybook sequence numbers are applied to the transactions, and exclude
transactions for selected journal types and accounts.
On a definitive daybook listing, sequence numbers can be assigned automatically to transactions. In addition,
a continuous page numbering sequence can apply from one daybook listing to the next.
The following steps are required to produce the Daybook Listing:
1 Access Daybook Listing (DYL) from SunSystems.
2 Enter the report parameters, for example, to select the range of transaction dates you require.

3 Select Action > Print. The standard document format print request form appears to allow you to control
the production of the payment documents.
4 Enter the remaining print request details and click OK.
Note: If a transaction reference number stream is being used to continue the page numbering from the
previous daybook listing, you may have the option to override the next page number to be printed in the
Data Settings section on the Document tab. The option to use the transaction reference as the page
number, and the ability to override this at run time, is set for the document format using Document
Format (DFS).
5 Enter the Transaction Date From/To which is an entry date, or range of dates, to be included in your
report. These dates must be within the fiscal year.
6 Select the Definitive Request option to change the provisional transactions included on the report to
permanent transactions, to assign daybook sequence numbers to the transactions, for the Next Sequence
Number on the Number Stream Details Setup to be updated with the next page number and to include
continuous page numbers on the report, if required.
The Daybook Listing does not calculate the last page number or write back the last page number to the
number sequence if the Pre-Printed Sequence is set to Pre-Printed Stationery.
7 Select Yes to reprint a daybook listing for which you have already printed a definitive request with a new
start page number. If you select this option, you can only select a range of dates which is prior to the date
in the Last Process Date field in Daybook Setup.
If you select Yes to reprint the Daybook Listing, you must also manually set the start page number based
on the last page number printed on the previous report.
Tax Reporting
Financials Tax Reporting provides a flexible reporting mechanism that allows you to report on the tax
transactions, and the related 'taxable' gross and net values.
Tax Reporting (TXR) allows you to produce tax reports in a variety of different formats, depending on the
reports defined using Data Source Designer.
Two tax report formats are provided as standard with Financials:
• Tax Listing Detail Report (Document Format TL1) - this report analyzes the tax transactions by
transaction reference, for example by invoice number. Each transaction reference is printed on a single
line containing the gross, net and tax values.
• Tax Listing Summary Report (Document Format TL2) - this report analyzes the tax transactions according
to the account code to which the gross taxable value has been posted, typically the debtor, creditor and
client accounts. For each account it identifies the gross, net and tax values.
Selecting the Tax Report Transactions

The standard Financials tax reports report on selected transactions, according to your selection criteria. The
selection criteria is determined by the tax filters associated with the tax report document format.

The standard tax reports use a single tax filter that is assigned to the document format using Document
Format (DFS).
The tax filter is defined using Filter Designer (FLD) and determines the type of transactions, and transaction
details that are extracted for the tax reports.
For the standard tax reports, the tax filter extracts either the gross, net or tax related transactions depending
on the range of account codes you select. The tax report then uses the document format Offset selection
capability to extract the corresponding gross, net or tax transactions.
Note: The Offset option for the tax reports must be set on Document Format (DFS) to automatically extract
these offset journal postings.
For example, if you enter the range of tax account codes as the filter account code selection to extract the
tax transactions, the Offset facility extracts the corresponding gross and net transactions automatically. It
uses the journal transaction reference on each tax transaction to retrieve the relevant gross and net
transactions.
As an alternative you might use multiple filters to retrieve the gross, net and tax transactions separately and
define a report that analyzes these transactions.
Separating the Gross, Net and Tax Transactions

Having extracted all of the gross, net and tax transactions the tax reports summarize these groups of related
transactions by account or transaction reference, depending on the type of tax report you are running.
Note: In order to do this, the tax reports use a Gross/Net/Tax indicator on each transaction to distinguish
between the three types of transactions. This indicator must be set using a business rule. For example, the
business rule could use account code on each transaction to determine the transaction type.
Analyzing the Tax

The tax reports use the tax codes on the tax transactions to determine the type of tax that has been calculated.
These tax codes are the analysis codes defined for the Tax Dimension identified on Ledger Setup (LES). The
tax rate associated with each tax code is defined using Tax Details (TXD).
Printing and Posting Provisional Transactions

The Tax Reports can optionally include provisional transactions. The tax filter provided with the standard tax
reports allows you to include or exclude provisional transactions.
If provisional transactions are included, Tax Reporting can optionally post these as permanent transactions
on the ledger as part of the reporting process. To post the transactions you must set the Final Print reporting
option on the document format print request form.
Setting Up User Defined Tax Reporting

Tax Reporting (TXR) uses the following SunSystems facilities to produce the standard tax reports delivered
with the system:

• Document formats to identify the tax reports

• Filters to extract the gross, net or tax transactions for the report
• Rule sets to be able to distinguish between gross, net and tax transactions
You can use Report Designer to define your own tax reports. You need to consider how the report identifies,
extracts and analyzes the appropriate tax related transactions.
You must define:
• The report using Report Designer.
• A document format for the report using Document Format (DFS).
• The tax filters required to extract the transactions for the report using Filter Designer (FLD).
• Any user defined selection criteria input forms to support the tax filters using Form Designer (FRD).
• Any business rules required to analyze the transactions using Business Rules.
Defining the Filters

You should use filters to extract the tax report transactions for the tax report. You can use more than one filter
to select the transactions you need.
The standard tax reports use a single filter to extract only one type of transaction, gross, net or tax. The
document format Offset facility is used to extract the other two types of transaction.
You could define three separate filters to extract the gross, net and tax transactions independently. If so, all
three filters must be linked to the tax report document format using Document Format (DFS) and the Offset
option would not be set.
Each filter is run separately and displays the selected transaction on a control desk. As the user selects the
transactions they want to include on the report they are added to a separate interface table until the report
is produced.
Once the user has selected transactions using all of the filters, the total number of transactions held on the
interface table is displayed and the user can then choose to produce the report.
Defining the Business Rules

The standard tax reports analyze the selected transactions into three value columns on the report: Gross,
Net and Tax, based on the Gross/Net/Tax indicator that is available on each transaction held on the interface
table.
The Gross/Net/Tax indicator for each transaction is set by a business rule that must be established for tax
reporting purposes. You should define business rules to set this Gross/Net/Tax indicator according to your
own report requirements.
User Defined Transaction Classifications

In addition to the Gross/Net/Tax indicator, each transaction on the interface table contains an additional ten
classification code fields. Each classification code can contain up to 15 characters.
You can use these codes to analyze the tax reporting transactions in different ways. You must define business
rules to set these codes, and then use the Report Manager (RMA) to analyze and report on the transactions.

For example, you may want to produce a report which separates the net value into different columns depending
on the type of tax rate. In this case you could use classification code 1 to group together your tax rates as
required. For example, grouping transactions for tax codes V04, V07 and V16 as 'Standard Rates', transactions
with tax codes A04, A07 and A16 as 'Self Supply Rates', and transactions with rate code VEX as 'Export Rates'.
You could then set up a report that prints separate columns for gross and tax based on the Gross/Net/Tax
indicator, and extra columns for each different type of net total, depending on the Gross/Net/Tax indicator
and Classification Code 1 field values.
Setting Up the Standard Tax Reports

Tax Reporting (TXR) uses the following SunSystems facilities to produce the standard tax reports delivered
with the system:
• Document formats to identify the tax reports
• Filters to extract the gross, net or tax transactions for the report
• Rule sets to be able to distinguish between gross, net and tax transactions.
Two tax reports, and their associated document formats, are provided as standard with Financials:
• Tax Listing Detail Report which analyzes the tax by transaction reference - format TL1
• Tax Listing Summary Report which analyzes the tax by account - format TL2.
The tax filter required to extract the transactions is provided and is referenced on each document format. In
addition, the Offset option is set on the document formats.
You must define the business rule required to produce the tax reports.
Setting Up the Business Rules for Tax Reporting

You must define a business rule for the Tax Reporting reports. The rule sets the tax indicator that allows the
tax reports to distinguish between the gross, net and tax transactions. The business rule must identify the
gross, net and tax account codes within your chart of accounts.
Note: The account codes used in these steps refer to those in the PK1 demonstration business unit.
You must create an event profile for the Tax Reporting function. You must then define a rule set for this profile
that sets the Gross/Net/Tax indicator on each transaction to Gross, Net or Tax for the account ranges identified:
Account Code Ranges Set Indicator

64001 to 64999 (Debtor accounts) Gross
10000 to 19999 (Income accounts) Net
94000 to 94999 (Tax accounts) Tax
1 Select Event Profiles (EVP).

2 Enter a new event profile code, click OK and create the new profile.

3 Enter a description and click OK.

4 Click Detail to display the Condition details.
5 Click Create.
6 Enter the following condition field details to define the If Function Code = Tax Reporting statement.
You must press Enter or click OK after each field to accept the information.
Running Tax Reporting

Tax Reporting (TXR) allows you to produce tax reports. Two standard tax report layouts are included in
Financials:
Note: These tax reports are defined using Report Designer. You can use Report Designer to amend these
reports, or define different reports. However, you should be aware of how the tax reports extract, analyze
and summarize the tax related transactions.
The following steps are required to produce tax reports using the standard Financial tax report formats TL1
or TL2:
1 Ensure the business rules have been defined to support the tax reports.
2 Access Tax Reporting (TXR) to display the standard document format print request form.
The Document Format Code at the top of this form determines the type of tax report to be produced.
3 Select the document format, enter the remaining print request details and click OK.
If the tax report includes provisional transactions, these transactions are posted as permanent transactions
if you set the Final Print option. The Document Date entered on the report parameters is used as the
posting date.
4 The tax reporting filter selection form appears. Enter the selection criteria to identify the tax transactions
you want to report on, and select OK.
The transactions that match the selection criteria are extracted and a pop-up dialog identifies the number
of transactions selected.
5 Click OK to display the selected transactions on the Financials - Account Inquiry. This list should only
contain one type of tax transaction, that is gross, net or tax transactions.
6 Highlight the tax transactions you want to include on the tax report, and select Action > Reviewor click
Review.
7 Alternatively, select Action > Review All or click Review All to automatically select all of the transactions.
The selected transactions appear on the Control Desks In-Tray. You can deselect transactions at this
point, if required.
8 Click OK to select the transactions and add them to the interface table for tax reporting.
Do not select a Report Process.
9 Click OK on the Rows Extracted Successfully message that appears at this stage.
Repeat steps 4 to 8 to extract transactions using each filter. The Tax Report Listing window appears
when you have selected transactions using all of the filters available.

The Tax Report Listing window identifies the total number of transactions selected for tax reporting.
This is the total number of transactions included on the interface table which includes any offset
transactions that have been extracted automatically.
10 Click OK to run the tax report. The report is produced by Report Manager in the normal manner.
11 Alternatively, click Exit to cancel the report.
Entering the Tax Reporting Transaction Selection Criteria

The Tax Reporting Filter Selection Criteria window is used to determine the transactions that are extracted
for a tax report. This window appears after you have selected the type of tax report you want to produce by
choosing the appropriate document format.
You should enter the selection criteria to identify the accounts and transactions you want to include in the
report and then click OK. The transactions that match the criteria are listed on the Financials - Account
Inquiry window. This inquiry window is used to pass some, or all, of the selected transactions on to the control
desk to be included in the tax reporting process.
Note: The exact selection fields required are determined by the tax filter associated with the tax report
document format you have chosen. The following selection criteria are available for the standard TL1 and TL2
tax reports.
The range of accounts for which transactions are extracted for the report. This defaults to All to include
transactions for all accounts. The accounts selected in this range may be restricted by Account Type, if
required.
Account Type
The type of accounts extracted for the report. You can restrict the account selection to one or more
account types only, for example, you might restrict the report to Customer, Supplier and Client accounts
only.
Analysis Codes 1 to 10
The range of analysis codes, for each of the ten available analysis dimensions, for which transactions
are extracted for the report. This defaults to All for each analysis dimension to include transactions for
all analysis codes.
Code From/To
The range of transaction currency codes for which transactions are extracted for the report. By default,
all currencies are selected.
Journal Source From/To

The range of journal sources for which transactions are displayed. The journal source typically identifies
the operator that entered the journal. By default, all journal sources are selected.
Journal Type From/To

The range of journal types for which transactions are extracted for the report. This defaults to All to
include transactions for any journal type.

Transaction Reference From/To

The range of transaction references for which transactions are extracted for the report. By default, all
transaction references are selected.
Entry Period From/To

The range of entry periods for which transactions are extracted for the report. This is the accounting
period in which the transactions were entered. By default, all entry periods are selected.

The range of accounting periods for which transactions are extracted for the report. By default, all
accounting periods are selected.
Allocation Period From/To

The range of allocation periods for which transactions are extracted for the report. This is the accounting
period in which the transactions were allocated. By default, all accounting periods are selected.
Transaction Date From/To

The range of transaction dates for which transactions are extracted for the report. By default, all
transaction dates are selected.
Allocation Date From/To

The range of allocation dates for which transactions are extracted for the report. This is the date the
transactions were allocated. By default, all allocation dates are selected.
Due Date From/To

The range of due dates for which transactions are extracted for the report. By default, all due dates are
selected.
Allocation Marker
The allocation markers for which transactions are extracted for the report. You can select one or more
markers to restrict the transactions selected.

The provisional posting status of the transactions extracted for the report. This only applies if provisional
posting is optional or mandatory. Select Yes to include provisional postings or No to exclude provisional
postings. If you include provisional postings these can made permanent postings as part of the reporting
process.
Allocation Marker Not Equal to Correction

Transactions with an allocation marker of Correction are excluded from the report.
Journal Source Not Equal to Cleardown

Transactions generated by the cleardown process are excluded from the report.

Producing financial reports

Financial reports that you can produce include financial analysis reports, financial statement reports and
financial table reports.
Producing a Financial Analysis Report

Financial Analysis (FNA) is used to run a financial analysis report. The report is identified by a layout code
which must have been defined using Financial Analysis Layouts (FNL).
If the report uses the optional ledger balances that can be maintained by the system, you are offered the
option to update the balances when you produce the report.
Note: If a Transfer File Format was selected for the report, a transfer file is also produced.
If you have entered a column code on the financial analysis layout that requires budget information,
SunSystems looks for the relevant budget ledger. If it cannot find it, the budget amounts are shown as zero
on the report.
If you have selected Consolidation in Financial Analysis Layouts, the first time you run the report using
Financial Analysis you are prompted to enter up to thirty business unit codes for consolidation in the report.
You can subsequently amend the business unit codes selected, if required.
Note: Financial Analysis reports do not use the standard report parameter input forms, although a document
format code is required and is defined in the Financial Analysis Layout.
Layout Code
The code for the financial analysis report you want to produce, as defined in Financial Analysis Layout.
The name of the report appears alongside the code.
Supplementary Report Name

An additional title for the report. This name is printed at the top of each page, underneath the text
specified in the Layout Name fields in Financial Analysis Layout.
Period From/To
The accounting period, or range of periods, you want to be included in this report.
Selection 1-5 From/To

Up to five run time selection criteria for the report are displayed. For example, you may be prompted to
enter a range of account codes, analysis codes and currency codes. This criteria determines the
transactions that are retrieved for the report and is defined on Financial Analysis Layouts (FNL).
You can enter a single code, or a range or codes, for each selection dimension. Leave the fields blank to
select all of the codes available for the dimension.
2 The Financial Analysis Consolidation dialog appears when you select Action > Amend Consolidation,
providing the Consolidate option is selected for the report.
You can consolidate values from up to 30 different business units on the report.
Specify this information:

Business Unit Codes

Up to 30 business unit codes can be consolidated on the report. The business unit codes are saved for
subsequent report runs. So, each time you run the report you do not need to re-enter all of the codes,
you only need to make any amendments required
Producing a Financial Statement

The Financial Statements report writer can be used to provide most of your monthly, management reports.
You can use it to design and produce any number of reports, including profit and loss statements, balance
sheets, and so on.
A Financial Statements is defined in two parts using Financial Statement Layouts (FSL) and Financial Statement
Rows (FSR). The report is produced using Financial Statements (FSS).
If you have entered a column code on the statement layout that requires budget information, SunSystems
looks for the relevant budget file. If it cannot find it, the budget amounts are shown as zero on the report.
You can consolidate figures on a Financial Statements from one or more business units. The business units
to be consolidated are identified in Financial Statement Rows (FSR).
If your report uses the optional ledger balances data, you are offered the option to update the balances when
you print the report or save it to disk.
Note: Financial Statements reports do not use the standard report parameter input forms, although a
document format code is required and is defined in the Financial Statement Layout.
Financial Statements (FSS)

Layout Code
The code identifying the statement you want to produce, as defined in Financial Statement Layouts (FSL).
The report rows are defined using Financial Statement Rows (FSR) and identified in the layout. The name
of the report is displayed for your information.

A third title line, which is printed in addition to the two lines defined on the Financial Statement Layouts
(FSL).
Period From/To
The accounting period, or range of periods, you want to appear as this period on your report. Leave the
field blank to select the default, current period.
Selection Codes 1-5 From/To

Up to five run time selection criteria for the report are displayed. This depends on the selection criteria
defined in the financial statement layout. For example, you may be prompted to enter a range of account
codes, analysis codes or currency codes. This criteria determines the transactions that are retrieved for the
report and is defined on Financial Statement Layouts (FSL).

You can enter a single code, or a range or codes, for each selection dimension. Leave the fields blank to select
all of the codes available for the dimension.
The selection criteria also depends on the columns chosen on the report, for example if quarterly columns
are included Accounting Quarter fields appear.
Producing a Financial Table Report

Financial Tables (FTB) is used to produce a Financial Tables report.
The report must first have been defined using Financial Table Formats (FTF), Financial Table Columns (FTC)
and Financial Table Rows (FTR).
You can consolidate figures from more than one business unit. The business units to be consolidated are
defined in Financial Table Columns (FTC).
Note: Financial Table reports do not use the standard report parameter input forms, although a document
format code is required and is defined in Financial Table Formats.
Table Code
The code that identifies the financial table report you want to produce. This is defined in Financial Table
Formats (FTF). The name of the report is displayed; this can be up to two lines and is also set in Financial
Table Formats.

A third, optional, title line for the report. This extra line then appears underneath lines 1 and 2 of the
table name at the top of each page.
Period From/To
The range of periods for the report. The default is the current period. To produce the report for a single
period, leave the To field blank.
Spread Start Period

If your table columns include a Period Spread or Reset Spread data choice, you must enter the period
you want to use for the start of the spread. The default is the current period.
Level Codes 1 and 2 From/To

The headings of the level codes defined on Financial Table Formats are displayed. The default is all
occurrences of the codes. Otherwise, enter the code or range of codes to be printed.
The Level Codes are applied jointly so a transaction has to fall within both ranges of the specified Level
Codes if it is to be shown on the report.
Selection Codes From/To

Additional run time selection criteria for the report are displayed. This depends on the selection criteria
defined in the financial tables format. For example, you may be prompted to enter a range of account
codes, analysis codes and currency codes. This criteria determines the transactions that are retrieved
for the report.
You can enter a single code, or a range or codes, for each selection dimension. Leave the fields blank to
select all of the codes available for the dimension.

The selection criteria also depends on the columns chosen on the report, for example if quarterly columns
are included Accounting Quarter fields appear.
Reporting on Assets
A number of standard reports are available in the fixed asset register. The first three listed below are
user-definable report formats, although layouts, which you can use or adapt, are supplied.
You can use Report Designer to design your own reports.
Asset Register Report

Asset Register Report lists information from the asset record. It shows the gross value, depreciation, and net
book for selected assets.
Asset Notes Report

Asset Notes Report lists the notes that are held of an asset.
Asset Status Report

Asset Status Report is an exception report, which highlights inconsistencies in the asset register. Assets can
be included, for example, if the end depreciation period has been reached and the asset has not been fully
depreciated. Assets that have been selected for disposal can also be included.
User Defined Reports

Where you want to report specific asset information, you should use the report writers Financial Analysis,
Financial Tables and Financial Statements, using asset code, or asset indicator, or both, as a selection criterion
within the report.
Producing the Asset Register Report

The Asset Register Report (REPFAG) shows information for one or more asset records, including asset analysis
information.
You can select a range of asset codes, a range of analysis codes, and the periods from which to list asset
records and transactions.
The report shows asset values, i.e. gross value, accumulated depreciation and net book value, for each asset
code and for each asset subcode present for that asset.

Asset Code From/To

The range of asset codes to be reported. Leave this blank to include all assets.

The range of periods for which transactions are printed on the report. Leave this blank to only include
periods for the current period.
Budget Code
Optionally select a budget code or codes to include in the report. Check the All check box to include all
budget codes.
Producing the Asset Status Report

The Asset Status Report details assets fulfilling the following conditions:
• Assets that have information missing, for example the start period for depreciation.
• Assets that have a net value which is less than their final value.
• Assets expected to be fully depreciated but which are not so. For example, where the accounting period
is after the end period depreciation but the net value is not equal to the final value, or zero.
• Assets that are fully depreciated whose net value is equal to the final value, but which do not have Ready
for Disposal status.
• Assets fully depreciated and marked with Ready for Disposal status, with or without transaction details.
• Assets marked with Suspended status.
• Assets marked with Ready for Disposal status.
Asset Code From/To
The range of the assets to be included on the report. Leave this blank to include all assets.
Analysis Dimension
The asset analysis dimension you want to use to select assets for the report. Leave this blank to select
all dimensions.
Analysis Code From/To

The range of analysis codes within the dimension you have selected to be included in the report.
Period
This period is used to evaluate an asset's status from the start of the asset's life to a particular period.
Leave this blank for the current period.
Asset Status
Options are:
• Blank - to disregard the asset status.
• Suspended - to include assets with a status of Suspended.
• Disposed - to show assets that are marked as Ready for Disposal.

Fully Depreciated
Enter Yes, or leave blank, to report fully depreciated assets that are not marked for disposal. Enter No to
omit these from the report.
Disposed - Transactions Exist

Select Yes to report on disposed assets that still have transactions present. Select No to omit these from
the report.
Disposed - No Transactions
Select Yes to report assets that have been disposed of, and have no transactions present, but where the
asset record still exists. Select No to omit these from the report.
Value Beyond Last Depreciation

Select Yes to include assets that were expected to be fully depreciated, but were not. Select No to exclude
these assets.

Managing fixed assets
Chapter 13: Managing fixed assets
Asset acquisitions, revaluations and other asset related transactions are all entered using SunSystems Ledger
Entry (LEN) or Ledger Import (LIM).
The fixed asset transaction you enter posts to both the balance sheet chart of accounts code for the asset in
Financials, and to the appropriate asset code in the Fixed Assets Register.
Entering Asset Transactions

Asset related transactions must be entered with the asset code, asset subcode and asset indicator on the
journal.
• The asset code identifies the asset in the Fixed Asset Register.
• The asset subcode is optional and identifies an asset posting preset which contains a set of default
transaction analysis codes.
• The asset indicator is important because it identifies how the asset value will be updated by the transaction
amount.
See 'How are the Asset Values Updated?'
Before you enter a ledger transaction to record an asset acquisition, you may need to:
• set up the new asset in the Fixed Assets Register using Asset Records (FAS)
• set up a new corresponding budget asset using Asset Budget Details (FAB)
• set up a new balance sheet account for the asset in the Financials ledger using Chart of Accounts (COA).
Optionally, you can also enter an asset quantity in the Memo AmountLedger Entry (LEN) field. In order to
re the following configuration must previously have been defined:
• Use Asset Quantity option on the General tab of Ledger Setup (LES) must be checked field. In order to
record asset quantities in
• Non-Currency Value Post Rule on the Memo Value tab of Business Unit Setup must not be set to
Undefined
• Memo Post Rule Override field in Journal Types Setup (Posting Overrides) (JDX) must not be set to
Undefined.
Further information is available in 'Entering the Journal Details' and 'Ledger Entry Asset Details'.

The effect of depreciation locking

You can lock the depreciation accumulated to date.
If you do this, the straight line depreciation calculation for each asset is calculated as the asset's net value
divided by the number of depreciation periods remaining for the asset.
Example
In a 12 period accounting year, an asset purchased in 07/2007 with a gross value of 2600 Euros is depreciated
until 11/2011 at straight line 20% at 43.34 Euros. Check the check box Lock Calculated Depreciation in Ledger
Setup (LES), and change the asset percentage to 12.5%.
Run Depreciation Calculation (FDC) historically for period 06/2012. The calculated depreciate charge is now
7.05 Euros. This new depreciation charge is calculated as follows:
100 / 12.5% x 12 = 96
As 52 of the 96 periods have already been depreciated, the remaining 43 periods are then depreciated at the
new percentage.
Example
Asset net value / depreciation periods remaining = new depreciation charge.
The effect of depreciation locking combined with adjustments

to gross value
When working with Depreciation Locking switched on in Ledger Setup (LES), you should first run the
depreciation calculation for all of the previous periods before manually posting any adjustments to the gross
value of an asset in the current period.
However, when an asset value is increased (or decreased) using a V Marker in Ledger Entry (LEN) and Ledger
Import (LIM), a warning message is displayed if the depreciation is not up to date. This is so that the revised
depreciation takes effect only from the accounting period of the revised value.
Manually posting a depreciation amount

Under normal circumstances it is not recommended to manually post a depreciation amount to an asset
using Ledger Entry (LEN).
This is because posting a depreciation transaction to an asset in a particular period then excludes the asset
from the Depreciation Calculation (FDC) for that period. If the amount you post is not in line with the asset's
depreciation rate, gross value and number of periods depreciated, then depending on the specific
circumstances, the subsequent period's depreciation calculation might include an amount to compensate

for the change. You can suppress this compensation amount for all assets by checking theLock Calculated
Depreciation check box on the Ledger Setup (LES).
However, it may be appropriate to manually post a depreciation amount to an asset under the following
circumstances:
• You are posting a depreciation amount that correctly brings the accumulated depreciation into line with
the depreciation rate, gross value and number of periods depreciated. For example, posting the
accumulated depreciation of an asset that you are migrating into SunSystems.
• You are posting the depreciation to an asset that is excluded from the depreciation calculation, for
example if its depreciation method is defined as no-depreciation on the Value tabs in Asset Records
(FAS).
• You are posting a manual correction or adjustment to the accumulated depreciation of an asset, for
example, in an asset revaluation. In this case it is usually necessary to also adjust the gross value (using
an additional journal), the percentage or the start period of depreciation in Asset Records (FAS), so that
the manually posted depreciation is not reversed by the depreciation calculation in the following period.
In addition to standard depreciation, if you are using enhanced depreciation you can post manual adjustments
for advanced and reduction depreciation. You must use specific journal types for each, which must first have
been created in Journal Types (JNT), with the Asset Depreciation Type option set to Standard, Advanced or
Reduction, as appropriate.
Running the depreciation calculation

Depreciation Calculation calculates and posts depreciation for a range of asset codes. It does so for all of the
periods between the last time depreciation was calculated and the selected period.
Each asset record contains the following details which are used by the Depreciation Calculation as the basis
for the calculations:
• The depreciation method
• The gross value of the asset, calculated from transactions
• The accumulated depreciation, calculated from transactions
• The net value of the asset, the difference between the gross value and accumulated depreciation
• The final value of the asset, which can either be deducted before depreciation is calculated, or can be a
value below which depreciation is not calculated.
Additionally, the depreciation cost can be spread according to the timing rules code defined in Depreciation
Timing Rules, or apportioned across different analysis codes according to the preset posting analysis details,
or both. For example, a timing rule could be defined if you have 13 accounting periods in a financial year but
you only want to calculate depreciation for the 12 operational periods because the final thirteenth period is
used for holding year end adjustments.

Closed or suspended accounts

You can specify a suspense account to be used in Depreciation Calculation.
If any depreciation is due to be charged to an account with a status of Closed or Suspended in Chart of Accounts
(COA), the posting is made to the suspense account and a warning is given on your depreciation calculation
report.
Multi-currency depreciation
Asset values can be maintained in the base currency, transaction currency, and second base / reporting
currency, and different depreciation methods may be used for each.
Depreciation Calculation calculates the depreciation required for the base, transaction, and second base /
reporting currencies.
Note: If you are using expenditure checking, transactions are posted during Depreciation Calculation even
if budgets are exceeded.
Depreciation exceptions
If an asset already has a depreciation amount posted to it within a period, then it is excluded from the
Depreciation Calculation for that period, and a depreciation amount is therefore not posted for that asset.
You cannot post depreciation to an asset that has the status Ready for Disposal or Suspended.
The final value is a value below which depreciation is not calculated. It can either be deducted before
depreciation is calculated, so that it is always excluded from depreciation calculations, or depreciation can
be calculated on the gross amount, until the net value reaches the final value. In the final depreciation
calculation, only the difference between the net value and the final value is generated.
It is important to note that the net value may be less than the final value if depreciation is posted manually
or if the gross value is reduced by posting a disposal. Such exception conditions are shown on the Asset Status
Listing.
Calculating depreciation
Use Depreciation Calculation (FDC) to calculate depreciation.
Asset Class From/To
The asset class, or the range of asset classes, to be processed. Leave this blank either to select all assets,
or if you want to select specific asset codes in the field below.

Asset Code From/To

The asset code, or range of asset codes, to be depreciated. Leave these fields blank to select all assets.
Analysis Dimension
The asset analysis dimension to be used to select assets. Leave this blank to select all assets, regardless
of the analysis dimensions.

If an Analysis Dimension has been chosen as the selection criterion above, this analysis code or range
of codes is used to select the assets. Only assets that reference one of these codes in the chosen analysis
dimension are selected for depreciation.
Depreciation Period
Depreciation is calculated for periods between the last period for depreciation and the period selected
here. The default is for depreciation to be calculated up to the current period. Otherwise, enter the
period up to which depreciation is to be calculated.
Post Transactions
If you wish to report on the depreciation calculations without posting them, select No. Select Yes to
calculate and post the depreciation. If provisional postings are mandatory or optional, you can select
Post Provisional to post the transactions as provisional transactions. A depreciation report is always
produced.
Posting Period
Select Single to post all of the calculated depreciation to the period specified in the Depreciation Period
field. Select Historic to post the calculated depreciation to the period to which it relates.
Select Yes if you only want to print the asset transactions generated during this run. Select No if all of the
asset transactions are to be printed, including any previous depreciation, asset and disposal transactions.
Balance Sheet
The balance sheet depreciation account to which the depreciation is posted. Normally, depreciation is
posted to the balance sheet account on the asset record in Asset Records. If this account is blank in
Asset Records, then the account entered in this field is used.
Note: SunSystems does not check that the account entered is a Balance Sheet type account.
Profit and Loss

The profit and loss depreciation account to which the depreciation is posted. Normally, depreciation is
posted to the profit and loss account on the asset record in Asset Records. If this account is blank in
Asset Records, then the account entered in this field is used.
Note: SunSystems does not check that the account entered is a Profit and Loss type account.
Consolidate Profit and Loss

Normally two postings are generated for each asset's depreciation calculation: one to the balance sheet
accumulated depreciation account and the other to the profit and loss depreciation expense account.
If this field is set to Yes, then you can specify how you want to consolidate the profit and loss postings.

Depreciation calculation consolidation

If you select Yes in the Consolidate Profit and Loss field, when you click OK the Depreciation Calculation
Consolidation form is displayed.
This allows you to define how you wish to consolidate the profit and loss depreciation transactions.
Asset Code From/To
Check the Asset Code check box to consolidate the profit and loss posting by asset code into one transaction
line. You can specify the range of asset codes to be consolidated, or alternatively leave the From and To
fields blank with the check box checked if you want all asset codes to be consolidated.
Analysis Dimension
For each analysis dimension, check the check box to consolidate the profit and loss posting by that analysis
dimension into one transaction line. You can specify the range of analysis codes to be consolidated, or
alternatively leave the From and To fields blank with the check box checked if you want all analysis codes
for that dimension to be consolidated. Additionally, analysis codes are removed if the analysis is not allowed
for the relevant depreciation account.
Note: If you consolidate asset codes and/or analysis codes then those codes are not included on the
consolidated transaction line.
In addition to consolidation, you can also use Business Rules to set or validate analysis codes on the generated
transactions. To do this, create an Event Profile that checks for a Function Code of Asset Depreciation, and
use a Call Point of either 00015 Populate or 00016 Validate Analysis on System Generated Transactions.
Note: If you use both Consolidation and Business Rules for this function, the analysis codes validated and
set by Business Rules are definitive, and if different, override the codes set (or removed) by Consolidation.
This is because the Business Rules operate after the Consolidation process finishes setting analysis codes
on the generated transactions.
for this to the asset depreciation transaction report.
Performing an Asset Inquiry

Fixed Asset Inquiry (FAQ) allows you to display a range of posted journal transactions. This inquiry uses a
predefined control desk and filter. The inquiry results are displayed on the Financials Inquiry window
1 Select Fixed Asset Inquiry (FAQ) from SunSystems to display the Asset Inquiry selection form.
2 Enter the selection details. A transaction must meet all of the selection criteria to be displayed.
3 Click OK to extract the transaction details.
4 They appear on the Financials Inquiry window.

Enhanced depreciation
In certain countries, financial legislation allows companies to implement a number of additional accounting
elements and calculations over normal straight line depreciation, known collectively as "Enhanced
depreciation".
Use Fixed Asset Reduction Depreciation Selection (FDR) to select assets for reduction depreciation. Use Asset
Advanced Depreciation Selection (FDA) to select assets for advanced depreciation.
Selecting assets for reduction depreciation

Reduction depreciation reduces the amount of ordinary depreciation by a percentage you specify, during a
particular year of an asset's useful life. When a reduction depreciation is applied to an asset for a certain year,
there can be no advanced depreciation for the asset in that year.
Use Fixed Asset Reduction Depreciation Selection (FDR) to determine which assets are to be included in the
reduction and the percentage by which their depreciation rate is reduced. Following this selection, use Asset
Reduction Depreciation Calculation (FAR) to calculate and post the reduction.
Note: You can also set the depreciation reduction percentage manually for specific assets in Asset Records
(FAS) before running the reduction depreciation.
The steps required to configure and run reduction depreciation are described in 'Setting Up the Elements of
Enhanced Depreciation' in the Financials Administrator Guide.
1 Open Fixed Asset Reduction Depreciation Selection (FDR).
Asset Class From/To
The asset class, or the range of asset classes, to be selected. Leave this blank either to select all assets,
Asset Code From/To

The asset, or the range of assets, to be selected for reduction depreciation. Leave this blank to select all
asset codes.
Analysis Dimension
An analysis dimension for which you may select a range of codes to be included. Leave this blank to
select all dimensions.

The analysis code, or range of analysis codes, for the analysis dimension chosen above, to be used to
select assets for reduction depreciation. Leave this blank to include all analysis codes for the dimension
selected.
Reduction Percentage
Enter the percentage (0 to 100) by which the ordinary depreciation is to be reduced for the selected
assets for the current year.
Note: By entering 0 (zero) in the Reduction Percentage, you can clear the % Current Year Reduction
field on all of the assets selected, thus leaving that field blank in Asset Records (FAS) for those assets.

Running the Reduction Depreciation

If you are using enhanced depreciation, you might need to apply the reduction depreciation to certain fixed
assets. This reduces the amount of ordinary depreciation by a percentage you specify, during a particular
year of an asset's useful life. When a reduction depreciation is applied to an asset for a certain year, there can
be no advanced depreciation for the asset in that year. Standard depreciation is posted during all the periods
of the year (normally 12), and then in the last period the reduction depreciation posts a separate transaction
in the normal asset accounts (balance sheet and profit and loss).
Before running the reduction depreciation, use Fixed Asset Reduction Depreciation Selection (FDR) to
determine which assets are to be included in the reduction and the percentage by which their depreciation
rate is to be reduced, or alternatively set the percentages manually in Asset Records (FAS). Use Asset
Reduction Depreciation Calculation (FAR) to calculate and post the reduction.
transactions. To do this, create an Event Profile that checks for a Function Code of Asset Advanced/Reduction
Depreciation Calculation, and use a Call Point of either 00015 Populate or 00016 Validate Analysis on
System Generated Transactions.
• If you use both Consolidation and Business Rules for this function, the analysis codes validated and set
by Business Rules are definitive, and if different, override the codes set (or removed) by Consolidation.
This is because the Business Rules operate after the Consolidation process finishes setting analysis codes
on the generated transactions.
• If a transaction fails validation by a business rule using call points 0015 or 0016, by default the error
message is not shown in the transaction report. This is because it is not included in the SunSystems
sample reports; therefore, to show the details of such analysis code validation, you must add an
appropriate column for this to the asset depreciation transaction report.
Asset Class From/To
Asset Code From/To

The asset code, or range of asset codes, on which to perform the reduction depreciation. Leave these
fields blank to include all assets that have percentage specified in the % Current Year Reduction option
in Asset Records.
Analysis Dimension
The asset analysis dimension to be used to select assets. Leave this blank to include all assets that have
percentage specified in the % Current Year Reduction option in Asset Records, regardless of the analysis
dimensions.

dimension are selected for reduction depreciation.

Depreciation Period
Enter the last period of the current year.
Post Transactions
If you wish to report on the reduction depreciation calculations without posting them, select No. Select
Yes to calculate and post the reduction depreciation. If provisional postings are mandatory or optional,
you can select Post Provisional to post the transactions as provisional transactions. A reduction
depreciation report is always produced.
Posting Period
Select Single to post all of the calculated depreciation reduction to the period specified in the
Depreciation Period field. Select Historic to post the calculated depreciation reduction to the period
to which it relates.
asset transactions are to be printed, including any previous depreciation and reduction depreciation,
asset and disposal transactions.
Balance Sheet
The balance sheet depreciation account to which the reduction depreciation is posted. Normally,
reduction depreciation is posted to the balance sheet account on the asset record in Asset Records. If
this account is blank in Asset Records, then the account entered in this field is used.

Normally two postings are generated for each reduction depreciation calculation: one to the balance
sheet accumulated depreciation account and the other to a profit and loss depreciation expense account.
If this field is set to Yes, then you can specify how you want to consolidate the profit and loss postings.
2 If you select Yes in the Consolidate Profit and Loss field, when you click OK the Depreciation
Consolidation form is displayed. This allows you to define how you wish to consolidate the profit and
loss depreciation transactions.
Asset Code From/To
Check the Asset Code check box to consolidate the profit and loss posting by asset code into one
transaction line. You can specify the range of asset codes to be consolidated, or alternatively leave the
From and To fields blank with the check box checked if you want all asset codes to be consolidated.
Analysis Dimension
For each analysis dimension, check the check box to consolidate the profit and loss posting by that
analysis dimension into one transaction line. You can specify the range of analysis codes to be
consolidated, or alternatively leave the From and To fields blank with the check box checked if you want
all analysis codes for that dimension to be consolidated. Additionally, analysis codes are removed if the
analysis is not allowed for the relevant depreciation account.

Selecting assets for advanced depreciation

If you are using advanced depreciation, you need to select assets or groups of assets to be included in the
advanced depreciation calculation for a particular year. Use Asset Advanced Depreciation Selection (FDA)
to select the assets which must be included in the calculation. This checks the Apply Current Year check box
in the Value 1, Value 2 and Value 3 tabs in Asset Records (FAS). You can use the Process Mode option to
determine whether your selection is to be included or excluded from the advanced depreciation calculation,
however, certain assets in your selection may not be included, depending on their Apply From and Term of
Years settings in Asset Records, as detailed below.
1 Open Asset Advanced Depreciation Selection (FDA).
Asset Class From/To
Asset Code From/To

The asset, or the range of assets, to be processed. Leave this blank to select all asset codes.
Analysis Dimension
An analysis dimension for which you may select a range of codes to be processed. Leave this blank to

select assets. Leave this blank to process all analysis codes for the dimension selected.
Process Mode
Determines the course of action to be performed on the group of assets selected above.
Select Exclusion to remove the check from the Advanced Current Year check box in Asset Records
(FAS) for the group of assets, thus excluding them from the advanced depreciation calculation for the
current year.
Select Reset to check the Advanced Current Year check box for the group of assets. For each asset in
the selection, the check box is checked unless the current year is after the term of advanced depreciation
for the asset, in which case it is unchecked. To establish whether or not the year falls into the term of
advanced depreciation, the system inspects both the Apply From and Term of Years options on the
asset record.
Running the advanced depreciation calculation

Note: Before calculating the advanced depreciation, you must use Asset Advanced Depreciation Selection
(FDA) for all the assets to be included in the calculation, to check or uncheck their Apply Current Year check
boxes depending on their Apply From and Term of Years settings in Asset Records (FAS). Advanced
depreciation is not calculated in the current year for assets that have been processed with Asset Reduction
Depreciation Calculation (FAR), nor for assets that have their Apply Current Year check box unchecked.

From SunSystems select Asset Advanced Depreciation Calculation (FAA) to calculate advanced depreciation
at year-end, after all ordinary depreciation methods have been posted. The advanced depreciation is posted
to the same periods as ordinary depreciation, and therefore may be 'back-posted' to periods throughout the
year. By setting the Post Transactions option to No on the Advanced Depreciation Calculation form, you can
run advanced depreciation calculations without posting to the ledger. You can view the calculation results
report, and try different scenarios to help you decide whether to include a group of assets or not for the
definitive calculation.
Advanced depreciation, also sometimes called 'anticipated depreciation', is the multiplication of the ordinary
depreciation amount by a factor during the first few years of the asset life. Both the multiplication factor and
the term in years for which advanced depreciation applies are defined on each asset record using Asset
Records (FAS).
1 Open Asset Advanced Depreciation Calculation (FAA).
Asset Class From/To
Asset Code From/To

The asset code, or range of asset codes, to be depreciated. Leave these fields blank to select all assets.
Analysis Dimension
The asset analysis dimension to be used to select assets. Leave this blank to select all assets, regardless
of the analysis dimensions.

dimension are selected for advanced depreciation.
Depreciation Period
Enter the last period of the current year.
Post Transactions
If you wish to report on the advanced depreciation calculations without posting them, select No. Select
Yes to calculate and post the advanced depreciation. If provisional postings are mandatory or optional,
you can select Post Provisional to post the transactions as provisional transactions. An advanced
depreciation report is always produced.
Posting Period
Select Single to post all of the advanced depreciation calculated to the period specified in the
Depreciation Period field. Select Historic to post the advanced depreciation calculated to the period
to which it relates.
asset transactions are to be printed, including any previous depreciation, asset and disposal transactions.

Balance Sheet
The balance sheet advanced depreciation account to which the advanced depreciation is posted.
Normally, advanced depreciation is posted to the Advanced Deprctn Acnt Bal Sheet identified on the
asset record in Asset Records. If this account is blank in Asset Records, then the account entered in
this field is used.
Profit and Loss

The profit and loss advanced depreciation account to which the advanced depreciation is posted.
Normally, advanced depreciation is posted to the Advanced Deprctn Acnt P&L identified on the asset
record in Asset Records. If this account is blank in Asset Records, then the account entered in this field
is used.
Note: SunSystems does not check that the account entered is a Profit and Loss type account.

Normally two postings are generated for each asset's advanced depreciation calculation: one to the
balance sheet advanced depreciation account and the other to a profit and loss advanced depreciation
expense account. If this field is set to Yes, then you can specify how you want to consolidate the profit
and loss postings.
Advanced depreciation calculation consolidation

If you select Yes in the Consolidate Profit and Loss field, when you click OK, the Depreciation Consolidation
form is displayed.
This allows you to define how you wish to consolidate the profit and loss advanced depreciation transactions.
Asset Code From/To
Check the Asset Code check box to consolidate the profit and loss posting by asset code into one transaction
line. You can specify the range of asset codes to be consolidated, or alternatively leave the From and To fields
blank with the check box checked if you want all asset codes to be consolidated.
Analysis Dimension
For each analysis dimension, check the check box to consolidate the profit and loss posting by that analysis
dimension into one transaction line. You can specify the range of analysis codes to be consolidated, or
alternatively leave the From and To fields blank with the check box checked if you want all analysis codes
for that dimension to be consolidated. Additionally, analysis codes are removed if the analysis is not allowed
for the relevant advanced depreciation account.
transactions. To do this, create an Event Profile that checks for a Function Code of Asset Advanced/Reduction
Depreciation Calculation, and use a Call Point of either 00015 Populate or 00016 Validate Analysis on
System Generated Transactions.

If you use both Consolidation and Business Rules for this function, the analysis codes validated and set by
Business Rules are definitive, and if different, override the codes set (or removed) by Consolidation. This is
because the Business Rules operate after the Consolidation process finishes setting analysis codes on the
generated transactions.
for this to the asset depreciation transaction report.
Calculating Advanced and Reduction Depreciation

For specific Help on calculating advanced depreciation, see 'Running the Advanced Depreciation Calculation'.
For specific Help on calculating reduction depreciation, see 'Running the Reduction Depreciation'.
For a general understanding of these depreciation methods, see 'What are the Elements of Enhanced
Depreciation?'.
Asset Disposal
Disposing of an Asset
There are three stages involved in the disposal of an asset:
1 You must identify the asset to be disposed of by setting the Asset Status to Ready for Disposal. You can
do this manually using Asset Records (FAS), or you can change the status for a range of assets using
Asset Disposal Selection (FAE).
2 You should use Ledger Entry (LEN) to manually post any sales proceeds for the asset, if it has been sold.
Note: Do not remove the asset static data if sales proceeds are to be posted after disposal. The asset
sale proceeds posting does not need to contain an Asset Marker.
3 You must then use Asset Disposal to dispose of the assets by generating transactions that reduce the
asset values to zero, and remove the selected asset details. If Force Journal Listing is switched on in
Ledger Setup (LES), then a listing of the generated transactions is printed.
Note: If you are using over-expenditure checking, transactions are posted during Asset Disposal even if
budgets are exceeded.
If you choose to remove asset details, note that they are still accessible in Ledger Inquiry.
Once an asset has been processed by Asset Disposal, the Disposed flag is set for the asset on Asset Records
(FAS).

Determining the disposal period

Transactions are posted to the disposal period specified on the asset record, provided it falls within the range
of periods selected in the asset disposal process.
If the disposal period on the asset record is blank, then the disposal transactions generated are posted to the
last period in the disposal period range. The disposal period on the asset record is also updated with this
period.
What are the disposal postings?

The following disposal postings are generated:
• Credit the balance sheet asset account with the gross value of the asset, including any adjustments
• Debit the profit and loss account specified with the same gross value amount
• Debit the balance sheet accumulated depreciation account with the accumulated depreciation value
• Credit the profit and loss account specified in Asset Disposal with the same accumulated depreciation
amount.
Sequence codes can be applied to the system generated asset disposal transactions, if required.
Note: If asset posting preset subcodes have been used to apportion the depreciation values across a series
of analysis codes using the preset factors, the same factors are used to apportion the accumulated depreciation
disposal postings. See 'Presetting the Asset Posting Analysis Codes'.
In addition to presetting the analysis codes for the asset postings, you can also use Business Rules to set or
validate analysis codes on the transactions generated by the disposal. To do this, create an Event Profile
that checks for a Function Code of Asset Depreciation, and use a Call Point of either 00015 Populate or 00016
Validate Analysis on System Generated Transactions.
Note:
• If you use both Preset Analysis Codes and Business Rules for this function, the analysis codes validated
and set by Business Rules are definitive, and if different, override the codes set by Preset Analysis Codes.
This is because the Business Rules operate after the disposal process finishes setting analysis codes on
the generated transactions.
• If a transaction fails validation by a business rule using call points 0015 or 0016, by default the error
message is not shown in the transaction report. This is because it is not included in the SunSystems
sample reports; therefore, to show the details of such analysis code validation, you must add an
appropriate column for this to the asset disposal transaction report.
Selecting a group of assets for disposal

Prior to using Asset Disposal (FAD), you need to identify and flag the assets you want to dispose of by setting
the assets' status to Ready for Disposal.
You can use Asset Disposal Selection (FAE) to set this status for a group of assets. Alternatively, you can set
the status on an individual asset in Asset Records (FAS) and specify the disposal period.

Complete these steps to select and mark assets for disposal.

1 Enter the asset selection details in Asset Disposal Selection (FAE).. Specify this information:
Asset Class From/To
Asset Code From/To

The asset, or the range of assets, to be selected for disposal. Leave this blank to select all asset codes.
Analysis Dimension
An analysis dimension for which you may select a range of codes to be included. Leave this blank to

select assets for disposal. Leave this blank to include all analysis codes for the dimension selected.
2 Select Action > Process to select the assets and change the asset status.
Disposing of Assets
Asset Disposal (FAD) can automate the procedures for disposing of a selected asset or group of assets. It
generates the relevant disposal postings, and reports the postings.
You must first select the assets for disposal by setting the Ready for Disposal status for each asset.
Note: Do not remove the asset static data if sales proceeds are to be posted after disposal. The asset sale
proceeds posting does not need to contain an Asset Marker.
You can use Business Rules to set or validate analysis codes on the transactions generated by the disposal.
To do this, create an Event Profile that checks for a Function Code of Asset Disposal, and use a Call Point
of either 00015 Populate or 00016 Validate Analysis on System Generated Transactions.
Asset Class From/To
Asset Code From/To

The asset code, or range of assets codes, to be disposed of providing the Asset Status is set to Ready
for Disposal.
Analysis Dimension
You can select assets for disposal according to their asset analysis dimensions. Leave it blank to select
all dimensions.


These fields restrict your choice to selected analysis codes within the asset analysis dimension you have
selected. Leave these blank to select all codes.
Disposal Period From/To

The period, or range of periods, for which you want to dispose the assets. Transactions are posted to
the disposal period specified on the asset record, provided it falls within the range of periods selected
here. If the disposal period on the asset record is blank, then transactions generated during the disposal
are posted to the last period in the disposal period range. The disposal period on the asset record is also
updated with this period.
Profit and Loss Disposal Account

The profit and loss account to which the disposal transactions are posted.
Post Transactions
Select No to report on the disposal transactions but not post them. Select Yes to post the transactions.
If provisional postings are optional, you can select to post the transactions as provisional transactions.
Remove Asset Details

This field is displayed only if you selected to post the disposal transactions. Options available are:
• No - select this if the asset details are not to be removed.
• Remove Transactions - select this to remove transaction details for the disposed asset from the Fixed
Assets Register. They are still accessible in Financials for account inquiries and reports.
• Remove Transactions and Assets - select this to remove transaction and asset details from the Fixed
Assets Register.
Disposal Suspense Account

The account to be used if any of the transactions generated by disposal have memo type accounts. To
make sure the disposal journal balances, any memo accounts are replaced by this disposal suspense
account.
What is Asset Part Disposal?

Asset Part Disposal (FAF) assists you in disposing of part of an asset, by allowing you to select the asset and
specify the quantity you want to dispose of.Using the Asset QuantityUsing the Asset Quantity
This can be part, or all, of the current asset quantity of the selected asset. The relevant disposal postings are
generated, and the transactions are listed in a report.
For example, if a company purchases 100 identical chairs, one asset might be created with asset code CH01,
with a quantity of 100 and an initial value of 10,000 euros. After a year, 20 of the chairs are sold or physically
disposed of, and must be taken off the books. In the asset register, this constitutes a part disposal of 20 of
the original asset quantity of 100. Asset Part Disposal (FAF) is used to automatically generate the relevant
postings for the part disposal, to set the asset quantity to 80 for asset CH01, and to reduce the value and
accumulated depreciation amounts by 20% (as 20/100 chairs are being disposed of).

Using the Asset Quantity
Disposing of Part of an Asset's Quantity
Determining the Part Disposal Period
What are the Part Disposal Postings?
Asset Posting Presets
Business Rules
Using the Asset Quantity

In order to dispose of part of an asset, the asset must have an asset quantity posted to it using Ledger Entry
(LEN).
To record asset quantities in Ledger Entry (LEN), the following configuration must previously have been
defined:
• On the General tab of Ledger Setup (LES), the Use Asset Quantity check box must be checked.
• A Ledger Entry (LEN) form that includes the Memorandum Amount must be made available using Form
Designer (FRD). The Memorandum Amount is used for entering the asset quantity.
• Non-Currency Value Post Rule on the Memo Value tab of Business Unit Setup must not be set to
0-Undefined.
• Memo Post Rule Override in the special Journal Types Setup (Posting Overrides) form must not be
set to 0-Undefined.
Disposing of Part of an Asset's Quantity

There are two stages involved in the part disposal of an asset:
1 If part of the asset has been sold, use Ledger Entry (LEN) to manually post any sales proceeds for that
part of the asset.
Note: You must post the proceeds of the sale prior to disposing of the part quantity of the asset.
2 Use Asset Part Disposal (FAF) to select the asset and enter the quantity that you want to dispose of.
Once an asset has been processed by Asset Part Disposal, the Part Disposed flag and the Part Disposal
Period are both set appropriately for the asset on the Asset Record (FAS).
Note: Asset budgets are not checked or modified by part disposals. If you are using over-expenditure checking,
transactions are posted during Asset Part Disposal even if budgets are exceeded.

Determining the Part Disposal Period

Transactions are posted to the part disposal period specified on the asset record, provided it falls within the
range of periods selected in the asset part disposal process.
If the part disposal period on the asset record is blank, then the part disposal transactions generated are
posted to the last period in the entered range. The part disposal period on the asset record is then updated
with this period.
What are the Part Disposal Postings?

The following postings are generated:
• Credit the balance sheet asset account with the fraction of the asset's value that corresponds to the
quantity being disposed. This transaction contains the asset code and an asset indicator of Initial.
• Debit the profit and loss account (specified in Asset Part Disposal) with the same fraction of the asset's
value
• Debit the balance sheet accumulated depreciation account with the fraction of the accumulated
depreciation that corresponds to the quantity being disposed. This transaction contains the asset code
and an asset indicator of Depreciation.
• Credit the profit and loss account (specified in Asset Part Disposal) with the same fraction of accumulated
depreciation.
Asset Posting Presets

If Asset Posting Presets are being used to assign analysis codes on the asset transactions, you may need to
consider how these should be changed after a part disposal.
You can access Asset Posting Presets from within Asset Records (FAS), and use a different asset subcode
for each portion of the asset transactions that you want to apportion to an analysis code.
For example, if the Asset Posting Presets previously apportioned 20% of the asset transactions to the analysis
code for a location that no longer belongs to the company, then after the part disposal, the asset subcode
corresponding to that location (the 20%) should be deleted, so that the remaining asset subcodes are
redistributed proportionately across the remaining location analysis codes.
Note: If asset posting preset subcodes are being used to apportion the depreciation values across a series
of analysis codes using the preset factors, the same factors are used to apportion the part disposal postings
for the accumulated depreciation. The analysis codes posted on the disposal transaction can be subsequently
changed, if necessary, using Account Allocation.
Business Rules
In addition to presetting the analysis codes for the asset postings, you can also use Business Rules to set or
validate analysis codes on the transactions generated by the disposal.

To do this, create an Event Profile that checks for a Function Code of Asset Depreciation, and use a Call
Point of either00015 Populate or 00016 Validate Analysis on System Generated Transactions.
Note: If you use both Asset Posting Presets and Business Rules for this function, the analysis codes validated
and set by Business Rules are definitive, and if different, override the codes set by Asset Posting Presets.
This is because the Business Rules operate after the Part Disposal process finishes setting analysis codes on
the generated transactions.
Note: If a transaction fails validation by a business rule using call points 0015 or 0016, by default the error
for this to the relevant asset disposal transaction report.
Disposing of part of the quantity of an asset

Asset Part Disposal (FAF) can automate the procedure for disposing of part of an asset, by allowing you to
specify the quantity you want to dispose of, and generating the relevant disposal postings. This can be part,
or all, of the current asset quantity of the selected asset. The disposal transactions are listed in a report.
You can use Business Rules to set or validate analysis codes on the transactions generated by the part disposal.
To do this, create an Event Profile that checks for a Function Code of Asset Disposal, and use a Call Point
of either 00015 Populate or 00016 Validate Analysis on System Generated Transactions.
1 Open Asset Part Disposal (FAF).
Asset Code
Select the asset that you want to dispose part of.
Asset Quantity
Display only. The current asset quantity of the selected asset, as stored on the asset record.
Analysis Dimension
You can select an asset for part disposal according to its asset analysis dimensions. Leave it blank to

These fields restrict your choice to selected analysis codes within the asset analysis dimension you have
selected above. Leave these blank to select all codes.
Disposal Quantity
The quantity of the selected asset that you want to dispose of. This must be greater than zero, and cannot
be more than the current asset quantity remaining on the selected asset record. If the quantity you enter
equals the total asset quantity, a complete asset disposal is processed, as described in 'What is Asset
Disposal?'
Part Disposal Period From/To

The period, or range of periods, for which you want to part dispose of the asset. Transactions are posted
to the Part Disposal Period specified on the asset record, provided it falls within the range of periods
selected here. If the Part Disposal Period on the asset record is blank, then transactions generated

during the disposal are posted to the last period in the range selected here. The Part Disposal Period
on the asset record is also updated with this period.
Profit and Loss Disposal Account

The profit and loss account to which the disposal transactions are posted.
Post Transactions
Select No to report on the part disposal transactions but not post them. Select Yes to post the transactions.
If provisional postings are optional, you can select to post the transactions as provisional transactions.
Remove Details
This field is only displayed if you select to post the disposal transactions, and the Disposal Quantity
you enter equals to the total quantity of the asset (that is, a complete asset disposal). Options available
are:
• No - select this if the asset details are not to be removed
• Remove Transactions - select this to remove transaction details for the disposed asset from the Fixed
Assets Register. They are still accessible in Financials for account inquiries and reports.
• Remove Transactions and Assets - select this to remove transaction and asset details from the Fixed
Assets Register.
Disposal Suspense Account

The account to be used if any of the transactions generated by disposal have memo type accounts. To
make sure the disposal journal balances, any memo accounts are replaced by this disposal suspense
account.

Reconciliation Manager
Chapter 14: Reconciliation Manager
Reconciliation Manager (RCM) provides the facility to match and reconcile transactions in the SunSystems
ledgers, either automatically according to predefined match criteria, or manually.
Reconciliation Manager allows you to reconcile transactions on different accounts. For example, to reconcile
transactions that appear on two corresponding inter-company accounts.
Because of its flexibility Reconciliation Manager has a number of uses including:
• bank reconciliation
• inter-company reconciliation
• debtor/creditor payment matching.
Reconciliation Manager matches and then reconciles two sets of transactions according to a set of predefined
match criteria. The two sets of transactions are defined as separate reconciliation accounts. The selection
and matching criteria are defined in a reconciliation profile.
Reconciliation Manager can reconcile the transactions automatically using the match criteria and also allows
you to manually reconcile the transactions. This is particularly useful if you are reconciling a large number
of transactions because you can automatically reconcile all of the obvious matches, then manually check the
results and make any further reconciliations.
For example, if you use Reconciliation Manager to perform a bank reconciliation, you can automatically
reconcile the bank account postings to the bank statement details by matching on the amount and reference
number. Then you can manually reconcile any additional transactions such as bank charges.
The Three Reconciliation Steps

There are three stages to configuring and running the Reconciliation Manager:
1 Define a reconciliation profile to identify a reconciliation requirement and determine the transaction
selection criteria.
2 Define two reconciliation accounts to identify the two sets of transactions to be reconciled.
3 Run the Reconciliation Manager using the reconciliation profile to match and reconcile the transactions.
Note: The first two steps are only required once for a reconciliation requirement.
The Reconciliation Manager allows you to:
• automatically and manually match items.
• generate a journal for any balancing entries required such as exchange gains and losses, or bank charges.

• split values.
• produce a reconciliation report.
• post the reconciliations.
Running Reconciliation Manager

Reconciliation Manager (RCM) is used to reconcile or match two sets of transactions. The two sets can be
from the same business unit, from different business units, or if you use multiple databases they can be from
different SunSystems databases. Multiple Reconciliation Manager profiles can be run simultaneously by
different users within the same business unit, as well as different business units. However, you cannot reconcile
the same transactional information within the same business unit, therefore you must ensure the reconciliation
profiles and reconciliation accounts do not contain the same information. Before you can run a reconciliation:
The following steps are required to perform a reconciliation:
1 Select Reconciliation Manager (RCM).
2 Enter the reconciliation requirements on the Reconciliations - Select form and click OK.
3 From theAction menu select Extract to extract the transactions and display them on the Reconciliations
form.
4 You can sort the transactions in either grid on the window, if required.
5 To perform an automatic reconciliation, from the Action menu select AutoReconcile. The Fully Rec box
is set automatically on any transactions in each set that meet the matching criteria.
If there are any duplicate transactions in either transaction grid, these are ignored by the reconciliation
process, unless the Consolidate Amounts option is set for the reconciliation profile. A message appears
if duplicates are found, and the Duplicate box is set to identify these transactions.
6 From theAction menu select Find to find a particular transaction.
7 To manually reconcile transactions, check or uncheck the Fully Rec check box to the left of a transaction
in each set of transactions, to reconcile or unreconcile the transaction.
When you check (or uncheck) the Fully Rec check box, the transaction is not immediately selected (or
deselected) for reconciliation. To ensure your selection takes effect, click on another transaction record
in either grid, and verify that the relevant total at the top of the form is adjusted correctly for your selection.
8 To reconcile part of a transaction, you can use the Allow Split option.
9 To generate a transaction, you can use the Generate and Generate Balance options.
10 To print the contents of the transaction grids, from the Action menu select Report.
11 From the Action menu select Post to save the reconciliation results.
If the reconciled transactions, that is the reconciliation totals displayed at the top of the form are the
same, the transactions are passed to Ledger Import for validation and posting.
If any validation warnings are identified, you are given the option to print the Ledger Import Validation
Report or to continue with the posting process. If any errors are identified, the Ledger Import Validation
Report is produced and the posting process is stopped.
If you selected the Hide action before manually or automatically reconciling the transactions, the
reconciled transactions are removed from the list automatically. You can select Show from the Action
menu to redisplay them.

Selecting Transactions for Reconciliation

Reconciliation Manager (RCM) is used to reconcile or match two sets of transactions. There are two stages
to the reconciliation process which use different, linked forms:
• The Reconciliations - Select form is used to enter the selection details and then extract the transactions
for reconciliation.
• The Reconciliations form lists the extracted transactions and is used to reconcile the transactions both
manually and automatically.
Note: Before you can use Reconciliation Manager to perform a reconciliation you must have defined the
transaction matching criteria using Reconciliation Profiles (RCP) and identified the source of each set of
transactions using Reconciliation Accounts (RCA). You must also have imported or loaded into SunSystems
the transactions to be reconciled, for example, using SunSystems Transfer Desk.
Reconciliations - Select (RCM)

Profile Code
The code that uniquely identifies the reconciliation profile as defined using Reconciliation Profiles (RCP).
Accounts
1st Business Unit
The business unit for which transactions will be displayed in the top grid of the reconciliation manager form.
1st Actual/Budget Marker

The letter representing the actuals ledger (A) or budget ledger (B to K) for which the transactions are to be
displayed in the top grid of the reconciliation manager form.
1st Account Code

The account code for which transactions will be displayed in the top grid of the reconciliation manager form.
If this code was not defined in Reconciliation Accounts (RCA) from the profile, you must enter the code
here.
2nd Business Unit

The business unit for which transactions will be displayed in the bottom grid of the reconciliation manager
form.
2nd Actual/Budget Marker

The letter representing the actuals ledger (A) or budget ledger (B to K) for which the transactions are to be
displayed in the bottom grid of the reconciliation manager form.
2nd Account Code

The account code for which transactions will be displayed in the bottom grid of the reconciliation form. If
this code was not defined in Reconciliation Accounts for the profile, you must enter the code here.
Currency Code
The transaction currency code for which transactions are extracted for reconciliation.
Note: This is not required if the Reconciliation Profile being used reconciles by Third Amount, as this is
defined in the business unit.

Transaction Date From/To

The range of dates for which transactions are to be extracted for reconciliation. For large volumes of data,
we recommend setting up a selection criteria for the Transaction Date range to assist performance during
the extract process.
Show Posted/Reconciled
Select this option to include transactions that have already been reconciled in the transaction grids. For
example, you might want to reset the reconciliation flag on selected transactions.
Note: You can use the Hide action to remove these transactions from the reconciliation manager grids, and
the Show action to redisplay them.
• Reconciliation Manager Extract Form

Select the form for which transactions are to be extracted for reconciliation. The following options are
available:
• Standard displays transaction details including Ledger Analysis and currency Values 1, 2, 3 and 4
• Simple displays transaction details including Ledger Analysis and currency Values 1, 2 and 3
• Extended displays transaction details including Ledger Analysis, currency Values 1, 2 and 3, General
Descriptions and Ledger Extension Data.
Analysis information will only be displayed for analysis which is not prohibited and General Descriptions will
only be displayed if they are setup for use.
Note: These forms are only available for reconciliations in the same business unit. When reconciling in
different business units, a variation of the standard form will automatically be used.
Selection
• Using these fields you can specify a value, or range of values, for each selection criteria to determine the
transactions selected for reconciliation. Transactions for the reconciliation accounts are only selected
if they match these selection criteria, and they fall within the overall transaction date range and other
criteria identified above.
Selection criteria only appear if they have been defined for the profile using Reconciliation Profiles
(RCP).
Note: If you are using a reconciliation profile in which Allocation Marker is one of the selection criteria, you
can use a '-' (hyphen) in the From/To fields to extract only the unallocated transactions.
Understanding the Reconciliations Transaction Lists

Transactions are extracted for reconciliation when you click Extract on the Reconciliations - Select form.
The chosen account transactions are listed on the Reconciliations form in the top and bottom grids. The
transactions displayed are determined by the reconciliation account definitions for the reconciliation profile.
The top of the form identifies the reconciliation accounts from which the transactions were extracted for the
two transaction grids. It displays the business unit, account code and account description of each reconciliation
account. Alongside this information it also displays the total of the transactions that have been reconciled
for each reconciliation account. The appropriate total is updated automatically when the Fully Rec flag is
set on a transaction to reconcile it.

These reconciliation totals are expressed in either the base or transaction currency, as determined by the
Use Transaction Amount field for the reconciliation profile.
Each transaction grid displays the following transaction details:
• Transaction Date
• Allocation Marker
• Amount in the Base Currency
• Transaction Currency Amount
• Credit/Debit Indicator
• Description
• Posted Date
• Ledger Analysis Codes 1-10.
Each grid also contains the following indicator fields for each transaction:
• Fully Rec - this indicates a reconciled transaction and can be set manually or automatically, and removed
manually.
• Duplicate - which indicates a duplicate transaction and is set by Auto-Reconcile.
Tailoring the Reconciliations Transaction Lists

You can tailor the list of transactions in each grid on the Reconciliations form by:
You can sort the transactions on the following fields: Transaction Date, Transaction Reference, Allocation
Marker, Base Amount, Transaction Amount, 4th Currency Amount, Debit/Credit, Description, and
Duplicate.
To sort the transactions in a list:
1 Click in the grid on the Reconciliation Manager window that contains the transactions you want to sort.
2 Click the heading of the column you want to use for the sort. If you want to sort on more than one column,
press Ctrl and click on the heading of the additional column.
If you sort on multiple columns, the sort sequence is defined by the order of the columns on the grid from
left to right.
3 Select Action > Sort Ascending.
If you repeat a sort, the transactions are sorted in descending order.
Hiding or Displaying Reconciled Transactions

You can choose to hide reconciled transactions from the transaction lists. For example, a large number of
transactions may have been extracted and automatically reconciled and you wish to view the unreconciled
transactions only.
To hide the reconciled transactions, select Action > Hide.

To redisplay previously hidden transactions,select Action > Show.

Note: These actions hide and show the transactions reconciled during your current reconciliation session,
and any previously reconciled transactions that were extracted if you set the Show Posted/Reconciled option.
Finding Transactions in Reconciliation Manager

Reconciliation Manager includes a Find facility that enables you to search for transactions that contain a
particular field value, in one of the Reconciliation Manager sections.
You choose the find field and enter the value to be found. The Reconciliation Manager sorts the transactions
according to this field and positions the selection arrow on the first transaction that contains the value, or
on the transaction that contains the closest match to the value. If no match can be found, transactions are
sorted at the next highest transaction, and the following message is displayed: Unable to find exact match,
re-positioning at start of transactions in requested order.
1 Click on the transaction grid in the Reconciliation Manager window that contains the transactions you
want to search.
2 Select Action > Find to display the Data Dictionary Lookup dialog.
3 Click on the data item you want to use to find the transactions and click OK. For example, to search for
a particular reference, click Transaction Reference. The Reconciliations Find dialog appears and the
chosen data item is identified alongside the Enter Value for prompt.
4 Enter the search value in theEnter Value for field.
5 Click OK to find the matching transactions. The Reconciliation Manager window reappears. The first
transaction that matches the find value appears as the first line of the grid and is identified as the current
transaction by the arrow to the left of the transaction.
Generating Transactions in Reconciliation Manager

Reconciliation Manager allows you to enter and post journal transactions as part of the reconciliation
processing. It provides two very similar commands for this: Generate and Generate Balance. In each case,
the Reconciliation - Generate form is displayed where you can enter the details of the offset transaction to
balance the generated transaction. For example, you can specify the account to which the offset transaction
is posted.
Use Generate to enter a new transaction based on the details of an existing transaction. For example, in a
supplier account, you may need to generate a transaction to register the postage and packaging amount not
originally included in an invoice transaction. The offset account for the generated transaction could be the
postage and packaging expense account.
The generated transaction can be the same sign as the source transaction, or it can be the opposite sign,
depending on the reconciliation profile you use. To determine the sign of the generated transaction, you
must configure the Same Sign Matching flag in Reconciliation Profiles (RCP), as follows:
• If set to Yes, when you select Generate for a transaction in the source window, the system creates a
transaction in the other window with the same sign as the source transaction.

• If set to No or Not Applicable and you select Generate, a transaction is generated with the opposite sign.
Use Generate Balance to post a transaction for the amount required to balance the reconciliation. For
example, if a payment amount in base currency does not balance exactly with the corresponding invoice due
to exchange rate differences, Generate Balance automatically sets the journal amount required to balance
the reconciliation in the base currency. The offset account for the generated balance in this example could
be the exchange gains and losses account.
1 Select Action > Generate or Action > Generate Balance to display the Reconciliation - Generate form
for journal entry.
2 Enter the journal details as required.
3 Click OK.
The journal amount is added to the reconciliation totals that appear at the top of the Reconciliation
Manager window.
Reconciliation Manager Generate

Journal Type
The type of journal or ledger transaction you wish to enter as defined in Journal Types (JNT).
A reference to the accounting or business transaction, normally from the originating document. For
example, the invoice number. You cannot leave this blank.
Transaction Date
The date that applies to this transaction. This defaults to the current date. You can enter another date
if required. You can only post to dates that fall within the open date range specified in Ledger Setup
(LES).'
Accounting Period
The default accounting period is the current period unless preset otherwise. You can only post to periods
that fall within the open period range specified in Ledger Setup (LES).
Account Code
A valid account code, created using Chart of Accounts (COA), to which the balancing reconciliation
amount is posted. You cannot select a closed account. If you select a suspended account a warning
appears but you can continue and post to the account.
Description
A description of the business transaction.
Ledger Analysis 1 to 10
Up to ten ledger analysis codes can be entered on a ledger transaction. Analysis codes can only be
entered for analysis dimensions that have been assigned to the ledger transactions entity. The analysis
codes required, and whether they are mandatory or optional, depends on the journal type and the
account referenced on the journal transaction. The codes may be preset using journal presets.

General Description 1 to 20
You can enter up to twenty additional descriptions to be applied to each transaction line generated.
Splitting Transactions in Reconciliation Manager

You can use Reconciliation Manager to reconcile only part of a selected transaction by manually splitting
the transaction in two. You cannot split the amount of a reconciled transaction.
The Allow Split option must be set for the Reconciliation Account before you can manually split transactions
on the account.
When you have split a transaction, the new transaction appears immediately above the original transaction
in the transaction list. It contains the same allocation marker and other transaction details, and the transaction
amount is the amount entered in the Transaction Base Amount field. The original transaction contains the
remaining transaction value.
Note: In some cases Auto-Reconcile splits transactions automatically in order to balance the matching.
1 Select the transaction you wish to split.
2 Select Action > Split to display the Split Transaction dialog.
3 Enter the amount to be reconciled and a description.
4 Click OK.
Posting Exchange Differences from Reconciliation Manager

If the Generate Difference option is set for a Reconciliation Profile, Reconciliation Manager will generate
and post realized exchange gain or loss transactions, where necessary. For example, if the transaction currency
values match on the reconciled transactions but the base currency values do not match.
The balancing currency is chosen in the Amount to be Used field on the Reconciliation Profile. For example,
if Use Transaction Currency is chosen here the transaction currency amounts must balance and the system
will generate gain or loss transactions to balance the base currency amounts, if necessary.
Two exchange gain or loss transactions are posted. One is posted to the realized gain or loss account that is
nominated for the Reconciliation Account and the other is posted to the source transaction account.
Exchange Difference Transaction Analysis

The transaction analysis codes that are set on the exchange difference transactions are determined in different
ways depending on:
• how the transactions are reconciled - manually or automatically
• whether single or multiple debit and credit transactions are being matched.

Manual Reconciliation
If you are using Reconciliation Manager to manually match single debit and credit transactions on a single
account and an exchange difference posting is required, the analysis codes for both of the exchange difference
transactions are taken from the transaction in the matched pair that has the lowest amount in base value.
If you are using Reconciliation Manager to manually match multiple debits and credits on a single account,
the Manual Ledger Alloc - Analysis Codes form is displayed. This allows you to enter the analysis codes
required for the exchange difference transactions posting to the source account and exchange gain/loss
account. The analysis codes available for input on this form are determined by Chart of Accounts (COA) and
Ledger Setup (LES).
Automatic Reconciliation
If you are using the Auto-Reconcile facility, Reconciliation Manager must be able to automatically determine
the analysis codes that should be used on any exchange difference transactions required.
The system derives a set of default analysis codes from the reconciled transactions. These default codes are
derived in different ways depending on how many transactions are being reconciled and the Consolidate
Amounts setting for the Reconciliation Profile, as follows:
• If you are using Reconciliation Manager to automatically match single debit and credit transactions on
a single account and the Consolidate Amounts flag is not selected on the Reconciliation Profile, the
default analysis codes for both of the exchange difference transactions are taken from the transaction
in the matched pair that has the lowest amount in base value.
• If you are using Reconciliation Manager to match multiple debits and credits on a single account and
the Consolidate Amounts flag is not set, you are prompted to enter the analysis on the gain/loss and
source accounts.
• If you are using Reconciliation Manager to automatically match multiple debits and credits on a single
account and the Consolidate Amounts flag is set, the reconciled debit and credit transactions are
consolidated. The default analysis codes are taken from the group of debit or credit transactions with
the lowest consolidated value. The default analysis codes are copied from the transaction in this group
that contains the largest value.
Once it has determined the default analysis codes it applies any analysis code overrides that have been
defined on the Reconciliation Profile. You can override the default codes separately for the two exchange
difference postings, to the source account and to the gain or loss account.
Note: You can only define these analysis code overrides if the Exchange Difference per match option is set
on the profile. If the Exchange Differences per match option is not set, all gains and losses are consolidated
and the balance posted to the gain/loss and source accounts.
Reporting on Reconciled Transactions

The Reconciliation Manager report shows the results of the reconciliation process. It is produced in two
circumstances:
• If you request it from Reconciliation Manager (RCM) by selecting Action > Report.
• When the results of a reconciliation are posted successfully by Ledger Import.

The Reconciliation Manager report begins by identifying the source of the transactions selected for
reconciliation. It identifies the Reconciliation Accounts from which the transactions were extracted for the
top and bottom transaction grids, referred to as Window 1 and Window 2. It also identifies the accounting
period and transaction date range that applied to the transaction selection.
The report then lists the transactions in window 1, the top grid, followed by all the transactions in window 2,
the bottom grid. You can choose to include all the transactions extracted for each window, or only those that
have been reconciled or unreconciled.
For each transaction it identifies the original Allocation Marker and the current Allocation Marker. It identifies
the transactions for which this marker has changed by printing an '*' asterisk in the Changed This Session
field.
Finally, the reconciliation processing is summarized at the bottom of the report.
How Does Auto-Reconcile Work?

The Auto-Reconcile option in Reconciliation Manager (RCM) is designed to recognize matching transactions
within two sets of transactions selected for reconciliation.
Note: The two sets of transactions to be considered for matching are displayed in the top and bottom sections
of the Reconciliation Manager window. The transactions may be drawn from the same account, or from
different accounts, as determined by Reconciliation Accounts (RCA).
Auto-Reconcile uses the match criteria you set in Reconciliation Profile (RCP) to determine how to recognize
matching transactions within each set. The matching can occur in one of three ways:
• matching on criteria other than amount.
• matching on amount and other criteria.
• consolidated matching on amount and other criteria.
Matching on Criteria Other than Amount

If the matching criteria set on the Reconciliation Profile, or determined in a rule set, does not include the
transaction amount as one of the matching criteria and the Consolidate Amounts option is not set, the
matching is based solely on the selected criteria. The amount of each transaction is ignored. As a result, this
method matches transactions in the following ways:
• one to one, that is, matching a single transaction in each set (Reconciliation Account).
• one to many, that is, matching a single transaction in one set to many transactions in the other set.
• many to many, that is, matching several transactions in one set to several transactions in the other set.
Using this method, the total of the reconciled transactions in each set are unlikely to balance, so manual
intervention may be required before the matching can be posted.
Matching on Amount and Other Criteria

If the matching criteria set on the Reconciliation Profile, or determined in a rule set, includes an amount field
as one of the matching criteria, the matching is carried out on a one to one basis only where the amount of
each transaction must match exactly before the two transactions can be reconciled.

The Consolidate Amounts option must not be set if you want to use this matching method.
A tolerance amount or percentage can be set on the Reconciliation Profile. This allows two transactions to
be reconciled if the two transaction amounts are within this tolerance. In this case, the larger of the transactions
is split into two transactions. One split transaction contains the exact amount required to match and is
reconciled automatically. The second split transaction, for the smaller amount, remains unreconciled on the
account.
Using this method only two transactions can ever be reconciled together, one in each set.
Note: Auto-Reconcile ignores duplicate transactions on a Reconciliation Account, except if the Consolidate
Amounts flag is set. This is because it cannot decide which of the duplicate transactions it should match.
Instead it indicates the duplicate transactions to allow you to manually reconcile them.
Consolidated Matching on Amount and Other Criteria

The auto reconcile consolidated matching method allows several transactions in each reconciliation set to
be matched together, providing they meet the matching criteria, and ensures the matching totals balance.
For example, it allows a single payment transaction on the Reconciliation Account, to be matched against
several invoices for smaller amounts.
The Consolidate Amounts option must be set if you want to use this matching method.
The matching criteria must include at least one matching field and must not include an amount field. This is
because the amount field is included automatically. The matching criteria is used to identify the set of
transactions available for matching in each section of the window. The values of these transactions in each
set are then consolidated and the total of each set is used to drive the automatic reconciliation process. The
smaller of these totals is the total amount that will be reconciled.
Auto-Reconcile processes the transactions in each set in order of transaction date, selecting the oldest
transaction first. It reconciles the transactions in each set until the smaller total set has been fully reconciled.
Any partially reconciled transaction in the larger value set is split to allow an exact reconciliation and the
remainder of the split transactions is left unreconciled.
This is best explained using an example:
Matching Criteria: Department (Ledger Analysis 1)
Before Auto-Reconciliation
Transaction Set 1 (Top section of window)
Table 8:
Transaction Processing
Details Details
Dept Tx Date Tx Value Dr/Cr Alloc Ind Considered Consolidat-
for Rec? ed Total
100 20/05/02 200.00 Debit Yes 200.00
100 25/05/02 150.00 Debit Yes 350.00

Details Details
100 26/05/02 100.00 Debit Yes 450.00
110 26/05/02 100.00 Debit No (wrong
dept)
Transaction Set 2 (Bottom section of window)
Table 9:
Details Details
Dept Tx Date Tx Value Dr/Cr Alloc Ind Considered Consolidat-
for Rec? ed Total
100 02/05/02 100.00 Credit Yes 100.00
100 06/05/02 50.00 Credit Yes 150.00
100 07/05/02 60.00 Credit Yes 210.00
100 10/05/02 80.00 Credit Yes 290.00
100 11/05/02 50.00 Credit Yes 340.00
110 14/05/02 40.00 Credit No (wrong
dept)
After Auto-Reconciliation
Transaction Set 1
Table 10:
Details Details
Dept Tx Date Tx Value Dr/Cr Alloc Ind Processing Consolidat-
ed Total
100 20/05/02 200.00 Debit R Fully Recon- 200.00
ciled
100 25/05/02 140.00 Debit R Original tx 340.00
split and rec-
onciled
100 25/05/02 10.00 Debit New split tx
- unrecon-
ciled

Details Details
100 26/05/02 100.00 Debit Not recon-
ciled
100 26/05/02 100.00 Debit Yes 340.00
Transaction Set 2
Table 11:
Details Details
Dept Tx Date Tx Value Dr/Cr Alloc Ind Processing Consolidat-
ed Total
100 02/05/02 100.00 Credit R Fully Recon- 100.00
ciled
ciled
ciled
ciled
ciled
110 14/05/02 40.00 Credit
Reconciliation Profiles
A reconciliation profile identifies a reconciliation or matching requirement for Reconciliation Manager (RCM).
For example, you might define reconciliation profiles for:
• your monthly bank reconciliations, reconciling a bank account to the corresponding bank statement
• large volume customers accounts, reconciling cash receipts against invoices and credit notes on the
account.
As well as identifying a requirement, the reconciliation profile identifies the match criteria that determines
how the two sets of transactions are to be reconciled by the Auto-Reconcile facility. If the transactions can
be matched by a simple field value comparison, the match criteria are defined in the reconciliation profile.
For example, the match criteria may be transaction reference and amount. Alternatively, if more complex
comparisons and conditions are required to match the transactions, the match criteria can be defined in a
rule set which is referenced on the reconciliation profile.

Reconciliation profiles are defined using Reconciliation Profiles (RCP).

Once you have defined a reconciliation profile, and its corresponding reconciliation accounts, you can run
the reconciliation process repeatedly for the profile using Reconciliation Manager (RCM).
Defining a New Reconciliation Profile

Two steps are required to define a new reconciliation profile:
1 Define the reconciliation profile code and enter the profile details.
2 Define the two reconciliation accounts required for the profile.
These two steps are carried out using separate SunSystems functions which are linked together as outlined
below:
1 Select Reconciliation Profiles (RCP).
2 Enter a new profile code and click OK to add this.
3 Enter the remaining profile details on the Reconciliation Profile form and click OK.
4 Click Accounts to display Reconciliation Accounts (RCA).
5 Enter the window number for the first reconciliation account details and click OK to add this.
6 Enter the first reconciliation account details and click OK.
7 Enter the window number for the second reconciliation account details and click OK to add this.
8 Enter the second reconciliation account details and click OK.
9 Click Exit in Reconciliation Accounts to return to Reconciliation Profiles.
10 You can then add or maintain another set of reconciliation profile details, or click Exit to leave the function.
Setting Up Reconciliation Profiles

Reconciliation Profiles Setup (RCP) is used to identify a reconciliation or matching requirement for the
Reconciliation Manager (RCM). For example, if you wish to use Reconciliation Manager to reconcile your bank
statements and also to match debtor receipts to invoices, you need to define separate reconciliation profiles
for each.
A reconciliation profile determines the transaction selection criteria and matching criteria for the reconciliation
process.
Note: Once you have defined a reconciliation profile, you should define the reconciliation accounts for the
profile. To do so, click Accounts to display the Reconciliation Accounts form.
Reconciliation Profiles Setup contains fields:
• Header Information
• General
• Selection
• Matching
• Source Acct Analysis Override

• Gain/Loss Acc Analysis O-ride.

1 Specify this information for Header Information:
Profile Code
The code that uniquely identifies a reconciliation profile.
Status
Each static data record contains a status code that determines the current processing status of the
record. A status is assigned to each static reference record, for example to every account, asset, customer
and supplier. It determines the current processing status of the record.
• Open - this status is set automatically when you add a new record, for example, if you create a new
account. Open items are available for input, inquiry, processing and reporting.
• Hidden - a record with a hidden status does not appear on any inquiries but is available for input,
processing and reporting.
• Suspended/Held - a suspended record.
• Closed/Completed - a closed record cannot be used for input or processing. For example, you cannot
post transactions to a closed account or analysis code.
You can alter the status of a record at any time. You must use the options on the Action menu to change
the status.
2 Specify this information for General:

Description
The full name or description of the data item or record. This is used to identify it on reports and inquiries.
Generate Difference
This determines whether or not exchange gain or loss differences are calculated and posted to the
exchange gain and loss accounts. The exchange gain or loss accounts are identified in the Reconciliation
Account details.
Note: Any gain or loss when reconciling by Third Amount is calculated in terms of Base Amount only
and differences in Transaction Amount currencies are ignored.
Allocation Indicator
The allocation indicator to assign to the reconciled transactions. You can assign any one of the following
allocation markers to the reconciled transactions: Allocated, Correction, Withheld, Forced, Reconciled,
Not Allocated, or any of the numeric markers 0 to 9.
For example, if the profile matches payment transactions against invoices on a debtor account, you
would assign the Allocated allocation marker. Whereas, if the profile matches bank account transactions
to the bank statement details, you would assign the Reconciled allocation marker.
Transactions marked as Allocated, Reconciled or Correction must balance before the details are posted.
Note: The Allocated and Correction markers can only be assigned if you are reconciling transactions on
the same account, with opposite signs.
Journal Type
The journal type to be assigned to any journal transactions generated when manually reconciling
transactions using this reconciliation profile. Journal types are defined using Journal Types (JNT).
Same Sign Matching

This determines how the sign of the transactions is used to determine whether or not transactions
reconcile.

Set this option to Yes to match transactions with the same sign. For example, if you use the reconciliation
profile to match bank account transactions to the bank statement transactions, you would use same
sign matching to match each bank account posting to its corresponding bank statement items.
Note: This is on the assumption that the sign of the bank statement transactions was reversed when
the transactions were loaded into SunSystems.
Set this option to No to match transactions with opposite signs. For example, to match payment and
invoice transactions on a debtor or creditor account.
Alternatively, set this option to Not Applicable if the sign of the transaction amount is irrelevant to the
matching process. For example, if the transaction amount is not one of the matching criteria.
Note: This can also be used to determine the sign of any transactions you generate with Reconciliation
Manager.
Match Percentage
The percentage tolerance allowed between matching transaction values. Transactions are matched if
the difference in the transaction amounts is within this percentage. If a percentage is entered, an amount
field must be selected as one of the matching criteria.
Note: If you enter both a match percentage and match amount, the difference in the two transaction
values is compared to the smaller of the Match Percentage or Match Amount values.
Match Amount
The tolerance amount allowed between matching transaction values. Transactions are matched if the
difference in the transaction amounts is equal to, or less than, this amount. If an amount is entered here,
an amount field must be selected as one of the Matching Criteria.
Note: The Match Percentage and Match Amount are ignored if the Consolidate Amounts options is
set.
Data Access Group Code
Amount To Be Used
This determines the currency in which the reconciliation totals are displayed at the top of the
Reconciliation Manager form. This is also the currency in which the reconciled values must balance
before they can be posted. Entries in this field update the match criteria, as detailed in the Matching
section below.
Reconciliation Manager can use any one of Values 1, 2, 3 or 4 as a basis for matching. Whichever Currency
Value is used for determining the match, Value 1 amounts are always balanced. Value 3 and Value 4
amounts are balanced according to the Cur Amount Balancing settings on the Value 3 and Value 4 tabs
of the Business Unit Setup. Resulting currency differences are generated according to the settings on
the Reconciliation Account records. Currency differences are never generated into Value 2, because it
is the transaction currency, and each transaction can hold a different currency in Value 2.
Note: The generation of balancing entries is only applicable to Allocations (transactions marked as
Allocated or Correction), and not to Reconciliations (marked as Reconciled).
Consolidate Amounts
This determines whether the Auto Reconcile feature consolidates the values of the matching transactions,
for example, to match several smaller value transactions against a single large value transaction. The
amount field is selected as one of the matching criteria automatically.
Note: If a Match Percentage or Match Amount is entered, or the Consolidate Amounts option is set,
the Auto Reconcile process may split a transaction in order to balance the matching transaction values.
This split processing is carried out regardless of the Allow Split flag setting on the reconciliation accounts.

Exchange Difference per Match

This determines whether or not exchange differences are calculated by Reconciliation Manager for each
match found within the matching criteria. If this option is set, the system calculates the exchange
differences for each set of matching transactions and copies the analysis from the transaction with the
lowest base value in the matched pair of transactions. Where duplicate transactions are found, they are
omitted from the matching process.
If this option is not set, the system consolidates all gains and losses and posts the balance to the gain/loss
and source accounts.
It is only possible to use this option if Generate Difference is also selected, and it can only be used when
matching credit transactions against debit (or vice versa) within the same account of the same business
unit. Therefore, to use Exchange Difference per Match, the Same Sign Matching option must not be
set, and the two Reconciliation Accounts must be configured for the same account code; one for credit,
the other for debit. Additionally, when this option is selected, exchange differences are only generated
when the Auto-Reconcile action is selected in Reconciliation Manager.
Leave Form Open

Set this option to leave the Reconciliation Manager form open when the reconciliation process has
been completed for this profile.
Report Options
The Report Option allows you to select whether a report is generated, and if so, what transactional
details are included in the report.
• No Report - Select this option if no report is to be generated
• Report Only Changed Transactions - Select this option to only include details of transactions that
have changed
• Report All Transactions - Select this option to include all transactions.
3 Specify this information for Selection:

Selection Criteria 1-10
You can choose up to ten selection criteria which transactions must meet before they are considered
for reconciliation.
A data item to be used as part of the selection criteria is selected from the Data Dictionary Lookup
dialog. This dialog lists the data items available and allows you to choose those you require.
4 The Matching tab is used to identify the data items that must match on the selected transactions for
them to be reconciled by the automatic reconciliation process, Auto-Reconcile. For example, you may
wish to match transactions on transaction reference, amount and ledger transaction analysis code 1.
When you choose to automatically reconcile, the system searches through the transactions extracted
for each reconciliation account, and identifies transactions that contain the same data in the matching
criteria fields. These transactions are matched and then reconciled.
Note: If you are matching by currency, then the currency code must have already been created in the
business unit in which Reconciliation Manager (RCM) is being run. This may be a different business unit
from those identified on the Reconciliation Accounts for which the reconciliation is being run.
5 The reconciliation profile matching option compares the contents of the same fields on each set of
transactions. If you need to match on different fields, or apply conditional or more complex matching,
then you should leave the matching criteria on Reconciliation Profiles Setup blank and define the matching
rules in a Rule Set.

For example, you may want to compare the transaction reference field value in one group of transactions
with the transaction description on the other set of transactions.
To define a matching rule set you must:
• set up an event profile that initiates the rule if Reconciliation Manager is being used with the
appropriate Reconciliation Profile. For example, the event profile may contain the following conditions
where BankUSD is the Reconciliation Profile:
If Function Code = Reconciliation Manager
If Reconciliation Profile = BankUSD
• define a rule set that contains the matching conditions and uses the special command of Match to
match the transactions if the conditions are met.
If the matching criteria in a rule set needs to be applied to multiple Reconciliation Profiles, you can
reference each Reconciliation Profile in the same event profile. For example the event profile might
contain the following conditions where Bank and BankUSD are the required reconciliation profiles:
If Function Code = Reconciliation Manager
IF Reconciliation Profile = Bank
OR Reconciliation Profile = BankUSD
Note: If the matching criteria are defined using a Rule Set, you cannot identify data items on the Matching
tab.
6 Source Acct Analysis Override only applies when the Exchange Difference per Match option is selected,
and only applies to Auto-Reconcile processing.
This tab is used to override the default transaction analysis codes that apply if exchange difference
transactions (per match) are generated for the Reconciliation Profile. The analysis code overrides defined
here apply to the exchange difference transactions that post to the source account.
The default analysis codes for the exchange difference source transaction are taken from the transaction
in the matched set that contains the lowest base currency value.
Note: The analysis codes that apply to the exchange difference transaction that posts to the gain/loss
account are defined on the Gain/Loss Acc Analysis O-ride tab.
Ledger Analysis 1-10
Select an analysis code, for an analysis dimension, to be used if a default analysis code is not provided
on the source transaction.
Alternatively, leave the analysis code blank to use the default code. The default code is taken from the
transaction in the matched set that contains the lowest currency value.
Enter '-' hyphen to remove any default code and leave the analysis code blank on the exchange difference
transactions.
Use if existing anl is blank

Check this option if the analysis code is only to be used when the analysis dimension is blank on the
source transaction.
7 Gain/Loss Acc Analysis Override only applies when the Exchange Difference per Match option is
selected, and only applies to the Auto-Reconcile processing.
This tab is used to override the default transaction analysis codes that apply if exchange difference
transactions (per match) are generated for the Reconciliation Profile. The analysis code overrides defined
here apply to the exchange difference transactions that post to the gain or loss account.

The default analysis codes for the exchange difference gain/loss transaction are taken from the transaction
in the matched set that contains the lowest base currency value.
Ledger Analysis 1-10
Select an analysis code, for an analysis dimension, to be used if a default analysis code is not provided
on the source transaction.
Alternatively, leave the analysis code blank to use the default code. The default code is taken from the
transaction in the matched set that contains the lowest currency value.
Enter'-' hyphen to remove any default code and leave the analysis code blank on the exchange difference
transactions.
Use if existing anl is blank

Check this option if the analysis code is only to be used when the analysis dimension is blank on the
source transaction.
Reconciliation Accounts
A reconciliation account identifies the account and ledger from which transactions are to be extracted for
reconciliation or matching by the Reconciliation Manager (RCM).
Reconciliation accounts are defined using Reconciliation Accounts (RCA).
Reconciliation Manager reconciles two sets of transactions which appear in the top and bottom sections of
the Reconciliation Manager window. A reconciliation account determines the source of a set of transactions.
This means that two reconciliation accounts must be defined for a reconciliation profile: one identifying the
source of the top set of transactions; and the other identifying the source of the bottom set of transactions.
The transactions in each set are extracted from a particular account and ledger. You can extract transactions
into the top and bottom sets from any of the following, depending on your requirements:
• the same account, ledger and business unit
• the same account but from different ledgers and/or business units
• different accounts, ledgers and business units
For example:
1 To reconcile the postings on a particular debtor account the reconciliation accounts for the profile would
both extract transactions from the same debtor account and ledger. For one group of transactions you
would extract credit transactions and for the other, debit transactions.
2 To reconcile the bank statement details against the bank account postings in the ledger, you might load
the bank statement transactions into a budget ledger for the bank account. You would then define two
reconciliation accounts both extracting transactions from the bank account, but one extracting the bank
account transactions from the actuals ledger and the other extracting the bank statement transactions
from the budget ledger.
Note: In order to import a bank statement for reconciliation purposes, use Transfer Desk (TRD) to define
the bank statement file layout using Format Designer, and map it to the Ledger data using Transformation

Designer. You must then create an import profile in Import Profile Designer, using this transformation
record, and run the import profile to import the data.
Note: Bank statements must be imported to a ledger other than Actuals.
The source account does not need to be stored permanently in the reconciliation account details. Instead it
can be entered at run time. This enables you to use the same reconciliation profile and reconciliation accounts
to reconcile different bank accounts or debtor accounts, depending on the requirements.
Setting up Reconciliation Accounts

You must define a reconciliation profile before you can define the reconciliation accounts. As a result, you
can access Reconciliation Accounts by clicking Accounts on the Reconciliation Profiles (RCP) form.
Reconciliation Accounts (RCA) is used to identify a set of transactions to be reconciled using Reconciliation
Manager (RCM). Reconciliation Manager reconciles two sets of transactions so you must define two
reconciliation accounts for a reconciliation profile.
For example, if the reconciliation profile is to be used to reconcile bank account transactions against the bank
statement, two reconciliation accounts would be required as follows:
• one to retrieve the transactions posted to the bank account
• another to retrieve the bank statement transactions which must have been loaded into SunSystems.
The bank statement transactions are typically posted to a budget ledger as budget transactions to the bank
account.
The two sets of transactions are displayed in the top and bottom sections of the Reconciliation Manager
window. For each reconciliation account, you determine whether the transactions are to appear in the top
or bottom part of the window.
1 In SunSystems, select Reconciliation Accounts (RCA).
Profile Code
The code that uniquely identifies the reconciliation profile as defined using Reconciliation Profiles
(RCP).
Status
The status assigned to the static data record.
Window Number
The section of the Reconciliation Manager form in which transactions will be displayed. The top part
of the form is identified as window number 1 and the bottom section as window number 2.
Description
Business Unit Code

The business unit for the transactions. This is useful for inter-company reconciliation. For example, if
you wish to reconcile the postings to inter-company trading accounts in different business units. It might

also be used if the bank statement details are imported into a different business unit. If you use multiple
databases, it is possible to specify business units from different databases for windows 1 and 2.
Actual Budget Marker

The ledger from which the account transactions are extracted. The actuals ledger is identified as A and
the budget ledgers are identified by B to K. For example, the bank statement details might be posted as
budgets to the bank account in a budget ledger
Account Code
The account code for which the transactions are extracted. You can leave this blank to select the account
at run time. For example, to select the debtor account you wish to match, or the bank account you wish
to reconcile.
Loss Account Code

The account to which exchange losses, or net gains and losses, are to be posted. This is only required if
the Generate Difference option is set in the reconciliation profile. If the Use Transaction Amount option
is set in the reconciliation profile, the transaction currency amount is used as the matching amount and
the system will generate gain or loss transactions to balance the base currency amounts, if necessary.
If the Exchange Gain/Loss Post Rule is set to Losses only, Net Gains and Losses, or Separate Gains
and Losses, any loss or net exchange difference is posted to this account.
Gain Account Code

The account to which exchange gains are to be posted. This is only required if the Generate Difference
option is set in the reconciliation profile. If the Use Transaction Amount option is set in the reconciliation
profile, the transaction currency amount is used as the matching amount and the system will generate
gain or loss transactions to balance the base currency amounts, if necessary.
If the Exchange Gain/Loss Post Rule is set to Gains only, or Separate Gains and Losses, any gains are
posted to this account.
Allow Generate
This determines whether or not journal transactions can be generated as part of the reconciliation
process. For example, whether exchange gain or loss postings are to be generated automatically.
Allow Split
This determines whether or not a transaction can be split. You may wish to split a transaction to allocate
only part of the transaction value. See 'Splitting Transactions in Reconciliation Manager'.
Debit or Credit
This can be used to restrict the transactions selected to either debit or credit transactions only, or both.
For example, if you are matching transactions for a debtor account you might wish to display the debit
transactions in the top window and the credit transactions in the bottom window.

Withholding tax
Chapter 15: Withholding tax
SunSystems Withholding Tax calculates and posts withholding tax on selected accounting transactions
according to user-defined tax rules and thresholds.
Withholding Tax calculates the tax to withhold and generates the journal transactions required to post these
values. Once the tax transactions have been posted the payments can be produced. If the withholding tax
transactions are posted back to the source account, these transactions will have adjusted the amount due
for payment or collection on the account either at invoice posting point or at payment posting point
automatically.
What is Withholding Tax?

A withholding tax is an amount of tax that is withheld from payments to suppliers, and paid directly to
government at regular intervals.
Withholding tax rate structures and calculations can be complex and may vary for different types of activity
or area. For example, different tax rates and thresholds may apply to each tax type and within each tax type
to different services, goods, interest payments etc.
In addition:
• the percentage of tax that must be withheld from the payments to a supplier may vary according to the
taxable value of the invoices being paid.
• the tax rate may vary according to the cumulative taxable payments made to the supplier throughout
the tax period.
• a fixed amount of tax may be required at each threshold, in addition to the variable percentage.
• an initial non-taxable amount may be allowed each period on which tax is not calculated.
• a minimum amount of tax may need to be withheld and if the calculated tax value is less no tax is withheld.
• the withholding tax may need to be calculated on the gross, net or tax values of the payments being
made (or received).

Withholding tax
Overview of Calculating and Recording Withholding Tax

The Withholding Tax function calculates the amount of tax to be withheld from selected transactions for
one or more accounts, and generates the journal transactions required to record the tax values. If the
withholding tax is being calculated on the total payments made during the tax period, it also maintains the
cumulative payment totals for the period.
It is designed to cater for different withholding tax requirements and as a result is very flexible.
Using Withholding Tax involves the following tasks:
1 Create a time frame. If withholding tax is to be calculated on the cumulative total of many transactions
over a certain period of time, you must first identify the range of dates by setting up the time frame.
2 Set up the Withholding Tax types. You must identify the different types of withholding tax required.
3 Define the Withholding Tax calculation rules. You must identify the tax calculation rules.
4 Define the groups of taxable accounts. You must assign the taxable nominal ledger accounts to the
appropriate tax account classes.
5 Define the Withholding Tax exemptions. If a supplier or customer is granted full or partial exemption or
discount from withholding tax.
6 Allow Withholding Tax on specific journal types. If you are using Argentina Withholding Tax you must
select Include Into Withholding Tax in Journal Types (JNT).
7 If you would like the numerical allocation marker to be updated on the Withholding Tax transaction
source account you can set the Withholding Tax Allocation Mkr in Ledger Setup (LES).
8 Calculate the tax. The calculation process uses the withholding tax rules to determine the type of tax
that applies to the account transactions. The net and off-set postings are considered for each gross
transaction.
9 Generate the Withholding Tax journal transactions. Once you have verified the tax values, you can generate
the journal transactions required to post the withholding tax to the ledger.
10 Post the Withholding Tax transactions. The journal transactions are automatically posted to the actuals
ledger. The tax amount is posted to the tax account identified for the withholding tax type, and the offset
is posted to either the source account of the transactions, or the alternative source account if one is
identified on the tax type.
What are the Withholding Tax Cumulative Totals?

Withholding tax may need to be calculated on the cumulative payments that are made to a supplier, or it may
need to be calculated on collection from a customer during the tax period (time frame). This is because the
tax rate may change according to the cumulative taxable amount.
The withholding tax cumulative totals are set up on Withholding Tax Types (WTT) in theCalculation type
field.
If the Calculation type field is set to Cumulative, Withholding Tax automatically stores the transaction
amounts it needs in order to to calculate the cumulative taxable value each time withholding tax is calculated.
The tax periods, for which the cumulative values are calculated, are defined using Time Frames (WTF). They
do not need to correspond to the accounting periods.

Withholding tax
Where is the Withholding Tax Rate Defined?

The Tax Rate by Transaction Value
Sometimes the amount of tax to be withheld from the transactions on an account depends on the value of
the taxable transactions for the account. The rate of tax can vary according to:
• the value of the selected taxable transactions alone, or the accumulated total of all the taxable transactions
for the account for the tax period.
• other transaction criteria, for example account code, analysis codes, product codes, transaction references
and so on.
• the transaction dates.
For example:
• the withheld tax rate on interest payments might be 1.5% in the Southern province and 1.75% in the
Northern province and the province is identified by an analysis code on each transaction.
• the tax rate begins at 0.5% for cumulative purchases below 5000, rises to 1% on total purchases between
5000 and 10000, and then rises to 1.5% on all subsequent purchases for the period from the same supplier.
The transaction level tax rules for a withholding tax code are maintained as withholding tax calculation rules.
A calculation rule identifies:
• the range of dates for which the tax rules apply, for example, different rates may be set each year.
• a set of up to five key constraint selection criteria that control the transactions on which the tax is
calculated, for example where different rates of tax apply by product group, area or supplier type.
• the tax percentage to apply, or a table of value ranges, tax amounts and rates that determine the amount
and/or rate of tax to be withheld for each range.
Note: The Calculation Type setting for the withholding tax type determines whether the withholding tax is
calculated on cumulative taxable values for the tax time frame, or only on the taxable transactions selected
for the run. If the tax is calculated on cumulative values, a table of value ranges is required to define the tax
percentages.
A Tax Exemption for an Account

Sometimes an account might be granted a withholding tax exemption or discount. For example, some countries
offer very large organizations a discount on the withheld tax.
This rate is defined for the account on Withholding Tax Exemption (WTE). The exemption or discount percent
is entered in the Exemption Rate field. The withholding tax is calculated for the account using the standard
tax rates, and then this percentage is deducted to determine the final tax amount.
Setting up the Withholding Tax reference data

Withholding Tax reference data includes:
• Withholding Tax Types
• Calculation rules

Withholding tax
• Cumulative Tax Time Frames

• Tax exemptions
•
Withholding Tax Types

A withholding tax type is required for each type of withholding tax to be calculated. For example, these
withholding tax types might be defined:
• Withheld corporation income tax
• Withheld gross revenue tax
• Withheld value added tax.
Note: You do not need to define separate withholding tax types if different rates apply to groups of accounts
or transactions. The tax rate tables are defined as calculation rules for a withholding tax type.
When you have defined a withholding tax type, you must define the calculation rules to identify which
withholding tax percentages to apply.
Withholding Tax Types (WTT)

Select Withholding Tax Types (WTT).
Withholding Tax Types (WTT) - Basic Details

1 Open Withholding Tax Types (WTT).
Withholding Tax Type
The code identifying the type of withholding tax. You must create a separate code for each different type
of withholding tax you want to calculate. For example, you may require one type to calculate withheld
corporation tax, and another to calculate withheld gross revenue tax.
Tax account code

The account code in the nominal ledger to which the calculated withholding tax is posted.
Note: You must create a separate withholding tax code for each different tax account you require.
Description
A description of the withholding tax. For example, Withheld Corporation Tax.
Calculation Details

Withholding tax
Withhold Point
This flag indicates whether the payment should be withheld at invoice or payment posting time.
Calculation Type
This determines how the withholding tax is calculated on the selected taxable transactions.
Options are:
• Non cumulative individual
calculates the withholding tax on each individual taxable transaction.

• Cumulative
calculates the tax on the cumulative total of all the taxable transactions selected for the tax time
frame. In this case, cumulative taxable totals are maintained for each withholding tax time frame
and are used in each successive calculation. If the cumulative source transaction amount is less
than the Minimum Non-Taxable Base amount or the final tax amount is less than the Minimum to
Withhold, then no transaction is generated.
• Non cumulative total
calculates the tax on the total of the taxable transactions selected.

• Invoice Cumulative (Argentina)
calculates the tax by the sum of transactions over the 12 months prior to payment.
Note: For Invoice Cumulative (Argentina) calculation type, if the sum reaches the minimum amount,
two withholdings are determined, income tax and VAT.
Cumulative Time Frame

The time frame code that determines the tax period for which the cumulative values are calculated. This
is required if the Calculation Type is set to Cumulative. For example, the withholding tax may be calculated
and paid monthly, or fortnightly.
Note: This code must have been previously defined using Time Frames (WTF).
The accumulated values are reset automatically at the end of each time frame.
Account Tax Class

The basis for the withholding tax calculations identifies the type of transaction the withholding tax is
calculated on. The valid values are:
• Gross
to calculate the tax on the gross amount of transactions

• Net
to calculate the tax on the net amount of transactions

• Tax
to calculate the tax on the tax amount of transactions.
Apply by Default
This check box controls how the supplier or customer accounts for which the tax should be calculated
are determined. It allows you to calculate withholding tax even if no tax adjustment is applied. If Apply
by Default is not selected withholding tax will only be calculated if there is a tax adjustment.

Withholding tax
Uncheck this check box, to leave blank, if this type of withholding tax should only be calculated on the
source accounts that reference this withholding code specifically.
Note: This check box is checked by default.
Receivables or Payables
This option indicates whether the Withholding Tax Typeapplies to the receivable transactions generated
via Payment Collection Run (PYC) or payable transactions generated via Payment Run (PYR). This
option is only available if the Withhold Point is Payment Posting.
Generated Transaction Details

Journal Type
The journal type to be used for the withholding tax transactions generated.
Transaction Reference Format

Select the transaction reference format required to determine the format of the reference number and
how it is generated.
Same Sign as Source Account

Check this check box if the withholding tax transaction generated for each source account should use
the same debit/credit indicator as the source account transactions. Normally, transactions use the
opposite sign.
Source Account
An alternative to the transaction source account for the withholding tax offset posting. Leave this blank
to post the withholding tax amount back to the account referenced on the source transactions, and
thereby adjust the account's balance.
Selection Criteria
Selection Criteria
Choose the relevant selection criteria options if required. The options are:
• Not Applicable
• Account Code
• Conversion Code
• Journal Source
• Journal Type
• Account Analysis 1-10

Withholding tax
• Ledger Analysis 1-10

• Supplier Analysis 1-10
Defining calculation rules

Calculation Rules is used to define the variable tax rates and transaction selection criteria, or key constraints,
for a withholding tax type.
Each calculation rule is identified by a unique code, for the withholding tax type. You must define at least one
calculation rule for each withholding tax type.
Withholding Tax Calculation Rules

Calculation Rules is used to enter and maintain the details for a particular withholding tax code.
The Calculation Type for the withholding tax code determines how the withholding tax rate is defined.
If the Calculation Type is Cumulative, which calculates tax on the cumulative taxable value for the tax time
frame, the tax rate can vary according to the cumulative taxable value. Therefore, you can enter a series of
taxable value ranges and an associated fixed amount and tax rate.
If the Calculation Type is Non cumulative individual, or Non cumulative total, which calculates the tax on
the total of the taxable transactions selected for the run, or on each individual taxable transaction, only a
single tax rate is used.
Calculation Rule Code
A code to uniquely identify the calculation rule within the withholding tax code. This might be a sequential
number or a reference code for the tax range.
Description
The description of the withholding tax calculation rule.
Start Date
The first date on which this set of withholding tax rules apply. The year must be entered as four digits.
End Date
The last date on which this set of withholding tax rules apply. The year must be entered as four digits.
Minimum to Withhold
The minimum amount of withholding tax that can be withheld. If the calculated withholding tax is less than
this value, no tax is withheld. For example, if the minimum value is 100 and the tax due is calculated as 40,
then no tax is withheld. If the tax is calculated on a cumulative basis, this minimum is applied to the total
tax calculated. Whereas, if the tax is calculated on a non-cumulative basis, this minimum is applied to the
tax calculated for each individual taxable transaction or set of taxable transactions.

Withholding tax
Minimum Non-Taxable Base

The amount that is not liable for withholding tax. If the withholding tax legislation specifies that the first tax
band, or base amount, is not taxable, you must specify that amount here. There are two ways in which the
non-taxable base is treated, depending on whether the withholding tax calculation type is cumulative or
non-cumulative.
If the withholding tax Calculation Type is non-cumulative, tax is calculated for a transaction or set of
transactions only if its total value exceeds the non-taxable base. For example, if the non-taxable base is 1000
and the taxable transaction value is 5000, then withholding tax is calculated on the 5000. Conversely for the
same non-taxable base of 1000, a transaction value of 800 means that withholding tax is not calculated.
If the Calculation Type is cumulative, the non-taxable base amount is deducted from the cumulative total
of transactions and withholding tax is calculated on the remainder. That is, withholding tax is calculated only
on the amount by which the cumulative total exceeds the non-taxable base. For example, if the non-taxable
base is 1000 and the cumulative total of taxable transactions is 5000, then withholding tax is calculated on
4000.
Minimum Unit Price
If the Calculation Type is Invoice Cumulative (Argentina), enter the required minimum unit price. The
default value of minimum unit price is 0.00 and is validated against the highest unit price during the
withholding tax calculation.
Percentage
The percentage of withholding tax to be calculated. If withholding tax is calculated on a non-cumulative
transaction basis, this percentage is calculated on the individual transaction value or on the total of the
selected taxable transactions. If withholding tax is calculated on a cumulative basis, this is the percentage
tax to apply when the cumulative taxable value falls within the associated range of values. This percentage
is only calculated on the amount of the total taxable value that falls within the current range.
Selection Value 1-5

The transaction value that must exist in the appropriate selection field on the transaction. These fields only
appear if the selection value fields are selected for the calculation rules. For example, if withholding tax only
applies to transactions with a journal type of XYZ, then Journal Type must be chosen as a selection value
field for the withholding tax calculation rules, and the value XYZ must be entered on the calculation rule.
Amending a Withholding Tax Calculation Rule

1 In Withholding Tax Types (WTT) choose the Withholding Tax Type and select Calculation Rules.
2 Select the calculation rule you want to modify and click Amend.
3 Amend the calculation rule details and selection criteria values as required.
4 Modify the selection criteria for the calculation rules, if required, and click Save.
5 When you have made the changes, click OK to save the calculation rule.
Note: If you modify the selection criteria fields, any existing calculation rules are removed and must be
redefined. This is because the calculation rule selection values may be incorrect. However, you can modify
the selection criteria values freely.

Withholding tax
Deleting a Withholding Tax Calculation Rule

1 In Withholding Tax Types (WTT) choose the Withholding Tax Type and select Calculation Rules.
2 Select the calculation rule you want to remove and click Delete.
3 You must confirm that you want to delete the rule.
What are Selection Criteria?

Different rates of withholding tax may apply to payments made or received for particular types of goods, or
service, or other types of transaction. In this case, you may need to apply different tax calculation rules to
selected groups of transactions for an account, and you need a method of identifying the groups of transactions.
Selection criteria are used to group the transactions on an account. You can define up to five selection criteria
to identify the analysis and group the taxable transactions.
A selection criteria identifies a field of information that exists on either the account or transactions which are
used to select and group the transactions. The fields you can use as selection criteria fields are predefined
within the Withholding Tax module and include the account analysis codes and transaction analysis codes.
The calculation rules that define the withholding tax rates can be entered against a valid combination of
selection criteria values. If you select more than one selection criteria for a calculation rule, a transaction
must meet all of these criteria for the tax to apply.
For Example
A type of corporation withholding tax might apply to payments to suppliers. Different rates of tax might apply
according to the type of class of service being purchased, as illustrated in the following table:
Class of Goods/Ser- Purchase Value Purchase Value Fixed Tax Percentage

vices From To Amount Tax
Professional Services 0 2000 - 10
2000 4000 200 14
4000 8000 480 18
8000 Onwards 1200 22
Rent 1200 Onwards 6
The class of rent or service is identified by a transaction analysis code called PG Class with a value of either
Rent or Service. Therefore, a selection criteria of PG Class could be identified for this withholding tax code
and calculation rules could be defined. One rule defining the professional services tax details for transactions
referencing the service, and the other defining the rent tax details for transactions referencing the rent.

Withholding tax
Adding and Maintaining the Cumulative Tax Time Frames

A time frame code identifies the period for which the taxable values are accumulated for withholding tax
purposes. This is required when the tax is being calculated on the cumulative taxable values for each account.
When you access Withholding Tax, you are prompted to enter a Payment Date. This date is used to determine
the withholding tax time frame for the calculations.
The time frame corresponds to the frequency when the withholding tax must be paid and depends on the
tax settlement period. For example, the time frame might be a calendar month or fortnight.
Time Frames (WTF)

1 Open Time Frames (WTF).
2 Complete this information:
Time Frame Code
A unique code identifying the period to be used when calculating cumulative taxable amounts for the
source accounts.
Description
Short Heading
The short heading, which is used where space is limited. If this is blank it defaults to the first characters
of the description.
Lookup Code
A lookup code can be used to find a record, as an alternative to the record code. It is often set to a
shortened version of the description. It is particularly useful if a record is often referred to using different
codes. For example, the Chart of Accounts code for Fuel Expenses is 75201 and the Lookup Code is set
to FUELEXP.
3 Click Time Frames Details to add a From and To date.

From
The first date for which transactions are included in the time frame, based on the transaction date.
To
The last date for which transactions are included in the time frame, based on the transaction date.
Defining Withholding Tax Exemptions

Sometimes a supplier or customer is granted a full or partial exemption, or discount, from withholding tax.
This may be a temporary or permanent exemption. This information is defined using Withholding Tax
Exemptions (WTE).

Withholding tax
The exemption percentage rate is entered for the account, and applies to a particular period of time. This
enables you to record temporary exemptions that only apply until a specified date.
The withholding tax is calculated in the normal way for the account, and then at the end of the processing
the exemption percentage is deducted to calculate the actual amount of tax due.
Withholding Tax Exemptions (WTE)

The Exemption Setup form contains the following:
Exemption Code
A unique code to identify the Exemption Setup record. You can enter a maximum of 15 characters
Withholding Tax Type

The withholding tax type for the account. This code is defined using Withholding Tax Types (WTT).
Account Code
The nominal ledger account code that requires a specific withholding tax rate.
Description
A description for the Withholding Tax Exemption code.
Exemption Rate
The percentage of the normal withholding tax amount that should be used to calculate the final withholding
tax for transactions posted to this account. The percentage can be between 0 and 100 and include up to two
decimal places.
Start Date
The first date on which the exemption percentage applies.
End Date
The last date on which the exemption percentage applies.
Note: If the same withholding tax type and account code are used, but a different exemption code is entered,
where the effective dates overlap a warning message is displayed, Overlapping date ranges are not permitted.
How is Withholding Tax Calculated?

Withholding tax is calculated when you post a transaction or a payment. It is calculated on the group of
transactions that are selected for processing providing they are eligible for withholding tax according to the
rules defined for each type of tax. These are referred to as the source transactions.
The withholding tax rules identify the taxable accounts and transactions, and the rates of withholding tax
that apply.
The withholding tax calculation process performs these steps:
1 The source transactions are grouped by account and date, and by which, if any, types of withholding tax
should be calculated for each account.

Withholding tax
2 If the tax is being calculated on a non-cumulative basis it is calculated either for each individual transaction
or on the total of the transactions for the account. Whereas, if the tax is being calculated on a cumulative
basis it is calculated on the total taxable value for the tax time frame. If the tax is being calculated on an
Invoice Cumulative (Argentina) basis it is calculated by the sum of transactions over the 12 months prior
to payment, including any unpaid transactions.
Note: An audit log identifies all of the choices made by the tax calculator on each account, and on each
transaction within each account.
Retrieving the Offset Transactions

Withholding tax can be calculated on the gross, net, or tax values of a business transaction. This is determined
by the Withholding Basis set in the Withholding Tax Type (WTT).
The gross, net, and tax values are posted to the ledger on separate posting transactions, to separate accounts.
This means that different transactions may be required to calculate different types of tax.
Checking the Withholding Tax Calculations

As withholding tax is calculated, an audit log is produced that documents the transaction selection and tax
calculation processes. You can view this audit log in the SunSystems cobol log folder.
The audit log identifies each of the decisions the tax calculator has taken to determine whether each account,
and the selected transactions, are eligible for tax. The tax amounts calculated are also displayed.
What Transactions are Generated for Withholding Tax?

Withholding Tax generates the transactions required to post the results of the withholding tax calculations.
It generates a journal that posts the withholding tax value for each source account.
The Withholding Tax Journal

The withholding tax amount is posted in the actuals ledger to the Tax Account identified on the Withholding
Tax Types (WTT). The offset amount is posted to the source account of the transaction from which the tax
value was calculated, or to the alternative Source Account if one is identified on the Withholding Tax Type.
The Journal Type is also identified on the Withholding Tax Type.
The transaction reference for the withholding tax posting is determined by the Transaction Reference Format
on the Withholding Tax Type.
The journal description is taken from the Withholding Tax Type description. The journal source is WHTAX. The
posting period is the current period as defined in Ledger Setup (LES) and the due date is the same as the
source journal's source account code transaction date. The transaction date is the payment date you enter
when you run Withholding Tax (WHT). If you are using calculate withholding tax at payment posting point,
the transaction date is the payment date you entered in Payment Run (PYR). If you are using calculate

Withholding tax
withholding tax at invoice posting point, the transaction date is the last source taxable line's transaction date
and the allocation marker is set from Withholding Tax Allocation Mkr in Ledger Setup (LES).
Which Analysis Dimensions are Required in the Generated Journal?

Analysis codes are automatically generated in the withholding tax journal, following the conventional ledger
analysis rules that you set for the account and the journal type. As such, the inclusion or exclusion of specific
analysis dimensions on the journal depends on the following factors:
• the posting account. Analysis dimensions must be defined as either Mandatory or Optional in the
Transaction Analysis tab on the Chart of Accounts (COA) record for an account, in order to be entered
by the withholding tax journal. If a particular dimension is defined as Mandatory in the account record,
then a code must be entered, regardless of the journal type. If it is defined as Optional, then the journal
type indicates whether or not a code is required for that dimension. If it is defined as Prohibited, then
that analysis dimension is left blank on the generated journal.
• the journal type. As described above, if an analysis dimension is defined as Optional in the account record,
and you require that dimension in the withholding tax generated transaction, then it must be enabled
in Journal Type (JNT) on the Analysis tab, for the journal type used to post the generated transaction.
What Analysis Codes are Entered in the Generated Journal?

For each analysis dimension that is required by the account and journal type combination, the specific analysis
code entered on the generated journal depends on the source transaction or transactions. As a general rule,
the required analysis codes are copied from the source transaction onto the withholding tax generated
transaction. However, in practice there are normally many source transactions for each generated transaction,
and so the analysis codes are only copied from one of those source transactions. They are copied from the
transaction with the highest base amount (regardless of credit / debit), and if more than one source transaction
has that same amount, then the first of those transactions is used, as displayed in the Withholding Tax dialog.
Posting the Journal

The withholding tax journals are posted to the actuals ledger when you post an invoice or a payment.
Voiding Withholding Tax Transactions

There may be times when incorrect withholding tax transactions are generated, for example if you select the
wrong source transactions or the tax rate is incorrect.
If you notice the error after you have posted the journal files you must reverse these journals in Journal
Reversal and Copy (JRC).
Source transactions and withholding tax transactions must be reversed separately if the journal types are
different.
All withholding tax transactions are hard posted, even if the source transactions are provisionally posted.
If you are using invoice posting point, if the provisional transactions are posted again, the previous withholding
tax transactions could be automatically reversed and new withholding tax may be recalculated. However, if

Withholding tax
you are using the cumulative calculation type and the cumulative amount is less, then the non-taxable amount
is not reversed.
If you are using payment posting point, withholding tax is not recalculated if the relating withholding tax
transactions already exist.
Note: Only generated withholding tax transaction lines are reversed. For cumulative type, if the base amount
is less than the Minimum Non-Taxable Base amount, the cumulative amount in the cumulative table is not
reversed.

Sunsystems - 6.4.xSunSystems Financials

Uploaded by

Copyright:

Available Formats

Sunsystems - 6.4.xSunSystems Financials

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sunsystems - 6.4.xSunSystems Financials

Uploaded by

Copyright:

Available Formats

SunSystems Financials

Chapter 1: Financials overview...................................................................................................12

Chapter 2: A Quick Guide to Allocating Transactions After Posting.................................................14

Chapter 3: Entering journals and transactions..............................................................................15

Deleting Provisional Transactions...............................................................................................................62

Applying Discounts in Transaction Matching............................................................................................116

Voiding a System Generated Payment......................................................................................................159

Intercompany Posting Workflow Example...................................................................................................189

Selecting a group of assets for disposal....................................................................................................250

Voiding Withholding Tax Transactions......................................................................................................290

Chapter 1: Financials overview

SunSystems Financials is an integrated accounting system.

Chapter 2: A Quick Guide to Allocating Transactions After

Chapter 3: Entering journals and transactions

Introducing Ledger Entry

Entering the correct codes

Journal totals and balances

Understanding the Ledger Entry forms

Ledger Entry Form Styles

Ledger Entry Form Functions

Journal Transaction Fields Available

The Ledger Entry Menu and Toolbar

Menu Com- Sub-Menu Command Tool- Use

Currency Totals - Fourth Displays the totals in fourth currency

Post Post Posts the journal, providing it satisfies the validation

Go To - Prev Displays the previous journal line

Go To - Next Displays the next journal line

Go To - Last Displays the last journal line

New Line Allows you to enter a new journal line

Amend Allows you to amend a selected journal line

Examine Allows you to view a selected journal line

Standard Text Allows you to enter standard text

New Jour- Allows you to select a different journal type for a

View Displays the entire journal

Online Allo- Allows you to allocate the journal transactions

The Ledger Entry Command Buttons

Command Button Toolbar But- Use

Hold Places the journal on hold

Selecting the Ledger Entry Form for a Journal Type

Entering and posting a journal

A Quick Guide to Entering a Journal

Entering the Journal Details

2 Specify this information for Standard Line Details:

Ledger Analysis Codes

3 Specify this information for Additional Line Details:

Document Date 1-4

Discount Date 1/Percentage

Discount Date 2/Percentage

Late Payment Date/Percentage

Transaction Currency Rate

Transaction Currency Amount

Base Currency Rate

Base Currency Amount

Second Base/Reporting Currency Rate

Second Base/Reporting Currency Amount

Fourth Currency Rate

Fourth Currency Amount

Asset Sub Code

11 Save your changes.