Before we turn to specific scenarios, let's begin with a basic overview of how job costing operates in xTuple ERP. For one thing, whenever we talk about job items, we are really, more specifically referring to manufactured items which have an item site with the job costing method defined on it. We discussed this point in the System Administration chapter—and will look at it again more closely in a moment. Meanwhile, here are some other high-level facts about xTuple job costing:
Job items are by definition custom-made items (or services) which are linked to specific sales orders and jobs. As such, they are not maintained in inventory.
The costing for job items is always distinct to a particular sale. Consequently, the cost of job items resides solely in the materials and labor that are posted to the work order for the job. Parent-level job items do not have their own, separate standard cost.
Since the costing for job items is distinct to a particular sale, there is a hard link between job sales orders and job work orders. When a job sales order is shipped, all the costs transfer from the job work order to the cost of goods sold (COGS). This provides you with clear cost-tracking by job.
As we mentioned previously, for an item to be a job costing item in xTuple ERP it must first be a manufactured item. Only manufactured items have access to the job costing method on the Item Site screen. The following screenshot shows the Item master for CTRUCK1, a manufactured item available in xTuple ERP demo databases:
In addition to being a manufactured item, the CTRUCK1 item is also marked as sold. This is an important point to note, because you need the Sold flag to be enabled if you want to enter the job item on a sales order.
You can also see in the screenshot that the item is marked as configured. xTuple ERP supports assemble to order (ATO) configuration through individually-priced item characteristics. When these characteristics are added to sales order line items, the pricing of the item is adjusted accordingly. And when the linked work order is created, the characteristics are also transferred to the work order material requirements list. ATO configuration is not a requirement for the job costing process flow. However, you may find ATO configuration useful, depending on the needs of the jobs you are running. (For more information about ATO in xTuple, please see the Assemble to Order Configurator topic on the xTuple.org community website.)
Once an item has been defined as a manufactured item, you will have access to the job costing method when you define and item site record for the item:
Once you specify the job costing method on the Item Site screen, the item will now be treated as a job item by xTuple ERP. Also, be sure to select the Sold from this Site option on the Item Site screen. Having this option on is another requirement for making it possible to sell job items on a sales order.
Job items are entered on sales orders just like any other sold item would be. You enter a quantity and a unit price, specify a scheduled date:
But as you can see in the example, job items will also have work orders automatically created for them. The link between sales orders and work orders is a fundamental aspect of the xTuple job costing feature set. This linkage is so important, the only way you can post production for and close a job work order is to ship the sales order the work order is related to. Job sales orders and job work orders are thus inseparably connected.
This connection between job sales orders and job work orders is rooted in the fact that job items do not have any standard cost. They are non-inventory items. All their costs are tied up in the materials and labor associated with the job work order. Consequently, when a job sales order is shipped—and the work order is closed—the entire cost of the job is transferred to the cost of goods sold (COGS). In this way, from both a manufacturing and accounting point of view, job items are uniquely tied to particular sales.
The work order that gets created automatically when the job sales order is saved shares the same number as the sales order itself. Having this link between sales order number and work order number further enhances the connection between the two:
If the sales order is linked to a project, then the work order will also inherit the project linkage. But in every other aspect, the work order is just like any other work order for a manufactured item. It contains material requirements and, depending on your xTuple ERP edition, work order operations. And just like any other work order, you will need to issue materials (unless you are backflushing materials) and post labor to the job.
The difference between regular work orders and job work orders comes in when the job is done and you need to post production and close the work order. To enforce the link between job sales orders and job work orders, the only way to post production for and close a job work order is to ship it.
Shipping sales orders is a two-step process. In the first step, you issue stock to shipping. And in the second step you ship the order. The following screenshot shows the G/L transactions flowing from this two-step process for a sample work order:
To understand the example in the screenshot, you have to read the transactions from the bottom-up. In other words, at the bottom the issue to shipping transaction occurs first. This issuing causes the work order materials to be backflushed (i.e., issued to the work order). And then finally, when the sales order is shipped, the entire cost of the work order is transferred out of the work in process (WIP) asset account and into the cost of goods sold (COGS) account.
Keep in mind that if project accounting is enabled on your system, you can run financial reports by project—thus gaining even more detailed insight into the financial aspects of your jobs.
This look into the G/L transactions associated with a sample job order illustrates how the accounting for job costing works.