Current POS design appears to be flawed

ERPNext
21

That’s the definition of not reproducible. Why do the 2 get submitted and 8 not get submitted? And for me, the ones that get submitted get sync’d automatically most of the time. I need to manually sync only sometimes. But yes - sometimes I do need to manually sync even when I haven’t lost connection!

Don’t misunderstand me - I’m not saying there aren’t any problems. There absolutely are. It’s just that the behavior is so erratic, that it is difficult to point to the source of the issue beyond “offline POS”. @bkm’s last post showing his test steps are a great example of this.

EDIT: I’ll also state my opinion on solution. Offline should be removed from the browser. Then, a third party or foundation can build an Electron app or similar to take care of offline for those that need the functionality. It also becomes easier to use native printing, weigh scales, barcode scanners, cash drawers, secondary screens (customer-facing screens) with native apps. Yes there are downsides - fragmentation of the erpnext codebase, deployment in a store, testing new releases supporting multiple platforms, but I believe the upsides outweigh the downsides.

1 Like
22

@felix Spot on, its erratic i agree. And i second on the move to remove the offline and revert to live pos only. Let the IT departments in stores handle powet and data availability. For us we ask most clients to go with ssd drives for the server so crashes are rare and everything is fast. Then we do pure gigabit networks all way.

I can even say affirmatively that even hitting sync doesnt sync some. Funny enough printing is just one thing that makes submission complete.

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 29
[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/n/4da419/40.png]noetico:

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.

That’s the definition of not reproducible. Why do the 2 get submitted and 8 not get submitted? And for me, the ones that get submitted get sync’d automatically most of the time. I need to manually sync only sometimes. But yes - sometimes I do need to manually sync even when I haven’t lost connection!

Don’t misunderstand me - I’m not saying there aren’t any problems. There absolutely are. It’s just that the behavior is so erratic, that it is difficult to point to the source of the issue beyond “offline POS”. @bkmhttp://discuss.frappe.io/u/bkm’s last post showing his test steps are a great example of this.

EDIT: I’ll also state my opinion on solution. Offline should be removed from the browser. Then, a third party or foundation can build an Electron app or similar to take care of offline for those that need the functionality. It also becomes easier to use native printing, weigh scales, barcode scanners, cash drawers, secondary screens (customer-facing screens) with native apps. Yes there are downsides - fragmentation of the erpnext codebase, deployment in a store, testing new releases supporting multiple platforms, but I believe the upsides outweigh the downsides.

23

No to idea of removing the offline pos.we have great need of it.few problems that are in it now will be overcome.

24

Okay, I think I see the divide here between those asking getting rid of the use of browser cache for ‘offline’ POS sales, ad the developers that tell us the browser cache is very important to the POS system.

The real problem is a lack of understanding about exactly how the browser cache is being used. It is not only for the retention of sales that occur when the internet connection drops. It is apparently also used to attept to cache an entire quick reference table of all of the products/items in the database to make the right side of the screen where the items are displayed to populate faster and enable that endless search routine to operate when looking up items to add to the cart. The more items/products you have in your database, the more the browser is stressed to house the lookup table. Now add to that the need to keep track of online vs offline sales and it may very well be the browsers ability to manage it’s cache that could be causing some of the problems.

I personally really dislike the ‘endless search’ routine they use on the item grid in POS. As long as you add another character to the end of the search string the routine keeps trying to narrow down the displayed items in the grid. It is because of this action that the POS system cannot buffer barcode scans. This creates a condition where a good cashier will lock up the POS modle because the search routine cannot process the scanned code fast enough to clear the searcj bar and then next scan is accidentaly appended to the first one in a long string that the search routine cannot resolve.

