Community mailing list archives

community@mail.odoo.com

Re: Cancel done delivery order

by
XPANSA, Eva Pinter
- 06/20/2015 19:33:42
Hi Marcello,

To answer your questions, basically you are right. Picking does not mean delivered, in no company.

Nevertheless, in many small businesses, they only have a picking/packing/sending process in one, so that it is sufficient for them to have only the “picking” as finishing process for deliveries

Further, the picking / packing / sending process is usually organised the following way

a. Pick goods from different warehouse locations/spot and bring them to a preparation area
b. Pack the goods for the customer and move them to the delivery area
c. Send out the goods

Generally, it is agreed that when goods are on the delivery area, they will not be brought back into the stock and this is the point where the goods are considered deliverd (other ERP also do the same)

So, in order for you to set-up this properly, you will have to define a two step process: a. picking b. packing. This should be possible starting from V8, using pull/push rules that forces the delivery to wait for another move. You will also need to define the extra warehouse locations that will allow to represent your warehouse as it really is.

Good Luck
-- 

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 | https://xpansa.com/products/xpansa-odoo-alfresco-bi-saas/
mERP | Odoo Android App | merpapp.com

/// site  : xpansa.com
/// mail  : eva.pinter@xpansa.com
/// skype : epinter

On 26 May 2015, at 15:34, Marcelo Bello <marcelo.bello@gmail.com> wrote:

HI all,

    I know this thread is old and I am not sure anyone is paying attention anymore.

    However, I wonder why nobody seems bothered by the fact that finishing the picking operation automatically sets the SO as delivered? (if this has been discussed in another thread, please let me know)

    Having the completion of the picking operation setting the SO as delivered does not reflect the reality of most business IMO.

     I agree that after an order is delivered, no changes should be allowed to the SO (after the goods leave the premises of the company - which should be the real meaning of having an "SO delivered" - a SO is finished and if the goods are to be returned they should go through a proper RMA process), however, after only the picking operation has been completed such changes should be acceptable. The problem is that confirming the Picking Operation currently sets the order as delivered.

     Let me show a few examples when Picking != Delivery:
- Customer confirms a SO by phone/email but says he will pick up the order himself at the shop. SO generates picking, warehouse operator finishes picking and the order is set as Delivered (but delivered it is not). Customer arrives at the shop to pick up the goods, the goods are already packed and waiting at the "delivery area" but customer changes his mind and want things changed. Salesman should be able to change the SO but unfortunately the goods are already considered as delivered;

- Customer confirms an order. Order is picked, packed and addressed. Early afternoon, a few hours before the shipping agent comes by to collect the order, customer calls and says he wants things changed. Unfortunately the system is already marking the order as delivered while it is there sitting at the warehouse awaiting pick-up. Salesman has no way to tell if the goods are indeed sitting at the warehouse of if they are in fact already in transit. This piece of information is important for the salesman to know how flexible he can/should be with the client that is asking for the changes;
    
    I think if we had a flow like "Quotation -> Sales Order -> Sales Order (confirmed) -> Picking -> Packing (optional) -> Ready to be Picked-up/Shipped/Delivered -> Picked-up/Shipped/Delivered", the whole process could be much better in that a SO while still in-house could certainly be reopened and edited (or cancelled).
    Also in Brazil, we actually need to distinguish between Picking/Packing Done and Delivery, because the electronic invoice that will be shipped with the goods should ideally be issued when the goods are about to leave the premises of the company, not a few days in advance (some shipping agents may take a few days to come pick the goods).

    Has this issue ever been discussed on this list? Are there modules to add such additional steps to the sales/delivery flow? Your pointers are appreciated.

Best regards,

Marcelo

On Wed, Apr 22, 2015 at 6:48 AM, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
hi Jordi,


Thanks for joining us on this one ! Here is our current related PR in case you want to have a look.

Pre-requisit for Odoo Core:

 * PR for Odoo Sale: https://github.com/odoo/odoo/pull/6036
 * PR for Odoo Purchase: https://github.com/odoo/odoo/pull/6038
 * PR for stock_split_picking: https://github.com/OCA/stock-logistics-workflow/pull/94

Then the PR for the modules:

 * sale_amedment: https://github.com/OCA/sale-workflow/pull/134

 * purchase_amendment: https://github.com/OCA/purchase-workflow/pull/117

Best regards,

