Some things I do not like about ERPNext

There are a million things I like about ERPNext.


In the old days of monolith - local Intranet, the mantra was Codd normalization, Do Not Repeat Yourself, Storage is Expensive and Computation is Cheap. Secret sauces and side effects of Class inheritance are considered elegantly DRY. Data duplication is bad and Data retrieval is slow.

In today’s world of Microservices, security, hack attacks, and potential user base in the millions , the mantra is Storage is cheap, Computation and Network bandwidth are expensive, Class inheritance brings confusion and slows down coding. The tight coupling of objects eventually creates a nightmare of rigidity. Composition and Functional programming brings more clarity. The loose coupling allows reuse and patterns throughout the teams and organization. Data duplication avoids Recomputation and frees up Computation power and avoids Network bandwidth (if data has to be retrieved from multiple sources). Data retrieval is fast because of SSDs. User base are potentially in the millions. Simpler is better. I mean, things have changed in response to experience as well as technology.

Here I list the things I do not like.

  1. Account Name

Account Name contains magic code. It gets performs computation on Account Name, Account Number, and Company abbreviation, and splits it up again when needed.

It would be simpler if Name of Account (ID) is a hash or Generated ID that is never changed. Account Name, Account Number are recorded as the User inputed it. No magic transformation of attaching Company suffix at the end. If the User wants it, let him do it himself.

Account Names and Account Numbers may be recorded (duplicated) in other tables along with the Account Name (ID).

When Account Names change, the affected Names and Account Numbers in other tables may or need not be changed. In some organizations which transition into different Chart of Accounts coding, they may want to retain the original Account Codes in the old entries (for legal compliance), but relate the new Codes to the old codes, and have account totals using the new Code. By not automatically changing the Names and Codes for all entries, you can fulfill this requirement. (Not to mention avoidance of computation power).

The current Account Name is magic and side-effect. I do not like it.

  1. Warehouse as Cost of Goods.

This is an example of how a functionality reaches out to another functionality and creates confusion and inflexibility.

Warehouse is meant to be a location of goods, and not an accounting code.

The thing is, the Account Name in the Warehouse is used as the Cost of Goods Sold for ALL items stored in it.

Stock Item is Inventory (making sure that no item gets lost and counting), Accounting is money.
Warehouse as Cost of Goods is bad.

1 Like
  1. SQL SUM for Financial Reports.

Everytime you produce need an Income Statement and Balance Sheet, ERPNext goes back to the beginning of time and recomputes all ledger entries to come up with the totals.

It would be nicer if ERPNext stored periodic (monthly and annual) totals and used these totals for Financial Reports.

At the moment, an entry error in a previous year or accidental cancellation would impact the Financial Statements.

Even Manual Accounting relies on Totals. When you get the total, you may lose the Journal book containing the original entries, but you don’t care because you just go to the totals of the previous year.

ERPNext recomputes all the entries of all years over and over again. I do not like it.

Helo @Joseph_Marie_Alba1
as you can see am just a regular community memeber with no title, however being a community mmeber i thing give the righ to reply to your statement. ERPNext is open source application whice means you can controbute to the code to make it work like your suggesion if you thing that would be better for your instant.

I want to comment on point 3 - Every accounting system comes with Accounting Period like ERPNext is do have Accounting Period you can close the Accounting Period to prevent change of data so your finance will not be impacted.

1 Like

If you see the code, the Account Period totals is not used.
These totals can be put to better use.
The over-all totals are produced by SQL SUM which goes back to the beginning of time.
This is quite dangerous, and I learned my lesson when I did my own Financial Accounting software. Periodic totals saved me a number of times. It also assures the Financial Accounting department that there are no surprises for the current period.

Yes, I have contributed code to make fixes in ERPNext. That is why I respect Frappe team.