Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)

[CarlosR]

Empezado por Sistel

Hola,

Tengo unos 150 bazares chinos como clientes en TicketBAI.
Y todos ellos emiten todos sus tickets con el correspondiente QR de TicketBAI.

Mis clientes chinos son mucho más cumplidores que la media del resto de clientes.

Saludos

Totalmente de acuerdo. Tampoco les queda otra, como a los demás.

[bmfranky]

Empezado por CarlosR

El concepto de prefactura/borrador de factura/etc.etc no es mas que un espacio donde puedas aglutinar albaranes hasta ver el resultado. ES AL VALIDAR la prefactura cuando se crea una factura (documento distinto) con movimientos contables, cartera y un nuevo registro en la tabla verifactu o como quieras llamarla. La factura generada es un nuevo documento con su fecha-hora del momento de creación y que se lleva dicha fecha-hora al nuevo registro de verifactu. La factura y el registro en verifactu coinciden. El documento prefactura en este momento ya no existe. No importa la fecha-hora de la prefactura porque a nadie de la AEAT le molesta un documento que no tienen ni por qué conocer.

No va a funcionar si quieres usar el mismo documento de factura con un contador también de prefactura porque distorsionarías la fecha de creación del registro, entre otras cosas.

El concepto de fecha-hora es muy importante. No sirve solo con leer la fecha del sistema central y usarla. Se debería tener mecanismos de actualización automática con algún servidor de tiempo externo. Esa fecha-hora será luego analizado por la AEAT para ver si se cumplen normas.

No se si me explico.
Este tema ya lo traté hace unos meses, podeis repasar el foro.





Saludos.

Hola, saludos, estamos diciendo los 2 lo mismo, queriendo tener razon...

[jguarda]

Yo perdoname pero no me entero.


Vamos a suponer un cajero de mercadona que puede ser el que más movimientos tenga en 60 segundo, mas o menos, una factura simplificada como mucho.


Según esta gente, para enviar, hay 2 posibilidades.
1.- consumir el tiempo ( t ) y proceder a enviar lo que tengas.
2- consumir 1000 operaciones antes de que se cumpla el tiempo (t), quien cojones hace 1000 facturas simplificadas en 60 sg, 120 sg, o lo que cojones quieras poner.


Es decir, como es incontrolable, como dijo uno de otro foro, yo haré lo que el, cada 10 minutos miro, y envio lo que tenga y punto pelota.


Eventos.
Para generar el evento de que se me ha ido el suministro electrico, como lo haria el que tiene que emitir las facturas, crearia el un XML con dicho evento a pelo en un TXT y cuando vuelva el suministro enviarselo a la AEAT.


No entiendo como se puede implementar esto en determinados casos. ( que serán muchos )., el router no furula, no tengo suministro electrico, le han pegado una pata al cable y no saben que pasa, no me enciende el monitor y no tengo otro .. un monton de casuisticas incontrolables. .... como se genera el evento de errores ???

[ermendalenda]

Empezado por jguarda

Yo perdoname pero no me entero.


Vamos a suponer un cajero de mercadona que puede ser el que más movimientos tenga en 60 segundo, mas o menos, una factura simplificada como mucho.


Según esta gente, para enviar, hay 2 posibilidades.
1.- consumir el tiempo ( t ) y proceder a enviar lo que tengas.
2- consumir 1000 operaciones antes de que se cumpla el tiempo (t), quien cojones hace 1000 facturas simplificadas en 60 sg, 120 sg, o lo que cojones quieras poner.


Es decir, como es incontrolable, como dijo uno de otro foro, yo haré lo que el, cada 10 minutos miro, y envio lo que tenga y punto pelota.


Eventos.
Para generar el evento de que se me ha ido el suministro electrico, como lo haria el que tiene que emitir las facturas, crearia el un XML con dicho evento a pelo en un TXT y cuando vuelva el suministro enviarselo a la AEAT.


No entiendo como se puede implementar esto en determinados casos. ( que serán muchos )., el router no furula, no tengo suministro electrico, le han pegado una pata al cable y no saben que pasa, no me enciende el monitor y no tengo otro .. un monton de casuisticas incontrolables. .... como se genera el evento de errores ???

