So, I’ve got a huge set of transactions, customers, and addresses that I’m importing from another system. Trying to get customers imported, I’ve got the data filling in correctly, but ERPNext insists on ignoring the provided ID and filling in its own number based on the provided series. This is causing huge problems, because I’ve got to ensure that 26000 customers get synced with their correct addresses, which are linked by the now arbitrarily changed customer ID, meaning there’s no clean way to build an import flow for the docs.
How do I keep ERPNext from changing the ID on first import? Do I need to resort to importing directly into mysql?
You should leave name as it is, upload customers and try to use the link fields in the address doc type so that address is linked. You would need two upload files, one for Customers and one for Addresses.
You misunderstand the problem. The ID that needs to be preserved is not the same as the full_name, and the ID for the customer is ignored when uploaded.
@Emmett_Raymond: not sure if this problem is still actual on your end …
Just wanted to share one of the possible ideas/workarounds for issues like that. You may want to introduce a new custom field for your Customer doctype to store such an ID, and then prepare customer import data with the information for this field, too. Such Customer data import can be facilitated either via standard mechanisms (Data import tool or bench’s import-csv command) or via your custom python script uploading such data via Frappe API.
Then you build custom python scripts to do data import (via Frappe API engaged), to make sure historic transactions are correctly matched to the right Customer instances, using that ID field values. This won’t require direct mysql data manipulation (btw, it is a dangerous thing in Frappe world )
That’s how we resolved the similar problem in one of the recent projects for one of our customers.
I am reactivating this topic here as I observe the same issue. In a migration, I need to import customers with their respective customer number (from the previous ERP). So I have switched customer to be controlled by naming series. Now, I have tried with the import wizard on a file like this:
Import is successful, but all IDs are ignored and rewritten.
I have tried the same with an import script (which works fine for other doctypes that are bound to a naming series), again, the customer.name is being ignored and a new ID assigned:
def create_customer(cells):
# create record
cus = frappe.get_doc(
{
"doctype":"Customer",
"name": cells[CUSTOMER_ID].value,
"naming_series": "K-#####",
"customer_name": cells[CUSTOMER_NAME].value,
"customer_type": "Company",
"customer_group": "All Customer Groups",
"territory": "All Territories",
"description": cells[CUSTOMER_DESCRIPTION].value,
"tax_id": cells[CUSTOMER_TAX_ID].value,
})
try:
new_customer = cus.insert()
except Exception as e:
print(_("Insert customer failed"), _("Insert failed for customer {0}: {1}").format(
cells[CUSTOMER_ID].value, e))
Is this a bug affecting customer (and I guess supplier) because of their dualism with/without naming series? Is there a better way to assign the customer IDs rather than by changing it in the database? Using ERPNext/Frappe v10.1
It’s an old thread, but people might still find it searching for a solution.
You can find a solution here (from June 2025):
if use standard data import, simply fill the the number into ID field, the ID field has highest priority which will prevent autoname by naming series.
if create sales order via api, you can create before_insert server script with code like below
doc.name = f"{number}"
doc.flags.name_set = True
In other words: Using the Script API, create your document with the usual construct, including the legacy number as name (e.g. “ID”), and then use this specific flag to signal that you want to use the already set name as is.
my_new_doc = frappe.get_doc({
"doctype": "ToDo",
"description": "Setting my own name",
"name": "11321-3XL-RS"
})
my_new_doc.flags.name_set = True
my_new_doc.insert()
To confirm it works, simply check the ToDo list to verify that the name indeed got through as expected.