Setting transaction timestamp by store orders
Sometimes, the algorithm for automatic set of transaction timestamps on transaction release may not choose the best possible dates and times. This is usually because of the specific logic of the business process of ordering store transactions which are unknown to the Logistics module.
It is possible to set transaction timestamps for the ordered transactions in the store orders. The module that contains the specific business logic helps setting better and more accurate times and dates in the store orders. When the orders are fulfilled, these transaction timestamps will be copied to the transactions and will remain unchanged on transaction release.
The current article describes some specific cases which require setting the transaction timestamp by the store orders.
In transitional store orders
For more information about transitional documents, see Transitional documents.
When a store order is transitional, all its rows are filled in with the creation date and time of the parent document. The logic here is as follows:
If the store order is set to transitional, then it is considered that it will happen automatically along with the parent document. So, the transaction timestamps will inherit the creation date and time of the parent document.
Example 1:
There is a work order where all documents except for the transactions (consumption orders, output orders and store orders) are transitional. On release, the store orders generate released transactions, i.e. the process is completely automatic.
At first, the work order has the following technological ratio:
producing 1 PCS of a product, the materials are 1 PCS of material #1 and 1 PCS of material #2.
On work order release, all sub-documents are created, and the materials are issued with a transaction timestamp of [19 Jan 2020 14:00:07] and the produced product has a transaction timestamp of [19 Jan 2020 14:00:09]. Also, because of the quick creation and release of all sub-documents, these are the transaction timestamp for creating the producing sub-documents (the consumption order is created on [19 Jan 2020 14:00:07] and the output order - on [19 Jan 2020 14:00:09].
Then, on 22 Jan 2020 the Work Order is adjusted and the quantity of the first material is changed from 1 PCS to 2 PCS. If in the transitional Store Orders the transaction timestamp fields are left blank, when releasing the new transaction for the additional 1 PCS of material #1, its transaction timestamp would be [19 Jan 2020 23:59:00] because it was released later than its Document Date. In this case, we would have the following chronology:
1 PCS of material #1, issue, 19 Jan 2020 14:00:07;
1 PCS of material #2, issue, 19 Jan 2020 14:00:07;
1 PCS of produced product, receipt, 19 Jan 2020 14:00:09;
1 PCS of material #1, issue, 19 Jan 2020 23:59:00
At 14:00:09 there will be a receipt of 1 PCS of the product for which 2 PCS of material #1 are needed. By now, only 1 PCS is issued (the other piece is issued later). This leads to failure in the issue and receipt balance validation (see Receipt and issue balance validation in store transfers and Calculating cost for produced products because of incorrect time of the last issue transaction.
When the Store Orders are transitional, the transaction timestamp is equal to the time and date of creation of the parent document, so the last issue transaction will also have transaction timestamp [19 Jan 2020 14:00:07] and the problem with the issue/receipt balance would not appear again.
In store orders created from completing output orders
When completing output orders are generated from the work order document form, specific date and time are set as a transaction timestamp in the rows of the output order. For each row in the output order, the greatest or the last transaction timestamp of all timestamps marking the moment the production has entered the store, is set as a transaction timestamp (this is the maximum date and time in all receipt transaction rows created by the current work order row, which has quantity different from 0). After that, the transaction timestamp from the completing output order are passed to the store orders and copied to the transaction rows.
The completing output orders actually distribute the cost of the materials which are not issued on time. As a standard, it is considered that later issues of materials are distributed to the last manufactured products. This is why the greatest transaction timestamp of all non-zero receipt transactions for the specified product is set as a transaction timestamp.
In store orders created by consumption orders for material
In the generation procedure of store orders by consumption orders, there is also a specific way of setting the transaction timestamp in the store orders rows. It appears only if the quantity in the specified row is negative and the greatest transaction timestamp from all material issue transactions in the generated store order is used as a transaction timestamp.
The consumption order rows with negative quantities return unnecessary (exceeding) materials. This process has to be entered in the store with the same cost, as issued. If the material is issued in more than one transaction, the issue transaction preceding the return of the materials is unknown, so the last issue is used as a reference.
In store orders created by shipment orders for products return
This case is similar to the return of materials to the production. If the quantity of the current shipment order row is negative, the greatest transaction timestamp from the relevant store order row (of all issue transactions happening by now) is set as a transaction timestamp.