Passa al contenuto principale

Sincronizzazione Liste di Carico Soluziona → Zucchetti

Obiettivo

La sincronizzazione inversa ha lo scopo di riportare su Zucchetti i dati operativi prodotti dal tablet in Soluziona.

Il flusso è:

Zucchetti
    ↓
SincronizzaListeDaZucchettiASoluziona
    ↓
DocumentoTb / DettDocumentoTb
    ↓
Compilazione tramite Tablet
    ↓
SincronizzaListeDaSoluzionaAZucchetti
    ↓
Zucchetti

La sincronizzazione inversa deve aggiornare:

QuantitaLetta
Note
StatoLettura delle righe
StatoLettura della testa

La logica deve tenere conto del fatto che una singola lista Zucchetti può essere divisa in più documenti Soluziona quando contiene righe appartenenti a clienti differenti.


Tabelle coinvolte

Soluziona

DocumentoTb
DettDocumentoTb
DecodificaGestionaleEsternoTb

I documenti interessati hanno:

TipoDocumento = 29

Quantità

In DettDocumentoTb:

QntDaLeggere

rappresenta la quantità prevista proveniente da Zucchetti.

Qnt

rappresenta la quantità effettivamente letta tramite tablet.

Stato

Il tablet gestisce lo stato esclusivamente sulla testa del documento:

DocumentoTb.StatusDocumento

Non viene gestito uno stato operativo sulla singola DettDocumentoTb.

Note

Anche le note vengono gestite dal tablet sulla testa del documento Soluziona.


Zucchetti

Testata

TestaListaDiCaricoTb

Campi interessati:

S2serial
Note
StatoLettura
DataModifica
UtenteModifica

Righe

RigaListaDiCaricoTb

Campi interessati:

S2serial
S2rownum
QuantitaLetta
Note
StatoLettura
DataModifica
UtenteModifica

Mapping

La relazione tra le righe Soluziona e le righe Zucchetti viene gestita tramite:

DecodificaGestionaleEsternoTb

Per le righe:

IdSoluziona               = DettDocumentoTb.Id
IdGestionaleEsterno       = S2serial
IdRigaGestionaleEsterno   = S2rownum
TipoEntita                = 2
TipoDocumento             = 29
IsAttivo                  = 1

La sincronizzazione inversa deve utilizzare esclusivamente mapping attivi:

IsAttivo = 1

I mapping storici con:

IsAttivo = 0

non devono partecipare alla sincronizzazione verso Zucchetti.


Aggiornamento quantità lette

La quantità effettivamente letta dal tablet è memorizzata in:

DettDocumentoTb.Qnt

e deve essere riportata in:

RigaListaDiCaricoTb.QuantitaLetta

Il mapping è quindi:

DettDocumentoTb.Qnt
    ↓
RigaListaDiCaricoTb.QuantitaLetta

L'aggiornamento deve essere eseguito esclusivamente sulla riga Zucchetti corrispondente al mapping attivo:

S2serial + S2rownum

Esempio:

Soluziona

Qnt = 25

        ↓

Zucchetti

QuantitaLetta = 25

Aggiornamento stati

Gli stati definiti sono:

Stato Significato
0 ND
1 Attivo
2 Da convalidare
3 Convalidato
4 Autorizzato

Il tablet modifica solamente:

DocumentoTb.StatusDocumento

La sincronizzazione inversa deve propagare lo stato della testa Soluziona alle righe Zucchetti appartenenti a quel documento.


Stati Soluziona 0 e 1

Se:

DocumentoTb.StatusDocumento = 0

oppure:

DocumentoTb.StatusDocumento = 1

la sincronizzazione inversa non deve modificare lo stato Zucchetti.

Quindi:

Soluziona 0 / 1
    ↓
nessun aggiornamento StatoLettura

Non devono essere effettuati reset dello stato Zucchetti.


Passaggio a Da_Convalidare

Quando il tablet inizia la lavorazione, Soluziona porta il documento a:

StatusDocumento = 2

La sincronizzazione inversa deve impostare:

StatoLettura = 1

su tutte le righe Zucchetti collegate a quel documento.

Quindi:

Soluziona StatusDocumento = 2
        ↓
Righe Zucchetti StatoLettura = 1

La testa Zucchetti viene successivamente ricalcolata sulla base dello stato complessivo delle sue righe.


Passaggio a Convalidato

Quando il tablet chiude la lavorazione, Soluziona porta il documento a:

StatusDocumento = 3

