Table of Contents

Basic algorithm for cost correction calculation

This algorithm is applied to multiple records: either transaction rows or accumulated records for goods cost (most often opening a balance for а specified period).

The algorithm has two stages:

  1. The records are ordered chronologically.

  2. The cost of the rows that do not include accumulated information is recalculated one by one.

The cost of transaction rows in multiple records is recalculated instead of the accumulated data. The mismatch between the newly calculated and the current actual cost is saved in the document cost correction. With the release of cost correction, the costs in the transaction rows are updated.

Multiple records are generated when all transaction operations for a period (as well as the opening balance at the start of the period) are loaded. It is of great importance for all transaction operations and opening balances to be loaded during the operation. Any of them missing may lead to incorrect cost correction (during stage 2 of the algorithm).

Stage 1: Chronological sorting of the records

The following criteria is used to order the records chronologically:

  • In case two records share the same enterprise company, store, product, and lot (only if the product has a separate cost for each lot), the records with a shorter transaction timestamp are placed before the ones with a greater transaction timestamp. If the transaction timestamps are equal, the receipt goes before the issue operation. If the records have the same movement type, it is assumed that the operations have happened at the same time.

  • If two records - part of a transfer or a production process - have opposite movement types, then an issue transaction is performed before a receipt transaction (only if the transaction timestamp of the issue transaction is smaller than or equal to the receipt transaction). Enterprise company, store, product, and lot do not affect the order here.

The criteria above can’t provide thorough sorting of the records. That is why a topological sorting is applied. Any topological sorting may be used - more than one for a specific partial sorting. The result in the next stage is the same regardless of the sorting method used.

Stage 2: Recalculating the sorted records

When the records are ordered in the previous stage, the cost accumulated from the starting period (average) is calculated. Then, the cost of each record is recalculated. Finally, the recalculation of the next record begins (if there is one in the first place).

The recalculation of the record cost is performed as follows:

  • If the record is for accumulated data (opening balance), the record is not recalculated.

  • If the record is an issue transaction, then the cost is calculated according to the average accumulated cost.

  • If the record is a receipt transaction and is part of a transfer or a production process, then its cost is recalculated according to the algorithm from articles Calculating cost for produced products, Calculating cost for transferred products, and Calculating cost for returned products.

  • If the record is a receipt transaction and is not part of a transfer or a production process, the record is not recalculated.

This includes Inventory Reconciliation receipt transactions and other receipt store transactions that are not part of a transfer or production process.

A transaction released later with an earlier Transaction Timestamp can change the accumulated cost in the store transaction chronology. Cost Correction can use this change when recalculating subsequent issue transactions.

However, receipt transactions that are not part of a transfer or production process are not recalculated. Therefore, an Inventory Reconciliation receipt that was originally calculated with zero cost can remain with zero cost after Cost Correction.

For details about transaction participation in the original cost calculation, see Original cost calculation.

Example 1:

There are two stores and three products, the first two of which are provided by external suppliers. The third is internally produced. A recalculation of the cost for January 2020 is needed. This is the data for the first store. The second store has no movements recorded (including the current period):

  • Store #1, Product #1, Opening Balance, before 01 Jan 2020 00:00, 10 PCS, total cost: 100;

  • Store #1, Product #2, Opening Balance, before 01 Jan 2020 00:00, 10 PCS, total cost: 150;

  • Store #1, Product #1, receipt transaction, Transaction Timestamp 05 Jan 2020 17:27, 10 PCS, total cost: 140;

  • Store #1, Product #2, receipt transaction, Transaction Timestamp 05 Jan 2020 17:27, 10 PCS, total cost: 190;

On 16 Jan 2020, a certain quantity from the third product is manufactured and added in the other store:

  • Store #1, Product #1, issue transaction, Transaction Timestamp 16 Jan 2020 10:12, 4 PCS, total cost: 48;

  • Store #1, Product #2, issue transaction, Transaction Timestamp 16 Jan 2020 10:25, 6 PCS, total cost: 102;

  • Store #2, Product #3, receipt transaction, Transaction Timestamp 16 Jan 2020 14:47, 2 PCS, total cost: 150.

Then, on 19 Jan 2020, part of the produced quantity is moved to the first store and the transport costs 7:

  • Store #2, Product #3, issue transaction, Transaction Timestamp 19 Jan 2020 11:32, 1 PCS, total cost: 75;

  • Store #1, Product #3, receipt transaction, Transaction Timestamp 16 Jan 2020 11:50, 1 PCS, total cost: 82.

It turns out that there was a receipt transaction on 11 Jan 2020 which is not entered in the system on time:

  • Store #1, Product #1, receipt transaction, Transaction Timestamp 11 Jan 2020 13:44, 5 PCS, total cost: 85;

  • Store #1, Product #2, receipt transaction, Transaction Timestamp 11 Jan 2020 13:44, 6 PCS, total cost: 44.

The cost of all other store Transactions during this month is incorrect (except the first two receipts on 05 Jan 2020) and has to be recalculated. When executing the algorithm with the previous data, the following order of records will be completed after the first stage:

  • Store #1, Product #1, Opening Balance, before: 01 Jan 2020 00:00;

  • Store #1, Product #2, Opening Balance, before: 01 Jan 2020 00:00;

  • Store #1, Product #1, receipt transaction, Transaction Timestamp: 05 Jan 2020 17:27;

  • Store #1, Product #2, receipt transaction, Transaction Timestamp: 05 Jan 2020 17:27;

  • Store #1, Product #1, receipt transaction, Transaction Timestamp: 11 Jan 2020 13:44;

  • Store #1, Product #2, receipt transaction, Transaction Timestamp: 11 Jan 2020 13:44;

  • Store #1, Product #1, issue transaction, Transaction Timestamp: 16 Jan 2020 10:12;

  • Store #1, , Product #2, issue transaction, Transaction Timestamp: 16 Jan 2020 10:25;

  • Store #2, Product #3, receipt transaction, Transaction Timestamp: 16 Jan 2020 14:47;

  • Store #2, Product #3, issue transaction, Transaction Timestamp: 19 Jan 2020 11:32;

  • Store #1, Product #3, receipt transaction, Transaction Timestamp: 19 Jan 2020 11:50.

After the recalculation in the second stage for the last five transactions, the following actual costs will be calculated:

  • Store #1, Product #1, issue transaction, Transaction Timestamp: 16 Jan 2020 10:12, recalculated cost: 52;

  • Store #1, Product #2, issue transaction, Transaction Timestamp: 16 Jan 2020 10:25, recalculated cost: 96;

  • Store #2, Product #3, receipt transaction, Transaction Timestamp: 16 Jan 2020 14:47, recalculated cost: 148;

  • Store #2, Product #3, issue transaction, Transaction Timestamp: 19 Jan 2020 11:32, recalculated cost: 74;

  • Store #1, Product #3, receipt transaction, Transaction Timestamp: 19 Jan 2020 11:50, recalculated cost: 81.

This means that in the cost correction document, 5 rows will be created, one for each of thе operations with cost changed, and the rows will save the mismatches:

52 - 48 =4, 96 - 102 = -6, 148 - 150 = -2, 74 - 75 = -1 and 81 - 82 = -1.

Suggest improvement to this page