11.8. Important Costing Factor - Transaction Time

The accuracy of moving average costing, first-in, first-out costing, and first-in, last-out costing heavily depend on the time of transactions.

If PostERP users fail to post in time the transactions to journal, it is very likely to cause the exception where the quantity of an item becomes negative. Once this error happens, it is extremely difficult to correct because the costing data of items flow between various sites all the time. It is not uncommon case that the site where and the time when the quantity becoming negative is not the actual sites where and the time when the problem actually occurs. The following scenario demonstrates such problem:

Table 11-3. the Actual Transaction Order of Item X in Site S

transaction timetransaction content
2011/1/10 12:00On hand quantity is 10 units
2011/1/10 12:1020 units is moved in
2011/1/10 12:2015 units were withdrawn

Table 11-4. The Incorrect Order of Item X Being Posted to Journal

transaction timetransaction content
2011/1/10 12:00The on hand quantity is 10 units
2011/1/10 12:2015 units were withdrawn

The transaction occurred at 2011/1/10 12:10 should have been entered and posted to journal before 2011/1/10 12:20. However, it was posted after 2011/1/10 12:20. This delay of posting resulted in the effect that inventory controllers are disallowed to withdraw item X from site S at 2011/1/10 12:20. It is so because PostERP demands that the on hand quantity of any given item must be greater than or equal to 0 while in this scenario the on hand quantity of item X in site S was only 10 units while the wanted quantity was 15 units. In such case, posting the withdraw transaction to journal would fail. Such failure can interrupt the business operation and causes logistic costs. Hence it is very important to strictly follow this rule to prevent this anomaly from happening:


PostERP demands that users must post every transaction data to journal immediately after it occurs. To follow this demand, users simply click on

button to run business logic processor immediately after entering the transaction data.