Re: Cancel done delivery order

Following up on this topic, in the scenario where new products are ordered (in PO or SO), the agreed solution is to create a new SO/PO.

But users are fustrated because the supplier/customer already refers to the initial contract. I think that it would be interesting to indicate that the new SO/PO is an addendum [1] of a previous SO/PO, and make sure that both appear in subsequent references in Incoming Shipments / Invoices.

For example, PO/0001 is created and approved.

However, for whatever reason, the supplier will send an additional item under the umbrella of the first PO (maybe because they ship in quantities multiple of 10, and we ordered 8).

The user then creates a new PO, PO/0002, with the extra 2 items, and adds in the field 'Addendum of' the PO/0001.

When the user creates the Incoming Shipment IN/0002 from PO/0002, the field 'Addendum of' is copied from the PO, and the field 'Reference' says "PO/0002 (addendum of PO/0001) "

When a user searches for Incoming Shipments based on PO/0001, the application will list IN/0001 and IN/0002 (that is, the original contract and all subsequent addendums).

When the user creates the Invoice from the Incoming Shipment, the field 'Source Document' says "IN/0002: PO/0002 (addendum of PO/0001)".

When a user searches for Supplier Invoices based on the reference field including PO/0001, the application will list all invoices for the original contract, as well as subsequent addendums.

Quick follow up on this topic, we discover that Odoo isn't handling the Sale Order line states correctly. That means, cancelling a sal order line (even through the menu, using standard Odoo features) doesn't work properly as in various places the code doesn't exclude the SO line at state "cancel" (for example in procurement management, in the re-creation of deliveries, etc...). Also, in some places, the code is handling the canceled SO lines properly.

It almost sounds like you meant to send this email to someone else? Your case scenario isn't really 2 options, option 2 only becomes available if you partial deliver goods in the first step. Your business case revolves around backorder management, or the customer requests less quantity than what they ordered.

It doesn't do anything to describe a scenario where customer wants more than ordered, or they want different item altogether.

I am sending you this because at least the first situation "the Customer wants to decrease the quantity to be shipped for an ordered product" is handled (IMHO) out of the box with Odoo to the satisfaction of my customers, and I've never been asked to improve it after showing them how to do it. In fact, it was Odoo that pointed this out to me when I asked how to handle the first case.

The README suggests "The end user is stuck with the system and can't do anything".

I disagree. My questions for you are: Did you decide that this support is not adequate? During which step?

My example:

1. the Customer wants to decrease the quantity to be shipped for an ordered product.

* We need to set proper business process around to ensure
those use cases below do not happen, at least not too much

* We need to solve (without headache) the situation in the ERP
in some cases where it make sense

I try to make an approach of what are the use cases where
you need such a feature (and those use cases have to be
resolved for : MTO, Drop ship and MTS). My below cases are
based on drop shipping because it is the "worst" as you
need a strong agreement from supplier (but the same happen
with MTO). I take the assumption you agree to be nice with
your customer.

1) Customer want to decrease the quantity to be shipped
of an ordered product

=> We have remaining quantity to be shipped and the
customer want less product, but still want some (so you
can't cancel).

- Ask supplier if ok, he says yes !

=> You're stuck with the system and can't do
something. Only way out: cancel the remaining deliveries,
SO goes in exception, say "manually corrected", do the
same for PO, make a new SO and PO. That's not really good
but it works.

2) Customer want to increase the quantity to be
shipped of an ordered product

=> We have remaining quantity to be shipped and
the customer want more of the product.

- Ask supplier if ok, he says yes !

=> You're stuck with the system and can't do
something. Only way out: make a new SO and PO. That's
not really good but it works.

3) Customer want to cancel the remaining quantity to be
shipped of a product

=> We have remaining quantity to be shipped and
the customer want to cancel it. Here, it can work the
following way only is you cancel all remaining, because
if you have other line to be shipped, we have the same
trouble than in 4)

- Ask supplier if ok, he says yes !

- Cancel the remaining picking

- SO goes in exception, say "manually corrected"

- Same for PO

Trouble => You don't have the historical value
somewhere. You may log a note in the chatter, but well,
this is not really clean as your SO contain the ordered
quantity only.

4) Customer want to cancel a whole line of a product not
yet shipped

=> Imagine you already ship some line, but still 2
lines to be shipped.

- Ask supplier if ok, he says yes !

=> You're stuck with the system and can't do something.
You cannot split a delivery so you can cancel the proper
line. Only work around: make note in the chatter. Once you
will have the only remaining line in a delivery, you'll be
able to cancel it like 3)
5) Customer want to cancel a SO no yet shipped - Check with supplier it is OK
- Cancel the pickings of the SO
- Cancel the PO
- Cancel the SO

6) Customer want to add a new product in existing
confirm SOCreate a new SO :)

Conclusion

* 5) and 6) are ok

* 1) and 2)) are ok, but really boring task

* 3) is boring if no other product, but if other
product are here, it's like 4)...

* 4) is may work, but is really the worst...

My solution would be not to bypass any of the system
process, but provide automation so the task is not taking
too much time, but overall it'll avoid to make mistake !

Solution 1:

- Create a wizard for SO, a wizard for PO that help the
user to make those operations in a semi-automatic way
(e.g. for 1) it will automatically cancel the remaining
and create a new so with the wanted value).

- The wizard will always keep a link between canceled
or done document and the new created one for audit purpose
(like backorder in pickings)

- The document will always store the ordered quantity
AND the new agreed one, with a log of what has been done.
The user will have to provide a reason for his changes and
it'll be logged

Solution 2:

- Create a wizard for SO, a wizard for PO that help
the user to make those operations in a semi-automatic
way

- The wizard will work at line level and "play" with
the status of the line

e.g. I have a confirmed SO line with ordered qty
= 1000 ; I already ship 200 ; The user only wants 300 of
the remaining 800

=> the wizard will:

- Keep the original line and change
quantity for 200, mark it as shipped

- Add a new line with quantity 300,
confirm it and generate the delivery

- Add a new line with quantity 500,
set state to cancel

- The user will have to provide a reason for his changes
and it'll be logged

=> Regarding the accounting flow, for both solution,
the wizard will try to cancel the invoice if any. If it
cannot (e.g. already paid), it'll generated a full refund
and set the proper line to "to be invoice" (will here to
take care of the invoicing policy of the document).

Le 19/03/2015 12:47, Eva Pinter a écrit :
> The problem we have to solve there is that the confirmation does
> creates immediately delivery order on confirmation. This is causing so
> much trouble because it then requires cancellation of delivery and
> order, in case the customer changes his mind.
Unless I misunderstand your comment, as I wrote this problem was solved
sooner this week in v8.
Now conform order => creates delivery
Cancel order => cancels delivery.
I juste tried on runbot, it works.
Just be careful if you make to order, you don't want to make the same
things twice. But again, MTO doesn't lend itself to changing orders anyway.