For those unaware, Books was a basic accounting and inventory app built on Electron/Vue as a desktop app. Think of it like “ERPNext Lite”. It went unmaintained for quite some time due to lack of an owner.
That repo has now been archived and Books has officially reached its end of life. It is being succeeded by Frappe Books, pretty much the same app except this time built on the Frappe Framework with Frappe UI on top and a mobile app (PWA) to go along with it. Documentation has also been updated with the latest changes.
Do install it and check it out (develop branch only for now). If you find any issues, please make a GitHub issue accordingly.
We hope this new version does justice to the reputation of the old Books
This is interesting. I’m curious how well it can integrate into a site running Frappe CRM. I think it could be a winning combo if it could have one set of customers/contacts, etc.
Maybe custom installer when adding Books to a site already running CRM.
I didn’t realize “Develop” branch would mean a minimum Frappe version > 17.
So, Frappe Books will be in the Development branch for a couple of years, yes?
This puts a production-ready/stable version a couple of years in the future?
@mihir-kandoi It looks like Frappe Version 17 has major architectural changes. I’m a bit confused by this excerpt from the documentation. Does the following apply to user-created doctypes when creating a custom app? Does this mean more code to be written vs. the “low code/no code” selling point that Frappe has been based on? Perhaps this is just over my head
Put each fill, default and rule in the controller.
If the form shows values that the server fills, add a whitelisted preview.
In the DocType JSON, set each placeholder, and the depends_on rules.
Write the model: extend FrappeDoc, set doctype, presentation and previewMethod, and use Frappe fieldnames.
Give each table that needs one a row model in rowModels.
Register the model in frappeModels.
Find each link to the doctype (grep '"options": "Books X"' in the DocType JSON files). Set its filters and createFilters in Frappe fieldnames.
Add route filters for the lists of the doctype (src/utils/filters.ts, sidebar, Get Started) in Frappe fieldnames.
Add node tests for the model and the form layout, and a Playwright spec for the screens.
I myself am unsure at this point. I will try a v16 version soon.
That was not meant to be user facing, its just some internal instructions Claude made and used itself. The /books SPA currently only supports Custom Fields (through the Settings tab, not through Desk’s Custom Field DocType) and no other customizations right now. I will remove it so it doesn’t cause more confusion.
So I think the problem is that if someone installs either CRM or Books as standalone apps.
One idea could be that all fields that rely on another app (e.g. HRMS needs employee from ERPNext) should be installed as standard at the framework level otherwise we will always have this reco/sync problems
Can anyone with core Framework experience comment if this is possible and what would be the pros and cons
Please, Let’s not make this into something it isn’t. IMO books would be a less capable version of erpnext when it comes to integrations, focused on doing one thing, accounting, and doing it simply and well. If integrations are necessary there is always erpnext.
You could maybe focus on an easy and well documented upgrade route?
Yes, that is what books was and is now. I was just asking that we be careful about integrating to many outside features as to not recreate erpnext. As it is now, both have there place and uses and hopefully it can stay that way.
There are many businesses that don’t manufacture, don’t have multi company, don’t need HRMS, etc. What they do need is a solid accounting app with multi user access, with the ability to combine other business apps, project management, CRM, along with adding custom apps.
