Draft: trade: update relationship between document dates
I recently thought about start and stop date for standard ERP5 Business Process. The issue that made me wonder was the default simulation configuration, which generates Packing Lists with both start and stop date equal to the stop date of the Order, while on both views, the user can enter « Shipping Date » and « Delivery Date », and would therefore expect these properties to be reported the same way on the related Packing List.
ERP5 is made in such a way that both date cannot, on purpose, be reproduced on the Packing List. This behaviour is defined on the getExpectedTradeModelPathStartAndStopDate method of BusinessProcess. I think the implementation makes sense: one always compute both start date and stop date of the next movement in the tree from a reference date of the previous movement (usually stop date).
From there, I wondered if it actually made any sense to have a Shipping Date on an Order: this is purely a Packing List property. Imagine ordering something from a provider, you enter the quote as an Order, then validate. Before validating, there are little chances you may be able to know the delivery date. However, there are high chances you know the shipping date, and you surely know the placement date. As such, I ended up with the following table:
| Order | Packing List | Invoice | Payment | |
|---|---|---|---|---|
| Start date | Placement date | Shipping date | Invoice date | Payment triggered date |
| Stop date | Shipping date | Delivery date | Accounted date | Payment received date |
The link between Packing List and Invoice is usually Invoice date = Shipping date, and not Invoice date = Delivery date, since there is often no way for a seller to know that a shipment actually arrived, or checking would be a useless extra cost. Legally, is depends on many things, most notably the Incoterm. So flexibility would require to be able to configure both.
So to follow this table, we have two issues: the view for Order and Payment should be modified to display these strings, and a Trade Model Path should allow a movement’s reference start date to be the start date of the parent movement instead of its stop date; this MR does both. I saw that some tests regarding conventions, proxification and related things were failing. Fixing should be fairly easy, but I would like some feedback before to know if these changes can be 1. deemed acceptable and 2. upstreamed.