No hay que enviar eventos ni es obligatorio generarlos en tu sistema si estás enviando.
Si tienes una incidencia marcas el registro como incidencia y ya lo mandaras cuando se pueda.
Los 1000 registros se puede dar en los casos en los que un obligado tributario centraliza los envios a través de un servidor (lo he descubierto hoy en el foro)
Normalmente no puedes/debes mandar fuera de los tiempos que te indican
Si te dicen que mandes en 60segundos, llegado ese momento manda lo que tengas, te Dan unos segundos para enviarlo, aunque lo acepten fuera de ese tiempo te van poner una "x" como en el cole(es metaforico)cada vez que lo hagas
No se cuantas "x" te dejaran acumular para que no sea leve. O sea si pasa de vez en cuando y tienen mucho trabajo no creo que te digan nada, y creo que no se van a aburrir durante una larga temporada, aunque seguro automatizan algún aviso al correo.

[bmfranky]

Empezado por jguarda

Yo perdoname pero no me entero.


Vamos a suponer un cajero de mercadona que puede ser el que más movimientos tenga en 60 segundo, mas o menos, una factura simplificada como mucho.


Según esta gente, para enviar, hay 2 posibilidades.
1.- consumir el tiempo ( t ) y proceder a enviar lo que tengas.
2- consumir 1000 operaciones antes de que se cumpla el tiempo (t), quien cojones hace 1000 facturas simplificadas en 60 sg, 120 sg, o lo que cojones quieras poner.


Es decir, como es incontrolable, como dijo uno de otro foro, yo haré lo que el, cada 10 minutos miro, y envio lo que tenga y punto pelota.


Eventos.
Para generar el evento de que se me ha ido el suministro electrico, como lo haria el que tiene que emitir las facturas, crearia el un XML con dicho evento a pelo en un TXT y cuando vuelva el suministro enviarselo a la AEAT.


No entiendo como se puede implementar esto en determinados casos. ( que serán muchos )., el router no furula, no tengo suministro electrico, le han pegado una pata al cable y no saben que pasa, no me enciende el monitor y no tengo otro .. un monton de casuisticas incontrolables. .... como se genera el evento de errores ???

Hola, sin ofender esta mezclando conceptos, no es acumular 1000 registros en 60/120 segundos, es acumular los que tengas , hasta un "Maximo" de 1000 registros, que pueden ser de alta, baja o rectificaciones y enviar minimo entre 60-180" , las cajas de mercadona/carrefour, deverian emitir los tiquets desde un servidor central, que es el que gestiona stocks, precios de articulos, y demas, las cajas en si son puntos de acceso al servidor central, ellos casi lo tienen mas facil con los plazos, pueden emitir 300 tiquets cada 60 segundos sin despeinarse... o un corte ingles, cuantas cajas centralizadas tienen, me asustan los numeros solo de pensarlo.
El tiempo lo consideraran por si imagine, hay 100000 de SIF, que envian 100 tiquets cada 60 segundos sin parar, al final pueden genera un DOS, entonces espacian los envios para generar menos conexiones por segundo, y poder atender la demanda, o desde mi punto de vista , es la explicacion mas plausible.
En cuanto a como atender los errores de envio, por las diferentes razones es lo que tiene que programar , ya sea automatica o manualmente.
Si el router , no funciona, no hay conexion con acienda, tiene que crear un servicio automatico, que en el momento de restablecerse la conexion, envie los registros pendientes, sea 1 ,10 o 1000, si son mas, pues dividir en varios paquetes.

Por cierto, por desgracia, para lo que se nos viene encima, hay que proveerse de Sais y opciones redundantes de envio, por contemplar posibles caidas del la red.

[CarlosR]

Empezado por ermendalenda

No hay que enviar eventos ni es obligatorio generarlos en tu sistema si estás enviando.
Si tienes una incidencia marcas el registro como incidencia y ya lo mandaras cuando se pueda.
Los 1000 registros se puede dar en los casos en los que un obligado tributario centraliza los envios a través de un servidor (lo he descubierto hoy en el foro)
Normalmente no puedes/debes mandar fuera de los tiempos que te indican
Si te dicen que mandes en 60segundos, llegado ese momento manda lo que tengas, te Dan unos segundos para enviarlo, aunque lo acepten fuera de ese tiempo te van poner una "x" como en el cole(es metaforico)cada vez que lo hagas
No se cuantas "x" te dejaran acumular para que no sea leve. O sea si pasa de vez en cuando y tienen mucho trabajo no creo que te digan nada, y creo que no se van a aburrir durante una larga temporada, aunque seguro automatizan algún aviso al correo.

