Posting Code

When the term 'account type' is used, it is a posting code or a collection of like posting codes that is most often referred. When COA codes are added to a posting code, a specific account is defined. For example, the collection of different posting codes for cash - Regular Cash (A001), Intercepted Cash (D202), and Investment Cash (I001) fall into the Posting Code Closing Classification of Cash Roll Forward (5). A total amount of cash can be found by adding up all specific accounts in the #5 classification. The total amount of intercepted cash can be found by adding up all specific accounts with posting code D202. The total amount of intercepted cash in a particular fund code can be found by adding up all specific accounts with the fund code and posting code D202. Finally, the amount of intercepted cash for a fund code and balance sheet account can be found by selecting that specific account.

Posting codes provide a reporting capability not available in prior CGI Advantage Financial products. Before there was only one value for the account type of Asset. To find out how much of the Asset total was for receivables, fixed assets, cash, or inventory a query had to know the specific balance sheet accounts used for those items. Any time a new balance sheet was added, the query had to be updated. Now a query can be just for a single posting code, such as Inventory (S001). That query will return all records with that posting code with no need for balance sheets to be specified. With this ability many different balance sheets can be used to track different kinds of inventory items and new ones added as needed without ever having to change the query.

The reporting benefits of posting codes go even further by allowing the recording of elements needed for cash basis, modified accrual, and full accrual reporting simultaneously. Then in the construction of the reports, different groups of posting codes or individual posting codes are included or not included as needed.

Posting codes are an indication to the system that will contain instructions on how accounting and budgeting updates are to be done. These types of controls should not be changed in an application after a posting code has been used. To do so often requires a reconciliation batch job or a conversion process.

The Posting Code table provides the system with rules on which posting codes use default accounts and where from these accounts should be inferred. The Default Accounts section earlier gave details about the accounts and where they are established. Additionally, since users can manually enter balance sheets for many posting codes, the Posting Code table provides fields for defining attributes about those balance sheet accounts that must be satisfied in order to be used.

Many posting codes are delivered in the application to be used with the delivered event types and to be used on certain journal vouchers without event types. New posting codes can be added, but should begin with the letter 'X' or be all numbers so that later releases of Financial do not provide a new baseline posting code with the same ID. Deleting posting codes is not recommended, but may be done so that they are not used on journal vouchers. Changing settings on existing posting codes is also permitted, keeping in mind that once used, certain settings being changed will cause data integrity problems. Those fields are noted as such in the field by field description of the table later. However, before an application goes live or has any conversions of data into it, there is no problem changing any settings for a posting code. Keeping a record of these changes is a very good idea in case the baseline posting codes have to be restored.

Fields on the Posting Code (PSCD) table:

Field Name	Field Description
Posting Code	A required unique identifier for each posting code. Delivered posting codes contain one letter followed by three numbers.
Name	A required text field used to describe a posting code often for reporting and for informational reasons on a posting code pick page.
Short Name	A required short text field used to describe a posting code often used for reporting when the full name will not fit.
Closing Classification Code	Each posting code has to be associated with a closing classification code from the Posting Code Closing Classification table. These classifications drive the Annual C losing process. Reporting often uses this field as a rollup of posting codes for grouping records instead of having logic that specifies individual posting codes. The use of a Closing Classification Code for reporting eliminates the need to change the reporting logic each time a new posting code is added. Please see the table following the definition of Posting Code Closing Classification fields to find a crosswalk of the delivered Closing Classifications to the Account Types of prior CGI Advantage products.
Closing Classification Name	The inferred name of the closing classification code that is inferred from the Posting Code Closing Classification table.

