CRM un ERP datu sinhronizācija: kura sistēma ir noteicošā katram laukam?

Pirms CRM un ERP integrācijas katram koplietotajam laukam nosakiet noteicošo sistēmu, atbildīgo darbinieka lomu un konfliktu apstrādes kārtību. Atsevišķi vienojieties par ieraksta izveidi un turpmākajiem labojumiem. Neizvēlieties divvirzienu sinhronizāciju visam klienta ierakstam tikai tāpēc, ka abas sistēmas ļauj to rediģēt.

Nosakiet atbildību katram laukam, nevis visai sistēmai

Prasību aprakstā nošķiriet trīs darbības: jauna klienta izveidi, konkrēta lauka labošanu un vērtības pārkopēšanu uz otru sistēmu. CRM varat noteikt kā galveno avotu kontaktinformācijai, bet ERP — pasūtījuma izpildes informācijai. Šādu sadalījumu pielāgojiet savam procesam, nevis pieņemiet par universālu standartu.

Business Central dokumentācijā tabulu sasaiste, lauku atbilstība, datu plūsmas virziens un vērtību pārveidošana ir aplūkoti kā atsevišķi konfigurācijas aspekti. Tomēr jaunu tabulu un lauku atbilstību vedņa sadaļai ir preview marķējums, un pielāgoto tabulu pieejamība dažādās Business Central versijās atšķiras. Skatiet Business Central tabulu un lauku atbilstību dokumentāciju. Šo piemēru izmantojiet prasību strukturēšanai, nevis kā solījumu par iespējām jebkurā instalācijā.

Praktiska datu atbildības tabula

Ilustratīvs piemērs: izdomāts Latvijas B2B preču piegādātājs vēlas CRM uzturēt pārdošanas kontaktus, bet ERP — apstiprinātos klientus un pasūtījumu izpildi. Zemāk ir redakcionāls projektēšanas priekšlikums, nevis ražotāja noklusējuma konfigurācija vai VIZUAL klienta gadījums.

Objekts vai lauks	Noteicošā sistēma	Atbildīgā loma	Izveides vai izmaiņu nosacījums	Sinhronizācijas virziens	Rīcība konflikta gadījumā
Potenciālā klienta uzņēmuma ieraksts	CRM	Pārdošanas speciālists	Izveido pēc sākotnējās uzņēmuma identificēšanas.	Sākotnēji nepārnes uz ERP.	Pirms izveides pārskata iespējamos dublikātus.
ERP klienta ieraksts un tā ID	ERP	Klientu datu administrators	Izveido pēc darījuma apstiprināšanas un esošo ERP ierakstu pārbaudes.	CRM → ERP izveides pieprasījums; ERP → CRM piešķirtais ID.	Esošu klientu sasaista; neskaidru atbilstību nodod pārbaudei.
Kontaktpersonas tālrunis un e-pasts	CRM	Pārdošanas speciālists	Labo pēc kontaktpersonas sniegtās informācijas pārbaudes.	CRM → ERP	ERP ierosinātu labojumu nodod pārdošanai apstiprināšanai.
Uzņēmuma nosaukums un reģistrācijas numurs	ERP pēc klienta apstiprināšanas	Klientu datu administrators	Apstiprina, veidojot ERP klientu; vēlāk labo pēc pārbaudes.	ERP → CRM	Aptur automātisku pārrakstīšanu un pārbauda uzņēmuma identitāti.
Konkrētā pasūtījuma piegādes adrese	ERP	Pasūtījumu koordinators	Apstiprina pirms nodošanas izpildei; vēlākas izmaiņas saskaņo.	ERP → CRM	Atšķirīgu adresi nodod koordinatoram izvērtēšanai.
Pasūtījuma izpildes informācija	ERP	Izpildes komanda	Atjaunina pēc izpildes darbības apstiprināšanas.	ERP → CRM	ERP vērtība ir noteicošā; CRM to neraksta atpakaļ.

Pievienojiet tabulai arī abu sistēmu tehniskos lauku nosaukumus, atļautās vērtības un noteikumus tukšiem laukiem. Piemēram, vienojieties, vai tukšs tālruņa lauks nozīmē dzēšanas pieprasījumu vai informācijas trūkumu. Šo izvēli neatstājiet izstrādātāja minējumam.

