Hey Iain, Ray -
How's this going? Have you figured this out, or do you need some help?
On Nov 30, 2006, at 2:36 AM, Iain Fogg wrote:
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" <[EMAIL PROTECTED]>
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"
<[EMAIL PROTECTED]>
To: <[email protected]>
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
Best Regards,
Si
[EMAIL PROTECTED]
