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:

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:

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:

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:

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:

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:

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:

Example

The example shows a simple Job, JC1, with two activities:

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:

  1. 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.
  2. 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.
  3. Standard parts are issued to the shop order for a total standard cost of 10.
  4. 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).
  5. Refinement costs of labor at a cost of 12 and overhead at a cost of 8 are reported.
  6. 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.
  7. The customer order is shipped.
  8. 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:

Scenario 1

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

After step 2

After step 3

After step 4

After step 5

After step 6

After step 7

After step 8

Transactions

The following transactions will be generated at each step in the example to achieve the above analysis:

  1. 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.
  2. 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.
  3. 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.
  4. The DOP parts which are issued to the shop order will be posted from the inventory account to the WIP account at standard cost.
  5. 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).
  6. 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.
  7. 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.
  8. 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.

Scenario 2

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

After step 2

After step 3

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

After step 6

After step 7

After step 8

Transactions

The following transactions will be generated at each step in the example to achieve the above analysis:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Scenario 3

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:

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

After step 2

After step 3

After step 4

After step 5

After step 6

After step 7

After step 8

Transactions

The following transactions will be generated at each step in the example to achieve the above analysis.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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. 
  8. 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.

Scenario 4

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.