Thanks @wale so the bugs are patched. Nice work! I’ll update. Thanks to the team
Hi, I’ve not been able to test the new update, can you confirm that you have tested and no more auto-submission and duplication?
Haven’t had the opportunity of updating yet. Really hope the patch solves offline POS issues too
Kind regards,
Same is still happening to me.
By the time of the following post I was on version 10
Now is starting to happen ( or we just noticed now) on version 11.
Its been impossible to me to pin point the scenario
It looks as if no one is interested in the online POS so for me, I gave up. There’s a whole lot of issues there, performance problems, duplicates, wrong invoice totals, auto submission, poor product display (names are so short in the grid). Offline is what works and I think it’s being given focus. Unfortunately offline is not acceptable for many people, since it’s too dependent on cashier actions to perform sync, with the risk of a valid printed invoice. I can easily say this will even fail many many audit and IT standards but it’s what it is here in ERPNext land.
Do tests exist for any of those issues, would that help identify and resolve them ?
Help with Writing Tests - Foundation and community invite to help with 'do nothing' pass tests
All these issues apply to offline too
So then is the question - whether to exercise the code with automated tests - is that the answer or the problem?
Could you explain this better ?
What’s there not to understand here?
Here’s a case, for example, that argues for a test Project and task table Bug
If you are referring to code tests, well, I don’t know, and it’s even hard to identify why for instance the duplicate sale happens or the auto submission. Apparently it’s something in the code and possibly because it’s almost now entirely JS handling everything. Like I always say, much like a broken radio, these things didn’t exist in version 6 which thankfully I still have in some places (over 7) running for many years now without any of such issues save for slowing down when db gets too large. All that was required was to just add features and improve v6 POS (as Toyota would do until it’s perfect) including adding in the offline feature, all right there… but everything was reworked and it’s been really unreliable.
That’s terrific news - so before v7 your POS issues did not exist!
To resolve any issue, once you can reproduce it at will, you are more than half way. You are much closer to a fix when you write a single test case that captures the problem. That is the essential goal and tipping point here - a selection of tests that mark, extend and solve nasty bugs.
(Tests not just exercise functions to validate they still work, but also detect breaking changes. Plus they neatly show how stuff works, a big win for learning too.)
Apart from that technical hurdle, there is of course the business one. That remains an impasse - our market audience has yet to meet the challenge here. (Nor can the Frappe folks be expected to solve every last issue.)
A popular Chinese proverb says: “The best time to plant a tree was 20 years ago. The second best time is now.”
One problem seems to be the transaction separation and synchronization process. I can’t say exactly how or where that is implemented or better yet tested in the code.
Problem here is sharing someone’s business data, else we have some old data that has huge transactions and items. You can make a mock of 5 to 10 cashiers posting simultaneously and watch it grind to a halt. For about 3 months now, what one outlet does is to go offline in the evening/every evening when the volume spikes.
You have a benchmark for this case, where v6 runs fine but v7 dies? If so that is a good start.
That exists in a working public form - where is that to be found please?
I believe there was a pull request that solved most of these issues… even though it wasn’t merged? Does that still work?
Kind regards,
We tried to solve the duplicate invoice issue.
A quick and dirty fix for this is to make the offline PoS Name field unique. If you notice all duplicated invoices have the same offline PoS name/number. By making this field unique the system will bounce any incoming duplicate invoice.
But note that the naming is based on the system time to the second. So you might have a problem in a multi till environment if 2 or more tills submit invoices at the exact same second.
We are looking at extending the naming to microsecond, this will reduce the current possibility of false duplicate by 99%.
Your thoughts
Well, I wouldn’t know what benchmarks you would need but what I have is customer feedback and experience, and also what we witnessed first hand… looking at number of key complaints from different users on different versions.
Here’s a summary of what I’m trying to pass on:
Version 6:
- Users experience a very stable, reliable and dependable POS, on those instances i have not received one report of cashiers being under or over. POS is almost bulletproof on that aspect.
Issues on the V6:
- Easy Access to account via breadcrumb link
- Draft printing
- Unfriendly cashier setup (have to create a customer profile per cashier)
- Sales Report per user is not available as a core report, lot of modification to do sales per user when you are dealing with named customers.
Version 7+
If I remember well, this is when the POS began to change until at one point it was only the offline POS that was available. Issues were immediately noticed especially from version 9.
- Sales duplication
- Wrong totals
- POS hang ups
- Items repeating in customer grid
- Troublesome display with unreadable names
- One time there was the super embarrassing feature where on searching, an item is then into the cart! Long thread to drive the point home.
At this point we started hearing of cashiers being over or short. Things that were practically impossible on v6 except for time differences which you will see it’s effect by expanding report scope, it balances out.
Asides customer feedback, we paid visits and saw these for ourselves.
Your issues make a good textbook case example of the need for user tests -
The first step is to formulate a set of unit tests to run and validate that each transaction or report type and so on is correct and bug free.
That test set forms the key standard to resolve performance-related bug issues that arise only under stress: With no load the tests all pass, but some fail only under load.
The question and goal is to discover what particular parameter(s) - what variable at a specific value (or range) - cause a given test to start to fail.
Apart from fixed hardware resources (server ram memory size, cpu core count, network capacity etc) the independent variables that affect load include user count and say transaction size. The dependent variable metrics include response time and transaction volume rate.
A ‘benchmark’ series of test runs would help specify exactly what variables and values would lead to issues like missing or duplicate records, false values, and hung processes or servers.
With each code update, run the tests again to collect a new set of metrics to add to the benchmark. That series history will serve to analyse and resolve bugs that may or may not relate to performance.
Hope this helps!
Note, the hangups of erpnext is not only on the POS
In our companies we are experiencing erpnext hanging-up on the Lead and the Event doctypes… the Event the most frequent.
Browser console shows a network disconnection error but that’s definitely not true.
Hello @eagoweb,
I don’t know anybody who has been able to pinpoint the cause. So I went for a prevention based fix. In our case, we discovered that all the duplicate invoices had exactly the same data in the offline_pos_name field. So first I created a patch that de-duplicates all the invoices. Second, I added code that makes the offline_pos_name field unique at the database level so that if for any reason the pos tries to create more than one copy of the same invoice, the database will reject them.
The de-duplication is done by finding the sales invoices that share offline_pos_name with other invoices, and appending a serial number to the offline_pos_name data so that the data in the column will be unique (so if we find 3 invoices with offline pos name - 123, the script will change them to 123, 123-1, 123-2). It also made it easy to find all the duplicate/triplicate invoices in the system by filtering by offline_pos_name that have a ‘-’. It is then up to the owner of the data to decide what to do with the duplicates.
This approach worked for us.
This was packaged as this PR. Unfortunately, it wasn’t merged since it could not be reproduced. If you have technical resources, let them have a look at it. It is also the same behind @olamide_shodunke’s suggestion. The only thing he didn’t point out is that you can’t set offline_pos_name to unique without ensuring that the data in the column is already unique.
If you encounter problems, send a reply and i’ll see if I can assist further.
NOTE: The patch was written for v10 so test it properly