Campi Partita IVA CAP (numerici) che iniziano con 0

[gabrielepiccinnu]

Durante la fase di inserimento, i campi Partita IVA e CAP, vengono in fase di salvataggio su MySQL, privati dello 0 iniziale. Agendo sul DB manualmente, con l'inserimento del carattere 0, viene salvato e infatti quando vedo l'anagrafica, i campi che iniziano per 0, sono corretti. Se provo però a salvare senza modifiche, tutti i campi che iniziano per 0 vengono modificati.

[Dasc3er]

Il problema si verifica esclusivamente con l'utilizzo dell'interfaccia nativa di PHP per l'internazionalizzazione...
Per versioni PHP in cui l'estensione intl non è abilitata, la conversione funziona correttamente.

@loviuz @lucasalva87 @fpsoftware A questo punto, vorrei chiedere se credete che sia utile utilizzare l'interfaccia nativa PHP.
Il vantaggio è che vengono supportati in modo automatico più formati e lingue (per il momento solo per la conversione dei numeri); lo svantaggio principale è che ci possono essere situazioni simili che bisogna controllare manualmente.

Per il momento, se l'estensione è abilitata viene utilizzata, altrimenti la conversione avviene con il metodo customNumber (da me creato).

[fpsoftware]

Ciao Thomas, pensiamo che sia meglio eliminare questa interfaccia nativa PHP.
Oltre ai campi qui segnalati (p.iva, cap) mi viene in mente il campo codice articolo, codice anagrafica/fornitore, inoltre in alcune personalizzazioni abbiamo dovuto introdurre ulteriori formattazioni sui numeri per gestire casi particolari, ti faccio alcuni esempi: articoli venduti al metro quadrato che andavano gestiti con 3 cifre decimali, oppure casi in cui siamo costretti a scorporare l'iva da un prezzo finito, e se non usiamo il terzo decimale non tornano i calcoli.
Quindi per più motivi è meglio eliminare questa funzione e tornare alla vecchia funzione in javascript

[fpsoftware]

e grazie a Gabriele per la segnalazione!

[Dasc3er]

In realtà, questa funzione serve per convertire un numero, per esempio, dal formato italiano a uno comprensibile per PHP.
Per esempio, "2.345,67898764" in italiano diventa "2345.67898764" in PHP, così può essere utilizzato per fare calcoli e altro.

@fpsoftware La conversione non influenza in alcun modo il numero di decimali, e accetta solo numeri corretti (se ci sono lettere non si tratta di un numero, e se inizia con 0 fa un controllo sull'effettivo stato del numero).

Ovviamente, sono stati mantenuti anche tutti i sistemi JavaScript per la conversione tra formati, ma prima questa conversazione veniva effettuata proprio su questi e può quindi fallire con la semplice dimenticanza di una classe CSS.

Il problema in questo caso nasceva dal fatto che 0 è una cifra numerica, e quindi un numero che inizia con 0 veniva formattato senza di esso.

[fpsoftware]

ok allora diciamo che per i decimali non ci sono problemi, ma rimane comunque il problema sui codici, in quanto potrei avere il codice articolo 00500, oppure il codice anagrafica 050, oppure un seriale 0800, eccetera.... quindi per me questa funzione conviene eliminarla

[Dasc3er]

In realtà, ho aggiunto il supporto a questi tipi di numeri...
Avevo proposto la conversazione per sentire se avevate altre proposte per la gestione dei numeri o simili, o per migliorare in modo più logico la gestione attuale.

Dobbiamo gestire in ogni caso la conversione tra formati, e il metodo attuale funziona.