web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Small and medium business | Business Central, N... / Business Central Upgra...
Small and medium business | Business Central, N...
Answered

Business Central Upgrade – PTE Field Conflict

(3) ShareShare
ReportReport
Posted on by CU06091550-0 16

Hi,

I am working on an extension where we have a custom field in Purch. Rcpt. Line Table Extension:

field(67; "Vendor Shipment No."; Code[35])

In the newer BC version, Microsoft has introduced the same field with a different ID:

field(5797; "Vendor Shipment No."; Code[35])

Because both fields have the same name, I am getting AL0887 during the upgrade.

AL0887: A member of type Field named 'Vendor Shipment No.' conflicts with a similarly named member 'Vendor Shipment No.' of Table Purch. Rcpt. Line. Both will have the same database name 'Table'.

The main concern is that Field 67 already contains production data, and this value is also flowing to the other documents.

I checked Microsoft's documentation for PTE merge conflicts, and their suggested approach is to backup the data, uninstall the extension with "Delete extension data and schema", remove the conflicting field, and then restore the data:

Microsoft – Upgrading per-tenant extensions that conflict with other extensions

However, I have 5–6 companies in the environment, and the PTE has around 55 custom tables and 43 table extensions with a lot of data. Because of this, the deletion and backup/restore approach seems quite complicated and risky, and I would prefer not to use the deletion approach if there is another supported option.

So I wanted to ask:

  1. Is there any other supported way to resolve this conflict and migrate Field 67 + its existing data to Microsoft's Field 5797 without deleting the extension data/schema?
  2. Is there a recommended approach for handling this when there are multiple companies and a large amount of PTE data?
  3. If the deletion approach is the only supported option, is there a safer/easier way to handle the backup and restoration for all companies and tables?

I will test the solution in a production-copy sandbox first.

If anyone has dealt with a similar issue, please share your experience or any suggestions. It would be really helpful.

Thanks,

Ankit

 

Categories:
Dynamics 365 Business Central
  • Suggested answer
    YUN ZHU Profile Picture
    YUN ZHU 103,644 Super User 2026 Season 2 on at

    This highlights the importance of using a prefix or suffix.

    More details: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/compliance/apptest-prefix-suffix?wt.mc_id=DX-MVP-5004336

    In your case, you can first export your original data using Configuration Packages, update the field names, install the extension using Force mode in Schema Sync Mode, and then re-import the data via Configuration Packages.

    Hope this helps.

    Thanks.

    ZHU

  • Suggested answer
    OussamaSabbouh Profile Picture
    OussamaSabbouh 20,124 Super User 2026 Season 2 on at

    Hello Ankit,

    Unfortunately, for a PTE → Microsoft Base Application field conflict, Microsoft’s documented supported resolution is still to remove the PTE schema that owns the conflicting field; you cannot simply rename/remove field 67 and preserve it through normal synchronization, and the newer MovedTo/MovedFrom field-migration mechanism does not help because Microsoft explicitly states that moving tables/fields between extensions is not supported for PTEs (and in any case a move requires the same field name/ID, while yours is 67 → 5797). So I would follow Microsoft’s procedure in a production-copy sandbox: export all data owned by that PTE because Delete extension data removes all 55 custom tables and all table-extension fields, uninstall with data/schema deletion, deploy the conflict-free PTE, upgrade BC, then restore the PTE data and map the backed-up Purch. Rcpt. Line field 67 value into Microsoft’s new field 5797 using the record key/SystemId as appropriate. With 5–6 companies I would automate the backup/restore rather than do it manually—Configuration Packages/RapidStart are Microsoft’s documented option, or a controlled custom export/import utility to external storage—and reconcile record counts/totals before and after. Also update future custom field names with your company prefix/suffix to reduce recurrence. 

    Regards,
    Oussama Sabbouh

  • Suggested answer
    Tony NAVCore Development Profile Picture
    Tony NAVCore Develo... 59 on at

    There's an easy, safe way to handle this.  Lucky for you Microsoft didn't use the same Field No. as your custom field.  That's the more critical piece and should've been in a custom range.  Field names aren't as critical and easy is to fix, provided you have access to the PTE codes of course.  All you need to do is rename your custom field but be sure to use the Rename function in VSC to do this. VSC will then apply this same change to all references to the same field in your code.  If you have other extensions that reference your custom extension, then there may be more work to do.

     

    After renaming your field, you can deploy it as PTE using the force sync option.  This will fix the name conflict while preserving your data.  I would imagine your PTE is doing more than just adding the field, and you might have other functions referencing this field for other operations.  This will allow you time to fix those references, so it can point to the same new field, assuming Microsoft's new field is an exact replacement for your custom field.  After installing Microsoft's update, use the config package to export this table to Excel, copy your custom field's content to the new field, and reimport.

     

    I suggest continuing to use your PTE for a while, to ensure it is capturing data exactly like what you're doing in your custom field.  If all is good, that's when you update your extension to reference Microsoft's field and, eventually, drop your custom field.

  • CU06091550-0 Profile Picture
    CU06091550-0 16 on at

    Hi Everyone,

    Thanks for your valuable responses and suggestions. I will keep in mind the suffix and prefix for the field names and put a prefix on every field in future.

    @Tony NAVCore Develo... , @OussamaSabbouh  thanks for the detailed information and suggestion for providing valuable information and also a process to follow. 

    However, could you also guide me if I restore the data back to the Microsoft-created field, will the upgrade Codeunit work, or will the Configuration Package do the work?

    Thanks @YUN ZHU  for your quick responses, as everyone has advised the same. I will apply the ForceSync approach after the fix and will try to re-import the data.

    If it does not work, then I will go for the backup and delete extension and restore approach only. However, it seems this may not work because the posted transactions already have data, which will not be restored by RapidStart/Configuration Package.

    Any idea how to handle the posted data, as this field is in the Purch. Rcpt. Line table, which comes under the posted category?

    Thanks,

    Ankit

  • Verified answer
    Tony NAVCore Development Profile Picture
    Tony NAVCore Develo... 59 on at

    Here are the steps, assuming you don't have any other extension that's dependent on your extension:

    1. Use the rename function in VSC to rename your field.
    2. Deploy your extension using the force sync option.
    3. Check if everything still works as usual, and check if data is still there. It should be.
    4. Upgrade BC, the name conflict should be resolved.
    5. Continue using your old field for a few weeks, and ensure data in Microsoft's new field matches your custom field.
    6. Update your extension and change all references fom your old field to the new field.  Don't remove the old field yet, and don't change the old field's operation either.
    7. Deploy your changes.
    8. Use the config package to copy data from your old field to the new field.
    9. Ensure everything works correctly and that the copied data is there.
    10. Continue for another few weeks until you're comfortable.
    11. Now remove your old field and its operations.
    12. Deploy your changes, but no need to copy or move data since you already did that in step 8.

    For a sandbox environment, you can skip the wait.  Just do a thorough test.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Winners!

Congratulations to our community stars!

Women in Power Builds Momentum

Expanding mentorship, skilling, and AI innovation

Congratulations to the August Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 750 Super User 2026 Season 2

#2
YUN ZHU Profile Picture

YUN ZHU 534 Super User 2026 Season 2

#3
AndrewThomas81 Profile Picture

AndrewThomas81 287 Super User 2026 Season 2

Last 30 days Overall leaderboard

Featured topics

Microsoft Training Manuals

Product updates

Dynamics 365 release plans