La sincronizzazione inversa deve impostare:

StatoLettura = 4

su tutte le righe Zucchetti appartenenti a quel documento.

Quindi:

Soluziona StatusDocumento = 3
        ↓
Righe Zucchetti StatoLettura = 4

Liste Zucchetti monocliente

Se tutte le righe di una lista Zucchetti appartengono allo stesso cliente, viene creato un solo documento Soluziona.

Esempio:

Lista Zucchetti L00001
Cliente 0001246

        ↓

Documento Soluziona
Cliente 0001246

In questo caso lo stato del documento Soluziona può essere propagato a tutte le righe Zucchetti della lista.


Liste Zucchetti multicliente

Se una lista Zucchetti contiene clienti differenti, Soluziona crea un documento separato per ogni cliente.

Esempio:

Lista Zucchetti L00001

Riga 1 → Cliente A
Riga 2 → Cliente A
Riga 3 → Cliente B
Riga 4 → Cliente B

diventa:

Documento Soluziona A
Cliente A
├─ Riga 1
└─ Riga 2

Documento Soluziona B
Cliente B
├─ Riga 3
└─ Riga 4

La sincronizzazione inversa deve modificare esclusivamente le righe Zucchetti appartenenti al documento Soluziona interessato.


Stato testa Zucchetti in caso di multicliente

Lo stato della testa Zucchetti non può essere copiato direttamente dallo stato di un singolo documento Soluziona.

Deve essere calcolato analizzando tutte le righe appartenenti alla stessa:

S2serial

La regola è:

se tutte le righe sono a 4
    → testa = 4

se almeno una riga è a 1 oppure 4
   e non tutte sono a 4
    → testa = 1

altrimenti
    → non modificare lo stato

Esempio stato parziale

Lista Zucchetti:

S2serial = L00001

divisa in:

Documento A
Documento B

Situazione:

Documento A = StatusDocumento 2
Documento B = StatusDocumento 0

La sincronizzazione porta le righe del Documento A a:

StatoLettura = 1

Le righe del Documento B non vengono modificate.

La testa Zucchetti diventa:

StatoLettura = 1

perché almeno una parte della lista è stata iniziata.


Esempio autorizzazione parziale

Situazione:

Documento A = 3
Documento B = 2

Le righe di A diventano:

StatoLettura = 4

Le righe di B diventano:

StatoLettura = 1

La testa Zucchetti rimane:

StatoLettura = 1

perché non tutte le righe sono ancora autorizzate.


Esempio autorizzazione completa

Situazione:

Documento A = 3
Documento B = 3

Tutte le righe Zucchetti diventano:

StatoLettura = 4

A quel punto anche la testa viene impostata a:

StatoLettura = 4

Il processo può essere considerato completato.


Gestione note

Il tablet gestisce le note esclusivamente sulla testa del documento Soluziona.

La modalità con cui vengono riportate su Zucchetti cambia tra lista monocliente e lista multicliente.


Note su lista monocliente

Quando una lista Zucchetti genera un solo documento Soluziona:

1 lista Zucchetti
1 cliente
1 DocumentoTb

la nota della testa Soluziona viene riportata direttamente sulla testa Zucchetti.

Quindi:

DocumentoTb.Note...
        ↓
TestaListaDiCaricoTb.Note

Le note delle righe Zucchetti non devono essere modificate per questo scopo.

Esempio:

Soluziona:

Materiale verificato, manca un collo.

        ↓

Zucchetti Testa.Note:

Materiale verificato, manca un collo.

Note su lista multicliente

Quando una lista Zucchetti genera più documenti Soluziona, ogni documento può avere una propria nota.

In questo caso la nota della singola testa Soluziona deve essere riportata sulle sole righe Zucchetti appartenenti a quel documento.

Esempio:

Documento Cliente 0001246
Nota:
Materiale verificato, manca un collo.

Le righe Zucchetti appartenenti al Cliente 0001246 ricevono:

Note = Materiale verificato, manca un collo.

Un secondo documento:

Documento Cliente 0000219
Nota:
Consegna parziale autorizzata.

porta la propria nota esclusivamente sulle righe Zucchetti appartenenti al Cliente 0000219.


Nota concatenata sulla testa Zucchetti

Nel caso multicliente, la testa Zucchetti deve contenere la concatenazione delle note delle singole sottoliste Soluziona.

Ogni nota deve essere preceduta dal codice cliente.

Il formato deciso è:

