Since v12 the Addresses have been their own function and are only linked to the customers and suppliers. Yes, the old records still have a “primary” address as part of their makeup, but I would bet they disappear in the near future. In v13, the I do not believe the primary address (the one still in the customer and supplier record) is called for any documents. Almost everything uses the linked addresses in the Address tables.
Since that is the direction things seem to be headed, I just make sure the Address tables are in place.
To be honest, Addresses have had their own import/export template since about v10.
Yip, I’ve experienced the same segregation with Customer/Supplier and separate Address records in v12.
Although Supplier/Customer can have their primary Address as part of the record I’ve opted not to do so and rather link it to Address records.
The same goes for the primary phone numbers and email address. Conventionally you’d assign these to a Contact at the Supplier/Customer but sometimes the business has a switchboard and something such as email@example.com which is not ordinarily related to a Contact.
In both these cases I first import the Supplier/Customer and then use the name (aka Supplier Name or Full Name) and not the ID to link the Address(es) etc. This saves me from exporting the records again just to link on the ID.
Also note that the Supplier and Customer are not consistent in which fields they carry, eg Supplier has Website but no Email or Phone, whereas Customer has Website, Mobile No and Email ID.
Yes, and No… The address I am referring to would be the one typed in during the creation of a supplier or customer. This address labeled as “Primary” actually gets dropped into the customer record or the supplier record under the heading Primary Address. I have never seen it used anywhere and it can be absolute nonsense in the record without affecting the operation of the system.
The Billing, Ship To, and other addresses are the ones that make up the address functions in the system (as far as I can tell).
The only way I can explain this is to tell you to use the import/export tool to dump a template (with data) for Supplier or Customer, and then do the same thing for Addresses.
You sill see that the important addresses that the system uses are actually in the Address tables separate for the customer or supplier records. If you look at the file dumped from the supplier or the customer you will also see an address column the really has no function that I can find. It appears to be a carry over from the older versions.
So, when “editing” an address for a contact, a customer, or a supplier, be sure to select billing, ship to, or other category so the address is properly linked in the rest of the system. It appears that “Primary” address is a fall back position that may only be used if no linked addresses can be found.
This is of course my speculation based on my experience in working with this mess since v12, but this appears to be what is going on.
There was once a request to force any address to be saved ONLY once a category was selected. This would negate the need for the old primary address to appear in the customer or supplier records. You can never tell when that will eventually be implemented. All of the framework is already in place to do away with it, but we continue to move ahead with theis sort of half step of redundant addresses in multiple places.
However there are many fingers that typed the code for how to handle identifying information related to suppliers and customers. It appears that there may have also been competing strategies for how to handle the information. We can leave it at that
In an Open Source project, once something is working (even if redundant) there is little resources or desire to go back and clean it up. I understand how we got here, even if I find it absurd. I am just happy that everything mostly works.
So the extra address locations in the supplier and customer records appear to be harmless at this point even if they are confusing.
To my mind it is completely irrational to have separate tables for Customers, Suppliers, Users, Employees, Contacts, etc.
They are all Persons!!!
Some are Corporate Persons. Some are Individual Persons. That can be distinguished with a single flag.
If you have a User who is an Employee who buys your products, you need three separate records. It is perfectly possible that that Employee would resign and set up shop as a Supplier too. That should be created as a separate entity. It too can then be both Customer and Supplier, while the same Person now has to be entered a fifth time as a Contact in that new entity.
The way it is done is just so wrong, seeing it brought me very close to passing over ERPNext for something else.
Believe me @MartinHBramwell I am laughing with you and not laughing at you. When faced with the strange ways ERPNext is held together with bailing wire and duct tape, you have to laugh to yourself that it all still works, and for the time being, we are all still using it BECAUSE it works. The irony is the funny part. Mainly because in no sane world of commercial software would we be this tolerant of these issues.
I would almost agree - not all of them are Persons.
At this point I like the Business Partner Concept from SAP:
Business Partner Categories
Business Partners are created in Categories. Categories determine the fields available for general data entry. There are 3 different categories of Business Partners:
SAP Business Partner Roles
The Business Partner Serves as a database of every person, group, or organization that is involved in a business. SAP Business Partners can serve different functions within a company. These are referred to as Roles. For example, if a partner is a Customer and a Vendor, both these roles can be supported by this Object. This prevents the system from having to store redundant data for multiple objects.
Some example roles are:
All Business Partners must be created in the General Role. General data includes address information, technical and other forms of identification, tax, and general payment information.
… Implementing this concept would be a big change affecting almost everything in ERPNext. But let’s see, maybe it’s worth a try to start a discussion on this.
Maybe add Industry Type, Brand, Contact and Address to the list also?
Industry Type and Brand are lookup values, so we need to import them before we reference them in a subsequent import.
Contact and Address I normally import after Supplier and Customer so that I can link them immediately on the supplier or customer name in the import data.
Also note that hierarchical tree structures such as Item Group and Chart Of Accounts might need multiple imports. Starting with an import for the top level and subsequent imports for each lower level. You might have to export a previous import to get the correct parent name.
Let’s assume you sell computer hardware components and computer software. Then it might be convenient for you to set up a stock item hierarchy so that you can report on hardware vs software sales. Within hardware you’d like to have yet another level of differentiation, namely CPU and RAM. All your different CPU stock items will then be listed under CPU and likewise for RAM.
Setting up this simple item group hierarchy is best achieved directly in the WUI. In the Awesome Bar, type Item Gr… and then select Item Group Tree.
You’ll see a default hierarchy, dependent on which modules you activated when you installed your instance of ERPNext. Now you can add your hierarchy directly to the top level All Item Groups.
However for more complex and/or automated configurations we can achieve this via the data-import tool:
Settings > Import Data > New >
then type in Item Group and select Insert New Records and Save
Download an import template
Now this tool requires all higher level members to exist prior to a lower level member referring to them in the Parent Item Group column. Hence we have to break the import into 2 phases:
First import only the Hardware and Software levels. Making sure to specify that Hardware is also a group by setting Is Group to 1.
Then run another import, but this time import only the CPU and RAM levels, making sure they refer to Hardware in the Parent Item Group column and setting their Is Group values to 0.
In general, I find it insightful to make a small amendment via the WUI. I then Download the import template again, making sure I select to export some sample data containing my manual amendments. This affords me to find out which columns are required and which values are acceptable etc.
This answer turned out more verbose than what I anticipated, however I trust it’ll serve you well