Help with POS behaviour

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with POS behaviour

Iain Fogg
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

Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Jacques Le Roux
Administrator
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" <[hidden email]>
To: <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Ray Barlow
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" <[hidden email]>
> To: <[hidden email]>
> 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
>>    
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Jacques Le Roux
Administrator
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" <[hidden email]>

> 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" <[hidden email]>
> > To: <[hidden email]>
> > 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
> >>
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Iain Fogg
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" <[hidden email]>
>  
>> 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" <[hidden email]>
>>> To: <[hidden email]>
>>> 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

Reply | Threaded
Open this post in threaded view
|

Views Ofbiz.

Chandresh Turakhia
In reply to this post by Iain Fogg
Hi ,

Should view-entity create views in the database.

I do not see any views in the database ( oracle ).

Chand

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

Jacques Le Roux
Administrator
No it don't, it's on the fly

Jacques

From: "Chandresh Turakhia" <[hidden email]>
> Hi ,
>
> Should view-entity create views in the database.
>
> I do not see any views in the database ( oracle ).
>
> Chand
Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

David E Jones-2

http://incubator.apache.org/ofbiz/docs/entity.html#View_Entity_Modeling


On Nov 30, 2006, at 12:29 AM, Jacques Le Roux wrote:

> No it don't, it's on the fly
>
> Jacques
>
> From: "Chandresh Turakhia" <[hidden email]>
>> Hi ,
>>
>> Should view-entity create views in the database.
>>
>> I do not see any views in the database ( oracle ).
>>
>> Chand

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

Ashish Vijaywargiya-2
In reply to this post by Jacques Le Roux
Chandresh,
 
If you want to see the view-entities you can take a
look into Webtools --> Entity Data Maintenance page.
 
Regards
Ashish Vijaywargiya

--- Jacques Le Roux <[hidden email]>
wrote:

> No it don't, it's on the fly
>
> Jacques
>
> From: "Chandresh Turakhia"
> <[hidden email]>
> > Hi ,
> >
> > Should view-entity create views in the database.
> >
> > I do not see any views in the database ( oracle ).
> >
> > Chand
>



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Iain Fogg
In reply to this post by Iain Fogg
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" <[hidden email]>
>>  
>>> 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"
>>>> <[hidden email]>
>>>> To: <[hidden email]>
>>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Iain Fogg
I take it back - the inventory (ATP/QOH) is correctly updated for sales
and refunds in POS

- Iain

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" <[hidden email]>
>>>  
>>>> 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"
>>>>> <[hidden email]>
>>>>> To: <[hidden email]>
>>>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Ray Barlow
In reply to this post by Iain Fogg
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):
Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Iain Fogg
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

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

cjhowe
In reply to this post by David E Jones-2
Chand,
What are you trying to accomplish, perhaps we can
describe a work around for you.

David,

No matter how many times you link to that excellent
write-up, it does not answer that question.  


--- David E Jones <[hidden email]>
wrote:

>
>
http://incubator.apache.org/ofbiz/docs/entity.html#View_Entity_Modeling

>
>
> On Nov 30, 2006, at 12:29 AM, Jacques Le Roux wrote:
>
> > No it don't, it's on the fly
> >
> > Jacques
> >
> > From: "Chandresh Turakhia"
> <[hidden email]>
> >> Hi ,
> >>
> >> Should view-entity create views in the database.
> >>
> >> I do not see any views in the database ( oracle
> ).
> >>
> >> Chand
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

David E Jones-2

On Nov 30, 2006, at 8:03 AM, Chris Howe wrote:

> David,
>
> No matter how many times you link to that excellent
> write-up, it does not answer that question.

Joins are mentioned various times in that write-up. If you read the  
whole section I'm not sure how you could miss it. Here is one example  
copied from that section of that document:

"To represent an outer join you can specify in a view-link element  
that the related entity is optional using the rel-optional attribute,  
which can be either "true" or "false", and of course defaults to  
"false". The Entity Engine will generate ANSI, Oracle Theta, or MS  
SQL Server Theta style join code depending on the setting in the  
entityengine.xml file. See the Entity Engine Configuration Guide for  
more information."

