Procesos de Facturacion Automática

[jlmoli_67]

Empezado por Jesusggc

Claro encadenamiento de Registros de Facturacion (RF)

Cada RF nuevo debe encadenar con el anterior mediante el HASH (excepto el primer RF). Ese RF anterior es Segun OBLIGADO TRIBUTARIO + SIF (ID PRODUCTO INFORMATICO + NUMERO INTALACION).

En un mismo lote de envio podria ir entonces los registros de distintos sif (incluso mezclados entre si) mientras cada registro este encadenado por su correspondiente sif al que pertenece. Seria eso posible?

[Neftali [Germán.Estévez]]

Empezado por jlmoli_67

En un mismo lote de envio podria ir entonces los registros de distintos sif (incluso mezclados entre si) mientras cada registro este encadenado por su correspondiente sif al que pertenece. Seria eso posible?

Creo que no.
Cada SIF tiene que generar sus paquetes de envío y si un SIF trabaja con varios obligados tributarios, dividir esos RF por cada uno de los obligados tributarios.
No puedes mezclar en un envío cosas de diferentes SIF.

[bmfranky]

Empezado por jlmoli_67

En un mismo lote de envio podria ir entonces los registros de distintos sif (incluso mezclados entre si) mientras cada registro este encadenado por su correspondiente sif al que pertenece. Seria eso posible?

Hola, no , porque prima en el encabezado el cif del obligado a emitir la factura.

3.1.1 Validaciones de negocio del bloque Cabecera.
1. ObligadoEmision
- El NIF del obligado a expedir (emitir) facturas asociado a la remisión debe estar identificado
en la AEAT.

3.1.3 Validaciones de negocio de la agrupación RegistroAlta en el bloque de
RegistroFactura.
1. Agrupación IDFactura
El NIF del campo IDEmisorFactura debe ser el mismo que el del campo NIF de la
agrupación ObligadoEmision del bloque Cabecera.
- La FechaExpedicionFactura no podrá ser superior a la fecha actual.
- Si Impuesto = “01” (IVA), “03” (IGIC) o no se cumplimenta (considerándose “01” - IVA), la
FechaExpedicionFactura solo puede ser anterior a la FechaOperacion, si ClaveRegimen=
"14" o "15”.
- La FechaExpedicionFactura no debe ser inferior a 01/07/2024 (esta fecha podría cambiar en
función de la fecha de aprobación / publicación de la orden ministerial).
- NumSerieFactura solo puede contener caracteres ASCII del 32 a 126 (caracteres imprimibles)

Deven coincidir en CIF de las facturas , con el de la cabecera.
lo pone en el documento de validaciones.

[bmfranky]

Empezado por Neftali [Germán.Estévez]

Creo que no.
Cada SIF tiene que generar sus paquetes de envío y si un SIF trabaja con varios obligados tributarios, dividir esos RF por cada uno de los obligados tributarios.
No puedes mezclar en un envío cosas de diferentes SIF.

No, no se puede, lo acabo de explicar un poco mejor.

[Jesusggc]

Empezado por Neftali [Germán.Estévez]

Creo que no.
Cada SIF tiene que generar sus paquetes de envío y si un SIF trabaja con varios obligados tributarios, dividir esos RF por cada uno de los obligados tributarios.
No puedes mezclar en un envío cosas de diferentes SIF.

A ver, como yo lo entiendo, un SIF es un Sistema Informatico que puede facturar.

1 .- Imaginad un SaaS, el cual es el mismo SIF para todos los Obligados tributarios (OT) que utilizan el Saas.

De ahí que el encadenamiento deba ser por OT + SIF. Y el envío debe ser en bloque del mismo OT.

2 .- Otro caso sería una instalación local de 5 puestos contra un servidor local, con instalacion de la aplicacion independiente en cada puesto. Cada puesto puede facturar (Por lo tanto 5 SIF, ya que cada uno tiene diferente numero de instalación con igual id de producto) y son la misma empresa es decir el mismo OT. Aqui cada SIF encadeba sus RF y el servidor podría enviar los registros de todos en un mismo paquete (ya que son = OT).

Así es como yo lo entiendo.

Un saludo.

PD: Adjunto conversación con VERIFACTU:

Pregunta :
Buenos días

Los lotes de registros de facturación deben pertenecer al mismo SIF? . No se pueden mezclar de diferentes SIF?

Gracias

Un saludo. :-)

Respuesta :
Buenas tardes:

La restricción para envíos de un mensaje XML con diferentes registros, es a nivel de Cabecera por lo que la restricción estaría en el Obligado a la emisión de la factura, que debe ser el mismo en todos los registros.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

[delphiGar]

Empezado por jlmoli_67

En un mismo lote de envio podria ir entonces los registros de distintos sif (incluso mezclados entre si) mientras cada registro este encadenado por su correspondiente sif al que pertenece. Seria eso posible?

