Me estoy agobiando

[ermendalenda]

Lo de usar apis externas solo va a solucionarte el 50%, además de que lleva su integración, tienes que repasar mil cosas y si estás en Vb6.0 como yo, probablemente estás en el punto en el que yo estaba hace unos años:
1. Que BD usas?, posiblemente la nativa MDB
-Ya sabes lo inconsistentes que son y no te puedes permitir perder contadores, por lo tanto:
a) tienes que tener un plan para cuando se corrompan
b) Tienen una latencia alta e impredecible de actualización, con lo cual, una BD .mdb leida desde otros ejecutables pueden tener un tiempo de espera y bloqueos, y probalemente vas a tener que poner ejecutables en segundo plano por que los trigger en Vb6. no van bien y no son asincronos.
2. No tienes nada de facturas rectificativas, con el tiempo que te quedas ni de coña vas a controlar varias series, aunque de forma un pogo "alegal" y sin mucho riesgo podrias actuar con abonos en la serie de las simplificadas (que creo que me has comentado que es lo que manejas).

3. Para usar apis externas no tienes más remedio que usar o comunicaciones con empresa externa o apis compatibles con VB6, incluso en local (Las que he visto carisimas), algunas inluso tienes que montar un servidor. Opciones hay, algunas más baratas y otras más caras, pero hay que tener en cuenta que una vez enviado pierdes el control y lo que hagan con esos registros, aunque no es responsabilidad totalmente tuya, te pilla en medio.
4.Sí, te van a devolver un QR, y según la API, incluso el contador para que te olvides de numeradores, tienes que pintar correctamente el QR, pero no solo eso, tienes que conservarlo junto con el tiquet por si hay requerimiento de los tiquets, una cosa es que si estas en verifactu no necesitas conservar esos XML's y otra es que tienes que conservar los tiquets tal y como lo emitistes.
5. Por supuesto tienes que revisar que cumplir normativa ROF y LIVA, al menos lo más importante.
6.La ley te obligaba a tenerlo adaptado el 29 de Julio, has sido un pelín "dejado".

Resumen:

Las consecuencias de haberlo dejado hasta 1 mes antes te hacen practicamente inviable adaptar el software en ese tiempo record.
La única opción compatible con lo que necesitas y que yo puedo ver es:
Convencer a tus clientes que rellenen el formulario de retraso de puesta en marcha, objetando problemas técnicos de forma que expliques la problemática y que no ha habido desidia, y que lo acepten en la AEAT y de esa forma tengas un margen mayor de maniobra.

La otra opción es que digas a tus clientes que tienen que cambiar el software y adquirir uno, aunque sea de forma temporal, los hay desde 35-60 euros mes (SIF) y en algunas redes anuncian gratuitos.

Saludos.

[reyelche]

Empezado por ermendalenda

Lo de usar apis externas solo va a solucionarte el 50%, además de que lleva su integración, tienes que repasar mil cosas y si estás en Vb6.0 como yo, probablemente estás en el punto en el que yo estaba hace unos años:
1. Que BD usas?, posiblemente la nativa MDB
-Ya sabes lo inconsistentes que son y no te puedes permitir perder contadores, por lo tanto:
a) tienes que tener un plan para cuando se corrompan
b) Tienen una latencia alta e impredecible de actualización, con lo cual, una BD .mdb leida desde otros ejecutables pueden tener un tiempo de espera y bloqueos, y probalemente vas a tener que poner ejecutables en segundo plano por que los trigger en Vb6. no van bien y no son asincronos.
2. No tienes nada de facturas rectificativas, con el tiempo que te quedas ni de coña vas a controlar varias series, aunque de forma un pogo "alegal" y sin mucho riesgo podrias actuar con abonos en la serie de las simplificadas (que creo que me has comentado que es lo que manejas).

3. Para usar apis externas no tienes más remedio que usar o comunicaciones con empresa externa o apis compatibles con VB6, incluso en local (Las que he visto carisimas), algunas inluso tienes que montar un servidor. Opciones hay, algunas más baratas y otras más caras, pero hay que tener en cuenta que una vez enviado pierdes el control y lo que hagan con esos registros, aunque no es responsabilidad totalmente tuya, te pilla en medio.
4.Sí, te van a devolver un QR, y según la API, incluso el contador para que te olvides de numeradores, tienes que pintar correctamente el QR, pero no solo eso, tienes que conservarlo junto con el tiquet por si hay requerimiento de los tiquets, una cosa es que si estas en verifactu no necesitas conservar esos XML's y otra es que tienes que conservar los tiquets tal y como lo emitistes.
5. Por supuesto tienes que revisar que cumplir normativa ROF y LIVA, al menos lo más importante.
6.La ley te obligaba a tenerlo adaptado el 29 de Julio, has sido un pelín "dejado".

