An accounts payable lead messaged me on a Thursday afternoon. A supplier had changed banks, the change request in MDG was approved and activated, and someone had already run DRFOUT and sent her a screenshot of the green result. The payment run in S/4 was due on Friday, and the vendor in that run still carried the old account. She wanted to know whether she should hold the payment or trust the screenshot. I told her to hold it, and by the end of the evening we knew why: the message had reached S/4 and posted successfully, just not to the vendor she was paying.
This is a different problem from a change request that never replicates at all, which I wrote about earlier this month. In this case every monitor says the job is done. The gap sits in how the hub's partner and codes are translated into the target's partner and codes, and in what the target does with the message once it has it.
First, prove the message really left and arrived
I keep this part short because in this kind of ticket it usually passes, but I still do it, since everything after it depends on it.
I start on the hub. The change request is in its final status, and the active business partner shows the new bank details, so the hub is right. Then I open DRFLOG for the run and make sure this partner is actually listed for the business system in question. A green run can also mean the filter selected nothing, so a green line on its own proves very little. In DRFRSD I check that the replication status for this partner and this receiver has a timestamp after this activation, and not an old success from the initial load.
In MDGIMG, under the data replication settings, I read the replication model for that business system so I know which outbound to look at. If it is the SOA service, I open SRT_MONI on the hub and then on S/4. If it is ALE, I use WE02 on both sides and want the inbound IDoc in status 53. In this case both service messages were green, and when I opened the payload, the new IBAN was in it.
At that point I stop looking at replication, because the message left, it arrived and S/4 said it posted. The real question now is where it posted and what it changed.
Key mapping: which partner did S/4 actually update?
MDG does not send "update this vendor" in the target's own terms. It sends the hub's business partner, and key mapping tells it which partner or vendor number that is in each target system. If that mapping is wrong, the target updates a perfectly valid record that nobody uses.
I search key mapping with MDG_ANALYSE_IDM, using the hub partner number and the target business system. I want to see exactly one mapped partner on the S/4 side, and it has to be the number on the invoices and in the payment proposal. In this case it was not. The mapping pointed to a partner that had been created during an earlier test load and never cleaned up after the S/4 client was refreshed. That partner existed, it accepted the update, and it now had the new IBAN. The vendor in Friday's payment run still had the old one, and since nothing had failed, nothing had raised an alert.
I corrected the entry in MDG_KM_MAINTAIN so the hub partner pointed to the vendor that AP actually pays, and then replicated again. After a client copy or refresh, I now run MDG_ADJUST_IDM and then reread the mapping for a handful of high-volume vendors, rather than assuming the rows from the initial load still describe the target. I also look for the opposite fault. If there is no mapping entry at all, the target may treat the message as a new partner, and you end up with a twin instead of an update. If a second change creates a new number in S/4, the mapping is still not right.
It is also worth checking the target side of the link. In S/4 every vendor is a business partner, and the link between the two sits in CVI_VEND_LINK. If the mapped partner and the vendor on the invoice are not the same pair there, you are still comparing the wrong records.
Value mapping: the codes have to mean the same thing on both sides
The second run moved the bank to the right vendor. The same change request had also changed the payment terms on the company code, and that field still showed the old value on the correct vendor.
This is where value mapping comes in. Code lists such as country, region, payment terms, or bank country can differ between the hub and a target, especially when one side has custom codes. In MDGIMG, under General Settings, Value Mapping, you assign code lists to elements and business systems and maintain the internal and external values. Our new payment term existed on the hub, but the code list assigned to this business system was an older copy with no entry for it. The change request was clean and the message was green, but the term the target needed simply was not there.
I did not create a workaround code on the hub to force an error. I added the missing value to the mapping for that system, checked that the term also existed in the S/4 company code customizing, and ran the change again. When I review value mapping now, I check every code list that the business is likely to extend, not only the ones that broke last time.
The inbound side can quietly ignore what you sent
Even with the right key and the right codes, the target decides what to write. There are two patterns that have caught me more than once.
The first is bank details. A business partner can hold several bank entries, each with its own bank ID. If the hub and target do not agree on which entry is being replaced, the target can add the new account alongside the old one instead of replacing it. The partner then shows both accounts, and invoices that point to the old bank entry still pay the old account. I compare the bank entries in BUT0BK on both sides, not just the IBAN on the screen.
The second is a field that arrives in the payload but is not taken over. Field control in the target, a custom enhancement on the inbound processing, or the way the message flags which parts of the data are complete can all mean a segment is read and then left alone. When the payload has the value and the target does not, I check the inbound application log for that message before anything else, and then ask the S/4 team whether anything custom runs on the inbound.
How I decide it is really done
I take the same partner on the change-request type the business actually uses, make one change to a field we can both see, and activate.
DRFLOG must list the partner for that business system after the activation, and the service message or IDoc must contain the new value. In MDG_ANALYSE_IDM the hub partner must map to one S/4 partner, and that must be the vendor on the invoices. On that vendor, the bank entry, payment term, or address must show the new value with codes translated correctly. A second change must update the same number, and the old bank entry must be gone or deliberately kept, not left behind by accident.
A green DRFOUT tells me the run finished. What I send back to AP is the field value on the vendor they actually pay.
To practise this on our training servers, the next MDG batch is at https://saberia.in/training. For a live landscape, write to admin@saberia.in or see https://saberia.in/consulting.