Anyway, I get why the developers do not want to abandon the browser caching scheme. They depend on it for too many other functions. That over reliance on the browser cache may very well be the root cause of all of our POS problems. The developers have passed far to much responsibility for the operation of the POS module to a 3rd party cache manager that they do not control the code base to fix it. So, unless they write their own browser, I am not sure they can ever promise us a good POS module. I may be wrong, but I noticed that the more item I have in my item database, the more erratic the behavior of the POS module. I have a database of over 3000 items. At first I only imported a small portion (about 500 items) into ERPNext for testing. Later I bumped that up to 1800 items and the erratic operations increased. When I porting in about 3200 items, only 1 or 2 transactions in 10 would post properly.

I have already committed to spending a lot of money to generating a fix to allow a way to buffer barcode scans and let the system catch up to the user when they encounter natural pauses in their checkout flow. Now that I am alonst finishe with the scan buffer fix, it looks like I am still not going to be able to use the POS module. businesses cannot rely on their cashiers to go check if their transactions were all submitted properly or to take the initiative to force them to submit if they build up in the queue. It is the fact that transaction ‘appear’ to work properly but actually do not complete the submit process that will cause bad publicity for the whole ERPNext project.

What business owner would want to risk having their inventory numbers to get our of sync because the POS system is not completing the process? What happens when a cashier closes out their shift and powers down the device they use at the checkout stand? All of the buffers are discarded and the transactions caught in the hidden limbo state NEVER get into the system. I cannot think of any business that want to roll the dice on such a POS system.

To be fair and complete here, I am doing all of my testing on the latest ‘production’ version all the time. I have been dumping my system and rebuilding with a fresh production install about every two weeks now since the ERPNext version 8.0.22. I have never been more than two weeks out from the latest release production configuration. I dump the ENTIRE system lately because I found how to reinstall everything including he Debian operating system ins less than 30 min (using GCP and ready made OS images). I cannot see any purpose in testing with a developer configuration since I need production ready system for training the users and writing the documentation the users will depend on later.

I am not happy about spending so much money on fixing one ridiculous problem in POS only t have another even worse problem gt in my way again. I cannot put my clients on the POS module here with it not processing transactions!!! I am very disappointed that such an important module for small businesses is getting such little help. I still believe it need a complete rethink, rewrite, and redesign to make it work in a reliable fashion. Some small businesses only use POS to make their money. How can we continue to allow this module to not post transactions?!? This does not seem like a very good way to attract users. If they cannot trust the system to track their sales and inventory through the POS module, then why bother at all?

At this point I have no idea how I am going to complete my task to get a working ERPNext solution installed and switch everything over from our old ERP system. Too much of the business relies on the POS module for the income side of things.

BKM

1 Like
25

As I mentioned before I strongly agree that relying on browser cache for offline POS is really a worrisome. A suspicious user can easily exploit it without much need for technical expertise. Also the performance is crippled especially when you have lots of item

I think the POS should have its own standalone app. For desktops, I think it should be Electron app since it is cross platform (windows, linux, and mac) with same app, it its built using JavaScript, HTML, and CSS so most of current code will be reused. For iOS and Android, it should be a native app.
After having such apps, there should be an option to disable access to POS through browser.

In my personal opinion, I think that the only way moving forward to redesign the POS component and we should start a bounty for that.

1 Like
26

@bkm, your points about the browser caching may be the very reason why they should decisively remove.

Now let me tell you that I have over 6 retail clients with 10k+ items running the v6 pos!!! 3 Of them hbe close to 21k items and almost 2 years worth of transactions that are checked in time during sales and the pos module is still fast enough.

For barcode scanning speed, i dont see a problem and theres no need for over paced scanning. From experience; the cashiers even like to see that what they just scanned was loaded into the grid! infact we have edited the pos.html and pos-bill.html files using a transform so the last item scanned is on top because by popular client demand; the cashiers want to see the last item scanned and see it on top! (in v6).

All these clients are running fast and you know what! they are mostly installed in a vm with around 2gb of ram average and 2 processor cores max from the host, matter of fact over 10 installations have just 1 core from the host and they use the pos and even love the simplicity and speed!

