Customer V3 entity and Addresses

(4) Share

Report

Posted on by renMike

Hello,

I am struggling with the migration and subsequent maintenance of postal addresses into a FO instance. I am using the Customer V3 entity to supply values when creating a new customer and I can supply it with just an Invoice address or an Invoice address and a Delivery address. The record is generally successful in it's creation. At a later time I may need to update that customer record to supply a new value for a non-address field e.g. credit limit or for an address field e.g. correction to a street name. If there is no change to the address values then the update is successful, but if there is an update to any of the address values then the process fails. The failure is generally reporting something similar to "Insert not supported with the values specified for 'Effective' and 'Expiration'. New record overlaps with multiple existing records.". I'm not intending to insert as I want to update. The maintenance window is only for a few weeks until the system is handed over to the end users as they will maintain the addresses manually from that point onwards.

I'm aware of the GAB and the use of Location Id values but this has proven tricky to use as my migration process needs to know what the Location Id value is in order to test if there is a changed value and I'm struggling to keep track of them. If I had a better way of identifying the address and its location id value to determine if it has changed then I would prefer to use the GAB. But since I don't i'm seeking advice or links to resources to help me maintain customers and addresses once they've been migrated.

Has anyone any advice on how to migrate and then maintain addresses into FO?

Regards,

Mike

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (15)

Answers (1)

Sort by

Suggested answer

Navneeth Nagrajan 2,618 Super User 2026 Season 1 on at

Like (2)

Report
Copy link

Link copied!

Hi Mike,

To answer the first part of the question, the issue insert not supported with the values specified for 'Effective' and Expiration usually arises because of the LocationId reference is generated and the ValidFrom and ValidTo dates are populated too, so if you are updating an existing address then you need to fetch the LocationId alongwith the EffectiveFrom and EffectiveTo fields. For this purpose, you can leverage the data entity Party Postal Address V2 (DirPartyLocationPostalAddressV2Entity) to update the address. Addresses cannot be updated using CustCustomerV3Entity.

The suggestion is to export the data entity with the location id values, update the addresses and later migrate the updated addresses.

Alternatively, you can use Customer postal addresses (CustomerPostalAddressEntity) that has the Customer account number, AddressLocationId along with the Effective and Expiration fields in there.

Hope this helps. Happy to answer questions, if any.

Was this reply helpful? Yes No
renMike 65 on at

Like (2)

Report
Copy link

Link copied!

Hi Navneeth,

I understand what you are suggesting and it was an avenue I was investigating but I ran into issues in identifying the correct location id, and therefore address, for each customer. I had been attempting to find the location id by exporting the entity as you suggest and then comparing the address values (Street, City, Zipcode, etc.) but because I wanted to update the address at that location there are always differences in these values.

Do you have any suggestions on how to identify the correct location id for a customer to permit an update?

Thanks

Mike

Was this reply helpful? Yes No
Suggested answer

Alireza Eshaghzadeh 15,159 Super User 2026 Season 1 on at

Like (2)

Report
Copy link

Link copied!

Hi,
You can try exporting addresses using "Part postal address V2" to retrieve address details and Location IDs.

By using the PARTYNUMBER, you can identify the actual customers. If needed, you can also update customer addresses using the same "Part postal address V2" entity.

Was this reply helpful? Yes No
renMike 65 on at

Like (1)

Report
Copy link

Link copied!

Hi Alireza,

This is the route I am currently investigating. My problem is that although I can export the Party Postal Address V2 entity I can't be certain that I am matching the correct Location Id records to the data I have to update. I almost need to record the Location Id after I initially migrate it so that I can lookup that in the future should there be changes.

Regards,

Mike

Was this reply helpful? Yes No
renMike 65 on at

Like (2)

Report
Copy link

Link copied!

Here's another thought I had...

When I insert a new Customer record can I provide the Location Id I want it to use rather than allow it to allocate a new one? If I can provide one and D365 will use it then I can encode the details I do know into it so that I can recreate that Location Id for subsequent updates.

Does this sound like a viable solution?
Has anyone employed this method before?

Mike

Was this reply helpful? Yes No
Suggested answer

Alireza Eshaghzadeh 15,159 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi Mike,

