Debugging of v12 issues moved to v13

Over the last 9 years I have seen ErpNext evolving from a rather primitive ERP/Accounting Package to a sophisticated full-fledged ERP system now competing with leaders in the field.

I have immense admiration for the 5-member founding team of which 4 are still active. I followed their struggle to find a financial sustainable business model while being religiously devoted to OS.

It seems they succeeded. Paying clients and Frappe workforce moved up steeply.

They deserve it.

Running a 2-person (my wife and myself) microenterprise I do everything. Running the business on a day to day basis, (sales & purchase), marketing, accounting, maintaining the website that runs under Erpnext. I am since 2011 a cloud user that frees me from all the headaches daily reported on discuss.frappe.io

It seems that we are about to move into a new era. Erpnext v13 with immutable ledgers.

I believe that there are many users who feel insecure. I never doubted migrating to the next version. Unlike many self-implementers this was never a problem. The few small hitches were immediately solved by the Mumbai team.

But this time I do doubt. Immutable Ledgers…how does this affect the way I do my accounts?

I run the administration probably the same way as many micro enterprises. Once in a while I spend a few hours doing accounts. Every 3 month I try to make accounts more or less complete and report VAT to the authorities. And at the end of the financial year I spend a full week or so comparing ERPNEXT accounts with my bank statements (manually, as integration is still a very weak point), entering the forgotten entries, calculating yearly subscriptions and cost like energy, insurances etc and enter them for the whole year on 31 dec 20xx. Repairing mistakes, wrong dates, and so on. Checks and double checks.

Negative stock is allowed so for sales I never have to bother about stock availability.

This all works brilliantly fine in v12.

But now??

Can I work the same way in Version 13. Enter or delete a sales or purchase invoice that dates from 9 month ago? I don’t know.

The implementation of the immutable ledger fits a trend. In Frappes zeal to make a more capable, more sophisticated ERP, fitting the needs of larger companies, sacrifices of end-user friendliness are made.

And this affects especially the users with a subscription. Ironically, Frappe depends on these paying customers.

Self implementers with the technical know how to modify the code will always find a solution. And are, with the exception of a few companies that contribute code, free-riders.

I will give a few examples of developments where technical constraints were given priority over end-users usability, friendliness, flexibility.

1.The layout of fields of a doc in the user interface (thus the order and position of the fields in e.g. a sales or purchase order) used to be user defined. This was difficult to maintain and thus abandoned. Technological difficulties/challenges are given priority over user friendliness.

  1. The web portal is a wonderful element of Erpnext. The end user could format the layout of the fields in the web interface. This caused issues and was thus abandoned . An end-user can not modify the webforms. Save has been disabled! Leaving the subscription user with a semi-functional module.

  2. The workflow of the webshop/cart is fully hard coded if there is no payment option. There is no control at all…not even a pop-up like…ÿou are now going to order…The team is very close to a professional webshop system. it is just a matter of adding the finishing touch and there is no need to integrate with professional shopping software. Erpnext can do it as well.

Similar for the integrated website builder.

  1. Over the years there have been endless discussions about the POS. Instead of making the POS as configurable as can be…the team opts (again, also in v13) for a hard-coded solution, leaving many users frustrated. The ease of hardcoding the options is preferred over the investment to make a POS system that suits say 90% of the users community.

It seems that all new functionality is moved to V13.

A recent remark that the “disable comments” for Blog articles as shown in manual is not available was replied with: “this functionality is moved to v13” .

Today I reported that the header info on a page is not working. Again the same reply…v13.

Also in version 12 there are functionalities that hardly work. The implementation (import of manual) of the CoA is a nightmare.

The import of a bank transaction file that can be linked to sales, purchases, a voucher is not or semi functional. In India cheques may still be used, but in Europe people under 30, do not even know what a cheques is.

I seems that ErpNext is hardly debugging v12…but repairs are made under v13.

And thus the users are more or less forced to move on.