Caching should be dumped. Pos module was good without caching and month after month, no cashier shorts and overs. Its just perfect asides the absence of split tenders.

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
July 30
[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/aeb1de/40.png]felix:

I’ll also state my opinion on solution. Offline should be removed from the browser.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/n/4da419/40.png]noetico:

Spot on, its erratic i agree. And i second on the move to remove the offline and revert to live pos only.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/e99b99/40.png]Fred1:

No to idea of removing the offline pos.we have great need of it.few problems that are in it now will be overcome.

Okay, I think I see the divide here between those asking getting rid of the use of browser cache for ‘offline’ POS sales, ad the developers that tell us the browser cache is very important to the POS system.

The real problem is a lack of understanding about exactly how the browser cache is being used. It is not only for the retention of sales that occur when the internet connection drops. It is apparently also used to attept to cache an entire quick reference table of all of the products/items in the database to make the right side of the screen where the items are displayed to populate faster and enable that endless search routine to operate when looking up items to add to the cart. The more items/products you have in your database, the more the browser is stressed to house the lookup table. Now add to that the need to keep track of online vs offline sales and it may very well be the browsers ability to manage it’s cache that could be causing some of the problems.

I personally really dislike the ‘endless search’ routine they use on the item grid in POS. As long as you add another character to the end of the search string the routine keeps trying to narrow down the displayed items in the grid. It is because of this action that the POS system cannot buffer barcode scans. This creates a condition where a good cashier will lock up the POS modle because the search routine cannot process the scanned code fast enough to clear the searcj bar and then next scan is accidentaly appended to the first one in a long string that the search routine cannot resolve.

Anyway, I get why the developers do not want to abandon the browser caching scheme. They depend on it for too many other functions. That over reliance on the browser cache may very well be the root cause of all of our POS problems. The developers have passed far to much responsibility for the operation of the POS module to a 3rd party cache manager that they do not control the code base to fix it. So, unless they write their own browser, I am not sure they can ever promise us a good POS module. I may be wrong, but I noticed that the more item I have in my item database, the more erratic the behavior of the POS module. I have a database of over 3000 items. At first I only imported a small portion (about 500 items) into ERPNext for testing. Later I bumped that up to 1800 items and the erratic operations increased. When I porting in about 3200 items, only 1 or 2 transactions in 10 would post properly.

I have already committed to spending a lot of money to generating a fix to allow a way to buffer barcode scans and let the system catch up to the user when they encounter natural pauses in their checkout flow. Now that I am alonst finishe with the scan buffer fix, it looks like I am still not going to be able to use the POS module. businesses cannot rely on their cashiers to go check if their transactions were all submitted properly or to take the initiative to force them to submit if they build up in the queue. It is the fact that transaction ‘appear’ to work properly but actually do not complete the submit process that will cause bad publicity for the whole ERPNext project.

What business owner would want to risk having their inventory numbers to get our of sync because the POS system is not completing the process? What happens when a cashier closes out their shift and powers down the device they use at the checkout stand? All of the buffers are discarded and the transactions caught in the hidden limbo state NEVER get into the system. I cannot think of any business that want to roll the dice on such a POS system.

To be fair and complete here, I am doing all of my testing on the latest ‘production’ version all the time. I have been dumping my system and rebuilding with a fresh production install about every two weeks now since the ERPNext version 8.0.22. I have never been more than two weeks out from the latest release production configuration. I dump the ENTIRE system lately because I found how to reinstall everything including he Debian operating system ins less than 30 min (using GCP and ready made OS images). I cannot see any purpose in testing with a developer configuration since I need production ready system for training the users and writing the documentation the users will depend on later.

