Some of us may know that a few days ago we updated a high data install from v6 to 9 and today we are testing it live. Here are some troubling issues that need to be fixed especially for medium to large environments.
Some of these issues are essential because we are looking at a real situation where a large amount of stock and transactions with negative balances were updated.
The item name field is too short, it is essential to see at least 12 to 15 characters, this helps cashier confirm if correct item Is entered, especially when searching
Point 1 is important because this version seems to have a bit different code for scan and search, making it easy to load the wrong item in the cart. Sometimes on searching, an item is instantly loaded in the cart, even when what was searched doesnāt match a barcode, previously it was almost impossible to make a mistake when entering items as the pos accurately matched barcodes or presented a search. I know some people said they needed fast scanning, but this is a downside even for a fast paced environment, this was never a problem. I think if we must do this, let the team consider a separate search field; the search is quite unstable.Note that it is impossible to have barcodes on all items.
Grand total sometimes doesnāt refresh, so when you scan items an remove one and add another; the grand total doesnāt change until the page is reloaded; no big deal for folks like us, but mighty big deal for cashier. Cache issue?
Valuation rate issue preventing sales even when you have negative stock. This should be optional, like a checkbox, enforce valuation rate, If I have allowed negative stock it is implied that I will be bringing stuff without capturing any purchase docs. It is not convenient to select allow zero valuation during retail sales, it will produce customer queues.
Although we are on browsers and canāt control copies fully; it is a high risk to allow cashiers print multiple copies; in the past we merged the print and new button to conclude from the js file, like this:
With this, after submit, you have conclude, conclude opens the print dialog, cashier prints, the print screen automatically closes and a new invoice awaits instantly. Couple this with seamless print on firefox and its nearly bulletproof for the average user.
I edited this file in v9 and got no changes so Its handled in a different place, I only see this popup if you print from form view.
Apps will solve this problem extensively; for now can we hide the print button after it has been clicked the first time and the dialog opened. if printing fails, cashiers usually call a supervisor or tech; it is never acceptable for them to manage printing on their own. so letās reduce the risk.
Items also just become unavailable, you see them when searching in the filter, on applying the filter they will not be available, the only way out has been to use mysql to remove the barcode so we can add the item again, so its in the item table but for some reason is not available to erpnext.
For speed, its better than our experience v6 and can be better still; the pos takes around 4 to 8 seconds for most items, some items where thereās a high transaction history or negative quantity, it can take up to 18 seconds. Listing items or PRs sometimes takes a long time, say 15 seconds. navigation sometimes also freezes, also pos sometimes freezes then responds instantly filling items searched for; I think its the script attempting to speed scanning. Note also that this pos does not load on some browsers like safari or slightly older version of chrome, not a big deal but maybe vital info.
These are issues I promised to bring up as I implement v9
I think, out of the box, the big reports like sales register, stock balance, stock ledger, gross profit, trial balance etc should load one day reports on opening rather than the whole year or a month. This is a huge source of bottlenecks for large databases, if someone opens these reports unknowingly, the entire system freezes. Although in time past and on v9 we have set the start and end dates to:
frappe.datetime.get_today();
Please can we update the reports to be like this initially; for the sake of those that may have huge data and canāt update the js files. Let the report user open the report safely (1 day) and then select a period, this way a decision can be made on when to run the big reports and still safely check daily reports without freezing up other users.
Thanks, all our users have the pos profile. Iām currently at the store and Iām seeing things first hand, we have had to re create or rename items to be able to get them on pos. the search is a bit unpredictable; I think the cache is at work here.
Issue: the pos profiles are requiring territory and customer group; these fields are not in the pos profile form, I have checked the customer profiles attached and all is good. possible bug?
585 invoices raised with around 1800 items sold in the last 7 hours. quite some traffic today as well; a little heavy on the system, some hang ups on opening modules and lists as the cashiers work, 8 in total, no heavy inventory work in progress just sales (its a sunday). Will set up slow query logs. One thing is clear, this is more calm on the processor, max 70% used on each core, just that the scripts delay.
If you are using āOnlineā POS mode, changes to pos.js or payments.js files will have no effect. Those will be active when you change POS settings to use POS in Offline mode.
Thank, we are on offline, the editing was made against sales_invoice.js and it was working on older version, but not with this one, it seems the print and new buttons are handled by the frappe framework document printing.
Well; the updated pos profiles are there and in use but I canāt modify. I think it could be a bug; its asking for customer group and territory; these are already filled in the attached customer profile. So I canāt set up payment methods, choose print formats, etc, so they have to always type in paid amount.
It wasnāt an easy day yesterday altogether; search was the main issue, then missing items, valuation rate problems, Iām making them see the upsides of this version because from go they were more comfortable with the stability and reliability of the old pos; I think the team needs to look at the search and keep it as efficient as previons online pos or create a separate field for searching by name and description and one for barcodes.
Amazing, those fields are in the form, not hidden, yet not displaying; I have filled in defaults and made them not mandatory, let me see how that goes.
Actually; Iāve not had one invoice submit successfully with the offline pos in this implementation, we are online fully, just that the online also feels excessively cached so you find totals hanging here and there and page reloads needed. But itās fast. One other issue is; the search is too fast to make searching items by name convenient.
The pos search box was designed with the hope/assumption that a scanner will be used all the time and that there will always be proper barcodes, but there are always 1000s of items with no or bad barcode in stores. Itās too fast to make efficient searching amongst thousand of items. Hereās our practical observation:
3 items can fly into the cart while you try searching for an item; so once a sub-string is matched it is entered as an exact match.
The design doesnāt consider the following scenario:
a. Sometimes barcodes get damaged and the barcode needs to be typed or the item name used
B. Many items come with a poorly printed barcode, distorted or blurred, sometimes damaged due to handling, inventory may have typed the code by hand hoping some day a Barcode printer will be purchased; many stores donāt have a printer, we canāt enforce that; even when a printer is available; it may not get used for many reasons beyond us.
C. Its a practice for certain items like in-house bakery items, say 10 product types; to get displayed right after production in a showcase, no packaging; served in bags; for these items the stores have short codes like 1001, 1002 etc or something else, these are sometimes printed on a paper and pasted around the terminal, usually they just type 1001 and the item is in after a very short time; 1 second a most. Now; imagine a barcode like 1001552365 that needs to be typed in to get an exact match; on getting to 1001 we see the item 1001 is in the cart and the field continues at 5523, if another item matches 55236, its in as well and field is reset to 65. Pleas try it.
I think there should be a separate field that searches with the same logic as the one in older versions it was just perfect. So 1 field for barcode, one for search so we have the goodness of fast barcode scanning and the reliability of slower, more user friendl search.
Please can you confirm that this is where the print and new buttons are for the online pos? they are not in a dialog; after concluding they are right of the menu button.
Sir; weāre using online; for offline post; I just answered a question regarding if I have issues with it. I tested it and I didnāt get one to submit.
