A buyer messaged me after a vendor create was approved. The new number was active. So was an older one for the same company, same city, almost the same street. Nobody had seen a duplicate list on the way through. The requestor had pressed Check. We had enabled the check on a type we used in a workshop and assumed the type in the menu inherited it. It had not.
This type, this step
I open MDGIMG and go to General Settings, Process Modeling, Change Requests, Configure Properties of Change Request Step. I pick the change-request type that was actually submitted, not the workshop copy.
Then I look at the step where the name and address are complete enough to match. Often that is step 00. If the legal name only arrives on the next dialog step, the check has to be allowed there as well.
Under Enhancements and Checks per Change Request Step, duplicate check has to be Relevant. If it is not, Check runs the other validations and says nothing about a twin. Execution can be always, or only when data changes. The second choice is wrong on a confirm step: nothing was edited, the check skips, and activation writes a second partner.
On the business partner model the entity is BP_HEADER. A row for another entity never sees this request.
Which search runs
Relevant means “call the configured search.” It does not mean that search can see this partner.
Under General Settings, Data Quality and Search, Search and Duplicate Check, I open Configure Duplicate Check for Entity Types. I want one row for data model BP and entity type BP_HEADER.
DB is database search. A shortened street or a spelled-out legal form will not hit. ES is Enterprise Search. The list comes from the connector, not from the partner tables at that moment. AD is Business Address Services, through the BAS duplicate interface. Two names pass when BAS treats the addresses as different. HA is SAP HANA search. On Define Search Applications the Fuzzy flag does nothing for HA. HANA search is already fuzzy.
I read the match profile on that row, then open Match Profile under Define Search Applications for the same mode. It has to be data model BP and the attributes the business actually matches: name, street, house number, city, postal code, country, tax number. A profile that only has the business partner number will not call two companies the same.
A mandatory attribute that is still empty means the check does not run. I lost a round to a tax number that was mandatory on the profile and blank until a later step, while that later step was not Relevant. The customizing looked done. The check was never eligible.
For HA, the profile should name the search rule set from the search view. That rule set is what gets used, not the attribute view. Weight and fuzziness on the profile do not move the score while the rule set stays as it was.
Can it see a partner from this morning
Create Search View is transaction MDG_HDB_GEN_UI. It builds attribute views for the active area and for the inactive area, which is staging. An active partner and a partner still on an open change request are different reads.
If the view no longer matches its objects, the status goes to Outdated. I regenerate it in the customer package this system already uses. Then, on search mode HA, I check Allocation of Search Help to Search Applications and Allocation of Entities to Search Help. This view has to be the included search help, on entity BP_HEADER. A view that was never allocated is not called.
Regenerating the view does not rebuild the rule set. Adjust the rule set itself when attributes change, or the next create misses the same way.
The staging view should hide records marked obsolete, not every open request. If I can still open the partner and the list omits it, I look at that filter before I touch a threshold.
If HANA is only a side database, the view is only as current as the copy. I check HDBC, and on the replication server I check IUUC_SYNC_MON for this morning’s partner. On S/4HANA the search reads the local database, so a miss there is the view, the rule set, or the step.
For ES I open ESH_COCKPIT. The connector has to be the one from template MDG_BUSINESS_PARTNER, with real-time indexing on, under Actions, Schedule Indexing. Off means a partner activated before lunch is invisible until the next delta. The afternoon request creates the twin. A connector in error returns an empty list, and the screen still looks like a pass.
If our existing partner is missing from the duplicate list and from the same search method on the search screen, the index is late.
The name they actually type
One record says GmbH. The other spells the legal form. One says Str., the other Strasse. On HANA that is stopwords and term mappings on the rule set, for the forms this data uses. A mapping copied from another country will not catch them.
On AD I compare the stored address with the address on the new request before I move a threshold. A lower number will not pull those strings together. The check stays quiet, or it starts blocking good creates.
The two thresholds
The row has Low Thres and High Thres, as percentages. High Thres is the stop line. I do not hunt for a third field called invalidation.
Under the low threshold, nothing is shown. That empty list is the miss. Between the two, the user sees a potential duplicate and can still continue. Approvers who always continue still create the twin. I say that before I lower anything.
Above the high threshold the records count as identical, and that create is not supposed to go through as a new partner. The hit is still shown, so someone can take the old record. A high threshold at the top of the scale blocks almost nothing.
The low threshold decides what HANA search shows. It does not behave the same way for database search, remote key search, or Enterprise Search. I do not paste a HANA pair onto an ES row.
I change a number only after this real pair scores too low. Low goes under the score we just measured. High goes where the business agrees the create has to stop.
Proof, both ways
I retest on the type from the menu.
Positive: same legal name, same city, and the tax number or street the profile uses. The list must show that partner. Above the high threshold, the request must not end as a second active partner. I run it for an active partner and for one still in staging. For Enterprise Search, the open request only counts if real-time indexing is on, or if I waited for the delta.
Second positive: the legal form or street written the way requestors type it. Silence here means the rule set or BAS is still wrong.
Negative: a different company, different city, different tax number. It must not be blocked, and it should not lead the list.
Then one clean request is allowed through. Active area, one business partner for that company. A second number means I am not finished.
I leave the old twins for a cleansing case. That path exists for business partner only. This fix is the next create. No dump. No failed message. Two numbers in purchasing.
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.