The new intercompany document type that will not behave

Why it fails. Field status is resolved separately for the header and for each line item, and the most restrictive setting wins:

• Document type field status group → header fields only (document date, reference, currency…).
• Posting key field status group → the line-item fields on the vendor/customer line, including baseline date and net due date.
• G/L account field status group → line-item fields on G/L lines.

Baseline date and net due date are line-item fields of the vendor line, so they are governed by the posting key (e.g. 31) and by the reconciliation account, not by the document type's field status group. Making them required in ZIV's field status group changes nothing.

Options, worst to best:

1. Change the posting key's field status group - hits every document type that uses posting key 31. Unacceptable.
2. Change the vendor reconciliation account's field status group - hits every vendor invoice in the chart of accounts. Unacceptable.
3. Create a validation (OB28), prerequisite BKPF-BUKRS = '1000' AND BKPF-BLART = 'ZIV', check BSEG-ZFBDT IS INITIAL / BSEG-ZTERM IS INITIAL, message as error, activated for company code 1000 at the correct call-up point. This enforces the rule for ZIV only and leaves all other processes untouched.

Prepare to explain to the auditors that a validation, not field status, is the control - and test it against parked and reversed documents.

Cause. FI document number ranges are defined per company code (and, if the interval is flagged year-dependent, per year). They are configuration objects in their own right and are not copied when a document type is copied, nor when a company code is copied. ZIV was pointed at interval 18 in company code 1000 only; company code 2000 has no such interval, so the posting is refused with 'number range … not defined'.

The same trap awaits on 1 January: a year-dependent interval must be maintained for the new year before the first posting, or the whole company code stops at midnight.

Judgement:

• Year-dependent intervals reset each year and give auditors a clean yearly sequence per document type - good for external reporting, but an annual customizing task that must be in the year-end checklist.
• Year-independent intervals never reset, so there is no maintenance risk, but the numbers run continuously across years and any gap analysis is harder.

For a low-volume intercompany document type, a year-independent interval in both company codes is the pragmatic choice: no January failure, no duplicate numbers, and gaps are still visible in the document flow. Whichever you pick, maintain the interval in every company code that will ever post ZIV, and verify with a test posting in each before go-live.

First blocker: account types. A document type carries an 'account types allowed' list. ZIV was copied from KR, which permits vendor and G/L only, so the customer line is rejected before any other check runs. Add 'Customer' to ZIV. Since the posting is also cross-company-code, the users need authorisation for both company codes, and the customer must exist in company code 2000.

Second blocker: intercompany clearing accounts. Cross-company-code postings need the intercompany clearing accounts to be maintained per chart of accounts, per company code and per posting key (OBYA). If they exist only for company code 1000, the 2000 side has nothing to offset against and the posting fails or produces an unbalanced intercompany position.

Third check: reporting consistency. With New GL document splitting, the cross-company-code document also carries the sender's profit centre and segment into company code 2000. Confirm that the ZIV posting keys and the clearing accounts are included in the splitting rules - otherwise the intercompany payable/receivable will land without a segment, the segment balance sheet will not balance, and the intercompany elimination in the group consolidation will not reconcile.