Posted by
Iain Fogg on
URL: http://ofbiz.116.s1.nabble.com/Help-with-POS-behaviour-tp174892p174905.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