Can you please settle remaining unpaid ticket and fully post both reports?
1 Like
OK we made a mistake while calculating service charge. Replace your report with that and it will work fine. Please keep in mind work period > service charge amount shows total from both paid and unpaid tickets. Our report shows totals for only paid amounts as it calculates from payments.
[Service Breakdown:1, 1, 1, 1]
>Payment|Net|Service Charge|Total
{REPORT PAYMENT DETAILS:P.Type,[$4-(($4*5)/105)];'#,0.00',[($4*5)/105];'#,0.00',P.Amount.Sum:(CA=Service Charge)}
>Total|{REPORT PAYMENT DETAILS:=[$3-(($3*5)/105)];'#,0.00',[(($3*5)/105)];'#,0.00',P.Amount.Sum:(CA=Service Charge)}
1 Like
I tried it still not matching. all tickets are closed no payment is pending:
Can you create a backup and PM me the zip file?
Please check I have messaged you the backup file.
There are 2 issues.
-1. Your current setup does not match to your definition.
You said when your cash sales is $4000 the service charge will be $200 but you don’t calculate service charge from discounted ticket amount. Here you can see service charge is almost %10 ($405) of payment amount ($4.405.)
-2. You applied rounding to service charge calculation.
When such rounding applied service charge won’t be exact %5.
I tried to find a solution from your comments but as @JTRTech tried to explain service charge calculations does not directly relates to how you settle ticket.
We can force calculating service charge from ticket total like…
[Service Breakdown:1, 1, 1, 1]
>Payment|Net|Service Charge|Total
{REPORT PAYMENT DETAILS:P.Type,[$4-(($4*5)/100)];'#,0.00',[($4*5)/100];'#,0.00',T.PlainSum.Sum:(CA=Service Charge)}
>Total|{REPORT PAYMENT DETAILS:=[$3-(($3*5)/100)];'#,0.00',[(($3*5)/100)];'#,0.00',T.PlainSum.Sum:(CA=Service Charge)}
However that won’t perfectly match to original service amount.
3 Likes
Emre,
You are correct, service charge doesn’t apply to discounts, and yes there is a rounding to the service charge.
How ever today, I have no discounts, so the net total in the new report for the cash and credit card payments should always be the same as the ticket total in the work period report. Why is the net total not the same?
Marked in Red, these values should be the same:
No, I just tried to explain how to calculate Service Charge amount. We found 107.50 but it is 108.00 actually because of rounding. More tickets may increase that difference.
If you look closely the report it does not use payment amount. It uses Ticket’s before discount amount to be able to find 107.50.
Also amounts you marked in red will not match when you have take-away tickets. I guess this is what you want.
[Service Breakdown:1, 1, 1, 1]
>Payment|Net|Service Charge|Total
{REPORT PAYMENT DETAILS:P.Type,[$4-$3];'#,#.00',([T.PlainSum]*5/100).Sum,P.Amount.Sum:(CA=Service Charge)}
>Total|{REPORT PAYMENT DETAILS:[$3-$2];'#,#.00',([T.PlainSum]*5/100).Sum,P.Amount.Sum:(CA=Service Charge)}
If it is still not the report you want please explain us in detail how you expect it to calculate so we can offer better solutions.
So far in the new report the service charge is fine (service charge should only display dine in only amount). I understand its not giving the rounding amount which is fine.
How ever, I would like the net for cash and credit card payments to include all dine and take away transactions without service charge.
Keep pushing the same thing despite being repetitively told you cannot achieve an acturate answer…
You cannot report service charge by payment type directly you can only calculate an estimate.
I am giving in trying to explain the reasoning as have tried to explain to you several times.
All you can do is estimate and thats before you throw rounding and discounts in there.
I am not interested in helping you create an estimate you will expect to be accurate an keep coming back everytime you see a difference.
I only work in finite numbers which I know are accurate.
@daftkam perhaps you shouldn’t use calculations at all since they will not be able to solve your needs. Maybe consider using Ticket Tags and tie them with Payment processed rule to capture payment type. Although it would be rather complex setup to achieve what your wanting and even then I have doubts it would work.
PS. you have yet to answer why you need this report? Is it some weird country legal requirement?
Thank you all for trying to help.
JTRTech, kindly refrain from outburst, we all have different understanding and approach and we are here to help one another.
Kendash, this is not a country requirement, it is a custom requirement for us. When we purchased SAMBAPOS it came with the sell point of custom reports.
So far what Emre has helped has achieved better part of the requirement related to service charges being displayed only for dine in. The only factor remaining is the net total of credit and cash transactions, which should include all transactions (dine in and takeway).
I thank you all in advance for your patience and assistance in this matter.
What outburst, I have been trying to help, if you look back most of the reply on your thread are from me trying to explain why you will never have a 100% accurate report for what your asking. I tried to help you link tags and services charge into a single flow but you showed little interest…
Either way, good luck with your setup.
1 Like
Thank you and I appreciate your help.
I am a little displaced with the calculations in here, where are the two variables $4 and $3 coming from? I tested and it works without declaring any variables like
@{xxxxxxx}
However i cant see where those variables are coming from, are they hard coded?
Wihtout looking too deeply I would take a guess that they are referring to columns, $n can be used in expressions at end to refer to columns of the report expression. That make sence with what you can see?
2 Likes
You are right i had no idea i was busy banging my head to make sense out of it, this is so cool!! I just tried it in this line
{REPORT ORDER DETAILS:O.ItemGroup,[$4];0.00,O.ExactTotal.Percent.desc,O.ExactTotal.Sum:(ODI=True)}
And it works!! Thanks i would have never guessed, i was so dogmatic in thinking that variables only come from ‘’@’’ declarations
1 Like
Here you can see a different example
1 Like