Hoppa till innehållet

Kontrollera kunddubbletter inför en datamigrering

Ett exempel visar skillnaden mellan lika namn och samma kund. Kontrollera identitet, aktuell adress och befintliga orderkopplingar före överföringen.

Tobias Krüger2 min läsning
Tre kundkort med profilikoner, två grå rubrikfält, ett rosa rubrikfält och en rund rosa bock.

Fastställ före en datamigrering vilka poster som avser samma kund. Samma företagsnamn ger en ledtråd vid sökning, men bevisar inte att det är samma organisation. En ny adress kan tillhöra en befintlig kund; två företag med samma namn kan fortfarande vara skilda kunder.

Microsoft Dataverse skiljer möjliga dubbletter från den senare sammanslagningen. Vilka fält som ger en träff beror på de inställda reglerna. En likhetssökning ersätter därför inte verksamhetens beslut om kopplingen.

Skilj mellan tre poster med kontrollerade identiteter

Exemplet är helt fiktivt. Alla tre källposter heter Beispiel Technik GmbH. Organisationsreferenserna har redan kontrollerats för exemplet; de är inte officiella identifierare. Flytten för organisationen från den gamla Nordweg-adressen till Parkweg har också bekräftats. Tabellen visar förväntade migreringsbeslut, inte resultat av en genomförd import.

Källpost

Adress i posten

Kontrollerad organisation

Beslut i målsystemet

SRC-11

Nordweg 4

ORG-41

Koppla till kund K-900.

SRC-12

Südweg 9

ORG-88

Håll separat och koppla till K-901.

SRC-13

Parkweg 6

ORG-41

Koppla också till K-900; använd den bekräftade aktuella adressen.

De första två raderna förblir åtskilda trots samma namn. Den första och tredje hör ihop trots olika adresser. I exemplet blir Parkweg 6 aktuell adress för kund K-900. Det får inte tyst ändra en tidigare leveransadress i en befintlig order.

Dokumentera underlag och oklara fall före importen

Låt kopplingen granskas mot lämpliga identitetsunderlag som godtagits i projektet. Tillförlitliga referenser och spårbar dokumentation av masterdata kan användas. Identifierarna i tabellen står för resultatet av den kontrollen. De får inte bara härledas ur det liknande namnet.

Utan tillförlitligt underlag förblir kopplingen oklar. Dokumentera möjliga träffar, skälet till utredning och ansvarig roll. En ny post kräver ett bekräftat beslut om kunden; den får inte kringgå den saknade identitetskontrollen. En sammanslagning kan också påverka länkade poster: kontrollera den konkreta produktfunktionen före användning.

Fortsätt använda den bekräftade kopplingen

Spara länken mellan källa och mål så att en senare överföring känner igen samma post. I vår utformning är (sourceSystem, sourceId) den unika källreferensen. Den kopplas till den bekräftade målidentifieraren. Fältnamnen beskriver vårt exempel, inte Dataverse-API:et.

Dataverse dokumenterar alternativa nycklar som bygger på en unik kombination av kolumnvärden. Klarlägg i den tekniska förstudien vilka nycklar och begränsningar systemen faktiskt stöder. En kopplingslista upprätthåller inte ensam unikhet i målsystemet.

Pröva även upprepning och relationer

Överför först exempeldata till en lämplig testmiljö. Kontrollera de två skilda målkunderna, den gemensamma kopplingen för den flyttade organisationen och dess aktuella adress. Skicka därefter samma källreferenser igen: ingen extra kund ska skapas.

Kontrollera också vilken målkund de överförda orderna tillhör och om historiska dokumentadresser bevaras. Ändras en bekräftad koppling senare måste följderna för befintliga relationer granskas separat.

Källor

Skriven av

  • Tobias KrügerRedaktör för systemintegrationTobias Krüger arbetar på ASES med hur olika mjukvarusystem samverkar. I sina artiklar förklarar han hur ERP, CRM och webbutiker kopplas samman och hur man hanterar fel i datautbytet.

Följ ASES

Läs vidare

Alla artiklar

API:er & integration med ASES

ERP, CRM och webbutik smidigt sammankopplade