Hi I am busy doing a lot of reading up about customization ( Form , Doctype etc)
I am looking around on my backend trying to find files. I found the doctypes.
And I can see that the doctype have not been updated which is what I was expecting because
I did not change the doctype.
I simply customized the Form. But where are those changes saved ?
Any customizations made from the Customize Form toll will be saved in the database, in a few different tables such as Custom Field and Property Setter. These changes are not saved to the file system, which is important because any changes to the Frappe/ERPNext source files will be wiped out on every update.
Thank you for taking the time. I have been reading and looking at videos for the entire day, in
an effort to understand “Doctypes” and “Forms”. I dont even want to go into the detail of
what I did on the backend ( via SSH ) to search for these changes. Never thought of a table
in the database. So … thank you.
What I found …
It seems the changes are indeed in tabCustom Field …Cool …
Oh… this is related to my post …
So, in short what I did was to add a field each to "Stock Entry Detail’ and
“Purchase Receipt Item”.
I noticed that these tables have indeed those fields added to the respective database-tables.
But now there is still a spot of confusion …
As I say, my goal is to get to grips with doctypes vs Forms. And from what I have read so far,
it seemed that , the doctype and the database-table for that doctype is closely
related. I.e. when you create your own doctype, it actually creates a table for that doctype.
Right ?
But now, I did not change the doctype for “Purchase Receipt Item” and yet the database table
'tabPurchase Receipt Item` contains the added field “Stock Entry” ( See pic below)
Doctypes can be defined and modified in a few different ways. Generally speaking, your Frappe instance will store all changes you make via the customize form tool to the database rather than to the source code.
If you create a new doctype, it will also be defined by default in the database. This is indicated by the “Custom” checkbox on the doctype definitions.
If you wish to make changes directly to the source code, you need to turn on developer mode from your site settings. This is, as the name implies, intended for development work, not production deployments. If you develop new features, you can do it in your own custom app that lives along side ERPNext, or you can do it in ERPNext directly. If you edit the ERPNext source code directly, your changes will be wiped out at next update.
Unless you have activated development mode in your site_config.json file, which is off by default and can only be activated via ssh, your changes are being stored safely in your sites database. Leave development mode off and your customizations will persist across updates.
The “DocType” basically defines what goes into the Form when it is rendered when you
click (e.g.) on “Purchase Invoice” …"new’ BUT addisionally to using the info in DocType,
the info in the database is then used to make the “additions”, if any.
So in my case, the “Purchase Receipt Item” DocType is still used when I click on the “Item”
field in “Purchase Receipt” to build or “render” the form but it then adds the additional field based on what is in the data base tables as discussed further up in this thread?
I hope I have it correct like that now, because it will finally make sense.
I’d frame it a bit differently, but I’d think you’ve more or less got it.
The doctype represents your data model for any kind of entity being represented in the ERP. That entity can include a number of different fields, plus meta-data. ERPNext comes with many doctypes predefined (as JSON files) in the source code, and these predefined files can be customized. To ensure that they survive updates, customizations are not stored on the file system but rather in the site database itself. The doctype, properly speaking, is a data structure definition, which includes both default and custom fields.
You can also define your own new doctypes, by default those new doctypes will also be stored in the database to allow them to persist across version updates.