Field Name	Field Description
Default Fund	The default fund field on an inference source table that will be inferred when the posting code is used. That inferred fund, and sub fund if entered on the inference source, will be used instead of the fund and sub fund on the accounting line. The inference of a fund is not a common routine and is only done for certain event type processors. Please see the descriptions of those processors for more information.
Default BSA	The default balance sheet account field on an inference source table that will be inferred when the posting code is used and an account was not manually supplied on the accounting line. If a sub balance sheet account is also specified on the inference source, it will be inferred as well if one is not manually supplied. The inference of balance sheet accounts is a common routine shared by all event type processors. Care should be taken to save a value in this field that when inferred, will match the Account Type restriction field for the posting code. If Use PSCD Value is selected, the Default Balance Sheet Account Code (and Sub Balance Sheet Account Code if also entered) will be inferred to the posting line.
Default BSA Code	An optional field to specify a default balance sheet account code for inference to a posting line if a value is not manually supplied. In order to use this field, the Default BSA selection must be Use PSCD Value. That selection in turn makes the Default BSA Code field required. Be sure to enter a BSA code that is valid in the current fiscal year and has the same Account Type as the posting code.
Default SBSA Code	An optional field to specify a default sub balance sheet account code for inference to a posting line if a value is not manually supplied. In order to use this field, the Default BSA selection must be Use PSCD Value. Be sure to enter a Sub BSA code that is valid in the current fiscal year for the Default BSA Code.
Default Object	The default object field on an inference source table that will be inferred when the posting code is used. That inferred object, and sub object if entered on the inference source, will be used instead of the object and sub object on the accounting line. The inference of an object is not a common routine and is only done for certain event type processors. Please see the descriptions of those processors for more information.
Default Revenue Source	The default revenue source field on an inference source table that will be inferred when the posting code is used. That inferred revenue source, and sub revenue source if entered on the inference source, will be used instead of the revenue source and sub revenue source on the accounting line. The inference of a revenue source is not a common routine and is only done for certain event type processors. Please see the descriptions of those processors for more information.
Offset	When a debit and credit are performed for the information on the accounting line of a document, most of the information for both entries are the same. Only information on the posting code and balance sheet account usually differ. The concept of an 'offset' posting code was developed to enable a single posting line to be created for both the debit and credit of a posting pair. When one posting code is marked an offset and the other isn't, a single posting line is created. Journal Posting then takes that single line and creates two full journal entries, repeating the common information on the two and putting the specific information that belongs on each. When neither posting code in a posting pair are marked as offsets, two half posting lines are created. Information on each line will lead to only one journal entry and each contains all information necessary to create that journal entry. The option of having two posting codes that are both marked as offsets for a posting pair is not allowed by the Event Type (ETYP) table. The offset flag value is inferred to that ETYP for each posting code where it can be changed so that half posting lines can be generated or a combined posting line can be generated. If the Offset flag is changed on the Posting Code table, the inferred offset value is changed on all Event Type records that use the code. For this reason, a user may be presented with Event Type errors because of the above edit preventing two offset codes in the same pair. When this happens, the correct route would be to change the offset values directly on the Event Type table where the edit allows. The offset flag has another use which is to direct the application to use a manually entered Offset Balance Sheet Account (OBSA) value on the accounting line with the posting code that is marked as offset. A manually entered value in the Balance Sheet Account field will be used with the non-offset posting code. The only exception is in the Double Non-Offset event type processor logic. The default value for this flag is not selected, but if selected, warnings will be issued if there is not a Default BSA and First Inference Source value. In most cases, there should be values for these two fields for an offset posting code. However, there can be offset posting codes where a user will have to manually enter an OBSA value on the accounting line because a default should not exist. In such a case, the document that can use the event type should allow entry of the OBSA field. Please see the section on the Document Control table for more information on this control.
Account Type	For those posting codes that require the association of a balance sheet account (BSA or OBSA) to create a complete journal record will have this field set to the appropriate balance sheet account type. When set, this field provides the application with the editing ability to issue errors when a BSA or OBSA was defaulted or manually entered that does not match what the posting code requires. The field will also provide the same error when no BSA or OBSA is inferred or manually entered and the posting code requires an account type. When a value is entered in this field, the value entered in the Closing Classification Code should correspond to that type of account. Failure to do so will cause Annual Close problems. Changing the value of this field for a posting code that has already been used is strongly discouraged. A modification, cancellation, or reference of that document will not process as the balance sheet associated with the posting code will no longer be allowed.
Cash Account	For those posting codes that should require a cash balance sheet account to create a complete journal record, this field will be checked. Such setup will require a manually entered or inferred balance sheet account used with the posting code to have the Cash Account flag checked on the Balance Sheet Account reference table. When not checked, the flag will enable the application to reject any document that attempts to associate a balance sheet account marked as cash with a posting code that does not allow cash accounts. Changing the value of this field for a posting code that has already been used is strongly discouraged. A modification, cancellation, or reference of that document will not process as the balance sheet associated with the posting code will no longer be allowed. This flag cannot be selected unless the Account Type field is set to Asset and the Default BSA field also has a value.
Memo Account	For those posting codes that should require a memo balance sheet account, this field will be checked. Such setup will require a manually entered or inferred balance sheet account used with the posting code to have the Memo Account flag checked on the Balance Sheet Account reference table. When not checked, the flag will enable the application to reject any document that attempts to associate a balance sheet account marked as memo with a posting code that does not allow memo accounts. Changing the value of this field for a posting code that has already been used is strongly discouraged. A modification, cancellation, or reference of that document will not process as the balance sheet associated with the posting code will no longer be allowed.
First Inference	Posting codes that have a default balance sheet account, l object, revenue source, or fund will have this field completed with a table that the application will look to first to find a default value when a value has not been manually entered on the accounting line. When this value is System Wide Special Accounts (SPEC), there is the possibility that the application will look to another table to retrieve a default. When the Override flag is checked on SPEC, the application will go to the Special Fund Accounts (SPECFUND) table to retrieve any value defined there. If one is not defined, then the one from SPEC will be used. The default value for the field is System Wide Special Accounts. If this value exists for a posting code without a Default BSA, Object, Revenue Source, or Fund, document processing will not be impacted as the field will not be used.
Second Inference	Posting codes that have a default balance sheet account, object, revenue source, or fund may have this field completed with a table that the application will look to next to find a default value when a value has not been manually entered on the accounting line or inferred from the First Inference source.
Third Inference	Posting codes that have a default balance sheet account, object, revenue source, or fund may have this field completed with a table that the application will look to next to find a default value when a value has not been manually entered on the accounting line or inferred from the First or Second Inference sources.