A single customer can have zero to many addresses, and each address is identified by a unique Location ID.
Using the “Party Postal Address V2” data entity, you can retrieve both the Location ID and the PartyNumber, which you can match with customers to identify their corresponding addresses.
Additionally, you can use the “Customers V3” entity to export the PartyNumber along with the Customer Account ID, allowing you to accurately map addresses to specific customers.
Then you can location id for specific customers. What is your requirement and expectation here?

Was this reply helpful? Yes No
renMike 65 on at

Like (1)

Report
Copy link

Link copied!

Thanks for confirming the expected behaviour Alireza,

In my case I might migrate two delivery addresses against a Customer e.g. Unit 1, Test Street, Test City, Zip Code and Unit 2, Test Street, Test City, Zip Code. Based on these example addresses we can assume that they are next to each other on the same street, in the same city and have the same zip code. Before the FO system goes live the source data is changed and example address 2 becomes Unit 2, Test Street, Different City, Different Zip Code.

I would like to be able to update the example address 2 so that the legal entity is kept in line with the source data.

I appreciate that I can export the Customer and Party Postal Address entities, but how do I know that example address 2 has been updated rather than a new, third, address has been provided? I can't do a comparison of the fields to identify the location Id to update because I'm expecting at least one field to have changed. I also don't want to update both delivery addresses, This is why I was asking if it is possible to provide a Location Id when I first create the address so that I know what to look for later on when I wish to update the address.

Regards,

Mike

Was this reply helpful? Yes No
Suggested answer

Alireza Eshaghzadeh 15,159 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi,

If your goal is to update a specific delivery address (e.g., "Address 2") for a customer based on changes in the source system, and avoid unintentionally creating a new address, the key is to track and reference the correct Location ID tied to the customer.
Since the “Party Postal Address V2” entity is global (shared across legal entities) and the Customer entity is legal entity–specific (unless shared), you can:
-Export “Party Postal Address V2” entity and create a filtered version of the for the relevant customers in the specific legal entity using the PartyNumber as a reference.
-Use additional fields like Address Purpose/Role and Description to help identify “Address 2” if the main address fields (e.g., street, zip code, city) are expected to change.
-When address values change in the source system, you can match and update based on the known Location ID of "Address 2", if that ID was stored or tracked during migration.

If you're unsure about the historical address or need to confirm that a change occurred, I recommend exporting data from the “Party postal address history” entity. This gives you visibility into past address values and can help with matching or restoring previous data, especially useful for validation or rollback scenarios.
If possible, during initial address creation (e.g., migration or master data import), you could store the Location ID externally (in the source system or a mapping table) to make future updates easier and more reliable, exactly as you suggested.

Was this reply helpful? Yes No
renMike 65 on at

Like (1)

Report
Copy link

Link copied!

Hello,

I like your thought about 'hijacking' unused fields to hold some "key" to help identify the source data once the address has been migrated into D365. This is similar to what I was suggesting about on the 25th July when I asked "When I insert a new Customer record can I provide the Location Id I want it to use...". I've had issues 'hijacking' fields in other systems before as when the team decide that they then wish to use those fields for their intended purpose it causes problems, but this is just for a short (1-2 months) timeframe after which the data can be cleansed if necessary.

Do you think that 'hijacking' fields is a better approach than providing the Location Id when first creating the address?

Mike

Was this reply helpful? Yes No
Verified answer

Alireza Eshaghzadeh 15,159 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi,
In my approach, I typically use the address description to store the part name — such as the customer name — which makes it easier to identify and match the address back to the customer’s party number.
Additionally, using the Purpose and Primary fields provides better control over the addresses. For example, setting addresses as Invoice or Business types based on your requirements can serve as an extra key for filtering or identifying specific addresses.
A few years ago, I faced a similar challenge where we needed to update active addresses with the correct city and district values. In that case, I followed the same method — leveraging the “Party Postal Address V2” entity to perform a bulk update across multiple customer records.
So yes, while ‘hijacking’ fields for short-term tracking can work, using standard fields like Description, Purpose, and Primary offers a cleaner and more sustainable approach that aligns with the system’s data model and avoids potential conflicts later on.

Was this reply helpful? Yes No