SWN137 - Esportazione delle tabelle CMA¶
Nome programma SWN137 Linkage section UTILAGPRG - Linkage comune Id processo: 137 Nome processo: TABELLECMA Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| COGTABEL (62) | ARPTABELLECMA | ------> |
Logica generale Sincronizzazione tabelle CMA Esportazione Esportazione tabelle CMA. Importazione Non prevista 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: ARPTABELLECMA. 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 "ARPTABELLECMA"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPTABELLECMA" |
| 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 <> " " (conterrà EUTA-KEY) |
Si legge direttamente il record da aggiornare su COGTABEL 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 COGTABEL di tipo EUTA-TIPO 62; ogni record va considerato, ignorando il controllo sulla variazione dei record |
| Esportazione standard | Si scorrono tutti i record di COGTABEL; non si effettua un controllo su data aggiornaento poichè non c'è su COGTABEL | |
| Pulizia | AGPRG-OPE = "PULIZIA" | Eseguire solo il giro di cancellazione logica B.3 quindi uscire |
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 ARPTABELLECMA
| Dato | Contenuto |
|---|---|
| a-ptc-azi | Codice azienda |
| a-ptc-tip a-ptc-cod | euta-ptc-tip euta-ptc-cod |
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 COGTABEL NB: se a questo punto A-PTC-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-ptc-azienda | Codice azienda | |
| a-ptc-tip a-ptc-cod | euta-ptc-tip euta-ptc-cod | |
| a-ptc-des | euta-tma-des (*) | Si |
| a-ptc-FL-CANC | " " | Si |
| a-ptc-ID-SINCRO | Prossimo id sincro | |
| a-ptc-FL-AGG | " " |
(*) Questi campi devono essere parsati da GESSTR con operazione "CONV-TESTO-X-ESPORT" prima di effettuare il confronto In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. B.3 Verifica record cancellati Sulla tabella di origine COGTABEL non esiste il flag di cancellazione logica. Quindi si opererà come segue: 1. Scorrere tutti i record di ARPTABELLECMA per l'azienda 2. Ricerca, per ciascuno, del corrispondente record su COGTABEL A questo punto la situazione potrebbe essere la seguente:
| COGTABEL trovato? | A-PTC-FL-CANC | Cosa fare |
|---|---|---|
| Si | "C" | Aggiornare ARPTABELLECMA impostando |
| Si | " " | Nessuna operazione |
| No | "C" | Nessuna operazione |
| No | " " | Aggiornare ARPTABELLECMA impostando |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPTABELLECMA" |
| 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 |
DFN010 - Importazione giacenze da DB frontiera¶
Nome programma DFN010 Linkage section UTILAGPRG - Linkage comune Id processo: 51010 Nome processo:DFN010 Tabelle principali gestite
| AREA | DB FRONTIERA | Direzione |
|---|---|---|
| COGSLMAG | DFGIACENZE | <------ |
Logica generale Sincronizzazione delle giacenze di magazzino tra AREA e il DB frontiera. Per il momento funziona solo in IMPORT Magazzini secondari Per il momento l'importazione giacenze è prevista solo per i magazzini principali. Il programma pero' se non trova il collegamento con un magazzino principale, cercherà se il magazzino da importare è collegato con un magazzino secondario: in questo caso la riga verrà marcata come importata senza dare segnalazioni, ma non effettuerà - per ora - nessuna importazione NOTA operativa/funzionale La sincronizzazione delle giacenze potrebbe provocare delle incongruenze: in primo luogo, se si decide di non importare anche i movimenti di magazzino dall'HOST che la determinano. In secondo luogo, a seconda dei tempi di aggiornamento. Se importo una giacenza immediatamente dopo che su AREA è stato effettuato un movimento, la giacenza attesa su AREA potrebbe non essere corretta. Questo finchè non si effettua il seguente procedimento: 1. Esportazione movimento AREA->DB frontiera 2. Importazione movimento DB frontiera -> HOST e conseguente aggiornamento della giacenza 3. Esportazione giacenza HOST -> DB frontiera 4. Importazione giacenza DB frontiera -> AREA Si potrebbe pensare, se questo crea disfunzioni, di studiare un metodo che impedisce l'aggiornamento a seconda della data e ora di aggiornamento su AREA e sul DB frontiera, ma potrebbe risultare difficoltoso e comunque non risolvere il problema. Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| dbfront | sincro-attiva | |
| dbfront | email-segnalazioni | |
| dbfront | db-tipo | |
| dbfront | db-conn-string | |
| dbfront | db-log-level |
Elaborazione
| Operazione | Descrizione |
|---|---|
| " " | Elaborazione standard: Importa i record aggiornati dal db host. |
| "PULIZIA" | Controllo approfondito dati importati In questa modalità si esegue come prima cosa l'elaborazione standard. Poi si scorre tutto il contenuto delle giacenze su AREA, e per ciascun record non più presente su DBF lo cancella su AREA |
Tipi di segnalazione: Vedi Tipi di segnalazione A - Controllo di esecuzione Vedi Controllo di esecuzione B - Apertura B.1 Apertura tabelle Tentare l'apertura della tabella da sincronizzare: DFGIACENZE. Se fallita inviare una Segnalazione grave e chiudere. Tentare l'apertura della tabella semaforo: DFSEMAFORO. Se fallita inviare una Segnalazione grave e chiudere. B.2 Blocco semaforo Lettura del record DFSEMAFORO:
| Nome campo | Note |
|---|---|
| DF_SMF_TABELLA | DFGIACENZE |
Se il record non esiste inserirlo. Se risulta bloccato dal gestonale host (DF_SMF_USO_HOST = 1) Informazione sul log e chiudere. Dopodichè aggiornare il semaforo impostando:
| Nome campo | Note |
|---|---|
| DF_SMF_USO_AREA | 1 |
| DF_SMF_VERSIONE | Versione attuale: 1 |
B.3 Aggiornamento stato Aggiornamento dello stato sul record specifico; in particolare:
| Dato | Contenuto |
|---|---|
| DBFST-STATO | "I" |
| DBFST-ATT-DATA | Data sistema |
| DBFST-ATT-ORA | Ora sistema |
| DBFST-SCHED-DATA | Sommare il tempo di attesa a data/ora sistema |
| DBFST-SCHED-ORA | |
| DBFST-ERRORI | 0 |
| DBFST-MSG-ERRORE | " " |
| DBFST-LOG-PROCEDURA | " " |
C - Sincronizzazione (Importazione) C.1 Selezione record da importare Tramite un comando SQL specifico, estrazione di tutti i record aggiornati dall'HOST: SELECT * FROM DFGIACENZE WHERE DF_GIA_AGG_HOST = 1 C.2 Controllo record Per ciascun record letto, verificare la correttezza delle informazioni contenute NB: per ottimizzare i tempi di elaborazione, precaricare in tabella di working l'elenco dei magazzini. Controllo DF_GIA_MAG_HOST Questa informazione deve essere significativa, altrimenti segnalare Errore . 1. Si dovrà cercare su COGMAGAG se esiste già un magazzino con MAGG-CODICE-HOST = DF_GIA_MAG_HOST. Se non esiste: 2. Si dovrà cercare su COGMAGPE se esiste un magazzino secondario con MGP-CODICE-HOST = DF_GIA_MAG_HOST. Se non esiste: 3. Segnalare Errore : "DF_GIA_MAG_HOST : magazzino non collegato ad un magazzino di area" Se esiste ed è collegato ad un magazzino interno, sarà quello su cui aggiornare la giacenza. Se esiste ed è collegato ad un magazzino secondario, marcare il record come importato, ma non fare nulla e non dare segnalazioni. Controllo DF_GIA_MPR_HOST questa informazione contiene il codice merce avanzato di una merce (che corrisponde al codice articolo HOST) su cui impostare lo sconto. Quindi, cercare su COGRACMC; se non esiste segnalare Errore "DF_GIA_MPR_HOST; merce non esistente" C.3 Importazione record Se tutti i controlli sono superati, proseguire con l'inserimento/variazione della giacenza. Ricerca su COGSLMAG:
| Nome campo | Contenuto |
|---|---|
| MSAL-MAG1 | Il magazzino collegato a DF_GIA_MAG_HOST |
| MSAL-MERCE | Il codice merce collegato a DF_GIA_MPR_HOST |
Se il record non esiste inserirlo. Dopodichè, aggiornare la quantità giacenza, ma solo se diversa da quella già presente, per minimizzare la successiva esportazione verso WEB:
| Nome campo | Contenuto |
|---|---|
| MSAL-QTA | DF_GIA_QTA_GIA |
| MSAL-FL-AGG | "S" |
C.4 Aggiornamento stato record Aggiornare il record DFGIACENZE impostando:
| Nome campo | Contenuto |
|---|---|
| DF_GIA_AGG_HOST | 0 |
| DF_GIA_AGG_AREA | 0 |
D - Sincronizzazione (esportazione) Fase non prevista in questo programma E - Chiusura E.1 Rilascio semaforo Aggiornare il record semaforo relativo a DFGIACENZE, impostando
| Nome campo | Note |
|---|---|
| DF_SMF_USO_AREA | 0 |
E.2 Chiusura tabelle Chiudere le tabella DFGIACENZE e DFSEMAFORO E.3 Aggiornamento stato Aggiornamento dello stato sul record specifico; in particolare:
| Dato | Contenuto |
|---|---|
| DBFST-STATO | "A" |
| DBFST-ERRORI | Numero di errori rilevati |
| DBFST-MSG-ERRORE | Ultimo errore rilevato |
| DBFST-LOG-PROCEDURA | Codice procedura di gestione log |
F - Cancellazione logica record non presenti (Operazione "PULIZIA") F.1 Blocco semaforo Lettura del record DFSEMAFORO:
| Nome campo | Note |
|---|---|
| DF-SMF-TABELLA | DFGIACENZE |
Se il record non esiste inserirlo. Se risulta bloccato dal gestonale host (DF-SMF-USO-HOST = 1) segnalare sul log e chiudere. Dopodichè aggiornare il semaforo impostando:
| Nome campo | Note |
|---|---|
| DF-SMF-USO-AREA | 1 |
F.2 Elaborazione Scorrere COGSLMAG. Per ciascuna riga presente fare una ricerca su DFGIACENZE, usando la chiave primaria:
| Nome campo | Contenuto |
|---|---|
| DF-GIA-MAG-HOST | Codice magazzino host di MSAL-MAG1 (trovato su COGMAGAG.MAGG-CODICE-HOST) |
| DF-MPR-KEY-HOST | Il codice merce avanzato di MSAL-MERCE (RCM-COD-AVA) |
Se il record non viene trovato, eliminare fisicamente il record di COGSLMAG: Al termine registrare sul log i contatori di record letti/cancellati F.3 Rilascio semaforo Lettura del record DFSEMAFORO:
| Nome campo | Note |
|---|---|
| DF-SMF-TABELLA | DFGIACENZE |
Dopodichè aggiornare il semaforo impostando:
| Nome campo | Note |
|---|---|
| DF-SMF-USO-AREA | 0 |
Altri processi schedulati¶
Qui descrivo altri processi nati per essere schedulati da AGLANCIO, anche se non direttamente correlati alla sincronizzazione.
COGT42N - Schedulazione-avvisi-n¶
Nome programma COGT42N Linkage section UTILAGPRG - Linkage comune Id processo: 30001 Nome processo:AVVISI-N Logica generale Questo programma genera degli avvisi per ciascuna commessa fatturata parzialmente, e per la quale non sono state emesse fatture entro "n" giorni Mettere nel programma la scrittura dei log di procedura sufficienti a capire lo svolgimento dell'elaborazione. 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. B - Elaborazione B.0 - Ricerca testata segnalazione Ricerca della testata segnalazione su COGSGTIP:
| Dato | Contenuto |
|---|---|
| SGC-CAT | "A" |
| SGC-COD | "N" |
Se il record esiste, e SGT-FL-ATTIVA = 'S' proseguire con l'elaborazione; altrimenti uscire segnalando nel log che l'elaborazione non è attiva. Questo record contiene anche altri dati necessari in seguito. B.0.1 - Ricerca destinatari Creare una tabella in working contenente di destinatari (elenco di operatori) Scorrere i record di COGSGDST per il tipo avviso:
| Dato | Contenuto |
|---|---|
| SGD-CAT | "A" |
| SGD-COD | "N" |
| SGD-LIV | 1 |
Ogni record trovato corrisponde ad un destinatario dell'avviso; quindi, se SGD-DST-TIP vale:
| SGD-DST-TIP | Cosa fare |
|---|---|
| "O" | SGD-DST-OPE contiene un operatore da aggiungere alla tabella (se non esiste già) |
| "G" | SGD-DST-GRP contiene un gruppo di utenti; quindi, cercare gli utenti contenuti nel gruppo, con una ricerca su PRNTGROD: Ciascun record trovato corrisponde ad un operatore; aggiungere quindi PGOD-OPE alla tabella, se non esiste già |
B.1 - Ricerca commesse Ricerca delle commesse aperte: scansione di COGTESCM via TSC-CHIA7. La commessa è valida se è a preventivo: cercare il tipo commessa su COGTABEL:
| Dato | Contenuto |
|---|---|
| EUTA-TIPO | K-EUTA-TIPO-TIPO-COMMESSA |
| EUTA-COD | TSC-TIPO |
Il record trovato deve avere EUTA-COM-FL-ECON <> "S" -> Commesse a preventivo Per "IMPERNOVO": considerare solo le commesse con TSC-RAGGR = "F" B.2 Analisi dati commessa Se la commessa è valida, effettuare una chiamata a COGUA0 :
| Dato | Contenuto |
|---|---|
| COGUA0-COMMESSA | TSC-COD |
All'uscita valutare il totalizzatore "DIFF-PREV-FATT" (restituito nella tabella COGUA0-TAB-TOTALIZZATORI) Se è > 0 proseguire B.3 Ricerca data ultima fattura Cercare tutte le fatture collegate alla commessa, con ricerca su COGRIGCM : RGC-TSC = TSC-COD Considerare quindi solo i record con RGC-TIP = 'FT'; RGC-CHIAVE conterrà la chiave fattura. Con questa cercare la testata fattura su COGFATTU. Determinare la data fattura più recente per la commessa. No, siccome il tipo "FT" non e' gestito, la data e la chiave dell' ultima fattura viene restituita da COGUA0:
- cogua0-ult-fat-data
- cogua0-ult-fat-key Calcolare la differenza tra la data odierna e la data ultima fattura, in giorni: se è > numero di giorni configurati in SGT-SOGLIA-1, allora proseguire con il punto B.4 B.4 - Creazione avviso (prendere spunto da COGT42M) B.4.1 Ricerca segnalazione per la commessa Fare una ricerca su COGSEGNA con chiave SGN-CHIA2:
| Dato | Contenuto |
|---|---|
| SGN-CAT | "A" |
| SGN-COD | "N" |
| SGN-KEY-LIV | 1 |
| SGN-KEY | TSC-COD |
Scorrere tutti i record trovati, e verificare se esiste una segnalazione ancora aperta per la commessa in esame (SGN-FL-EVA <> "S"); i casi potrebbero essere: * Non esiste -> Creazione di una nuova segnalazione * Esiste: "Refresh" segnalazione B.4.2 Creazione nuova segnalazione B.4.2.1 Testata segnalazione Cercare il primo numero libero di segnalazione, con una ricerca all'indietro su COGSEGNA. Quindi creare il record di testata:
| Dato | Contenuto |
|---|---|
| SGN-NUM | Primo numero libero |
| SGN-CAT | "A" |
| SGN-COD | "N" |
| SGN-KEY-LIV | 1 |
| SGN-KEY | TSC-COD |
| SGN-AUT-TIP | "P" |
| SGN-AUT | k-program-id |
| SGN-DATA-EMI | Data sistema |
| SGN-ORA-EMI | Ora sistema |
| SGN-OGG | Commessa non fatturata completamente: TSC-COD |
| SGN-FL-RISP | "N" |
| SGN-FL-AGG | "S" |
| SGN-FL-EVA | "N" |
B.4.2.2 Note segnalazione Inserire un record su COGSGNNT
| Dato | Contenuto |
|---|---|
| SGL-NUM | SGN-NUM |
| SGL-LEN | Lunghezza della nota creata |
| SGL-NOTE | L'ultima fattura sulla commessa è TT/AAAA/NNNNNNN del GG/MM/AAAA |
B.4.2.3 Destinatari Per ciascun operatore presente nella tabella preparata all'inizio, aggiungere un record su COGSGNDT:
| Dato | Contenuto |
|---|---|
| SGO-NUM | SGN-NUM |
| SGO-OPE | Codice operatore |
| SGO-FL-EVA | "N" |
| SGO-DATA-EVA | 0 |
| SGO-ORA-EVA | 0 |
| SGO-DATA-EMI | SGN-DATA-EMI |
| SGO-ORA-EMI | SGN-ORA-EMI |
| SGO-FL-ALLARME | "N" |
B.4.3 Refresh segnalazione esistente In questo caso una segnalazione potrebbe essere stata vista anche solo da 1 utente del gruppo, quindi non risulta ancora evasa. E' necessario quindi "riaprire la segnalazione" per tutti gli utenti interessati: Loop su COGSGNDT. impostando
| Dato | Contenuto |
|---|---|
| SGO-NUM | SGN-NUM |
Per ciascun record letto, se SGO-FL-EVA = "S", aggiornare impostando * SGO-FL-EVA = "N" * SGO-FL-VISTA = "N"
SKG002 - Ricalcolo calendario¶
Nome programma SKG002 Linkage section UTILAGPRG - Linkage comune Id processo: 30002 Nome processo: RIC-CALENDARIO Logica generale Questo processo è propedeutico a SWN123 - Giorni di non disponibilità Lo scopo è quello di ricreare il calendario aziendale e/o per operatore, con una chiamata a ASN120 Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online | |
| areaapp | arpggnondisp-giorni-ricalcolo |
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 ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Elaborazione Se la configurazione arpggnondisp-giorni-ricalcolo vale 0, non effettuare nessuna elaborazione B.1 Ricalcolo calendario Il ricalcolo del calendario viene fatto semplicemente con una una chiamata a CRM120:
| Dato | Contenuto |
|---|---|
| CRM120-CALLER | k-program-id |
| CRM120-CALLED | "CRM120" |
| CRM120-OPE | 0 |
| CRM120-DATA-MIN | Oggi |
| CRM120-DATA-MAX | Oggi + arpggnondisp-giorni-ricalcolo |
| CRM120-BATCH-MODE | "S" |
Questo ricostruisce il contenuto di CRMAGCAL per il periodo in corso.
CLR001 - Pulizia calendario CRM¶
Nome programma CLR001 Linkage section UTILAGPRG - Linkage comune Id processo: 4001 Nome processo: CLR001 Logica generale Programma che effettua la pulizia periodica delle tabelle che gestiscono l'agenda CRM: * CRMAGCAL * CRMAGASP Le informazioni riguardanti le cancellazioni effettuate verranno registrate su COGEVCLR La pulizia verrà effettuata in base al periodo identificato dalla configurazione limite-pulizia Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online | |
| cogesys | limite-pulizia |
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 ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Elaborazione Se la configurazione limite-pulizia è vuota, non effettuare nessuna elaborazione Come prima cosa effettuare una chiamata a GESDATE, operazione "TOGLI-PERIODO"
| Dato | Contenuto |
|---|---|
| GESDATE-OPE | "TOGLI-PERIODO" |
| GESDATE-DATA-IN | Data di sistema |
| GESDATE-STRING | limite-pulizia |
Questa funzione restituisce in GESDATE-DATA-OUT la data fino a cui effettuare la pulizia. Se vuota, segnalare nel log con un errore critico e uscire B.1 Ricerca operatori Entrambe le tabelle hanno in chiave primaria il codice operatore, ma non hanno una chiave diretta sulla data calendario. Scorere quindi la tabella operatori (PRNTOPER); per ciascun operatore trovato: B.1.1 Pulizia CRMAGCAL Scorrere tutti i record di CRMAGCAL per l'operatore, usando la chiave primaria:
| Dato | Contenuto |
|---|---|
| CCA-OPE | PTOP-COD |
| CCA-DATA | 0 |
Effettuare la cancellazione di tutti i record, finchè CCA-DATA < GESDATE-DATA-OUT, quindi interrompere Aumentare un contatore per tutti i record cancellati sulla tabella B.1.2 Pulizia CRMAGASP Scorrere tutti i record di CRMAGASP per l'operatore, usando ASP-CHIA2:
| Dato | Contenuto |
|---|---|
| ASP-OPE | PTOP-COD |
| ASP-DATA | 0 |
Effettuare la cancellazione di tutti i record, finchè ASP-DATA < GESDATE-DATA-OUT, quindi interrompere Aumentare un contatore per tutti i record cancellati sulla tabella B.2 Inserimento COGEVCLR Per ciascun contatore dei record cancellati, se sono > 0 inserire un record su COGEVCLR
| Dato | Contenuto |
|---|---|
| EVC-ID | Primo id disponibile |
| EVC-PRG | K-PROGRAM-ID |
| EVC-TABELLA | La tabella interessata |
| EVC-DATA | Data sistema |
| EVC-DATA-LIMITE | GESDATE-DATA-OUT |
| EVC-N-RECORD-CANC | Numero di record cancellati |
CLR003 - Pulizia listini vendita/acquisto¶
Nome programma CLR003 Linkage section UTILAGPRG - Linkage comune Id processo: 40003 Nome processo: CLR003 Logica generale Programma che effettua la pulizia periodica delle tabelle che gestiscono i listini vendita/acquisto: * COGLISNW * COGLISFO La pulizia verrà effettuata tramite chiamate a COGU67 Le informazioni riguardanti le cancellazioni effettuate verranno registrate su COGEVCLR La pulizia verrà effettuata in base al periodo identificato dalla configurazione limite-pulizia Aggiungere le informazioni principali dell'elaborazione nel log di processo Configurazioni possibili Gestire le configurazioni impostando NCNF-SUDD = 'CLR003'
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online | |
| cogesys | limite-pulizia |
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 ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Elaborazione Se la configurazione limite-pulizia è vuota, non effettuare nessuna elaborazione Come prima cosa effettuare una chiamata a GESDATE, operazione "TOGLI-PERIODO"
| Dato | Contenuto |
|---|---|
| GESDATE-OPE | "TOGLI-PERIODO" |
| GESDATE-DATA-IN | Data di sistema |
| GESDATE-STRING | limite-pulizia |
Questa funzione restituisce in GESDATE-DATA-OUT la data fino a cui effettuare la pulizia. Se vuota, segnalare nel log con un errore critico e uscire B.1 Pulizia listini clienti standard Effettuare una chiamata a COGU67
| Dato | Contenuto |
|---|---|
| COGU67-CALLED | "COGU67-CALLED" |
| COGU67-DATA-LIS | GESDATE-DATA-OUT |
| COGU67-TIP-OP | "N" |
| COGU67-COMPATTA | "S" |
| COGU67-TIP-LIS | "L" |
| COGU67-RIF-LIS | 0 |
B.2 Pulizia listini particolari clienti Effettuare una chiamata a COGU67
| Dato | Contenuto |
|---|---|
| COGU67-CALLED | "COGU67-CALLED" |
| COGU67-DATA-LIS | GESDATE-DATA-OUT |
| COGU67-TIP-OP | "N" |
| COGU67-COMPATTA | "S" |
| COGU67-TIP-LIS | "C" |
| COGU67-RIF-LIS | 0 |
B.3 Pulizia listini fornitori Effettuare una chiamata a COGU67
| Dato | Contenuto |
|---|---|
| COGU67-CALLED | "COGU67-CALLED" |
| COGU67-DATA-LIS | GESDATE-DATA-OUT |
| COGU67-TIP-OP | "N" |
| COGU67-COMPATTA | "S" |
| COGU67-TIP-LIS | "F" |
| COGU67-RIF-LIS | 0 |
B.4 Inserimento COGEVCLR Ogni chiamata a COGU67 restituità i record letti e quelli elaborati: quelli con tipo listino "C" e "L" vanno sommati. Poi per ciascun contatore dei record cancellati, se sono > 0 inserire un record su COGEVCLR
| Dato | Contenuto |
|---|---|
| EVC-ID | Primo id disponibile |
| EVC-PRG | K-PROGRAM-ID |
| EVC-TABELLA | La tabella interessata (COGLISNW/COGLISFO) |
| EVC-DATA | Data sistema |
| EVC-DATA-LIMITE | GESDATE-DATA-OUT |
| EVC-N-RECORD-CANC | Numero di record cancellati |
TGL473 - Importazione lavorazioni LVD¶
Nome programma TGL473 Linkage section UTILAGPRG - Linkage comune Id processo: 90001 Nome processo: TGL473 Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
Logica generale Gestione taglio lamiere Importazione del consuntivo lavorazione da LVD (gestione piegatrici) Questo programma mantiene la struttura dei programmi SWN per poter usufruire delle logiche di innesco e del controllo di keep-alive (i processi tra 90000 e 99999) saranno assegnati di default all'istanza 91, e che potrà quindi essere debitamente controllata. Essendo un programma in background, aggiungere al programma il "verbale" delle operazioni abbastanza preciso e dettagliato tramite la scrittura con "gesdebug" Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online | |
| tagliolm | path-lvd-input | |
| tagliolm | lav-piegatura |
Elaborazione Tipi di segnalazione: Vedi Tipi di segnalazione a 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: ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Importazione consuntivi Effettuare la scansione della cartella configurata in path-lvd-input, usando i comandi "C$LIST-DIRECTORY". Ciascun file corrisponde ad un consuntivo di lavorazione da acquisire. Att100ualmente non è noto se il nome del file è riconoscibile, quindi diamo per scontato che ciascun file sia da acquisire. B.1 - Acquisizione singolo file Il file può contenere una o più righe di dati. Una singola riga potrebbe essere come segue: "33081;lvd001;3;2;1;21-11-17 11:55:08;21-11-17 11:55:58;00:00:10;00:00:37;00:00:47;Operatore;FINISHED;Commento";
| Dato | Significato | Note |
|---|---|---|
| 33081 | Codice macchina "LVD" | Corrisponde al codice "esterno" presente su CLCANAMA.MAC-COD-ESTERNO Cercare su questa tabella la macchina corrispondente. Se non presente, segnalare un errore critico nel log e non importare il file. |
| lvd001 | Codice lavorazione (chiedere conferma) | Cercare la commessa di lavorazione; il codice lavorazione è nel formato "221250_13": |
| 3 | N. pezzi richiesti | |
| 2 | N. pezzi lavorati | |
| 1 | N. pezzi scartati | |
| 21-11-17 11:55:08 | Data/ora inizio | |
| 21-11-17 11:55:58 | Data/ora fine | |
| 00:00:10 | Tempo di lavorazione | |
| 00:00:37 | Tempo di setup | |
| 00:00:47 | laTempo totale di lavorazione | |
| Operatore | Operatore assegnato alla macchina | |
| FINISHED | Stato del lavoro | |
| Commento | Commento inserito manualmente dall'operatore |
B.2 - Creazione consuntivo Per ciascuna riga presente nel file creare un record su TGLLCONS:
| Dato | Contenuto |
|---|---|
| TLCO-ID | Nuovo id progressivo |
| TLCO-COM-ANN | CLA-ANNO |
| TLCO-COM-NUM | CLA-NUMERO |
| TLCO-MAC | MAC-COD (trovato da CLCANAMA come spiegato sopra) |
| TLCO-LAV | lav-piegatura |
| TLCO-TIP | "L" |
| TLCO-OPE-1 | 0 |
| TLCO-OPE-2 | 0 |
| TLCO-STATO | "C" |
| TLCO-DATA-INI | Data inizio operazione |
| TLCO-ORA-INI | Ora inizio operazione |
| TLCO-DATA-FIN | Data fine operazione |
| TLCO-ORA-FIN | Ora fine operazione |
| TLCO-TEMPO | Il contenuto del campo "Tempo di lavorazione", convertito in minuti |
| TLCO-POSTAZIONE | " " |
| TLCO-RIGA-ORDINE | Il numero riga ricavato dal codice lavorazione (vedi sopra) |
B.3 - Backup file Al termine dell'elaborazione spostare il file nella sottocartella "backup". Segnalare in caso di errore
FORMA0 - Esportazione movimenti a Soprasteria¶
Nome programma FORMA0 Linkage section UTILAGPRG - Linkage comune Id processo: 90002 Nome processo: FORMA0 Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| FRMTESBO FRMDETBO |
Logica generale Esportazione Esportazione movimenti fedi di deposito "Pegno rotativo" verso il portale "Soprasteria" Importazione Non prevista Configurazioni possibili
| Pacchetto | Gruppo | Parametro | Note |
|---|---|---|---|
| C | abilita | attiva-areaapp | |
| C | areaapp | cod-azienda | |
| C | areaapp | db-conn-string | |
| C | areaapp | agg-postgres-online | |
| F | connect | soprasteria-fonte | |
| F | connect | modo-pegno-rotativo | |
| F | connect | fors24-invio-interattivo |
Elaborazione Attenzione: se la configurazione fors24-invio-interattivo vale "S", e EXT-IS-BATCH-MODE = "S" emettere una segnalazione "warning" sul log e uscire: "Il programma non verrà eseguito perchè è in modalità interattiva" 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: ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. A.2.2 Data/ora ultima esportazione Sulla tabella APSTATOSYN, leggere il record relativo alla tabella/oggetto da sincronizzare "FORMA0"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "FORMA0" |
| 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) Leggiamo anche un altro record:
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "FORMA0-FRMSCLMV" |
| A_SYN_DA_GES_DATA | 0 |
| A_SYN_DA_GES_ORA | 0 |
| A_SYN_DA_ID_SINCRO | 1 |
| A-SYN-VERSIONE | 2 |
Qui leggiamo data/ora ultima esportazione dei movimenti scalera. B - Creazione file di transito Definire all'interno del programma un file di transito che dovremo popolare nell'elaborazione, e servirà da base per l'esportazione. Il file di transito conterrà i seguenti campi:
| Dato | Formato | Descrizione |
|---|---|---|
| TRS-CHIA1 | ||
| TRS-DOCUMENTO TRS-TESTA |
9(02) 9(04) x(01) 9(06) 9(02) 9(04) 9(02) x(10) |
Identificativo di movimento |
| TRS-DATI | ||
| 9(04) | Anno/Mese di produzione nel formato AAMM | |
| x(20) | Ubicazione della partita nel formato "Magazzino"."Area"."Scalera".0.0 |
|
| x(10) | Causale del movimento | |
| 9(05) | Codice cliente depositante | |
| x(16) | Codice fiscale del cliente depositante | |
| x(01) | Tipo di merce |
|
| x(10) | Codice matricola (caseificio) | |
| 9(06) | Numero di forme presenti | |
| 9(08)v999 | Peso complessivo delle forme | |
| x(20) | Id garanzia | |
| 9(08) | Data evento |
B.1 - Ricerca movimenti tramite log Diamo per scontato che sia attivo il log di aggiornamento sulla tabella FRMTESBO. Quindi effettuiamo una scansione su LOGAGREC con LGR-CHIA3, impostando
| Dato | Contenuto |
|---|---|
| LGR-FILE | "frmtesbo" |
| LGR-DATA | Data e ora ultimo aggiornamento da APSTATOSYN |
| LGR-ORA |
Per ogni record valido cerco la chiave corrispondente su LOGIDREC attraverso la chiave primaria:
| Dato | Contenuto |
|---|---|
| LRR-FILE | LGR-FILE |
| LRR-ID | LGR-ID-RECORD |
Se il record non esiste saltare segnalando un errore critico. Altrimenti LRR-CHIAVE conterrà la testata del documento da considerare, e corrisponde a TES-CHIA1 Cercare la testata documento FRMTESBO
| Dato | Contenuto |
|---|---|
| TES-CHIA1 | LRR-CHIAVE |
Filtro in base a modo-pegno-rotativo> B.F.1 - Modo "F" Considerare solo i movimenti con TES-TIPODOC1: * "F" (vincoli) * "W" (svincoli) B.D.1 - Modo "D" Considerare solo i movimenti con TES-CAUSALE: * Tra 1 e 39 (Entrate) * Tra 60 e 99 (Uscite) NB: il record di aggiornamento può essere inserito solo in caso di inserimento: ora non è possibile modificare un movimento, dopo che è stato esportato, quindi l'eventuale modifica trovata è solo quella che viene effettuata da questo programma per fleggare il record. Invece la cancellazione è possibile solo se non ancora esportato, quindi in questo caso posso proseguire con l'elaborazione. Poi cercare sul file di transito se abbiamo già considerato il documento (quindi se è presente almeno un record a fronte della testata TES-CHIA1. Se esiste: valutare il tipo di log (LOG-OPERAZIONE") * "C" (cancellazione) rimuovere tutti i record collegati alla testata sul file di transito * <> "C": non fare nulla Altrimenti proseguire Cercare la testata aggiuntiva documento FRMTESAP
| Dato | Contenuto |
|---|---|
| TAP-CHIA1 | TES-CHIA1 |
B.F.1.1 - Svincolo: ricerca vincolo (solo se modo-pegno-rotativo = "F") Se stiamo elaborando uno svincolo, dobbiamo cercare il vincolo a cui è collegato, da completare B.2 - Movimenti documento Per ciascun documento leggere tutti i movimenti collegati su FRMRIGBO, usando la chiave primaria:
| Dato | Contenuto |
|---|---|
| RIG-TESTA | TES-CHIA1 |
Per ciascun movimento valido leggiamo anche FRMDEPOS tramite la chiave primaria
| Dato | Contenuto |
|---|---|
| DPS-DEPOSITO | RIG-DEPOSITO |
B.D.2.1 - Filtro su deposito (solo se modo-pegno-rotativo = "D") Considerare il movimento solo se DPS-ANT-TIP = "P" Proseguire cercando l'anagrafica merci FRMMERCI:
| Dato | Contenuto |
|---|---|
| PRO-CHIA1 | RIG-MERCE |
B.3 - Dettaglio mensile Ora per ciascun movimento leggiamo il dettaglio mensile del movimento, scorrendo FRMDETBO per la chiave primaria
| Dato | Contenuto |
|---|---|
| ESP-TESTA | RIG-TESTA (passando campo campo perchè la lunghezza di ESP-PROGR1 non corrisponde) |
B.4 - Scalere Ciascun dettaglio mensile potrebbe ulteriormente essere suddiviso in "movimenti scalera"; scorrere quindi la tabella FRMSCLMV usando SCM-CHIA2
| Dato | Contenuto |
|---|---|
| SCM-DOC-TESTA | RIG-TESTA |
| SCM-DOC-RIG | RIG-RIGA |
| SCM-DOC-MES | ESP-MESE |
Attenzione: SCM-FORME corrisponde al dettaglio massimo del movimento che si può trovare. A parità di record dettaglio mensile (FRMDETBO) la sommatoria di FRMSCLMV.SCM-FORME dovrebbe corrispondere a FRMDETBO.ESP-NUMFORME
Nel caso in cui non esistano movimenti, o la sommatoria sia inferiore a ESP-NUMFORME, considerare come se esistesse un record di FRMSCLMV con SCM-SCL = " " Se invece la sommatoria dovesse essere superiore, segnalare con un errore critico indicando documento+riga+mese Per ciascun movimento trovato leggere invece l'anagrafica scalera FRMSCLAN:
| Dato | Contenuto |
|---|---|
| SCA-COD | SCM-SCL |
B.9 - Aggiornamento transito Ora per ciascun movimento scalera trovato andremo a cercare ed inserire/aggiornare il file di transito riepilogativo per fede/mese Ricerca:
| Dato | Descrizione |
|---|---|
| TRS-TESTA | TES-CHIA1 |
| TRS-RIGA | RIG-RIGA1 |
| TRS-MESE | ESP-MESE |
| TRS-SCALERA | SCM-SCL |
Se non presente inserire il record con:
| Dato | Descrizione |
|---|---|
| TRS-LOTTO | DPS-MER-ANN (3:2) + ESP-MESE |
| TRS-UBICAZIONE | SCM-DOC-MAG+"."+SCA-UBI+"."+SCM-SCL+".0.0" |
| TRS-CLI | DPS-CLIE |
| TRS-CF | COGGEANA.ANA-COFI |
| TRS-MATRICOLA | DPS-MTR-NUM |
| TRS-CAUSALE | A seconda del tipo di movimento: Entrata Uscita |
| TRS-TIPO | PRO-CLASSE |
| TRS-FORME | Numero di forme |
| TRS-PESO | Il numero di forme per il peso medio movimento (RIG-QTA/RIG-NUMFORME) |
| TRS-ID-GARANZIA | DPS-ANT-NUM |
| TRS-DATA | RIG-DATA |
B.10 - Movimenti scalera Aggiungiamo al file di transito anche i movimenti scalera effettuati dalla funzione di trasferimento. Questi sono memorizzati su FRMSCLMV senza riferimenti al documento di magazzino.
Per ora effettuiamo la scansione sequenziale della tabella, considerando tutti i record con data/ora aggiornamento superiore all'ultima effettuata. Al momento data/ora aggiornamento non sono indicizzati su FRMSCLMV. Si prenderanno in considerazione quindi tutti i movimenti a partire dall'istante successivo, e solo quelli con SCM-DOC-TESTA non valorizzati. Per ciascun movimento dobbiamo leggere: * FRMDEPOS per il deposito collegato SCM-DEPOSITO * FRMSCLAN per la scalera in esame SCM-SCL * COGGEANA per il cliente collegato al deposito * FRMMERCI per il prodotto collegato al deposito Poi andiamo a memorizzare l'informazione sul file di transito
| Dato | Descrizione |
|---|---|
| TRS-TESTA | SCM-CHIA1 |
| TRS-RIGA | SCM-DOC-RIG |
| TRS-MESE | SCM-DOC-MES |
| TRS-SCALERA | SCM-SCL |
Se non presente inserire il record con:
| Dato | Descrizione |
|---|---|
| TRS-LOTTO | DPS-MER-ANN (3:2) + ESP-MESE |
| TRS-UBICAZIONE | SCM-DOC-MAG+"."+SCA-UBI+"."+SCM-SCL+".0.0" |
| TRS-CLI | DPS-CLIE |
| TRS-CF | COGGEANA.ANA-COFI |
| TRS-MATRICOLA | DPS-MTR-NUM |
| TRS-CAUSALE | A seconda del tipo di movimento: Entrata Uscita |
| TRS-TIPO | PRO-CLASSE |
| TRS-FORME | Numero di forme |
| TRS-PESO | Il numero di forme per il peso medio deposito (DPS-CAR-NUM/DPS-SCA-NUM) |
| TRS-ID-GARANZIA | DPS-ANT-NUM |
| TRS-DATA | SCM-DA-DATA |
C - Creazione file di testo Durante l'elaborazione alzare dei flag per capire se sono presenti record per le causali interessate: * TRS-CAUSALE = "CARICO" * TRS-CAUSALE = "SCARICO" Per ciascuna causale con almeno 1 record rileggere il file di transito e seguire l'elaborazione Tramite COGPA9 effettuare l'esportazione del file. NB: In ciascun ambiente sarà presente un solo modello di esportazione per ciascuna causale; la ricerca verrà effettuata impostando come filtro la causale stessa in modo che sia possibile la scelta automatica. Il modello conterrà tutte le informazioni previste, nella sequenza qui indicata. Vedi ad esempio COGFA6/COGP78HT C.1 - Ricerca modello Prima chiamata a COGPA9 per recuperare il modello:
| Dato | Descrizione |
|---|---|
| COGPA9-OPERAZIONE | "SELEZIONE" |
| COGPA9-MODELLO | K-IE-MODELLO-E-FORMA1 |
| COGPA9-FILTRO | La causale in elaborazione |
All'uscita COGPA9-ID-VERSIONE conterrà il modello da utilizzare C.2 - Creazione file di transito x COGPA9 Definire un nome per il file di transito COGPA9-T-DATI, usando anche data/ora sistema (richiamabile nel programma direttamente da screens), e aprirlo in output Scorrere il file di transito interno al programma. Per ciascun record con TRS-FORME > 0, effettuare l'esportazione di una riga (1 record per ciascun campo), con tutti i campi previsti nel modello "E-FORMA0"
| Dato | Descrizione |
|---|---|
| FONTE | "Fonte" configurata |
| FILIERA | "FORMAGGIO" |
| CAUSALE | La causale in elaborazione |
| DATA-EVENTO | TRS-DATA |
| UBICAZIONE | TRS-UBICAZIONE |
| CF-PROPRIETARIO | TRS-CF |
| PRODUTTORE | TRS-MATRICOLA |
| LOTTO | TRS-LOTTO |
| NUM-FORME | TRS-FORME |
| PESO | TRS-PESO |
| ID-GARANZIA | TRS-ID-GARANZIA |
C.3 - Produzione file Il modello sarà configurato per esportare un file "CSV", il cui nome dovrà essere indicato nel modello stesso. Chiudere COGPA9-T-DATI. Effettuare quindi una chiamata a COGPA9
| Dato | Descrizione |
|---|---|
| COGPA9-OPERAZIONE | "ESPORTAZIONE" |
| COGPA9-MODELLO | K-IE-MODELLO-E-FORMA1 |
| COGPA9-ID-VERSIONE | La versione restituita in precedenza |
| COGPA9-NOME-T-DATI | Il nome del file attribuito al transito COGPA9-T-DATI |
| COGPA9-FL-BATCH | "S" |
| COGPA9-FL-APRI-OUTPUT | "N" |
| COGPA9-TIPO-PATH | "S" |
| COGPA9-PATH | EXT-TMP-DIR+"soprasteria-fonte_causale_YYYYMMDDhhmmss.csv" |
All'uscita COGPA9-PATH conterrà il nome del file "csv" generato. D - Passaggio dati a Soprasteria Effettuare una chiamata a FORS24
| Dato | Contenuto |
|---|---|
| FORS24-OPE | "INVIA" |
| FORS24-FILE-NAME | Il nome del file da inviare |
| FORS24-FILE-LOCATION | Location del file da inviare |
All'uscita se l'esito è "S" l'operazione è riuscita. Altrimenti inviare una segnalazione critica contenente FORS24-MSG D.1 - Blocco i documenti Se l'operazione è riuscita con successo, rileggere il file di transito; per ciascuna testata movimento considerata, effettuare l'aggiornamento di FRMTESBO:
| Dato | Descrizione |
|---|---|
| TES-FL-BLOCCATO | "S" |
FORMA1 - Esportazione "balance" a Soprasteria¶
Nome programma FORMA1 Linkage section UTILAGPRG - Linkage comune Id processo: 90003 Nome processo: FORMA1 Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| FRMTESBO FRMDETBO |
Logica generale Esportazione Esportazione saldo fedi di deposito verso il portale "Soprasteria" Importazione Non prevista Configurazioni possibili
| Pacchetto | Gruppo | Parametro | Note |
|---|---|---|---|
| C | abilita | attiva-areaapp | |
| C | areaapp | cod-azienda | |
| C | areaapp | db-conn-string | |
| C | areaapp | agg-postgres-online | |
| F | connect | modo-pegno-rotativo | |
| F | connect | soprasteria-fonte | |
| F | connect | fors24-invio-interattivo |
Elaborazione Attenzione: se la configurazione fors24-invio-interattivo vale "S", e EXT-IS-BATCH-MODE = "S" emettere una segnalazione "warning" sul log e uscire: "Il programma non verrà eseguito perchè è in modalità interattiva" 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: ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Creazione file di transito Definire all'interno del programma un file di transito che dovremo popolare nell'elaborazione, e servirà da base per l'esportazione. Il file di transito conterrà i seguenti campi:
| Dato | Formato | Descrizione |
|---|---|---|
| TRS-CHIA1 | ||
| 9(04) | Anno/Mese di produzione nel formato AAMM | |
| x(20) | Ubicazione della partita nel formato "Magazzino"."Area"."Scalera".0.0 |
|
| TRS-DATI | ||
| 9(05) | Codice cliente depositante | |
| x(16) | Codice fiscale del cliente depositante | |
| x(10) | Codice matricola (caseificio) | |
| 9(06) | Numero di forme presenti |
B.0 - Modalità di ricerca A seconda della configurazione modo-pegno-rotativo, eseguire l'elaborazione dedicata: * "F": B.F - Ricerca per fede * "D": B.D - Ricerca per deposito B.F - Ricerca per fede B.F.1 - Ricerca depositi aperti Scansione su FRMDEPOS, per tutti i depositi aperti, usando DPS-CHIA7:
| Dato | Contenuto |
|---|---|
| DPS-CHIUSO | " " |
B.F.2 - Movimenti deposito Per ciascun deposito leggere tutti i movimenti collegati su FRMRIGBO, usando RIG-CHIA2:
| Dato | Contenuto |
|---|---|
| RIG-DEPOSITO | DPS-DEPOSITO |
Dobbiamo considerare solo i movimenti relativi a fedi di deposito: * RIG-TIPODOC1 = "F" (vincoli) -> Entrate * RIG-TIPODOC1 = "W" (svincoli) -> Uscite Per ciascun movimento valido leggiamo anche FRMTESBO e FRMTESAP, usando la parte di testata
| Dato | Contenuto |
|---|---|
| TES-CHIA1 TAP-CHIA1 |
RIG-TESTA |
Considerare il documento solo se TES-FL-BLOCCATO = "S" (significa che è già stato "esportato") 21/09/2023 Correzione NO: li consideriamo tutti, perchè ci sono casi in cui i movimenti non sono stati tutti esportati in quanto l'esportazione è iniziata dopo una certa data, quindi il risultato sarebbe incompleto. Perciò diamo per scontato che l'esportazione del balance avvenga solo dopo un'esportazione recente delle entrate/uscite: in pratica dovrà essere effettuato manualmente quando necessario Proseguire con il punto B.3 B.D - Ricerca per deposito B.D.1 - Ricerca depositi aperti Scansione su FRMDEPOS, per tutti i depositi aperti, usando DPS-CHIA7:
| Dato | Contenuto |
|---|---|
| DPS-CHIUSO | " " |
Considerare solo i depositi con DPS-ANT-TIP = 'P' B.D.2 - Movimenti deposito Per ciascun deposito leggere tutti i movimenti collegati su FRMRIGBO, usando RIG-CHIA2:
| Dato | Contenuto |
|---|---|
| RIG-DEPOSITO | DPS-DEPOSITO |
Per ciascun movimento valido leggiamo anche FRMTESBO e FRMTESAP, usando la parte di testata
| Dato | Contenuto |
|---|---|
| TES-CHIA1 TAP-CHIA1 |
RIG-TESTA |
Considerare il documento solo se TES-FL-BLOCCATO = "S" (significa che è già stato "esportato") 21/09/2023 Correzione NO: li consideriamo tutti, perchè ci sono casi in cui i movimenti non sono stati tutti esportati in quanto l'esportazione è iniziata dopo una certa data, quindi il risultato sarebbe incompleto. Perciò diamo per scontato che l'esportazione del balance avvenga solo dopo un'esportazione recente delle entrate/uscite: in pratica dovrà essere effettuato manualmente quando necessario Dobbiamo considerare solo i movimenti con TES-CAUSALE: * Tra 1 e 39 (Entrate) * Tra 60 e 99 (Uscite) Proseguire con il punto B.3 Sezione comune B.3 - Dettaglio mensile Ora per ciascun movimento leggiamo il dettaglio mensile del movimento, scorrendo FRMDETBO per la chiave primaria
| Dato | Contenuto |
|---|---|
| ESP-TESTA | RIG-TESTA (passando campo campo perchè la lunghezza di ESP-PROGR1 non corrisponde) |
B.4 - Scalere Ciascun dettaglio mensile potrebbe ulteriormente essere suddiviso in "movimenti scalera"; scorrere quindi la tabella FRMSCLMV usando SCM-CHIA2
| Dato | Contenuto |
|---|---|
| SCM-DOC-TESTA | RIG-TESTA |
| SCM-DOC-RIG | RIG-RIGA |
| SCM-DOC-MES | ESP-MESE |
Attenzione: SCM-FORME corrisponde al dettaglio massimo del movimento che si può trovare. A parità di record dettaglio mensile (FRMDETBO) la sommatoria di FRMSCLMV.SCM-FORME dovrebbe corrispondere a FRMDETBO.ESP-NUMFORME
Nel caso in cui non esistano movimenti, o la sommatoria sia inferiore a ESP-NUMFORME, considerare come se esistesse un record di FRMSCLMV con SCM-SCL = " " Se invece la sommatoria dovesse essere superiore, segnalare con un errore critico indicando documento+riga+mese Per ciascun movimento trovato leggere invece l'anagrafica scalera FRMSCLAN:
| Dato | Contenuto |
|---|---|
| SCA-COD | SCM-SCL |
B.9 - Aggiornamento transito Ora per ciascun movimento scalera trovato andremo a cercare ed inserire/aggiornare il file di transito riepilogativo per fede/mese Ricerca:
| Dato | Descrizione |
|---|---|
| TRS-LOTTO | DPS-MER-ANN (3:2) + ESP-MESE |
| TRS-UBICAZIONE | SCM-DOC-MAG+"."+SCA-UBI+"."+SCM-SCL+".0.0" |
Se non presente inserire il record con:
| Dato | Descrizione |
|---|---|
| TRS-CLI | DPS-CLIE |
| TRS-CF | COGGEANA.ANA-COFI |
| TRS-MATRICOLA | DPS-MTR-NUM |
Infine aggiornare il record: * Sommando le forme a TRS-FORME, in caso di entrata * Sottraendo le forme da TRS-FORME, in caso di uscita C - Creazione file di testo ed esportazione Se è stato scritto almeno 1 record Ora rileggere il file di transito, e tramite COGPA9 effettuare l'esportazione del file. NB: In ciascun ambiente sarà presente un solo modello di esportazione in modo che sia possibile la scelta automatica. Il modello conterrà tutte le informazioni previste, nella sequenza qui indicata. Vedi ad esempio COGFA6/COGP78HT C.1 - Ricerca modello Prima chiamata a COGPA9 per recuperare il modello:
| Dato | Descrizione |
|---|---|
| COGPA9-OPERAZIONE | "SELEZIONE" |
| COGPA9-MODELLO | K-IE-MODELLO-E-FORMA1 |
All'uscita COGPA9-ID-VERSIONE conterrà il modello da utilizzare C.2 - Creazione file di transito x COGPA9 Definire un nome per il file di transito COGPA9-T-DATI, usando anche data/ora sistema (richiamabile nel programma direttamente da screens), e aprirlo in output Scorrere il file di transito interno al programma. Per ciascun record con TRS-FORME > 0, effettuare l'esportazione di una riga (1 record per ciascun campo), con tutti i campi previsti nel modello "E-FORMA1"
| Dato | Descrizione |
|---|---|
| FONTE | "Fonte" configurata |
| FILIERA | "FORMAGGIO" |
| CAUSALE | "BALANCE" |
| TIMESTAMP | Data/ora nel formato "GG/MM/AAAA hh:mm:ss" |
| UBICAZIONE | TRS-UBICAZIONE |
| CF-PROPRIETARIO | TRS-CF |
| PRODUTTORE | TRS-MATRICOLA |
| LOTTO | TRS-LOTTO |
| NUM-FORME | TRS-FORME |
C.3 - Produzione file Il modello sarà configurato per esportare un file "CSV", il cui nome dovrà essere indicato nel modello stesso. Chiudere COGPA9-T-DATI. Effettuare quindi una chiamata a COGPA9
| Dato | Descrizione |
|---|---|
| COGPA9-OPERAZIONE | "ESPORTAZIONE-ET" |
| COGPA9-MODELLO | K-IE-MODELLO-E-FORMA1 |
| COGPA9-ID-VERSIONE | La versione restituita in precedenza |
| COGPA9-NOME-T-DATI | Il nome del file attribuito al transito COGPA9-T-DATI |
| COGPA9-PATH | EXT-TMP-DIR+soprasteria-fonte_BALANCE_YYYYMMDDhhmmss.csv" |
| COGPA9-TIPO-PATH | "S" |
| COGPA9-FL-APRI-OUTPUT | "N" |
| COGPA9-FL-BATCH | "S" |
All'uscita COGPA9-PATH conterrà il nome del file "csv" generato. D - Passaggio dati a Soprasteria Effettuare una chiamata a FORS24
| Dato | Contenuto |
|---|---|
| FORS24-OPE | "INVIA" |
| FORS24-FILE-NAME | Il nome del file da inviare |
| FORS24-FILE-LOCATION | Location del file da inviare |
All'uscita se l'esito è "S" l'operazione è riuscita. Altrimenti inviare una segnalazione critica contenente FORS24-MSG
COGZK0 - Acquisizione log Galassia¶
Nome programma COGZK0 Linkage section UTILAGPRG - Linkage comune Id processo: 90001 Nome processo: COGZK0 Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
Logica generale Gestione laboratori odontotecnici Importazione del log di lavorazione da stampanti 3d "Galassia" Questo programma mantiene la struttura dei programmi SWN per poter usufruire delle logiche di innesco e del controllo di keep-alive. Essendo un programma in background, aggiungere al programma il "verbale" delle operazioni abbastanza preciso e dettagliato tramite la scrittura con "gesdebug" Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online | |
| macchine | lav-stampa3d | |
| macchine | path-job |
Elaborazione Tipi di segnalazione: Vedi Tipi di segnalazione a 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: ARPSTPRC Se fallita inviare una Segnalazione critica e chiudere. B - Importazione file Scorrere CLCMACC2; per ciascun record leggere il corrispondente record su CLCANAMA; considerare solo se: * MAC2-PATH è significativo: vuol dire che la macchina è predisposta per l'invio dei dati * MAC-LAV = lav-stampa3d Per ciascuna macchina predisposta quindi si dovrà ripetere il seguente processo. B.1 - Scansione cartella Tramite C$LISTDIR effettuare la scansione della cartella configurata MAC2-PATH. Per ciascun file trovato effettuare l'elaborazione seguente: B.2 - Acquisizione singolo file Il file ha una struttura piuttosto complessa e poco chiara. Le sessioni di stampa della macchina vengono chiamate "job". All'interno di una sessione di stampa possono essere prodotti più oggetti, appartenenti ad una o più commesse. Riga con "START JOB" Identifica l'inizio di una sessione di stampa. Se all'interno del file ci sono più JOB, identifica anche la fine del job precedente (non ci sono altri modi per ottenerlo) Riga con "Start process build job....." Contiene il nome del job elaborato, ad esempio: [0;37m2023-12-04_10:35:21.320$[0;33m[Worker:I]5[0;0m;[0;37m[2957]H[0m P[1;30mW[0;37mStart process build job "/tmp/.ET/envisiontec/Job/job 05" [0m In rosso il nome del job che verrà utilizzato successivamente Inizio/fine lavorazione Quasi tutte le righe del log hanno come nell'esempio precedente: [0;37m2023-12-04_10:35:21.320 [0;33m[Worker:I][0;0m![0;37m[2957].[0m 6[1;30m=[0;37mStart process build job "/tmp/.ET/envisiontec/Job/job 05" [0m In rosso data e ora dell'esecuzione della riga di log. Analizzando tutte le righe fino all'inizio del job successivo possiamo ottenere quindi in modo approssimativo l'inizio e la fine del job, quindi della sessione di stampa. B.3 - Creazione consuntivo Per ciascun "job" esaminato e di cui abbiamo ricavato i dati come spiegato sopra, inseriamo un record su CLCMACLG:
| Dato | Contenuto |
|---|---|
| MACL-ID | Primo ID disponibile |
| MACL-COD-MACCHINA | Macchina in elaborazione |
| MACL-INIZIO | Data/ora inizio trovata |
| MACL-FINE | Data/ora fine trovata |
| MACL-TEMPO-MINUTI | Differenza tra inizio e fine |
| MACL-PROGRAMMA | Nome Job |
| MACL-MP-X | " " |
| MACL-MP-MERCE | k-merce-null |
| MACL-FL-MP-SCARICATA | "S" |
| MACL-PN-SCARICO-MP | Inizializzato |
B.3.1 - Creazione consuntivo per commessa Ora, usando ancora C$LISTDIR effettuare la scansione della cartella "path-job + ext-os-slash-client + nome_job (percorso clienti)
Ciascun file trovato dovrebbe contenere il codice di una commessa, come spiegato in COGZQ0 - Rinomina cartella con commessa; ad esempio: * path-job * Job-21 * MODEL-Mascellare1- 1234567890.stl * MODEL-Mascellare2- 1234567890.stl * MODEL-Mandibolare1- 1234567890.stl * MODEL-Mascellare1- 2142910015.stl * MODEL-Mascellare2- 2142910015.stl * MODEL-Mandibolare1- 2142910015.stl Il codice commessa verrà quindi identificato tra l'ultimo carattere "-" e ".stl" Per ciascun "job" esaminato e di cui abbiamo ricavato i dati come spiegato sopra, inseriamo un record su CLCMACLG:
| Dato | Contenuto |
|---|---|
| MACR-ID | MACL-ID |
| MACR-PROG | Progressivo di riga |
| MACR-RAC-TIPO | "LC" |
| MACR-RAC-DOC | Codice commessa |
B.4 - Backup file Al termine dell'elaborazione spostare il file nella sottocartella "backup". Segnalare in caso di errore
Estratto da documentazione interna ClickUp