The concept of internal accounting refers to what some call inter-governmental or intra-governmental. All labels refer to accounting that is done for two parties on the same CGI Advantage Financial application. It does not mean just two governmental entities because if they are on separate financial systems, transactions between the two would be treated as external. A check still has to be written and a cash receipt has to be recorded as if the two parties were not under the same governmental umbrella.
Internal accounting event types therefore use two posting pairs. Posting Pair A is always for the selling or providing party. Posting Pair B is always for the buying or receiving party. On the Internal document types (IET, ITI, and ITA) the distinction of which party is the buyer or the seller is made with the Initiator field on the document header. On the other document types that perform internal accounting, the Payment Request (PR), Stock Transfer (TR), Stock Issue (CI and OC), Stock Return (SN), and Payroll (PYRL), that initiator distinction is still made by being defaulted to Seller/Provider. When the Initiator is Seller/Provider, the COA information for that party will be on the vendor line (that is, Exchange Details on the ITA and IET). The Buyer/Receiver information will be on the accounting lines.
When an event type has posting codes defined for Posting Pair C, then the event type processor will create a posting line for pair C with the same document data used to create the posting line for Posting Pair A. When an event type has posting codes defined for Posting Pair D, then the event type processor will create a posting line for pair D with the same document data used to create the posting line for Posting Pair B. When these additional posting pairs are used, it is likely different posting codes will be used and thus different balance sheets are inferred.
All rules in the internal event type processor other than which posting pair is used for which party involve data edits:
For all event categories, the inference of a Bank code is dependent on the Event Type Requirement Bank rule. If set to Optional or Prohibited, no bank will be inferred. If set to Required, then the Bank code will be inferred from the Fund table using the fiscal year and fund code.
Event types entered on the vendor lines of the internal documents are defaulted to the accounting lines. The values must be the same between the two with an exception for the Internal Reimbursements (IP1, IP2, and IP3) and Quasi External Transactions (IP4, IP5, IP6) accounting models. The event types can change between the vendor line and accounting line with an override application as long as they have the same accounting model.
For event categories IP1, IP2, IP4, IP5, OT1, OT2, or OT3, the Fund and Sub Fund combination must be different between the buyer and the seller.
For event categories IP3 and IP6, the Fund and Sub Fund must be the same between the buyer and the seller.
For event categories OT1 or OT2, the revenue source is required for the receiving party and must be marked as Transferable on the Revenue Source table. Entry of an object and sub object is not allowed. Also, the Require Sub Nominal Account for Buyer/Receiver flag is read for the event type ID on the Event Requirements table to determine if a sub revenue source is also required.
For event categories OT1 or OT2, the object is required for the providing party. Entry of a revenue source or sub revenue source is not allowed. Also, the Require Sub Nominal Account for Seller/Provider flag is read for the event type ID on the Event Requirements table to determine if a sub object is also required.
If event category ID1, IP4, IP5, IP6, IP9, or IP10 is used, a revenue source code is required for the seller/provider and values are prohibited for object and sub object. Also, the Require Sub Nominal Account for the Seller/Provider flag is read for the event type ID on the Event Requirements table to determine if a sub revenue source is also required.
If event category ID1, IP4, IP5, IP6, IP9, or IP10 is used, an object code is required for the buyer/receiver and values are prohibited for revenue source and sub revenue source. Also, the Require Sub Nominal Account for the Buyer/Receiver flag is read for the event type ID on the Event Requirements table to determine if a sub object is also required.
If event category IP1, IP2, IP3, OT1, or OT2 is used, the object code entered for the seller/provider must be marked as Reimbursable on the Object table. Not to be confused with the Reimbursement Eligible field.
If the event category is IP2, IP5, IT2, or OT2 is used, populate the Internal Fund, Sub Fund and Department values on the posting line in pair A with Fund, Sub Fund, and Department from the posting line in pair B. Populate the Internal Fund, Sub Fund and Department values on the posting line in pair B with Fund, Sub Fund, and Department from the posting line in pair A.
If the Internal Event Type Processor is called, and all of the following are true:
The referencing document type is ITI, ITA, or IET.
The referenced document type is RE, CL, or ARE.
The reference is a non-memo type of reference.
The AR_REF_OPT on the Application Parameters table has a parameter value of 3.
Then, if the BFY field on the referencing accounting line is NOT blank, the processor will set the BFY on the liquidation posting line(s) to that BFY value. If the BFY value on the referencing accounting line is blank, the processor will set the BFY on the liquidation posting line(s) to the CURR_BFY value of the accounting line.
If the event category is ID1 (Internal Debt 1) then several of the restrictions of other internal event categories are not enforced:
Fund and Sub Fund codes are not compared
Reimbursable Objects
Transferrable Revenue
The AR_REF_OPT Application Parameter
Requiring or Prohibited on Object or Revenue Source
If the event category is ID1 (Internal Debt 1) then several features not available on other internal event categories are available:
Event types on all accounting lines must be that of the parent vendor line.
Internal Fund, Sub Fund, and Department will always be populated with values for the ‘other party’.