The FIFO/LIFO algorithm implemented since Compiere times is creating "fake" Attribute Set Instance (ASI) records for that purpose.
That is a common cause of confusion and we would like to change the way FIFO/LIFO is achieved to let ASI be ASI (this is product attributes or instance attributes, nothing else)
This is a very raw description of what was discussed at Vancouver conference (to be designed in detail at dev stage) - of course community feedback is welcome:
Add DateMaterialPolicy column on M_StorageOnHand table to records sequence of receipt for LIFO or FIFO policy.
We add field named "Use Warranty Date for Material Policy" on Attribute set to enable following warranty date for FIFO/LIFO process (this is to solve a problem because actually just the ASI is taken into account for FIFO, and sometimes is preferred to do FIFO using the expiration date - for example for perishables)
We use either MR Receipt date (Created date on M_InOutLine) or Warranty date to fill DateMaterialPolicy on MStorage Detail depending on value in "Use Warranty Date for Material Policy"
If Product has not ASI then we use MR Receipt date to fill DateMaterialPolicy
If Product has ASI then we use Warranty Date if attribute set is configured to use warranty date for Material Policy otherwise we use ASI created date.
DateMaterialPolicy is used for FIFO and LIFO material policy at time of Material Allocation.
Time of reverse, We should use same DateMaterialPolicy value used to create records. I
I am adding some amendment on what is planned at above
1. We always use Movement date on DareMaterialPolicy when adding new stock (On MR, Physical Inventory or production)
2. In GetWarehouse method, when retrieving storages, we check for UseGauranteeDateForMPolicy flag on attribute set and use guaranteeDate on ASI or use DateMaterialPolicy for FIFO logic.
I sent patch for your peer review.
Attaching patches for review in future
this commit make libero plug-in break. because change of parameter in function MStorageOnHand.get ()
please help me resolve it with a introduction.
Thanks Hiep, I just committed a fix restoring the method - can you please check again.
sorry, I miss. method MStorageOnHand.add has same problem.
what is *MA table. ex: MInOutLineMA?
I see somewhere ex:MDDOrder, MPPOrderBOMLine call MStorageOnHand.add with diffQtyOnHand = Env.ZERO.
this call don't make any effect. it safe to delete it?