Yes, has nothing to do with pos profile, I used as an example because thats how I noticed this on v9. v6 didn’t respect amount received, invoice always submitted as paid except when submitted from form view.
Something also caught my eye in the images: in the tender pop up, lower left it should be Invoice Total not paid Amount, where you have the disabled N9,200
Maybe this feature would be useful for credit enabled customers with an “account”, unlike the typical “anonymous customer” retail environment. This could be why its here in the first place.
In this case its a good idea to be able to enable or disable this feature in POS Profiles. If anything that’s what it may have to do with POS Profiles . Putting it in POS settings would imply that its a company-wide feature.
Exactly, it should be a settings thing, if you are setup as a retail cashier for walk in customers, then you must get full payment you know. its up on our list.
Authorization rule has no prompt for password, maybe something good to have, it just blocks the transaction and doesn’t allow any obvious progress, does it mean the sale has to be done by the authorizing role? Kind of odd. add to list of updates?
This dialog (this is from v9 form view) should be used for printing in online pos, its available from form view but funny enough its not on the main pos screen, this one is easily recoded to automatically print and create a new invoice, editing it in v9 has no effect on the pos print and new buttons. Please check, why the disconnection; seems exchanged, the menu print belongs to form view and the dialog belongs to pos
@noetico I see you’ve been trying to edit the POS scripts for a while. I have observed what seems (from the layout and behaviour) like 2 different POS modules/views/etc (not sure) when you switch between Offline capable and Online-only.
Offline being what we’ve been using so far V7/V8, Online-only being the latest version with its new set of issues.
I think if you want to try out applying some code. Try it on the Offline capable mode it should still work as before. I haven’t tried much of this but I think it’ll work.
Yes, seems like 2 very different things. I actually have no interest in the offline though, as it depends on the cache; its not good for business, fails submission in my experience 90% of the times. A user can clear the cache etc, what about price changes that happen before user refreshes cache, cashier will sell at old price, the offline should have been designed on top of online, on-demand, automatic, only when the server goes offline; I think its like that in v7 right?
On this one I concurr with @olamide_shodunke on the Enter Key/Carriage Return, but not a slower search.
I think some middle ground and practical way forward would be that if more than one item exists with a barcode/item code sequence, then the user should manually choose one. The system can find them all and list them as usual but NOT add anything to the Cart. If Enter/Carriage return is detected, the best (full length) matching item should be added to the Cart, otherwise just list the items and let the user choose.
@bkm@noetico. I think we need to agree on this one then add it to the list going on github.
Perfect. The only instance where two or more items will be listed instead of just the unique one is if more than one item has the exact same barcode. This will be an inventory error and will be corrected once it is discovered.
. Putting it in POS settings would imply that its a company-wide feature.
