Difference between revisions of "ITrack/Enterprise/Work Order Accounting"

From ISoft Wiki
Jump to navigationJump to search
(New page: Work orders have a powerful but complicated accounting system. These accounting processes are described in detail here so that account managers can configure ...)
 
 
(12 intermediate revisions by 3 users not shown)
Line 8: Line 8:
Work orders have several GL Contexts used in different situations, depending on the item being accounted and the item being accounted.
Work orders have several GL Contexts used in different situations, depending on the item being accounted and the item being accounted.


* Work Order Production - used by the [[Work Orders (Enterprise)#Master Part|master part record]] on a work order for inventory (not on customer WOs).
* Work Order Production - used by the [[ITrack/Enterprise/Work Orders#Master Part|master part record]] on a work order for inventory (not on customer WOs).
* Work In Progress contexts - these contexts are designed to facilitate moving value into work in progress accounts.  If a company doesn't use work in progress accounts, this context can be left empty.  There are several specific contexts that are used depending on the item in question.
* Work In Progress contexts - these contexts are designed to facilitate moving value into work in progress accounts.  If a company doesn't use work in progress accounts, this context can be left empty.  There are several specific contexts that are used depending on the item in question.
** Work In Progress - used by inventory items (and miscellaneous part items), labor, EPA charges, and shop fees when an open WO is saved.  This context is designed to facilitate moving assets into a work in progress account.
** Work In Progress - used by inventory items (and miscellaneous part items), labor, EPA charges, and shop fees when an open WO is saved.  This context is designed to facilitate moving assets into a work in progress account.
Line 23: Line 23:


==GL Accounting Timeline==
==GL Accounting Timeline==
The following tables show detailed accounting information.  The '''Item''' column describes the object that is being accounted.  '''Timing''' describes the phase the accounting happens in (work in progress or finalization).  '''Table''' is the database table that those objects are stored in.  '''GL Category''' describes the gl category used to retrieve the accounts for accounting (if its in italics, that means the appropriate accounts are stored in the table, probably in the final...glaccountid or wip...glaccountid accounts).  '''Context used''' quickly describes the gl context(s) used for accounting.  WIP means Work In Progress, WOSold is Work Order Sold, and WOConsumed is Work Order Consumed (WIP..., WOSold..., or WOConsumed... mean either the context WIP, WIP Inherent Core, or WIP Dirty Core and so forth depending on the item type).  '''Amount''' describes the value that will be accounted, which is normally the cost of the item for inventory account pairs and price of the item for transaction account pairs.  Columns '''I''' and '''T''' simply describe which account pairs are hit in the accounting: inventory pair, transaction pair, or both.
The following tables show detailed accounting information.  The '''Item''' column describes the object that is being accounted.  '''Timing''' describes the phase the accounting happens in (work in progress or finalization).  '''Table''' is the database table that those objects are stored in.  '''GL Category''' describes the gl category used to retrieve the accounts for accounting (if its in italics, that means the appropriate accounts are stored in the table, probably in the final...glaccountid or wip...glaccountid accounts).  '''Context used''' quickly describes the gl context(s) used for accounting.  WIP means Work In Progress, WOSold is Work Order Sold, and WOConsumed is Work Order Consumed (WIP..., WOSold..., or WOConsumed... mean either the context WIP, WIP Inherent Core, or WIP Dirty Core and so forth depending on the item type).  '''Amount''' describes the value that will be accounted, which is normally the cost of the item for inventory account pairs and price of the item for transaction account pairs.  Columns '''Inventory''' and '''Transaction''' simply describe which account pairs are hit in the accounting: inventory pair, transaction pair, or both.


<table border=1 cellpadding=1 cellspacing=1>
{| class="wikitable" border="1" cellpadding="1" cellspacing="1"
<tr><th>Item</th><th>Timing</th><th>Table</th><th>GL Category</th><th>Context Used</th><th>Amount</th><th>I</th><th>T</th><th>Other Notes</th></tr>
|-
<tr><td>Job Part</td><td>WIP</td><td>jobpart</td><td>''jobpart.glcategory''</td><td>WIP...</td><td>jobpart.averagecost * jobpart.quantity</td><td>X</td><td></td></tr>
! Item
<tr><td>Labor</td><td>WIP</td><td>workclock</td><td>job.glcategory</td><td>WIP</td><td>workclock.cost</td><td>X</td><td></td></tr>
! Timing
<tr><td>Job Part</td><td>Final</td><td>jobpart</td><td>''jobpart.glcategory''</td><td>WOSold... or WOConsumed...</td><td>jobpart.averagecost * jobpart.quantity</td><td>X</td><td></td></tr>
! Table
<tr><td>Labor</td><td>Final</td><td>workclock</td><td>job.glcategory</td><td>WOSold or WOConsumed</td><td>workclock.cost</td><td>X</td><td></td></tr>
! GL Category
<tr><td>Job</td><td>Final</td><td>job</td><td>job.glcategory</td><td>WOSold or WOConsumed</td><td>job.cost</td><td></td><td>X</td><td>Only if the job has a fixed price</td></tr>
! Context Used
<tr><td>Job Part</td><td>Final</td><td>jobpart</td><td>''jobpart.glcategory''</td><td>WOSold... or WOConsumed...</td><td>jobpart.price* jobpart.quantity</td><td></td><td>X</td><td>Only if the job doesn't have a fixed price</td></tr>
! Amount
<tr><td>Labor</td><td>Final</td><td>workclock</td><td>job.glcategory</td><td>WOSold or WOConsumed</td><td>job.laborcharge</td><td></td><td>X</td><td>Only if the job doesn't have a fixed price</td></tr>
! Inventory
<tr><td>EPA Charges</td><td>Final</td><td>job</td><td>EPA GL Category*</td><td>WOSold or WOConsumed</td><td>job.epacharge</td><td></td><td>X</td><td>Only if the job doesn't have a fixed price</td></tr>
! Transaction
<tr><td>Shop Fees</td><td>Final</td><td>job</td><td>Shop Fees GL Category**</td><td>WOSold or WOConsumed</td><td>job.shopfees</td><td></td><td>X</td><td>Only if the job doesn't have a fixed price</td></tr>
! Other Notes
<tr><td>Master Part</td><td>Final</td><td>workorder</td><td>inventory.glcategory</td><td>Work Order Production</td><td>Sum of all job.cost</td><td>X</td><td></td><td>Only if the work order is 'work on inventory'</td></tr>
|-
<tr><td>Master Part</td><td>Final</td><td>workorder</td><td>inventory.glcategory</td><td>Work Order Production</td><td>workorder.price</td><td></td><td>X</td><td>Only if the work order is 'work on inventory'</td></tr>
| Job Part
</table>
| WIP
| jobpart
| ''jobpart.glcategory''
| WIP...
| jobpart.averagecost * jobpart.quantity
| X
|
|-
| Labor
| WIP
| workclock
| job.glcategory
| WIP
| workclock.cost
| X
|
|-
| Job Part
| Final
| jobpart
| ''jobpart.glcategory''
| WOSold... or WOConsumed...
| jobpart.averagecost * jobpart.quantity
| X
|
|-
| Labor
| Final
| workclock
| job.glcategory
| WOSold or WOConsumed
| workclock.cost
| X
|
|-
| Job
| Final
| job
| job.glcategory
| WOSold or WOConsumed
| job.cost
|
| X
| Only if the job has a fixed price
|-
| Job Part
| Final
| jobpart
| ''jobpart.glcategory''
| WOSold... or WOConsumed...
| jobpart.price* jobpart.quantity
|
| X
| Only if the job doesn't have a fixed price
|-
| Labor
| Final
| workclock
| job.glcategory
| WOSold or WOConsumed
| job.laborcharge
|
| X
| Only if the job doesn't have a fixed price
|-
| EPA Charges
| Final
| job
| EPA GL Category*
| WOSold or WOConsumed
| job.epacharge
|
| X
| Only if the job doesn't have a fixed price
|-
| Shop Fees
| Final
| job
| Shop Fees GL Category**
| WOSold or WOConsumed
| job.shopfees
|
| X
| Only if the job doesn't have a fixed price
|-
| Master Part
| Final
| workorder
| inventory.glcategory
| Work Order Production
| workordermasterpart.averagecost + workordermasterpart.averagecorecost
| X
|
| Only if the work order is 'work on inventory'
|-
| Master Part
| Final
| workorder
| inventory.glcategory
| Work Order Production
| workordermasterpart.averagecost + workordermasterpart.averagecorecost
|
| X
| Only if the work order is 'work on inventory'
|}
 
==Tips and Tricks==
* Work in progress accounting isn't required. If you chose not to use it, simply leave those parts of configuration empty.  This will appear to create 'unbalanced' accounting configuration, but essentially the lineitems on the WO will take value out of their specific accounts for the amount of their cost, and the master parts will put the job total amount into its own account, which should balance out.
* If you want to use WIP accounting, make sure you use the same WIP account for all items.  If you have multiple WIP accounts, they will end up with a net value in them because value will get put into Used Parts WIP, and value will be taken out of Vehicles WIP, which are never balanced against each other.
* If you check 'Estimate' on an open WO or void a WO, all current accounting (including WIP accounting) will get backed out and netted to $0.  If this happens on a different day/period than the original document date, its possible you'll end up with corrective entries on a different day.
* If you open and save an existing document that had any accounting errors, the net difference between the correct totals and the current totals will be added to the accounting queue with the current date.  Its possible this will create corrective activity on a different period.
* Changing gl category/context configuration after a WO document has been created/closed may not affect that document.  Recreate the document if you are testing and want to make sure the new settings affect that document.


<br>
<br>
See also: [[Accounting (Enterprise)]]
See also: [[ITrack/Enterprise/Accounting]]
[[Category:Enterprise Concepts]]
 
[[Category:ITrack/Enterprise/Concepts]]

Latest revision as of 12:11, 13 December 2016

Work orders have a powerful but complicated accounting system. These accounting processes are described in detail here so that account managers can configure their GL Categories and GL Contexts appropriately.

Work orders essentially have two stages in their accounting lifetime: work in progress, and finalization. The timing of these stages can vary depending on the WO parameters, such as whether it is a customer WO, or a WO for inventory.

In the work in progress stage, inventory and labor value is moved into appropriate work in progress GL accounts. Then, once a WO has been finalized, value is moved from the work in progress accounts into either inventory value (for work on inventory WOs) or into sales and accounts receivable (for work on customer units).

Pertinent GL Contexts

Work orders have several GL Contexts used in different situations, depending on the item being accounted and the item being accounted.

  • Work Order Production - used by the master part record on a work order for inventory (not on customer WOs).
  • Work In Progress contexts - these contexts are designed to facilitate moving value into work in progress accounts. If a company doesn't use work in progress accounts, this context can be left empty. There are several specific contexts that are used depending on the item in question.
    • Work In Progress - used by inventory items (and miscellaneous part items), labor, EPA charges, and shop fees when an open WO is saved. This context is designed to facilitate moving assets into a work in progress account.
    • Work In Progress Inherent Core - same as above, but used for inherent core charges on inventory items.
    • Work In Progress Dirty Core - same as above, but used for dirty core items.
  • WO Sold contexts - these contexts come into play when a 'work on customer unit' WO gets finalized. One of the following contexts gets used depending on the type of item in question.
    • Work Order Sold - used by inventory items, labor, EPA charges, and shop fees when a 'work on customer unit' WO reaches the final accounting stage.
    • Work Order Sold Inherent Core - same as above, but for inherent cores.
    • Work Order Sold Dirty Core - same as above, but for dirty cores.
  • WO Consumed contexts - these contexts come into play when a 'work on inventory' WO gets finalized. One of the following contexts gets used for WO components' accounting, depending on the type of item in question.
    • Work Order Consumed - used by inventory items, labor, EPA charges, and shop fees when a 'work on inventory' WO reaches the final accounting stage.
    • Work Order Consumed Inherent Core - same as above, but for inherent cores.
    • Work Order Consumed Dirty Core - same as above, but for dirty cores.

GL Accounting Timeline

The following tables show detailed accounting information. The Item column describes the object that is being accounted. Timing describes the phase the accounting happens in (work in progress or finalization). Table is the database table that those objects are stored in. GL Category describes the gl category used to retrieve the accounts for accounting (if its in italics, that means the appropriate accounts are stored in the table, probably in the final...glaccountid or wip...glaccountid accounts). Context used quickly describes the gl context(s) used for accounting. WIP means Work In Progress, WOSold is Work Order Sold, and WOConsumed is Work Order Consumed (WIP..., WOSold..., or WOConsumed... mean either the context WIP, WIP Inherent Core, or WIP Dirty Core and so forth depending on the item type). Amount describes the value that will be accounted, which is normally the cost of the item for inventory account pairs and price of the item for transaction account pairs. Columns Inventory and Transaction simply describe which account pairs are hit in the accounting: inventory pair, transaction pair, or both.

Item Timing Table GL Category Context Used Amount Inventory Transaction Other Notes
Job Part WIP jobpart jobpart.glcategory WIP... jobpart.averagecost * jobpart.quantity X
Labor WIP workclock job.glcategory WIP workclock.cost X
Job Part Final jobpart jobpart.glcategory WOSold... or WOConsumed... jobpart.averagecost * jobpart.quantity X
Labor Final workclock job.glcategory WOSold or WOConsumed workclock.cost X
Job Final job job.glcategory WOSold or WOConsumed job.cost X Only if the job has a fixed price
Job Part Final jobpart jobpart.glcategory WOSold... or WOConsumed... jobpart.price* jobpart.quantity X Only if the job doesn't have a fixed price
Labor Final workclock job.glcategory WOSold or WOConsumed job.laborcharge X Only if the job doesn't have a fixed price
EPA Charges Final job EPA GL Category* WOSold or WOConsumed job.epacharge X Only if the job doesn't have a fixed price
Shop Fees Final job Shop Fees GL Category** WOSold or WOConsumed job.shopfees X Only if the job doesn't have a fixed price
Master Part Final workorder inventory.glcategory Work Order Production workordermasterpart.averagecost + workordermasterpart.averagecorecost X Only if the work order is 'work on inventory'
Master Part Final workorder inventory.glcategory Work Order Production workordermasterpart.averagecost + workordermasterpart.averagecorecost X Only if the work order is 'work on inventory'

Tips and Tricks

  • Work in progress accounting isn't required. If you chose not to use it, simply leave those parts of configuration empty. This will appear to create 'unbalanced' accounting configuration, but essentially the lineitems on the WO will take value out of their specific accounts for the amount of their cost, and the master parts will put the job total amount into its own account, which should balance out.
  • If you want to use WIP accounting, make sure you use the same WIP account for all items. If you have multiple WIP accounts, they will end up with a net value in them because value will get put into Used Parts WIP, and value will be taken out of Vehicles WIP, which are never balanced against each other.
  • If you check 'Estimate' on an open WO or void a WO, all current accounting (including WIP accounting) will get backed out and netted to $0. If this happens on a different day/period than the original document date, its possible you'll end up with corrective entries on a different day.
  • If you open and save an existing document that had any accounting errors, the net difference between the correct totals and the current totals will be added to the accounting queue with the current date. Its possible this will create corrective activity on a different period.
  • Changing gl category/context configuration after a WO document has been created/closed may not affect that document. Recreate the document if you are testing and want to make sure the new settings affect that document.


See also: ITrack/Enterprise/Accounting