-David

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

cjhowe
Yes, but the question was...
Should view-entity create views in the database?



--- David E Jones <[hidden email]>
wrote:

>
> On Nov 30, 2006, at 8:03 AM, Chris Howe wrote:
>
> > David,
> >
> > No matter how many times you link to that
> excellent
> > write-up, it does not answer that question.
>
> Joins are mentioned various times in that write-up.
> If you read the  
> whole section I'm not sure how you could miss it.
> Here is one example  
> copied from that section of that document:
>
> "To represent an outer join you can specify in a
> view-link element  
> that the related entity is optional using the
> rel-optional attribute,  
> which can be either "true" or "false", and of course
> defaults to  
> "false". The Entity Engine will generate ANSI,
> Oracle Theta, or MS  
> SQL Server Theta style join code depending on the
> setting in the  
> entityengine.xml file. See the Entity Engine
> Configuration Guide for  
> more information."
>
> -David
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Si Chen-2
In reply to this post by Iain Fogg
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" <[hidden email]>
>>>
>>>> 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"  
>>>>> <[hidden email]>
>>>>> To: <[hidden email]>
>>>>> 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
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Help with POS behaviour

Iain Fogg
Si,

In the long term, POS will have to be refactored to use the Return
services to do this correctly. In the short-term, the fix described
below works (at least better than not having the fix). At the very
least, negative amounts in POS are now treated consistently. At best,
returns/refunds almost work well enough to say you could live with the
current implementation for now. The only problem I found was that an
inventory item gets created for the returned item, but the unitPrice
field was set to 0.0 instead of the (a) supplier's lastPrice.

I'll have another look at returns using the Order Manager, but I think
the last time I did that there were problems with handling off-line
payments.

Cheers, Iain

Si Chen wrote:

> 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" <[hidden email]>
>>>>
>>>>> 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"
>>>>>> <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> 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
> [hidden email]
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.15.3/562 - Release Date: 1/12/2006
>  



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.3/562 - Release Date: 1/12/2006

Reply | Threaded
Open this post in threaded view
|

Re: Views Ofbiz.

Chandresh Turakhia
In reply to this post by cjhowe

Dear all,

Quikie question : Where can more info on this ?

Keen on pointers for "Oracle Theta" . More interested in generating SQL for
Oracle Specific stuff " For Update of " , "Connect by".

Went thru code , may be I am missing something : I could not find switch
based on database type. Where the does the generator check for the database
type

Chand


"To represent an outer join you can specify in a

>> view-link element
>> that the related entity is optional using the
>> rel-optional attribute,
>> which can be either "true" or "false", and of course
>> defaults to
>> "false". The Entity Engine will generate ANSI,
>> Oracle Theta, or MS
>> SQL Server Theta style join code depending on the
>> setting in the
>> entityengine.xml file. See the Entity Engine Configuration Guide for
>> more information."


----- Original Message -----
From: "Chris Howe" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, November 30, 2006 10:28 AM
Subject: Re: Views Ofbiz.


> Yes, but the question was...
> Should view-entity create views in the database?
>
>
>
> --- David E Jones <[hidden email]>
> wrote:
>
>>
>> On Nov 30, 2006, at 8:03 AM, Chris Howe wrote:
>>
>> > David,
>> >
>> > No matter how many times you link to that
>> excellent
>> > write-up, it does not answer that question.
>>
>> Joins are mentioned various times in that write-up.
>> If you read the
>> whole section I'm not sure how you could miss it.
>> Here is one example
>> copied from that section of that document:
>>
>> "To represent an outer join you can specify in a
>> view-link element
>> that the related entity is optional using the
>> rel-optional attribute,
>> which can be either "true" or "false", and of course
>> defaults to
>> "false". The Entity Engine will generate ANSI,
>> Oracle Theta, or MS
>> SQL Server Theta style join code depending on the
>> setting in the
>> entityengine.xml file. See the Entity Engine
>> Configuration Guide for
>> more information."
>>
>> -David
>>
>>
>
>