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
