Similar/same custom field in different doctypes - best practice

I need want a very similar custom fields in 2 different doctypes and am wondering whether


the custom field I’ll need in both of them is an additional name field where I’ll put a translated version of the Customer/Supplier name

As for the context I am in a Chinese/English bilingual environment and will have Customers/Suppliers who’ll have a Chinese Name (in Characters) and others who’ll originally have an English name. I will add a translated version of that name either way.

what I am wondering is whether is is better in any way to pick different names for the translated name of the Customer vs the Supplier Doctype Translated Supplier Name / Translated Customer Name or whether is is fine to use the same name/label (Translated Name).

For the frontend (what users will see) it is completely fine or even better to use the same name Translated Name for both parties but I want to achieve the best practice also in regards to how this is handled in the database.

I am aware that both will probably end up in different tables of the databse anyway (and likewise be

I have two fields with the one fieldname in different tables and it works without any problems but I don’t know if it’s the best practice)

and now after your question I suppose it’s better to have different fieldname(supplier_translated_name and customer_translated_name) but the same label(Translated Name).

sounds reasonable. thx for the feedback.

For anyone who might wonder how this can be done. Here is the procedure (for creating a custom field which has a different Label (what the user sees in the form) then the actual database name of the field )whcih the system will use to internally identify the entries made)

  1. got to the “Cuistomize Form” and select a doctype
  2. add a custom field in the “Fields” Section by clicking on one of the existing fields and then choose “insert below” / “insert above” (which will create a new field?
  3. you put “Customer translated Name” (or whatever your field should) be named internally in the “Label” field. You will note that there is not field “Name” (which represents the database name of that field). This will be generated from the “Label” entered once you say “Update”. Practically it takes the text frem the “Label” and replaces the spaces with underscores (_), because the database would not allow spaces in a field name. So the Label has to be chosen wisely at this point.
  4. After the database field has been created like this you can change the “Label” to something shorter or something that makes more sense for the user to see. This will not change the database name which is a fixed unchangeable (unless u are able to hack your database which most common users won’t do) value

I have digged a bit into how the ERPNext database handles such a scenario by default.

For my example I am comparing the table for the Customer Doctype [tabCustomer] and the Supplier Doctype [tabSupplier]. Both Doctypes have identical fields by default (Name, for example)

> DESCRIBE tabCustomer;

> DESCRIBE tabSupplier;

what this shows is that the default fields of identical Lables (name, creation, modified, …) actually do have the identical field name in the database (and not specific names depending on the context (or Database table) they are used in.

So, based on that ‘research’ the statement:

seems to be FALSE. The fields can have the same database name.