This chapter contains these topics:
You review and analyze workfile information to track the status of workfile transactions and accurately plan your invoicing cycle.
The Billing Detail Workfile (F4812) is a repository of transactions used by the system to invoice customers, recognize revenue, and allocate costs. The system provides the following three methods to create workfile transactions:
| File | Description |
|---|---|
| Workfile Generation | The system uses this batch process to create workfile transactions based on billable accounting entries stored in the Account Ledger table (F0911). When you run Workfile Generation, the system copies source transactions from the Account Ledger to create workfile transactions, applying the correct markup, offset, and tax information. You use the Workfile Revisions form to view these transactions. |
| G/L Transaction Selection | You use this interactive program to create workfile transactions based on billable accounting entries stored in the Account Ledger table (F0911). When you use G/L Transaction Selection, the system copies the selected source transactions from the Account Ledger to create workfile transactions, applying the correct markup, offset, and tax information. You use the Workfile Revisions form to view these transactions. |
| Ad-hoc Workfile Transactions | You use this interactive program to create workfile transactions that are not represented in the Account Ledger table (F0911). |
To maintain the integrity of the original source transactions, the system creates copies of these billable transactions. The copied transactions are referred to as workfile transactions and are stored in the Billing Workfile (F4812).
Workfile transactions include costs with any applicable markup, tax, and other key information. The rest of the billing process is based on the information stored in workfile transactions.
All workfile transactions with an eligibility code of 0 (invoicing, revenue, costing) or 1 (invoicing only) must include a customer number. The system uses the customer number to invoice the transactions. You must identify a customer number on individual jobs (business units) or work orders associated with the transactions.
Note:
You attach a customer number in the Owner Address field on the Job Master Revisions form, not the Job Site Address field. The Address Book number on the Revise Business Unit form is not the customer number.Account Ledger (F0911) transactions originate from multiple sources, such as the Accounts Payable, Equipment/Plant Management, and Payroll systems. You run the Workfile Generation program to accumulate the cost information from these sources into the billing system.
For the system to create workfile transactions from payroll transactions, all information in the Payroll and Employee tables must be identical to the Account Ledger table. The Payroll system allows summarized accounting entries; therefore, the billing system must retrieve detail information from the Payroll system to create the workfile transactions. The system uses the following fields from the Account Ledger to retrieve additional information from the Payroll Transaction History (F0618) or the Employee Transactions Detail (F06116) table to create the workfile transactions:
Batch Number
Account Number
G/L Date
Subledger Information
Caution:
After the system processes payroll, the fields above should not be changed or deleted in the F0911 table.Burden is the cost that a company incurs as a result of employing people. Burden can include:
Company-paid payroll taxes
Insurance
Fringe benefits, such as union pensions
Direct labor costs, such as small tools
The following conditions must exist for the system to automatically create burden transactions in the workfile:
The Business Unit Burden Flag in the Payroll system must be set to create burden entries in the Burden Distribution File (F0624)
A PDBA must be set up for burden
Company burden distribution rules must be set up
A labor entry must be posted to a billable account in the Account Ledger table (F0911)
The burden accounting entries must also be posted to a billable account in the Account Ledger table (F0911)
The Bill Burden field in the Billing System Constants table (F48091) must be set to process burden
You use a billing constant to control whether burden entries from the Payroll system are processed for the workfile. The system calculates burden transactions when payroll journal entries are created. The only way you can process burden within the billing system is in conjunction with its associated labor workfile transaction.
The eligibility code for burden transactions must be compatible with the eligibility code for the associated labor workfile transaction. Specifically, the system prevents the eligibility code for a labor workfile transaction from being more restrictive than the eligibility code of its burden workfile transactions.
For example, if the burden transaction for a labor workfile transaction is eligible for revenue and invoicing, but the labor workfile transaction is eligible only for invoicing, the system overrides the burden transaction eligibility code with the labor workfile transaction eligibility code.
The Payroll system calculates the following types of burden:
| Burden | Description |
|---|---|
| Actual burden | The actual cost of payroll taxes, insurance, and fringe benefits. The system calculates the burden for the actual costs that are associated with each employee's timecard. |
| Flat burden | An estimated burden amount that the system derives from the direct labor costs. The system calculates the burden on a timecard-by-timecard basis as a percentage of the labor costs. |
When burden transactions are associated with a labor workfile transaction, the system displays an X in the Burden (B) field for that workfile transaction on the Workfile Revisions form. You use the Burden Info option in Workfile Revisions to view these workfile transactions.
After the original payroll transactions have been processed, the system does not retrieve any new burden transactions calculated for the transactions. For example, if you reverse the flat burden amount and calculate the actual burden amount for the original payroll transactions, the system does not retrieve the new burden transactions.
A component is a type of markup. The system calculates component transactions based on amounts or units from source transactions. For example, you might create a component transaction to offset the cost of borrowing money.
You can use component transactions based on the invoice amount to apply charges in addition to the markup amount for the workfile transaction. A compound component creates an additional markup; its calculation is based on existing component amounts.
You set up the rules for component calculations in the Component Table Master table (F4860). You must then assign this component rule to a markup rule in the Cost Plus Markup table to instruct the system to create component transactions.
When a component transaction is associated with a workfile transaction, the system displays an X in the Component (C) field for that workfile transaction on the Workfile Revisions form. You use the Component Info option within Workfile Revisions to view the component workfile transactions.
The workfile transactions can share a parent/child relationship under the following conditions:
| File | Description |
|---|---|
| Workfile transaction/Component workfile transaction | This parent / child relationship exists when component transactions are created for a workfile transaction. |
| Labor/Burden | This parent / child relationship exists when the burden associated with labor is stored in the workfile. |
| Burden/Components | This parent / child relationship exists when component transactions are created for burden transactions. |
You can view the following transactions in the workfile:
Workfile transactions are copies of source transactions from the Account Ledger that represent the billable costs for your company.
Burden transactions are workfile transactions that represent the cost over and above the direct labor wages or salaries that a company incurs as a result of employing people. Burden transactions might include:
Company-paid payroll taxes
Insurance
Fringe benefits, such as union pensions
The billing system always processes burden transactions in conjunction with the associated labor workfile transactions.
Component transactions are special types of workfile transactions that represent additional amounts that you add to the original costs when you invoice a customer. For example, component transactions might be used to offset the cost of borrowing money.
The billing system always processes component transactions in conjunction with associated workfile transactions.
The system assigns eligibility codes to workfile transactions based on the Billable Y/N field in the Account Master table and the Journal Generation Control option that you set up in your Billing Constants.
Note:
The value stored in the eligibility code field specifies the amounts that are displayed and the billing processes in which the workfile transaction can participate. The system assigns the following eligibility codes to the workfile transactions:0 – The workfile transaction is eligible for invoicing, revenue recognition, and costing processes.
1 – The workfile transaction is eligible for invoicing processes.
2 – The workfile transaction is eligible for revenue recognition and costing processes.
3– The workfile transaction is nonbillable.
4 – The workfile transaction is eligible for cost processing only.
For example, if the Billable Y/N field for an account is set to Y (Billable) and the Journal Generation Control option selected is Revenue Recognition and Invoicing without Reconciliation, then the eligibility code is set to 0, indicating that the workfile transaction is eligible for invoicing, revenue recognition, and costing. If the same account with a Y in the Billable Y/N field is processed through the billing system and the Journal Generation Control option selected is Invoice Only, then the eligibility code is set to 1, indicating that the workfile transaction is eligible for invoicing only.
The following table illustrates the system logic used to assign the eligibility codes:
| Account Master - Bill Y/N | Billing Constants - Journal Creation | Billing Workfile - Eligibility Code Assigned |
|---|---|---|
| N (Nonbillable) | Not Applicable | No workfile transaction created |
| Y (Billable) | 1 (Invoice Only) | 1 (Invoice Only) |
| Y (Billable) | 2 (Revenue Only) | 2 (Revenue Only) |
| Y (Billable) | 3 (Inv/Rev w/o Reconciliation) | 0 (Invoicing and revenue) |
| Y (Billable) | 4 (Inv/Rev with Reconciliation) | 0 (Invoicing and revenue) |
| 1 (Invoice Only) | 1 (Invoice Only) | 1 (Invoice Only) |
| 1 (Invoice Only) | 2 (Revenue Only) | No workfile transaction created |
| 1 (Invoice Only) | 3 (Inv/Rev w/o Reconciliation) | 1 (Invoice Only) |
| 1 (Invoice Only) | 4 (Inv/Rev with Reconciliation) | 1 (Invoice Only) |
| 2 (Revenue Only) | 1 (Invoice Only) | No workfile transaction created |
| 2 (Revenue Only) | 2 (Revenue Only) | 2 (Revenue Only) |
| 2 (Revenue Only) | 3 (Inv/Rev w/o Reconciliation) | 2 (Revenue Only) |
| 2 (Revenue Only) | 4 (Inv/Rev with Reconciliation) | 2 (Revenue Only) |
| 4 (Costing only) | 1 (Invoice Only) | 4 (Costing only) |
| 4 (Costing only) | 2 (Revenue Only) | 4 (Costing only) |
| 4 (Costing only) | 3 (Inv/Rev w/o Reconciliation) | 4 (Costing only) |
| 4 (Costing only) | 4 (Inv/Rev with Reconciliation) | 4 (Costing only) |
When you revise workfile transactions, the system sequentially numbers the workfile transactions and each new revision for audit purposes.
You can use these numbers to track the progression of revisions to original workfile transactions. The system assigns each workfile transaction the following control and sequence numbers:
| File | Description |
|---|---|
| Billing Control ID (BCI) | The BCI number is assigned at the time the workfile transaction is first created in the Billing Workfile. The system uses Next Numbers for System 48 and Index 2 (Billing Control) to derive the number. The BCI number of a workfile transaction never changes, regardless of the revisions made to the workfile transaction. If you split a workfile transaction, the resulting workfile transactions will share the same BCI. |
| Sequence Number (SBSQ) | The sequence number of the original workfile transaction is always 1. The sequence number changes only when you split the workfile transaction. The system assigns the next available sequence number within that BCI series to the resulting workfile transactions. For example, the first time a workfile transaction is split, the sequence numbers assigned to the resulting workfile transactions are 2 and 3. If you split one of those workfile transactions, the sequence numbers assigned to the resulting workfile transactions are 4 and 5. |
| Parent Sequence Number (PRSQ) | The parent sequence number of the original workfile transaction is always 0. The parent sequence number changes only when you split the workfile transaction. The system assigns a parent sequence number to workfile transactions that result from a split. The parent sequence number is always the sequence number of the workfile transaction that you split. For example, if you split a workfile transaction with a sequence number of 1 and a parent sequence number of 0, the system assigns the resulting workfile transactions a parent sequence number of 1. |
| Secondary Sequence Number (SCSQ) | The secondary sequence number of the original workfile transaction is always 1. The secondary sequence number tracks the number of revisions you make to a workfile transaction. You can use this number to track the progression of revisions to original workfile transactions. For example, you might revise a workfile transaction three times. The secondary sequence number of the workfile transaction you revise is 1. After the revision, the secondary sequence number for the workfile transaction is 2. When you change the transaction again, the secondary sequence number is 3. When you split a workfile transaction, the secondary sequence numbers will be 1 on the resulting workfile transactions. |
| Component Link Number (CLNK) | The component link number of the workfile transaction links the parent workfile transaction to the child component transactions. If this number is 0, no components exist for this workfile transaction. The component link number changes when you split a workfile transaction with components. The system assigns a new component link number to each resulting parent workfile transaction. This new component link number is then assigned to the respective component workfile transactions. |