Redesign ASI usage for FIFO

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.