Una empresa que genere mas de 1000 tickets por minuto seguramente estará acogida al SII, difícilmente entre en verifactu.

Seguramente, pero un detalle.
Segun esto, al llegar a los 1000 registros hay que enviar si o si, sin esperar el tiempo.
Nadie de los que realizais envios masivos, ha hecho la consulta?
Aparte que los que seguramente lleguen a esa cifra, seran los que realicen envios por 3ºs , se me ocurre por ejemplo una, gestoria que c entralice los envios de facturas de sus clientes.

Todavía no está claro que un grupo de empresas o una asesoría, o un intermediario.. no pueda enviar como tercero a todas las del grupo,en un lote, ya se sabe?

Si tengo un paquete que no se ha podido enviar en tiempo por algún motivo técnico. Falta de luz, internet, fallo de ordenador.

Cuando envió el xml pendiente tengo que marcar incidencia en S en ese xml y seguir con normalidad supongo. La incidencia es S o N, no se indica texto descriptivo de la misma.

Corrijo el original, aunque lo tengo en la cabeza, no me he explicado bien.

El PROCESO 2 envía lo que hay en la cola con el límite de paquetes de 1000. Y diría que si envía 1000, no hay que esperar para enviar el resto. Es decir, al enviar paquetes de 1000, la restricción de tiempo para enviar el siguiente paquete desaparece (justo para evitar esto).
Por otro lado, empresas que envían un volumen muy grande pueden solicitar que los límites de tiempo (sólo para ellos) no afecten, justo para estos temas. Pero son excepciones que se han de solicitar a la AEAT.

En esos casos hay que comunicarlo a hacienda (si los volúmenes de la empresa son muy grandes) y hay excepciones. En esos casos para esa empresa se varía el tema de los límites para evitar estos problemas.

Del documento de Preguntas Frecuentes:

En relación con lo 2º (número de OT gestionados por el SIF), si un SIF permite la gestión de la facturación de varios OT (como puede ser el caso de un SIF utilizado por una gestoría para llevar en él la facturación de varios OT que son clientes de esa gestoría), dicho SIF deberá tener una cadena independiente por cada OT cuya facturación gestione.


Yo creo que esto supone envíos independientes.

Bueno, realmente la cadena de emvios(encadenamiento) puede ser independiente a que se envíe en el mismo paquete(soap)

¿ Y si lo combinas con esta otra pregunta respondida ?

¿A qué nivel se debe realizar la trazabilidad exigida en el reglamento y la orden «de requisitos de los sistemas informáticos de facturación (SIF)»: obligado tributario (OT), tienda, terminal punto de venta (TPV)…?

Los registros de facturación (RF) se deben encadenar de forma independiente dentro de cada SIF, y para cada OT (en el caso de que el SIF gestione la facturación de varios OT). Es decir, debe existir una única cadena de RF por cada par de valores distintos de (SIF; OT).
Por lo tanto, la respuesta a esta pregunta dependerá de cómo tenga organizado cada OT su forma de facturar y del número de OT cuya facturación se gestione en cada SIF empleado.
En relación con lo 1º (la organización de la forma de facturar por parte del OT), por ejemplo, si un OT dispone de varios TPV (en uno o diversos centros de venta, o tiendas) que expiden o gestionan la expedición de sus propias facturas de forma independiente a las del resto de TPV, cada TPV se considera que es un SIF, de acuerdo a la definición dada en el reglamento, así que deberá poseer su propia cadena de RF. De esta manera, el OT tendrá tantas cadenas de RF como TPV tenga.
En relación con lo 2º (número de OT gestionados por el SIF), si un SIF permite la gestión de la facturación de varios OT (como puede ser el caso de un SIF utilizado por una gestoría para llevar en él la facturación de varios OT que son clientes de esa gestoría), dicho SIF deberá tener una cadena independiente por cada OT cuya facturación gestione.

Me da la impresión que se refieren a envíos independientes, además recuerda que en la cabecera del envío, que es única, van los datos del OT.

