# 04 — Operatori e barcode

## 1. Ruolo nel dominio Lavorazioni

`Operatori` è l’anagrafica operatori di reparto. Lavorazioni lo usa in due modi:

1. **Riferimento** `operatore_id` (uitype 10) sul record padre Lavorazioni
2. **Barcode** `barcode_operatore` (testo) allineato a `Operatori.vcf_14_3` (“Codice a barre”)

L’endpoint Ajax e il JS servono a **sincronizzare** id ↔ barcode senza digitare entrambi a mano.

## 2. Identità Operatori

| Proprietà | Valore |
|-----------|--------|
| tabid | 96 |
| IsCustomModule | true (ModuleMaker) |
| Tabelle | `vte_crmentity` + `vte_operatori` + `vte_operatoricf` |
| PK | `operatoriid` |
| Nome visualizzato | `vcf_14_1` (Nome Operatore) |
| Codice a barre | `vcf_14_3` |
| Codice univoco | `vcf_14_4` (uitype 4) |
| Altri campi rilevanti | `reparto` → Reparti (uitype 10), `attivo` (checkbox), CF società |
| Record vivi | **39** |

Classe: [`modules/Operatori/Operatori.php`](../../../vte23083_2711/modules/Operatori/Operatori.php).

## 3. Metadata relazione

`vte_fieldmodulerel`:  
`Lavorazioni.operatore_id` → `Operatori`  
(install forza unset Users e setRelatedModules Operatori).

## 4. Endpoint Ajax — lettura DB

File: [`modules/Lavorazioni/OperatoreBarcodeAjax.php`](../../../vte23083_2711/modules/Lavorazioni/OperatoreBarcodeAjax.php)

Routing: `module=Lavorazioni` + `action=LavorazioniAjax` + `file=OperatoreBarcodeAjax` (pattern Ajax VTE).

Input (via `RH`):

- `operatore_id` (int) **oppure**
- `barcode` (string)

Query A — per id:

```sql
SELECT o.operatoriid, o.vcf_14_1, o.vcf_14_3
FROM vte_operatori o
INNER JOIN vte_crmentity ce ON ce.crmid = o.operatoriid
WHERE o.operatoriid = ? AND ce.deleted = 0
LIMIT 1
```

Query B — per barcode:

```sql
… WHERE o.vcf_14_3 = ? AND ce.deleted = 0 LIMIT 1
```

Output JSON:

```json
{ "id": 123, "name": "Mario Rossi", "barcode": "ABC" }
```

oppure id null se non trovato. Content-Type JSON; `die()` immediato.

**Scrittura:** nessuna (solo SELECT).

## 5. Client JS (autofill)

In `Lavorazioni.js`:

| Trigger | Azione |
|---------|--------|
| Popup restituisce Operatore su campo `mlLavorazioniSess_operatore_id_{n}` | Ajax by id → riempie `…_barcode_operatore_{n}` |
| Blur / Enter su `mlLavorazioniSess_barcode_operatore_{n}` | Ajax by barcode → riempie id + display name |

SDK file [`ReturnOperatoreBarcode.php`](../../../vte23083_2711/modules/SDK/src/modules/Lavorazioni/ReturnOperatoreBarcode.php): al return popup legge `vcf_14_3` e dovrebbe chiamare `lav_sess_return_operatore(...)`. **Non risulta registrato** in `sdk_popup_return_funct` → oggi il percorso attivo è l’hook `vtlib_setvalue_from_popup` nel JS, non l’SDK.

## 6. Disallineamento padre vs riga

- **DB/UI padre:** `operatore_id`, `barcode_operatore` presenti e displaytype 1
- **UI ModLight:** campi operatore/barcode **non** in `vte_field`
- **JS:** lavora sui nomi campo **riga ModLight**

Conseguenza: autofill barcode è calibrato sullo schema “operatore sulla sessione”. Sul padre i due campi esistono ma **non** hanno lo stesso wiring JS. Per un utilizzo corretto sul padre andrebbe esteso il JS (fuori scope di questa analisi — solo segnalazione).

## 7. Lettura/scrittura Operatori (cenni)

CRUD standard CRMEntity su tabelle Operatori. Nessun `save_module` speciale verso Lavorazioni. Quando una Lavorazione salva `operatore_id`, scrive solo il bigint nella riga lavorazioni; non aggiorna Operatori.

## 8. Evidenze

- 39 operatori disponibili per risoluzione barcode
- Ajax solido e parametrizzato
- SDK return presente su filesystem ma non wired in DB
- Dipendenza funzionale forte: senza `vcf_14_3` valorizzato lo scan barcode non risolve