[Cliente 0001246] Materiale verificato, manca un collo.  [Cliente 0000219] Consegna parziale autorizzata.

Quindi la struttura è:

[Cliente CODICE] NOTA

ripetuta per ogni documento Soluziona derivato dalla stessa lista Zucchetti.

Esempio completo:

[Cliente 0001246] Materiale verificato, manca un collo.  [Cliente 0000219] Consegna parziale autorizzata.

La concatenazione deve contenere una sola voce per ogni documento/cliente Soluziona collegato alla lista.


Individuazione del codice cliente

Il codice cliente Zucchetti è memorizzato in Soluziona nel campo:

ClienteTb.CodiceTessera

Per la composizione della nota della testa deve quindi essere utilizzato:

ClienteTb.CodiceTessera

e non:

ClienteTb.Codice

Righe storiche e mapping inattivi

Una stessa riga Zucchetti può aver generato più righe Soluziona nel tempo, ad esempio in caso di cambio articolo o cambio cliente dopo l'inizio della lavorazione.

Esempio:

S2serial = L00001
S2rownum = 10

DettDocumento A → IsAttivo = 0
DettDocumento B → IsAttivo = 0
DettDocumento C → IsAttivo = 1

La sincronizzazione inversa deve considerare esclusivamente:

DettDocumento C

perché rappresenta la versione attuale della riga Zucchetti.

Quindi:

IsAttivo = 0
→ ignorato

IsAttivo = 1
→ sincronizzato

Cambio articolo o cliente

Se dopo l'inizio della lista Zucchetti cambia articolo o cliente, la sincronizzazione Zucchetti → Soluziona:

azzera QntDaLeggere sulla vecchia riga
disattiva il vecchio mapping
crea una nuova DettDocumentoTb
crea un nuovo mapping attivo

La sincronizzazione inversa deve quindi riportare verso Zucchetti solamente i dati della nuova riga attiva.

Non devono essere sommati o trasferiti automaticamente i dati delle vecchie righe storiche.

In particolare:

QuantitaLetta Zucchetti
=
Qnt della DettDocumentoTb con mapping attivo

e:

Note associate alla sottolista
=
note della testa del documento Soluziona corrente

Righe eliminate da Zucchetti

Quando una riga Zucchetti viene eliminata dopo l'inizio della lavorazione, la sincronizzazione diretta:

QntDaLeggere = 0
IsAttivo mapping = 0

La sincronizzazione inversa non deve più tentare di aggiornare questa riga.


Ordine logico della sincronizzazione inversa

La procedura:

SincronizzaListeDaSoluzionaAZucchetti

deve eseguire logicamente questi passaggi.

1. Aggiornamento quantità

Per ogni mapping attivo:

DettDocumentoTb.Qnt
    ↓
RigaListaDiCaricoTb.QuantitaLetta

2. Aggiornamento note

Lista monocliente

Nota DocumentoTb
    ↓
TestaListaDiCaricoTb.Note

Lista multicliente

Nota Documento Cliente A
    ↓
righe Cliente A

Nota Documento Cliente B
    ↓
righe Cliente B

e sulla testa:

[Cliente A] Nota A  [Cliente B] Nota B

3. Aggiornamento stato righe

Solo per:

StatusDocumento = 2

oppure:

StatusDocumento = 3

Mapping:

Soluziona 2 → Zucchetti 1
Soluziona 3 → Zucchetti 4

Gli stati Soluziona 0 e 1 non modificano Zucchetti.


4. Ricalcolo stato testa

Per ogni S2serial coinvolta:

tutte righe = 4
    → testa = 4

almeno una riga = 1 o 4
    → testa = 1

nessuna riga iniziata
    → nessuna modifica

Principio generale

La sincronizzazione inversa segue questo principio:

Soluziona è autorevole sui dati prodotti dal tablet; Zucchetti continua a rappresentare la lista originaria e deve ricevere quantità lette, note e avanzamento della lavorazione senza perdere la distinzione tra le eventuali sottoliste create per cliente.

In particolare:

Soluziona
    ↓
Qnt
Note testa
StatusDocumento

vengono trasformati in:

Zucchetti
    ↓
QuantitaLetta
Note testa / righe
StatoLettura righe
StatoLettura testa

tenendo sempre conto della relazione:

1 lista Zucchetti
    ↓
1 o più documenti Soluziona

e utilizzando esclusivamente i mapping correnti:

DecodificaGestionaleEsternoTb.IsAttivo = 1