Number Series, Posting Groups, and Late Dimensions in a Three-Company Rollout
Cronus Design Ltd runs three companies in one Business Central environment: CRONUS (parent), CRONUS-UK and CRONUS-DE. The parent's chart of accounts and setup were migrated with one configuration package that you then applied to both subsidiaries. Two weeks later: the first sales order in CRONUS-UK is numbered SO-104882, continuing the parent's sequence; 340 imported customers have blank Customer Posting Group and VAT Bus. Posting Group values, so invoices cannot post; the REGION dimension and its 22 values, created on the parent after the package was built, do not exist in the subsidiaries; and users in both subsidiaries cannot select their own bank account. Each subsidiary must keep independent numbering, share the same dimension values, and close its year on 31 March.
1. Explain why CRONUS-UK's sales order numbers continue the parent's sequence, and describe how you give each company an independent sequence without breaking posted documents.
Read the worked answer
Cause. A package that includes the No. Series and No. Series Lines tables copies the line-level state, including Last No. Used, Open and the date fields. The subsidiary inherits a sequence already advanced to the parent's position, and because Sales & Receivables Setup points at the same code, the next order continues from there. The series definition is company-specific data, but its state travels with the package.
Fix. In the package, exclude the No. Series Line rows or clear Last No. Used on them before applying. Then, per company: create series codes with a company prefix (SO-UK-, SO-DE-), leave exactly one line Open, repoint Sales & Receivables Setup and Purchasing Setup, and set the prefix on the No. Series card so manual and default numbers stay readable.
Reasoning to state. Do not simply edit Last No. Used downward in a live company to 'catch up' - nothing prevents re-issue of a number already used on a posted document, and you lose the audit trail. Verify by posting one order and one invoice per company before handing over.
2. 340 customers imported with blank posting groups. What most likely went wrong in the package, and what is the safe correction path?
Read the worked answer
Cause. The posting group fields on a customer are foreign keys into setup tables (Customer Posting Group, Gen. Bus. Posting Group, VAT Bus. Posting Group). If those tables are absent from the package, or present but sequenced after the Customer table, the lookups cannot resolve and the values are dropped. Package validation (Check Table Relations / Validate Table Relations) surfaces exactly this; skipping validation - or clearing the check - lets the import run silently.
Correction. Build a small follow-up package with the setup tables in dependency order (posting groups, payment terms, shipment methods, then customers), validate it, apply it to a sandbox company copy first, then to production so existing customer records are updated rather than duplicated. For 340 rows, an Excel round-trip (export, fix two columns, paste-update) is legitimate and faster, but it bypasses the validation that would have caught the original defect.
Verification. Post a test invoice and a test credit memo per company. A blank VAT Bus. Posting Group usually throws a posting error, but a wrong Gen. Bus. Posting Group posts silently to the wrong account - that is the failure mode that reaches the auditors.
3. The REGION dimension was added on the parent after the package was exported. How do you deliver it, and its default dimensions, to all three companies?
Read the worked answer
Key fact. A configuration package is a static snapshot of tables and fields; it does not track later changes. Adding values on the parent pushes nothing to the subsidiaries, and dimension values are per company - there is no shared dimension table you can point them at.
Approach. Use a dedicated mini-package rather than re-exporting the original: include only Dimension and Dimension Value, apply it to CRONUS-UK and CRONUS-DE, then confirm REGION is mapped as required in General Ledger Setup (Global Dimension 1/2 shortcuts). Re-applying the original package just for this would overwrite unrelated setup that has drifted since go-live.
Default dimensions. If REGION must prefill on accounts, customers or vendors, add the Default Dimension table to the same package; otherwise users will post blanks and the analysis will show the same symptom in a month.
Close the loop. Entries posted between go-live and the package application still have no region. Decide explicitly: correct them with an adjusting journal, or document them as an accepted exception so the next dimension analysis is not misread as a configuration failure.