Accreditamento canale SDIFTP, errore nomenclatura, RC.0 = 1

Salve, è la prima volta che scrivo quì. Sto cercando di accreditare un canale SDIFTP.

Dopo alcuni tempi biblici, finalmente sono stato ammesso ai test di interoperabilità.

Quindi ieri ho provato a caricare 1 supporto, dopo avere creato uno script per zippare i files, firmare e crittografare il supporto e copiarlo nella directory destinazione come .ZIP

Tuttavia, mi da un errore sul nome del supporto:

Questo è il nome che mi ha generato il mio script:

FI.XXXXXXXXXXX.2458514.1753.901.zip

Il supporto l’ho caricato e generato il 30 Gennaio 2019, alle 1753

Per creare la data in formato Giuliano ho usato una funzione in php

function julian_date($T) {
$M=date(“m”,$T);
$D=date(“d”,$T);
$Y=date(“Y”,$T);
return gregoriantojd($M,$D,$Y);
}

Dove $T è in TimeStamp

Metto in dubbio la data, perchè è l’unica cosa sulla quale ho il dubbio sul nome.

Il fatto è che non credo di avere sbagliato la conversione però vedo dagli esempi Sogei, che le loro date Giuliane, sembrano iniziare con l’anno, esempio 2014, 2015, 2019

L’errore che ho ricevuto è questo:

Errore nella nomenclatura file:
RC.0 = 1
Produzione files non conforme con abilitazione

Magari provo un attimo a creare la data in altra maniera.

Comunque la documentazione della Sogei è pietosa.

Ho fatto altre prove. Ho messo questa data adesso:

2019030

Nome supporto:

FI.XXXXXXXXXXX.2019030.1309.901.zip

Mi dice: Produzione files non conforme con abilitazione

Ciao il problema è che la documentazione non è chiarissima se guardi però con molta attenzione vedrai che il nome del file è così composto :
FI .12345678901 . 2019031 . 0909 . 001
FI. (Costante indica file in ingresso verso la pubblica amministrazione)
12345678901 (è il codice fiscale del soggetto accreditato per la gestione del nodo)
2019 (anno di produzione del file)
031 (il giorno dall’inizio dell’anno in cui è stato prodotto il file)
0909 (ora e minuto in cui è stato prodotto il file)
001 (Progressivo , nel caso in cui si producano più file nello stesso minuto)

Io non produco più di un file al minuto quindi il mio progressivo sarà sempre 001

io il progressivo ce l’ho giornaliero tanto gli invii li faccio ogni ora o ogni 100 file ricevuti, farli ogni minuto è inutile e dannoso… SDIFTP preleva dopo un’ora circa dal deposito nella cartella e si aspetta che il sistema sia fatto per invii massivi non per invii di singole fatture…

Allora se sei ancora in fase di test ( cosa molto importante ) purtroppo anche io sono in fase di test ancora, il progressivo da utilizzare (come da messaggio inviatomi 16 giorni fa dai servizi crittografici) :
"come da indicazioni del manuale SdI il protocollo per i TEST vanno da 900 a 999.
I valori da 001 a 899 valgono per la Produzione"

Per quanto riguarda il progressivo, francamente non so se controllino ma credo si tratti di un progressivo legato alla radice del nome del file precedente (non di un progressivo giornaliero)
Ossia se si fanno più file con stessa data stessa ora e stesso minuto allora il progressivo dovrà incrementarsi.

Grazie, dalla risposta di Gianluca Passaro, mi sono accorto che oggi è giorno 31, mentre la funzione date() di php nel mio script, mi ha messo “30” come valore del giorno.

Domattina cerco di capire, perchè php ha un giorno indietro, visto che l’orario del server è corretto. Deve essere sbagliata la time zone nel file di config di php. Domattina la correggo e riprovo.

Insomma le cose un po particolari sono :
il giorno della data che è il numero “assoluto” di giorni da inizio anno oggi credo debba essere 031
il numero progressivo che deve essere (da 900 a 999) nella fase di test

Il giorno ovviamente deve essere di 3 “cifre” fillato a 0

Se hai usato il formato “z” per avere il numero del giorno dall’inizio dell’anno, la documentazione della funzione date() dice:

z - The day of the year (starting from 0) (example values: 0 through 365)

1 Mi Piace

Si quello ho usato, stavo guardando proprio adesso. Adesso correggo un attimo e riprovo.

Ieri poi ho caricato il file nuovo, con la correzione, e tutto è morto.

Suppongo che dia errori, perchè almeno il nome è corretto, ma non da segni di vita.