Ray,
You're right about the handling of the return. In fact, while it appears
that the current implementation adjusts the inventory correctly, it
doesn't. Specifically, it creates a new InventoryItem for the return,
but sets the unitPrice to 0.0. Assuming I keep the item in inventory (no
damage etc), the a future sale will chew up that inventory item, but the
accounts will not be debited/credited correctly since the unitPrice is 0.0.
That's just one problem I spotted - I expect there are more.
BTW, I have done some testing with OrderReturns in the OrderMgr, but I
seem to recall having some trouble with that, especially for
cash/offline CC refund methods. I'll have to investigate further to see
if it was user error or not.
Cheers, Iain
Cheers, Iain
Ray Barlow wrote:
Understandable you don't want to do proper returns now, we are all
constrained by time so some things have to wait. Yes debatable on
whether it should handle negatives but I would agree it should be
consist for both supplied/generated.
Re inventory and returns you don't always want to do an increase
especially for faulty goods which usually result in credit notes from
the manufacturer. Sorry just another little area the POS "returns"
feature falls short, but it will get there some day if we keep going on
it...
Ray
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):
--
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