1º Ese tiempo (t) es el tiempo que debe esperar entre envíos.
2º Después de ese (t) que son 60 segundos actualmente o eso se espera, cuando junte 1000 registros ya puede enviarlos.

3º Si en un plazo de 2 horas -insisto- no ha juntado 1000 registros entonces ha de enviar lo que tenga. Este punto ya se ha discutido anteriormente y mientras no vea un documento oficial que lo desmienta me quedo con estos datos.
4º Si junta 1000 registros cada 60 segundos en una única instalación entonces es una gran empresa. Caso que hizo alusión a Mercadona, aunque este no sería un caso representativo porque cada instalación según yo recuerdo tiene los datos por separado y luego sube tablas todos los días hacia una base de datos general. Lo que indica que el verifactu tendrá que usarlo por instalación. 1000 registros cada 60 segundos sería algo así como 24000 registros por día. dudo que los tenga un Mercadona. Pero le pondré un caso que si los tiene, por ejemplo Telefónica que tiene la facturación centraalizada en un solo sitio.

5º De cualquier modo me da la impresión de que estas grandes empresas optarán por el NO veri*factu. Eso es una conclusión que saco yo, nada mas. Encima los responsables serán ellos mismos porque el fabricante o bien son ellos mismos o bien tendrán sendos contratos con alguna firma de renombre para delegar la responsabilidad desde el fabricante al cliente.
6º Los eventos (creo) hay que tenerlos disponibles en las dos modalidades tanto veri*factu como NO veri*factu, otra cuestión es que se suban a la AEAT. -Si estoy confundido que alguien me corrija por favor-
7º Caso de NO veri*factu: No se suben los registros uno a uno, solo se suben los registros que solicite por requerimiento la AEAT. También pueden exigir subir los registros de eventos.


No sé si alumbraré o crearé mas oscuridad con este post, espero que sea lo primero.


Saludos.

[CarlosR]

Empezado por CarlosR

1º Ese tiempo (t) es el tiempo que debe esperar entre envíos.
2º Después de ese (t) que son 60 segundos actualmente o eso se espera, cuando junte 1000 registros ya puede enviarlos.

3º Si en un plazo de 2 horas -insisto- no ha juntado 1000 registros entonces ha de enviar lo que tenga. Este punto ya se ha discutido anteriormente y mientras no vea un documento oficial que lo desmienta me quedo con estos datos.
4º Si junta 1000 registros cada 60 segundos en una única instalación entonces es una gran empresa. Caso que hizo alusión a Mercadona, aunque este no sería un caso representativo porque cada instalación según yo recuerdo tiene los datos por separado y luego sube tablas todos los días hacia una base de datos general. Lo que indica que el verifactu tendrá que usarlo por instalación. 1000 registros cada 60 segundos sería algo así como 24000 registros por día. dudo que los tenga un Mercadona. Pero le pondré un caso que si los tiene, por ejemplo Telefónica que tiene la facturación centraalizada en un solo sitio.

5º De cualquier modo me da la impresión de que estas grandes empresas optarán por el NO veri*factu. Eso es una conclusión que saco yo, nada mas. Encima los responsables serán ellos mismos porque el fabricante o bien son ellos mismos o bien tendrán sendos contratos con alguna firma de renombre para delegar la responsabilidad desde el fabricante al cliente.
6º Los eventos (creo) hay que tenerlos disponibles en las dos modalidades tanto veri*factu como NO veri*factu, otra cuestión es que se suban a la AEAT. -Si estoy confundido que alguien me corrija por favor-
7º Caso de NO veri*factu: No se suben los registros uno a uno, solo se suben los registros que solicite por requerimiento la AEAT. También pueden exigir subir los registros de eventos.


No sé si alumbraré o crearé mas oscuridad con este post, espero que sea lo primero.


