Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)

[Jarogo08]

Empezado por emailesc

Depende, en los programas de TPV las adiciones de artículos no se registran ya que están en el ticket, pero cambios en cantidades "para abajo" sí. Luego el sistema solo deja borrar artículos en determinadas circunstancias, solo pueden cancelarlos: quedan marcados pero no se borran. Por otro lado respecto a las proformas cada vez que se emite/imprime hay una tabla que la graba entera, ticket y artículos. Otra tabla para dar de comer a los proveedores de discos duros y que no va a mirar nadie jamás.
En el ERP, que es lo que comentaba antes, sí, cada vez que se modifica un registro se graban todos los campos del mismo en otra tabla, exactamente como estaban antes del cambio. Estas tablas tiene la misma estructura que la primera, salvo un indice adicional para ella, y tres campos más para el usuario que realiza el cambio, la fecha hora y el tipo de modificación: si es borrado o edición.

eso si le metes un trigger a la tabla ya funciona sólo, ¿no? Y ya no hay que programar nada, se encarga la base de datos sola (estoy hablando de SQL Server, no sé si otras tienen lo mismo)

[emailesc]

Empezado por Jarogo08

eso si le metes un trigger a la tabla ya funciona sólo, ¿no? Y ya no hay que programar nada, se encarga la base de datos sola (estoy hablando de SQL Server, no sé si otras tienen lo mismo)

Supongo que sí, el indice yo lo tengo como autonumérico, y la fecha y hora es un Getdate(), el tipo de cambio lo sacas del tipo de trigger, lo único que te faltaría es el usuario que realiza el cambio (siempre que quieras poner estos campos claro). En cualquier caso yo lo tengo como clases y consultas en datasets, ya que básicamente es lo mismo, pero te da mas juego de modificar cosas, poner verificaciones, enlazar con otros objetos etc.

[bmfranky]

Gracias a todos por las respuestas, en cuanto acabe de afinar lo de verifactu, me meto en la cabeza a ver como lo implemento, supongo que creare unas tablas espejo de las que tengo al estilo.
FacturaProforma2025
FacturaProforma2025Mod <-- igual que el anterior , pero con 3 campos mas FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces)
MaterialProforma2025
MaterialProforma2025Mod <-- igual que el anterior , pero con los campos FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces),TipoMod(Que Se Izo) solo de las lineas modificadas.

[emailesc]

Empezado por bmfranky

Gracias a todos por las respuestas, en cuanto acabe de afinar lo de verifactu, me meto en la cabeza a ver como lo implemento, supongo que creare unas tablas espejo de las que tengo al estilo.
FacturaProforma2025
FacturaProforma2025Mod <-- igual que el anterior , pero con 3 campos mas FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces)
MaterialProforma2025
MaterialProforma2025Mod <-- igual que el anterior , pero con los campos FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces),TipoMod(Que Se Izo) solo de las lineas modificadas.

Si usas tablas espejo, depende de como lo tengas, vas a necesitar también un indice adicional, para que puedas relacionar los datos originales y las modificaciones sin problemas.

[bmfranky]

Empezado por emailesc

Si usas tablas espejo, depende de como lo tengas, vas a necesitar también un indice adicional, para que puedas relacionar los datos originales y las modificaciones sin problemas.

Pues al final voy a introducir un campo Versión, que inicialmente sera 0, si modifico algo al guardar copio íntegramente la versión que tenia guardada y la actualizo en la base tabla de modificaciones, los mats solo los borro/modifico en la tabla original enviando unicamente el material modificado borrado anterior a la tabla backup.


Así si cargo la pro-forma y veo que versión !=0 , cargo desde la de mods, una lista con todas las modificaciones, aunque al visionar muestro solo la ultima, puedo retroceder en el tiempo mostrando que paso y mostrando como se vería.


Por ejemplo edito y borro una de las lineas, al cargar la pro-forma al ser la primera modificación, la versión 1, la muestro y si deseo , cargaría la anterior , mostrando los materiales guardados con ese numero de versión y los que haya en la tabla principal, con ese numero de versión y anterior hasta 0.
Así llevo un control de que le hice , incluyendo en mi caso reparaciones y demás.

[Ketemeto2008]

buenas chicos

yo estoy haciendo pruebas y hay 2 cosas que tengo bastante claras pero que a tenor de los resultados obtenidosigual no están tan claras.