Field Name	Field Description
Expense Budget	When a posting code should update a budget structure that tracks spending, this flag will be checked. If checked, the value in the Expense Bucket ID field will be updated. Additionally, if checked and a matching budget line at every budget level defined as Presence Optional = false of a budget structure that is required because a Required Budget (REQBUD) match was found, then a 'budget line not found' error will be issued. If not checked, no update will be made and no budget line editing will occur. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.
Expense Bucket ID	When the Expense Budget flag is checked for a posting code, this budget amount field will be updated with the Posting Amount found on the posting line that uses the posting code. When a value is set in this field and the Expense Budget flag is not selected, there will be no budget update. There will be no document processing impact at all because the flag determines if this bucket ID is used. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.
Expense Budget Name	When the Expense Bucket ID field is entered and the posting code record saved, the name for the bucket ID is inferred from the Budget Tracking Amount (BUDTAM) table.
Revenue Budget	When a posting code should update a budget structure that tracks revenues, this flag will be checked. If checked, the value in the Revenue Bucket ID field will be updated. Additionally, if checked and a matching budget line at every budget level defined as Presence Optional = false of a budget structure that is required because a Required Budget (REQBUD) match was found, then a 'budget line not found' error will be issued. If not checked, no update will be made and no budget line editing will occur. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.
Revenue Bucket ID	When the Revenue Budget flag is checked for a posting code, this budget amount field will be updated with the Posting Amount found on the posting line that uses the posting code. When a value is set in this field and the Revenue Budget flag is not selected, there will be no budget update. There will be no document processing impact at all because the flag determines if this bucket ID is used. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.
Revenue Budget Name	When the Revenue Bucket ID field is entered and the posting code record saved, the name for the bucket ID is inferred from the Budget Tracking Amount (BUDTAM) table.
CBAL Update	When a posting code should update the Cash Balance Inquiries, this flag will be checked. If checked the bucket in the CBAL Bucket field will be updated. If not checked, there will be no update. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.
CBAL Bucket	When the CBAL Update flag is checked for a posting code, this CBAL amount field will be updated with the Posting Amount found on the posting line that uses the posting code. The update will occur to the Cash Balance Detail (CBALD) table where the application pushes the update up to the Cash Balance Summary (CBALS) and optionally the Cash Balance Pool (CBALP) table. When a value is set in this field and the CBAL Update flag is not selected, there will be no CBAL updates. There will be no document processing impact at all because the flag determines if this bucket ID is used. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.
FBAL Update	When a posting code should update the Fund Balance Inquiries, this flag will be checked. If checked the bucket in the FBAL Bucket field will be updated. If not checked, there will be no update. When a value is set in this field and the FBAL Update flag is not selected, there will be no FBAL updates. There will be no document processing impact at all because the flag determines if this bucket ID is used. The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.
FBAL Bucket	When the FBAL Update flag is checked for a posting code, this FBAL amount field will be updated with the Posting Amount found on the posting line that uses the posting code. The update will occur to the Fund Balance Detail (FBALD) table where the application pushes the update up to the Fund Balance Summary (FBALS). The changing of this field after documents have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.
Code Type	This protected field is determined automatically based on values entered in the Account Type, Expense Budget, and Revenue Budget fields to enable the application to determine the appropriate BFY Stage Definition table (Balance Sheet, Spending, Revenue, or Non-Accounting) to read to determine what state a document record date falls. Please refer to the Document Editing section under BFY Staging Configuration for more information. When the Account Type field is not blank, the Code Type will be set to Balance Sheet Account. If the Account Type is blank and the Expense Budget flag is checked, the Code Type will be set to Spending. If the Account Type is blank and the Revenue Budget flag is checked, the Code Type will be set to Revenue. If the Account Type field is blank and both the Expense Budget and Revenue Budget flags are unchecked, the field will be set to Non-Accounting.

Field Name	Field Description
Overhead Rate Process	The Overhead Rate chain job in the Cost Accounting area uses this field to select journal records. Journal records are selected that have a posting code with this flag checked. The run sheet for that job and the User's Guide information for Cost Accounting should be consulted for more information on overhead.
Cost Allocation Process	The Cost Allocation chain job in the Cost Accounting area uses this field to select journal or ledger records. Records are selected that have posting codes with a Cost Allocation Process value equal to the indicated type of allocation of the Allocation ID selected from the Cost Allocation Control Step (ALOC) table as input. Valid values for this field are Cash Expenditure, Collected Revenue, Revenue Credits, and Charges to match flags found on ALOC with a fifth value of Not Applicable to mark all posting codes not eligible for any type of cost allocation. The default value for the field is Not Applicable. The run sheet for that job and the User's Guide information for Cost Accounting should be consulted for more information on cost allocation.
Funding Split	Cost Accounting functionality allows for the definition of Front End Split (FES) and Back End Split (BES) Major Program Codes. Both allow for the use of multiple funding sources while only requiring an end user to code one funding source. For FES, the breakout into various funding source occurs before the accounting document goes to pending and final phase. For BES, the breakout occurs as the result of a batch job selecting journal records that did not split when processed because the Major Program used was defined as BES. Valid values for this field are Split for Reporting, Split for Reimbursement, and N/A. The default value for the field is N/A. The run sheet for the Reimbursement chain job and the User's Guide information for Cost Accounting should be consulted for more information on splits.
FACP Eligible	Cost Accounting/Fixed Asset functionality allows for the automatic creation of Fixed Asset Increase/Decrease (FI), Fixed Asset Cancellation (FC), and Fixed Asset Type Change (FX) documents based on Program or Program/Phase data. As accounting documents are processed that match the Program or Program/Phase data, journal records are created. When those journal records contain a posting code marked as FACP Eligible, they will be selected by the Program Asset Generation chain job and the appropriate fixed asset document will be created. The run sheet for the Program Asset Generation chain job and the User's Guide information for Cost Accounting and Fixed Assets should be consulted for more information on Program Asset Generation.
Accounting Type Journal	The Journal/Ledger Control (JLCTRL) table requires that a value must be entered in the Posting Code Types for Selection field for each journal defined to an application. When that setting is All or Accounting for a given journal, the Journal Engine will write all posting lines from the Posting Line Catalog that are marked as 'Ready to Post' with a posting code that has this Accounting Type Journal flag checked. Those journals not built from posting lines will not use the Accounting Type Journal flag or the Posting Code Types for Selection field. The Commodity, Budget, and Fixed Asset Component are such journals. Each of these is posted not by the Journal Engine but directly from documents. The value in this flag should never be changed once a posting code has been used. To do so would likely require the rebuilding of all journals that would have the posting code written out now or not written out now, along with all the ledgers built from that journal.
Journal Type for 1099 Reporting	The Journal/Ledger Control (JLCTRL) table requires that a value must be entered in the Posting Code Types for Selection field for each journal defined to an application. When that setting is 1099 for a given journal, the Journal Engine will write all posting lines from the Posting Line Catalog that are marked as 'Ready to Post' with a posting code that has this Journal Type for 1099 Reporting flag checked. The value in this flag should never be changed once a posting code has been used. To do so would likely require the rebuilding of all journals that would have the posting code written out now or not written out now, along with all the ledgers built from that journal.
Cash Type Journal	The Journal/Ledger Control (JLCTRL) table requires that a value must be entered in the Posting Code Types for Selection field for each journal defined to an application. When that setting is Cash for a given journal, the Journal Engine will write all posting lines from the Posting Line Catalog that are marked as 'Ready to Post' with a posting code that has this Cash Type Journal flag checked. The value in this flag should never be changed once a posting code has been used. To do so would likely require the rebuilding of all journals that would have the posting code written out now or not written out now, along with all of the ledgers built from that journal.
Fixed Asset Type Journal	The Journal/Ledger Control (JLCTRL) table requires that a value must be entered in the Posting Code Types for Selection field for each journal defined to an application. When that setting is Fixed Asset for a given journal, the Journal Engine will write all posting lines from the Posting Line Catalog that are marked as 'Ready to Post' with a posting code that has this Fixed Asset Type Journal flag checked. The value in this flag should never be changed once a posting code has been used. To do so would likely require the rebuilding of all journals that would have the posting code written out now or not written out now, along with all of the ledgers built from that journal.