Saludos.

Se nota que acabo de levantarme y aún no tomé un café. Im Sorry.
1000 registros cada 60 segundos sería algo así como 86,400,000 registros día.
Una gran cantidad, sin duda.

[bmfranky]

Empezado por CarlosR

1º Ese tiempo (t) es el tiempo que debe esperar entre envíos.
2º Después de ese (t) que son 60 segundos actualmente o eso se espera, cuando junte 1000 registros ya puede enviarlos.

3º Si en un plazo de 2 horas -insisto- no ha juntado 1000 registros entonces ha de enviar lo que tenga. Este punto ya se ha discutido anteriormente y mientras no vea un documento oficial que lo desmienta me quedo con estos datos.
4º Si junta 1000 registros cada 60 segundos en una única instalación entonces es una gran empresa. Caso que hizo alusión a Mercadona, aunque este no sería un caso representativo porque cada instalación según yo recuerdo tiene los datos por separado y luego sube tablas todos los días hacia una base de datos general. Lo que indica que el verifactu tendrá que usarlo por instalación. 1000 registros cada 60 segundos sería algo así como 24000 registros por día. dudo que los tenga un Mercadona. Pero le pondré un caso que si los tiene, por ejemplo Telefónica que tiene la facturación centraalizada en un solo sitio.

5º De cualquier modo me da la impresión de que estas grandes empresas optarán por el NO veri*factu. Eso es una conclusión que saco yo, nada mas. Encima los responsables serán ellos mismos porque el fabricante o bien son ellos mismos o bien tendrán sendos contratos con alguna firma de renombre para delegar la responsabilidad desde el fabricante al cliente.
6º Los eventos (creo) hay que tenerlos disponibles en las dos modalidades tanto veri*factu como NO veri*factu, otra cuestión es que se suban a la AEAT. -Si estoy confundido que alguien me corrija por favor-
7º Caso de NO veri*factu: No se suben los registros uno a uno, solo se suben los registros que solicite por requerimiento la AEAT. También pueden exigir subir los registros de eventos.


No sé si alumbraré o crearé mas oscuridad con este post, espero que sea lo primero.


Saludos.

Hola, buenos dias, con todo el respeto, continua juntando churras, con merinas.
Continua insistiendo que ha de juntar 1000 registros para el envio, cuando lo que le indican que puede juntar un maximo de 1000, la obligatoriedad es de emitir , en los verifactu , en los siguientes 120segundos de la creacion del registro o si ha acumulado 1000.

3. Esquema general de funcionamiento.
...
...

El número máximo de registros por envío es de 1.000.



2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.
El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.
El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».

Puede leerlo en la descripcion del servicio web https://www.agenciatributaria.es/sta...pcion_SWeb.pdf
Este es el documento oficial que rige los envios, cual es el otro que usted ha consultado?

[CarlosR]

En respuesta a uno de los últimos post que hacían alusión a una participación mía sobre el famoso (t)




1º Si se fija en lo que yo he escrito verá que he hablado de que al juntar 1000 registros debe enviar. Ergo es un máximo. Apartado 4.
2º que si ha llegado a un período de 2 horas sin juntar 1000 (máximo por envío) registros debe enviar lo que tenga. Apartado 3.
Lo tiene en mi post.

Con respecto al link que usted me ha propuesto leer...

Página 24 de su documento reseñado : bajo el item TiempoEsperaEnvio ... "Segundos de espera entre envíos.
Para poder realizar el siguiente envío, el sistema
informático deberá esperar a que transcurran
<TiempoEsperaEnvio> segundos desde el anterior envío
o deberá esperar a tener acumulados un número de
registros de facturación igual al límite establecido en el
diseño de registro para cada envío, la circunstancia que
ocurra primero"

Página 26 de su documento reseñado : Bajo el epígrafe 6.3.1.1.Mecanismo de control de flujo.
Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.

un link de esa pregunta hecha ya en abril de este mismoo año ...
http://www.clubdelphi.com/foros/showthread.php?p=555426

Aunque ahora ya no hay pdf colgados en la página de la AEAT atrasados, creo recordar (y tendría que revisar en los pdf impresos) que se especificaba que el tiempo (t) podría variar en función de la saturación de datos de la propia AEAT.
Actualmente es 60 segundos. Por eso indiqué en mi post en el apartado 2 que son 60 actualmente, en el futuro dependerá de la propia AEAT.