I wonder (but do not know…) whether ErpNext would be more successful in attracting new paying customers if the present v12 is more flexible, repairing the many dead-ends, adding end-user flexibility and critically look at the shortcoming than moving on to V13 adding (again) limitations …this time the immutable ledger.

But above all I hope that the team will come with clear advice to the user community.

What to expect when moving to version 13. What is meant with Immutable Ledger. What is no longer possible. I have read the full thread, but to me the consequences of the immutable ledger to me as an end user are still very foggy.

If I Google “Immutable Ledger” I get only returns referring to blockchain technology. If I google “Immutable Ledger ERP” all the first returns point to ErpNext. So it seems other ERP vendors do not use this concept or term. It is ErpNext / blokchange jargon

Paying customers are all still on version 12. Bugs in v12 are moved to v13.

This is not fair

Best regards Robert

4 Likes

Hi Robert,
That’s a long piece with many points.
I am now a paying customer and have been moved to V13 this week.
I can tell you that bugs have been sorted between V12 and V13.
V12 has been running at an acceptable level for us. There are some bugs in V12 which are no longer in V13 but obviously there are some new bugs in V13!!! which were not in V12 :slightly_smiling_face:
I am trying to be comforted by the thought that the massive amount of new features of the software will soon out way the pain of the bugs.
I guess the money I am paying to Frappe to support the product directly finances the fixing of bugs for everyone using the software and by the same token, the community who are finding and fixing bugs, developing new ideas/features are benefitting my business.

I think your accusation that bugs are not being fixed in V12 is a little unfair when you look at the list of recent fixed bugs here Releases · frappe/erpnext · GitHub also bearing in mind the chaos this pandemic is casing everywhere in the world, not least India. That does not mean to say why are the bugs in there in the first place…

I agree Immutable ledger is not a great term.

This is how is explained to me.

"There are two kinds of transactions:

  • Financial Transaction (Invoices and Journal Entry)
  • Stock Transaction (Purchase Receipt, Delivery Note & Stock Entry )

In v13, they introduced the concept of Immutable Ledger which basically makes the Stock Transactions to only move forward,
for example, Suppose a Stock Transaction has been made for “Item A” with posting time as 19-06-2020 23:00:10 then after this transaction you cannot post a transaction for Item A with posting time before this timestamp.

Along with this, you won’t be able to delete any Stock Transaction, cancellation is allowed but even cancellation will have a reverse effect on the day of cancellation.

However, this doesn’t apply to Financial Transactions.

You can read more about Immutable Ledger here."

I will let you know how we get on with immutable ledgers. We have looked at the events in the last 12 months which triggered a stock transaction issue and implemented practices which must reduce the sources of errors so they are reduced in the first place (good practice?) then we will reconcile more frequently, to start with, to find ways of catching them quickly. I am certain we can get to an acceptable level of discomfort.

I don’t know what size of business you have to be when you need the comfort in knowing your staff are not able to fudge the stock transactions to make them look right.

If I have learned anything from the folks at Frappe, it is to evaluate my existing business processes, try and understand Frappes thinking behind a certain process then revaluate my process. I can tell you that most of the time this process leads me to a new process which is actually ERPNext standard process!
I really hate when they are correct. A caveat to that is that the ERPNext process was probably not obvious to me in the first place because, due to bugs, it was not working as Frappe had designed it to work and there had not been enough explanation or detail put in the help manual. Maybe the person writing the manual was not the person who designed the process?

There are so many things in ERP systems which are subjective. If there was only one way of looking at it there would only be the need for one ERP solution on the market. You too could be using SAP!

I have chosen this one and I am not going to make another change, life is too short. So immutable ledgers or not, I have to make it work for me.

I suspect you will also get over this little hicup and be able to move on, battle scarred, but determined!

One last comment is that I believe I am now benefitting from investing the Launchpad program and great things are starting to happen.

Chris

3 Likes

Hi Chris,

Thanks for you elaborate answer.