Ahi tampoco veo relacion de envio con encadenamientos.
Si estas generando los registros y lo envias a una central para que lo gestione (Por ejemplo como tercero) la pregunta es como puede enviar dichos registros ese tercero.
Por que para el tercero se le puede complicar como tenga que crear muchas hileras de envios.
Entonces el tercero, tiene que enviar un soap por cada obligado?, por que está claro que agrupar por obligados es lo mínimo, no creo que haya que hacer un soap por cada SIF.
Si tienes una empresa dedicada a dar el servicio de envio como tercero y tienes muchos clientes, crear multiples tareas para enviar los soaps y controlar los tiempos de cada uno no lo veo muy sensato.
Yo se que ya han hecho la pregunta de que se puede enviar varios sifs del mismo obligado en el mismo soap, la duda es si al enviar como tercero tiene el mismo tratamiento. Como no es un tema que me afecte, tampoco voy a preguntar, ya bastante les pregunto

Te entiendo, a mí, tras enviar una consulta, me han llegado a llamar por teléfono para comentarla y resolverla, y aunque me dijeron que la respuesta también me la mandarían por escrito, no ha sido así. Por eso no la he publicado. Creo que también se han hartado de mí.

Nos va a llegar la complementaria a unos cuantos:D
Esta semana les doy descanso.

El trabajo que les estamos haciendo como beta testers no tiene precio.

La verdad es que no lo entiendo, nos dan 9 meses para crear los programas pero tecnicamente 0 para depurarlos, porque segun pone en los faq, si detectan que hay algun programa en produccon, usando el portal de desarrollo lo banearan, cuando deveriamos tener , los que teneis empresas variadas, mas de uno en produccion para ver por donde rompen, sino os digo que entre el 1 de julio y el 31 habra 300 versiones delmismo programa o mas...
La verdad es una put**a,con lo bien que funciona un betatester en produccion, para corregir fallos.

Yo he decidido hacer un emulador del servicio en mi propio servidor. Haciendo una simulación a la petición a al AEAT con la mayoría de respuestas de correcto y errores. Ponerlo en producción a mis usuarios cuando tenga algo consistente y conforme lo voy desarrollando para simulando distintas respuestas hacer diferentes acciones. Una vez lo quiera poner en producción para la AEAT cambio la llamada simulada por la real y a rezar.

Edito para decir que mi software es muy simple, solo emite tickets. Alta, anulación, subsanación y muy esporádico alguna rectificativa.

Igualmente esa es mi idea. Yo ya tengo estas opciones en el programa:


<<---- VERIFACTU ---->>


1-No activo (Para que no haga absolutamente nada sobre VeriFactu)

2-Sistema VeriFactu
3-Pruebas Sistema VeriFactu
4-Sistema NO VeriFactu
5-Pruebas sistema NO VeriFactu


Para que el cliente pueda activarlo en modo de pruebas cualquiera de las opciones VeriFactu/NO VeriFactu y que cuando llegue el día (ahora resulta que comienzan en días distintos según sea sociedad o autónomo) elija con cual quiere trabajar.


Ahora se me plantea el dilema que si, una vez llegado el momento, el cliente sigue usando la opción 1 (no activo) el programa seguirá funcionando como hasta ahora y pienso que igual no deberíamos dejar esa opción porque la aeat puede responsabilizarte de que está usando un programa no actualizado.


¿Ahora cómo le ponemos al niño?


Saludos.

Yo le pondría una clave para cada modo y que te soliciten en que modo quieren trabajar, modo SII,, modo verifactu y nodonoverfifactu, y lo pones que se vea bien en que modo trabaja y solicitud por escrito.

En la opción 1 todo abierto para que puedan consultar, listar, exportar, estadísticas, etc. Pero la opción de emitir o cobrar facturas desactivada.

Me parece una solución muy razonable. Si desactivas la opción de poder generar o modificar una factura después del 1/7/2025, me parece difícil multarte. El reglamento y todo siempre se aplica a la emisión de las facturas, que es la única cosa que se debe restringir.

Es cierto que un tramposo puede cambiar la hora del ordenador para ponerlo en el pasado, pero solo podrá emitir una factura con fecha 30/6/2025 o anterior; y si un cliente se deja engañar en agosto de esta manera, no creo que sea responsabilidad del desarrollador.
Bueno, estoy asumiendo que el programa prohíbe emitir facturas en el futuro, que me parece de cajón.

