Procesos de Facturacion Automática
 

Buenas he puesta esta consulta. A ver que que cuentan:

Cuando se salva cada factura se crea el registro de facturación y ya se puede enviar. No hace falta esperar a que se haya terminado todo el "proceso de facturación automático" que comentas para enviarlas todas, no?

A ver que contestan

Ya pero si me tengo que esperar 60 seg para realizar el siguiente envío.

De ahí la duda

Gracias

Tendras que implementar un temporizador, que acumule durante por ejemplo 120" (y menos de 1000 registros), las facturas generadas y enviarlas de golpe,reinicias el contador, asi hasta que las envies todas.

Mandalo a un servicio en segundo plano a medida que la vas generando y programa bien el servicio para que envie, si has enviado al menos una, el sevicio como tiene que esperar 60 segundos y así sucesivamente se acaba el problema

De hecho, esto que describes es lo que ellos llaman control de flujo

Bueno sí, pero el significado de control de flujo sabemos que no es ese o más bien que es para otra cosa, dispositivos serie.
Pero ya está, aceptamos pulpo como animal de compañía, el scattergories es de ellos.

Gracias, no se me había ocurrido esta alternativa

Por cierto, en una instalación multipuesto (distintos SIF), como lo estáis contemplando, todos envían? o limitais el envío a un equipo (por ejemplo el servidor)

Gracias de nuevo

Mejor cada sif. Te vas a liar mucho centralizando con los tiempos de envío. Pero lo que te quieras complicar. Ten en cuenta que aunque lo envíes desde uno centralizado tienes que enviar en distintos paquetes, no puedes mezclar en el mismo envío, y ya se te complica un pelin

Buenas ermendalenda

Tu respuesta me dejó pensando sobre el tema de en un paquete solo registros del mismo SIF y como no encontré nada sobre esto en la documentación puse consulta :

Respuesta :

Si esto es así simplifica mucho el tema del envío centralizado.

Pues sí parece que me llo he inventado, juraría que hablaron de que indexaban por cada sif para esta cuestión de meter en cada soap registros de distintas series pero del mismo sif peor ya veo que no He estado buscando en el reglamento técnico, webnimar y varios documentos y no sé de donde lo he sacado. Lo siento
Y además mejor por que es un lio para las empresas que emitan miles de registros y quieran centralizar la remisión.
Pues has hecho muy bien en realizar la consulta y sacar el tema.

Si te fijas en el XML que se genera para enviar, la información del SIF va en cada Registro de facturación (ya sea de Alta o Anulación) si fuese como decíamos la info del SIF deberia estar en la Cabecera al igual que los datos del Obligado.

Bueno, mejor así.

Gracias.

Estoy dándole vueltas, que si puedes enviar en el mismo paquete todo lo del mismo CIF, lo mismo debe suceder si envías como tercero, podrás mezclar todos los clientes que te han autorizado a enviar el su nombre.

Si porque si te fijas en cada nodo registro alta/baja, se identifica al que emite la factura, siendo independiente del que envia el paquete, que si puede ser un tercero, y ese si que puede liarla parda con envios de 1000 cada pocos segundos....

Si pero cada lote de registros pertenece a cada obligado por su cabecera desde se indica nif/CIF del obligado

Respecto a las facturas automáticas o importación de "facturas" (temporales) de otro sistema, le voy a meter un retardo de mínimo un segundo entre factura y factura, que coincidan en tiempo no me mola mucho, no sé si puede dar problemas.

Buenas, Tengo una duda....


Si un servidor puede ser el que al final envie todo lo que se hace en los terminales en vez de estos enviar lo suyo por su cuenta y si el encadenamiento debe de hacerse por fecha de creacion del registro de venta .....¿no se podria dar el caso que una vez encadenados y enviados por el servidor un terminal enviase un documento con fecha anterior a la ultima enviada? ¿ tendria alguna consecuencia?...,.¿me estoy liando?

El encadenamiento es por Obligado tributario y SIF (Sistema Informático que puede Facturar). El SIF lo compone (Id sistema informático + numero instalación sistema informático).

Yo para generar el "numero instalación sistema informático" utilizo el nº de placa del PC + Fecha + HHmmss.

¿El encadenamiento del que hablais no es el del RF? porque ya he leido en dos hilos diferentes me parece el tema del sistema informatico dentro de él, en el RF lo que entiendo y veo es que el apartado de encadenamiento tiene los siguientes campos:

PrimerRegistro
RegistroAnterior
IDEmisorFactura
NumSerieFactura
FechaExpedicionFactura
Huella

El sistema informatico es otro bloque con la información pertinente.

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?

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.

Hola, no , porque prima en el encabezado el cif del obligado a emitir la factura.
Deven coincidir en CIF de las facturas , con el de la cabecera.
lo pone en el documento de validaciones.

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

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:

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.

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

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.

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.

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.

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.

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.

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

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