Well, I used to be rather active on this forum in the beginning (2011-12). Things were simple and there were 3-4- post per day. Now, 90% of the questions are from self implementers who face problems and the manuals are so much better now. So iI have become silent…but still read most of the content.

Then, when you do rarely write you write about your cumulated observations, ideas, frustrations.

I do withdraw my statement about not debugging v12 @umair @rmehta.

Concerning the immutable ledgers. Sales invoice are entered at the moment of sales. My wife however prefers paper. I copy them on a regular basis…with say a delay of maximum one month.
And still many small companies do write a paper invoice that is later entered in a bookkeeping system.
For purchases I always maintain the old workflow PO, Received, Invoice, Payment. At the end of the year when I do all checks I usually find several purchases that have never been entered.

From your explanation none of these late entries is possible under v13m since both sales and purchase have related stock transactions. Our business (dogsloveit@erpnext.com) is part-time and I live from my pension. I know I will not have the discipline to immediately enter all sales/purchases immediately. So I am afraid that I will have to stay with v12.

I do not need the extra functionality. The only part I am always eager to see improvements is the website builder and related Cart. Really a pity that I will miss the improvements here.

From the point of view of Frappe I can understand their move. ErpNext used (also) to target very small companies. This is no longer the case. With a minimum subscription of $2500 per year It is just to expensive for a micro-enterprise. There are plenty of online bookkeeping programmes with a simple stock keeping module as a cloud service fine-tuned to local conditions (bank integration, taxes) for 1/10 of the price ErpNext now takes. Yes, that is for one user only.

Conclusion: ErpNext has out grown me : slight_smile:

From a pure rational point of view I’d probably better move to a local provider of a bookkeeping program. But after 10 years looking at the ups and down, and witnessing the tremendous improvements , I probably will not make such rational decision, and stick with v12.
I still do hope that the immutable ledger will become optional in v13 to also keep their smallest customers happy.

@umair @rmehta any chance that the immutable ledger will become optional, or is this a no-go?

Best, Robert

Hello @becht_robert I am a fan of yours, I am therefore sorry to see you in this state of mind

Read the last post by @rmehta from the long discuss above, he states clearly that @nabinhait will make immutable ledgers optional. We are still waiting.

I am currently using version 13 in a real life environment and the immutable ledgers is a big pain in the butt. In my humble opinion it is not sustainable. I am waiting for @nabinhait to come up with the optional button/check.

To be truthful though V13 is BEAUTIFUL! really awesome.

Olamide

1 Like

My experience:

v13-beta4 immutable ledgers for financial transactions is not a problem as such. Just that you can’t delete a transaction, which our auditors love. It does show the transactions left behind that were hastily without checking posted to the general ledger. Apart from not being able to delete, all works well now. There was a time that transaction was canceled and it’s cancellation due to being recorded as reversal on the day of cancellation was creating an issue, but the reports have now been fixed not to show cancelled transactions and reports are correct now.

Regarding entering stock related back-dated transactions, yes, it’s a pain to not record your transactions backdated from the last stock entry per stock item. But, I think this is also being worked on, though if you enter sequentially backedated transactions and no current transactions, it works just like v12. Just dont’ enter backdated transaction after you entered curretn transaction

Mitesh Choksi

Hi @olamide_shodunke,

I have reread all threads including Nabin’s 2017 one.
Many opinions were aired. And it seems many people are still confused.

I believe the discussion of a couple of use-cases would clarify more than discussions.

Today is 17 oct 2020.
I have forgotten to enter an purchase (itemized) of May 2020.
How do I do this. Or not possible.
Somehow I forgot to enter a sales of august.
How do I do this. Or not possible.
I find a mistake in a sales/purchase invoice of Juli.
How do I fix this. Or not possible

Just some simple use cases with an “how to” would take away uncertainty.

And yes, let us hope that the team in Mumbai does not enforce but leave the option of using immutable ledgers

best Robert

This is based on my own practical experience

let us wait for good news from Mumbaii

1 Like