Es correcto, siempre que la cabecera sea la misma para todos los Registros de Facturacion de los distintos SIF que esten enviando en ese mismo paquete.

Los registros de alta o anulacion son independientes y por lo tanto no es necesario que sea el mismo SIF en el envio, no es lo mas comun, pero no da error, ya que cada registro pertenece a un SIF y tiene la misma cabecera.

Lo que si es que las huellas de un SIF y otro tienen que ser la de cada uno.

Tambien deben coincidir los NIF y en su caso la Denominacion de cada registro con la cabecera.

[jlmoli_67]

Empezado por delphiGar

Es correcto, siempre que la cabecera sea la misma para todos los Registros de Facturacion de los distintos SIF que esten enviando en ese mismo paquete.

Los registros de alta o anulacion son independientes y por lo tanto no es necesario que sea el mismo SIF en el envio, no es lo mas comun, pero no da error, ya que cada registro pertenece a un SIF y tiene la misma cabecera.

Lo que si es que las huellas de un SIF y otro tienen que ser la de cada uno.

Gracias.


He preguntado esto porque acabo de terminar el programa que envia a hacienda y que corre en segundo plano en cada sif y me preguntaba que quizas fuese mejor que ya que cada sif envia las ventas al servidor (que a su vez es otro sif) que este ultimo cogiera todo y lo enviara. Claro, para hacer esto , la cosa podria ir fluida si en un mismo lote de envio meto las ventas de cada sif, eso si,encadenando cada registro por el sif que lo creó. Por lo pronto se me ocurren dos cosas buenas 1) omito certificado en cada terminal tpv. Cada sif crea y encadena pero el envio lo va a hacer otro sif del obligado. 2) Las actuaciones para subsanar las puedo realizar en el servidor (sif que envia) de forma centralizada sobre todas las incidencias


que opinais? como lo haceis vosotros? LAs subsanaciones las teneis contempladas para que en cada sif al terminar el trabajo el cajero las realice?

Por cierto, he aplicado la idea que bmfranky dio en otro post sobre que a la hora de abrir el programa que envia consulte por el ultimo registro que se envio para evitar fallo y la verdad es que estoy muy contento con su aplicacion. Funciona muy bien.

muchas graciasl

[Jesusggc]

Empezado por jlmoli_67

Gracias.


He preguntado esto porque acabo de terminar el programa que envia a hacienda y que corre en segundo plano en cada sif y me preguntaba que quizas fuese mejor que ya que cada sif envia las ventas al servidor (que a su vez es otro sif) que este ultimo cogiera todo y lo enviara. Claro, para hacer esto , la cosa podria ir fluida si en un mismo lote de envio meto las ventas de cada sif, eso si,encadenando cada registro por el sif que lo creó. Por lo pronto se me ocurren dos cosas buenas 1) omito certificado en cada terminal tpv. Cada sif crea y encadena pero el envio lo va a hacer otro sif del obligado. 2) Las actuaciones para subsanar las puedo realizar en el servidor (sif que envia) de forma centralizada sobre todas las incidencias


que opinais? como lo haceis vosotros? LAs subsanaciones las teneis contempladas para que en cada sif al terminar el trabajo el cajero las realice?

Por cierto, he aplicado la idea que bmfranky dio en otro post sobre que a la hora de abrir el programa que envia consulte por el ultimo registro que se envio para evitar fallo y la verdad es que estoy muy contento con su aplicacion. Funciona muy bien.

muchas graciasl

Tb evitas que se queden RF sin Enviar (y por tanto sin cumplir el limite de los 120 seg)
si por ejemplo se hace factura al final del dia y sin enviar cierra la aplicacion y se va a casa. En este caso (si se envia desde el servidor) estaria controlado.

Por no hablar del control que hay que hacer de tiempo de espera, es mas facil si solo envia el servidor y no cada SIF

[sglorka]

