-
Create option to Remove ability to reprint just concluded sales invoice from erpnext to allow administrators make that decision in browser or by other plugins/services; erpnext should not provide the print button after conclusion always.
-
Create option to Prevent sale from submitting at POS if paid amount less than or greater than invoice total; ie do not post submitted sales invoice as outstanding and do not enter POS sales as unpaid. provide option which can be selected in pos profile or pos settings, maybe simple checkbox: ‘Allow partial payment’. If POS profile is created without selecting payment modes for the profile (for any reason) then cashier can conclude without even entering any payment and invoice is submitted as “Unpaid”.
-
A new invoice should be created on conclusion/printing rather than keep old invoice displayed with print button; this confused certain cashiers because we made a fix in v6 which always gave a new invoice after submitting, reduces multiple clicks, saves time and adds a bit more security. So, provide single CONCLUDE button and send print automatically while opening a new invoice in originating tab.
-
Searching should be natural as before; use v6,7,8 as reference, if possible; provide separate search field in addition to barcode field with the natural feel and finesse of v6 search, searching for items in v9 online pos is rather too fast for accurate human input considering different speeds; v6 accommodated everything and there were no issues or complaints
-
Online pos item names need to be longer; if possible the name should be above the quantity, discount and rate, maybe in smaller bold fonts so it doesn’t take up a lot more space; its crucial sometimes to see if the right item is selected; almost impossible on current display.
-
It seems pos printing for online pos is managed by frappe document printing? (can’t explain this well); it should return to the scheme where it’s handled in erpnext code, maybe a dialog as usual.
updated -
IMPORTANT, Show amount for items entered, item A is 200 and 2 have been entered in cart, show amount as 400 not 200, current display shows Qty 2 and Rate, as before, we had rate and amount, if space is a constraint, kindly use amount, ie, show amount for number of item scanned rather than single rate
Wouldn’t both of these issues be put to bed by setting up an automatic printing after the transaction? The security argument aside, having the receipt print automatically and resetting the screen to the next new transaction would solve most of what you are asking about.
I still think the security argument is in need of much more discussion. It is not a slam dunk to limit receipts to a single print, although the above fix might help ease you mind partially for this.
This one I do not understand. Help me understand exactly what is wrong with the searching in the new POS module. Aside from it being faster in some ways, it hasn’t changed in it’s function that I am aware of. what might I be missing here?
Agreed! This is something we can probably get taken care of without much issue. It seems the addition of the quantity change box right in the Item line in the cart has taken up the room needed to properly display the Item names. It completely changed the line item change practice that had been in place in previous versions. Although I am not sure if the same information still pops up next to the on-screen keypad, but maybe we need to go back to that, or something similar to regain the space needed in the cart item names.
Ok, but I thought in your bullets 1 and 2 you were wanting the extra dialog (where the print button lives) to go away completely or be otherwise altered?
I am not sure of your logic on this one, but I believe printing from POS was standardized to work like the rest of the system in order to make it less prone to problems as the whole system advances up the version ladder. I believe that was done because POS was becoming such a popular module and difficult to maintain. We would need more to go on in order to justify a complete change of how the system prints. Is it possible there may be other ways to address this by creating a special app and tie it to the POS module just for printing? Looking for possible paths to solution here.
BKM
Please check updated list. Thanks
Point 5 is not asking for anything new! rather I’m even saying print as offline and as v6 prints! Restore the old dialog, it works and is easily editable to print automatically, I have done that already in all the shops still on that version.
Ok, yeah I like that as well. IF… the quantity and rate are both to be part of the cart list, then a total amount should probably be added to the line as well. It already prints to the receipt this way.
It may have something to do with columns in the list. If that is the case, then maybe look at how it was handled in the receipt printing in order to make it also work on the cart screen?
Your thoughts?
BKM
Here’s a suggested way to hand non-full POS payments:
POS payments less than the due amount must result in a draft Invoice (to be controlled by the supervisor).
I moved a copy of your post here to make it more relevant to the discussion.
@adam26d said:
One more thing guys. I think @olamide_shodunke raised this last time.
Dealing with a lesser payment, i.e. Ball is priced $12. User pays $5. This transaction still goes through.
Is this list of issues extensive or is it just a few urgent things we’ve already discussed here?
This sounds like a really severe issue and is very much the kind of thing we need to investigate and get fixed. So, YES it is valid to be included in our list and should actually be prioritized higher than redesign issues because this affects current users in a possible negative way.
Thank you.
BKM
Great so lets move it to point 1…
Does the “lesser payment” issue you raised above, occur in your system? if so, are you using POS in online or offline mode? I want to find the path to verify and duplicate the error so it can be better explained to the developers that we need to call on to repair it. Any further detail you can provide to duplicate the issue would be most helpful.
Agreed. Once it can be replicated reliably, it can be better solved. I have asked for details on the original post to try to set up a test scenario to find the issue.
Thanks,
BKM
Actually the proper treatment is for the transaction not to go through.
In retail payment should be by cash, card or on account.
Ability to take payment on account is then governed by user rights and or customer terms.
If full payment is not made by any of the three options then the transaction cannot be submitted.
Sure. Makes sense!
I am also a witness to it; Here’s my understanding of the new scheme, if cashier has pos profile where default and optional modes of payment are selected; invoice total is auto filled in default mode and if submitted, invoice is entered as paid. If cashier’s profile has no payment modes and she fails to enter the total or amount paid, the invoice will be posted/submitted as unpaid, if lesser then you have outstanding. so let’s make it optional in settings. First day of v9; when I had issues saving the profiles, we had over 200 invoices entered as unpaid as some cashiers didnt have the patience to enter the figure; we didnt have the modes of payment in the pos profiles. That was solved by commenting out the territory and customer group validation in the python file. With that the invoice total gets prefilled in the tender popup
Yes, it does make sense, but I still want to know how @olamide_shodunke using the POS module that it was able to make such a mistake? I want to try to replicate it and then test for it under different configurations to determine where it may have gone astray. This will allow us to ask for the correct fix and reduce the time to implementing a fix.
Any work I or we can do to better inform the developers will make their decision to jump in and fix it much easier.
BKM
emm, maybe not, it may get overwhelming and they may skip/forget submitting them. its even safer entered with outstanding/unpaid so its present in sales reports.
Thank you! That gives me something to experiment with and see if I can replicate the issue. Will work on it later this evening (after dealing with the mob of kids that will be coming to the house looking for candy and treats tonight).
’
BKM
@bkm let me even use your ‘mistake’ scenario. Cashier sells goods for 1850, customer tenders 2000, cashier wants to charge 1850 which is auto filled in default mode of payment and just quickly types 200 and hits enter, skipping one 0. Invoice gets posted, will try it.
The ability to seemingly close a sales transaction without enough funds being applied to the sale (i.e. a $12 item in list and only $5 collected in payment but transaction appears to be done).
BKM
Guys, another question. How do we handle supervisor overrides? These are common in a retail setting.
Example 1. Price change. Customer buys $12 item, which is currently on promotion at $9. And Cashier has no rights to change the Item ‘Rate’.
Example 2. A sale is made. For some reason the customer fails to pay the full amount and opts to cancel the purchase or only buy some of the items.
Most POS systems allow the supervisor to enter their password and permit the transaction.
But it seems with ERPNext we have to (1) logout the Cashier, (2) Login the Supervisor, (3) Carry out the required action, (4) Logout Supervisor, (5)Login Cashier. Obviously this wouldn’t fly in a high volume store.
A costly workaround is to have a separate terminal where the supervisor handles such issues. Do you guys currently have a better solution to this?
Really solid point. I have not seen the authorization rule at work in erpnext, maybe I’ll see if it brings up a prompt if set limit is reached.