Luego tienes al hramposo con H de hacker que cambia el código del programa para saltarse el control sobre la fecha. Pero todos sabemos que no se puede cazar todos los liebres.

Y después que hayan ahora dos fechas es un lío. Estoy pensando muy fuertemente en tener dos versiones, una para personas físicas y otra para los demás, entre julio y diciembre de 2025...

Una pregunta que me hago es poder (o no) volver a la opción 1 una vez se ha pasado a la opción 2 o 4. Tengo la sensación que no se debe permitir, de la misma manera que no se debe permitir pasar de la opción 2 a la 4 (o al SII) antes del 31 de diciembre si hay al menos una factura registrada en el año en curso. Pero imagino que hay casos (como un autónomo que se traslada al País Vasco o a Andorra) que pueden justificarse...

El problema que yo veo es que si la fecha de entrada en vigor fuera la misma para todo el mundo yo podría obligar el día 1 de enero de 2026 (por ejemplo) a elegir las opciones 2 o 4 pero de la manera que lo han planteado (con dos posibles fechas de inicio) hay que darle al cliente la posibilidad de activarlo cuando le toque por lo que si no activan nada el programa seguiría funcionando en el modo "Antes de VeriFactu" y eso creo que si puede ser conflictivo.

Puedes intentar controlarlo por el CIF, letra delante sociedad, letra detrás persona física.

Y recordando que K, L, M, X, Y y Z no son letras si va delante :rolleyes:

Sinceramente creo que nos estamos otorgando demasiada responsabilidad. Un mensaje bien visible (podría ser incluso con un check que confirme que se ha visto) indicando que la licencia de uso del software obliga a que el usuario active la opción que legalmente le corresponde y ya está. Si no lo hace, problema suyo. Creo que no se puede pedir más. Tratamos de evitar el fraude con nuestros desarrollos pero no podemos ser niñeras de nuestros usuarios.

Diferenciar Persona física o Juridica
 

Personalmente ,hace tiempo que en la configuración del programa,añadí un combo , para elegir entre Persona Física y Jurídica, en los datos de la entidad emisora de facturas, pensando en las próximas facturas electrónicas, que hacían distinción en ello, si se ha rellenado como toca, en mi caso obvio lo hago yo, simplemente con consultar el tipo de persona, contrastando con la fecha, directamente forzare que entre en producción, teniendo en cuenta que solo podré trabajar como verifactu.
Una vez asignado el tipo, podéis añadir una clave de acceso o llave , para tener que cambiar esos datos, para que el cliente o si cuñado , la líen por tocar lo que no se debe.
Tened en cuenta que estamos rediseñando nuestros programas , está es una modificación mínima y muy útil.

Una pregunta, que me has hecho pensar...



Ponéis visible en vuestro programa actual que esta versión no está activa en verifactu?

Ahora que más o menos tengo claro el flujo para un NIF/empresa (un Obligado Tributario = OT), se me platea una duda cuando el programa gestiona varios OT.
(sería el caso de 1 tienda con varias sucursales que comparte BD, pero con diferentes NIF o una gestoría o una empresa que hace de representante,...).
Asumiendo que en un envío no se pueden mezclar facturas de diferentes OT. (*1)

La situación es la siguiente:
1) Me entran en la cola de envío 4 facturas de diferente OT (que se han generado ahora).
2) En consecuencia tengo que generar 4 envíos uno para cada factura y esperar entre cada uno 60" (*2)
3) Si después de cada envío debo esperar 60", irremediablemente voy a pasar de los 120" (de límite desde que se generan el Registro de facturación hasta que se envía) en el tercer o cuarto envío.

¿Alguien tiene esta misma situación?
¿Alguna de las suposiciones (*1) (*2) son incorrectas?

Tenemos la misma situación. Seria una buena consulta para el buzón de correo de veri*factu.

La suposición 1* tiene que estar bien porque en la cabecera del envío hay la información del emisor (OT)
La suposición 2* pues ... estaría bien que nos permitieran enviar datos de un OT y seguido del otro OT sin esperar y controlar los tiempos de espera independientes para cada OT.

