Repost Item Valuation - jigneshpshah/greycube_helpmanual GitHub Wiki
Repost Types
break the transaction wise reposts into _Item-Warehouse wise _reposts.
That will be a bit faster since many transactions may share the same item-warehouse. This will add more no. of repost entries to the queue (since a transaction is broken down into item-warehouses) but will ingest faster and skip duplicate item-warehouse entries. But for new repost entries being created everyday, they will be ingested the usual way If an extremely large no. of new repost entries (a lot of backdated entries) gets queued, it will require waiting again
to split Transaction-wise reposts to item-warehouse rows in transactions change Stock Reposting Settings to
Use Item based reposting
The Origin of Repost
https://github.com/frappe/erpnext/pull/24031
The Problem: We maintain the stock item's valuation rate for each warehouse separately and we need it for each transaction for maintaining the FIFO queue. We also need stock qty for any specific date for reporting purposes. Hence we store both qty and valuation rate in Stock Ledger Entry record.
When we receive or deliver an item, we simply add/deduct qty in current SLE with previous stock qty and calculate the valuation rate based on current qty and rate.
But when we submit or cancel a back-dated stock transaction, we need to repost all future SLE's for linked items to recalculate qty and valuation rate after each future stock transactions.
All these were happening in version 12. But there were some problems.
When there are a lot of records for an item, submitting or canceling a back-dated transaction for that item takes a lot of time to repost future SLE and lead to a Time Out error. There are kinds of stock transactions where an item's incoming rate depends on other items/warehouse/transaction. In those cases, while reposting happens for dependant items, the system should repost SLE for the target item with an updated incoming rate. This does not happen and it leads to incorrect valuation rate and accounting entries for the target item. Here are some examples: Inter-warehouse stock transfer: The valuation rate in the target warehouse depends on the source warehouse. Manufacture / Repack Entry: The valuation rate of finished goods depends on raw materials. Sales Return: The valuation rate of a returned item depends on the item's outgoing rate in the original Delivery transaction. Purchase Return: The valuation rate of a returned item depends on the item's outgoing rate in the original Receipt transaction. Subcontracting: The valuation rate of finished goods depends on the supplied raw materials. The Solution:
Handle reposting via background jobs. Introduced a new document called "Repost Item Valuation" which is created on submission/cancellation of every stock transaction. And it handles reposting via background jobs. If any background jobs fail it shows the status and records an error log. You can restart the reposting after taking an action to resolve those errors. Reposting can also be done manually for any voucher or item. Repost all related items and warehouse. Enforced incoming rate for target warehouse based on source warehouse In Stock Entry added "Is Finished Item" and "Is Scrap Item" checkbox, it will be auto-checked in case of manufacturing. Organised form fields Introduced a field "Role Allowed to Create/Edit Back-Dated Stock Transactions" in Stock Settings. If any customer wants to restrict back-dated transactions to a specific role they can do it.