Quick Service/Tables: Food/Retail Setup - Advanced Refunds | Aborts | NonTax Functions


Maybe I should consider a better naming system for my Transaction Types etc so you can understand my flow better. I should probably include External Payouts - Supplier Payment Transaction or Government Tax Payouts - State Sales Tax Transaction… something along those lines so Tax Transaction does not get confused with State Tax Transaction and the purpose of them.


Good Idea. Also, do all refunds in your system end with a cash payout or credit card transaction reversal?


I can see how someone would get confused trying to understand the Transaction Types if you do not have an understood knowledge of which one does what or which one relates to which transaction. I will try to do some renaming on them in future and upload the changed DB. Until then just do a little tracing of them through Payment Processors, Document Types , ticket types etc and it will make sense to you.


Right now yes. I plan to do item substitution as well but that will involve a slightly more complex system for it to calculate it right and still keep a reverse transaction method.


@kendash How can i Refund Service Charge? See below for Service Charge related components


You attach that SAME service charge to the Refund transaction type as it is essentially just a mirrored Sale transaction. Basically Sale and Refund both are doing the same thing… the only difference being the accounts they are putting money into.

basically you create that same service charge… and you create mirrored transaction types and create mirrored accounts etc. just put Refund in front of the names so you know the difference.

Study it closely it will make more sense to you. When you have a reverse transaction the word reverse often throws people off and technically is not the right adjective. You really are not reversing a transaction you are running another transaction the same way the first one ran… the money just goes into different accounts the accounts the money ends up in is how you know if its money in or money out.

So yes the outcome is reverse… you give money instead of take money… but as far as transaction is concerned its really not running in reverse. Hopefully I explained it a little better.

It has came to my attention we really need a basic simple accounting 101 documentation tutorial to help people grasp the accounting. Samba once again is unique that it even lets you mess with accounting most POS that is something which is hard coded and you never mess with it which limits its flexibility but makes it easier to support.

PS Another way to look at a Refund Transaction is: Its still a sale transaction the difference is the customer is selling the product we are buying it back.


@kendash Thanks for that. So what would be the Source Account & the Target Account for the Refund Service Charge Transaction ? I ask this because in my system, Service Charge is a Sales Account.


Refunds Accounts and Refund Receivables

PS It will all click in your brain and once it does you will be able to manipulate accounting like a pro. This exercise is getting you close to that.


@kendash :smile: That’s similar to what i used prior to getting your feedback. Except, i created a separate account called Refund Service Charge with account type Refunds Accounts . Was this separation necessary or could i have just used the already existing Refunds account with account type Refunds Accounts ? See the resulting Refund Service Charge Transaction Below:


You could have used the already created one… both ways will work… but if you want all refunds in one place you should use the one I created. essentially you are separating Refunds that do not have a calculation with refunds that do when you do that. However since ALL of your refunds use that calculation its an unnecessary separation.


Wait a minute i think we are getting some transactions confused. Which is probably my fault because my naming was not clear. Let me look at what you just posted a minute.

EDIT: OK look at my Refund Tax 1 and Refund Tax 2 Account Transaction Type. Your Refund Service Charge Transaction Should be setup exactly like those were. You can rename accounts to support your naming system since you do not name it Tax 1 or State tax etc. But the behavior would be the same.


[quote]You could have used the already created one… both ways will work… but if you want all refunds in one place you should use the one I created. essentially you are separating Refunds that do not have a calculation with refunds that do when you do that. However since ALL of your refunds use that calculation its an unnecessary separation

I get that but what puzzled me is the fact that you didn’t use the refunds account to refund the taxes, as seen below in the Refund Taxes Transaction screen

Why the different approach?


AH I see what you are getting at… its the (Credit) thats throwing you off? Why I put it there?

Ok let me explain something because I think you are relating how Sales and Refunds are working to how Tax and Tax Refunds are working. I setup Sales and Refunds transaction types differently than I did the Tax. I did the Sales so it would reflect Gross Sales… in otherwords I could have made it subtract the refund from Sales but I chose not too because I want to see Gross Sales (GROSS SALES = SALES BEFORE REFUNDS). I pull my Net Sales which is (Sales-Refunds) from custom reports…

