Handling reactivation of warehouse orders

[Martin Schönbeck]

Hi,

when completing a warehouse order a shipment is created automatically. Invoices have to be created by other means (in my case by manually creating them). When such a warehouse order is reactivated not only the shipments are reversed but also invoices connected to this order. Because the invoice where created independently they often carry a bunch of positions from other orders and of course are already sent to the customer. Now that this invoices are reversed all their positions show up when creating invoices the next time. This invoice is then sent to the customer, too. But because the reversal is not done during the normal process nobody has a chance to sent this reversed invoice to the customer. A customer might be made unhappy by this. ;-)

If using a standard order and then changing the order or the shipment nothing happens to the related invoices and the user has (and is able) to deal with this transparently, for example an invoice with a negative amount will be created. I don't see any reason why this shouldn't be handled exactly that way by a warehouse order. Reversing only what was created by completion. So I fear the reversion of invoices is introduced their because it's necessary for POS-orders and should have been skipped on warehouse orders.

What do you think?

Regards,

Martin

[Flo Boj]

Hi Martin,

this dimenension is hard to understand at all, I think. Chuck did VERY good attempts in his academy in order to explain all that stuff ( like explaining all Standard Order, Credit Order and so forth, step by step), 

and all the flags and their impact (like whats the difference between PaymentRules  Direct Debit and Credit when it comes to payment),

so I think a FlowChart with ALL that stuff inside would be straight forward ( if not yet exists (if one exists WHERE ?) , and done by somebody knowing ), and being updated conscientiously by the community,

in order to help users understand in future. 

Just my idea on that,

Best Regards

Florian

[shiju01]

Hi
Warehouse Order, Credit Order, POS Order, Standard Order all have their specific features.

All document workflow should be tested before implementation.

This is very important.

If it's not align with business process then it need to be customized.

Openbravo allows REACTIVATE in all types of documents at any stage after validating dependencies, which can be easily implemented here also

Which may avoid reversing invoices but the concept may be against accounting principles.

[Martin Schönbeck]

Hi Flo,

Am Mittwoch, 27. Mai 2020 18:55:13 UTC+2 schrieb Flo Boj:

Hi Martin,

this dimenension is hard to understand at all, I think. Chuck did VERY good attempts in his academy in order to explain all that stuff ( like explaining all Standard Order, Credit Order and so forth, step by step), 

and all the flags and their impact (like whats the difference between PaymentRules  Direct Debit and Credit when it comes to payment),

It's not that I don't understand what's going on. I simply think it's not straight forward (not to say 'wrong'). 

so I think a FlowChart with ALL that stuff inside would be straight forward ( if not yet exists (if one exists WHERE ?) , and done by somebody knowing ), and being updated conscientiously by the community,

in order to help users understand in future.

 

In this case the flow can be seen easily in MOrder.java. But as reactivating a standard order doesn't reverse connected invoices I don't see a reason to do so with a warehouse order.

Regards,

Martin

[Carlos Antonio Ruiz Gomez]

Martin, I think you wrote the answer to that previously here:
https://groups.google.com/d/msg/idempiere/rl6czXpP7kY/LII_1bPMAwAJ

you said:
> Reversing a completion should reverse anything which was initiated by
this completion

And that's what I understand is happening here, standard orders don't
create any document, so associated docs are not reversed when the order
is reversed.
Warehouse order creates some documents, so, those documents are reversed
when the order is reversed.

It sounds correct, no?

Regards,

Carlos Ruiz


El 27/05/20 a las 10:49 a. m., Martin Schönbeck escribió:

[Martin Schönbeck]

Hi Carlos,

Am Mittwoch, 27. Mai 2020 21:51:36 UTC+2 schrieb Carlos Antonio Ruiz Gomez:

Martin, I think you wrote the answer to that previously here:
https://groups.google.com/d/msg/idempiere/rl6czXpP7kY/LII_1bPMAwAJ

you said:
 > Reversing a completion should reverse anything which was initiated by
this completion

And that's what I understand is happening here, standard orders don't
create any document, so associated docs are not reversed when the order
is reversed.
Warehouse order creates some documents, so, those documents are reversed
when the order is reversed.

It sounds correct, no?

No, warehouse orders create shipments (m_inout) but no invoices. Invoices are created automatically only by POS-orders, on credit orders and prepay orders. And those of course then should reverse the invoice. That's never a problem, because the invoice is connected to the order. And only to the order. With standard orders or warehouse orders the invoices can be connected to several orders, which leads into several problems if reversing it without explicitly wanted by the user.

Regards,

Martin

[Carlos Antonio Ruiz Gomez]

I see, so, somehow this thread is related to the other thread from Víctor Suárez.

I agree with you, just automatically created documents must be reverted.

OK to add a ticket to implement this new behavior, but, as many people may have modeled their reversal processes with the current behavior in mind, I think is important to add a SysConfig key that still can be enabled to preserve the actual way.

Regards,

Carlos Ruiz

El 27/05/20 a las 10:05 p. m., Martin Schönbeck escribió:

[Martin Schönbeck]

Hi Carlos,

Am Mittwoch, 27. Mai 2020 22:22:51 UTC+2 schrieb Carlos Antonio Ruiz Gomez:

I see, so, somehow this thread is related to the other thread from Víctor Suárez.

I'm not fully aware what exactly his problem was, but I think it's the same direction.

I agree with you, just automatically created documents must be reverted.

OK to add a ticket to implement this new behavior, but, as many people may have modeled their reversal processes with the current behavior in mind, I think is important to add a SysConfig key that still can be enabled to preserve the actual way.

I created a ticket (https://idempiere.atlassian.net/browse/IDEMPIERE-4310) and will try to create a patch. And learn how to define a new SysConfig key.

Regards,

Martin