I am not happy about spending so much money on fixing one ridiculous problem in POS only t have another even worse problem gt in my way again. I cannot put my clients on the POS module here with it not processing transactions!!! I am very disappointed that such an important module for small businesses is getting such little help. I still believe it need a complete rethink, rewrite, and redesign to make it work in a reliable fashion. Some small businesses only use POS to make their money. How can we continue to allow this module to not post transactions?!? This does not seem like a very good way to attract users. If they cannot trust the system to track their sales and inventory through the POS module, then why bother at all?

At this point I have no idea how I am going to complete my task to get a working ERPNext solution installed and switch everything over from our old ERP system. Too much of the business relies on the POS module for the income side of things.

BKM

27

@bkm, if you really need to just get an older version. Cuatomize the pos with split tenders. I know you’ll be missing some of the good stuff in other modules like purchase invoices upating stock, grid item bulk selection etc. But again, I have found that users have been doing just fine without it!

if you weigh the options as you have also pointed out, using a working pos module vs the new perks is the way to go; the pos is so critical that the v8 implementation is totally unacceptable for business, simple. The lack of push from the community tells me so few may be using the software for core retail that requires a reliable, dependable pos system accurately pushes stock balance and account balances.

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
July 30
[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/aeb1de/40.png]felix:

I’ll also state my opinion on solution. Offline should be removed from the browser.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/n/4da419/40.png]noetico:

Spot on, its erratic i agree. And i second on the move to remove the offline and revert to live pos only.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/e99b99/40.png]Fred1:

No to idea of removing the offline pos.we have great need of it.few problems that are in it now will be overcome.

Okay, I think I see the divide here between those asking getting rid of the use of browser cache for ‘offline’ POS sales, ad the developers that tell us the browser cache is very important to the POS system.

The real problem is a lack of understanding about exactly how the browser cache is being used. It is not only for the retention of sales that occur when the internet connection drops. It is apparently also used to attept to cache an entire quick reference table of all of the products/items in the database to make the right side of the screen where the items are displayed to populate faster and enable that endless search routine to operate when looking up items to add to the cart. The more items/products you have in your database, the more the browser is stressed to house the lookup table. Now add to that the need to keep track of online vs offline sales and it may very well be the browsers ability to manage it’s cache that could be causing some of the problems.

I personally really dislike the ‘endless search’ routine they use on the item grid in POS. As long as you add another character to the end of the search string the routine keeps trying to narrow down the displayed items in the grid. It is because of this action that the POS system cannot buffer barcode scans. This creates a condition where a good cashier will lock up the POS modle because the search routine cannot process the scanned code fast enough to clear the searcj bar and then next scan is accidentaly appended to the first one in a long string that the search routine cannot resolve.

Anyway, I get why the developers do not want to abandon the browser caching scheme. They depend on it for too many other functions. That over reliance on the browser cache may very well be the root cause of all of our POS problems. The developers have passed far to much responsibility for the operation of the POS module to a 3rd party cache manager that they do not control the code base to fix it. So, unless they write their own browser, I am not sure they can ever promise us a good POS module. I may be wrong, but I noticed that the more item I have in my item database, the more erratic the behavior of the POS module. I have a database of over 3000 items. At first I only imported a small portion (about 500 items) into ERPNext for testing. Later I bumped that up to 1800 items and the erratic operations increased. When I porting in about 3200 items, only 1 or 2 transactions in 10 would post properly.

I have already committed to spending a lot of money to generating a fix to allow a way to buffer barcode scans and let the system catch up to the user when they encounter natural pauses in their checkout flow. Now that I am alonst finishe with the scan buffer fix, it looks like I am still not going to be able to use the POS module. businesses cannot rely on their cashiers to go check if their transactions were all submitted properly or to take the initiative to force them to submit if they build up in the queue. It is the fact that transaction ‘appear’ to work properly but actually do not complete the submit process that will cause bad publicity for the whole ERPNext project.

