There are a million things I like about ERPNext.
Context:
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.
- 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.
- 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.