Current POS design appears to be flawed

ERPNext
1

I have been trying to start up the POS module for my client that has 2 stores with 3 cashiers each. The performance of the POS part of the system very slow.

The cashiers have Andriod tablets for their screens and bluetooth barcode scanners for each check out station. To make sure we were not experiencing problems with the Andriod OS we also replaced one station with a Windows 10 touch screen PC, but the problem was still there.

When the cashiers scan an item, it was taking up to 3 seconds for the item to be added to the customers purchase list. This was when we only had about 2000 items in the test database. We went back to the “Item” information in the system and eliminated all of the item pictures so there would be less data to sort and load. Now it takes about 1.5 seconds for the scan to register to the customers cart. This is NOT in any way the fault of the scanner. I can also type the barcode information into the search bar quickly and it still takes the same length of time to find and post the item.

To make matters worse, the POS module does not appear to have been designed with barcode scanner use in mind from the beginning. Even a slow cashier, using a barcode scanner will get ahead of the “search and return” script that the POS module uses to populate the sales ticket. If you scan more than 4 or 5 items in less than 7 seconds you will overrun the POS feature that populates the cart. The search bar above the item grid of the POS screen will wind up with multiple sets of barcode data in the same line.

It seems to be the “open ended” search function that is at the root of the problem. The open ended search appears to work similar to “predictive text” in a smart phone. As long as you continue to add characters to the search bar it keeps trying to narrow the search. With this kind of design, there is no end point for the search mechanism to be able to know that new characters coming in are for the NEXT search. Because of this there can be no buffering of searches.

When using a barcode scanner on any other POS system, the system will buffer individual scans in case the user gets ahead of the the processor trying to populate the cart. In other systems, the buffering allows the system to catch up to the user. The open ended search does not allow for such features and therefore slows everything down.

Here is a screen shot of what happens when you get ahead of the search bar with a scanner:

POS error.jpg1178×734 48.5 KB

You can see in the search bar there are actually 2 sets of barcode data. All of the barcodes in this case start with ABC followed by 5 digits.

Other systems are able to use buffering because they can accept a control character as the marker for the end of a search string. Anything that follows the control character is obviously part of the next search code. This is why all barcode scanners have the ability to append a scan with control characters like carriage return, carriage return/line feed, tab, or even escape. The one I am using for testing right now is programmed to add “Carriage Return/LineFeed” to the end of each scan. the ERPNExt POS module seems to ignore those characters though and continue looking for more to append to the current search criteria.

In this way, a cashier can easily find they have 2 or 3 sets of barcode data present in the search bar, because the system could not buffer the individual scans and instead could find nothing. The user then has to stop and clear the search bar, then scan each item and wait for it to populate before they attempt to scan the next one. This is exactly what happened on the very first sale a clinet tried to do in a convenience store. A customer wanted 2 packs of cigarettes and a bottle of water. The owner scanned all three items in a row and the search feature could not keep up. I have tried this at a convenience store, an auto parts store, and a small family owned wine shop. In all three cases the frustration over the POS system as forced them to abandon it and go back to a simple cash register. Then sales have to be entered by hand at the end of the day.

This is not an acceptable POS solution. The user interface needs to be redesigned with a real POS operation in mind. The current implementation simply does not work in most real life POS scenarios.

This problem is not new to this version of ERPNext. It has been around for a long time, but nobody has addressed it.See below:
https://discuss.frappe.io/t/pos-screen-extremely-slow-can-we-remove-item-pre-loading-on-pos/8904

Does anyone have this on their list of things to fix?
I would have hoped it would have been taken care of with all the changes made during the version 8 upgrade to POS.

Does anyone have an alternative method to make this work better?

Thanks,

BKM

6 Likes
2

Hello @bkm

is this an on-premise installation? If yes, ensure you have a fast network.

I and my friends have quite a number of clients, over 15, these are mostly retailers running for over 2 years with erpnext, over 12000 items,upto 6 cashiers, each with loads of transactions, purchase docs, stock entries, etc. No one has complained yet of the scan speed. Rather there have been issues that have caused lagging like error snapshots, excessive negative stock (laziness) for example.

Here’s what we do

Setup:

  1. If LAN, we always use gigabit ethernet. If wifi. It has to be fast and close to the pos terminals.

  2. Check that you dont hare error logs piling up! This almost killed a store until we turned it off in the site config and deleted all the error snapshots using a truncate command after duplicating the table structure.