What business owner would want to risk having their inventory numbers to get our of sync because the POS system is not completing the process? What happens when a cashier closes out their shift and powers down the device they use at the checkout stand? All of the buffers are discarded and the transactions caught in the hidden limbo state NEVER get into the system. I cannot think of any business that want to roll the dice on such a POS system.

To be fair and complete here, I am doing all of my testing on the latest ‘production’ version all the time. I have been dumping my system and rebuilding with a fresh production install about every two weeks now since the ERPNext version 8.0.22. I have never been more than two weeks out from the latest release production configuration. I dump the ENTIRE system lately because I found how to reinstall everything including he Debian operating system ins less than 30 min (using GCP and ready made OS images). I cannot see any purpose in testing with a developer configuration since I need production ready system for training the users and writing the documentation the users will depend on later.

I am not happy about spending so much money on fixing one ridiculous problem in POS only t have another even worse problem gt in my way again. I cannot put my clients on the POS module here with it not processing transactions!!! I am very disappointed that such an important module for small businesses is getting such little help. I still believe it need a complete rethink, rewrite, and redesign to make it work in a reliable fashion. Some small businesses only use POS to make their money. How can we continue to allow this module to not post transactions?!? This does not seem like a very good way to attract users. If they cannot trust the system to track their sales and inventory through the POS module, then why bother at all?

At this point I have no idea how I am going to complete my task to get a working ERPNext solution installed and switch everything over from our old ERP system. Too much of the business relies on the POS module for the income side of things.

BKM

28

Lets forget product caching now. Just build a fast server, if budget is tight use a 120gb ssd and put in 8gb or RAM to a standard core i3 or even late intel pentium pc and the pos runs fine without caching. This is not hypothesis this is something we have done for more than 10 clients. Check these images out; this store started lately. Server is a normal pc with 4gb ram and normal 7200rpm hdd (we have an ssd to upgrade later). over 10k items already and the sales are smooth.

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
July 30
[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/aeb1de/40.png]felix:

I’ll also state my opinion on solution. Offline should be removed from the browser.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/n/4da419/40.png]noetico:

Spot on, its erratic i agree. And i second on the move to remove the offline and revert to live pos only.

