-
Notifications
You must be signed in to change notification settings - Fork 414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VoidTicketAction added #326
base: master
Are you sure you want to change the base?
Conversation
- Reports changed to not include Voided Ticket
…voiding them also on TicketTypeID
Now also VoidTaxTransaktion can be mapped against the VoidTicket |
Hello Wolfgang. Good idea. I've tried similar feature before so we can merge our ideas. This is what I'm thinking about this.
And... Sorry for the long comment :) |
My test database for refund tickets. |
5-7 I didn't konow about this negative amount trickery so I agree that I only have to set a negative amount to the orders to reverse the transactions. I'll incorporate this behavoir to my next commit. 8 I'll look into that new feture.
For the void-ceaters: If somebody want's to cheat the taxmen he would blantly delete the tickets, orderes and transaction in the DataBase and would do other SQL-Wizardy to hide this. To not have the option to void plain wrong tickets doesn't stop them. As it goes for a tax-audit here in Austria you have to explain every and all void-Tickets to the taxman in detail if there are unusual ammounts of them and if he isn't satisfied with the explanaition he won't do unnessesary voids ever again because of the hefty fines he got the last time. The refund thing could always be missused for this purpouse. With this VoidTicket-Action it's clear what thicket was voided and why (if you add a sufficion description) so it would be better with the taxmen where you don't "hide" your plain wrong tickets in refunds. |
As for the english word "gift": I would use "discount" or "tip" (if the customer gives some money for the good service) The word "gift" reminde me of the well wrapped christmas-presents under the christmas-tree on christmas-eve ;-) I think in arabic-cultures there are no diferent words for these meanings and all get translated to gift in dictionaries. Thought its true there is the restaurant-owner who gives a gift to the customer (in the meaning sense) but in sales the word discount is used. A gift or freebee in the western culture has often the meaning of low value and a discount means that you haggeled for a high value product and got a not so high price for it. Some (dump) people favour high dicsounts over producs without any discounts even if the product with the discount detrackted is more expensive than the product without getting any discount by anonther seller. |
Hello Wolfgang. Yeah I know I'm no too good at English. I agree there might be errors and we can fix that. Your approach to the problem is great but the only issue with your solution is removing voided tickets from past reports. Let me tell my thoughts about that. As I know from my experience there is no "error correction" if we think from the financial perspective. For example you create an invoice and deliver some goods. If there is something wrong (or anything else) you receive a refund invoice (or return invoice) and recreate a new invoice. Refund term comes from here. You do not void the invoice or do not do something that filters out that invoice. You just create a new transaction. Voiding is something rare. Most of the time it happens because of typos or calculation errors. Since the transaction will not appear in past reports it alters past data. Altering past data is something needs to be avoided. If we look at the issue from a restaurant business perspective most errors happens during the ordering phase and it generally gets corrected by consumer. We simply void orders to notify kitchen and enter new orders. But when ticket gets paid and financially closed "error correction" have a different meaning. Did the operator settled wrong ticket? Did he clicked cash instead of credit card? Or maybe customer came back two days later and blamed she bought one coke but paid for two cokes. These all happens. The solution is not voiding the ticket. Because:
and this list can be longer. The only case I want to support is just refund tickets. This is not so useful for restaurants but if they have a retail shop for selling wines, chocolate, etc.. They'll use it. Not for error correction but for changing items or refunds. If might be useful for delivery too. And I don't mean stopping cheaters here. What I'm trying to keep users trust. Some people constantly asking us voiding feature (not like you did. by deleting the ticket) They can't ask how they cheat so they are asking for error correction. That sometimes confuses people about there is something missing in SambaPOS. No. All operational errors can be fixed by refund operation. For most cases even V2 Cash Drawer module did the job and for more than 3 years we have users using SambaPOS without void feature. Of course it works in Turkey without problems and there might be changes in different countries. The reason might be laws, culture or people behavior. If you think that should be done that way we can talk about it but I believe we can solve most issues without voids. At least we should try to avoid. Finally. We do not use "gift" term in Turkey too. It means "hediye" and it much more sounds like a "present". We use "İkram" and the translation of it is "treat". However I saw the Gift term in another open source POS and preferred that. We use discount term for ticket total reduction by a rate. Yes financially it is a discount too but I don't think we should change "gift" term with "discount" since we have another button labelled as discount. If there is another term that fits better we can change that. |
I've tested my code with the negative-quantity and amount and there seems to be an bug with the taxes. If I have two products with different taxes it doesn't reverses the transaction and it makes the same normal transaction. If I only have one product with on tax it creates the transactions in reverse as it should. I think my approach with the voidTicket and voidTransactions would be much more clearer to see in the accounting and stand more out as this type of operation have to. Another thing I don't like about this solution is how its viewed in the reporting. It counts the voided ticket as a sale which conceptionaly isn't true with a plain wrong ticket. Example: A customer want's 2 bottles of wine. You sell him the 2 bottles and when you want to give him the ticket you see that somehow the ticket shows 200 bottles. Now the customer wouldn't pay for 200 bottles but had only paid for the 2 bottles. Conceptionaly you havn't sold 200 bottles so the customer can't return 198 bottles which he never had. The ticket is planly wrong so you have to correct this error. If you treat this like a "normal" return though the actual technical numbershifting in accounting is the same in an tax-audit the auditor would ask for the invoce from the wine-wholeseller. You culdn't produce it because you never had this much bottles of wine in your basement. "If a customer can return 198 bottles of wine you must had it in stock! So from where are all the bottles comming?" the auditor would argue. If you argue that this is the only way the software can deal with such wrong tickets, the auditior could refuse to belive so or if he nearly belives this argument you could end up explaining all and every return for the last 7 years (here in Austria) in great detail, because every return could potentialy be a wrong ticket. For the taxmen a return and a wrong ticket are completly different things so you mustn't merge them together in one same transaction. If the taxman likes your answers about the wrong tickets and returns you may get away with your return transaktions. |
There will always be some cultural differences with phrasing. And this comes down to translation.
For 1. this could be because wrong quantity, wrong item, faulty item etc For any reason we need to be able to record why, and show this on the reports, along with adjusting inventory levels. Its about creating an audit trail that can be followed, not about hiding mistakes - its about full disclosure, and a system that is easy to follow. Settled tickets/items should never be removed from reports - this is why some countries require Fiscal printers. As far as the other terms go We need to be able to refund a single item(s) or a complete ticket, with an option for supervisors only feature. Anything that happens after a sale should have approval from a supervisor or manager - this stops/reduces staff fraud. Emre, there is nothing wrong with your English, its a cultural difference in meanings. |
This is like when I asked Emre about selling Gift Certificates. It's about an audit trail. As we don't technically sell GC, but they are an exchange for cash, we still need to track the money and account for the extra cash at the end of the day. |
I agree that all transaction which could be classified as by refund operation should be dealt with as such. Basicaly my approach to voiding tickets could also characterised as a refund operation. Now my changes only "hides" tickets in Reporting if the voided ticket and the void-ticket is in the same timespan and doesn't alter any closed workperiods. I think I'll add a more verbose reporting on my next commit. @JohnSCS I wasn't aware that refund is also used in Accounting/Bookkeeping for such "voiding"-transaction. In this context my approach is a refund operation named "voidTicket" with a verbose audit trail in account-transactions. I think about using another word for my VoidTicket-Action. |
Maybe 'RefundTicket'. The English language is spoken by many countries, either as primary or secondary language - and I'm not saying that everyone should speak English before their native language, but most systems are English based. Refund has been the most used word in the forum and website, so maybe we go with that? |
Wolfgang, |
Yes I can do this because these "voidTickets" are marked. By the way all these VoidTransaction-Types are linked to a void ticket-type. You can make such a versbose transaction with the original SambaPOS. |
- RefundPrefix added => makes different RefundActionTypes available
If we think about the functionality from an abstract perspective that issue might be related with this. The text is hard to understand for me but as far as I could understand he wants to change a takeaway ticket to delivery ticket and apply delivery fees. I'm thinking about a "duplicate ticket" action that copies a ticket to the given ticket type. We have options for the source tickets. For example we can change ticket state to (Void) and void all orders too. Since void functionality is just an order tag we can also have different tag named as refund or whatever else revenue needs. When all orders (calculate price) set to zero ticket will have no effect on reports but displayed as voided. Also instead of copying it to a void ticket type it can be copied to a refund ticket type that creates negative quantites. |
In my latest changes I implemented such a feture by a refundPrefix and I have the Idea to show this refundPrefix in the Reports and group them by this prefix. The account transfer magic which then happens is linked be the ticket-type we set which can be determinated by this prefix or another value wich holds the ticket-type. Yes we could create a RefundTicketType and set every TicketType, AccountTransaktion, Paymentransaction with such a RefundTicketType. This would take away some naming magic in setting the TicketType and PaymentType (and/or make an option to not copy payments or closing the ticket). With such additon "DuplicateTicketAction" would be a more fitting as this action does merly copy the ticket. In this questinon. Basicly with two refundTicketActions you can achive this by "voiding"/refunding the first ticket and then in the second refundTicket-Acton set another ticket-type. |
Hello Wolfgang. I don't like bugging people but I'm really wondering how we should handle that. Could you operate refund features? If we still have missing features we can discuss them. |
I hadn't realy time lately to work on it but implementing wise there isn't any real difference between "voiding" ticket and "refudning" it. |
Hello, sorry again for bugging you. I've just wanted to hear from you. I hope we'll work on it again when you have free time. You can think it as a SambaPOS convention. We use "void" term for canceling sales that are not paid yet and "refund" term for canceling sales that already paid. Correct terms and use cases might be different and I'll be happy to discuss different ideas about it. |
in your definition it is a "refund" operation (reverses the transaction) and not realy voiding (delete all records of a transaction) anything. I somehow got stuck with replacing a simple prefix with a real Model(Type or Entity) and to realy show this in all the reports proper. By the way: please make english names in the Reporting-Tables in the sourcecode. They are curently all in Turkish which I can't understand |
Help me please! |
I will also provide a How-To when comitted because there also needs be setted some VoidTicketType and VoidTransactions. With this Action you reverse your Transactions. The transaction and Ticket aren't simply deleted because the Taxmen will go balistic if this could be done!