I just cleared the browser (last 2 hours) fully and here’s my list… emptied, reads clearly, no customers yet but I’ve had 5, 2 showing paid; and I vacuumed them with my browsers’ clear history feature, sales invoice list, no records, the 2 paid stuck sales are gone forever. the other 3 are in draft so sales register nothing also, cache is cleared so should cash officer submit these as cashier’s browser cannot sync again? and why? are they valid? why should he/she submit a draft created by a cashier? was this sale complete? was it a mistake? hard to tell. its invalid, in real business this should be queried at the end of sale, its a major problem for the sales people.
I don’t even believe with all the security issues in today’s world, someone will want to keep financial transactions and master data inside a browser that may have an internet connection! Correct me if I’m wrong on this; is the cache of all popular browsers hacker-proof? What about slightly older browsers? Are they also secure? Because this works in some recent but older versions of Chrome and Firefox. Is there an issue here?
Is it possible for a hacker to lift data like stock, customers and prices from the cache?
@noetico some of these issues are already mentioned inside the topic. Try to make your replies concise to the point and aggregate them in one reply. Its better than spamming the topic with tens of replies as readers will get lost and will be hard to follow the topic. Thanks
@noetico We understand your point about the older version 6 of ERPNext working so well for you with POS, but your idea of us all going backwards to that old version is actually diluting the important point of fixing ERPNExt version 8.4 and beyond with a good working POS module. I actually considered for a few minutes trying out an older version, but I (and I fear many others) do not want to be in your position of being firmly stuck at versions 6. The transitions from version 6 to version 7 were not reliable and about half the time the system upgrade process left errors that took a great deal of energy to repair. The transitions from version 7 to version 8 are even worse. I do not recall of reading a single upgrade that went well and most are still stuck in version 7 because they cannot afford to loose all of their data when it does not upgrade well. So to me your idea is not worth the trouble to go backwards and possibly be stuck there forever. So may new features and fixes went into the manufacturing and purchasing modules since version 6 that I cannot even consider it.
Again, building a faster server is not a real solution. I am running on Google Cloud Platform and have scaled the system up to 15gb of memory and 4 cpu’s for testing and found no measurable relief.
My point exactly! I have already committed a developer contractor to prepare a fix for the barcode scan buffering and they are nearly finished. When it is done I will have paid as much as your bounty (and possibly even more) to fix a problem that still will be added to a useless POS module. Useless because I cannot trust it to handle the simplest of tasks like decrementing inventory and crediting accounts when a transaction ‘appears’ to be done.
Isn’t that something the foundation should do? If any of us were to start down that road, it would be a very biased end result. Most of us are NOT developers, we are users or implementers. Knowing the problems we described here, it should be the original developers of this version of POS that would best know how much of it can be salvaged and what parts need to be tossed out and redesigned.
I and many others are using a cloud based erpnext system (mine is on Google Cloud Platform) so thhe idea that these problems are only with local installations is a mistake. The issues are version related and not host related.
Ok so lets make sure to add the unreliable transaction submit process of a POS sale. This does not appear to be related to whether a transaction is cached as offline (even though the internet is not down). Some transactions just never deduct inventory from stock and add the sales funds to accounts. Not a single one of my cashier users would be able to figure out when something has been completely submitted or what the might do to remedy the issue. They are all great customer relations people, not software troubleshooters.
It is this last issue that has turned me off to the system in general. If the POS system cannot be trusted to manage the inventory and the money, then how could I trust any of the other modules to do the same?
@bkm and all; Please dont get me wrong! I’m not saying stay on v6! I’m saying before a fix,if you must use the system for clients and avoid even court cases (haha), stay on v6 to 7 for supermarket style operations. Going forward; the design also should be based on the reliability of online-only POS in previous versions, improve their touch friendliness as stated by others.
For upgrades I totally agree; I have basically wept on this forum about that, the updates mostly fail so I have never upgraded a client’s server, I know fom local attempts that the updates/upgrades usually leave the server with internal error or updating, we’ll be back soon. I have one v8 I just needed to update, same version, It still failed. With this in view, I say if you have something working in production, take a backup (full server image not db only), test the update on a different system, note the steps if you succeed. Hitting bench update on a production server could put you in big trouble.
If you want to update talk to @bobzz_zone. He has done miracles in different areas for me.
You will have to count me out until I am able to get value for the one I contributed to that’s still unusable.
And when you say we got what we paid for in the last bounty …do we need to set a bounty to correct a bug? Cause that is what this offline syncing matter is …a bug.
I will really be interested in seeing how many of the last contributors will line up behind this bounty request.
I think you got me wrong, those are bugs and they have to be fixed before moving any further with any new suggestions. What I meant is that the bounty was mostly about the design and other futures like adding client interface, client queue, item grouping, keypad, item level discount and price change, touch friendly … etc Those are all delivered and working fine, the problem here is mostly the slow search bar and offline syncing integrity and those has nothing to do with previous bounty as they are result of problems with the offline implementations which existed before the bounty and its still causing most of the bugs mentioned earlier.
All I’m saying is that offline implementation through the browser can’t be valid because the cache lives in the browser session. Thats why the only way I (at least in my opinion) is to have a native app for the POS, that how would you provide efficient offline functionality with security and data integrity, and it will solve other problems for hardware compatibility.
Well, the Foundation has a volunteer CEO (me), volunteer Directors and four dedicated developers. The Foundation does not have domain experience in every module and feature of ERPNext.
Therefore we need people from the community to step up and assume responsibility for putting together the specs. Sure it could be biased, but it will not be any more or less biased than if a Foundation resource were to do it. And even if it were more biased it would be more thorough thanks to the contributor’s, involvement, passion and familiarity with this domain/feature.
A Foundation resource will definitely validate the specs before we get onto the development stage.
So my request to everybody is: Stop complaining and start compiling (the specs) and when somebody does, please don’t use paragraphs or justifications. Just crisp bullet points. Like (all hypothetical points - any resemblance to real points is serendipitous):
Submittal of POS transaction must be reliable
Search of item code must be exponentially faster
Easier maneuverability between various screens
Please just provide the business requirement. Let somebody knowledgeable figure out if it is because of caching, because of the way we have implemented offline POS that’s resulting in the problem.
You could add security to this issue, if you have concerns around this.
Somebody, please step up.
You guys know we have a Foundation Fellowship program going. Here’s the link:
I’m not saying stepping up will get you the fellowship, but it would definitely be the beginning of the journey to Fellowship.
Foundation fellowship is a good thing, but for me, if we want people to contribute to the project there must be good documentation of development, not just youtube webinars.
I speak for our case. We have many peculiarities in the business, so we will have to make enough modifications and we do not see a clear starting point. As I said in other threads our intention is to free all code that does not have to do with internal knowledge logic obviously, we also have in mind translate the user manual to Spanish since we have seen that this translation is abandoned, etc. But before collaborating with contributions for the community we first need to have the erp running in the company (companies), and running stable.
I agree 100% with you that here are two parts that have to push the development of Erpnext, on the one hand the foundation and on the other hand the community. But at the moment I think it’s becoming a social mass of users and I think it’s time to ‘sacrifice’ and efforts to dedicate it to giving tools to the community, be it documentation, training as a consultant without thinking so much about the business, create knowledge within it to grow as other projects have done. Let’s remember how Odoo started …
For us it is a critical functionality POS module, we would have no problem assuming even developing a ‘corrected’ version, but we do not have a knowledge base of the operation of frappe / erpnext right now to take that task with guarantees.
We would be happy to be part of the Foundation Fellowship. This would mean that we are using ERpnext in production and contributing to the community. Hopefully this will come but right now I think the entry conditions are ‘high’, because we do not see that there are the right tools for people to be able to join this with guarantees. I always talk about the part of collaborating with code, which is the complex part.
I appreciate your input and can empathize with your frustrations.
But all I thought was to ask for a volunteer to compile the requirements.
We might even be able to depute a Foundation development resource to translate the requirements into code and solutions.
You perhaps read too much into my words, where I was trying to inspire the community to contribute code. I mean, in a way, I am, but that is the medium - long term hope.
For now, we have Foundation resources (4 Programmers) and we can deploy them for this project if somebody volunteers to come up with the requirement list.
I think the first step to take would be to solve the issue of transactions not being submitted even if there is a solid internet connection. That seems to be a critical issue.
The other problems are potentially problematic, but losing transactions is critical, in my opinion.
Would love to see some contributions from 