Me parece interesante el tema que se está tratando en este hilo.
Yo entiendo que, para un mismo OT, se pueden empaquetar en el mismo mensaje todos los registros de Alta y Anulación generados por los SIF's de dicho OT. Estos registros estarán encadenados por SIF y se deberían enviar ordenados por fecha de creación de registro (aunque esto no creo que sea importante). Mi filosofía personal es que cada SIF debe generar y enviar sus propios registros independientemente de que envíe sus facturas posteriormente a un servidor central. ¿ Por qué ?, bueno uno de los puntos importantes que definen a un SIF y que el Reglamento deja bien claro es su capacidad de Remisión de Registros a la Aeat de forma continua, fiable, segura, etc., etc y si por algún casual tenemos conexión a Internet pero perdemos la conexión con el servidor (se ha caído), los SIF's que esperan que sus registros sean enviados de forma masiva por el servidor, quedarán huérfanos de envío, y por ende, de la capacidad de remisión (no comparar este caso con la de ceder la emisión a un tercero ). Se podría pensar que en estos casos, los SIF's reanudaran ellos su comunicación individual, pero tendríamos que llevar la gestión de lo que ha enviado el servidor de cada uno de ellos para no caer en duplicidades ni en un huecos de envío.
Además, si cada SIF envía su registros, sabe de primera mano, qué registros tiene aceptados y rechazados, y ante una hipotética emisión de una factura rectificativa por sustitución en dos pasos (primero abono y luego rectifico), sin la información de si el registro fue rechazo o no, tendríamos que discernir entre Anular y Rectificar (ya que la Aeat no tiene el registro) o Abonar y Rectificar ( la Aeat sí tiene el registro).
Aunque cada SIF emita sus propios registros, no se resta la capacidad al servidor central para realizar las operaciones de rectificación y subsanación de los registros de otros SIf's ya que éste (el servidor central) puede consultar el estado de los registros en la Aeat y actuar en consecuencia.
Con esta filosofía, siempre se cumplen los plazos de entrega.
Siento el rollo que os he metido pero es una forma que tengo ( escribir un pensamiento ) para poder verlo mejor y darme cuenta si caigo en alguna incongruencia.

[delphiGar]

Aunque no soy partidiario de mezclar los SIF, de hecho no lo hago, al final esto consiste en hacerte tu propio servicio de envio y respuesta de tus registros como si fuera un servicio de terceros, de tal forma que puedes enviar cualquier grupo de registros con su cabecera correspondiente y ser distintos OT y SIFs en cada envio, el tema esta en gestionarlo cuando recibas las respuestas, pero esto es mas tema de software y como queremos gestionarlo.

Por ejemplo: Podrias crearte un servicio que envie todos los registros de tus distintos SIF con sus correspondientes OT ( Como lo hace un servicio de terceros ).

O como el caso que plantean de distintos SIF con el mismo OT y que lo gestionen en uno central ( Entiendo que el envio y recepcion ). Ya que la subsanacion o rectificacion deberian hacerlo en su SIF correspondiente. Si lo hacen desde el central en la rectificacion deberian indicar el SIF del central y no de donde vino, por que esto si incurre en una ilegalidad. Ya que la instalacion desde donde se hace la subsamacion o rectificacion es la que se ha de indicar por veracidad.

[Jesusggc]

Yo pienso que la mejor opción serie el envío y recepción de respuesta se centralizase en un servicio (no estamos teniendo en cuenta el Tiempo de espera entre envíos, realmente no se si es por OT o por SIF (si es por SIF se me desmonta todo lo que estoy exponiendo)). Y que la rectificación y subsanación se realice por SIF.

Voy a poner consulta sobre los tiempos de espera.

[Jesusggc]

Yo pienso que la mejor opción serie el envío y recepción de respuesta se centralizase en un servicio (no estamos teniendo en cuenta el Tiempo de espera entre envíos, realmente no se si es por OT o por SIF (si es por SIF se me desmonta todo lo que estoy exponiendo)). Y que la rectificación y subsanación se realice por SIF.

Voy a poner consulta sobre los tiempos de espera.

[sglorka]

Sí, lo más coherente es que haya un servicio por cada SIF corriendo en segundo plano gestionando los envíos y respuestas. Creo recordar que en el reglamento se hacía referencia a que cada SIF debería presentar a los usuarios, entre otras cosas, los registros que tiene pendiente de enviar, los que tiene rechazados, etc. Centralizar los envíos en un sólo SIF de todos los SIF's del OT, aunque pueda parecer más efectivo, en términos de claridad e independencia podría acarrear más problemas que beneficios. El tema de tener los certificados dispersos en cada SIF, por si le sirve a alguien, como estamos hablando del mismo OT, yo defino un FTP donde hay una carpeta de Certificados, cada SIF del mismo OT accede a este Ftp de forma programada por si se tiene que bajar e instalar un certificado más actualizado que el que tiene en ese momento.

[RUBEN_SP]

Empezado por jlmoli_67

Gracias.


Por cierto, he aplicado la idea que bmfranky dio en otro post sobre que a la hora de abrir el programa que envia consulte por el ultimo registro que se envio para evitar fallo y la verdad es que estoy muy contento con su aplicacion. Funciona muy bien.

muchas graciasl

A qué aplicación te refieres? Dónde está el código?

[Neftali [Germán.Estévez]]

Empezado por RUBEN_SP

A qué aplicación te refieres? Dónde está el código?

Revisa el primer hilo de este foro:
https://www.clubdelphi.com/foros/showthread.php?t=97004

[RUBEN_SP]

Empezado por Neftali [Germán.Estévez]

Revisa el primer hilo de este foro:
https://www.clubdelphi.com/foros/showthread.php?t=97004

Vale gracias, esa ya la conocía creía que se refería a otra