Īpaši atzīmējiet atbildības maiņas brīdi. Šajā piemērā uzņēmuma nosaukumu sākotnēji ievada CRM, bet pēc ERP klienta apstiprināšanas turpmākos labojumus uztic ERP administratoram. Aprakstiet arī rīcību, ja administrators izveides pieprasījumu noraida.

Vienvirziena vai divvirzienu sinhronizācija?

Vienvirziena plūsmu izvēlieties kā sākumpunktu laukam, kuru uztur viena komanda vienā sistēmā. Otrā sistēmā ieplānojiet tikai skatīšanu vai labojuma pieprasīšanu. Savukārt divvirzienu plūsmu apsveriet, ja rediģēšana abās pusēs ir pamatota darba vajadzība un komandai ir skaidrs konfliktu risināšanas noteikums.

Divas pretēji vērstas plūsmas dažādiem laukiem nav tas pats, kas viena lauka divvirzienu sinhronizācija. Ja tālrunis plūst no CRM uz ERP, bet izpildes informācija no ERP uz CRM, katram laukam joprojām varat saglabāt vienu noteicošo avotu.

Ilustratīvs konflikts: pārdošanas speciālists CRM ievada jaunu kontaktpersonas tālruni, bet administrators ERP tajā pašā laikā norāda citu numuru. Iepriekš izvēlieties rīcību: saglabāt CRM vērtību, nodot abas vērtības atbildīgajam vai izmantot citu skaidri aprakstītu noteikumu. Ja izvēlaties jaunākā labojuma prioritāti, precizējiet, ko nozīmē “jaunākais” un kā to pārbaudīsiet.

Atjauninot klientu ar Business Central API v2.0, nepieciešams If-Match; ieraksts netiek atjaunināts, ja iesūtītais ETag neatbilst tā pašreizējai versijai. To apraksta Microsoft klienta atjaunināšanas dokumentācija. Šo versijas pārbaudi neuztveriet kā uzņēmuma konfliktu atrisināšanas noteikumu. Pēc noraidījuma paredziet atkārtotu nolasīšanu un salīdzināšanu, nevis aklu visa ieraksta pārrakstīšanu.

Identifikatori un dublikāti: kā sasaistīt klientu

Dokumentējiet CRM ieraksta ID un atbilstošā ERP klienta ID sasaisti. Sākotnējai salāgošanai izvēlieties pārbaudāmus kritērijus un norādiet atbildīgo par neskaidriem gadījumiem. Ja atrodami vairāki iespējamie ieraksti, ieteicams apturēt automātisku sasaisti un pieprasīt pārbaudi, nevis izvēlēties pirmo rezultātu.

Uzņēmumu un tā kontaktpersonas aprakstiet kā atsevišķus objektus ar savām saitēm. Kontaktpersonas e-pastu neizvēlieties par universālu uzņēmuma identifikatoru. Testos iekļaujiet arī e-pasta maiņu un vairākas kontaktpersonas vienam uzņēmumam. Pirms sākotnējās datu pārneses sagatavojiet nesasaistīto un neskaidro ierakstu sarakstu.

HubSpot kontaktu API pakešu upsert darbība ļauj pēc e-pasta vai pielāgota unikālā identifikatora atjaunināt kontaktu vai izveidot jaunu. Daļējam upsert šajā API jāizmanto pielāgots unikālais identifikators, jo email kā idProperty šādam lietojumam netiek atbalstīts. Šie nosacījumi aprakstīti HubSpot kontaktu API dokumentācijā.

Šo kontaktu API piemēru neattieciniet uz uzņēmumiem, pasūtījumiem vai visu CRM sistēmu uzvedību. Katram objektam pārbaudiet, pēc kā drīkst meklēt un atjaunināt ierakstu, kā arī definējiet rīcību, ja integrācijas saglabātais ID vairs nav izmantojams.

Pasūtījuma statuss, kavējumi un atkārtoti paziņojumi

Veidojiet statusu nozīmju atbilstības tabulu, nevis savienojiet laukus tikai pēc līdzīga nosaukuma. Katram CRM attēlojamajam statusam norādiet ERP avota lauku, nosacījumu un sagaidāmo rīcību, ja nepieciešamās informācijas nav.

Business Central API v2.0 objektam salesOrder dokumentētās status vērtības ir Draft, In Review un Open; informācijai par pilnīgu preču nosūtīšanu paredzēts atsevišķs fullyShipped lauks. Skatiet Business Central salesOrder objekta aprakstu. Tādēļ šajā piemērā nepielīdziniet Open vērtību pilnīgai nosūtīšanai un neveidojiet no šiem laukiem universālu pasūtījuma dzīves cikla modeli.

