Posted by
Ray Barlow on
URL: http://ofbiz.116.s1.nabble.com/Help-with-POS-behaviour-tp174892p174908.html
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):