Resumen:

Las consecuencias de haberlo dejado hasta 1 mes antes te hacen practicamente inviable adaptar el software en ese tiempo record.
La única opción compatible con lo que necesitas y que yo puedo ver es:
Convencer a tus clientes que rellenen el formulario de retraso de puesta en marcha, objetando problemas técnicos de forma que expliques la problemática y que no ha habido desidia, y que lo acepten en la AEAT y de esa forma tengas un margen mayor de maniobra.

La otra opción es que digas a tus clientes que tienen que cambiar el software y adquirir uno, aunque sea de forma temporal, los hay desde 35-60 euros mes (SIF) y en algunas redes anuncian gratuitos.

Saludos.

Muchas gracias pero que adquieran un software temporal mejor no (los empleados tienen que adaptarse al nuevo software dar de alta articulos etc.)
Yo creía que la adaptación seria mas fácil (lo han echo bastante complicado) no hubiera sido mas fácil mandar un excel al fin del día con datos y campos principales de la de la factura.
He oido que las asociaciones ATA y COE han pedido retrasar la entrada para el 2027 ? porque hay gestores y empresarios que no les da tiempo para el 01-01-2026

[ermendalenda]

Empezado por reyelche

Muchas gracias pero que adquieran un software temporal mejor no (los empleados tienen que adaptarse al nuevo software dar de alta articulos etc.)
Yo creía que la adaptación seria mas fácil (lo han echo bastante complicado) no hubiera sido mas fácil mandar un excel al fin del día con datos y campos principales de la de la factura.
He oido que las asociaciones ATA y COE han pedido retrasar la entrada para el 2027 ? porque hay gestores y empresarios que no les da tiempo para el 01-01-2026

Sí, hay varias organizaciones que han solicitado retraso o incluso la no aplicación....pero... ya sabes quien manda,
Si quieres mi opinión: No puedes objetar a la AEAT que creias que era más facil ni que estas esperando a ver que le dicen a las asociaciones.

[[newtron]]

La verdad es que tienes la cosa apretada. Yo en tu lugar contrataría una API (la que veas más adecuada) y me pondría las pilas 24/7 en gestionar los envíos/recepciones y rectificativas para (por lo menos) tener algo el día 1 de enero. Yo por mi parte no creo que se pongan a sancionar los primeros meses porque ellos saben que esto va a ser una p.... locura.

[Faneka]

Otra opción es si tienes programado el SII que se acogan a él mientras tú terminas el Veri*Factu.

[Carlos]

Buenos días,

A ver...

Vas tarde, eso lo tenemos todos claro.

Cogerte una API.
Pues si, creo que es la mejor solución a 25/11/2025, sino la óptima.
Ganas tiempo para desarrollar tu solución y pasas unas buenas Navidades.

VB 6.0, no tengo ni idea, mi mundo me lo he cerrado yo, me basta. No se pueden coger todos los trenes.
Entiendo que VB 6.0 puede manejar ficheros DBF.

Si puedes usar una solución en local, prueba esto, o al menos míratelo:
https://rebuts.cat/vefa32/

¿Cómo funciona esto?
Básicamente espera que en 2 ficheros DBF, cualquier SIF grabe la información de las facturas a enviar a Veri*factu, él hace el resto.
Genera los RF, crea el XML con las huellas para cada RF, envía a Veri*factu (puedes inicialmente enviar a pruebas), espera la respuesta, la recoge en un XML, guarda los XML enviados y recibidos, deja rastro de la respuesta en el mismo DBF donde el SIF grabó la información a enviar para que el propio SIF pueda verla y dejarla en su pantalla.

Guarda todo en sus DBF (otros diferentes a los 2 mencionados), exportables desde pantalla a XLS.
3 DBF principales:
DBF de XML generados
DBF de los RF de cada XML
DBF de los errores recibidos para cada RF en cada XML (si los hay).

