Tiempos de envios

[CarlosArjonomia]

Empezado por ermendalenda

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

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

[bmfranky]

Empezado por CarlosArjonomia

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...

¿Para qué se puede utilizar este entorno de PREPRODUCCIÓN?
Estos sitios web están destinados a ofrecer exclusivamente pruebas en un entorno de PREPRODUCCIÓN para facilitar la integración y validación de servicios que la Agencia Tributaria determine publicar en este entorno y se haya autorizado para que se puedan usar para realizar las pruebas. Estos servicios solo permitirán realizar pruebas de modelos y consultar los presentado en las mismas condiciones que los servicios en Preproducción.
Se recuerda que este entorno solo se debe utilizar para realizar este tipo de pruebas puntuales y en ningún caso para realizar pruebas masivas, validaciones integradas en procesos de presentación en producción, etc. Si se detectan usos que se consideren abusivos se podrán adoptar medidas para bloquear el acceso.

La verdad es una put**a,con lo bien que funciona un betatester en produccion, para corregir fallos.

[CarlosArjonomia]

Empezado por bmfranky

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.

[[newtron]]

Empezado por CarlosArjonomia

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.

[ermendalenda]

Empezado por newtron

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.

[CarlosArjonomia]

Empezado por newtron

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.

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.

[antoine0]

Empezado por CarlosArjonomia

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...

[antoine0]

Empezado por newtron

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.

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...

[[newtron]]

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.

[novatico]

Empezado por newtron

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.

[unomasmas]

Empezado por newtron

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.

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.

[Jesusggc]

Empezado por newtron

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.

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

[edari]

Empezado por newtron

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.

Una pregunta, que me has hecho pensar...



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

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

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?

[rci]

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

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.

[ermendalenda]

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

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?

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.

[Jesusggc]

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

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?

Generar cuatro hilos distintos. Unica solucion que veo.

[_Io]

Buenos días.

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

.......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.
?

Estoy un poco perdido en este asunto del control de flujo.
Tengo claro por la documentación, que en la respuesta nos marcarán un tiempo mínimo de espera.
Pero lo que no entiendo es cuando habláis de 120" (de límite desde que se generan el Registro de facturación hasta que se envía), ¿Dónde viene este requisito?

Os pongo un ejemplo, como funcionaría mi sistema:

1º En la base de datos, se genera/n 1, 2, 5 facturas.
2º Hago el envío de esa/s factura/s
3º Espero el tiempo que me indiquen
4º Compruebo la base de datos, vuelvo al punto 1º.

¿Dónde están esos 120"? o ¿Dónde los debería aplicar?

Espero haberme explicado bien.

Muchas Gracias.