Subsystem Interface - GLUTSPSI
When transactions are processed by the various subsystems, such as Accounts Payable, Accounts Receivable, Payroll, Cash Receipts, and Fixed Assets, there are postings which need to be made to the General Ledger database. The GL Postings Subsystem Interface (GLUTSPSI) page is used for defining these subsystem interfaces (automatic entries to the general ledger). Each subsystem and type of transaction is specified and defines the types of entries to be made to the general ledger.
BusinessPlus is extremely flexible in terms of the posting strategies which may be employed in these automatic entries. This flexibility means that postings will happen exactly the way the user wants them to, and it means that someone needs to learn how to tell the system how they should happen. The system is installed with some fairly standard strategies for automatic posting. The accountants then make changes to or add strategies. These postings are defined to the system so that there is no need for manually created Journal Entries to post to accounts such as "Cash in Bank", "Accounts Receivable" or "Accounts Payable" (i.e., we would like the system to make these entries automatically, each time transactions are processed).
The posting of subsidiary system activity may be directed on an individual basis or at a summary level—by object, project, posting code, fund code, or by a grand total.
Ledger, Subsystem and Report Register identifies the subsystem and the report/register which prints the values that are to be posted. These fields are used to group transactions into categories within subsidiary systems.
The GL account identification consists of identifying the two parts which are used to post GL transactions. The first part is called the department, cost center, project, key, or some organization key and the second is the object code. Several codes have been established to make the definition of the GL interface easier. The following describes the possible codes for directing entries from subsidiary systems (AR, AP, etc.) to the proper GL account. Please note that not all of these will make sense for a particular subsystem and report/register and some may never be used by a given client.
Subsystem Interface Data Entry
Users can navigate to a ledger/subsystem/report register by using the Entity List panel on the left side of the WebClient page. This list contains a ledger control allowing the user to easily select from all ledgers defined in BusinessPlus. Then, the subsystem/report register can be selected from the list below the ledger by clicking on the desired record. This will automatically load the subsystem interface data on the main form of the page.
After entering/updating subsystem interface data, click the Save button to store the information in the database. If changes were made to the data and not saved, the user will be prompted if they wish to save their current changes and action will be taken accordingly. To add a new record, enter the desired information on the row with an asterisk ( * ) in the first column. To insert a row, right-click the desired row to insert before and select "Insert New Row". To delete a row, select the desired row to delete and press the delete key on the keyboard. Note that the Save button must be clicked after making ANY changes to the subsystem interface data. If a change was detected and the user tries to navigate to another row or close the application, they will be prompted to save the information first before performing the desired operation.
If there were any problems saving data to the database, an error list will appear and there will be a red exclamation point beside every row containing an error. No data for the current record can be saved until these errors are fixed.
GLUTSPSI data is stored in NU Common Codes (NUUPCD), in the format GLxx/DIST#### where GL is always GL, xx is the subsystem, DIST is the report/register and #### is a sequential number indicating which line this is in GLUTSPSI. For example, GLCR/DIST0001 would be the first GLUTSPSI entry for the CR subsystem.
PY has 3 report/registers: EREG, CREG, and DREG. The common codes look like this: GLPY/EREG#### for EREG, GLPY/CREG#### for CREG, and GLPY/DREG#### for DREG. PY data always uses the GL ledger.
Within each GLxx/DIST#### common code:
- The ledger field is stored in the common code ledger field.
- The short description has the ledger, Level, Type, Date (the Level, Type, and Date field make up the LTD section of the GLUTSPSI screen), posting code (this is stored as a 3-character field), and fund.
- The long description holds the views. The views are in YYNN format (they're usually set to YYNN; they can be any 4-character combination of Y's and N's). Views are used to tell GL how to accumulate the transactions.
- The first associated code is DR/CR for debit/credit.
- The second associated code is the org. key to be posted to.
- The third associated code is the object code to be posted to.
Subsystem Interface Definition Options
The top of the main form is used for information purposes only. It displays the current ledger/subsystem/report register selected by the user. It also shows valid data entry options corresponding to the columns in the credit/debit grid views. This is referred to as the Subsystem Interface "Legend" since is gives basic definitions to the options used when defining subsystem interface records.
Subsystem Interface Data Entry Definitions
Org Key (KEY) | Description |
|---|---|
TRNS | Use the Org. Key entered on the transaction. This option is used when the preference is to see individual transaction postings in the GL. |
TTLKEY | Total all the entries within the batch for the same Org. Key and post a single summary transaction. |
CKKEY | Certain types of transactions have a Check Stock ID code entered as part of the transactions; e.g., Cash Receipts, check writing from AP and Payroll. These Stock IDs can be associated with a particular Org. Key in the common codes table. When the user places CKKEY in this field, the system automatically retrieves the Org. Key associated with the given Check Stock ID. |
FDKEY | Using the common codes file posting of inter-fund (and other) entries at the fund level may be effected by directing posting to a single Org. Key for each fund. |
| CKFDKEY | A combination of FDKEY and CKKEY, it will use the CKKEY to look up the FDKEY. Used when the CKKEY is not at the fund level, but the offset entries need to be at the fund level of the CKKEY. It will use the value in Associated Code #1 of the FDID as the GL Org Key. |
DVKEY | From the Subsystem Division entered in the batch, use the Org. Key entered on the Division Definition Form (supported only by AR at the current time). |
xxxxxxx | Use the specific Org. Key entered on this form. |
Obj Code (Object) | Description |
|---|---|
TRNS | Use the Object Code entered on the transaction. This option is used when the preference is to see individual transaction postings in the GL. |
TTLOBJ | Total all the entries within the batch made to the same object code and post a single summary transaction. |
CKOBJ | Certain types of transactions have a Check Stock ID code entered as part of the transactions; e.g., Cash Receipts, AP, and Payroll. These Check Stock IDs can be associated with a particular Object Code in the common codes table. When the user places CKOBJ in this field, the system automatically retrieves the Object Code associated with the given check Stock ID. |
FDOBJ | When detail transactions are entered, they specify a particular Org. Key and Object Code. Each Org. Key is associated with a particular Fund Code. These Fund Codes can be associated with a particular Object Code in the Common Codes File. When the user places FDOBJ in this field, the system automatically retrieves the Object Code associated with the given Fund Code. |
| CKFDOBJ | A combination of FDKEY and CKKEY, it will use the CKKEY to look up the FDKEY. Used when the CKKEY is not at the fund level, but the offset entries need to be at the fund level of the CKKEY. It will use the value in Associated Code #2 on the FDID Common Code as the GL Object. (CR, AP, OH, PY only) |
| DVOBJ | Use the Object as defined on the Division Code (ARUPCD, Division tab) for the Division code on the transaction. (AR/CR only) |
xxxxxxx | Use the specific Object Code entered on this form. |
Any of the Key and Object Codes may be used together and there is NO relationship between the code used and the Level.
Level (L) | Description |
|---|---|
T | The individual transaction level that is only used when the Org. Key is "TRNS" or "xxxxxxx" and the Object Code is "TRNS" or "xxxxxxx". No summarization will occur. It will use details from the subsystem transaction to write the General Ledger transaction. |
O | Object Code total level. Transactions will be summarized by the Org Key, Object Code and PCi on the GLUTSPSI line. Transaction description will be “AutoID: {batch name} J: {job number}.” |
K | Org. Key total level. Transactions will be summarized by the Org Key, Object Code, and PCi on the GLUTSPSI line. Transaction description will be “AutoID: {batch name} J: {job number}.” |
P | Posting Code total level. Transactions will be summarized by the Org Key, Object Code, and PCi on the GLUTSPSI line. Transaction description will be “AutoID: {batch name} J: {job number}.” |
F | Fund total level. Transactions will be summarized by the Fund Administration Org Key and Object Code. When using “F” level, the FUND field will also require a value of a specific Fund Code or “@@” and a PCi will not be accepted. |
| E | Employee Level: Transactions will be summarized by Employee, Org Key, Object Code and Register. The Employee ID will be in the PEID field on the GL Transaction and the Employee Name will be the GL Transaction Description. (PY Only) |
| X | Pay Type Total: Transactions will be summarized by the Org Key, Object Code on the GLUTSPSI line and Pay Type on the CR transaction. Transaction description will be “AUTO PAY: {pay type} J: {job number}.” (CR only) |
Z | Finance Code total level. Transactions will be summarized by the Org Key, Object Code on the GLUTSPSI line and Finance Code on the CR transaction. Transaction description will be “AUTO Fin: {finance code} J: {job number}.” (AR, CR only) |
G | Grand total, all transactions. Transactions will be summarized into a single entry. |
Any control postings which occur (e.g., O, K, P, F, G) will be posted to the GL with a transaction description as follows: AUTO ID: BP004681JB: 000623
"AUTO" indicates that this is an automatic posting.
"ID" is followed by the Batch ID Number for all entries in the transaction batch.
"JB" is followed by the BusinessPlus Job Number which is automatically assigned at the time of posting.
TYPE (T) | Description |
|---|---|
A | Distribution amount (Qty x Price) |
B | Base price (SI subsystem ONLY) |
D | Discount amount (AR, AP, SI( |
F | FIFO (SI) |
| T | Tax Amounts (AP, SI) |
N | Distribution amount minus the discount amount (Net amount) |
L | Discounts Lost (AP, SI) |
| C | Charges (AP, SI) |
| U | Duty (AP) |
| P | Principal (AR, CR) |
Q | Quoted Price (SI subsystem ONLY) |
F | Net plus Discounts Lost |
| I | Interest (AR, CR) |
i | Digit 0,1,2….9 used primarily with PY subsystem postings. |
| 0 | (PY, EREG only) |
| Distribution amount | (PY, all Registers) |
| Overtime Pay | (PY, EREG only) |
| Vacation Pay | (PY, EREG only) |
| Holiday Pay | (PY, EREG only) |
| Sick Pay | (PY, EREG only) |
| Comp Time Pay | (PY, EREG only) |
| Gross Pay | (PY, EREG only) |
| Net Pay | (PY, EREG only) |
| Gross Pay plus Total Contributions | (PY, EREG only) |
The Type field provides some level of calculation; it can be used to pick up different amounts from the batch and post them separately, or combine some items and post them as a single amount. The above codes are available, depending on subsystem. The calculations can be changed, and new calculations added using the Calculation Definitions (GLUTSPSC) page.
DATE (D) | Description |
|---|---|
P | Posting date |
C | Check date (AP, PY) |
I | Invoice date (AP with Level “T” only) |
B | Bank date (AP interfacing with CK cancelled check process only) |
A | Accrual Entry (used only if posting both Cash & Accrual Balances) |
R | Accrual Reversal at Check Date (used only if posting both Cash & Accrual Balances) |
VIEWS (V) | Description |
|---|---|
A | None |
B | Accrual only |
C | Cash only |
D | Accrual and Cash |
E | Modified only |
F | Accrual and Modified |
G | Cash and Modified |
H | Accrual, Cash, and Modified |
I | User-Custom ONLY |
J | Accrual and User-Custom |
K | Cash and User-Custom |
L | Accrual, Cash, and User-Custom |
M | Modified and User-Custom |
N | Accrual, Modified, and User-Custom |
O | Cash, Modified, and User-Custom |
P | Accrual, Cash, Modified, and User-Custom |
The View field can be used to control which entries show up on specific reports. All views are combinations of four basic views, Accrual, Cash, Modified and User Defined. These codes are recorded on transactions as combinations of codes. The General Ledger transactions have four view codes that are flagged as either “Y” or “N.” The first view is for Accrual, the second for Cash, the third for Modified, and the fourth for User. Therefore, if an entry in GLUTSPSI is flagged as “N,” the resulting transaction would get a view of “YNYY,” meaning it would be viewed as Accrual, Modified and User. When GL reports are run, there is an optional question, “Report Base,” that will tell the report which transactions to view based on their view codes. If a report were run to view cash basis transaction only, the above “N” postings would not be seen. However, if any other Report Base flag were selected, the transaction would be reported.
Posting Codes (PCi) | Description |
|---|---|
| Blank implies that the posting is not related to a specific posting code |
@@@ | Each posting code |
Iii | Posting code 000-999 |
For most subsystems, the PCi is defined in GLUTSPPP and is formatted 0xx, where “xx” is the posting code as seen on the batch screen. Some exceptions are: FA, where the posting code is defined on the Depreciation screen in FA; and Payroll where the posting code is formatted “xxx.” Although Payroll uses GLUTSPPP, it is allowable to use CDH numbers as well, however, they function slightly differently from Posting Preferences codes.
FUND (FD) | Description |
|---|---|
| Blank implies that this is not a fund level posting |
@@ | Each posting code |
ii | Fund code 00-99 |
The Ledger field is only used for Payroll subsystem, however a valid ledger code is required. The ledger codes entered here only affects postings to GL for subsystem PY. For other subsystems, the ledger at the top of the screen defines which ledger will be posted to. For Payroll, the ledger at the top is always GL, and the ledger field here is the specific one being posted to for the debit or credit it is associated with.
History User Interface
The History User Interface (UI) provides a simple and efficient way of saving prior subsystem interface data records. To access the History UI, click the Preferences tool strip and select "History".
The History UI initially presents the user with options that describe when the software will automatically begin deleting history records. This is the "General" tab and is not specific to a ledger/subsystem/report register. These values are specific to the GLUTSPSI utility as a whole. Both a date and numeric value are required in case subsystem interface data remains static over a long period of time. This enables the user to specify a date significantly in the past to prevent deleting records unintentionally when the numeric value was set to a low number. Note that there is a limit on 25 records per ledger/subsystem/report register, however specifying a date in the past could cause the system to not delete records until BOTH the date and the numeric value constraints are satisfied.
The "Records" tab contains detailed information regarding when history records were created, as shown below. This information is saved on a ledger/subsystem/report register basis. If the current subsystem interface data were changed for the ledger, a snapshot of the current subsystem interface data would be saved as a new history record after a click to the save button.
In order to reload a history record, open up the History UI and navigate to the Records tab. Select the desired history record from the tree view control and click apply to reload the Main Form with the history record. Note that the Record Info text box on the Main Form will reflect the history record chosen by displaying the date/time of the selected record. Likewise, the History UI Records tab will also display "(Selected)" beside the record currently displayed on the Main Form. This provides easy identification on which record is currently selected.
Note that when saving a history record the user is prompted to see if they really want to make a history record the current data used for Subsystem Interfaces.
Tools
After defining or changing the System Interface records, launch the tool to Rebuild the System Interfaces and update the associated common codes.