Community mailing list archives

Re: push delivery date from PO to SO

XPANSA, Eva Pinter
- 07/29/2015 13:07:42

From a purchasing functional point of view, I totally agree with Ray. It is important to keep the date in the PO in order to make an analysis of the supplier quality. Changing the PO would mean you loose that information.


Best Regards,
Eva Pinter

Sales and Marketing Director, XPANSA Logistics | ERP, BI, E-commerce, Data Mining and DMS consulting
Xpansa CLOUD | Full Business IT Infrastructure |
mERP | Odoo Android App |

/// site  :
/// mail  :
/// phone, IE : +44 (0)7596 40 30 99
/// skype : epinter

On 29 Jul 2015, at 18:03, Ray Carnes - Implementation Strategy <> wrote:

I’ve always recommended to separate the promise/agreement (Purchase Order) with the fulfilment of that promise/agreement (Incoming Shipment or Receipt).


I encourage users to negotiate and update the RFQ as needed, but once it is confirmed to not make changes.  So, I’d recommend managing changes to the delivery date on the Incoming Shipment or Receipt, rather than the PO. 


What you lose if you don’t do this is “Which suppliers actually keep their word, or tell me something accurate?”.




From: Pedro Manuel Baeza Romero []
Sent: Wednesday, July 29, 2015 9:28 AM
To: Community <>
Subject: Re: push delivery date from PO to SO


I would create a new date at sale order line level for handling such things, and add the logic for a correct computation of this date, because the rest is very confusing for putting in order.



2015-07-29 18:08 GMT+02:00 Leonardo Pistone <>:

has anyone found a good way to manage a change of delivery date from
an existing PO to a linked (MTO) SO in v8? The use case is a supplier
calls in to say that a product will be available in a month, and I
want this change in the POL to affect the sale.
I found the following:
- the (POL) has a date_planned field, which is written to the
date_expected of the created move on the validation of the PO
- this is not propagated on subsequent updates of a confirmed PO. A
new module could do that
- changing the date_expected of a move propagates the date delta to
chained moves. This is a new feature in v8. So far so good.
Once we get to the SO, things get confusing to me. The
sale_order_dates module adds three new date fields to the SO:
commitment_date, requested_date and effective date. The latter could
be what I want, but:
- it is a field on the SO, while probably that should be on the SOL
- strangely enough, it checks the creation date of the picking, not
the expected date
Hence, this flow doesn't work. Does anyone know how to handle it?

Post to:


Post to:

Post to: