¿El registro de facturacion con el hash cuándo debe generarse?

[juanluislopez89]

Llevo un tiempo implementando verifactu con esta librería en mi programa y me acabo de dar cuenta de una cosa que me está volviendo loco...

Tengo una tabla de facturas y una tabla de registros verifactu.

Cuando emito una factura. genero el hash del registro en base al hash del registro anterior de mi tabla de registros y creo el registro verifactu en mi base de datos con su hash calculado.

Cuando voy a enviarlo a la AEAT, cargo el registro de la db y lo envío...

¿Qué pasa si es rechazado? porque ese registro no queda en la AEAT... por tanto en este escenario:

Emito factura 0001 y se genera el hash XXXXXX1 (sin hash previo)
Emito factura 0002 y se genera el hash YYYYYY2 hash previo XXXXXX1
Emito factura 0003 y se genera el hash ZZZZZZ3 hash previo YYYYYY2

En este punto mi cadena es correcta.

Envío el registro 1 y es aceptado
Envío el 2 y no es aceptado (no está en la AEAT)
Envío el 3 y es aceptado.

¿Como se gestiona esto ya que el 3 depende del 2 que hacienda no tiene en su lista y por haber sido rechazado?

A menos que el registro se genere en el momento del envío y no en el momento de la emisión, en cuyo caso, acabaría enviando el registro de la 00002 después del de la 00003 una vez corregido, quedando en la cadena de la aeat (y en mi base de datos de registros) cronologicamente después del registro de alta de la factura 0003

Me estoy volviendo loco... ¿Alguien que me de algo de luz?

[popnoart]

Según yo entiendo la documentación el envío a verifactu debe ser inmediato a la emisión de la factura.
Lo que yo hago es:

1. Borrador: inserto los datos en bd y creo el xml
2. Revisión: una persona lo revisa y si hay algo mal modificas el borrador.
3. Firma (en este punto considero emitida la factura) y envío inmediato a verifactu
4. Guardas los datos que te devuelve hacienda
5. Si ha sido rechazada se para todo hasta que se resuelva

No se, si alguien piensa de otra forma iluminadnos! :-D

[juanluislopez89]

He probado varias cosas cuando el error es "No censado" (metes un dni mal o el par DNI-Nombre no coinciden en el censo de la AEAT):

Primer caso:

• Creo factura en borrador.
• Le doy a "emitir" (momento en el que se le asigna un numero de factura y en el que se genera un registro verifactu en mi base de datos local "pendiente de envío" y con el hash XXXXXX)
• Envío a la AEAT.
• Es rechazado, por "no censado" y mi factura vuelve a ser editable a nivel de mi software.
• Modifico los datos del cliente.
• Una vez corregida al darle a "Guardar" se genera un nuevo registro en mi tabla de registros, asociado a esa factura con el hash YYYY.
• Lo envío y la AEAT me dice que está correcto.
• Me queda un registro erróneo generado en mi blockchain local, que no existe en la AEAT y cuyo registro posterior (correcto y enviado a la AEAT) está encadenado a el.

Lo que no comprendo de este caso es ¿Cómo es posible que la AEAT se trague un registro con un hash que depende de otro registro para ellos inexistente? Ya que en la documentacion mencionan que si un registro es rechazado no estará en sus servidores...

Segundo caso:

• Creo factura en borrador.
• Le doy a "emitir" (momento en el que se le asigna un numero de factura y en el que se genera un registro verifactu en mi base de datos local "pendiente de envío" y con el hash XXXXXX)
• Envío a la AEAT.
• Es rechazado, por "no censado" y mi factura vuelve a ser editable a nivel de mi software.
• Modifico los datos del cliente.
• Envío a la AEAT el mismo registro, con el hash XXXXXX (el mismo que antes me dio error), pero en este caso dado que no he modificado datos que afecten al hash (importes), me lo acepta.
• Tengo todos mis registros encadenados localmente y enviados a la AEAT.

Lo que no comprendo de este segundo caso es:
Si quisiera modificar datos que sí afectan al hash (como que el error sea que soy idiota y he puesto mal la cantidad de iva) y tuviese que modificarlo, por narices tendría que ponerle otro hash al registro. Pero esto no lo puedo hacer ya que, si lo cambio y tengo registros posteriores, la cadena quedaría rota.

Por otro lado en el caso de que los datos modificados fueran los del cliente (que no afectan al hash) sí que podría enviar el mismo)

Creo que el primer caso vale para cambiar tanto datos erroneos del cliete como datos erroneos de los importes, pero me queda la duda de la trazabilidad que tendría la AEAT respecto de mis registros...

En ambos casos, la AEAT me da el OK, pero no se si esto en un futuro puede afectar al usuario como contribuyente...

[juanluislopez89]

Cito textualmente el documento:

Cuando sea necesario subsanar la información de un registro de facturación de alta inicial, que ha sido rechazado (y que, por tanto, no existe aún en la AEAT), siempre y cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro mecanismo contempladoen el Reglamento de Facturación) ni se anule la factura, se deberá generar un nuevo registro “de subsanación” de alta inicial por rechazo, ya con los datos completos y correctos, que será enviado a la AEAT.
El registro original no se puede modificar, por lo que permanecerá inalterado.

En el nuevo registro subsanado se incluirá la propia huella (según las especificaciones dadas en el documento de huella de la sede electrónica de la AEAT) del registro de facturación. Como siempre, el encadenamiento debe ser con el registro de facturación inmediatamente anterior (sea de alta o de anulación), por orden cronológico de generación de registros de facturación en el SIF.

Por tanto esto me hace decantarme por que la primera opción es la correcta, marcando el registro durante su envío como:

<sum1:Subsanacion>S</sum1:Subsanacion>
<sum1:RechazoPrevio>X</sum1:RechazoPrevio>

Usando:

$correction->previousRejection = YesNoType::YES;

junto con la posibilidad de incluir Subsanación, propuesta en la pull request #44

¿Alguien que me pueda confirmar?

[popnoart]

Para ver si esta censado yo uso esta librería https://github.com/ibericode/vat
Cuando se revisa visualmente si está bien el borrador, tengo un botón para revisar campos de los datos fiscales y entre ellos el que este de alta si corresponde.

Lo que no comprendo de este caso es ¿Cómo es posible que la AEAT se trague un registro con un hash que depende de otro registro para ellos inexistente? Ya que en la documentacion mencionan que si un registro es rechazado no estará en sus servidores...

Totalmente, tenía la misma duda e hice la prueba a ver si rechazaba que estuviera encadenado a un regsitro que ellos han rechazado, y no, palante:-D

Para el segundo caso lo suyo es una rectificativa, tanto si afecta al hash como no. porque estas modifciando datos obligatorios de la factura(dirección, base...) Y aunque Verifactu sea un colador, sería mejro hacerlo así.

Realmente el caso que tu dices de subsanación, yo creo que sería más por temas técnicos de por ejemplo un xml mal formado o algo por el estilo.
Tengo que mirar mejor la documentación, los ejemplos, para ver cúales son los casos que nos podemos encontrar.

[popnoart]

He abierto wiki y discussions en el fork que tengo(es el de josemmo, pero es para tratar en general verifactu) por si os interesa trasladar allí estos temas y dejar libre los issues.
https://github.com/popnoart/josemmo.Verifactu-PHP/wiki

[Eseperio]

Ciero el hilo por tratarse de una pregunta y no un issue.