- la primera es que no puede haber saltos en las numeraciones. Eso es algo que he leído siempre por aquí y por allá y que especifican en la documentación de la AEAT
- la segunda es que los clientes tienen hasta 17 dias naturales para enviar una factura desde el momento en el que se emite la factura. Esto nos lo dijo un cliente previa consulta a su equipo legal, se lo he preguntado a la IA y es cierto que me dicen que si todos, pero yo, documentación oficial, no he visto al respecto.

La cosa es que si fuerzo una transmisión al entorno de pruebas que pase de que haya huecos (que es algo que controlo en interfaz pero que dejo pasar a criterio del usuario) y que sea del mes pasado (más de esos 17 dias naturales que comento).... la respuesta me devuelve un <tikR:EstadoEnvio>Correcto</tikR:EstadoEnvio>

y claro, no se si estoy haciendo algo mal, o esta gente son tan sinvergüenzas que te devuelven un estado correcto y aceptan cualquier cosa para poder multar

[Carlos]

Empezado por Ketemeto2008

- la segunda es que los clientes tienen hasta 17 dias naturales para enviar una factura desde el momento en el que se emite la factura. Esto nos lo dijo un cliente previa consulta a su equipo legal,...

Enviar a quién? Al cliente? Ahí no entro.
A Veri*factu? Dile que cambie de equipo legal, a menos que te digan en que normativa se apoyan para afirmar eso.

Empezado por Ketemeto2008

... se lo he preguntado a la IA y es cierto que me dicen que si todos, ...

No me hablo con esta gente para cosas serias.

[razorxxx]

Empezado por Ketemeto2008

buenas chicos

yo estoy haciendo pruebas y hay 2 cosas que tengo bastante claras pero que a tenor de los resultados obtenidosigual no están tan claras.

- la primera es que no puede haber saltos en las numeraciones. Eso es algo que he leído siempre por aquí y por allá y que especifican en la documentación de la AEAT
- la segunda es que los clientes tienen hasta 17 dias naturales para enviar una factura desde el momento en el que se emite la factura. Esto nos lo dijo un cliente previa consulta a su equipo legal, se lo he preguntado a la IA y es cierto que me dicen que si todos, pero yo, documentación oficial, no he visto al respecto.

La cosa es que si fuerzo una transmisión al entorno de pruebas que pase de que haya huecos (que es algo que controlo en interfaz pero que dejo pasar a criterio del usuario) y que sea del mes pasado (más de esos 17 dias naturales que comento).... la respuesta me devuelve un <tikR:EstadoEnvio>Correcto</tikR:EstadoEnvio>

y claro, no se si estoy haciendo algo mal, o esta gente son tan sinvergüenzas que te devuelven un estado correcto y aceptan cualquier cosa para poder multar

En cuanto a tu primera pregunta, VeriFactu sólo te va a validar que los registros de las facturas que se van generando estén bien encadenados el último con el anterior, pero no te detecta que las numeraciones de facturas vayan correlativas (por ejemplo, puede generarse el RF de la factura 500 de la serie 1 y justo después el RF de la factura 300 de la serie 4 porque así fue como se registraron en el SIF) ni tampoco si has borrado facturas a posteriori de haber enviado sus RF (porque el encadenamiento se hace con el último RF enviado). No obstante, por la propia Ley de Facturación, no deberían existir saltos en la facturación, y además un SIF con saltos significa que permite borrar facturas y esto no cumple la Ley Antifraude.

Mientras tu SIF trabaje en modo VeriFactu se supone que evitas los requerimientos (y siempre podrás consultar los RF de las facturas ya subidas por si tienes que volvértelos a bajar y volver a llenar esos saltos). Pero lo que no evitas son las inspecciones, y es aquí donde puedes tener un problema si ven que en tu SIF hay saltos en la numeración de una misma serie. Si además tu SIF trabaja en modo No VeriFactu, y te hacen un requerimiento, también podrías tener problemas, porque igual les saltará un error de encadenamiento de hashes.

En cuanto a tu segunda pregunta, no sé de dónde se han sacado eso, porque el RF hay que mandarlo en un máximo de 240 segundos desde su creación, de lo contrario recibirás error y tendrás que reintentar el envío con la etiqueta Incidencia = S. A lo que se refieren tal vez es al periodo de devengo de las facturas.