Hi Vince, Eva I had a quick look and the problem seems to be that there is no inventory information in the retail facility, this means that when an order (sale) is processed no inventory is issued and when the order is returned there is no inventory information to receive the items against, so the return status stalls at accepted rather than proceeding to returned. This seems strange because you can manually receive the return without any problems as the system just creates a new inventory item and receives against it.
If you create inventory items for your retail facility most of the problems should go away. I'm not sure that cash/check refunds have been implemented in pos but at the very least any cc transactions should be refunded. Regards Scott On 03/12/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote: > > We should not have to complete refunds on the central server. the POS > terminal should do a proper refund and either refund the CC that was used to > pay for the order or kick out the cash drawer if it was paid by cash or > check. I would expect that it uses the same refund code as ordermgr for > refunding a credit card, handling inventory, etc. > > > Vince Clark > Global Era > The Freedom of Open Source > [EMAIL PROTECTED] > (303) 493-6723 > > ----- Original Message ----- > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > To: user@ofbiz.apache.org > Sent: Saturday, December 1, 2007 3:00:33 AM (GMT-0700) America/Denver > Subject: Re: Refunds in POS > > > Note that we are also running entity sync. Transactions occur on POS > terminals and are then pushed to Master Central Server. > > > > When a return is done at a POS terminal we need the transaction to go > from start to finish, including refunding the credit card if > that payment method was used. > > > > Are you suggesting that we would need to wait until the return is pushed > to the MCS and then change its status? > > Yes this should work, as it works on a sole instance. > > Jacques > > > > > Vince Clark > > Global Era > > The Freedom of Open Source > > [EMAIL PROTECTED] > > (303) 493-6723 > > > > ----- Original Message ----- > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> > > To: user@ofbiz.apache.org > > Sent: Friday, November 30, 2007 2:20:20 PM (GMT-0700) America/Denver > > Subject: Re: Refunds in POS > > > > Did you read my message ? > > > > Jacques > > > > De : "Evangelina Bowman" <[EMAIL PROTECTED]> > > > > > > Thank you for your replies. I'm currently trying to verify whether the > VOID > > > SALE in the POS Manager screen is properly tied to the OfBiz refund > > > functionality. We will be using refunds for orders paid with a single > > > payment method. > > > Has anyone tried to refund/void orders via POS? If so, what steps > should > > > the POS clerk take to properly generate a refund? > > > > > > > > > BJ Freeman wrote: > > > > > > > > I believe Si is zeroing in on this in his jira > > > > https://issues.apache.org/jira/browse/OFBIZ-1454 > > > > might want to add your comments > > > > > > > > Evangelina Bowman sent the following on 11/29/2007 4:36 PM: > > > >> When using the VOID SALE button from the Manager screen to void an > order, > > > >> I > > > >> enter the order number and get the confirmation that the order was > > > >> voided. > > > >> However, when I check the order in order manager there are no > changes. > > > >> Customer refunds were NOT generated in Payments either. > > > >> What is the best method to generate Refunds in POS? Old POS > documentation > > > >> (July 2005) describes the refund process in POS as a MINUS QTY > > > >> transaction. > > > >> Is this still true? > > > >> > > > >> Thanks, > > > >> Evangelina > > > > > > > > > > > > > > -- > > > View this message in context: > http://www.nabble.com/Refunds-in-POS-tf4900924.html#a14093705 > > > Sent from the OFBiz - User mailing list archive at Nabble.com. > > > > > > >
