Table of Contents

Original cost calculation

This article describes how the original cost is defined for each store transaction (i.e., for each row of a transaction).

There are two ways to define it: by average cost and by specifying the cost in the parent document.

Which way will be used is determined by the business process (procurement, production, transfer, sale) the transaction is created for. It depends on other modules and their respective documents, which are the main documents in the transaction flow.

The Cost source field defines which method is used. For more information, see Goods cost.

Transaction participation

The original cost of a store transaction is determined when the transaction is released.

A previous store transaction participates in the original cost calculation only when all of the following conditions are met:

  1. The transaction is already released when the original cost is calculated.
  2. The transaction precedes the current transaction according to its Transaction Timestamp.
  3. The transaction is for the same Enterprise Company, Store, and Product.
  4. If the Product uses a separate cost per Lot, the transaction is for the same Lot.

Both the release time and the Transaction Timestamp are important.

A transaction with an earlier Transaction Timestamp does not participate if it is released after the original cost has already been calculated.

A transaction that is released earlier does not participate if its Transaction Timestamp is later than the Transaction Timestamp of the transaction being costed.

For more information about the Transaction Timestamp, see Setting Transaction Timestamp.

Evaluation order

The system evaluates the transactions in the following order:

  1. It selects the transactions that are released at the time of the calculation.
  2. It groups the transactions by Enterprise Company, Store, Product, and, when applicable, Lot.
  3. It orders the transactions by Transaction Timestamp.
  4. It calculates the accumulated quantity and cost up to the current transaction.
  5. It applies the specific original cost calculation algorithm according to the Cost Source and transaction type.

If receipt and issue transactions have the same Transaction Timestamp, the receipt transactions are processed before the issue transactions.

For more information about chronological ordering and subsequent recalculation, see Basic algorithm for Cost Correction calculation.

Release time and Transaction Timestamp example

An Inventory Reconciliation receipt has a Transaction Timestamp of 25 July and is released on 28 July.

A Store Transaction for Cost is already released, but its Transaction Timestamp is 27 July.

The Store Transaction for Cost does not participate in the original cost calculation of the Inventory Reconciliation receipt because it is later in the store transaction chronology, even though it was released first.

Conversely, a Store Transaction for Cost with a Transaction Timestamp of 23 July does not participate if it is released after the Inventory Reconciliation receipt has already received its original cost.

Therefore, both conditions must be met:

  1. The preceding transaction must already be released when the original cost is calculated.
  2. Its Transaction Timestamp must precede the Transaction Timestamp of the transaction being costed.

Average cost

It is used when the Cost source field is set to store. These are usually the issue transactions in the store. The only receipt transactions with this source are generated by Reconciliations. Тo define the cost of the current transaction, the following is performed:

  1. All valid store transactions are gathered. They are non-voided or (at least) released transactions and contain the same product, store and enterprise company which date to before the current transaction. The order of the transactions is defined by the transaction timestamp. If there are multiple transactions with the same transaction timestamp, the receipt transactions are ordered before the issue transactions.

  2. The unit cost is defined in all currencies (see Goods cost) from p.1.

  3. The unit cost is multiplied by the quantity in the row and the result is saved as a cost in the current transaction (in all currencies).

Example 1:

For a specified product, store and enterprise company, there are transactions listed below. For issue transactions, the average cost method is used.

In the beginning, there are two receipt transactions:

  • receipt, Timestamp: 01 Dec 2020 12:45, 4 PCS, total cost: 100;

  • receipt, Timestamp: 01 Dec 2020 17:27, 3 PCS, total cost: 61.

These two transactions define the unit cost as (100 + 61) / (4 + 3) = 23. The result is used in the next issue transaction:

  • issue, Timestamp: 03 Dec 2020, 11:29, 5 PCS, total cost: 5 * 23 = 115;

Then, there is a receipt transaction:

  • receipt, Timestamp: 04 Dec 2020 15:33,6 PCS, total cost: 146;

The average cost is (100 + 61 - 115 + 146) / (4 + 3 - 5 + 6) = 24. This cost is used in the next issue transactions. Note that the first issue transaction happens at the same time as the receipt transaction, but the receipt transaction is considered before the issue transaction. Because of this, the cost of the issue transaction is affected:

  • issue, Timestamp: 04 Dec 2020 15:33, 2 PCS, total cost: 2 * 24 = 48;

  • issue, Timestamp: 07 Dec 2020 09:54, 1 PCS, total cost: 1 * 24 = 24.

This example illustrates a case where the product cost is not affected by the presence or absence of a lot. Even if different lots exist in the transactions, the cost is an average. There are products required to have individual costs for each lot (this is described in the product's definition). The principle above is then changed, and in p.1 we take into account transactions that also have a matching lot field. An empty value (no lot) is considered a valid/separate lot.

Example 2:

There is a receipt transaction with two lots (so there are two receipt store transactions):

  • receipt, lot #1, Timestamp: 01 Dec 2020 13:15, 10 PCS, total cost: 120;

  • receipt, lot #2, Timestamp: 01 Dec 2020 12:15, 8 PCS, total cost: 96.

The unit cost for both lots is 12. Then come the following issue transactions:

  • issue, lot #1, Timestamp: 01 Dec 2020 14:28, 3 PCS, total cost: 3 * 12 = 36.

The next receipt transaction is only for lot #1:

  • receipt, lot #1, Timestamp: 02 Dec 2020 10:30, 7 PCS, total cost: 98;

Now lot #1 has a unit cost of (120 - 36 + 98) / (10 - 3 + 7) =13, while the second lot has a unit cost of 12.

  • issue, lot #1, Timestamp: 05 Dec 2020 17:20, 4PCS, total cost: 4 * 13 = 52;

  • issue, lot #2, Timestamp: 05 Dec 2020 11:12, 5 PCS, total cost: 5 * 12 = 60.

Specifying the cost explicitly

This is used when the cost source is set to "Document". This is the source of all receipt transactions, except for the ones generated by Reconciliation. For each receipt transaction, the cost is calculated separately and according to a formula/calculation that is specific to the current business process. The method involves calculating a number in the document currency (the cost is in only one currency). Then, this number is converted into the rest of the cost currencies (see Goods cost).

A more complicated example is when the cost of the goods is defined by the issue transaction cost of other goods available in the same enterprise company. It is not required to receive the goods from the same store. When transferring goods from one store to another, the issue transaction has a standard average cost. However, the goods received in the second store have to be entered with a cost equal to the one from the first store issue (a greater cost may be set if there are transport or other expenses). The same principle is applied when returning sold goods from a client or receiving back a rented asset.

Another example is the production, where the cost of the produced products is formed by the costs of the ingredients, salary expenses, and more.

Further reading:

Suggest improvement to this page