Last month a plant buyer messaged me after a “governance done” mail: the new vendor was approved, the change request sat at Final Check Approved, and purchasing still could not find the number for a PO. I opened the hub. The business partner was active and staging was empty, so MDG had finished. What had not finished was a usable landing in the system the plant opens. We found it once we walked active data, replicate step, replication model and filter, outbound message, then key mapping — instead of starting in SOAMANAGER. The filter still held the old company code from a sample landscape. Headquarters could see the vendor. The plant could not.
What I check, and why each step matters
I start with the change request and the active object. Status has to be the final activated value for that type. Then I open the active area — the live master after staging is written — and I check the field the business cared about. If a derivation looked green in the UI but the active company-code or plant view still holds yesterday’s value, replication will send yesterday’s value. When active is wrong, I fix the derivation or the activation mapping and reopen a change request before chasing DRF.
Next I ask whether a replicate step actually ran. On a rule-based change-request type, activation and replication usually sit as system steps on the non-user agent group table (DT_NON_USER_AGT_GRP_) after the last approval. The workflow log shows whether the process stopped at activate or continued into replicate. If the condition alias never landed on a replicate pattern, DRF has nothing to do even when the model looks perfect. I correct that path and retest with a fresh request before touching filters.
Only then do I open the replication model: target system, outbound implementation, and the filter that decides who receives the object. A missing plant, sales org, or account group looks exactly like “replication never happened.” Partial landings are worse — general data arrives, plant views stay behind — and the buyer still cannot use the record. If the object is outside the filter, I correct the criteria and run again; if it is inside and still silent, I move to the message.
Then I look for the outbound message that should have left after this change request — the IDoc, the XML, or the service the model uses. No message means the model did not select the object or the run never started. An error means the hub tried and failed. Hub success with an empty target means I move to key mapping. Hub key and target key are not always the same string: mapping that still points at an old number after a target refresh, or a target that creates a new number while MDG thinks it updated an existing one, gives “success” in the hub and a stranger in the plant search. I read the key mapping before I reopen SOAMANAGER or ALE partner profiles.
Patterns that keep showing up
Activate without replicate. The decision tables activate and complete, but nobody added the replicate pattern for this type. The hub looks perfect; the target never hears about the object. Confirm in the workflow log: if the last system step is activate with no replicate, fix the non-user agent group row before you rebuild DRF.
Filter too tight, or copied from a sample. The filter still limits on one company code or a custom field blank on create, so first replication skips and a later change somehow works. Confirm by reading the filter against the object’s org data, then re-run for a key that should pass and one that should stay out.
Wrong outbound for the landscape. The model still points at IDoc while the target only accepts the service, or the other way around. Configuration looks green; nothing usable arrives. Confirm by matching the outbound implementation to what the target consumes, then check for a fresh message of that type after activation.
Key mapping drift after a reload. The target was refreshed; mapping still points at old numbers. The hub reports OK; users search their daily key and find nothing, or a duplicate from inbound number ranges. Confirm by comparing hub key, mapping entry, and the plant’s search key, then run a second change that must update the same target record rather than create a twin.
Partial segment success. General data posts while plant or company-code views error in the target, so the ticket looks half-closed because “something arrived.” Confirm that the views the plant needs are present, not only the header, before you call it done.
Manual DRF run trusted more than the process. Someone runs replication by hand for one material, the ticket closes, and the next change request still has no replicate step. Confirm by activating a new request on the real type and checking that an outbound message appears without a manual DRFOUT.
How I confirm it actually landed
I pick a plant-recognizable object on the real change-request type. After activation, active data must show the field change the business asked for. An outbound message must exist for that object and that target after that change request, not a leftover manual run from last week. The target must hold the same business key, or the mapped key we agreed, with the plant, company-code, or sales views in scope. A second change must update that target record rather than create a twin. Finally I run one filter-negative case that should stay out — empty is better than the wrong plant receiving master data. If any fail, I stay on that layer; rebuilding the whole replication model will not repair a missing replicate row.
When a buyer says “approved but not in the target,” I prove what left MDG, then what the target accepted.
To walk this path on practice servers, the next MDG batch is at https://saberia.in/training. For a live landscape, write admin@saberia.in or see https://saberia.in/consulting.