How to handle AL0155 (object already defined) without using "Next Major Version" option in Extension Management

In Version 20, “Sales Invoice” has added the “Customer Posting Group” field. This field has been previously added by an extension in version 19 with a page extension.

Exact error:
A member of type Field with name ‘Customer Posting Group’ is already defined in Page ‘Sales Invoice’ by the extension ‘Base Application by Microsoft (20.0.37253.38454)’.ALAL0155

This was caused by the code below. (From Version 19.*)

        addafter("Pmt. Discount Date")
            field("Customer Posting Group"; Rec."Customer Posting Group")

The previous solution was to remove or change the field to a “modify” and to manually deploy the extension with “Next Major Version”. I started to modify Publish-PerTenantExtensionApps in the BC-ContainerHelper to support “Next Major Version” but that is still a work in progress.

Is there an alternative?
I haven’t been able to figure out how to use the preprocessor directives to handle this. I can’t use the directives set by the base application. Example: #if not CLEAN20.

Is there some way to reference the base app preprocessor directives? Some other easy button I overlooked?

You cannot set the preprocessor for the base app indeed.
MS can only do that.
So the only solution is to modify your extension.

Nothing that I know.
When adding existing field to page, make sure you add your prefix or suffix. This will prevent your app from failing to upgrade.

addafter(“Pmt. Discount Date”)
field(“PFX_Customer Posting Group”; Rec.“Customer Posting Group”)

Your comment did give me an Idea…

Rename the Field

I incorrectly made the assumption a single field could not exist on a page at the same time. And that field name changes on a Production deployment would be rejected due to compatibility requirements. Disclaimer: This is PTE, so I have not tested this on AppSource.

Just ran a test, and I was able to put the Customer Posting Group on the Sales Invoice form 3 times with different field names. Edits still work and all fields stay synchronized. And I was also able to simply rename those same fields and redeploy.

Simply adding the prefix on this field prior to V20 should suffice. Once the next major version rolls out, I can then remove the duplicate custom field completely.

This maintains functionality for the users during the entire process.