Is there a tag in {Report Order Details} to display the payment type name?
This is the csv export i want to use it in:
LoyaltyCardCustomer,Date,Time,TicketNumber,ItemName,Quantity,Price,LoyaltyCardMember,CustomerName,Tax,Payment Type
{REPORT ORDER DETAILS:
EC.LoyaltyCard.Customer Name.asc,
FD([O.Date],'yyyy-MM-dd'),
O.Time,
T.TicketNumber,
O.MenuItemName,
O.Quantity,
O.Price,
EC.LoyaltyCard.Name.asc,
EC.Customer.Name,
tag goes here
:(ODI=True) :"{0}","{1}","{2}","{3}","{4}","{5}","{6}","{7}","{8}","{9}"}
I know that it can be filtered by Payment Type so this should be quick fix.
Are you sure?
You can probably filter by ticket payment type but payments are ticket level NOT order level.
There is nothing specifying a payment type to a specific order…
For example if a bill is split 50/50 and paid half cash and half card, what orders are paid in cash and what in card and on a 50/50 split this would unlikely be a matching amount to a combination of orders so if one order paid part cash and part card?
Maybe if you can explain why you need to know at order level what payment was used a alternative suggestion might be possible.
Yes, I tested with (TPT=Cash), and it only showed me the cash transaction.
I need this info on a csv so that i can email it to the accountant at the end of the day.
Would display payment details help here?
TPT = Ticket Payment Type.
As I said you are reporting ticket payments so all orders on a ticket containing at least one cash payment.
Ie it could be a £100 ticket paid with £1 cash and £99 card but all orders on that ticket will be included.
As I said there is no direct link between orders and payments.
If for example you were to list orders in sections by TPT so each table of orders was for different payment type the totals of the tables would not necessarily add up to total sales as orders could be reported under multiple payment types for the reasons mentioned above.
No, please read my comments above again…
There is NO direct link between orders and payments.
The only way to achieve this acurately would be to force every ticket to only be one single payment of a single type and have no idea or interest in how that could even be attempted.
I myself have had this same conversation with at least two other people on the forum and personally don’t see what is so hard to understand.
For the reasons mentioned above you cannot directly link orders and ticket payments.
Additionally those people also said ‘it’s for the accountant’.
I hate to presume but why does your accountant need to know the loyalty card customer name and customer name on a ‘non account’ transaction?
This request from an accountant is BS, as this is not a samba problem it is a pure practicality.
IF A SOFTWARE ALLOWS MULTIPLE PAYMENTS PER TICKET/SPLIT PAYMENTS THERE IS ABSOLUTLY NO WAY IT CAN ACURATLY REPORT INDIVIDUAL ORDERS AGAINST PAYMENTS.
As mentioned the only posible solutions to come remotely close to a real and accurate report would be;
Prevent multiple payments, single payment per ticket would mean reporting ticket payment type should be viable (although not direct reporting it should return a acurate value)
Only ever split a ticket by order value. Use something like kendash advance split payment a while back to automatically split a ticket by orders on going to payment screen. This would allow split payments but only by order combination amounts (not 50/50 or 5 ways etc) and would split the ticket into multiple tickets meaning that as previous point each ticket only had a single payment.
Merit her if these sugestions are ideal and personally not interested in entertaining them as a real world solution.
I personally would go back to my accountant and find out why they are making such a request which is impractical and not a value which any software is going to report with any accuracy.
I understand what you’re saying here. This CSV export is built off of the Item Sales Report, so it is using Orders and Item names, however these are not linked to the payment type, the ticket is, so to get a report that does display payment type, it will have to be separate and will not display item names, and will be per ticket.
Concerning the accounts, we only use them to keep track of sales and they aren’t used to do purchases from, so if no account is selected an empty box is good enough.
Thank you for answering my question, and pointing out some issues with this report itself.
Entities would be valid against orders as you can only select one entity of a particular type against a ticket so there is a direct relation between order <-> ticket <-> entity.
Payments is separate issue as you can have multiple payments per ticket.
while you may generally only have a single payment per ticket the fact that there inevitably will be multiple payments makes any report of this type inaccurate/unreliable.
if you were looking at averages or say trying to see a pattern in particular products being purchased using a specific payment type it could be useable with a pinch of salt but you would never really have a solid report you could use for proper accounting.
People usually try and claim that their local government required this type of breakdown or they claim they need to know the cash/card split of tax but usually they have just misunderstood as this type of analasis is not practical or viable in this type of business and government know that - in all honesty why would they even care if a ticket was paid in cash or card so long as your tax declaration is correct you owe them that much anyway and thats all they will care about - getting the tax money from you.
As you said the inaccuracy/unreliability of what I first looked at would be problematic, so I will just use this to cross reference between the two, and build a more accurate outcome. Thanks for the help.