Hola:
puede pasar 2 cosas, que envies como tercero o que tengas los certificados de cada uno:
- Si tienes los certificados de cada 1 deben tener cada uno su tiempo de espera y tendrás que tener arrays de tiempos para cada OT, los tiempos de espera seran por cada OT, o sea, en ese caso se mandan los 4 lotes sin esperar.
-Si envias como tercero, a falta de que te confirme verifactu, lo lógico es que lo puedas enviar todo en el mismo paquete, y para que funcione se supone que en la cabecera (en obligado emisión ) serña el cif del certificado que uses, deberia dejar meter todos los OT en el mismo soap. Pero claro, mejor asegurate.

Todo esto está muy verde todavía. Lo único que tengo es una opción en una parte del programa para seleccionar cómo se tiene que comportar el programa pero no, no he pensado en meter un cartel que lo ponga visible expresamente aunque no es mala idea.




Yo en la primera opción estoy de acuerdo, es lo más lógico. En la segunda tampoco lo tengo muy claro.

En las Faqs de Verifactu se especifica que un mismo obligado tributario puede tener varios SIF's y cada uno es independiente del otro, cito "...Por lo tanto, para expedir sus propias facturas (y generar los correspondiente Registros de Facturación asociados, de forma encadenada) no tienen por qué -ni necesitan- saber qué facturas están expidiendo otros SIF de la misma sociedad o empresa, ya que son independientes a estos efectos y no necesitan para ello estar "conectados o comunicados". Lo mismo ocurre cuando un tercero envía los registros de facturación de diferentes OT's y de sus diferentes SIF's.
Basándonos en estas premisas, los tiempos de envío para los registros de facturación deben estar establecidos por cada SIF, independientemente del OT. Esto nos tiene que hacer pensar que el módulo de envío debe crear un "hilo" por cada SIF que tenga que gestionar y estos "hilos" deben funcionar en paralelo para que cada SIF tenga sus propios tiempos de envío.
Si no, sería inviable que un tercero que gestiona cientos de SIF's pudiera cumplir con el reglamento en cuanto a los tiempos de envío.

Yo creo que mas que "el módulo de envío debe crear un "hilo" por cada SIF", debemos pensar que cada SIF debe tener su propio módulo de envío.

Siempre y cuando los módulos de envío trabajen en paralelo, por eso dije lo de hilo, luego cada uno puede implementarlo con un sólo módulo o con un módulo para cada uno.

Vale, ya me han dado la respuesta y coincide con lo que me comentáis.
(*1) Esta premisa es correcta (ya lo sabíamos); No se pueden mezclar facturas de diferentes OT.
(*2) Esta es incorrecta, en cuanto a la espera. No debo esperar 60" entre estos envíos porque son de diferente OT. Cada uno de ellos deberá esperar el tiempo especificado con el último envío realizado de ese mismo OT.

Por lo tanto no se dará el punto (3), porque en este caso que son 4 envíos de diferentes OT, se pueden hacer en paralelo (para hacienda es como si fueran 4 empresas distintas enviando).

Yo creo que lo voy a ir poniendo desde ya también

A traves del NIF/CIF podrias saber si es persona fisica o juridica y en base a eso establecer las opciones

Generar cuatro hilos distintos. Unica solucion que veo.

TiempoEsperaEnvio si no hay respuesta
 

Hola tengo una duda sobre el control de flujo y la gestión de los tiempos de envíos.

En el caso que al enviar se produzca una excepción y no recibamos una respuesta del servidor, no tenemos que volver a esperar para hacer otro envío no?
Al no tener respuesta, no tenemos el valor de TiempoEsperaEnvio y suponemos que la AEAT no ha recibido los registros de facturación de ese envío.
Por lo tanto puedo intentar hacer otro envío inmediatamente no?

Gracias

Correcto.
Pero aunque el problema sea del servidor de verifactu, tienes que marcarlo como incidencia si se te sale del tiempo de envio que te marcaron la última vez.
Por otro lado, aunque no creo que se haga mucho caso, el reglamento dice que en caso de problemas en el envío hay que reintentarlo mínimo cada 1 hora. Yo creo que todos vamos a intentarlo muchísimo más a menudo,pero era una simple observación.

Muchas gracias