SWA031 - Sincronizzazione clienti¶
Logica generale Import/export delle anagrafiche clienti tra gestionale e database KPN Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| clienti | inf-rating | |
| clienti | inf-multiplo-standard | |
| clienti | inf-raggr-statistico | |
| clienti | inf-raggr-stat-2 | |
| clienti | inf-raggr-stat-3 |
Versioni tabella ARPANAGR (vedi APSTATOSYN) Versione attuale: 2
| Versione | Descrizione |
|---|---|
| 1 | |
| 2 | Se la versione precedente della tabella è <2, dovrà essere effettuata una sola volta un'esportazione di tutti i clienti, azzerando la data ultima esportazione prima di iniziare |
Elaborazione Se l'operazione è: * "SINCRO": Esecuzione di * A - Importazione aggiornamenti da APP * B - Importazione aggiornamenti da Shop * C - Esportazione clienti * "ESPORTA-CLIENTE": Esecuzione di: * D - Esportazione cliente singolo A - Importazione aggiornamenti da APP Nuovo giro di importazione aggiornamenti da ARPANAGR, funzionale all'importazione degli aggiornamenti effettuati da Areagate/APP. * Query di ricerca di tutti i record di ARPANAGR per l'azienda, con "RANA_AGG_APP" = "A". Per ciascun record: * La posizione GPS su COGGEANA è vuota? * Se SI e sul gestionale è vuota, dovrà essere importata * Azzerare il flag RANA_AGG_APP=" " In questa fase saranno acquisite anche le modifiche ad alcuni dati che è possibile ora modificare su APP: * Ragione sociale * Indirizzo * Cap * Località * Provincia * Partita IVA * Codice fiscale * Telefono * Fax * Email B - Importazione aggiornamenti da Shop Eseguire una chiamata a SWA030 - Importazione nuovi clienti. C - Esportazione clienti Su POSTGRES, tabella APSTATOSYN, leggere il record relativo alla tabella/oggetto da sincronizzare "ARPANAGR"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPANAGR" |
| A_SYN_DA_GES_DATA | 0 |
| A_SYN_DA_GES_ORA | 0 |
| A_SYN_DA_ID_SINCRO | 1 |
Qui otterremo la data/ora aggiornamento dell'ultima anagrafica cliente esportata. Se A-SYN-VERSIONE è < 2, impostare data/ora aggiornamento a 0, in modo da riesportare tutti i clienti. Ricerca di tutte le anagrafiche clienti (COGGEANA) con ANA-TIPO = "C". Su ciascuna anagrafica letta saranno effettuati i seguenti controlli: * Se siamo in ambiente CAP e il numero di giorni configurato è 9999 * Il cliente deve avere almeno una partita * Saranno considerati solo i clienti aggiornati successivamente alla data/ora aggiornamento trovata su APSTATOSYN: usare COGANCAP.ANC-DA-DATA e COGANCAP.ANC-DA-ORA. Superati i controlli il cliente sara' esportato.
| Nome campo | Note |
|---|---|
| dati precedenti | Eventualmente da documentare |
| RANA-ID-SINCRO | Id sincronizzazione trovato su una numerazione specifica Sarebbe meglio adeguare questo come le altre tabella all'uso dell'id-sincro trovato su APSTATOSYN |
| RANA-LATITUDINE | Se ANC-LATITUDINE/ANC-LONGITUDINE sono diversi da quelli presenti su ARPANAGR, hanno priorita': quindi aggiornarli e impostare anche RANA-AGG-APP = " " |
| RANA-LONGITUDINE | |
| RANA-AGG-APP | |
| RANA-AGG-AREA | "A" |
| RANA_STATO_CONTENZIOSO | AAP2-STATO-CONTENZIOSO |
| RANA_TIPO_TRASPORTO | AAP-TRASP-CURA |
| RANA_CODICE_HOST | AAP2-RACCORDO |
| RANA_CLIENTE_LISTINO | AAP2-CLIENTE-LISTINO |
| RANA-IBAN | Il codice IBAN completo ottenuto unendo insieme i campi presenti su COGAPPOG, vedi COGE08C; deve essere esposto con i campi nell'ordine corretto come viene visualizzato sulla maschera |
| RANA-RATING | L'informazione CRM trovata sulla scheda nominativo, configurata in inf-rating, se > 0 |
| RANA-SCONTO-FIN | AAP2-SCONTO-FIN |
| RANA-MULTIPLO-STANDARD | L'informazione CRM trovata sulla scheda nominativo, configurata in inf-multiplo-standard, se > 0 |
| RANA_GRP_STAT_1 | L'informazione CRM trovata sulla scheda nominativo, configurata in inf-raggr-statistico, se > 0 |
| RANA_GRP_STAT_2 | L'informazione CRM trovata sulla scheda nominativo, configurata in inf-raggr-stat-2, se > 0 |
| RANA_GRP_STAT_2 | L'informazione CRM trovata sulla scheda nominativo, configurata in inf-raggr-stat-3, se > 0 |
| RANA_CODICE_PV | AAP2-CODICE-PV |
| RANA_INCOTERMS | AAP2-INCOTERMS |
| RANA_ORDINE_MINIMO | AAP2-ORDINE-MINIMO |
| RANA_NOMINATIVO_CRM | Inserire il codice nominativo CRA-COD trovato su CRMANAGR a fronte dell'anagrafica cliente, effettuando una ricerca tramite CRA-CHIA3 |
C.1 Posizione GPS La posizione GPS sulle anagrafiche clienti segue la seguente regola (vedi Posizione GPS) * Durante la fase di esportazione: * La posizione sul gestionale (ANC-LATITUDINE/LONGITUDINE) è diversa da quella presente sul WEB: * la posizione GPS verrà esportata * il flag RANA_AGG_APP dovrà essere reimpostato a ' ' C.2 Verifica clienti eliminati Quando si effettua l'elaborazione con la configurazione "Giorni=9999", eseguire anche questo giro aggiuntivo che permette di eliminare logicamente i clienti che non esistono più in Area. 1. Tramite una query, selezionare i clienti dell'azienda che non sono cancellati (RANA_VAL <> "C"). 2. Per ciascun cliente, Eseguire la lettura su COGGEANA 3. Se il cliente non esiste, effettuare la cancellazione logica 1. RANA-VAL = "C" 2. RANA-ID-SINCRO aggiornato C.9 - aggiornamento APSTATOSYN Al termine aggiornare il record di controllo della tabella:
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPANAGR" |
| A_SYN_DA_GES_DATA | Data/ora dell'ultimo record aggiornato |
| A_SYN_DA_GES_ORA | |
| A_SYN_DA_ID_SINCRO | Ultimo ID sincro aggiornato |
| A_SYN_VERSIONE | 2 |
D - Esportazione cliente singolo Eseguire l'esportazione del solo cliente passato in input in SWA005-CLI, come viene fatto nel punto C, ma senza aggiornare la tabella di sincronizzazione
Keyword index No index entries found.
Esempi operativi sincronizzazione con e-commerce¶
Vedi anche Sincronizzazione ordini Il processo di sincronizzazione tra gestionale ed e/commerce coinvolge 3 diverse tipologie di tabelle: * le tabelle di AREA (es. COGGEANA) * le tabelle del database intermedio su postgres (ad esempio ARPANAGR) * le tabelle del database di e-commerce Per meglio gestire l'interscambio dati, che potrebbe essere bidirezionale viene aggiunta la tabella ARPCLIECOM, che contiene il raccordo tra i clienti del gestionale e gli utenti dell'ecommerce. Inoltre aggiungiamo un flag su ARPANAGR: * RANA_AGG_AREA: * "A": Aggiornato da Area (anche se viene aggiornata una destinazione diversa) * " ": Non aggiornato * RANA_AGG_ECOM: * "A": Aggiornato da e-commerce * " ": Non aggiornato Simuliamo i vari casi che potrebbero succedere. Attivazione e-commerce In questo caso avremo clienti solo sul gestionale, che devono essere esportati su postgres, quindi dopo l'esportazione si avra':
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
dopo il passaggio del demone di aggiornamento e-commerce avremo:
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
Registrazione di un cliente su e-commerce Tramite un demone, o in tempo reale, il nuovo cliente viene memorizzato su ARPCLIECOM:
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
Viene eseguito il prg di sincronizzazione con AREA: 1) Crea il nuovo cliente sul gestionale
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
| C00003 | F.LLI GIALLI | |
| C00004 | BIANCHI BRUNO |
17/12/2018: da oggi questo avviene solo in presenza di almeno un ordine già presente su ARPORTES 2) esporta il cliente e i nuovi clienti nel frattempo registrati sul gestionale
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
| C00003 | F.LLI GIALLI | C00003 |
| C00004 | BIANCHI BRUNO | C00004 |
3) viene eseguito il demone di aggiornamento con e-commerce
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
| C00003 | F.LLI GIALLI | C00003 |
| C00004 | BIANCHI BRUNO | C00004 |
Modifica dati cliente su gestionale Viene eseguito il prg di sincronizzazione con AREA, che esporta gli aggiornamenti (potrebbe essere la ragione sociale come un altro dato interessante per l'ecommerce)
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
| C00003 | F.LLI GIALLI S.R.L. | C00003 |
| C00004 | BIANCHI BRUNO | C00004 |
Quando viene eseguito il demone e-commerce, importa le modifiche anagrafiche e azzera il flag di aggiornamento
| COGGEANA | ARPANAGR | ARPCLIECOM |
|---|---|---|
| ANA-CHIA | ANA-NOME | RANA_CODANA |
| C00001 | ROSSI MARIO | C00001 |
| C00002 | VERDI GIUSEPPE | C00002 |
| C00003 | F.LLI GIALLI S.R.L. | C00003 |
| C00004 | BIANCHI BRUNO | C00004 |
Acquisizione nuovo cliente da APP e contestuale creazione ordine¶
Spostare nelle procedure interne Questa procedura completa e integra il documento Esempi operativi sincronizzazione con e-commerce Questo sistema di sincronizzazione deve tenere conto dei seguenti aspetti: 1. L'inserimento nuovo cliente su APP potrà contenere una o più informazioni customizzate specifiche per l'azienda, che saranno memorizzate, relativamente al codice A_CLIECOM_ID_UTENTE, sulla tabella ARPSKDATI: le informazioni sono quelle contenute in una pagina configurata in 2. L'acquisizione su Area dovrà quindi acquisire queste informazioni, memorizzarle sulla scheda CRM collegata al nuovo cliente appena acquisito; dopodichè dovrà cancellarle e riesportarle collegate al nominativo corretto 3. Se l'azienda è standard, il giro si ferma su Area; altrimenti (vedi Pieri, Vimercati), si dovrà effettuare completare il giro verso il db frontiera: 1. Esportazione del nuovo cliente su una tabella apposita (non cliente) 2. Tenere conto che l'ordine si appoggia ad un cliente che esiste solo su Area e non ancora sul db frontiera nè sul gestionale Host 3. Il gestionale host acquisirà l'ordine, il nuovo cliente, e dovrà effettuare le attività necessarie per creare il nuovo cliente e associare l'ordine ad esso 4. Il nuovo cliente dovrà essere esportato collegato al nuovo cliente area, in modo da non creare un duplicato (a tal scopo forse, sulla tabella nuovi clienti, prevedere un raccordo) A tal scopo è importante similare il flusso dati previsto
A - Nuovo cliente e ordine - Fino ad AREA¶
A - Nuovo cliente e ordine - Fino ad Area A.1 - Registrazione di un cliente su e-commerce Tramite un demone, o in tempo reale, il nuovo cliente viene memorizzato su ARPCLIECOM. Contemporaneamente viene anche effettuato un ordine, intestato al nuovo cliente (in quel momento ancora conosciuto solo con il codice utente) A.1 - Dati cliente
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
nb: nella tabella ARPSKDATI sono presenti tanti record quante sono le informazioni "variabili" configurate sulla pagina informazioni A.1 - Dati ordine
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | |
|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE |
| APP: inserimento ordine su dispositivo con ID 50, con ID ordine interno = 150 | ||||
| Un utente crea un ordine su APP | ||||
| La APP salva l'ordine su KPN | Cxxxxx | 2 | 3 |
A.2 - Acquisizione da parte del gestionale Tramite i programmi specifici: SWA029, SWA030/SWA031, i dati vengono acquisiti e validati. Ci potrebbero essere 2 casi, in base a quale programma viene innescato per primo: * Viene innescato prima l'importazione ordini SWA029: il programma si accorge che l'ordine è collegato ad un cliente nuovo (A-CLCOM-CLIENTE = " "), quindi prima di proseguire innesca SWA030 * Viene innescato prima l'esportazione clienti, SWA031: durante il processo viene innescato SWA030 che acquisisce i clienti nuovi; quindi l'importazione ordini trova già l'utente collegato A.2 - Dati cliente Il cliente viene acquisito su Area, e successivamente riesportato e raccordato con il nuovo cliente Contestualmente i dati variabili vengono acquisiti nella sezione "CRM", e rimossi da ARPSKDATI
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO |
Poi nella stessa sessione i dati vengono riesportati (SWA029)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO |
Successivamente quando verrà schedulato SWA013 avviene la sincronizzazione della parte CRM (non fondamentale per questo scopo)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO |
A.2 - Dati ordine
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | |
|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE |
| APP: inserimento ordine su dispositivo con ID 50, con ID ordine interno = 150 | ||||
| Un utente crea un ordine su APP | ||||
| La APP salva l'ordine su KPN | Cxxxxx | 2 | 3 | |
| SWA029: L'ordine viene acquisito dal gestionale: creazione ordine | Cxxxxx | 2 | 3 | |
| SWA029: aggiornamento KPN | Cxxxxx | 2 | C20190000012 | 3 |
B - Nuovo cliente e ordine - Fino a DBF¶
B - Nuovo cliente e ordine - Fino a DBF B.1 - Registrazione di un cliente su e-commerce Tramite un demone, o in tempo reale, il nuovo cliente viene memorizzato su ARPCLIECOM. Contemporaneamente viene anche effettuato un ordine, intestato al nuovo cliente (in quel momento ancora conosciuto solo con il codice utente) B.1 - Dati cliente
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| 3 |
nb: nella tabella ARPSKDATI sono presenti tanti record quante sono le informazioni "variabili" configurate sulla pagina informazioni B.1 - Dati ordine
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |
|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT |
| Un utente crea un ordine su APP | |||||
| La APP salva l'ordine su KPN | Cxxxxx | 2 | 3 |
B.2 - Acquisizione da parte del gestionale Tramite i programmi specifici: SWA029, SWA030/SWA031, i dati vengono acquisiti e validati. Ci potrebbero essere 2 casi, in base a quale programma viene innescato per primo: * Viene innescato prima l'importazione ordini SWA029: il programma si accorge che l'ordine è collegato ad un cliente nuovo (A-CLCOM-CLIENTE = " "), quindi prima di proseguire innesca SWA030 * Viene innescato prima l'esportazione clienti, SWA031: durante il processo viene innescato SWA030 che acquisisce i clienti nuovi; quindi l'importazione ordini trova già l'utente collegato B.2 - Dati cliente Il cliente viene acquisito su Area, e successivamente riesportato e raccordato con il nuovo cliente Contestualmente i dati variabili vengono acquisiti nella sezione "CRM", e rimossi da ARPSKDATI
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | 3 |
Poi nella stessa sessione i dati vengono riesportati (SWA029)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO | 3 |
Successivamente quando verrà schedulato SWA013 avviene la sincronizzazione della parte CRM (non fondamentale per questo scopo)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO | 3 |
B.2 - Dati ordine
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |||
|---|---|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT | ID | |
| Un utente crea un ordine su APP | |||||||
| La APP salva l'ordine su KPN | Cxxxxx | 2 | 3 | 150 | |||
| SWA029: L'ordine viene acquisito dal gestionale: creazione ordine | Cxxxxx | 2 | 3 | 150 | |||
| SWA029: aggiornamento KPN | Cxxxxx | 2 | C20190000012 | 3 | C00004 | 150 |
B.3 - Esportazione dati su DBF In questa fase il sistema si accorge che l'ordine da esportare è relativo ad un cliente per il quale non esiste ancora il codice HOST. Quindi, diamo per scontato che questo possa succedere solo nel caso di acquisizione nuovo cliente Diamo per scontato anche che in sequenza venga esportato prima il nuovo cliente, e quindi l'ordine (in caso contrario il prg di esportazione ordini impedirà l'esportazione, che avverrà con il giro successivo) B.3 - Dati cliente Il cliente viene esportato su DFNUOVICLIENTI tramite DBF101 In questa fase il cliente non esiste su DFANAGR: l'esportazione avverrà rilevando che l'ordine è collegato ad un cliente senza codice host
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO | 3 |
B.3 - Dati ordine L'ordine viene esportato su DFDOCTES tramite DBF101
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |||
|---|---|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT | ID | |
| DBF101: L'ordine viene esportato | Cxxxxx | 2 | C20190000012 | 3 | C00004 | 150 |
NB: Il prefisso "P:" indicato in DFDOCTES.DF-DTES-ANA-FAT-HOST indica al gestionale HOST che il cliente è provvisorio, e va acquisito da DFNUOVICLIENTI tramite DF-NOM-KEY-AREA B.4 - Aggiornamento da parte del gestionale Host In questa fase il gestionale host si accorge che l'ordine è associato ad un cliente provvisorio (P:C00004); quindi dovrà far gli aggiornamenti del caso per: 1. Acquisire il nuovo cliente da DFNUOVICLIENTI (trovato tramite DF-NOM-KEY-AREA) 2. Associare il codice cliente creato alla stessa tabella su DF-NOM-KEY-HOST) 3. Esportare il cliente su ARPANAGR 4. Acquisire l'ordine e 1. Aggiornare DF-DTES-KEY-HOST con il codice ordine generato 2. Aggiornare DF-DTES-ANA-FAT-HOST con il codice cliente nuovo generato Situazione attesa dopo l'aggiornamento B.4 - Dati cliente
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO | 3 |
NB: Ipotizzo che l'esportazione del nuovo cliente su DFANAGR non sia in grado di aggiornare anche il raccordo con il codice AREA B.4 - Dati ordine
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |||
|---|---|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT | ID | |
| Gestionale HOST: L'ordine viene aggiornato | Cxxxxx | 2 | C20190000012 | 3 | C00004 | 150 |
B.5 - Importazione dati da DBF Operazioni che si svolgono quando si acquisce da DBF un nuovo cliente, che in realtà è associato ad uno provvisorio B.5 - Dati cliente DBF001: in presenza di cliente senza DF-ANA-KEY-AREA, prima di codificarne uno nuovo dovrà verificare se esiste lo stesso su DFNUOVICLIENTI, tramite la relazione DF-NOM-KEY-HOST = DF-ANA-KEY-HOST, quindi: 1. Aggiorna COGGEANA.ANA-CODICE-HOST 2. Aggiorna DFANAGR.DF-ANA-KEY-AREA
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | CXYZ | C00004 | BIANCHI BRUNO | 3 |
B.5 - Dati ordine I dati ordine rimangono invariati: tutti i collegamenti sono già presenti
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |||
|---|---|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT | ID | |
| Gestionale HOST: L'ordine viene aggiornato | Cxxxxx | 2 | C20190000012 | 3 | C00004 | 150 |
B.6 - Esportazione su KPN A questo punto l'esportazione su KPN dovrà aggiornare sul db web la relazione tra il codice cliente AREA e il codice cliente HOST, in modo che l'APP possa effettuare in locale l'associazione, quando troverà il nuovo cliente. B.6 - Dati cliente SWA031: non fa nulla di nuovo perchè aggiornerà l'anagrafica esportando anche il codice host
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ | DFANAGR.DF-ANA- | DFNUOVICLIENTI.DF-NOM- |
|---|---|---|---|---|---|---|
| CHIA | NOME | CODICE-HOST | CODANA | NOME | CODICE-HOST | ID-UTENTE |
| C00004 | BIANCHI BRUNO | CXYZ | C00004 | BIANCHI BRUNO | CXYZ | 3 |
B.6 - Dati ordine I dati ordine rimangono invariati: tutti i collegamenti sono già presenti
| Operazione | KPN: ARPORTES.A-ORTES- | APP | AREA: COGTESOR.TOR- | DBF: DFDOCTES.DF-DTES- | |||
|---|---|---|---|---|---|---|---|
| AZI | ID-PUB | TOR-CHIA | ID-UTENTE | CLIENTE | ID-INT | ID | |
| Gestionale HOST: L'ordine viene aggiornato | Cxxxxx | 2 | C20190000012 | 3 | C00004 | 150 |
Acquisizione nuovo cliente da APP e contestuale creazione chiamata¶
Spostare nelle procedure interne Questa procedura completa e integra il documento Esempi operativi sincronizzazione con e-commerce La logica è simile a quella già sviluppata nel documento Acquisizione nuovo cliente da APP e contestuale creazione ordine Questo sistema di sincronizzazione deve tenere conto dei seguenti aspetti: 1. L'inserimento nuovo cliente su APP potrà contenere una o più informazioni customizzate specifiche per l'azienda, che saranno memorizzate, relativamente al codice A_CLIECOM_ID_UTENTE, sulla tabella ARPSKDATI: le informazioni sono quelle contenute in una pagina configurata in 2. L'acquisizione su Area dovrà quindi acquisire queste informazioni, memorizzarle sulla scheda CRM collegata al nuovo cliente appena acquisito; dopodichè dovrà cancellarle e riesportarle collegate al nominativo corretto 3. Se l'azienda è standard, il giro si ferma su Area.
A - Nuovo cliente e chiamata - Fino ad AREA¶
A - Nuovo cliente e chiamata - Fino ad Area A.1 - Registrazione di un cliente su APP Tramite un demone, il nuovo cliente viene memorizzato su ARPCLIECOM. Contemporaneamente viene anche inserita una chiamata intestata al nuovo cliente (in quel momento ancora conosciuto solo con il codice utente) A.1 - Dati cliente
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
nb: nella tabella ARPSKDATI sono presenti tanti record quante sono le informazioni "variabili" configurate sulla pagina informazioni A.1 - Dati chiamata
| Operazione | KPN: ARPINTES.RCIT- | AREA: ARPINTES.ACIT- | |
|---|---|---|---|
| AZI | ID-INTERVENTO | ID-UTENTE | ANA |
| APP: inserimento ordine su dispositivo con ID 50, con ID ordine interno = 150 | |||
| Un utente crea un ordine su APP | |||
| La APP salva l'ordine su KPN | Cxxxxx | 201 | 3 |
A.2 - Acquisizione da parte del gestionale Tramite i programmi specifici: SWA005, SWA030/SWA031, i dati vengono acquisiti e validati. Ci potrebbero essere 2 casi, in base a quale programma viene innescato per primo: * Viene innescato prima l'importazione interventi SWA005: * il programma si accorge che l'ordine è collegato ad un cliente nuovo (RCIT-ANA = ' ', RCIT-NOM-ASS = 0, RCIT-ID-UTENTE <> " "), quindi prima di proseguire: * Cerca il contenuto di ARPCLIECOM per RCIT-ID-UTENTE; * se A-CLCOM-CLIENTE = " ": Innesca SWA030 per l'acquisizione del cliente, e lo rilegge * Modifica RCIT-ANA = A-CLCOM-CLIENTE * durante il processo viene innescato SWA030 che acquisisce i clienti nuovi; quindi l'importazione ordini trova già l'utente collegato A.2 - Dati cliente Il cliente viene acquisito su Area, e successivamente riesportato e raccordato con il nuovo cliente Contestualmente i dati variabili vengono acquisiti nella sezione "CRM", e rimossi da ARPSKDATI
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO |
Poi nella stessa sessione i dati vengono riesportati (SWA029)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO |
Successivamente quando verrà schedulato SWA013 avviene la sincronizzazione della parte CRM (non fondamentale per questo scopo)
| COGGEANA.ANA- | ARPANAGR.RANA_ | ARPCLIECOM.A_CLCOM_ | APCRMANAGR.A_CRA_ | ARPSKDATI.A_SKDI_ |
|---|---|---|---|---|
| CHIA | NOME | CODANA | NOME | AGG_AREA |
| C00004 | BIANCHI BRUNO | C00004 | BIANCHI BRUNO |
A
Estratto da documentazione interna ClickUp