Notably, I have refused to put any shops on the new pos, we are using v6 cus the offline, online thing is scary, sometimes we have the invoices as drafts even when the sale was submitted. You notice this even on localhost.

Scanning: I really dont think there’s a problem here, nearly 3 years and the scanning hasnt been an issue; the cashiers know they should scan and let the item get loaded in the grid.

Its a browser based app so we generally dont expect some of the knack you get in a pc based kind of app, practically theres no need to scan that fast. The script dynamically searches intelligently. Have a look at the script to see how nice it actually is. One field to scan and search. The script will attempt to match the barcode exactly, if no results, it will do a string search against the item name and item code. Then there are other extended things it needs to confirm, is item sales item, is it disabled, has batch number, in a pricing rule etc… all these happen in a split moment. Theres an advantage to all this, for me it is a very reliable system.

CHECK THE ANDROID TABS

Also check the android tabs, do they have good processors for this? what browsers do i use? if you can, switch to Puffin browser, the speed will get you hysterical. Of course erpnext is quite light with its payloads but u need a processor that can run the client scripts quickly. Remember that the number of checks made when you scan an item and the scripts loaded are quite intensive for a brief moment, but then thats why its an ERP system; if you look at the stock and accounting side of things; theres a good reason the scan shouldnt just pull in instantly, it needs to check ‘stuff’ to keep the system sane, a lot of stuff, everytime you scan.

I personally think the pos in v6 is faster, i may be wrong but practically the v6 has proved so powerful and stable.

Kent@Live Mail. its official!

