COND_A message type — COND_A IDoc for Condition Record Distribution
COND_A is the ALE message type used to distribute pricing condition records (master data, not sales or purchasing documents) between SAP systems, typically from a central pricing or ERP system out to CRM, BW, a distributed ERP instance, or an integration layer. It carries condition key fields, validity dates, and the rate or value, and can represent creation, change, or deletion of a condition record.
This page covers the COND_A IDoc message type used to replicate pricing condition records across systems via ALE or middleware. It focuses on the segment content, the partner profile and change pointer setup that must exist for the IDoc to fire, and the ordered checklist for diagnosing a condition that never arrives or arrives with the wrong value downstream.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 1,125 words
What it carries
COND_A moves pricing condition records, not transactional documents. A condition record is the row created behind a condition type in pricing customizing, keyed by the fields of a specific condition table, such as customer, material, sales organization, or a combination of those, together with a validity period and a rate or amount. COND_A is used to push newly created, changed, or deleted condition records from one system to another, most commonly from a central ERP or pricing master into a distributed sales system, a CRM landscape, a BW extraction layer, or out through an integration platform to a non-SAP pricing engine. The direction is one-way per IDoc: the system where the condition was maintained is always the sender. It is a master data message type, so successful posting means the record exists in the target, not that any specific sales document priced correctly using it.
Segments
The structure mirrors the condition record itself rather than a fixed document layout, so the exact segment set depends on which condition table generated the record.
- E1KOMG carries the communication fields that identify which condition table and key combination the record belongs to, effectively the qualifying fields of the access sequence entry.
- E1KONH carries the condition record header: condition type, validity start and end date, and the deletion indicator if the record was removed rather than changed.
- E1KONP carries the condition item detail: the rate or amount, the pricing unit, the currency or unit of measure, and scale information where the condition type uses scales.
- A deletion flag set at header level rather than the presence of a value in the item segment is what tells the receiver to remove the condition rather than update it, and this is easy to miss when reading the segment content casually.
Configuration
For COND_A to flow, a partner profile must exist in the partner profile transaction on both sides, with an outbound parameter on the sender naming COND_A and a message type or basic type combination, and an inbound entry on the receiver linked to the process code that posts condition records. A port must be defined pointing at the destination system, RFC-based for system-to-system ALE, file-based if a middleware layer picks the IDoc up. The distribution model must contain an entry for COND_A between the sender and receiver logical systems, otherwise the IDoc is never generated regardless of how the change was triggered. Distribution itself is driven by change pointers: the message type must be activated for change pointer processing, and the specific condition table and its fields must be in scope, since change pointers only fire for fields flagged as relevant to that message type. A periodic job then reads open change pointers and creates the IDocs.
What to inspect when it fails
Work from the point of failure back toward configuration rather than guessing at the target system first.
- Confirm the underlying condition record actually changed and that a change pointer was written for it, since manual mass maintenance sometimes bypasses change pointer logging entirely.
- Check the distribution model entry for COND_A between the two logical systems involved; a missing or filtered entry means no IDoc is ever created, and no error is logged anywhere.
- Check whether change pointers are activated for the message type and for the specific fields on the relevant condition table.
- Use the IDoc list and detail display to find the outbound IDoc, check its status, and open the segments to confirm the condition key, validity dates, and value actually match what was maintained.
- If the IDoc is stuck before dispatch, check the partner profile and port definition, and verify the RFC destination behind the port is working.
- If the IDoc left the sender but never posted on the receiver, check the inbound partner profile and process code assignment, and look at the transactional RFC queue on the receiving side for a queue that stopped processing.
- Reprocess through the standard IDoc reprocessing transaction only after the root segment content and configuration have been confirmed correct, not before.
Whose problem this is
Whether the correct fields and condition tables are in distribution scope, and whether the pricing outcome downstream is correct, is a functional pricing question for SD or MM. Port, RFC destination, and transactional RFC queue health are Basis. Any transformation or routing of the IDoc through an integration platform belongs to the integration or BTP team, and they should be handed the IDoc number, its status, and the segment content, not just a description of the symptom.
Common pitfalls
Several things make COND_A investigations run longer than they should.
The reflex is to resend or reprocess the IDoc immediately, or to recreate the condition record in the source to force a fresh change pointer. Both hide the actual cause when the problem is a missing distribution model entry or a condition table not in change pointer scope: the resend produces the same silent non-event, or the recreated record triggers a new IDoc that fails or is skipped for exactly the same reason as the first one, and the person troubleshooting concludes the interface is flaky rather than misconfigured.
- A successfully posted IDoc only confirms the condition record exists in the target; it says nothing about whether that record will actually be selected during pricing, which depends on access sequence order, validity overlaps, and exclusion settings on the receiver.
- The same message type looks structurally different depending on which condition table generated the record, so a segment layout seen for one pricing scenario cannot be assumed for another.
- Deletion is signaled by a flag in the header segment, not by an empty item segment, and is frequently misread as an incomplete or corrupted record.
- Mass changes to condition records through background jobs or migration tools often do not generate change pointers at all, so an apparently unchanged condition in the target may reflect a gap in the trigger, not a failure of the interface.
- Overlapping validity periods on the receiving system can leave an old and a new condition record both active, producing pricing results that look wrong even though the IDoc itself processed cleanly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-idoc/cond-aERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.