Hi Suraj,
I think cancelling an order is quite a different scenario from returns. I
can't think of a use case for customized behaviours depending on an order
cancellation reason. So personally I think using enumerations would be
sufficient.
Flexibility is good, but only if we have a good use for
Jacques,
I don't think that this is a showstopper. I just noticed it while
reviewing the release and fixed it in the branch.
Christian
Am 05.09.2019 18:18, schrieb Jacques Le Roux:
> Hi Chris, Jacopo,
>
> Does this needs a new [Vote] for 16.11.06? (I mean a new tentative
> release)
>
> Jacques
>
Hi Chris, Jacopo,
Does this needs a new [Vote] for 16.11.06? (I mean a new tentative release)
Jacques
Le 05/09/2019 à 14:31, chr...@apache.org a écrit :
Author: chrisg
Date: Thu Sep 5 12:31:57 2019
New Revision: 1866454
URL: http://svn.apache.org/viewvc?rev=1866454&view=rev
Log:
Updates READ
Hello,
I check and found that all GL entries are according to discounted amount
and no way to track how much sale discounts from GL, should we create
OrderAdjustments of certain type linked with certain invoice type as well
for all priceRules as well?
I mean why haven't we have done that yet, as
Hello folks,
I was looking into OrderItemPriceInfo entity and thought about how it is
managed while accounting, Like product was of $100 and due to a particular
price rule, it was sold at $50, unitListPrice in orderItem is $100 and
unitPrice is $50 with a record of OrderItemPriceInfo logging modif
Yes, agreed.
So what do you propose for to manage cancel reasons? A new entity or
something similar in pattern of ReturnReason.
My thought process was started with something for cancel reason, than I
looked into ReturnReason and started this discussion, actual need is we
should have something avai