Estos días ha fallado el server de Veri*factu, Vefa32 de lo deja en pantalla para que cuando 'quieras' (es un fallo de hacienda) vuelvas a enviar el XML con 'incidencia' (pulsando un botón)

Y está en constante desarrollo añadiendo lo que inicialmente no contemplaba.
Etc.

OJO!!!
El SIF te lo debes adaptar tu a los requerimientos normativos en cuanto a facturación, pero Veri*factu lo tendrías en marcha.



A 25/11/2025 vale la pena dedicar 2/3 horas a mirar el manual (no es una joya, pero la idea se pilla en él).

[Carlos]

Por favor, cuando abras los DBF hazlo en SHARED!!! No sea que VeFa32 esté intentando importar su información en ese momento.

[Daviid]

Empezado por Carlos

Buenos días,

A ver...

Vas tarde, eso lo tenemos todos claro.

Cogerte una API.
Pues si, creo que es la mejor solución a 25/11/2025, sino la óptima.
Ganas tiempo para desarrollar tu solución y pasas unas buenas Navidades.

VB 6.0, no tengo ni idea, mi mundo me lo he cerrado yo, me basta. No se pueden coger todos los trenes.

Si puedes usar una solución en local, prueba esto, o al menos míratelo:
https://rebuts.cat/vefa32/

¿Cómo funciona esto?
Básicamente espera que en 2 ficheros DBF, cualquier SIF grabe la información de las facturas a enviar a Veri*factu, él hace el resto.
Genera los RF, crea el XML con las huellas para cada RF, envía a Veri*factu (puedes inicialmente enviar a pruebas), espera la respuesta, la recoge en un XML, guarda los XML enviados y recibidos, deja rastro de la respuesta en el mismo DBF donde el SIF grabó la información a enviar para que el propio SIF pueda verla y dejarla en su pantalla.

Guarda todo en sus DBF (otros diferentes a los 2 mencionados), exportables desde pantalla a XLS.
3 DBF principales:
DBF de XML generados
DBF de los RF de cada XML
DBF de los errores recibidos para cada RF en cada XML (si los hay).

Estos días ha fallado el server de Veri*factu, Vefa32 de lo deja en pantalla para que cuando 'quieras' (es un fallo de hacienda) vuelvas a enviar el XML con 'incidencia' (pulsando un botón)

Y está en constante desarrollo añadiendo lo que inicialmente no contemplaba.
Etc.

OJO!!!
El SIF te lo debes adaptar tu a los requerimientos normativos en cuanto a facturación, pero Veri*factu lo tendrías en marcha.



A 25/11/2025 vale la pena dedicar 2/3 horas a mirar el manual (no es una joya, pero la idea se pilla en él).

Sin ánimo de ofender, no instalaría ni ejecutaría software en mi equipo, y mucho menos en el de la empresa, si no puedo revisar el código fuente o, al menos, saber a quién acudir en caso de que algo falle.
Quien quiera que haya creado la pagina esta de rebuts.cat no se ha esmerado mucho en inspirar confianza.

El WHOIS no muestra ningún dato.


Googleando puedo ver que es una pagina de o llevada por alguien del AMPA del Col·legi Dominiques de Vallirana

https://www.rebuts.cat/veurepdf.php?pdf=actupoliticaxxss
https://www.rebuts.cat/veurepdf.php?pdf=actulopd
https://www.rebuts.cat/veurepdf.php?pdf=actulopd
https://www.rebuts.cat/veurepdf.php?pdf=actusepadomiciliacio
https://www.rebuts.cat/veurepdf.php?pdf=actualtasoci
https://www.rebuts.cat/veurepdf.php?pdf=actudretsimatge
https://www.rebuts.cat/veurepdf.php?pdf=actuextraescolars
https://www.rebuts.cat/ampa32/index.html
https://www.rebuts.cat/veuredetall.php?codbd=123456789

Todo esto ya me genera mucho recelo; si el mismo nivel de cuidado que tiene la web del AMPA se refleja en VeFa32, sería arriesgado confiar en el software.

Si el dueño está por aquí, mis recomendaciones serían:

• Añadir una página “Sobre Nosotros” para identificar claramente a los responsables.
• Publicar el código fuente en un repositorio público (por ejemplo, GitHub).
• Mejorar la presentación y profesionalidad de la página web para generar confianza.