http://ofbiz.116.s1.nabble.com/Help-with-POS-behaviour-tp174892p174906.html
> Progress on the problem with POS incorrectly creditting the CASH
> account regardless of which payment type was used to process a
> customer refund...
>
> It seems processAmount in PaymentEvents.java behaves differently
> depending on whether you enter the amount to be refunded vs letting
> the system default to the value of the sale (refund). In the former
> case, the defect I have described does not exist (ie, the correct
> GL account gets updated on a refund). In the latter case, the
> behaviour defaults to posting transactions to the CASH-related
> accounts. This happens because processAmount treats a negative sale
> total as an exception when you don't provide an explicit value.
> Whether or not this is the right thing is debatable, but what is
> not debatable is that a negative value should be treated the same
> regardless whether it is supplied or generated. Therefore, to get
> me past one of my hurdles I simply made processAmount treat
> negative values as valid values.
>
> I don't have access to my local svn on this system so I've included
> the relevant change below...
>
> Looking closer at the POS handling of refunds, there is another
> painful deficiency (which would be solved by Ray's suggestion to re-
> implement using the Returns services - POS does not trigger the
> appropriate services to increase inventory when a product is
> returned/refunded.
>
> private static double processAmount(PosTransaction trans,
> PosScreen pos, String amountStr) throws GeneralException {
> Input input = pos.getInput();
>
> if (input.isFunctionSet("TOTAL")) {
> String amtStr = amountStr != null ? amountStr :
> input.value();
> double amount;
> if (UtilValidate.isNotEmpty(amtStr)) {
> try {
> amount = Double.parseDouble(amtStr);
> } catch (NumberFormatException e) {
> Debug.logError("Invalid number for amount : " +
> amtStr, module);
> pos.getOutput().print("Invalid Amount!");
> input.clearInput();
> throw new GeneralException();
> }
> amount = amount / 100; // convert to decimal
> Debug.log("Set amount / 100 : " + amount, module);
> } else {
> Debug.log("Amount is empty; assumption is full
> amount : " + trans.getTotalDue(), module);
> amount = trans.getTotalDue();
> // COMMENT OUT THE FOLLOWING 3 LINES
> //if (amount <= 0) {
> // throw new GeneralException();
> //}
> // END OF COMMENT SECTION
> }
> return amount;
> } else {
> Debug.log("TOTAL function NOT set", module);
> throw new GeneralException();
> }
> }
> }
>
> Iain Fogg wrote:
>> Ray, Jacques,
>>
>> I'm not going to disagree about Ray's recommendation to refactor
>> the code to use the Returns infrastructure, however, I'm up
>> against a hard go-live deadline and I suspect that would be too
>> much to do in the time available. Based on my testing, POS seems
>> to handle most things for basic sales and returns well enough.
>> Specifically, it calculates the right $ values (including taxes),
>> updates inventory properly, and hooks into the accounting ECAs
>> with the following exceptions (there might be more but I don't
>> know about them):
>>
>> 1. Refunds don't credit the correct default GL account (ie, the
>> issue that prompted this request for help)
>> 2. The INVENTORY and COGS accounts don't get updated. A while back
>> Si said that this was because the INVENT/COGS updates were
>> triggered off an ItemIssuance and presumably POS isn't doing this.
>> However, I looked through some trace last night and there is
>> definitely a call to one of the ItemIssuance services so I'm not
>> sure what's going on. I'll try to look at this ASAP...
>>
>> Thanks for the input on this, and if you've any other pearls of
>> wisdom to share, feel free to continue the thread :-)
>>
>> Cheers, Iain
>>
>> Jacques Le Roux wrote:
>>> Iain, Ray,
>>>
>>> Yes, I think that Ray is in the truth even if I did look at it
>>> seriously... I will try tomorrow...
>>>
>>> Jacques
>>>
>>> From: "Ray Barlow" <
[hidden email]>
>>>
>>>> Strictly speaking I don't think the POS system actually has any
>>>> support
>>>> for returns. The negative quantity "process" is really a work
>>>> around
>>>> rather than a planned feature for handling returns therefore I
>>>> would not
>>>> rely on any of its accounting and reporting impacts other than a
>>>> negative quantity and price in the order.
>>>>
>>>> The returns process used in the order manager screens didn't really
>>>> exist beyond concept I don't think when the POS system was
>>>> originally
>>>> done. In others words I suspect the correct thing to do is actually
>>>> recode the POS screens to make use of the returns services that
>>>> have
>>>> hopefully been exposed during the order manager development.
>>>>
>>>> Ray
>>>>
>>>>
>>>> Jacques Le Roux wrote:
>>>>
>>>>> Iain,
>>>>>
>>>>> Unfortunatly POS is not using much (actually any for the
>>>>> moment) verbose. Please see "trace" and "Debug." in
>>>>>
>>> PosTransaction.java.
>>>
>>>>> For the 1st point I have no quick answer. I will take a look
>>>>> ASAP...
>>>>>
>>>>> Jacques
>>>>>
>>>>> ----- Original Message ----- From: "Iain Fogg"
>>>>> <
[hidden email]>
>>>>> To: <
[hidden email]>
>>>>> Sent: Wednesday, November 29, 2006 5:45 PM
>>>>> Subject: Help with POS behaviour
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> If you process a customer return via the POS application, it
>>>>>> always
>>>>>> seems to think that the payment type is CASH, whether you
>>>>>> select CASH,
>>>>>> CHECK, or CREDIT on the payment screen. (In this context,
>>>>>> "payment" is
>>>>>> actually a refund).
>>>>>>
>>>>>> Consequently, the accounting ECAs are updating the wrong
>>>>>> account - CASH
>>>>>> IN REGISTER is credited instead of the default GL account for
>>>>>> whatever
>>>>>> "payment" method you select (eg, IN TRANSIT FROM CREDIT CARD
>>>>>> SUPPLIER
>>>>>> for a CREDIT CARD refund).
>>>>>>
>>>>>> Frankly, I can't see where the payment type is being set to
>>>>>> CASH in POS,
>>>>>> so I'm starting to suspect there may be an ECA further
>>>>>> downstream that
>>>>>> is assuming any negative amount (refund) needs to be handled
>>>>>> as a cash
>>>>>> transaction, but that's just because I'm starting to clutch at
>>>>>> straws :-)
>>>>>>
>>>>>> Also, can some kind soul tell me how to turn on verbose
>>>>>> debugging in POS
>>>>>> - setting the global verbose flag in
>>>>>> framework/base/config/debug.properties doesn't seem to do the
>>>>>> trick.
>>>>>>
>>>>>> Tips/pointers appreciated, Iain
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> No virus found in this outgoing message.
>>>>>> Checked by AVG Free Edition.
>>>>>> Version: 7.1.409 / Virus Database: 268.14.19/556 - Release
>>>>>> Date: 28/11/2006
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date:
> 29/11/2006