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