Taxes I do not care about Gross Tax… I just want it reflected as Tax in Tax out… So I made the Refund Tax transaction actually balance out the Tax income lines… This way the actual Tax Income is NET TAXES.

Technically in actual accounting Net Sales is NOT just Sales-Refunds… I am simplifying it as I set it up in Samba.


Why didn’t you use Refunds Accounts as Source Account Type (Debit) along with Refunds account as Default Source Account for Refund Taxes Transactions ?


Because I an refunding the Tax I want my Tax incomes to reflect the refund. I did not want my Sales accounts reflecting the Refunds because I want to see Gross Sales in my accounting screen. Its just a preference.

LOOK AT SALES before and after a refund transaction… Sales stays the same. Most people might want sales to be corrected after a Refund and see ONLY NET Sales… I actually want to see Gross sales because I plan based partly on gross sales… I do not plan based on Refunds.

When I say I plan… I mean factors I use to plan promotions, Seasonal sales etc. I want to grow sales… I use budgeting techniques for planning around my expenses.

PS Read what Ive just said and then look over my structure really closely again. You will eventually see it… your getting so close to understanding it. I am actually teaching you in a round about way how to handle bigger complex budgets and how to use forecasting you just dont even know it :stuck_out_tongue:

Since I do not use Taxes as part of my Sales Growth Planning… I just want the actual Tax Incomes line reflecting Net Taxes so I know how much to pay out. So I have the refund crediting the Tax accounts vs creating its own Refund Tax accounts and separating it. I could have it separate it… but then I would need to figure Net Taxes through Custom Reports… its not as important to me so I skip that step and just let accounting show it.

PS: One more thing then I promise ill stop ranting haha. You will learn very quickly if you follow me very long. I run my businesses in the future. I do not run them day by day. I plan for EVERYTHING even the unknown which seems impossible… but I promise you its not. Before a work day starts I could almost tell you how well I will do that day with a very narrow margin of error. this is even accounting for unexplained events… you may ask how is that possible… I would say through forecasting… I am not guessing… i am using mathematically correct near exact measurements…This allows me to be in a place that nearly nothing surprises me or catches me off guard… it leaves me more room to focus on growth and keeps me competitive without chasing tails.

All that said… Samba is a tool I am using to support this vision. I am shaping Samba to work along with my forecasting and my planning style to grow my businesses. So you will see my system move along those lines.

Now what did this have to do with what you asked me? Well nothing directly but it does explain my motive behind my design which maybe will help you and others understand it better.


The reason is… Refunds Accounts and Refunds Account is for holding Refund Sales Transactions. If I put taxes in there then my total is reflecting taxes… I want JUST sales.


@kendash I think i have a better understanding of your rational/logic now for when to create a separate account type/account and when to use same/pre-existing one for a particular transaction ( on both the debit and credit side) .

You create a Refunds Taxes Accounts (debit) separate from the Refunds ‘Sales’ account to keep you Sales and tax figures separate. And you used the original Tax Accounts (credit) when refunding taxes to ensure that your Tax figure balances on the accounts screen.

You create a separate Refund ‘sale’ account (debit) and refunds receivables (credit) account so that your refund process does not deduct from your original sales figure.

Is there anything i’m missing?


That sounds correct. Hi Five!

Now I can explain how it relates to inventory. The way I did mine is probably not the most efficient… I made Refund Ticket TYpe a Pre-Order ticket so it does not affect inventory… I probably should have just use an action to do that… but toggling Pre-Order accomplished it without having to make an action/rule setup. The only downside is… if I do decide to not consider refunds as throw aways I will probably need to toggle that off and use Update Order for it.

PS: Once the accounting truly clicks with you… you will be able to do all sorts of amazing things. We virtually have full control over accounting… I have been kind of slow on designing my system lately focusing on helping people. I am about to hit mine heavy again and I will update this post with all my additions etc.


So what effect does this have on the Pre-Order property?


I did that so it would add it back in while using preorder ticket. So technically it is not considering throw away atm. To make it consider Throw away just take that action out.

PS TO be honest I think I was doing some testing with that. I am not sure how it ended up affecting it due to Pre-Order being selected.

The behavior of my Refund… is it does Decrease False to original ticket… Meaning it did not take it out of inventory but I believe i did NOT put Increase = True. I did this because I wanted the strike through on the returned item to show on the original ticket.