Joël








On Wed, Apr 22, 2015 at 11:18 AM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
Hi Joël,

Certainly, adding new products to the same SO/PO would be great.

Then I will not follow my proposed approach. I will try support you as much as possible to complete "sale_amendment" and "purchase_amendment", and possibly start with the features that you proposed to add quantities/products to an existing SO/PO.



Regards,
Jordi.


On Tue, Apr 21, 2015 at 6:42 PM, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
Hi,


That's a good point: adding new products will be very much appreciated as well.

Your suggestion is good. Note that if the PR mentioned in my last mail is accepted by Odoo, I think we have everything to include this use case in the sale_amendment and purchase_amendment modules. As we'll follow the standard process in this implementation:

 * Adding new quantity/product in an SO will trigger the according procurement

 * Adding new quantity/product in a PO will update the incoming shipment

The only point is, for the first release, those use cases won't be implemented by us (a matter of budget). But from a technical point of view, nothing forbid the contributors to implement this use case : everything will be ready to support it !

Thanks to come back on this one.

Regards,

Joël











On Tue, Apr 21, 2015 at 5:12 PM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
Hello,

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.



Please let me know your thoughts on this one.

Regards,
Jordi.


On Mon, Mar 30, 2015 at 12:37 PM, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
Dear Community,


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.

So we suggest a PR here to fix that:

https://github.com/odoo/odoo/pull/6036

We would appreciate your support on this one, the goal is to treat the canceled SO lines properly and with consistency in all Odoo.


Best regards,


Joël









On Thu, Mar 26, 2015 at 5:27 AM, OpenERP Master <openerpmaster@gmail.com> wrote:
Ray,

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.

On Wed, Mar 25, 2015 at 9:42 PM, Ray Carnes <raycarnes@hotmail.com> wrote:
Hi Luc,

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.


A. Create a Sales Order for 10 units
B. Confirm (Delivery Order is created for 10 units).

Option 1 - Customer tells you before you deliver any, that they want 8, not 10:

C. Edit the Delivery Order, change 10 to 8. 
D. Transfer
E. SO shows 100% delivered.
F. Create the Invoice, change 10 to 8.
G. Validate
H. Pay
I. SO shows 100% invoiced.
J. State of SO is set to DONE.

Option 2 - Customer tells you after you have delivered 8, that they only want 8.

C. Edit the Back Order, change 2 to 0.
D. Transfer 0 items (silly UI defect, you have to change the qty transferred also to 0 - this wasn't the case at v7).
E. SO shows 100% delivered.
F. Create the Invoice, change 10 to 8.
G. Validate.
H. Pay.
J. State of SO is set to DONE.

Let me know what I am missing.  This seems perfectly acceptable to me, apart from the UI glitch introduced at v8 by reserving.

Ray.




Subject: Re: Cancel done delivery order
From: joel.grandguillaume@camptocamp.com
Date: Tue, 24 Mar 2015 16:07:55 +0000
To: community@mail.odoo.com


Dear community,


Here is the final decision taken on Camptocamp side about those amendment process:

https://github.com/gurneyalex/sale-workflow/blob/8.0-sale_amendment/sale_amendment/README.rst

We start the devs now and it'll of course be publish under the OCA umbrella. It'll be composed by sale_amendment and purchase_amendment modules.

Hope you'll enjoy it !

Regards,

Joël


 

On Fri, Mar 20, 2015 at 11:35 AM, Nuria Arranz Velazquez <nuria@opusvl.com> wrote:
Eloquently put, +1

On 19/03/15 16:27, Joël Grand-Guillaume wrote:
<blockquote cite="mid:CACk3wOLkZHteo=7ASrcCGjd4Tmg5Mf+kuMrei+J0aOs2OpUjMQ@mail.gmail.com" type="cite">
Hi,


What a debate :) My opinion here is:

 * We need to educate our users properly
 * 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 SO
Create 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).


Any preferred solution, comment or idea for me :) ?


Regards,

Joël


On Thu, Mar 19, 2015 at 3:02 PM, Lionel Sausin <ls@numerigraphe.com> wrote:
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.
_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe



-- 
N. Arranz-Velazquez
OpusVL Odoo Specialist Team (OOST)

OpusVL
Drury House
Drury Lane
Rugby
CV21 3DE

T: 01788 298 450
W: www.opusvl.com
_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--



camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe