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 those specific COA.

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. The construction of the reports should use different groups of posting codes or individual posting codes that are included or not included as needed to efficiently gather data instead of COA code listings or even rollups when possible. The reason is that establishing new posting codes are a rare event compared to new COA codes and even rollup codes. However, there are times when more detailed selection cannot be avoided.

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. Any changes to a record on Posting Code should be followed by a bounce of the application to ensure change takes effect. While some changes may not require a bounce, a bounce is the recommended practice.

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 codes 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.

Field InformationField Information

Fields on Posting Code (PSCD) are as follows, with common fields omitted:

Field Name

Field Description

Posting Code

A unique identifier for each posting code. Delivered posting codes contain one letter followed by three numbers.

Closing Classification Code

This required classification drives the Annual Closing process and is used in selection rules for reporting.

Default Fund

Default Object

Default Revenue Source

For those few posting codes that should infer a default fund, object, or revenue source instead of using the accounting line value, these listings provides the options.

Inferences of these three COA are not a common routine and are only done for certain event type processors.

Default BSA

For those posting codes that should default a balance sheet account, this listing provides those defaults. Although, the inference of balance sheet accounts is a common routine shared by all event type processors the use of a default account that cannot be connected to data within the transaction will not result in a default (e.g. a posting code setup to default from a Bank will not work if the bank cannot be entered). Always choose a Default Account value that matches the Account Type restriction field for the Posting Code.

The special choice of Use PSCD Value requires the input of at least the Default BSA Code field.

First Inference

Second Inference

Third Inference

Posting codes that have a defaulting COA will have at least the First Inference source completed with a source that the application will look to first to find a default value when a value has not been manually entered on the accounting line. In many cases where there is only one possible default source, this will be the only field of the three completed. For those inferences with multiple sources (mainly Accounts Receivable), multiple sources will be defined where the First Inference has priority as it will be read first. If a value is found then, no other attempt will be made to locate an inference. If a value is not found on the First Inference source then the Second will be read and then the Third.

These three fields should be blank if the Default BSA is blank or Use PSCD Value.

Default BSA Code

Default SBSA 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.

Offset

In the creation of a posting line there is typically a primary posting code and other posting code that is used for balancing, typically with a control account. This other posting code is referred to as the Offset Posting Code. This indication is a default for those offset posting codes that can be changed later in the setup of a Posting Pair for an Event Type because two offset posting codes are not typically paired together.

Account Type

This indication is used to enforce that any balance sheet account associated with a posting code is of the correct account type: Asset, Liability, Equity, or Contra Asset.

When entered, 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 transaction will not process, as the balance sheet associated with the posting code will no longer be allowed.

Cash Account

When true the balance sheet account used with a posting code should be flagged as a Cash Account on the Balance Sheet Account reference page.

Memo Account

When true the balance sheet account used with a posting code should be flagged as a Memo Account on the Balance Sheet Account reference page.

Expense Budget

Expense Bucket ID

Expense Budget Name

When true the posting code is to be one that will update all budget structures tracking spending where a matching budget line is found. The amount on the budget line that is updated is defined in Expense Bucket ID.

The changing of this field after transactions have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.

Revenue Budget

Revenue Bucket ID

Revenue Budget Name

When true, the posting code is to be one that will update all budget structures tracking revenue where a matching budget line is found. The amount on the budget line that is updated is defined in Revenue Bucket ID.

The changing of this field after transactions have processed with the posting code is not recommended because it will introduce System Assurance 1 or 11 out of sync conditions.

CBAL Update

CBAL Bucket

When true, a posting code will update the Cash Balance Inquiries. The CBAL Bucket field will define how the cash balance update will be made.

The changing of this field after transactions have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.

FBAL Update

FBAL Bucket

When true, a posting code will update the Fund Balance Inquiries. The FBAL Bucket field will define how the fund balance update will be made.

The changing of this field after transactions have processed with the posting code is not recommended because it will introduce System Assurance 2 out of sync conditions.

Code Type

A classification set by the application based on values entered in the Account Type, Expense Budget, and Revenue Budget fields to enable the applicable to determine the appropriate BFY Stage Definition (Balance Sheet, Spending, Revenue, or Non-Accounting) to read to determine what state a transaction record date falls. Please refer to the Transaction Editing tab 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 indication is true, the Code Type will be set to Spending. If the Account Type is blank and the Revenue Budget indication is true, the Code Type will be set to Revenue. If the Account Type field is blank and both the Expense Budget and Revenue Budget indications are false, the field will be set to Non-Accounting.

Overhead Rate Process

When true, the Overhead Rate Process in Cost Accounting will select journal records for the posting code.

Cost Allocation Process

Values for Cash Expenditure, Collected Revenue, Revenue Credits, and Charges exist to match settings for an Allocation ID on the Cost Allocation Control Step (ALOC) page. The Cost Allocation Process uses the Allocation ID setting to select posting codes with the same setting for record selection.

A fifth value, Not Applicable marks all posting codes not eligible for any type of Cost Allocation selection.

Funding Split

The 'Split Routine' of Cost Accounting reads this setting to determine if it should performing either a Front End Split (FES) or Back End Split (BES) as defined to the Major Program used. Valid values for this field are Split for Reporting, Split for Reimbursement, and N/A.

The first two will trigger the Split Routine but only posting codes set as Split for Reimbursement will be selected by the Reimbursement Output Process.

Fixed Asset Construction Program Eligible

When true, a posting code used with Program and Phase setup for Fixed Asset Construction Program Allocation along with a selective set of other COA flagged as eligible will update the Fixed Asset Expenditure Accumulation inquiry page.

Accounting Type Journal

When true, all posting lines with the posting code will post to all journals defined on the Journal/Ledger Control (JLCTRL) page where the Posting Code Types for Selection field is All or Accounting.

The value in this indication 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

When true, all posting lines with the posting code will post to the 1099 Journal (as it is setup on Journal/Ledger Control with the Posting Code Types for Selection of 1099).

The value in this indication should never be changed once a posting code has been used. To do so would likely require the rebuilding of the journal.

Cash Type Journal

When true, all posting lines with the posting code will post to the Cash Journal (as it is setup on Journal/Ledger Control with the Posting Code Types for Selection of Cash).

The value in this indication should never be changed once a posting code has been used. To do so would likely require the rebuilding of the journal.

Fixed Asset Type Journal

When true, all posting lines with the posting code will post to all journals defined on Journal/Ledger Control where the Posting Code Types for Selection field is Fixed Asset.

The value in this indication should never be changed once a posting code has been used. To do so would likely require the rebuilding of the journal and the ledger built from that journal.