[Alexander Yakunin (Alexander-Ya)]

What & why

Alternative to #13232, copied from its head 035b0e73eb28d118a073023750393707b88c0746 and squashed into one commit. The original PR and branch remain unchanged.

Retain the Intercompany extraction, but consolidate the four new localization apps into the shared Intercompany app. Application continues to depend on one Intercompany app, allowing localized public symbols to be exposed through its existing propagated dependencies.

Benefits compared with separate country apps

Benefit	Audience	Improvement
One public app identity	All consumers	The same Intercompany name, app ID, and version are used across countries; localization changes compiled content rather than introducing additional app identities.
Simpler first-party dependencies	Microsoft first-party apps	Apps can reference one Intercompany app without separate localization-app dependencies. Application's dependency propagation also exposes the symbols available in the country's build.
Compatibility for existing consumers	First-party and partner apps	Existing consumers depending on Application retain access to extracted symbols through its propagated Intercompany dependency, subject to API compatibility validation.
Simpler cross-country manifests	Partner apps	Partners choosing a direct Intercompany dependency use the same app ID across localizations, reducing country-specific dependency manifests and distribution variants.
Simpler deployment and servicing	Operations and all consumers	Each country image contains its matching Intercompany package, not W1 plus a localization app. There is no separate localization-app installation order or core/localization version pairing to manage.
Centralized maintenance	Intercompany maintainers	Common and localized code live in one project, making related changes easier to implement and review together.
Compile-time localization isolation	Maintainers and app developers	Country-only code and references are excluded from other builds, avoiding dependencies on localized BaseApp objects that are unavailable there.
Reusable, explicit build configuration	Build infrastructure and future extracted modules	Metadata maps countries to feature flags consistently across internal and AL-Go builds, while CLEAN controls remain independent.

Trade-off: this produces country-specific binaries, not a universal package, and each localization still requires validation. Country-only APIs remain available only in the relevant builds. Localizations share the main app's release lifecycle instead of being independently deployable.

Country compilation design

build/projects.json owns a new countryPreprocessorSymbols mapping on each applicable application. A shared resolver validates country keys and uppercase feature-qualified symbols, then resolves the symbols for an application or workspace.

Build countries	Symbol	Integration
AU, NZ	INTERCOMPANY_APAC	GST settlement, journal posting, and withholding-tax events
CA, MX, US	INTERCOMPANY_NA	Payment journals, deposits, customer lists, and register descriptions
IT	INTERCOMPANY_IT	Sales payment posting
NO	INTERCOMPANY_NO	Norwegian journal controls
Other countries	None	Common Intercompany functionality

• Move all 20 localized AL files into Intercompany/app/src/Localization, preserving their object IDs, names, and complete bodies. Each file is enclosed by its corresponding compilation guard, including the localization permission objects.
• Remove the four separate localization app manifests and their build/group registrations.
• Resolve country symbols for internal compilation independently of CLEAN symbols.
• Generate AL-Go workspace symbols together with country app/test folders. Preserve unrelated existing flags and validate symbol-only settings drift.
• Preserve localization and other non-cleanup symbols when generating the Default baseline for a Clean build.
• Extend source directive validation with the exact symbols declared in project metadata, rather than allowing arbitrary feature-prefix spellings.

This is one source project and app identity with country-specific compiled packages, not one universal binary.

Linked work

#13232 - original Intercompany extraction PR, left unchanged.

No separate GitHub issue or ADO work item was supplied for this alternative design.

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

• Invoke-Pester -Path .\build\scripts\tests\CountryPreprocessorSymbols.Test.ps1,.\build\scripts\tests\CountryProjectSettings.Test.ps1,.\build\scripts\tests\TestPreprocessorSymbols.Test.ps1 -PassThru -Output Minimal: passed, 40 tests.
• .\build\scripts\Update-CountryProjectSettings.ps1 -Validate: passed for all 23 country projects.
• git diff --cached --check features/Extract-Intercompany-module-into-app: passed for the new consolidation delta.
• git diff --cached --check: reports five inherited trailing-whitespace findings, confirmed to exist in the original extraction: one in src/Layers/GB/BaseApp/Purchases/Posting/PurchPost.Codeunit.al and four in src/Layers/W1/BaseApp/.github/skills/al-extraction/SKILL.md. These unrelated lines were left unchanged.
• Source checks: all 20 localized file bodies match the original PR exactly after removing their new outer guards; all new directives pass the repository validator; consolidated object-type/ID pairs have no collisions; changed PowerShell files parse successfully.
• Reviewed the new consolidation/build-infrastructure delta. The existing extraction was copied, not fully re-audited.
• AL compilation, analyzer execution, publishing, and Business Central/container tests were not run locally. The container-backed setup described in LOCAL_DEV_ENV.md is left to the user's validation workflow.

Pending: Default and Clean country builds, aggregate Application API compatibility checks, and localized Intercompany runtime scenarios.

Risk & compatibility

The original extraction's schema ownership moves remain unchanged. The consolidation preserves localized AL behavior and existing object identities but compiles the localized objects into Intercompany instead of the four newly introduced apps.

This assumes the separate localization apps from #13232 have not shipped. No uninstall/upgrade path from deployed versions of those experimental app identities is introduced.

Country compilation symbols must remain stable for each localization. CLEAN and CLEANSCHEMA symbols remain independent version-cleanup controls; removing them for baseline comparison must not remove country symbols.

[github-actions]

Could not find a linked work item. Please link one in either of these ways: (1) link an ADO work item using the pattern 'AB#' followed by the work item number - you may use the 'Fixes' keyword to automatically resolve it when the pull request is merged, e.g. 'Fixes AB#1234'; or (2) link a GitHub issue of type 'Task' using the pattern 'Fixes #' followed by the issue number, e.g. 'Fixes #1234'.