[http://discuss.frappe.io/letter_avatar_proxy/v2/letter/f/e99b99/40.png]Fred1:

No to idea of removing the offline pos.we have great need of it.few problems that are in it now will be overcome.

Okay, I think I see the divide here between those asking getting rid of the use of browser cache for ‘offline’ POS sales, ad the developers that tell us the browser cache is very important to the POS system.

The real problem is a lack of understanding about exactly how the browser cache is being used. It is not only for the retention of sales that occur when the internet connection drops. It is apparently also used to attept to cache an entire quick reference table of all of the products/items in the database to make the right side of the screen where the items are displayed to populate faster and enable that endless search routine to operate when looking up items to add to the cart. The more items/products you have in your database, the more the browser is stressed to house the lookup table. Now add to that the need to keep track of online vs offline sales and it may very well be the browsers ability to manage it’s cache that could be causing some of the problems.

I personally really dislike the ‘endless search’ routine they use on the item grid in POS. As long as you add another character to the end of the search string the routine keeps trying to narrow down the displayed items in the grid. It is because of this action that the POS system cannot buffer barcode scans. This creates a condition where a good cashier will lock up the POS modle because the search routine cannot process the scanned code fast enough to clear the searcj bar and then next scan is accidentaly appended to the first one in a long string that the search routine cannot resolve.

Anyway, I get why the developers do not want to abandon the browser caching scheme. They depend on it for too many other functions. That over reliance on the browser cache may very well be the root cause of all of our POS problems. The developers have passed far to much responsibility for the operation of the POS module to a 3rd party cache manager that they do not control the code base to fix it. So, unless they write their own browser, I am not sure they can ever promise us a good POS module. I may be wrong, but I noticed that the more item I have in my item database, the more erratic the behavior of the POS module. I have a database of over 3000 items. At first I only imported a small portion (about 500 items) into ERPNext for testing. Later I bumped that up to 1800 items and the erratic operations increased. When I porting in about 3200 items, only 1 or 2 transactions in 10 would post properly.

I have already committed to spending a lot of money to generating a fix to allow a way to buffer barcode scans and let the system catch up to the user when they encounter natural pauses in their checkout flow. Now that I am alonst finishe with the scan buffer fix, it looks like I am still not going to be able to use the POS module. businesses cannot rely on their cashiers to go check if their transactions were all submitted properly or to take the initiative to force them to submit if they build up in the queue. It is the fact that transaction ‘appear’ to work properly but actually do not complete the submit process that will cause bad publicity for the whole ERPNext project.

What business owner would want to risk having their inventory numbers to get our of sync because the POS system is not completing the process? What happens when a cashier closes out their shift and powers down the device they use at the checkout stand? All of the buffers are discarded and the transactions caught in the hidden limbo state NEVER get into the system. I cannot think of any business that want to roll the dice on such a POS system.

To be fair and complete here, I am doing all of my testing on the latest ‘production’ version all the time. I have been dumping my system and rebuilding with a fresh production install about every two weeks now since the ERPNext version 8.0.22. I have never been more than two weeks out from the latest release production configuration. I dump the ENTIRE system lately because I found how to reinstall everything including he Debian operating system ins less than 30 min (using GCP and ready made OS images). I cannot see any purpose in testing with a developer configuration since I need production ready system for training the users and writing the documentation the users will depend on later.

I am not happy about spending so much money on fixing one ridiculous problem in POS only t have another even worse problem gt in my way again. I cannot put my clients on the POS module here with it not processing transactions!!! I am very disappointed that such an important module for small businesses is getting such little help. I still believe it need a complete rethink, rewrite, and redesign to make it work in a reliable fashion. Some small businesses only use POS to make their money. How can we continue to allow this module to not post transactions?!? This does not seem like a very good way to attract users. If they cannot trust the system to track their sales and inventory through the POS module, then why bother at all?

At this point I have no idea how I am going to complete my task to get a working ERPNext solution installed and switch everything over from our old ERP system. Too much of the business relies on the POS module for the income side of things.

BKM

20170729_172728_resized.jpg1223×688 281 KB

20170729_172725_resized.jpg1223×688 275 KB

20170729_172715_resized.jpg1223×688 283 KB

20170729_145135_resized.jpg1223×688 300 KB

30

@ganas

We just paid a bounty of over $1,000 to improve this PoS and we still end up with a solution that is un-useable. I am not happy about this and I do not think any other contributor will be eager to jump on another bounty bandwagon if this flaw is not fixed.

This is an unexpected flaw and I believe the guys at ERPNext should look at it and fix it, then we can look at other features/directions if need be.

I know @rmehta does not like to be tagged in posts, but I believe this is important enough to break this rule. Also @JayRam needs to weigh in on this. This is Bounty gone wrong and it is very discouraging especially since this was one of the more successful bounty raising ventures.

Fix this PoS issue please

Sorry if I offended anyone.

Olamide

31

In my opinion ** any ** important transaction should run on the server, not on the browser. All that involves dealing with stock movements, movements in the POS, money (invoices, discounts, credit notes), generation of official documentation, delivery to taxes, etc … For security, without going into performance or loss of data, for that too.

I would cache POS in the latest products data type images, descriptions, previous historical prices, etc … but never the movements or critical things.

In this issue I am on the side of those who ask to deactivate the cache. Firstly from what I mentioned above, I find it critical. Secondly because having second-hand businesses, in these we do not have any stock per product. We have unique products with one unit that we buy from people in the store, so my catalog varies every minute and is not an exaggeration. Caching does not make sense in this scenario either.

I also do like the idea of external POS comunication by REST, so that it can be used both from browser, mobile device or desktop. This would even allow external clients to be made by comunity with gtk, qt, .net/mono, Electron as the companion commented, wxwidgets …

2 Likes
32

@meigallodixital. You captured it well, simple, dont cache critical transactions in a browser. There’s just no need, let the IT people take care of keeping thir server up. I’m sharing some more images of our current pos and how sales are instantly submitted reliably. IF YOU NEVER RAN A BUSINESS ON THIS VERSION OF ERPNEXT YOU MAY BE MISSING SOMETHING!! Its so good that I just keep a prepared VM expanded to 2TB and I just import appliances and we have stores up in no time. I even keep an image with over 8000 supermarket and pharmacy items so we can start stores even quicker.

erpnextscreenshot2.png1600×900 57.3 KB
erpnext_screenshot.png1600×900 49.4 KB

33

@noetico

How do you handle customer creation from the PoS end in version 6? I recall that from the PoS end you could only key in the customer name and nothing else.

Or do your retailers not need to capture customer details at the PoS level?

Regards

34

No pointing fingers. We did what was best at that time and we don’t to be neither overly critical nor defensive about what we did in the past.

Please put your heads together and come up with the changes you need and let’s see the easiest path to help us get there.

Can one of you please take the responsibility to get all concerned peoples’ inputs and to come up with a final list of specs for the POS module?

Thanks

Jay

5 Likes
35

100% agree, the world is moving forward looking for solutions not guilty. It is very complicated to make a system that make happy and works for everyone.

I think that regardless of the problems generated we all understand that Frappe has done what at the time seemed the best option. We are the ones that use the system and have large volume of data or more specs that we are going to detect where it can break. Give feedback and help where we can its our responsability.

1 Like
36

ok. Here’s a summaryof what we have done overtime and at different levels in other shops.

Scenario 1. pure retail, no named customets

  1. Setup users and default customer entities for each cashier with pos profiles. Use sales register for reports

Scenario 2. loyalty based sales - named customers

We made some modifications our pricing rule python file to automatically give discount to a certain customer group after a certain amount of purchases. This is just an addition.

Main tasks. Edit sales register report js, py files so you can sum sales by username not customer as available by default. This way you can handle customers with different names at a standard pos.

We assume as policy that the creation of customers will be by a customer care rep, but in the absence of that or where management allows entry by cashier we add the rolesband cashier can toggle to form view, quickl enter details and conytinue sales.

To speed this up we enter Defaults for territory, customer type and group so only personal details are entered.

Both scenarios work perfectly. In fact we run some of the most efficient and complete retail operations here in our area due to the end to end features offered by erpnext.

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 30

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

How do you handle customer creation from the PoS end in version 6? I recall that from the PoS end you could only key in the customer name and nothing else.

Or do your retailers not need to capture customer details at the PoS level?

Regards

37

Just as we want to appreciate the concerns of others over the new POS,i want to plead with the Team never to discard the the off-line feature because we need it badly in our organization.Our items are services and we never experience all the issues raised above.In remote places where there no Internet they can still get people enumerated without Internet.While we plead for solution to be found to my friends concern,off line feature should be retained

2 Likes
38

Those who suffer from POS bugs could use since sort of database replication from their local instance to the instance in the internet and not fall into this trap. Offline - online feature is extremely difficult and fickle in it’s performance and you should user tried and tested solution such as database replication.

39

Sorry not participating here. Will be great if someone can summarize this discussion and identify the key issues. We can make the offline feature optional.

I am listing the issues here:

  • Barcode (slow search)
  • Offline optional
2 Likes
40

We built exactly as per the features wanted. I think multiple users verified the design before it was closed. It is important to note that any new feature usually takes sometime before it matures.

1 Like
41

  1. Sync should be efficiently carried out and not need manual intervention when system is online

  2. Option to make it impossible for a cashier to complete a transaction if payment is not fully tendered either in cash or card.