De todos modos si en algo estoy errado, por favor, indíquemelo para poder corregir mi código a tiempo. Ya llevo cambiado muchas veces el código desde que salió el primer borrador de proyecto de Ley. Por ello no sería la primera vez.

Gracias de antemano.


"Errar es de humanos, rectificar es de sabios"

[CarlosR]

Página 26 del PDF reseñado anteriormente.

a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».


Después de darle vueltas a esto creo que tengo que rectificar mi concepto de 2 horas por el famoso (t) que devuelve la AEAT.

Creo que el usuario ermendalenda me lo decía así ayer.

¿ Es así ?

Gracias de antemano.

[bmfranky]

Empezado por CarlosR

En respuesta a uno de los últimos post que hacían alusión a una participación mía sobre el famoso (t)




1º Si se fija en lo que yo he escrito verá que he hablado de que al juntar 1000 registros debe enviar. Ergo es un máximo. Apartado 4.
2º que si ha llegado a un período de 2 horas sin juntar 1000 (máximo por envío) registros debe enviar lo que tenga. Apartado 3.
Lo tiene en mi post.

Con respecto al link que usted me ha propuesto leer...

Página 24 de su documento reseñado : bajo el item TiempoEsperaEnvio ... "Segundos de espera entre envíos.
Para poder realizar el siguiente envío, el sistema
informático deberá esperar a que transcurran
<TiempoEsperaEnvio> segundos desde el anterior envío
o deberá esperar a tener acumulados un número de
registros de facturación igual al límite establecido en el
diseño de registro para cada envío, la circunstancia que
ocurra primero"

Página 26 de su documento reseñado : Bajo el epígrafe 6.3.1.1.Mecanismo de control de flujo.
Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.

un link de esa pregunta hecha ya en abril de este mismoo año ...
http://www.clubdelphi.com/foros/showthread.php?p=555426

Aunque ahora ya no hay pdf colgados en la página de la AEAT atrasados, creo recordar (y tendría que revisar en los pdf impresos) que se especificaba que el tiempo (t) podría variar en función de la saturación de datos de la propia AEAT.
Actualmente es 60 segundos. Por eso indiqué en mi post en el apartado 2 que son 60 actualmente, en el futuro dependerá de la propia AEAT.

De todos modos si en algo estoy errado, por favor, indíquemelo para poder corregir mi código a tiempo. Ya llevo cambiado muchas veces el código desde que salió el primer borrador de proyecto de Ley. Por ello no sería la primera vez.

Gracias de antemano.


"Errar es de humanos, rectificar es de sabios"

Hola, saludos, primero que nada aclarar que no tengo ninguna vendeta contra usted,simplemente es ayudar.
Lo que le insisto es en que su codigo a de remitir pseudo inmediatamente(Despues de un tiepo demomento t minimo de 60" y menor a t + 120") , los datos del/los registro-os/factura-as generada-as, sin demoras mas alla de 120", a no ser por causa externas al programa en uso, y si se produce esa demora marcar incidencia, para en principio evitar el error por exceso de tiempo de generacion, tenga en cuenta que el tiempo maximo antes del envio se cuenta desde que asigna el TimeStamp TipoHoraGeneracionRegistro.
Realmente ,en los primeros borradores tenian en cuenta qu en principio o se gestionarian los envios por tiempo o numero de registros, ahora se gestiona solo por tiempo.

[bmfranky]

Empezado por CarlosR

Página 26 del PDF reseñado anteriormente.

a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».


Después de darle vueltas a esto creo que tengo que rectificar mi concepto de 2 horas por el famoso (t) que devuelve la AEAT.

Creo que el usuario ermendalenda me lo decía así ayer.

¿ Es así ?

Gracias de antemano.

Hola, si , lo de las 2 horas ya no es asi ,creo que desde la version 0.2 del servicio, ahora ay que enviar en t>envio<t+120" despues de crear o encadenar los registros, si envia varios , tenga en cuanta que los 120 segundos empiezan a contar desde el primer timestamp.

[CarlosR]

