The copied company code that will not post
After an acquisition, company code 3000 (Poland) is created by copying company code 1000 (Germany) in the reference-company-code transaction. Both use chart of accounts INT and fiscal year variant K4, both are assigned field status variant 0001, and both are now assigned posting period variant 1000. Go-live is 1 July 2024; the group currency is EUR and the new entity reports in PLN. In week one: every FI posting in 3000 fails with 'document number range 01 not defined'; once an interval is added, vendor invoices still fail because the AP team cannot open period 07/2024 for account type K in 3000 without also opening it in 1000, where audit has required the period to stay closed; and cross-company-code postings between 1000 and 3000 fail on a missing clearing account.
1. Explain why the number range failure occurred and how you would set the intervals for a brand-new company code.
Read the worked answer
Cause. Document number ranges in FI are not part of the company code definition. They live in their own table, keyed by company code, number range number and - if the interval is flagged year-dependent - year. Copying company code 1000 in the reference transaction brings over the global parameters, account assignments, fiscal year variant and so on, but not the number intervals. Company code 3000 therefore has a document type pointing at interval 01 with no interval behind it.
What to maintain. For every number range used by the document types actually needed (at minimum the G/L, customer, vendor, asset and clearing types), create intervals in 3000. Do not simply copy Germany's ranges: 3000 is a new legal entity with its own statutory sequence requirements, and starting at the German high-water mark looks like missing documents to a local auditor.
Decide the year-dependent flag deliberately. Year-dependent intervals reset each year and are clean for external reporting, but every January needs maintenance in every company code - put it on the year-end checklist. Year-independent intervals avoid the annual failure but run continuously.
Verify with a test posting per account type, and repeat the check at the fiscal year change: the failure appears on the first posting of the new year, which is usually the worst possible moment.
2. Why can the AP team not open the vendor period for 3000 independently, and what is the correct design?
Read the worked answer
Cause. Posting periods are not per company code. They are per posting period variant, and several company codes can share one variant. Sharing variant 1000 means 3000 and 1000 have literally the same open periods, per account type. Opening period 07 for vendors in 3000 opens it in 1000 as well. There is no override.
This surfaces immediately because the two entities have different closing schedules and different audit requirements - exactly the situation where a shared variant is inappropriate.
Correct design. Create a separate posting period variant for 3000, copied from 1000 so the account type configuration is identical, and assign it in the company code global parameters. Then periods can be opened and closed per entity. Remember that the variant is also used by MM and SD; check that the posting periods for the logistics account type are open for the new variant before the first goods movement, or the plant goes live with an invoice that cannot be posted.
General rule: share a posting period variant only between company codes that genuinely close on the same calendar and with the same account-type granularity. Copying a company code does not warn you about this, so add it to the go-live checklist alongside number ranges.
3. What must be checked about the currency before any posting is allowed, and what else must exist for the cross-company-code postings to work?
Read the worked answer
Currency. The company code currency was copied as EUR. For company code 3000 it must be PLN. The company code currency is set in the company code global parameters and, once the company code has postings, cannot be changed. Every document already posted in EUR would be wrong, the local statutory ledger would not tie to the local books, and the correction would be a full re-implementation. Set the currency, the country, and the currency translation rates for PLN/EUR before the first document of any kind - including test documents in the productive client.
Also confirm:
- PLN is maintained as an allowed currency for the payment methods and for the relevant bank accounts.
- The exchange rate type used for the EUR group valuation is maintained for PLN, otherwise period-end valuation produces no rate.
Cross-company-code postings. These need intercompany clearing accounts maintained per chart of accounts, per company code and per posting key. Configure them for 3000 against 1000, and confirm the document types involved allow the account types being posted. Check the resulting intercompany balances net to zero before the first consolidation, and that document splitting carries the segment on both sides.