Decide which GP company databases become D365 legal entities, which become archive, and how physically isolated companies with divergent vocabularies are reconciled inside one shared application.
Organisational modelling in a GP programme looks deceptively short. The headline mapping is one line long: a company database becomes a legal entity. The work is everything that mapping does not say.
A GP estate has one system database and a set of company databases. That split is the map for discovery.
A GP estate rarely contains only live trading entities. Typical residents include a test or training company, a company created for a divested business, an acquisition that was never fully merged, and one or more reporting-only shells. Each needs a disposition.
Dimension vocabulary. If Company A's department segment uses two-digit codes and Company B's uses three-digit codes with a different meaning for overlapping values, the shared dimension set has to reconcile them.
GP inventory sites carry more meaning than their name suggests, and the meaning varies by estate. A site can be a genuine physical location, a stocking policy boundary that exists to segregate availability, or an in-transit staging construct that models goods in motion.
The GP source package supports the structural claims in this module: the system-plus-company database model, the global account framework, the site-to-warehouse mapping shape, and the in-transit risk. It does not — and cannot — establish the following, which are discovery outputs for every engagement:
One active company database to one legal entity is the planning default, not a rule. Reporting-only, dormant and test companies each need an explicit disposition. GP's physical isolation does not carry into D365. Legal entities share one application, its dimensions, its products and its integration governance.