Empezado por bmfranky

Hola, saludos, primero que nada aclarar que no tengo ninguna vendeta contra usted,simplemente es ayudar.
Lo que le insisto es en que su codigo a de remitir pseudo inmediatamente(Despues de un tiepo demomento t minimo de 60" y menor a t + 120") , los datos del/los registro-os/factura-as generada-as, sin demoras mas alla de 120", a no ser por causa externas al programa en uso, y si se produce esa demora marcar incidencia, para en principio evitar el error por exceso de tiempo de generacion, tenga en cuenta que el tiempo maximo antes del envio se cuenta desde que asigna el TimeStamp TipoHoraGeneracionRegistro.
Realmente ,en los primeros borradores tenian en cuenta qu en principio o se gestionarian los envios por tiempo o numero de registros, ahora se gestiona solo por tiempo.

No hombre no, no considero que haya ensañamiento y alevosía, faltaría mas.

Es mas, agradezco las contribuciones de otros.

Hay dos formas de hacer un proyecto, bueno tres. He hecho unos cuantos desde cero a lo largo de mi carrera profesional.

1- Buscando apoyo de consultroes externos. (pagando y a veces no poco), doy fe.

2- Buceando en foros y compartiendo tiempo y esfuerzo de gente que tenga experiencia.
3- Inventándose las normas.
El primero tiene un coste. El tercero no va.
El segundo es muy viable si estás en el foro adecuado.
Para nada me ofende hombre, todo lo contrario.
No he visto a nadie en el canal con afán de ofender. Solo he visto gente colaborativa.
Otra cuestión es el estado de ánimo que uno tenga en un momento dado.


Saludos a todos !

[novatico]

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

[bmfranky]

Empezado por novatico

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

Hola, si seguro, pero como es el que tenemos al lado de casa, pues nos sale solo...

[bmfranky]

Empezado por CarlosR

No hombre no, no considero que haya ensañamiento y alevosía, faltaría mas.

Es mas, agradezco las contribuciones de otros.

Hay dos formas de hacer un proyecto, bueno tres. He hecho unos cuantos desde cero a lo largo de mi carrera profesional.

1- Buscando apoyo de consultroes externos. (pagando y a veces no poco), doy fe.

2- Buceando en foros y compartiendo tiempo y esfuerzo de gente que tenga experiencia.
3- Inventándose las normas.
El primero tiene un coste. El tercero no va.
El segundo es muy viable si estás en el foro adecuado.
Para nada me ofende hombre, todo lo contrario.
No he visto a nadie en el canal con afán de ofender. Solo he visto gente colaborativa.
Otra cuestión es el estado de ánimo que uno tenga en un momento dado.


Saludos a todos !

Si,si, doy fe al estado de animo, ayer encadene una de "Clientes" amables , que cuando llegue a casa parecia un pisonn de carretera, rebotando...

[ermendalenda]

Empezado por novatico

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

Hola
Si emites 2 tiques dentro del mismo minuto y sólo envías 1 cuando envíes el segundo estará fuera de tiempo y te dará el error 2004 mejor manda todo lo qie tebgas en el mismo paquete

Hay ejemplos más claros que mercadona, hay muchos negocios que emiten tiques más rápidos que un supermercado. Por ejemplo una autopista, una panadería, algun tipo de negocios de juegos...

[antoine0]

Empezado por CarlosR

Se nota que acabo de levantarme y aún no tomé un café. Im Sorry.
1000 registros cada 60 segundos sería algo así como 86,400,000 registros día.
Una gran cantidad, sin duda.

Más aún si tienes en cuenta que la empresa debe realizar menos de 6,012 millones de euros de facturación anual (en contrario pasaría al SII).

[sglorka]

Yo creo que como resumen para el tema de control de flujo, deberíamos estar de acuerdo en que cada "t" segundos se mira lo que está pendiente de enviar y se envía todo hasta la cantidad de 1000 registros como máximo. Luego actualizamos el valor de "t" que nos devuelve la última comunicación y volvemos a proceder de la misma manera

[sglorka]

Obviamente, para los que envían los registros de 1 en 1, los primeros registros sería Aceptados (si procediera) y el resto le respondería Aceptado con errores por exceso de tiempo