SWN113 - Esportazione backorder¶
Nome programma SWN113 Linkage section UTILAGPRG - Linkage comune Id processo: 113 Nome processo: BACKORDER Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| COGBKORD | ARPBACKORDER | ------> |
Logica generale Esportazione del backorder Esportazione Esportazione di tutti i record effettivamente modificati (con dati variati). Importazione Non prevista NB: in fase di acquisizione su KPN di un backorder aggiornato (una coppia merce/cliente), si dovrà anche effettuare la cancellazione (logica) del record che lo annulla: ARPBACKORDERVAR, se esistente, altrimenti su APP il nuovo backorder non verrà considerato. 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: ARPBACKORDER Se fallita inviare una Segnalazione critica e chiudere. B - Esportazione informazioni aggiornate * ID SINCRO: gestito * Esportazione differenziale: gestita e ottimizzata * Cancellazione logica: 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 "COGBKORD"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "COGBKORD" |
| A_SYN_DA_GES_DATA | 0 |
| A_SYN_DA_GES_ORA | 0 |
| A_SYN_DA_ID_SINCRO | 1 |
| A-SYN-VERSIONE | 2 |
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 <> " " | Si legge direttamente il record da aggiornare su COGBKORD Verrà eseguita se agg-postgres-online è attiva Se viene sincronizzato un record cancellato, verrà effettuata la cancellazione logica |
| Esportazione totale | AGPRG-ESPORTA-TUTTO = "S" | Si scorrono tutti i record di COGBKORD; ogni record va considerato |
| Esportazione standard | Si scorrono tutti i record di COGBKORD, usando la chiave BKO-CHIA3, partendo da A-SYN-DA-GES-DATA+A-SYN-DA-GES-ORA | |
| Pulizia | AGPRG-OPE = "PULIZIA" | Non prevista |
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 ARPBACKORDER
| Dato | Descrizione |
|---|---|
| A-BKO-AZIENDA | Codice azienda |
| A-BKO-ANA | BKO-ANA |
| A-BKO-DST-TIP | BKO-DST-TIP |
| A-BKO-DST-IDX | BKO-DST-IDX |
| A-BKO-MERCE | BKO-MERCE |
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 COGBKORD
| Dato | Contenuto | Confronto? |
|---|---|---|
| A-BKO-AZIENDA | Codice azienda | |
| A-BKO-ANA | BKO-ANA | |
| A-BKO-DST-TIP | BKO-DST-TIP | |
| A-BKO-DST-IDX | BKO-DST-IDX | |
| A-BKO-MERCE | BKO-MERCE | |
| A-BKO-QTA | BKO-QTA | Si |
| A-BKO-ULTIMO-ORDINE | BKO-ULTIMO-ORDINE | Si |
| A-BKO-UO-RIGA | BKO-UO-RIGA | Si |
| A-BKO-NOTE | BKO-NOTE | Si |
| A-BKO-FL-CANC | BKO-FL-CANC | Si |
| A-BKO-ID-SINCRO | Id sincro + 1 |
(*) Questi campi dovranno essere parsati con GESSTR prima del confronto In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. B.2.3 Annullamento ARPBACKORDERVAR Se il record è stato aggiornato è necessario verificare l'esistenza di un eventuale record di annullamento precedente, e cancellarlo logicamente; effettuare quindi una ricerca su ARPBACKORDERVAR:
| Dato | Contenuto |
|---|---|
| A-BKOV-AZIENDA | Codice azienda |
| A-BKOV-ANA | BKO-ANA |
| A-BKOV-DST-TIP | BKO-DST-ID-TIP |
| A-BKOV-DST-IDX | BKO-DST-ID-IDX |
| A-BKOV-MERCE | BKO-MERCE |
Se il record esiste, aggiornare effettuando la cancellazione logica:
| Dato | Contenuto |
|---|---|
| A-BKOV-FL-CANC | "C" |
| A-BKOV-AGG-APP | "A" (in modo che possa essere riacquisito all'indietro) |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A-SYN-AZIENDA | Codice azienda |
| A-SYN-TABELLA | "COGBKORD" |
| 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