Zaniżona marża może ujawnić błąd, który powstał wcześniej w kartotece klienta. Przychód zapisano przy jednej karcie, koszt reklamacji przy drugiej, a zaległą fakturę przy trzeciej. CRM zawiera aktywną relację bez zadłużenia, natomiast w ERP należność widnieje pod inną nazwą kontrahenta. Wyjaśnienie biegnie od raportu marży wstecz, przez windykację i dokumenty, aż do synchronizacji oraz pól użytych przy dopasowaniu. Lokalny model pomaga zestawić te powiązania na kontrolowanej infrastrukturze połączonej z ERP i CRM, bez wynoszenia danych finansowych poza to środowisko.
Marża wskazuje skutek, nie źródło
W raporcie przychody i koszty są łączone przez identyfikatory klienta oraz odwołania do dokumentów. Gdy reklamacja trafia na inną kartę niż sprzedaż, obliczona marża spada mimo poprawnych kwot na obu dokumentach. Analiza zaczyna się więc od rekordów użytych do raportu, a nie od samej formuły obliczeń.
Controlling zestawia przychód, koszt reklamacji i przypisanie kontrahenta. Księgowość odnajduje faktury, wpłaty oraz korekty. Windykacja wskazuje otwarte należności, adresata wysłanego wezwania i historię kontaktu. CRM dostarcza informacje o aktywnej relacji handlowej. Każdy obszar wnosi inny fragment obrazu.
Przed scaleniem kart trzeba zachować relacje między dokumentami. Pochopna korekta na podstawie podobnej nazwy mogłaby odłączyć wpłatę, limit kupiecki lub koszt od właściwego podmiotu. Kopia zależności służy do kontroli naprawy, nie do tworzenia równoległej kartoteki. Zestaw obejmuje także dokumenty zamknięte, ponieważ wcześniejsza korekta albo wpłata może wyjaśnić, dlaczego bieżące saldo trafiło na inną kartę. Kontrola nie kończy się na jednej fakturze. Ten sam błędny identyfikator mógł przejąć inne wpłaty, korekty, reklamacje lub limity kupieckie. Zakres ustala się zatem na podstawie relacji zapisanych w obu systemach, a każdą zmianę odnosi do dokumentu źródłowego.
Trzy karty jednego kontrahenta
Pierwsza karta zawiera przychód i aktywne zamówienia. Druga przejęła koszty reklamacji po zmianie adresu. Trzecia powstała podczas synchronizacji i otrzymała zaległą fakturę. Osobno każda wygląda wiarygodnie. Dopiero zestawienie salda, dokumentów i identyfikatorów źródłowych ujawnia, że opisują jednego klienta.
Nazwa i adres są sygnałami pomocniczymi. Większe znaczenie mają NIP, identyfikator systemu źródłowego oraz relacja płatnika. Ten sam numer konta bankowego także nie jest samodzielnym dowodem, ponieważ centrala może obsługiwać płatności kilku podmiotów. Konflikt NIP wymaga zatrzymania automatycznej korekty nawet przy bardzo podobnej nazwie. Brak jednej cechy nie przesądza jeszcze o duplikacie; liczy się zgodność całego zestawu i pochodzenie każdego pola.
Ślad prowadzi do synchronizacji
Historia wymiany pokazuje, że nowa karta pojawiła się po zmianie adresu w CRM. Mechanizm odnalazł podobny wpis w ERP, a kolejny zapis przeniósł część odwołań. Przyczyną mogły być niepełne dane wejściowe, zbyt szeroka reguła dopasowania albo zatwierdzenie wykonane bez zauważenia sprzecznych identyfikatorów.
Usunięcie duplikatu nie usuwa jego skutków. Faktura i wpłata mogą nadal wskazywać inny identyfikator, wezwanie mogło trafić do niewłaściwego podmiotu, a koszt reklamacji pozostać na karcie pomijanej przy obliczaniu przychodu. Zakres naprawy obejmuje każdą relację zmienioną przez wadliwą synchronizację.
Dziennik łączy wersję pobranych pól, konfigurację modelu, osobę akceptującą i zakres późniejszej operacji. Oddziela propozycję dopasowania od zapisu wykonanego w ERP lub CRM. Przy odrzuceniu pary zapisuje się przyczynę, na przykład różny NIP lub odmienną relację płatnika, zamiast samego statusu. Model nie zmienia sam faktur, płatności, salda ani limitu kupieckiego.
Lokalny model porównuje tylko potrzebne pola
Pierwszy etap wykorzystuje identyfikatory źródłowe, NIP, nazwę, adres i relację płatnika. Saldo, otwarte należności oraz historia płatności pojawiają się później, gdy trzeba ocenić finansowy skutek połączenia. Rozdzielenie etapów ogranicza zakres danych dostępnych w pojedynczej analizie i chroni dokumenty przed zbiorczą korektą.
Każde pole zachowuje informację o źródle i wersji. Model opisuje zgodności oraz sprzeczności zamiast zwracać samą ocenę liczbową. Wspólny adres może oznaczać oddział, podobna nazwa inny zapis firmy, a odmienny NIP dwa różne podmioty. Obok propozycji znajdują się odwołania do konkretnych kart, aby oceniający nie wyszukiwał ich ponownie. Para niejednoznaczna trafia do osoby odpowiedzialnej za dane podstawowe, a konflikt finansowy także do księgowości.
Lokalny model, baza robocza i dziennik operacji mogą działać na serwerach wirtualnych G2E obok hostowanych systemów ERP, CRM i SQL. Komponenty wymieniają potrzebne dane przez prywatną sieć. Organizacja z integratorem ustala dozwolone pola, konta, retencję kopii roboczej i zasady pseudonimizacji. Materiał do porównania nie wymaga stałego szerokiego dostępu do produkcji.
Od błędnej marży do poprawnej kartoteki
Naprawa przebiega odwrotnie do wykrytego skutku. Controlling najpierw wskazuje przychód i koszt przypisane do różnych kart. Księgowość ustala powiązania faktur, wpłat i korekt. Windykacja przenosi należność oraz historię kontaktu na właściwą kartę klienta. Na końcu integrator usuwa wadliwe mapowanie i zawęża regułę, która utworzyła duplikat.
Po korekcie ERP zawiera właściwe saldo i dokumenty. CRM pokazuje jedną aktywną relację, w danych windykacyjnych należność i historia wezwań są przypisane do właściwego dłużnika, a raport marży obejmuje komplet przypisanych przychodów i kosztów. To zamyka konkretny incydent: trzy karty przestają dzielić jednego klienta, a następna synchronizacja nie odtwarza błędnego powiązania.