Vai al contenuto

Collegare CRM ed ERP: definire la fonte di ogni campo

Una tabella compilata definisce fonti e direzioni di scrittura. Separa contatto, indirizzo di fatturazione e stato del conto tra CRM ed ERP.

Tobias Krüger2 min di lettura
Campo indirizzo verde con indicatore di posizione e linguetta con un ingranaggio.

Prima di collegare CRM ed ERP, definisca dove ogni valore viene modificato e confermato. Un cliente può esistere in entrambi i sistemi, con responsabilità diverse per campo. Ne deriva un contratto dati per l’implementazione: identità, significato del campo, fonte principale e direzione di scrittura consentita.

Identificare lo stesso record senza ambiguità

Un’azienda fittizia di software collega il cliente CRM C-204 al conto cliente ERP D-630. L’associazione deve restare stabile tramite questi riferimenti; un nome aziendale simile non basta. Per Dataverse, Microsoft descrive per esempio chiavi alternative che identificano righe tramite valori di colonna univoci. Le chiavi offerte dai sistemi effettivi vanno verificate tecnicamente.

Nell’esempio, la fonte principale conferma il valore valido del campo. L’altro sistema può mostrarlo o inviare una richiesta di modifica. Nomi e valori della tabella sono un modello progettato per questo esempio, non campi API di un fornitore.

Compilare fonte e direzione per ogni campo

Campo

Valore d’esempio

Fonte principale e direzione

Modifica nell’altro sistema

Contatto di progetto technicalContactEmail

projekt@example.invalid

CRM → ERP, come contatto tecnico.

Solo visualizzazione nell’ERP.

Indirizzo di fatturazione billingAddress

Werkstraße 8, Beispielstadt

ERP → CRM.

Registrare una richiesta di modifica nel CRM.

Stato del conto billingAccountState

active

ERP → CRM.

Uno stato commerciale nel CRM non modifica questo valore.

La direzione è definita per campo; una regola generale che attribuisse autorità al CRM non rappresenterebbe questa ripartizione. La documentazione dual-write di Microsoft mostra associazioni di colonne a una o due direzioni; il contratto concreto stabilisce quella adatta qui.

Trattare un valore diverso come richiesta di modifica

Se le vendite indicano nel CRM il nuovo indirizzo Werkstraße 12, Beispielstadt, deve prima crearsi una richiesta aperta. Il gruppo ERP autorizzato la verifica e conferma la modifica se appropriata. Torna solo il valore ERP confermato. Indirizzo richiesto e confermato richiedono quindi stati distinti.

Se il trasferimento fallisce, il CRM deve distinguere la richiesta aperta dall’ultimo stato confermato. Inviare un’operazione all’interfaccia non è una conferma del sistema di destinazione. Momento ed esito dell’elaborazione devono restare tracciabili sul caso.

Verificare tre trasferimenti con risultati attesi

Prima dell’utilizzo, verifichi l’accordo in un ambiente di prova adeguato:

  • Il contatto modificato in projekt-neu@example.invalid nel CRM compare come contatto tecnico nell’ERP.

  • Una richiesta d’indirizzo lascia inizialmente invariato il valore confermato Werkstraße 8, Beispielstadt. Dopo l’approvazione ERP, il nuovo indirizzo compare anche nel CRM.

  • Se l’ERP porta lo stato del conto a blocked, il CRM lo mostra. Cambiare lo stato commerciale non rimuove il blocco.

I risultati verificano campi e permessi di scrittura diversi. Trasferire tecnicamente un solo record con successo non copre interamente queste tre regole.

Fonti

Scritto da

  • Tobias KrügerRedattore per l’integrazione di sistemiTobias Krüger si occupa per ASES dell’interazione tra diversi sistemi software. Nei suoi articoli spiega l’integrazione di ERP, CRM e negozi online e come gestire gli errori nello scambio di dati.

Seguite ASES

Continuate a leggere

Tutti gli articoli

API & integrazione con ASES

ERP, CRM e negozio online collegati in modo pulito