http://ofbiz.116.s1.nabble.com/Help-with-POS-behaviour-tp174892p174910.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
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 29/11/2006