HubSpot Webhooks API pieļauj paziņojumu saņemšanu citā secībā un vairāk nekā vienu paziņojumu par notikumu; arī eventId unikalitāte nav garantēta. To norāda HubSpot Webhooks API dokumentācija. Prasībās paredziet, ka atkārtota paziņojuma apstrāde nerada otru klientu vai atkārtotu biznesa darbību. Pārbaudiet izvēlēto atkārtojumu atpazīšanas pieeju, nepaļaujoties tikai uz eventId.

Ilustratīvs tests: pēc jaunāka izpildes atjauninājuma pienāk aizkavēts paziņojums par agrāku stāvokli. Kā gaidīto rezultātu nosakiet jaunākā apstiprinātā stāvokļa saglabāšanu; tehnisko pārbaudi izvēlieties atbilstoši API iespējām.

Microsoft 2025. gada 11. jūnija dokumentācijā aprakstītais Business Central–Dataverse mehānisms izmanto plānotus uzdevumus; reāllaika datu konsekvence tajā nav garantēta. Skatiet Business Central sinhronizācijas un datu integrācijas aprakstu. Neattieciniet to uz visām integrācijām. Savam risinājumam saskaņojiet pieļaujamo kavējumu, pēdējās veiksmīgās sinhronizācijas attēlošanu un brīdinājumu saņēmēju.

Pirms ieviešanas: API pārbaude un pieņemšanas testi

Izvēlētajam CRM un ERP pārim sagatavojiet tehnisku pārbaudes sarakstu. Pirms izstrādes apstipriniet:

• API un piekļuvi: izmantoto versiju, vajadzīgo objektu un lauku pieejamību, lasīšanas un rakstīšanas tiesības.
• Datu plūsmu: identifikatorus, izmaiņu noteikšanas iespējas, pieprasījumu ierobežojumus un rīcību pēc neveiksmīga pieprasījuma.
• Ieraksta dzīves ciklu: izveides, dzēšanas un apvienošanas iespējas, kā arī saistīto ID turpmāko izmantošanu.

Tālāk minētie ir ieteicami pieņemšanas testi. Katram pierakstiet sākuma datus, darbību, gaidīto rezultātu abās sistēmās, kļūdu apstrādes kārtību un atbildīgo par rezultāta pārbaudi.

1. Jauns klients: ERP ierakstu izveido tikai saskaņotajā procesa posmā; tā ID saglabā CRM sasaistē.
2. Jau esošs ERP klients: izmanto esošo ierakstu; vairākas iespējamās atbilstības nodod pārbaudei.
3. Kontaktinformācijas maiņa: pārnes paredzēto lauku, nemainot citas komandas pārziņā esošās vērtības.
4. Vienlaicīgi labojumi: piemēro saskaņoto prioritāti vai izveido pārskatāmu uzdevumu atbildīgajam.
5. Atkārtots paziņojums: atkārtota apstrāde nerada jaunu ierakstu vai vēlreiz izpildītu biznesa darbību.
6. Novēlots paziņojums: agrāka izmaiņa nepārraksta jaunāko apstiprināto stāvokli.
7. Savienojuma pārtraukums: pēc atjaunošanās apstrādā atlikušās izmaiņas un padara kļūdas redzamas atbildīgajam.
8. Dzēsts vai apvienots ieraksts: seko iepriekš noteiktajai sasaistes maiņas vai apstrādes apturēšanas kārtībai.

Sāciet ar vienu objektu un skaidri norobežotu lauku kopu. Apstipriniet atbildības tabulu ar iesaistītajām komandām un tikai pēc testu rezultātu izvērtēšanas paplašiniet tvērumu. Neatrisinātos procesa jautājumus pierakstiet atsevišķi no tehniskajiem uzdevumiem.

Avotu tvērums: tehniskie piemēri balstīti dokumentācijas izpētes izvilkumos ar pārbaudes datumu 2026. gada 11. septembris, nevis konkrētās instalācijas pārbaudē. Pirms ieviešanas pārbaudiet aktuālo dokumentāciju un konfigurāciju.

Ja nepieciešams apspriest sistēmu savienošanu, iepazīstieties ar VIZUAL piedāvātajiem integrāciju un MCP risinājumiem. Sarunai sagatavojiet savu datu atbildības tabulu, izmantoto sistēmu nosaukumus un neskaidros procesa jautājumus.