About Job Costing
Job Costing allows you to trace and analyze actual cost for a job in the general ledger, and to update cost of
sales with this actual cost when the job is finished. A job is defined as a minor project.
This document aims to give the reader a sufficient conceptual understanding of how Job Costing works in IFS, and
what can be achieved by setting up the application in different ways. Also offered are four scenarios describing
how the effect of different accounting setups in IFS.
Job Costing is not a component of its own in IFS. Instead, Job Costing utilizes functionality in other
components in order to fulfill its tasks. Even though most components in IFS can be said to be influenced by Job
Costing, or to influence Job Costing themselves, only a few are really central to the functioning of Job Costing.
In this section, we will describe these central components and building blocks, and their roles in making Job
Costing work. A brief description of the basic flow through IFS regarding Job Costing is also presented.
General Ledger
The functionality in the general ledger is really central in Job Costing, both for analysis and for setting up
basic data. Job costing utilizes the project functionality that is available in the general ledger, such that a job
is treated as a financial project.
Since the job should be created automatically when initiated from customer order line, all the required
information is stored in templates using the project group functionality. When the job is created, it is handled as
a project. The financial analysis of a job or a group of jobs is done in either balance analysis or project
analysis. It is not different from the normal project follow-up, however it is of course possible to separate jobs
from projects.
A job should be closed once it is finished. The close job functionality uses the close project functionality in
the General Ledger. A job can be closed directly from a special page in the General Ledger.
Accounting Rules
Accounting rules play a central role on how Job Costing works and what can be analyzed in the general ledger.
However, there are no special features in accounting rules regarding Job Costing. Job Costing only requires that
accounting rules are set up in a specific way.
DOP
There is a one-to-one relationship between a DOP header and a Job (financial project). The DOP holds together
all purchasing and manufacturing for a single job via the DOP structure, and the inheritance of pre-accounting
information throughout the structure. DOP can also be used for a deep and thorough analysis of a single job.
Purchase Order & Shop Order
Purchase order and shop order play a central role in Job Costing since it is their transactions that form the
foundation for the financial follow-up of jobs. The ordinary transactions, however, inherit the Job ID from DOP in
one code part in the pre-accounting.
Customer Order
Because every job is initiated from a customer order line and the customer order line's pre-accounting is
inherited through the DOP-structure, all transactions are related to the job. Thus, if the pre-accounting on the
customer order line is wrong, basically every transaction will be posted incorrectly. In addition, since the job
cannot be closed until the part on the customer order line is delivered and invoiced, the customer order also
determines whether a job can be closed.
Basic Flow in Job Costing
The basic flow involves creating a job on a customer order line, releasing the customer order, and creating a
DOP Header. The prerequisite to create a job is the creation of the job template in the general ledger. The
customer order must be in the Planned status, and the part must be a DOP supplied part. A previously created DOP
structure can only be connected to a customer order line that is job-connected if the status of the DOP header is
Created or Unreleased.
The next stage in the Job Costing flow is to handle manufacturing of the DOP part. This can be done by first
creating the DOP structure, then, if needed, netting quantity to a DOP Order and releasing the DOP structure. The
netting and not reserving the quantity will cause the system to generate transactions since material will either be
connected to the Job or unconnected by these actions. Then, the sales part is manufactured by executing the pegged
orders. Once the DOP structure is manufactured, the sales part will be reserved for the specific customer order
line and the sales part can be delivered to the customer. The job functionality will affect all transactions
created during the manufacturing process. All transactions will be marked with the Job ID, enabling the actual cost
for a job to be traced in the general ledger. The actual cost can be calculated and viewed in DOP. Please note that
the actual cost in the general ledger and DOP might differ due to one of the following reasons:
- Transactions from Inventory/Shop Order have not yet updated the accounts in the general ledger. This effect
will cease when the job is closed.
- Other indirect costs have been directly entered on the job in the general ledger.
When the customer order is delivered and invoiced, the job can now be closed. To do this, a balancing takes
place in the general ledger wherein cost of sales is calculated. You can close a job from different places in the
system. One method is to use the Close Job command in the Operations menu on the customer order
line. Other methods include manually closing a job, or after-schedule closing of all jobs that are possible to
close at the moment. This can be done in IFS Financials. The job can be closed when all actual costs for the job
are registered. This is done when:
- All included purchase orders have matched invoices.
- All transactions generated for the job is transferred to the general ledger.
You can manually close the job at any time, although doing so may result in an incorrect job sales cost.
Basic Setup in General Ledger
All basic data concerning a Job is handled in the project functionality within General Ledger. Since Job costing
uses project functionality, most of the basic data is common for Jobs and financial projects.
Job Series / Project Series
All jobs will be given a Job ID from a number series for identification purposes. The number series is defined
by a prefix (2 characters) and a start value (maximum 7 characters). The Job ID will be automatically generated as
the next available number from this series. The recommendation is to use a prefix which easily identifies this as a
Job. Please also note that if IFS Project is used parallel to job costing, it is important not to give projects
Project IDs that start with the same two characters as the prefix in the Job number series.
Job Template / Project Group
All jobs are created automatically when initiated from the customer order line. In order to enable this, some
default data is required for the creation which is handled via templates in the Project Group page. In the
template, define the name of the project group, the project type which should be of the type capitalize
expenditure, the project series (job series) to use, and the account to which cost of goods sold should be posted
when closing the job. In the Job Information tab, define which user group and voucher
type should be applied when automatically closing a job. Furthermore, indicate whether this project group should be
the default for Jobs, and if you want the job automatically closed after the customer order line has been finally
invoiced.
Job Detail / Project Detail
Once a job is created, you can view basic information on this in the Financial Project
page, similar to any ordinary project. However, there is additional information for the job in a separate tab.
Automatic Posting Rule
Depending on how you wish to follow up the cost of a job in the general ledger, there might be a requirement of
an automatic posting rule which goes into action every time an inventory transaction is updated to the General
Ledger. The different scenarios and the impact of the various transactions are described in Financial Follow-Up
of Jobs. This section describes the two rules which might be necessary.
Job Inventory, Scenario 2
If you want to have a separate Job Inventory in the general ledger, you must prepare an
automatic posting rule which will transfer all job-related materials from ordinary inventory to the Job
Inventory. This is best described in the following example:
- Inventory account is 1400
- Job inventory account is 1410
- Job number series has the prefix JC
- Five code parts are used in the code string
- Job ID is posted in code part C
The original code string to trigger on would then be (in which * = the same part value as the original
posting):
| Account |
Cost Center |
Job ID |
Code D |
Code E |
| 1400 |
% |
JC% |
% |
% |
The original posting should be reversed and the new posting should be defined as follows:
| Account |
Cost Center |
Job ID |
Code D |
Code E |
| 1410 |
* |
* |
* |
* |
Full Follow-up of All Job Costs, Scenarios 3 & 4
If you want to have a full follow-up of all costs related to the job in the project analysis in general ledger,
prepare an automatic posting rule which transfers all job-related inventory transactions to a generic� cost
account. This is best described in the following example:
- Inventory account is 1400
- Generic cost account is 4029
- Job number series has the prefix JC
- Five code parts are used in the code string
- Job ID is posted in code part C
The original code string to trigger on would then be (in which * = the same part value as the original
posting):
| Account |
Cost Center |
Job ID |
Code D |
Code E |
| 1400 |
% |
JC% |
% |
% |
The original posting should be reversed and the new posting should be defined as follows:
| Account |
Cost Center |
Job ID |
Code D |
Code E |
| 4029 |
* |
* |
* |
* |
Basic Setup in Accounting Rules
Because there is no specific job functionality in Accounting Rules, this section will describe how to set up
different rules in Accounting Rules to enable Job Costing. For more information on Accounting Rules functionality,
refer to the user documentation on Accounting Rules.
Definition of Code String
Job Costing is based on project functionality, and consequently one code part must be defined with the code part
function Project Accounting.
Pre-Accounting
The follow-up in both accounts in the general ledger, and the project analysis in the general ledger, is based
on the Job ID. Therefore it is essential that the Job ID is part of the code string on all postings which are
related to the job. This is primarily achieved by using the pre-accounting functionality.
Posting Control
This short section on posting control is aimed as a reminder of some important issues concerning posting control
and what has to be set-up in order to have job costing functioning as desired. This is by no means a complete guide
on how to set-up posting control. Thus, the information here is very brief. If you require more information on
posting control and on how to set things up, please refer to the user documentation.
Pre-accounting in distribution and manufacturing: Pre-accounting must be made available by defining it in
posting control, so as to have it available for all transactions generated in DOP, Shop Order, Purchase Order,
Customer Order, etc. This is defined by using posting types M100 to M113.
Variances: Please note that there are a number of new posting types in order to handle the split of
variances in shop order. Posting types M120 to M137.
Inventory transactions and work in progress: Posting type M1 (inventory transactions) and M40 are central
to setting up job costing.
Project accounting: The accounting for the capitalization of a project cost has to be defined, and this
is done by using posting type GP3.
Initiating a Job
A job is always initiated from a customer order line. The basic flow involves creating a job on a customer order
line, releasing the customer order, and creating a DOP Header. The customer order must be in the
Planned status, and the part must be a DOP supplied part. A previously created DOP structure can
only be connected to a customer order line that is job-connected and if the status of the DOP header is
Created or Unreleased.
When initiating the job, a job/project is created in the general ledger based on the template information. You
can only overwrite the template information regarding the closing of the job, i.e., whether this should be done
automatically or otherwise when running the final invoicing of the customer order line.
Closing a Job
Closing a job is the last action that should be done to a job except for various forms of analysis. The closing
of the job will update the general ledger such that the cost of goods sold is moved from the work in progress
account to the appropriate cost account/s. The closing can be done either manually or as a scheduled batch job. The
customer order line must, however, be invoiced before closing the job. When done manually, you will receive
information if all transactions follow a certain condition that determines whether cost of goods sold will be
correctly updated or not. The information will tell you:
- Whether all manufacturing transactions have been transferred to the hold table in accounting rules.
- Whether all inventory transactions have been transferred to the hold table in accounting rules.
- Whether all purchase orders are fully invoiced and matched.
- If the general ledger has been updated with the transactions in the hold table.
You can ignore the information and close the job even if all transactions have not been updated yet to the
general ledger; however, the cost of goods sold will be incorrect. When scheduled and done automatically by the
application, all the above must be fulfilled before the batch job closes the job.
Please note the following concerning a job and job closings:
- When reporting manufacturing time for a shop order in Shop Floor Reporting, no transactions are created
before the time is authorized. This means that the Shop Order can be received and closed without any cost for
reported time. If closing a job includes such a shop order, no cost for the reported time will be included in the
total cost for the job at the time of closing. However, when the time transactions are created, the cost of the
job will be updated in DOP but not included in the Cost of Sales for the job.
- If transactions are manually posted to a job after it has been closed, these costs will not be included in
the Cost of Sales for the job.
Financial Follow-Up of Jobs
This section gives some general information on the follow-up and some fundamental rules which apply to job
costing. In addition, we present three possible scenarios on setting up the application to obtain different levels
of analysis in the general ledger.
Please note that you can perform a detailed follow-up in DOP or directly on related shop orders, regardless of
how you set up the accounting. However, while the follow-up in general ledger can be done on one or more jobs
altogether, the follow-up in DOP is always done per job and in shop order as a part of a job.
To easily follow the explanations on the different set-up's impact on the financial follow-up, see the
example in Financial Follow-Up of Jobs. For ach scenario, an explanation is provided on how the
events/transactions will impact this. Each scenario also has an Excel file describing how all transactions are
posted and what the different account balances are after each step.
General
Depending on how you want to follow up your jobs in the general ledger, you can set up the accounting rules and
other rules differently and achieve different follow-up possibilities. There are two main places in general ledger,
namely balance analysis and project analysis, and one in DOP with the tab costing in the DOP header to do the
financial follow-up on a job. There are, however, some fundamentals which apply no matter how the accounting rules
are set up and where the follow-up is done:
- The balance analysis in general ledger will catch any transaction which has the Job ID in its code
string.
- The project analysis in general ledger will catch any cost or revenue transaction which has the Job ID in its
code string, i.e., transactions that only involve balance accounts that will not show up as project costs.
- Job costing can only be run when using either standard cost or weighted average value as the inventory
valuation method. It is not advisable to use transaction based or periodic weighted average as supplier invoice
consideration.
- All inventory transactions for DOP-parts are done at inventory value. The actual cost is caught through
variances calculated at supplier invoice matching and closing of shop orders.
- All inventory transactions of standard parts are done at inventory value.
- All operations on a shop order are done at standard cost but at the actual quantity.
- If a job has an excess of one or more parts, these can either be put into inventory or used by another job.
The general principle here to handle the cost is that the original job will carry any cost/revenue (i.e.
variances) which is linked to the part, while standard inventory or the new job will carry the cost of the
part at inventory value. The only new transactions specifically made to support job costing are these
transactions transferring these costs.
- Costs which are not part of the purchasing process or manufacturing process will not be available in the DOP
analysis of the job, but rather in the general ledger and project analysis.
- There might be differences between DOP analysis and analysis in the general ledger due to timing on an
ongoing job, i.e., the general ledger might not be updated with all the latest transactions.
Example
The example shows a simple Job, JC1, with two activities:
- Activity 1, a purchasing activity (purchase order)
- Activity 2, a manufacturing activity (shop order)
In addition to these activities, there is a purchase of standard parts just to show the difference in
postings.
The company in the example uses standard cost for valuation of the inventory.
We have the following eight steps in the example:
- A purchase of standard parts for a total standard cost of 30. The purchase is received into inventory and
then invoiced but now at a total cost of 35.
- A purchase of Job specific parts (DOP-parts) at a total standard cost of 20. The purchase is received into
inventory and then invoiced and matched but now at a total cost of 26. The price variance is capitalized.
- Standard parts are issued to the shop order for a total standard cost of 10.
- Job specific parts (DOP-parts) are issued to the shop order for a total standard cost of 20 (i.e. all of the
purchased articles purchased in event 2).
- Refinement costs of labor at a cost of 12 and overhead at a cost of 8 are reported.
- The shop order is received at a standard cost of 45. This gives a total variance of 5 which is split into
labor 3 and OH 2.
- The customer order is shipped.
- The Job is closed
Example in Excel Files: Each scenario below is also presented in an Excel file. The Excel files are
called: Scenario 1; Scenario 2, Scenario 3 and Scenario 4. Each file contains the following
tabs:
- Accounting balance step 1 and 2, i.e., a presentation of what the balance analysis would show after steps 1
and 2.
- Accounting balance step 3 and 4, i.e., a presentation of what the balance analysis would show after steps 3
and 4.
- Accounting balance step 5 and 6, i.e., a presentation of what the balance analysis would show after steps 5
and 6.
- Accounting balance step 7 and 8, i.e., a presentation of what the balance analysis would show after step 7s
and 8.
- Project balance step 1 and 2, i.e., a presentation of what the project analysis would show after step 1s and
2.
- Project balance step 3 and 4, i.e., a presentation of what the project analysis would show after steps 3 and
4.
- Project balance step 5 and 6, i.e., a presentation of what the project analysis would show after steps 5 and
6.
- Project balance step 7 and 8, i.e., a presentation of what the project analysis would show after steps 7 and
8.
- Transactions, i.e., a presentation of all transactions generated in the scenario. Each transaction is
presented with a reference to the scenario description in each Chapter 7.x.x.1 below. Furthermore, there is a
reference to which posting type, posting rule, or function that the posting originates.
General
The objective of setting up the application following this scenario is to catch all job-related costs at the
time they occur, and post them to the job in such a way that it is easy to do a proper follow-up at any given time.
Material is not considered as a cost, however, until it is issued to a shop order when the cost is posted directly
to the WIP account, i.e., there are no possibilities to follow-up material costs in the project analysis during the
lifetime of the job. When the job is closed, these costs will show up as cost of goods sold (std). Please note that
transactions to the WIP account in this scenario would be handled similarly as when job costing is not applied.
This setup could be useful when there is a large number of jobs, and the jobs are generally quite small both in
value and calendar time, and there is not a direct follow-up in general ledger during the lifetime of the job. All
follow-ups during the lifetime is sufficiently handled in DOP and the follow-up in general ledger is only done
afterwards.
Accounts and Posting control
Normal posting control should be set up, with inventory transactions always going directly to the inventory and
WIP-transactions always going directly to the WIP account.
A specific account for job-related cost of sales is required. This will be the account used when a job is
closed.
Automatic Posting Rule
There is no requirement of an automatic posting rule.
Balance and Project Analysis
The following will be possible to see in project analysis and balance analysis after each main step in the
example.
(Please note that this is only a brief overview of what is possible to analyze in the general ledger and project
analysis, and the only intention is to give the reader an understanding of the effects of setting up the accounting
this way).
After step 1
- Balance analysis will show an inventory value of 30 and a price variance of 5. No job inventory value since
only standard parts have been purchased so far.
- Project analysis will show a project cost of 0 since no job specific activities has taken place. The price
variance only concerns standard parts with no relevance to the specific job.
After step 2
- Balance analysis will show an inventory value of 50, a WIP of 6, and a price variance of 5.
- Project analysis will show a price variance of 6 as the only cost on the job so far.
After step 3
- Balance analysis will show an inventory value of 40 after the issuing of standard parts at a value of 10. WIP
will be at 16. Price variance remains at 5.
- Project analysis will show a price variance of 6 as the only cost on the job so far.
After step 4
- Balance analysis will show an inventory value of 20 after the issuing of DOP parts of 20. WIP will be 36 as a
consequence. Price variance remains at 5.
- Project analysis will show a price variance of 6 as the only cost on the job so far.
After step 5
- Balance analysis will show WIP of 56 after adding refinement costs of a total of 20. Inventory remains at 20
and price variance remains at 5.
- Project analysis will show a price variance of 6 as the only cost on the job so far.
After step 6
- Balance analysis will show an inventory of 65 and a WIP of 11 after the receipt and closing of the shop
order. Please note that all variances remain as WIP and do not get posted to inventory. Price variance remains at
5.
- Project analysis will show a price variance of 6, labor variance of 3 and general OH variance of 2 totaling
11.
After step 7
- Balance analysis will show WIP of 56 after the part on the customer order line is shipped. Inventory is 20
and price variance remains at 5.
- Project analysis will show a price variance of 6, labor variance of 3, general OH variance of 2, and a
standard cost of goods sold of 45 totaling 56.
After step 8
- Balance analysis will show a cost of goods sold (Job) of 56. Inventory remains at 20 and price variance
remains at 5.
- Project analysis will show exactly the same as after step 7 since the closing of the job in itself does not
incur any costs to the job, i.e., a price variance of 6, labor variance of 3, general OH variance of 2, and a
standard cost of goods sold of 45 totaling 56.
Transactions
The following transactions will be generated at each step in the example to achieve the above analysis:
- The purchase of standard parts will be posted at arrival to the inventory account at standard cost, and then
the price variance will be posted to the price variance account at the matching of the invoice.
- The purchase of DOP parts (job specific parts) will be posted at arrival to the inventory account at standard
cost; the price variance will be posted to the price variance account at the matching of the invoice; and the
price variance will automatically be transferred to the WIP account (capitalization of costs). This posting is
handled by the project functionality in general ledger.
- Standard parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost; the cost of the standard parts will automatically be transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger.
- The DOP parts which are issued to the shop order will be posted from the inventory account to the WIP account
at standard cost.
- Refinement costs will be posted to the job cost account when reported (shop order transactions), and then the
counter-postings in the example are posted as “Internally distributed cost� since
they depend on the user setup and they are of no relevance for this example. After that, the refinement costs
will automatically be transferred to the WIP account (capitalization of costs) (this posting is handled by the
project functionality in general ledger).
- The shop order is closed. This receipt results in an inventory transaction at standard cost, a project cost
credit of the full cost of the shop order and variances which are posted to different accounts depending on which
cost buckets have been used on the shop order. In the example we have used labor variance and general OH
variance. These postings are controlled by new functionality in the shop order and new control types/posting
types. Then the variance postings will automatically be transferred to the WIP account (capitalization of costs).
These postings is handled by the project functionality in general ledger.
- The part on the customer order line is shipped, resulting in a posting from Inventory to cost of sales at
standard cost for the parts shipped. After that, the standard cost for the parts shipped will automatically be
posted to the WIP account (capitalization of costs). This posting is handled by the project functionality in
general ledger.
- The customer order is invoiced and the job is closed. The accumulated cost will then be posted to the
specified cost of sales account for closing (defined on the Job in general ledger via the Job template). This
reversal will be handled by the project functionality in general ledger.
General
The aim of setting up the application following this scenario is to catch all job-related costs at the time they
occur, and post them to the job in such a way that it is easy to do a proper follow-up at any given time. Material
is not considered as a cost, however, until it is issued to a shop order. In order to still be able to separate
job-specific material on a separate account, however, financial job inventory has been set up for all materials
which is part of a DOP structure.
This setup could be useful when there is a smaller number of jobs, and the jobs generally are a little larger
both in size and calendar time, and there is a direct follow-up in general ledger during the lifetime of the
job.
Basic Setup for the Job Template
The job template should be set up such that the reversal transactions at the closing of the job are posted to
the account Cost of goods sold (Job).
Accounts and Posting Control
In order to obtain the ideas in this scenario, WIP transactions should be posted to the general job cost account
instead of directly to the WIP account. This is done by using the control type C56 on the posting type M40. Control
type values are ISDOP or NOTDOP�.
A specific account for job-related cost of sales is required. This will be the account used when a job is
closed.
Automatic Posting Rule
There should be an automatic posting rule that transfers any inventory transaction related to a job from the
ordinary inventory account to the job inventory. Please refer to Job Inventory, Scenario 2, for details on
how this rule should be set up.
Balance and Project Analysis
The following will be possible to view in project analysis and balance analysis after each main step in the
example. Only accounts which have been affected by the step in question will be commented on for the balance
analysis. On the other hand, project analysis isalways fully commented on since this should be a specification of
the WIP-account at any given point in time.
(Please note that this is only a brief overview of what is possible to analyze in the general ledger and project
analysis, and the only intention is to give the reader an understanding of the effects of setting up the accounting
this way).
After step 1
- Balance analysis will show an inventory value of 30 and a price variance of 5. There are no job inventory
values since so far only standard parts have been purchased.
- Project analysis will show a project cost of 0 since no job specific activities has taken place. The price
variance only concerns standard parts with no relevance to the specific job.
After step 2
- Balance analysis will show a job inventory value of 20 and a WIP of 6.
- Project analysis will show a price variance of 6 as the only cost on the job so far.
After step 3
- Balance analysis will show an inventory value of 20 after issuance of standard parts at a value of 10. WIP
will be at 16.
- Project analysis will show a general job cost of 10 and a price variance of 6, thus totaling 16.
After step 4 Balance analysis will show a job inventory value of 0 after issuance of DOP parts of
20. As a consequence, WIP will be 36.
Project analysis will show general job cost of 30 and a price variance of 6, thus totaling 36.
After step 5
- Balance analysis will show WIP of 56 after adding refinement costs of a total of 20.
- Project analysis will show general job cost of 50 and a price variance of 6, thus totaling 56.
After step 6
- Balance analysis will show a job inventory of 45 and a WIP of 11 after the receipt and closing of the shop
order. Please note that all variances remain as WIP and do not get posted to inventory.
- Project analysis will show a price variance of 6, labor variance of 3, and general OH variance of 2, thus
totaling 11.
After step 7
- Balance analysis will show WIP of 56 after the part on the customer order line is shipped. Nothing remains in
the job inventory after shipment but it will not show-up in cost of goods sold until the job is closed, i.e., the
WIP account will not be emptied until then.
- Project analysis will show a price variance of 6, labor variance of 3, general OH variance of 2, and a
standard cost of goods sold of 45, thus totaling 56.
After step 8
- Balance analysis will show a cost of goods sold (Job) of 56.
- Project analysis will show exactly the same as that after step 7 since the closing of the job in itself does
not incur any costs to the job. Specifically, there is a price variance of 6, labor variance of 3, general OH
variance of 2, and a standard cost of goods sold of 45, thus totaling 56.
Transactions
The following transactions will be generated at each step in the example to achieve the above analysis:
- The purchase of standard parts will be posted at arrival to the inventory account at standard cost, and then
the price variance will be posted to the price variance account at the matching of the invoice.
- The purchase of DOP parts (job specific parts) will be posted at arrival to the inventory account at standard
cost; the Automatic Posting Rule (APR) will then transfer the inventory transaction to the job inventory account;
the price variance will be posted to the price variance account at the matching of the invoice; the price
variance will automatically be transferred to the WIP account (capitalization of costs). This posting is handled
by the project functionality in general ledger.
- Standard parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost. Next, the cost of the standard parts will automatically be transferred to the WIP
account (capitalization of costs). This posting is handled by the project functionality in general ledger.
- The DOP parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost. Second, the cost of the DOP parts will be automatically transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger. Third, the
Automatic Posting Rule (APR) will then transfer the inventory transaction to the job inventory account.
- Refinement costs will be posted to the job cost account when reported (shop order transactions). The
counter-postings in the example are posted as “Internally distributed cost� since
they depend on the user setup and they are of no relevance to this example. Next, the refinement costs will
automatically be transferred to the WIP account (capitalization of costs). This posting is handled by the project
functionality in general ledger.
- The shop order is closed. This receipt results in an inventory transaction at standard cost, i.e., a project
cost credit of the full cost of the shop order and variances which are posted to different accounts depending on
which cost buckets have been used on the shop order. In the example, we have used labor variance and general OH
variance. These postings are controlled by a new functionality in the shop order and new control types or posting
types. Next, the general job cost credit and the variance postings will be automatically transferred to the WIP
account (capitalization of costs). These postings are handled by the project functionality in general ledger.
Third, the Automatic Posting Rule (APR) will then transfer the inventory transaction to the job inventory.
- The part on the customer order line is shipped. This will result in a posting from Inventory to cost of sales
at standard cost for the parts shipped, and then the Automatic Posting Rule (APR) will then transfer the
inventory transaction to Project Inventory. Next, the standard cost for the parts shipped will be automatically
posted to the WIP account (capitalization of costs). This posting is handled by the project functionality in
general ledger.
- The customer order is invoiced and the job is closed. The accumulated cost will then be posted to the
specified cost of sales account for closing (defined on the Job in general ledger via the Job template). This
reversal will be handled by the project functionality in general ledger.
General
The aim of setting up the application following this scenario is basically the same as that of scenario 2,
except that any purchase of material in this scenario will be treated as cost at delivery. Furthermore, there is no
job inventory. Instead, all job-related inventory transactions are posted to the WIP account via the general job
cost account.
Like scenario 2, this setup could be useful when there is a smaller number of jobs, and the jobs are generally a
little larger both in size and calendar time, and when there is a direct follow-up in general ledger during the
lifetime of the job.
Basic Setup of the Job Template
The job template should be set up so that the reversal transactions at the closing of the job are posted to the
account Cost of goods sold (Job).
Posting Control
In order to obtain the ideas in this scenario, the following steps are required in posting control:
- Inventory transactions for DOP articles should be posted to the general job cost account. This can be
obtained by using a control type on the posting type M1. The control type to be used is dependent on which
attributes are used in the part catalog. The recommendation is to use one of the control types C5 to C9, or C32.
Please note that the use of one of these control types require information that can be entered in the
corresponding attribute in the part catalog.
- WIP transactions should be posted to the general job cost account instead of directly to the WIP account.
This is done by using the control type C56 on the posting type M40. Control type values can either be
ISDOP or NOTDOP.�
A specific account for job-related cost of sales is required. This will be the account used when a job is
closed.
Automatic Posting Rule
There is no need for an automatic posting rule in this scenario.
Balance and Project Analysis
The following will be possible to view in project analysis and balance analysis after each main step in the
example. Only accounts which have been affected by the step in question will be commented on for the balance
analysis. On the other hand, project analysis is always fully commented on since this should be a specification of
the WIP-account at any given point in time.
(Please note that this is only a brief overview of what can be possibly analyzed in the general ledger and
project analysis, and the only intention is to give the reader an understanding of the effects of setting up the
accounting this way).
After step 1
- Balance analysis will show an inventory value of 30 and a price variance of 5. There are no job inventory
values since only standard parts have been purchased so far.
- Project analysis will show a project cost of 0 since no job specific activities have taken place. The price
variance only concerns standard parts with no relevance to the specific job.
After step 2
- Balance analysis will show a WIP of 26.
- Project analysis will show a general job cost of 20 and a price variance of 6.
After step 3
- Balance analysis will show an inventory value of 20 after issuance of standard parts at a value of 10. WIP
will be at 36.
- Project analysis will show a general job cost of 30 and a price variance of 6, thus totaling 36.
After step 4
- Balance analysis will show no changes from step 3.
- Project analysis will show no changes from step 3.
After step 5
- Balance analysis will show WIP of 56 after adding refinement costs of a total of 20.
- Project analysis will show general job cost of 50 and a price variance of 6, thus totaling 56.
After step 6
- Balance analysis will show no changes from step 5.
- Project analysis will show a general job cost of 45 a price variance of 6, labor variance of 3, and general
OH variance of 2, thus totaling 56.
After step 7
- Balance analysis will show no changes from step 5.
- Project analysis will show a price variance of 6, labor variance of 3, general OH variance of 2, and a
standard cost of goods sold of 45, thus totaling 56.
After step 8
- Balance analysis will show a cost of goods sold (Job) of 56.
- Project analysis will show exactly the same as that after step 7 since the closing of the job in itself does
not incur any costs to the job. Specifically, there is a price variance of 6, labor variance of 3, general OH
variance of 2, and a standard cost of goods sold of 45, thus totaling 56.
Transactions
The following transactions will be generated at each step in the example to achieve the above analysis.
- The purchase of standard parts will be posted at arrival to the inventory account at standard cost; the price
variance will be posted to the price variance account at the matching of the invoice.
- The purchase of DOP parts (job specific parts) will be posted at arrival to the general job cob cost account
at standard cost. Next, the cost of the DOP parts will automatically be transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger. Third, the
price variance will be posted to the price variance account at the matching of the invoice. Fourth, the price
variance will be automatically transferred to the WIP account (capitalization of costs). This posting is handled
by the project functionality in general ledger.
- Standard parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost. Next, the cost of the standard parts will be automatically transferred to the WIP
account (capitalization of costs). This posting is handled by the project functionality in general ledger.
- The DOP parts which are issued to the shop order will be posted from the general job cob cost account to the
job cost account at standard cost. Next, the cost of the DOP parts will be automatically transferred to the WIP
account (capitalization of costs). This posting is handled by the project functionality in general ledger.
Note: Since the cost of the DOP part was already transferred to the WIP account in transactions 2b &
2c, the effect of the transactions generated at issue, i.e. 4a, must be offset, and this is done by transaction
4d.
- Refinement costs will be posted to the job cost account when reported (shop order transactions). The
counter-postings in the example are posted as “Internally distributed cost� since
they depend on the user setup and they are of no relevance to this example. Next, the refinement costs will
automatically be transferred to the WIP account (capitalization of costs). This posting is handled by the project
functionality in general ledger.
- The shop order is closed. This receipt results in a general job cost transaction (inventory transaction) at
standard cost, i.e., a project cost credit of the full cost of the shop order and variances which are posted to
different accounts depending on which cost buckets have been used on the shop order. In the example, we have used
labor variance and general OH variance. These postings are controlled by a new functionality in the shop order
and new control types or posting types. Next, the general job cost credit and the variance postings will be
automatically transferred to the WIP account (capitalization of costs). These postings are handled by the project
functionality in general ledger.
Note: Since we cannot get rid of the inventory transaction and the project cost credit, we post these to
the same account. The project functionality in general ledger will automatically transfer these transactions to
the WIP account even though the total effect of transaction 6a is 0.
- The part on the customer order line is shipped. This will result in a posting from general job cost account
to cost of sales at standard cost for the parts shipped. Second, the standard cost for the parts shipped will be
automatically posted to the WIP account (capitalization of costs). This posting is handled by the project
functionality in general ledger. Third, the cost of the DOP parts will be automatically transferred to the WIP
account (capitalization of costs). This posting is handled by the project functionality in general ledger.
Note: Since the objective of this scenario is to keep all job costs in the WIP account throughout the
whole lifetime of the job, the ordinary transaction 7a must be offset, i.e., when the customer order is shipped,
which is done by the third and fourth parts of this transaction.
- The customer order is invoiced and the job is closed. The accumulated cost will then be posted to the
specified cost of sales account for closing (defined on the Job in general ledger via the Job template). This
reversal will be handled by the project functionality in general ledger.
General
The objective of setting up the application following this scenario is basically the same as that in scenario 3.
The difference is that if you cannot separate your M1 transactions using a control type as you have to use
something else. The solution to this is to use the automatic posting rule functionality and to transfer all
inventory transactions from ordinary inventory to the WIP account. This transfer should however be done via the
general job cost account in order to catch the cost in project analysis. Please note that this setup generates a
considerable amount of extra transactions, thus it is highly recommended to use the setup in scenario 3.
The benefits of this setup is the same as that of scenario 3.
Basic Setup of the Job Template
The job template should be set up such that the reversal transactions at the closing of the job are posted to
the account Cost of goods sold (Job).
Posting Control
In order to obtain the ideas in this scenario, the following is required in posting control:
WIP transactions should be posted to the general job cost account instead of directly to the WIP account. This
is done by using the control type C56 on the posting type M40. Control type values can either be
ISDOP� or NOTDOP�.
Automatic Posting Rule
There should be an automatic posting rule that transfers any inventory transaction related to a job from the
ordinary inventory account to the general job cost account. Please refer to Full Follow Up of All Job Costs
Scenarios 3 & 4 for details on how this rule is set up.
Balance and Project Analysis
The account balances and project balances will be exactly the same as in the previous scenario. Therefore, no
comments are made here. Please refer to the balances in scenario 3.
Transactions
The transactions will not be the same as that in the previous scenario on all accounts, thus all transactions
are described in the following.
- The purchase of standard parts will be posted at arrival to the inventory account at standard cost, and then
the price variance will be posted to the price variance account at the matching of the invoice.
- The purchase of DOP parts (job specific parts) will be posted at arrival to the inventory account at standard
cost. Second, the Automatic Posting Rule (APR) will then transfer the inventory transaction to the general job
cob cost account. Third, the cost of the DOP parts will be automatically transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger. Fourth, the
price variance will be posted to the price variance account at the matching of the invoice. Fifth, the price
variance will be automatically transferred to the WIP account (capitalization of costs). This posting is handled
by the project functionality in general ledger.
- Standard parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost, and then the cost of the standard parts will be automatically transferred to the WIP
account (capitalization of costs). This posting is handled by the project functionality in general ledger.
- The DOP parts which are issued to the shop order will be posted from the inventory account to the job cost
account at standard cost. Second, the cost of the DOP parts will be automatically transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger. Third, the
Automatic Posting Rule (APR) will then transfer the inventory transaction to the general job cost account.
Fourth, the cost of the DOP parts will be automatically transferred to the WIP account (capitalization of costs).
This posting is handled by the project functionality in general ledger.
Note: Since the cost of the DOP part was already transferred to the WIP account in the 2nd and 3rd parts
of transaction 2, the effect of the transactions generated at issues 4a and 4b must be offset, and this is done
by the 3rd and 4th parts of this transaction.
- Refinement costs will be posted to the job cost account when reported (shop order transactions). Second, the
counter-postings in the example are posted as “Internally distributed cost� since
they depend on the user setup and they are of no relevance to this example. Third, the refinement costs will
automatically be transferred to the WIP account (capitalization of costs). This posting is handled by the project
functionality in general ledger.
- The shop order is closed. This receipt results in an inventory transaction at standard cost, i.e., a project
cost credit of the full cost of the shop order and variances which are posted to different accounts depending on
which cost buckets have been used on the shop order. In the example, we have used labor variance and general OH
variance. These postings are controlled by a new functionality in the shop order and new control types or posting
types. Second, the general job cost credit and the variance postings will be automatically transferred to the WIP
account (capitalization of costs). These postings are handled by the project functionality in general ledger.
Third, the Automatic Posting Rule (APR) will then transfer the inventory transaction to the general job cost
account. Fourth, the cost of the DOP parts will be automatically transferred to the WIP account (capitalization
of costs). This posting is handled by the project functionality in general ledger.
Note: Since the objective of this scenario is to keep all job costs in the WIP account throughout the
whole lifetime of the job, the ordinary transaction 6a must be offset, i.e., when a shop order is closed, which
is done by the 3rd and 4th parts of this transaction.
- The part on the customer order line is shipped, resulting in a posting from Inventory to cost of sales at
standard cost for the parts shipped. Second, the Automatic Posting Rule (APR) will then transfer the inventory
transaction to the general job cost account. Third, the standard cost for the parts shipped will automatically be
posted to the WIP account (capitalization of costs). This posting is handled by the project functionality in
general ledger. Fourth, the cost of the DOP parts will be automatically transferred to the WIP account
(capitalization of costs). This posting is handled by the project functionality in general ledger.
Note: Since the objective of this scenario is to keep all job costs in the WIP account throughout the
whole lifetime of the job, the ordinary transaction in the 1st part must be offset, i.e., when the customer order
is shipped, which is done by transactions in the 2nd, 3rd and 4th parts of this transaction.
- The customer order is invoiced and the job is closed. The accumulated cost will then be posted to the
specified cost of sales account for closing (defined on the Job in general ledger via the Job template). This
reversal will be handled by the project functionality in general ledger.