Ok. So essentially need to add multiple Refunds under transaction types…Sounds like that anyway.
EDIT: Because if I need to map one transaction type to multiple different possibilities I off hand do not see a way to do that.
Taxes are at this point manually computed (Consumption tax fairly easy to do) on the actual accounting software. So I’ve no need to worry about reversing them.
You would have a few transaction types yes. You have Sales, Payments, Receivables to reverse it you would need Refund Sales, Refund Payments, Refund receivables. And mirror taxes if your using tax templates but it sounds like your not using tax templates.
How are you manually doing taxes?
Just remember you cannot think of SambaPOS accounting screen as actual accounting… Its specifically for SambaPOS transactions/documents.
I’m doing this for a mate in Tonga. They pay a flat consumption tax. We include tax in the price of item. Then when sales are entered in separate accounting software, we do a little math to pull the tax rate out of item. Simple example: If a item cost $27.5 and Consumption Tax is 10% then the sales are 27.5/1.1 and taxes due are difference between sales and purchase price.
I see. I would think it would be easier to just put a 10% Tax Template and have tax separated per sale into its own account. But I also know that not everyone does it the same. So nothing wrong with how your doing it.
That would make one less step for your reverse transaction.
I have one last question. Will mucking with default debit credit rules make it a negative entry in work period report?
For Cash Sales
Presently: Refund Account has Rule Set as Default in Manage>Accounts>Account Types
And Refund Transaction is set to credit Sales Returns (increase hopefully) and debit (reduce) Cash
However, when I process a refund, it increases total sales for the day. So if I accidentally charge someone $25 for a plate, now after refund my sales are off by $50.
Your still looking at it wrong. You are not mucking with default debit credit rules. Refund runs separate from Sales.
You have to get traditional accounting out of your mind when your designing accounting in SambaPOS. I wouldn’t even attempt it until you get a full understanding.
If your refund process increases sales then you built the accounting wrong. Debit does not always mean its reducing. Until you get this understanding you will not be able to build it correctly.
I would advise you to really study it. If you can get my db to work on a test system then look at how I am doing reverse transactions and look at the accounting. You can make it read almost anyway you want when you have a full understanding of it.
The short answer to your question is no if you build it right your work day reports will be 100% accurate furthermore you can build some very nice Custom Reports to show even more detail.
I (think) I understand it.
I have just been looking at the transaction I want to reverse. When I make a sale it debits (Source ) sales and credits receivables (target). According to Samba; actual accounting is exact opposite.
So in my refund transaction I had sales as the target rather than source. Yet switching this seems to not do anything in particular. Guess I just need to read up.
No in actuality the way it works… When you make a sale it creates a transaction… the first transaction is Sale Transaction… it puts the money into the Sale account (credit) Its a credit because the Sale Transaction is setup to put money there. Your ticket type is setup to use Sale Transaction. For refunds you would make Ticket Type Refunds and for its transaction it would use Refund Transaction instead of Sale Transaction. OF course it all depends if you setup your accounts right.
You can follow it down the line from there based on your Transactions. If you told Sale Transaction to put money in debit first… it would.
You are still trying to look at it as conventional accounting…
It works with conventional accounting but when you build it you cannot think of Credit and Debit in the traditional sense… its simply places for transactions to put money.
Maybe this will help a little
(balance) = negative
balance = positive
Lets say I have item A with a value of $54. When I sell it… that value of $54 walks out the door so my Sales balance would be ($54)
My payments Balance would be $54 because that is money that replaced the sale value. Money out money in.
receivables should always balance to 0 because it is not an actual MONEY account.
Cash should always be positive balance unless you take money out of the drawer with a transaction.
A refund would reverse it… and it would show in your sales by increasing the sales balance but decreasing the actual sales dollars.
It would decrease the numbers in receivables but balance would still be 0
Refund receivables numbers would go up but again balance = 0 because its not an actual money account.
Refund payments would show a positive amount but it would Decrease your actual Cash Drawer balance because it is now running through refunds accounting for tracking. This is for tracking purposes since Refunds Payment account is not the actual till like Cash payment account is.
What I am about to say is very important and I think this is what gets most people hung up.
The accounts screen is NOT an accounting report… you can read it as one if you know how to interpret as such. But it is not an accounting report. It is a process.
Ok I will stop now. If you get anymore questions I will try to answer them but I think we need to step away from this for a bit. Just study it and study it extensively it will pay off.
**The way it should work is:**
**You would have the following Account Types:** Refund Accounts, Refund Receivables, Refund Payments, Refund Taxes(If you use Tax Templates)
**You would have the following Accounts(Account Type/Account):** Refund Receivables/Refund Receivables, Refund Accounts/Refunds, Refund Payments/Customer Refund, Refund Tax Accounts/Refund Tax(If you use Tax templates)
**You would have the following Transaction Types:** Refund Transaction, Refund Payments Transaction, Refund Tax(If you use tax template)
Define `Refund Transaction` in your `Refund Ticket Type` (Make Refund Ticket Type if you have not)
**Create Payment Type called Refund:** Account transaction type would be Refund Payments Transaction Account would be Customer Refunds
I left out some smaller details but that would be the general process.
When I said you would have to design entire accounting process around refunds… that’s what i meant. You cannot mesh it with Sales, Cash or any of the other existing accounting it will not work as a reverse transaction.
Now the important part! Since I established that the Accounting view in Sambapos is NOT an accounting report when you look at the refunds portion if you try to read it like a report it will look like your just selling stuff again… That is because Accounting in Sambapos is not an accounting report its the process the accounting uses.
If you look at the actual accounting reports (Work Period Report) or custom reports you may make it will read correctly. It will show Sales, Cash with accurate values and it will show Refunds, customer refunds with the amounts refunded.
You would define if it puts inventory back in or not through Update Order action.
I will say it once more because hopefully people reading this will finally understand. Accounting screen in SambaPOS is NOT a report of your accounting… It is the actual process SambaPOS is using to calculate the accounting… Your accounting reports are the Work Period Report or any custom reports you make. You can read the Accounting like a report and organize it via screens if you understand how to translate it.
I built a complete reverse sale refund system in my latest DB release. If you want to look at it you could incorporate parts of it that you like into yours.
Alright. So I got a refund system that seemed like it was working. Until I found that all the tickets I processed as Refund Ticket Types are not settling and seem impossible to close.
They have $0 balances.
Adding an item and trying to pay cash doesn’t do anything.
Consequently cannot close work period.
look at the PreMade databases forum category… download my database … it has a working refund system. You can choose what you want out of it… or learn how I did it and then build it in your own.
It gets a little complicated because you ahve to Change Ticket Type in middle of a transaction… etc… It would be really hard for me to explain it to you… My database I posted is 100% working with a full reverse transaction refund system… supports single item or partial refunds as well. Just backup your db… install mine and check it out.
Alrighty. I managed to close the tickets, turned out that somehow the refund tickets were not linked to tables/customers. Possibly a mapping error. Anyway, opening the ticket and selecting a customer did the deed.
Your accounting all coming out ok? It took me a couple weeks to get my Reverse Transaction Refund system working flawlessly… I ran into all kinds of issues. I built mine so it doesnt change sales… because you really do not reverse sales when you refund something… you reverse your income but if you reverse a sale then your skewing your gross sales.
So i had mine reduce cash but not sales. THis way I can still track Gross sales.
Share some of yours if you dont mind. I love seeing how other people implement stuff. I might learn a new trick or two 
Will do. I am still cleaning edges on a test system, but when it is in production state I will share it.