Ticket has now changed to a refund ticket, ticket header has update and turned red, the order state has become the return reason, in this case Past Sell By Date and the refund payment buttons have become active with all other payments buttons being removed.
Adding more orders will mark each one as a refund, with the refund reason and will either add it back into inventory or not depending on your answers to the ask questions that appear. Order lines that are NOT added back to inventory have a line through them on the ticket screen
When refunding the refund amount confirmation screen appears (same as the change screen for sales), this full size screen is available in V5 using the ask questions and setting the colour in the transparency setting. For V4 it is a banner across the middle of the screen
@RickH I like the way you have created this, especially since you have set up a refund receipt which most other solutions I have seen on here doesnāt. Iāve used one of the other tutorials for refund based on reopen closed ticket for a few clients and the main feedback I get is there is no proper refund receipt produced, so your method solves that one point.
However one concern I would have with this setup is you are refunding blindly, rather than either amending or linking to the original ticket where the products were purchased. I think in the UK especially if original purchase was by card then the refund should go back onto the card, but unless you link to the original ticket you lose the data as to which refunds match with sales.
Also, how about exchanges - like I guess in your scenario someone changes their mind between cheese & onion and ready salted crisps?
How do you figure you lose data? Can you elaborate on what you mean?
I think I see what you mean. I built a refund system that RickH based his off of but he went a different route than mine. I actually amended the original ticket but transacted the refund through a new refund ticket. I never wrote an actual tutorial I just offered the pre-built database. I consider it sloppy for my standards now it was my first big project but if you want to see how it works take a look here.
For exchanges you just refund then do a new sale, in my set up they would be two separate transactions
Like kendash said i used his original idea for inspiration and went down a different route, more of an ad hoc refund process. I know what you mean about linking to the original sale but that relies on customers keeping hold of their receipts so we can easily find that sale, otherwise we would have to manually go through previous tickets to try and find it and like you mention, if a customer wants to change a packet of crisps for a different flavour that just isnt practical for the actual price if the item, i would just refund as cash and resell new packet. That corrects stock levels and customer isnt kept waiting for ages while we try and find a previous transaction for the sake of 80p
The next step is to create what you suggest so i would have two options for refunds, an ad hoc refund (my current set up) and a receipt refund where the customer has the original transaction receipt to quickly bring up the original sale and amend that ticket like kendash first used
Thatll take me a while to implement and isnt something i need straight away but is on my list of things to eventually do
I know what you mean about finding out original payment method as ideally if they paid by card the refund should be by card, the other option is if they dont have the original receipt for proof of purchase then they can get a ācredit noteā by just creating a customer account and refunding as account so they have an available balance to use on next purchase
Again i dont feel that is practical for my set up when were only talking about a couple of pounds here and there, if i was doing a high value electrical type setup then linking to original receipt would have been the first refund setup i would have implemented
That said, in the future refunds linking to original transaction is on my to do list, just not in the immediate future (although you have made me start to think about a few ideas lol)
Thanks for the feedback on my setup its always good to have other peoples ideas to help create something that other people will benefit from and to improve set ups
@kendash yes you are correct that is what I was meaning about losing data
Yeah I saw your pre built database on the forum, I downloaded it but never got around to installing it . One main reason I was looking at it was about the way you handled refunds, because I followed this tutorial:
which worked but I didnāt like the fact you couldnāt print a proper refund receipt, and when you settled, whatever is added overwrites the original payment, so if you have any complex payment (i.e. multiple payments on ticket) or if the staff forgot the original payment type when settling, it is not straightforward.
So am I right to say the only way I can really get a proper refund receipt is to have a new ticket for the refund?
And I guess another indirect question related to above, do you know if there is a way to re-open settled ticket then settle again but not lose the previous payments (i.e. to avoid mistake or not lose complex payments as I refer to above)?
Not entirely just depends. Problem with changing the original ticket is if someone doesnt refund all items on ticket. So you would need a new ticket to print a refund receipt. You can copy items from original receipt and mark the ones refunded which is what I do.
BTW take a look at this action. This is the main action I use in my refund system.
The actual automation is fairly simpleā¦ setting up accounting and inventory is the harder part.
PS: I am rewriting my original refund system and will post an update when its done but right now I am deep into my TimeTrex integration still. @RickH has a great system too hopefully his will solve your needs.
. One main reason I was looking at it was about the way you handled refunds, because I followed this tutorial:
