Models for maintaining the actual cost
There are two main models to keep the goods cost up-to-date.
Right from the start, when we enter (and release) the transactions, the actual cost is recalculated. The costs of all existing store transactions affected by the current transaction are also calculated. This leads to a perfect situation where all transactions are correctly calculated no matter when they are entered in the system. In addition, the calculation is performed by the system and the user does not have to control it. The disadvantage of this model is the additional calculations for creating and releasing a transaction, especially when that transaction is old. This may lead to slow performance of the Logistics module.
The corrections are created periodically by a user instead of immediately for each transaction. This model provides the easier daily creation of a transaction with a risk for incorrect costs not covered by cost correction (this happens only when store transactions are entered in a non-chronological manner).
Dynamic cost correction
Maintaining the actual cost at all times with the first model is accomplished by using two specific procedures for generating cost correction from every transaction. They have to be created when the transaction is released and the generation of the cost correction updating the cost of the current transaction is performed first.
Thus, when the transaction is released, it will have its original cost, and the first generation will correct its values if necessary. We assume that the cost of all existing released transactions before the creation of the current transaction are correct (as the cost of the current transaction may be affected by them). Once the first generation corrects the cost of the newly entered transaction, the second generation corrects the cost of all other transactions that depend on the current transaction. Thus, after its release, the cost of all transactions in the system will be actual no matter the date they are entered. The older the transaction, the slower the performance of the two generation procedures will be (this means that more transactions will be affected by the current transaction).
Periodical cost correction
The second model for cost correction does not use automatic generation procedures for the cost corrections. Instead, the user manually enters documents for a specified period (month, quarter, etc.) and starts the basic algorithm for cost correction calculation for all transactions in the specified period.
For example, if cost corrections are performed monthly, the user creates a new cost correction document and sets the period from the first date to the last date of the month. Then, he starts the function Recalculate the corrections for the period, which loads all store transactions where transaction timestamp is in the specified period. The function then adds the opening balances at the beginning of the period, and this data is executed by the basic algorithm for cost correction calculation . So, the actions of the user are limited to entering the start and end dates, starting the function and releasing the document. This is performed for past periods (i.e. not for the current month) for which there will be no more new transactions, and in which the cost corrections are already calculated and released. Otherwise, there may be incorrect cost in the current-period transactions.
The recalculation of the cost of all transactions in a specified period may take more time than if the first model is used, but it eases the daily Transactions release significantly. Also, for periodical cost correction, a more appropriate execution time may be picked (for example, during the night).