VoidTicketAction added

[Stelzi79]

• Reports changed to not include Voided Ticket
  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!

[Stelzi79]

Now also VoidTaxTransaktion can be mapped against the VoidTicket

[emreeren]

Hello Wolfgang. Good idea. I've tried similar feature before so we can merge our ideas. This is what I'm thinking about this.

1. I do not call these tickets as "Void". I call it "Refund". If a ticket is paid and closed it can't be voided. But we can return items to inventory and refund. We can even do the same thing to change sold items. For example I've sold red wine, the other day customer came back and changed it with white wine. Price may change or not. If we can support this operation we can also support refunds.
2. To be able to mark an order as refund we can just change order quantity to negative via UpdateOrder action. Setting an Expression to Quantity parameter such as [=0-Order.Quantity] should change the order quantity to negative. Also we should mark order as "increase inventory".
3. We can mark an order as refund like we mark orders as gift so we can Enter both red and white wines to the same ticket and mark the red one as refund. If the prices are same ticket amount will be zero. No problem.
4. Red wine is cheaper so the ticket amount will be positive and we can settle remaining amount.
5. If white wine is cheaper the ticket amount will be negative. SambaPOS does something tricky here. If the ticket amount is negative it reverses all account transactions. So the sales account and the cash accounts works reversed.
6. We can create a different ticket type for refund tickets and when an order line is added we can automatically change quantity to the negative and mark it as Increase inventory with UpdateOrder action. Since SambaPOS reverses account transactions for negative values there will be no need to configure additional payment types or transaction types. It might be useful if user wants to track refunds under different account.
7. So if your action just duplicates a ticket with the given ticket type it will be enough. There will be no need to store additional info.
8. I've recently implemented logging for tickets so you can use it instead of ticket notes.
9. I don't think we should automatically add payments to refund tickets. User may need refund to customer account, cash or create a gift certificate. I know you meant voiding them but most people who wants voids just need to show less sales amount in their reports. I'm not sure if we should support such feature or not.
10. If you want to test it please try with latest state. I've recently added few features while trying it.

And... Sorry for the long comment :)

[emreeren]

My test database for refund tickets.
https://docs.google.com/file/d/0BzpGjxRhmyRpcmZKem1TSlVnU3M/edit?usp=sharing

[Stelzi79]

1. Well I don't know how the wording is in Turkish but a literal translation of refund = zurückgeben, rückerstatten (it means literaly to give something back) wouldn't be the right word for this function. The word void = unwirksam , nichtig, ungültig as noun Fehlerstelle (this means that there was an error and has to be corrected). My proposal doesn't change the sold Item. It makes a void Transaktion and reverses with this void-ticket the transaktions with the sold items to chancel them out in accounting-terms. Your example with the wine-bottle would be such a void-transaction (where the refund-word would be appropiate).
2. hm a negative order-quantity on the void ticket would be more consistant.
3. refund, gift and on the ohter side void are concetpionaly different things so I would not advise to implement it alike.
4. because void is not the same as refund it would not be wise (because of the taxmen) to mix such things.

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.

1. A refund to gift-certificate or customer-accounts could be made available and would be usefull in the classic refund situation but if the ticket is plain wrong such a behavoir would be very nasty to deal with.

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.

[Stelzi79]

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.

[emreeren]

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:

1. That changes past reports. When a work period ends it ends. User prints his report, puts it in his safe and it should remain in that state.
2. Most of the time I saw people corrects wrong errors and puts data to a unstable state since we can't undo error corrections. They'll talk about missing tickets and even you show them it is "their" error they loose their trust to numbers.
3. When operators knows their errors are correctable they starts to make more errors.

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.

[Stelzi79]

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.

[JohnSCS]

There will always be some cultural differences with phrasing. And this comes down to translation.
I understand where Wolfgang is coming from, but there are two parts to this problem after a ticket is settled.

1. Incorrect/Faulty item sold
2. Incorrect ticket settled

For 1. this could be because wrong quantity, wrong item, faulty item etc
2. Wrong ticket settled, wrong payment selected, wrong customer account, 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.
We need to list refunds on reports to show the gap between the cash we have and the sales we've made, because a refund will create a discrepancy.

As far as the other terms go
Gift - To give something away as a bonus or reward
Discount - Price reduction used to win a sale, loyalty or move older stock (Demo stock, food that was prepared but was wrong order)
Void - To remove an ordered item due to error (wrong item, no stock), but not settled items
Refund - To reverse a financial transaction due to agreed reasons (faulty item, wrong item, incorrect item)
Exchange - To replace a returned item of same value.

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.

[JohnSCS]

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.
All I did after that was, change the accounting rule to remove the GC price from sales instead of putting it to Issued Gift Certificates. The item report shows that we issued GC's, but under Accounts the Sales are correct.
The original way was great but you could print as many GC's as you wanted with no record of them for end of day procedures.

[Stelzi79]

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.

[Stelzi79]

I made some screenshots from the receivables and tickets

[JohnSCS]

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.
Maybe using a Thesaurus and Dictionary to find similar meaning words and checking their definitions may help. But in saying this, different industries do tend to vary a meaning which again makes it hard to understand.

Refund has been the most used word in the forum and website, so maybe we go with that?

[JohnSCS]

Wolfgang,
I like the screen shots. Is there a way in the Ticket Lister to show the Void as negative?

[Stelzi79]

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.

[emreeren]

If we think about the functionality from an abstract perspective that issue might be related with this.
https://sambapos.com/en/content/how-create-automated-command-change-ticket-type

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.

[Stelzi79]

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.

[emreeren]

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.

[Stelzi79]

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.

[emreeren]

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.

[Stelzi79]

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

[1322016ad]

Help me please!
how to edit language