General Actions:
The structure of your accounting codes in PECOS P2P may not therefore need to exactly resemble those of your main financial and general ledger systems. The codes used however must be the same. This is to ensure that any data sent out from PECOS P2P through integration points matches that in your finance system(s).
The structure and content of accounting setup in PECOS P2P is described here.
This is the name given to the STRUCTURE of the account codes. Each Method may have different Segments and Values. You may create as many different Methods as are required to support your Organisation. Users may be granted permission to use any combination of values for all or some of your Methods.
This is the name or label of each account code TYPE. There must be at least one segment within each Method with a maximum of nine segments. Each segment can have a relationship with its neighbour and this relationship will determine how code combinations are built. Segments will appear in the order they are listed and this order cannot subsequently be changed.
Values are all the individual general ledger code numbers and descriptions. Values are input under each Segment. There must be at least one Value entered under each Segment.
Once created, Financial Tracking methods and their segments cannot be deleted because there may be historic data linked to them. It is possible to deactivate or change a segment value, but you cannot delete it. If you deactivate a segment value, it remains available to legacy data but not to new data.
A bulk load utility (the 'bulkaccountload') is available for the automated loading and updating of account code values.
The 'bulk account load' process addresses initial high-volume loads during implementation allowing you to take an extract from your financial system and bulk load the data directly into PECOS P2P. This speeds the initial set-up process and also avoids any typographical errors that can be the result of a manual data input process. The utility is also capable of managing ongoing data updates, minimising the need for Administrators to manage the account code update process.
The bulk load interface supports both flat file (csv) and XML file formats. Additional information on the bulk loading of account data is available in the Document ‘Bulk Account Load for PECOS P2P’
Although the bulk load utility is capable of creating Segments, where they do not exist, it is recommended that the Method and Segment structure is created prior to the bulk load.
Please refer to your Elcom consultant or the Elcom Service Desk for further details of the bulk account load service.
The principal of creating Parent / Child relationships within an accounting method allows for cross validation between account code values. This will ensure that different ranges of general ledger codes within one segment can only be used when a particular code is chosen within another.
For example if an organisation has two segments within a method: Region and Department; and certain department values can only be used within certain regions, a Parent / Child relationship can be created. The Region segment will become the Parent of the Department Segment. The Department segment will therefore become the Child of the Region segment.
This relationship is created when the Segments are created and will apply to ALL values that are subsequently entered.
Example
Using the scenario above, an organisation has a financial tracking method containing two segments: Region and Department.
The following validation is required: the department codes for Central Purchasing and Finance are only to be selected if the Eastern region is selected; the Marketing department can only be selected when the Northern region is selected and the Warehouse Operations department exists only in the Western region. All regions have a sales department.
The table below shows the configuration required.
Segment – Region | Segment – Department | |
100 - Eastern | 1020 – Central Purchasing | |
1050 – Finance Department | ||
1060 – Sales | ||
200 - Northern | 1030 – Marketing Department | |
1060 – Sales | ||
300 - Southern | 1060 – Sales | |
400 - Western | 1060 – Sales | |
1070 – Warehouse Operations |
Solution
Example
The following describes an example of how Methods may be created to accommodate the different accounting requirements for different divisions within an organisation.
Requirement: The I.T. division within your organisation may be centralised and only requires a range of account codes that includes a Cost Centre and Financial (Subjective) Code. The Transport Services division however may be geographically dispersed and requires additional account codes to identify Region and an optional Project Code.
Solution: Firstly, a Method called ‘Information Technology’ can be created that contains two Segments. The first segment will be called ‘Cost Centre’ and the second will be called ‘Financial Code’. All cost centre and financial code Values that are to be used within the I.T. division will be entered under the appropriate segments.
A second Method called ‘Transportation’ can be created that contains four Segments. These segments will be called ‘Region’, ‘Cost Centre’, ‘Financial Code’ and ‘Project’. All accounting Values to be used within the Transport Services division will be entered under the appropriate segments.
The Method called ‘Information Technology’ can now be assigned to all members of the I.T. division and the method called ‘Transportation’ can be assigned to all users who work within transport services. In this way PECOS P2P will ensure that your users are able to correctly and accurately code their requisitions with all the required financial information.
Although the example above describes the flexibility of Financial Tracking setup within the PECOS P2P, it is usually only necessary to create a single Method, against which all values are input. Validation of and access to accounting values can also be easily defined within Business Rule Groups.
PECOS P2P will automatically apply an account code combination to every line on a requisition for each user. The requisition accounting is determined by a number of default settings that may be in place. Some defaults are mandatory and others are optional and they will take precedence as follows:
The accounting permissions available to the requisitioner after the selection of a buy-for user, will be limited to the business rule group permissions of the buy-for user only. Access to the accounting permissions of the requisitioner will only become available once more if the Financial Tracking Responsibility is changed back to ‘Requisitioner’ in the Requisition Financial Tracking screen.
The over-riding of default accounting can be performed at any time before the submission of a requisition through the Requisition, Order or Line Item level financial tracking screens. The editing of account code defaults is limited by the user’s business rule group permissions.
Any accounting value that is ‘forced default’ from procurement card or commodity accounting is non-editable by the requisitioner.
It must be remembered that any accounting changes derived from manual changes or procurement card selections, performed prior to the selection of a buy-for user, will be lost upon the selection at requisition level of a buy-for user.
PECOS P2P supports the creation of Blanket Orders and Templates (recurring lists) with different Financial Tracking Code combinations in the Header and the line level. The Financial Tracking Codes are stored with Blanket Orders and Templates. These Financial Tracking codes will be propagated to the requisition created from the Template and the Blanket Release created from the Blanket Order if the requisitioner has the permissions to use those specific Financial Tracking Codes. If the user does not have the correct permissions, the user’s default Financial Tracking codes will be used.
Navigation
P2P Admin