[http://discuss.frappe.io/user_avatar/discuss.frappe.io/bkm/45/7765_1.png] bkmhttp://discuss.frappe.io/u/bkm
June 29

I have been trying to start up the POS module for my client that has 2 stores with 3 cashiers each. The performance of the POS part of the system very slow.

The cashiers have Andriod tablets for their screens and bluetooth barcode scanners for each check out station. To make sure we were not experiencing problems with the Andriod OS we also replaced one station with a Windows 10 touch screen PC, but the problem was still there.

When the cashiers scan an item, it was taking up to 3 seconds for the item to be added to the customers purchase list. This was when we only had about 2000 items in the test database. We went back to the “Item” information in the system and eliminated all of the item pictures so there would be less data to sort and load. Now it takes about 1.5 seconds for the scan to register to the customers cart. This is NOT in any way the fault of the scanner. I can also type the barcode information into the search bar quickly and it still takes the same length of time to find and post the item.

To make matters worse, the POS module does not appear to have been designed with barcode scanner use in mind from the beginning. Even a slow cashier, using a barcode scanner will get ahead of the “search and return” script that the POS module uses to populate the sales ticket. If you scan more than 4 or 5 items in less than 7 seconds you will overrun the POS feature that populates the cart. The search bar above the item grid of the POS screen will wind up with multiple sets of barcode data in the same line.

It seems to be the “open ended” search function that is at the root of the problem. The open ended search appears to work similar to “predictive text” in a smart phone. As long as you continue to add characters to the search bar it keeps trying to narrow the search. With this kind of design, there is no end point for the search mechanism to be able to know that new characters coming in are for the NEXT search. Because of this there can be no buffering of searches.

When using a barcode scanner on any other POS system, the system will buffer individual scans in case the user gets ahead of the the processor trying to populate the cart. In other systems, the buffering allows the system to catch up to the user. The open ended search does not allow for such features and therefore slows everything down.

Here is a screen shot of what happens when you get ahead of the search bar with a scanner:

[http://discuss.frappe.io/uploads/default/optimized/2X/e/efde4344b436cb9ebc6c8479f9a60d453d454995_1_690x429.jpg]http://discuss.frappe.io/uploads/default/original/2X/e/efde4344b436cb9ebc6c8479f9a60d453d454995.jpg

You can see in the search bar there are actually 2 sets of barcode data. All of the barcodes in this case start with ABC followed by 5 digits.

Other systems are able to use buffering because they can accept a control character as the marker for the end of a search string. Anything that follows the control character is obviously part of the next search code. This is why all barcode scanners have the ability to append a scan with control characters like carriage return, carriage return/line feed, tab, or even escape. The one I am using for testing right now is programmed to add “Carriage Return/LineFeed” to the end of each scan. the ERPNExt POS module seems to ignore those characters though and continue looking for more to append to the current search criteria.

In this way, a cashier can easily find they have 2 or 3 sets of barcode data present in the search bar, because the system could not buffer the individual scans and instead could find nothing. The user then has to stop and clear the search bar, then scan each item and wait for it to populate before they attempt to scan the next one. This is exactly what happened on the very first sale a clinet trid to do in a convenience store. A customer wanted 2 packs of cigarettes and a bottle of water. The owner scanned all three items in a row and the search feature could not keep up. I have tried this at a convenience store, an auto parts store, and a small family owned wine shop. In all three cases the frustration over the POS system as forced them to abandon it and go back to a simple cash register. Then sales have to be entered by hand at the end of the day.

This is not an acceptable POS solution. The user interface needs to be redesigned with a real POS operation in mind. The current implementation simply does not work in most real life POS scenarios.

This problem is not new to this version of ERPNext. It has been around for a long time, but nobody has addressed it.See below:

discuss.frappe.iohttps://discuss.frappe.io/t/pos-screen-extremely-slow-can-we-remove-item-pre-loading-on-pos/8904
[http://discuss.frappe.io/images/default-apple-touch-icon.png]
POS Screen extremely slow - can we remove item pre-loading on POShttps://discuss.frappe.io/t/pos-screen-extremely-slow-can-we-remove-item-pre-loading-on-pos/8904

Please, can someone suggest a quick fix for the new POS screen; maybe editing the pos.py file in the frappe-bench directory- so that it pulls a limited amount of records per query; here’s the situation; every other module runs fast except the POS and…

Does anyone have this on their list of things to fix?
I would have hoped it would have been taken care of with all the changes made during the version 8 upgrade to POS.

Does anyone have an alternative method to make this work better?

Thanks,

BKM

1 Like
3

@noetico Thanks for the advice, but this is a cloud hosted system running ERPNext v8.1 so you experience with a locally hosted version 6 is probably going to be much better.

The Android tablets were of 3 types-

  • Samsung Galaxy Tab E with 16gb memory Android v5.1
  • Samsung Galaxy Tab A with 16gb memory Android v6.0
  • Samsung Galaxy Tab A with 8gb memory Android v5.1

All three performed the same

To rule out any possible issues with Android OS (as I stated in the original post) I also used a Windows 10 touchscreen computer. The touchscreen PC was directly wired to the router, and the tablets were WiFi. Regardless of what system we used the performance was the same in the live test.

This afternoon, I went another step further and hooked up my local Debian 8 server running nothing but Frappe/ERPNext version 8 and the performance was nearly identical.

In a store environment, the cashier is not focused on the screen for every item scanned. They are focused on finding and scanning every item on the counter. They trust the POS system to keep up it’s end of the business. In the Case or ERPNext v8 or 8.1, the open ended search function seems to be getting in the way of using the system. If the cashier has to be constantly watching the screen to make sure the scan clears the search bar and moves to the cart before they scan again, it increases the time taken to scan a customer order by as much as 400%.

That is why I believe the design is flawed. A cashier should not be focused on the search bar, they should correctly be focused on scanning everything on the counter in front of them and be able to depend on the POS system to keep up without requiring them to clear the search bar and scan again. Having a way for the scans to be buffered and executed in order would be a reasonable solution, but that cannot happen with this open ended search method.

I am looking for a way to make this work in the latest ERPNext version. I have no interest in trying to go backwards in order to find a version that works better.

BKM

4

Ok. I get your point. Maybe the team will consider implementing something like what it was in v4 and 5 where there was a separate search and barcode; then some form of buffering can be done. but have you considered if a barcode that doesnt exist is scanned and buffered only to pop up an error on submitting the sale, this may be more inconveniencing, although in a ‘perfectly’ inventoried shop this buffering will work, but in maby cases you have barcode issues.

There might also be ways to speed up the pos, like the post you referenced which the team fixed to show around 24 items rather than load thousands of items. Who knows. maybe the problem may be with newer scripts and all the added features; maybe this pos is generally ‘heavier’ on the browser. Its worth looking at.

one consideration

Kent@Live Mail. its official!

[http://discuss.frappe.io/user_avatar/discuss.frappe.io/bkm/45/7765_1.png] bkmhttp://discuss.frappe.io/u/bkm
June 29

@noeticohttp://discuss.frappe.io/u/noetico Thanks for the advice, but this is a cloud hosted system running ERPNext v8.1 so you experience with a locally hosted version 6 is probably going to be much better.

The Android tablets were of 3 types-

  • Samsung Galaxy Tab E with 16gb memory Android v5.1
  • Samsung Galaxy Tab A with 16gb memory Android v6.0
  • Samsung Galaxy Tab A with 8gb memory Android v5.1

All three performed the same

To rule out any possible issues with Android OS (as I stated in the original post) I also used a Windows 10 touchscreen computer. The touchscreen PC was directly wired to the router, and the tablets were WiFi. Regardless of what system we used the performance was the same in the live test.

This afternoon, I went another step further and hooked up my local Debian 8 server running nothing but Frappe/ERPNext version 8 and the performance was nearly identical.

In a store environment, the cashier is not focused on the screen for every item scanned. They are focused on finding and scanning every item on the counter. They trust the POS system to keep up it’s end of the business. In the Case or ERPNext v8 or 8.1, the open ended search function seems to be getting in the way of using the system. If the cashier has to be constantly watching the screen to make sure the scan clears the search bar and moves to the cart before they scan again, it increases the time taken to scan a customer order by as much as 400%.

That is why I believe the design is flawed. A cashier should not be focused on the search bar, they should correctly be focused on scanning everything on the counter in front of them and be able to depend on the POS system to keep up without requiring them to clear the search bar and scan again. Having a way for the scans to be buffered and executed in order would be a reasonable solution, but that cannot happen with this open ended search method.

I am looking for a way to make this work in the latest ERPNext version. I have no interest in trying to go backwards in order to find a version that works better.

BKM

5

@noetico

How do you handle incomplete payments at PoS?

If the total value is $1000 and the cashier keys in $800 as payment, in most other PoS I know the transaction will not go through. But in ERPNext it does and then shows as unsubmitted a few seconds later and is then stuck.

How do you handle this scenario with your clients?

6

This is among the reasons I dont use the new versions for any clients. All our clients are on the old pos. That POS always submits a correct invoice total regardless of what the cashier enters as Amount Received; its so convenient, no issues of shortages o over cash. Invoice total never changes; it has proved very reliable. I just cant use the new POS for any clients!

2 Likes
7

Thanks @noetico Noetico

How do you handle a basic report like a daily summary item sales report as shown below

Item Qty Sold Value Sold

It will have a total Qty and Value sold at the bottom.

It looks so basic that am sure I am missing something and not that it does not exist

8

@olamide_shodunke. Well. I can say the closest reports to that are:

the Gross profit report, you have average buying rate, buying rate, average selling, selling rate, quantity.

And the item-wise sales report. This one will show the total of all items, line rates and total. THIS MAY BE THE ONE YOU NEED. check it out.

I also think that if you need to add some extras, you may be able to do it in the code. For instance, on some of our clients installations the sales register report now has a user filter as opposed to just customer. This was cashiers can sell to loyalty card holders easily and you total by name. We were able to make some simple updates to the js and py files. But i would advice you seek help so you dont break your system.

Kent@Live Mail. its official!

[http://discuss.frappe.io/user_avatar/discuss.frappe.io/olamide_shodunke/45/7133_1.png] olamide_shodunkehttp://discuss.frappe.io/u/olamide_shodunke
July 17

Thanks @noeticohttp://discuss.frappe.io/u/noetico Noetico

How do you handle a basic report like a daily summary item sales report as shown below

Item Qty Sold Value Sold

It will have a total Qty and Value sold at the bottom.

It looks so basic that am sure I am missing something and not that it does not exist

9

Thanks @noetico

The item-wise report is not ideal because it is not summarised by item

The Gross Profit report seems to be ideal, I just need to find a way of masking the cost component for cashiers.

Can I send someone to you for training ??? Even if its for just 2 hours, he is quite smart.

Regards

10

Your cashiers view sales reports??? Any need for that?

To hide the costs…

That can be done from the report scripts. Its in the code. The select statements that load these columns can be edited to remove those columns.

If youre not code-savvy, hand this task to the community.

For training. Where is your person?

Kent@Live Mail. its official!

[http://discuss.frappe.io/user_avatar/discuss.frappe.io/olamide_shodunke/45/7133_1.png] olamide_shodunkehttp://discuss.frappe.io/u/olamide_shodunke
July 17

Thanks @noeticohttp://discuss.frappe.io/u/noetico

The item-wise report is not ideal because it is not summarised by item

The Gross Profit report seems to be ideal, I just need to find a way of masking the cost component for cashiers.

Can I send someone to you for training ??? Even if its for just 2 hours, he is quite smart.

Regards

11

Lagos??

Where are you?

12

Dear friends. I really think the new POS needs to be looked at again. If anyone has actually used this new POS in real retail operations; I’ll like to know how they navigate through it. I sat back and really tried this out (since all my clients use the old version - really good!).

Here are the things I noticed:

  1. On a VM, local, one-system install, invoices remain as draft after clicking submit
  2. Some invoices submit only if you click print
  3. It is mostly required to click Menu > Sync Offline invoices for invoices to get submitted (HUGE PROBLEM)
  4. Sometimes even on syncing, sales invoices remain as draft if you look at the Sales Invoice List
  5. Even when the VM was turned off (Server Down), clicking the sync buttons still progress as if the server is up!

Undoubtedly; this POS is faster but then lets look at this for high volume sales like supermarkets:

  1. Is it practical to DEPEND on a cashier to hit the sync buttons? I think, I really think the sync should be on-demand, only when the server goes offline, then an offline message should come to inform cashier and then script periodically checks for server and automatically syncs with message.
  2. Should sales stay locally in the browser even when the server is up? because I did not get one invoice to post to the server after clicking submit. All required to hit the sync buttons
  3. Is it practical to assume that a technical staff or supervisor will go synchronizing all the terminals?

I was strongly considering this due to the new features and great improvements in the other modules, but we cannot progress with this point of sales as we may have funny scenarios like:

  1. Over cash due to drafts; cash manager may not and mostly will not scroll the sales invoice list but will use the sales register report, so an intelligent cashier can decide not to sync her last few sales and ‘plan’ out the cash
  2. Stock becomes unreliable as customers have taken items but invoices haven’t updated

@olamide_shodunke sorry for the late response. I’m in Abuja.

NOTE: I also found this on the hosted solution.

1 Like
13

Am facing the same challenges as illustrated above.

To me the most disturbing drawback of this PoS module is the ability to print a transaction when payment is not fully taking from the customer. I have found no way to prevent this. When you put credit limits the invoice becomes a draft BUT the cashier can still print out as if the transaction is completed.

I just stopped using the PoS module.

14

Hi.
We want to improve the POS module. Some changes are presently being added by contributors to improve it.

Would you be able to open issues on github addressing these flaws, contribute a fix or start a bounty?

1 Like
15

Hi all,

I’ve had several issues with POS but over time, it’s improved significantly. Referring to the specific issues above, I really haven’t experienced this and we have the POS deployed in a number of stores. Sales get synced automatically as long as there’s an internet connection and the option to print comes only after a transaction has been completed

Could you please specify the version of ERPNext you’re using?

Cheers!

16

@tundebabzy Pls help.I made some sales in POS but invoices hanged and refused to sycn and remained in queue and because of this this error message is constantly being thrown up
Traceback (most recent call last):
File “/home/frappe/frappe-bench/apps/frappe/frappe/app.py”, line 56, in application
response = frappe.handler.handle()
File “/home/frappe/frappe-bench/apps/frappe/frappe/handler.py”, line 21, in handle
data = execute_cmd(cmd)
File “/home/frappe/frappe-bench/apps/frappe/frappe/handler.py”, line 52, in execute_cmd
return frappe.call(method, **frappe.form_dict)
File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 922, in call
return fn(*args, **newargs)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/doctype/sales_invoice/pos.py”, line 326, in make_invoice
submit_invoice(si_doc, name, doc)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/doctype/sales_invoice/pos.py”, line 475, in submit_invoice
save_invoice(e, si_doc, name)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/doctype/sales_invoice/pos.py”, line 482, in save_invoice
si_doc.insert()
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 192, in insert
self.run_before_save_methods()
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 772, in run_before_save_methods
self.run_method(“validate”)
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 666, in run_method
out = Document.hook(fn)(self, *args, **kwargs)
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 887, in composer
return composed(self, method, *args, **kwargs)
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 870, in runner
add_to_return_value(self, fn(self, *args, **kwargs))
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/document.py”, line 660, in
fn = lambda self, *args, **kwargs: getattr(self, method)(*args, **kwargs)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/doctype/sales_invoice/sales_invoice.py”, line 56, in validate
super(SalesInvoice, self).validate()
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/controllers/selling_controller.py”, line 33, in validate
super(SellingController, self).validate()
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/controllers/stock_controller.py”, line 17, in validate
super(StockController, self).validate()
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/controllers/accounts_controller.py”, line 47, in validate
self.validate_due_date()
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/controllers/accounts_controller.py”, line 125, in validate_due_date
validate_due_date(self.posting_date, self.due_date, “Customer”, self.customer, self.company)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/party.py”, line 302, in validate_due_date
default_due_date = get_due_date(posting_date, party_type, party, company)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/party.py”, line 267, in get_due_date
credit_days_based_on, credit_days = get_credit_days(party_type, party, company)
File “/home/frappe/frappe-bench/apps/erpnext/erpnext/accounts/party.py”, line 287, in get_credit_days
frappe.db.get_value(“Customer Group”, customer_group, [“credit_days_based_on”, “credit_days”])
TypeError: ‘NoneType’ object is not iterable
I have updated to the current version to avail

17

I can confirm that I have had the same issues. The only problem is, it is intermittent. Sometimes things work great. Sometimes they don’t.

The only reason I haven’t posted about this is because I have not been able to come up with any reproducible scenario. But yes, there is strange behavior sometimes.

18

Hi @Fred1
I believe the team is already working on this:
https://github.com/frappe/erpnext/issues/10147
https://github.com/frappe/erpnext/pull/10148

19

@felix

It is intermitent and absolutely reproducible. Make a few sample items and sell, close out with printing without printing, sync and all and you will see. 8 out of 10 transactions dont get submitted; and from my tests, the ones that get submitted require the user to hit sync offline invoices.

Please let the team look at this. Offline sales is not even a good idea for retail especially when its unreliable. I think the only thing missing from the old pos is split payments, for us we get into the code, hide the breadcrumbs, hide the form view switcher and you have a secure and efficient pos screen.

Kent@Live Mail. its official!

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/aeb1de/45.png] felixhttp://discuss.frappe.io/u/felix
July 28
[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/n/4da419/40.png]noetico:

On a VM, local, one-system install, invoices remain as draft after clicking submit
Some invoices submit only if you click print
It is mostly required to click Menu > Sync Offline invoices for invoices to get submitted (HUGE PROBLEM)
Sometimes even on syncing, sales invoices remain as draft if you look at the Sales Invoice List
Even when the VM was turned off (Server Down), clicking the sync buttons still progress as if the server is up!

I can confirm that I have had the same issues. The only problem is, it is intermittent. Sometimes things work great. Sometimes they don’t.

The only reason I haven’t posted about this is because I have not been able to come up with any reproducible scenario. But yes, there is strange behavior sometimes.

20

Unfortunately the sales ticket queue is a very real problem also. I have been contracting a developer team to fix the scan buffer issue and they are almost done with their changes. However, now that I can scan items without problems (thanks to my Dev contractors), I have also been finding the customer sales transa tions piling up in the queue even though the system has a strong internet connection.

POS really needs a rethink/rewrite. Unless the user is in a very low volume, low customer count, business, all of the problems in this thread will make for an insecure sales system and an accounting nightmare. The internal software decision algorythm for determining when to hold a sale in queue and when to use the internet connection for live transactions seriously confused. There is no reason to ho.d the sales in limbo when the connection is working. I have been finding this issues on a Windows10 POS terminal that is directyly wired to the network and the internet connection never faulters. This is NOT caused by a slow router, or bad wireless connection. My PC is hardwired to the network and this testing is the only traffic!

Next you will say you want me to make a girhub something-or-other for the issue. I am a lowly user and implementer. Aside from copying files from github sometimes, I really have no idea how to use it. I am not a programmer and the cataloging of software and related discussions in the github catalog structure is foreign to me. I have no account there and no understanding of how it works. That is why I come here to the forum. Sadly, this probably also the case for ,most people that come here to try to use ERPNext. Unless the developers can come up with a better way to address issues in the system brought to light by ‘users’ in the forum, they will find their otherwise beautiful project left in the dustbin of innovation history and some other player will have snatched away their victory in the small to medium ERP market.

POS has become a real sore spot in ERPNext that is overdue for attention.

BKM