I’ve viewed the tutorial on creating a refund button. However, it did work as I hoped (or didn’t seem to anyway).
My scenario is this: I have a regular customer. He was sitting on table 6. I had a new customer sitting on table 2.
Table 2 ordered a fish and chips. I absent mindedly put it as an order under table 6. Table 6 closed its tab. When Table 2 closed their tab, I noticed they had a fish and chips missing and figured out what happened. I added the Fish and Chips to Table 2’s tab so they closed out at the correct amount.
How can I create a refund button that essentially works as a negative sale or reverse sale? That is I would be able to reduce my sales total and increase my inventory (only one fish and chips went out the door even though I punched in two total for the day). It isn’t important that I link it to a customer account or that I link it back to the closed table (since it is my understanding a closed table is closed forever).
Its certainly possible. You would have to build an accounting system to support it. I have a reverse sale system setup in my database that I posted earlier today.
What you are asking for is slightly different but the concept is the same. You would create a new ticket and reverse sale it. The reverse sale system in my database uses existing tickets and changes them to Refund Ticket, I am waiting on a couple feature changes to implement my item per item version.
However you could still setup a reverse sale system the same way I setup mine the difference you would make is put your refund button visible on new tickets where mine is not. And you would probably need to change how it handles the tickets because mine is designed to change a ticket instead of create new one.
Bottom line the answer to your question is a big YES. You need to get very familiar with Accounting because to do it you have to build its own accounting from start to finish with a refund payment type its own taxes etc.
Do you have a link to your post?
And I’m pretty familiar with accounting (I teach it) though it doesn’t appear that debit and credit in Samba mean quite the same thing as they do in GAAP accounting.
Here ya go. Read it carefully it is a complete database. You should probably install it onto a different test system and just use it as reference to see how to build yours.
Its not the same thing. Debit and Credit in Samba Accounting screen is specifically for how the documents relate to each other and how transactions relate. It is NOT traditional accounting and if you try to use traditional accounting logic your going to fail miserably.
Instead approach it like a programming language. Document A put money in position B DOcument D took money from POsition C and put it in POsition F of account Z
Forget Credit and Debit as accounting terms they are strictly just places money goes according to where the transactions send it. Basically what I am saying… you could replace the words Credit and Debit with any word and it would still run the same. In accounting Credit and Debit have predefined definitions in Samba those 2 words are just words…its not a direct relation on the actual moneys behavior.
Rightio. So essentially an account is debited when it goes down, (customer account is debited goes down with customer account payment) and credited when it goes up (cash account is credited or goes up with customer account payment)
No Debit and Credit are simply placeholders for the transactions to put value. If a Transaction puts a value in credit and you want to decrease that value you can make a transaction put an amount in Debit… BUT you could also do it the other way around… you could have a transaction PUT money into Debit and then another one take it out by putting money into Credit. Balance is difference between the two. Whichever direction your using them dictates if the balance will be (balance) or balance.
You can use custom reports to get a traditional accounting view. The accounting screen is more of a view of its programming.
Its little more complex than that. You would need to mirror the setup for payments… this includes receivables etc.
You should have a refund receivables. refund Sales, Refund Payments, Refund Taxes etc.
To do it right and get it to track it correctly you have to completely mirror the primary sale method. This includes taxes etc. So you would also need new tax calculations specific to refunds.
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 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.
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.