Opening topic with simple points now.
Ok, let’s close it.
Redundant?
Not much of help?
I would not use those words my friend.
@olamide_shodunke sorry I didn’t mean the topic is not much help, no in fact its an eye opening. What I meant is too much redundancy, the reader get lost and some times miss important details. So maybe from now own since we discussed the problems in depth, we should move to summarize them and start suggesting solutions, and we should be more focused. I know, we all get frustrated sometimes 
btw did you create a github issue? and if you did, then everyone here should give it thumps up
While we’re on the POS subject. I’ve encountered a few issues with V9.x. I urgently need help setting a default Customer in a Multi-Company site.
You guys may have an interest in this and you may be familiar with some of the issues I’ve raised in this thread:
My assumption so for is that V9 Offline POS is using the V7/V8 UI/Client, whereas Online-only mode seems to be a new enhanced version with its unique issues.
Yes; have they been fixed?
I have a Software Development background but not yet with Frappe. I can tell you that if this is the case, the search code and all the dependant can be copied, pasted, and modified to requirements. Leaving the “Awesome bar intact everywhere else.”
Default customer for sales invoice, orders etc? Did you try creating the customer and then entering the name in the Default field in customize form for each doctype that you need it for? Like sales invoice, enter in customer and customer name, give it a shot; may b what you need.
Ok, I see your scare scenario here (just in time for Halloween).
However, the person running the refund request is supposed to run the refund against the specific transaction number. That transaction is then appended in the system and cannot be repeated multiple times if the clerk running the refunds does it through the system as it would already show the refund having taken place earlier.
The only thing really scary here is the prospect of a clerk offering a refund based only on a piece of paper and not the data in the system. The only purpose for the piece of paper is to identify the correct transaction in the system. All the more reason to be using POS in online mode.
BKM
1 Like
No no no this has nothing to do with refund! Scenario; busy day as usual; cashier A has a friend Mr B, prints 2 copies of a sale and gives one copy to Mr B who has been pacing around, quietly went to the cashier, invoice was slipped to Mr B, who ‘codedly’ peeps at it around the shelves, picks up same items, goes to his friend’s Till, Miss A (cashier); who pretends to scan and all, (remember in most stores no one and nothing is actually looking at the operation of each an every sale; they are depending on systems like erpnext ok). So… Mr B walks to the door, presents an invoice and heads home. Remember, these are not named customers, even if they were, Miss A can still print a male customers invoice, who presents id cards at a retail store???
Nah; no one should touch the awesome bar!! It’s the pos item search we are refering to; for me I wouldn’t recommend an enter key; but it should remain as reliable and fine as in v6,7 pos.
Ok, I cannot completely agree with this statement. There are several valid reasons to allow receipt reprints at the moment of sale or even after the sale by the cashier. If all this fear is based on a flawed refund process, then it is the refund mechanism that needs to be fixed rather than the printing of receipts. Once a refund has been processed, it should be marked on the original transaction in the system and the user issuing refunds should not base their action ONLY on a piece of paper. They should be using the data in the live system instead so that duplicate refunds could not be made. It just seems silly (or lazy) to only base a refund on a piece of paper. If the refund process is not working well enough in the live system, then let’s fix that and make the whole system better!
However, if you want to speed up the POS process by printing automatically and then resetting the screen for the next new customer, then I think we can work something out to make that process better.
Going forward, I am open to different ideas on these topics, but please be specific in your critiques and any paths to improvement. Let’s be open to all points of view and see if we can accommodate as many users as possible without alienating large chunks of the user base with our solutions.
Thank you in advance. So, hit me with your thoughts on these two issues above. I want to be sure I have all of the information possible.
BKM
1 Like
You know what? In my part of the world and I’m sure most; cashiers are not allowed to print more than a copy except it’s a company policy; even at that; the cashier doesnt enter the number to print, its been setup by the tech team and happens automatically. A store here uses that scheme; but one copy must be handed back to security before exit by customer.
Essentially, on concluding, 2 slips come out and a new sale screen, no print available/active anywhere again. At that point, any reprinting is handled by a supervisor
to move on, lets agree that hiding the print button after printing should be optional and configurable in the POS profile
Sadly, The scenario you described would work just as well with a single receipt. If Mr B buys the items, takes them out to the car and comes back in to perpetrate the same crime in conjunction with Miss A, then they have essentially procured the same products for free and can sell the “stolen” items for profit elsewhere. It is the same crime either way. In both scenarios, the business pays out a refund for products that never left the store so they lose the value of the original sale. There is really no way to stop that within the ERPNext POS module. That comes down to store security and good store security contractors have methods for minimizing this kind of crime.
If this is true, then how are you using the ID card to tie it to the transaction? If you are already doing this, you should also be using the same customer ID data in the system to prevent the double refund fraud. Maybe you didn’t explain it well enough for me to see the problem here, but I really do not see the issue.
Also, in most stores, the refund is processed by a separate service counter and never at the regular cashier counter (except in very small operations). So in smaller operations, the owner would have to be very trusting of the cashier because the fraud can be easily perpetrated when there is not a separate service clerk. regardless of the method of data tracking.
BKM
I’m saying, no one presents an idcard! Like @ganas said; let’s make it a setting option. Truth is the chance of using one invoice becomes a lot less. Stores today STAMP INVOICES on exit. So you can’t present a stamped invoice before exit! You see… invoices are stamped by security, of course there is also possibility to conive with even security but all these checks greatly reduce shrinkage by theft.
We don’t do any refunds mostly down here. So that’s not our issue. Just shrinkage by theft. Bottom line is; the software must be perceived as secure by any client @bkm, do you know how many times I’ve been asked to remove this feature?? All shop managers ask me to remove it. All; even the newbie IT guys all see it as a problem. That’s why @olamide_shodunke is always in wonder at this debate.