SWN035 - Contratti: tariffe¶
Nome programma SWN035 Linkage section UTILAGPRG - Linkage comune Id processo: 38 Nome processo: CONTRATTI-TAR Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| ASNCNTAR | ARPCNTAR | ------> |
Logica generale Sincronizzazione della testata contratti. Esportazione Esportazione di tutti gli elementi effettivamente modificati (con dati variati). Importazione Le applicazioni WEB potranno inserire, modificare o cancellare logicamente nuovi elementi Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online |
Elaborazione Tipi di segnalazione: Vedi Tipi di segnalazione A - Controllo di esecuzione Vedi Controllo di esecuzione A.1 - Aggiornamento KEEP-ALIVE Per il momento non lo eseguiamo: il keep-alive viene tenuto aggiornato dal thread autonomo di aglancio; se il programma venisse chiamato in "tempo reale" dal programma di gestione, non necessita comunque del keep-alive. A.2 - Apertura A.2.1 Apertura tabelle Tentare l'apertura della tabella da sincronizzare: ARPCNTAR Se fallita inviare una Segnalazione critica e chiudere. B - Esportazione elementi aggiornati * ID SINCRO: gestito * Esportazione differenziale: gestita ma non ottimizzata: non esiste una chiave diretta per ottenere solo i record aggiornati * Cancellazione logica: non gestita In questa fase si dovrà tenere conto di * Limite record * Limite errori * "Esporta tutto" B.1 - Stato sincronizzazione Sulla tabella APSTATOSYN, leggere il record relativo alla tabella/oggetto da sincronizzare "ARPCNTAR"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPCNTAR" |
| A_SYN_DA_GES_DATA | 0 |
| A_SYN_DA_GES_ORA | 0 |
| A_SYN_DA_ID_SINCRO | 1 |
Qui otterremo due informazioni importanti: * Data/ora ultima esportazione da gestionale a postgres (A_SYN_DA_GES_DATA e A_SY_DA_GES_ORA) * Prossimo ID sincronizzazione da memorizzare sulla tabella (A_SYN_ID_SINCRO) B.2 - Ricerca record da esportare B.2.1 Ricerca record da esportare
| Tipo di elaborazione | Condizione | Cosa fare |
|---|---|---|
| Singolo record | AGPRG-KEY <> " " (conterrà ACNR-CHIA1) | Si legge direttamente il record da aggiornare su ASNCNTAR Verrà eseguita se agg-postgres-online è attiva Se viene sincronizzato un record cancellato, verrà effettuata la cancellazione logica |
| Esportazione contratto | conterrà ACNR-CHIA1 |
Simile all'esportazione standard, ma in questo caso verranno esportati tutti i record collegati al contratto passato Verrà eseguita se agg-postgres-online è attiva |
| Esportazione totale | AGPRG-ESPORTA-TUTTO = "S" | Si scorrono tutti i record di ASNCNTAR; ogni record va considerato, ignorando il controllo sulla variazione dei record |
| Esportazione standard | Si scorrono tutti i record di ASNCNTAR; ciascuno dovrà essere esaminato | |
| Pulizia | AGPRG-OPE = "PULIZIA" | Eseguire solo il giro di cancellazione logica B.3 quindi uscire |
B.2.1.1 Filtri Pertinenza "contratto" ASNCNTAR potrebbe contenere anche record di tariffa collegati ai modelli di contratto: questo dobbiamo scartarli perchè non fanno parte di un contratto. Quindi, verranno considerati solo i record dove * ACNR-PERTINENZA = "C" Qta usata In questo programma, se la tariffa ha una quantità prevista (ACNR-QTA > 0), è necessario esportare anche la qta usata; di conseguenza non possiamo effettuare il filtro sulla data aggiornamento, perchè rischiamo di escludere l'aggiornamento di tariffe dove è modificata solo la qta usata -> non c'è un campo specifico su ASNCNTAR e viene calcolato in tempo reale.
La ricerca della qta usata viene effettuata tramite una chiamata a ASNS03, che potenzialmente potrebbe essere molto lenta. Quindi per ottimizzare i tempo cerco di diminuire i record su cui fare la chiamata. Quindi, in questo caso considero solo i record: * Relativi a contratti aperti (ACNT-FL-CHIUSO <> "C") * Righe con ACNR-QTA > 0 * Qualunque data/ora aggiornamento B.2.1.2 Record collegati Per ciascun record valido si cercano tutti i record collegati: Nessuno B.2.2 Verifica ed esportazione record Dopodichè si effettua la ricerca dell'informazione su ARPCNTAR
| Dato | Contenuto |
|---|---|
| A-CNR-AZI | Codice azienda |
| A-CNR-ID-CONTRATTO | ACNR-ID-CONTRATTO |
| A-CNR-PROG | ACNR-PROG |
Se non esiste, inserirlo. Se esiste, aggiornarlo l'aggiornamento del record deve avvenire solo se almeno un dato tra quelli da modificare è diverso. NB: se è stata richiesta l'esportazione completa (AGPRG-ESPORTA-TUTTO = "S") allora il record dovrà essere esportato a prescindere dal confronto Suggerimento Invece di popolare direttamente i dati del record di destinazione, portarli su delle copie in w/s. Al termine confrontare i dati sulla destinazione con la copia in w/s. Aggiornamento da ASNCNTAR NB: se a questo punto A-CNR-FL-AGG vale "A", significa che nel lasso di tempo tra la fase di importazione e questa, qualcuno ha aggiornato il record su APP: quindi segnalare sul log e ignorare l'esportazione.
| Dato | Contenuto | Confronto? |
|---|---|---|
| A-CNR-AZI | Codice azienda | |
| A-CNR-ID | ACNR-ID-CONTRATTO | |
| A-CNR-PROG | ACNR-PROG | |
| A-CNR-MERCE | ACNR-MERCE | Si |
| A-CNR-QTA | ACNR-QTA | Si |
| A-CNR-QTA-USATA | Se ACNR-QTA: >0 : Cercare la quantità consumata tramite una chiamata a ASNS03, che restituirà ASNS03-O-QTA-RES; quindi: |
Si |
| A-CNR-PREZZO | ACNR-PREZZO | Si |
| A-CNR-SCO-1 | ACNR-SCO-1 | Si |
| A-CNR-SCO-2 | ACNR-SCO-2 | Si |
| A-CNR-FL-SERVIZIO | ACNR-FL-SERVIZIO | Si |
| A-CNR-FL-CANC | " " | Si |
| A-CNR-ID-SINCRO | Prossimo id sincro | |
| A-CNR-FL-AGG | " " |
In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. Per tutti i campi alfanumerici significativi (non flag, non valori fissi) effettuare il parsing tramite GESSTR, come già fatto negli altri programmi di sincronizzazione B.2.3 Verifica record cancellati A cambio di id contratto aggiornato, dovrei anche verificare che non ci siano righe cancellate da ASNCNTAR per il contratto in elaborazione. Questo sarebbe importante farlo ora per evitare di avere contratti aggiornati in modo parziale (ho esportato le righe aggiornate, ma non ho rimosso le righe cancellate) Provo a implementare questo giro come il giro B.3 ma aggiungendo la clausola WHERE per il contratto: essendo in chiave primaria dovrebbe rendere la SELECT abbastanza efficiente. In questo modo è utilizzabile direttamente anche nel giro "ESP-CONTRATTO". Se questo rende l'elaborazione pesante, si potrebbe aggiungere direttamente il giro "B.3" una sola volta al termine dell'esportazione. Attenzione L'elaborazione verrà effettuata al termine del giro di esportazione, usando un file di transito che contiene l'elenco dei contratti aggiornati. Questo perchè la rilettura di record di ARPCNTAR durante il giro di esportazione sballa il puntatore e manda in loop il programma. B.3 Verifica record cancellati Sulla tabella di origine ASNCNTAR non esiste il flag di cancellazione logica. Quindi si opererà come segue: 1. Scorrere tutti i record di ARPCNTAR per l'azienda 2. Ricerca, per ciascuno, del corrispondente record su ASNCNTAR A questo punto la situazione potrebbe essere la seguente:
| ASNCNTAR trovato? | A-CNR-FL-CANC | Cosa fare |
|---|---|---|
| Si | "C" | Aggiornare ARPCNTAR impostando |
| Si | " " | Nessuna operazione |
| No | "C" | Nessuna operazione |
| No | " " | Aggiornare ARPCNTAR impostando |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPCNTAR" |
| A_SYN_DA_GES_DATA | Data/ora dell'ultimo record aggiornato |
| A_SYN_DA_GES_ORA | |
| A_SYN_DA_ID_SINCRO | Ultimo id sincro + 1 |
| A_SYN_VERSIONE | 2 |
Estratto da documentazione interna ClickUp