ITrack/Enterprise/Work Order Accounting

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