By Ashish Sampat
Make Trading Partner Mandatory with SAP FI Validation
To require a Trading Partner for selected SAP FI postings, define an FI validation that checks whether VBUND is populated. In classic SAP systems, maintain the rule in GGB0 and activate it for the relevant company code and callup point in OB28.
Making the field available for entry is only part of the solution. The rule must identify the transactions that need a partner, run when the relevant data is available, and issue an error if the required value is missing.
This guide explains field-status limitations, document-type settings, and a worked validation example. Start with Part I: SAP Trading Partner Configuration and Master Data to review company assignments and partner derivation.
System scope: The transaction-code example below describes classic FI validation in SAP ECC and SAP S/4HANA environments that support this configuration. SAP S/4HANA Cloud Public Edition uses the configuration and extensibility options available for its release; do not assume that the same SAP GUI transactions apply.
1. Understand Field Status Limitations
A field status group normally controls whether posting fields are required, optional, or suppressed. Trading Partner is not a standard field-status-group switch that can simply be changed to required in the usual setup.
- OBC4 – Define Field Status Variants: Maintain field status groups assigned through G/L account company-code data.
- OB41 – Define Posting Keys: Review field status at posting-key level.
The original example references SAP Note 1397715, FI – Adding VBUND to the coding block. Check the current note, prerequisites, and applicability for your release before considering a coding-block change. A technical change should not replace a clear decision about which business postings need a partner.
2. Review Document-Type Settings in OBA7
Review the document types used by each posting process in OBA7. Relevant indicators in table T003 include:
- XMGES: Trading Partner entry / partner company can be input.
- XGSUB: Cross-company postings.
The combination of these settings and the posting transaction affects Trading Partner entry and derivation. Enabling entry does not make the value mandatory. Test the required document types and posting routes before changing shared configuration.
If a partner is derived from customer, supplier, or G/L master data, verify the resulting line items. Do not force manual entry in a process where the field is derived or unavailable for editing.
3. Define the FI Validation in GGB0
An FI validation has three components: prerequisite, check, and message. The prerequisite selects the postings in scope; the check tests the required condition; and the message explains a failed check.
Use GGB0 to maintain the validation. For this line-item check, review Financial Accounting callup point 0002 – Document line item. Confirm that VBUND has been derived by the time the check runs for each posting process.
Create the required sets in GS01 and maintain them in GS02. The illustrated example uses:
- ZGL_TRAD_PART_REQD: G/L accounts requiring a partner (Figure 2).
- ZUSR_TRAD_PART_REQD: Users included in this example (Figure 3).
- ZDOC_TYPE_TRAD_PART_REQD: Document types in scope (Figure 4).
Prerequisite
BSEG-HKONT IN ZGL_TRAD_PART_REQD AND
BKPF-USNAM IN ZUSR_TRAD_PART_REQD AND
BKPF-BLART IN ZDOC_TYPE_TRAD_PART_REQDAll three conditions must be true. A posting by a user outside the user set does not enter this check, even if the account and document type match. A user restriction may help with a controlled rollout, but review whether it belongs in the final control. Include technical users where appropriate, or remove the user condition if the business rule must apply regardless of who posts.
Check
BSEG-VBUND <> ''The intended check is Trading Partner is not initial. Build and verify the expression using the validation editor's field and constant selection. Treat the text above as the illustrated Boolean rule, rather than ABAP code to paste into a program.
Error Message
The example uses error Z1 032: Trading Partner is required for GL. This is a customer-defined message example, not a delivered SAP message that every system contains. Maintain an appropriate error message in your own system so the user can identify and correct the missing value.
A nonblank check detects a missing value; it does not prove that the selected company is the correct counterparty. Master-data review and partner-based reconciliation remain necessary.
4. Activate in OB28 and Test the Posting Routes
In OB28, assign and activate the validation for the relevant company code and callup point. Check the activation level and any exclusions, especially where batch input or background processing is used. Defining the rule in GGB0 alone does not establish an active control.
Use these test cases before transporting the change into production:
| Test case | Expected result |
|---|---|
| In-scope account, user, and document type; partner blank | The validation issues the configured error. |
| Same conditions; correct partner populated | This validation passes; other posting checks still apply. |
| Account, user, or document type outside the prerequisite | This validation step does not apply. Confirm that the exclusion is intentional. |
| Interface, background job, or integrated posting | The intended control runs with the actual technical user and data available at that point. |
| Parked document and SAP Fiori verification workflow | Check behavior at parking, simulation, submission, and final posting as applicable. |
Troubleshoot Missing or Unexpected Validation Errors
- No error for a blank partner: Check OB28 activation, company code, callup point, set contents, actual posting user, and document type.
- Error despite a populated partner: Inspect the line item and the value available when the validation executes. A value visible later in the process does not by itself prove it was available at the check.
- Field unavailable for correction: Review derivation and document-type behavior for the posting transaction.
- Different behavior in a Fiori workflow: Test each relevant action rather than assuming that simulation, submission, and posting execute identical checks.
SAP documents relevant scenarios in KBA 3465162: Trading Partner validation not working as expected and KBA 3519376: Validation behavior in Verify General Journal Entries. The previews describe the symptoms; access to the full solutions may require an SAP sign-in.
Next step: Review Trading Partner company configuration and master data in Part I, then document the postings, users, interfaces, and exceptions your required-entry rule must cover.
Need Help with SAP Intercompany Posting Controls?
ERPCorp consulting can help review Trading Partner derivation, FI validation design, interface coverage, and intercompany reconciliation in your SAP environment.
Glossary
Trading Partner
The company identifier for the counterparty in an intercompany transaction. Field VBUND supports reconciliation, reporting, and consolidation by partner.
FI Validation
A posting rule comprising a prerequisite, check, and message. It can reject an in-scope posting when a required condition is not met.
Document Type
A classification of accounting documents that controls document-level attributes. Trading Partner entry and derivation depend partly on the document-type configuration.
Field Status Group
A group of settings controlling whether posting fields are required, optional, or suppressed. Trading Partner is not a standard required-entry switch in the usual field status setup.
Callup Point
The point in processing at which a validation executes. In classic FI, callup point 0002 checks document line items.
Set
A named collection of values or ranges, such as G/L accounts, used to maintain the scope of a validation condition.
Company Code
An organizational unit in Financial Accounting for which a complete set of accounts and financial statements can be produced.
Financial Consolidation
The process of combining group-company financial information and eliminating intercompany transactions and balances.