Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[bmfranky]

Empezado por ermendalenda

Tienes que tener opciones de importarte el xml y validarlo contra el xsd cada sistema de desarrollo lo tiene: vb, php...
Las funciones te devuelven si es correcto o donde tiene algun error,.por ejemplo un formato numérico que.le falte algún decimal obligatorio en el esquema xsd... eso te da más tranquilidad al enviar por que haces una co.probacion previa,y ea lógico que hayan solicitado a verifactu que modifiquen el esquema por que no se podía validar sin enviar, y lo lógico es que se pueda validar previamente

Pues a GooGlear se a dicho, a ver como se puede hacer con C#.

[bmfranky]

Por cierto, acabo de entregar el vehiculo a un cliente asesor fiscal, que venia de hacer un cursillo con los responsables de hacienda, y en tre otros "Palos", han hablado del verifactu, les han dicho que la entrada en vigor, obligatoria se aplaza hasta el 1 de enero de 2026, y que nos van a dar de tiempo hasta Julio de 2025, para que adaptemos los sistemas de facturacion y 6 meses desde ahi hasta enero para que los usuarios se acostumbren al uso hasta que porfin entre en vigor.
Supongo que no tardaran en comunicarnos a nosotros algo por el estilo.

[ermendalenda]

Empezado por bmfranky

Por cierto, acabo de entregar el vehiculo a un cliente asesor fiscal, que venia de hacer un cursillo con los responsables de hacienda, y en tre otros "Palos", han hablado del verifactu, les han dicho que la entrada en vigor, obligatoria se aplaza hasta el 1 de enero de 2026, y que nos van a dar de tiempo hasta Julio de 2025, para que adaptemos los sistemas de facturacion y 6 meses desde ahi hasta enero para que los usuarios se acostumbren al uso hasta que porfin entre en vigor.
Supongo que no tardaran en comunicarnos a nosotros algo por el estilo.

Si nuestro asesor nos ha dicho lo mismo, esperan aprobar el boe en breve y poner esas fechas,
Jejeje, ya verás de retrasos que meten después.
Ellos lo saben, pero tienen que ir poniendo plazos para que nos apretemos el culo.

[ermendalenda]

Empezado por bmfranky

Pues a GooGlear se a dicho, a ver como se puede hacer con C#.

Yo lo he intentado en vb y de hecho me comprobaba algunos xml/xsd antiguos, las nuevas versiones de xsd como tengan twngan referencias extrrnas me dan error. Estoy en el prerromano.
El año que viene tengo curso de .net pero ya se me hace tarde para pasar todo el software. He dedicado horas a buscar soluciones gratuitas y todo pasa a comprar apis etc. Paso de gastar para esos total si me devuelve error de estructura no se lo van a comer y la única diferencia es que me devolverá el error el envío, por que parar de facturar por eso no lo voy a hacer si lo demás está correcto, qr...
Y el qr es bastante difícil que sea erroneo, son pocos campos y ya está superverificado, así que desistí de esa validación. Además si hay que verificar contra un xsd con referencias a otros xsd externos hay que tener conexión y tendría que hacer más pruebas de 1ue pasa cuando no hay conexión cuanto tarda en devolver el error etc, más retardos
.aunque supongo que también los nuevos desarrollos te importan todas las referencias externas a tu sistema y se comprueba todo localmente, ya me contarás cuando pruebes.

[ermendalenda]

Sí, he dicho subsanación .
Buenas noticias para este lío.
Cuando me dé tiempo analizo respuesta que me ha dado verifactu para los distintos escenarios de errores en el cliente, y de principio parece que es con registro de subsanación.
Facil no?
Leo más detenidamente la respuesta y después os pongo la copia.

[bmfranky]

Empezado por ermendalenda

Sí, he dicho subsanación .
Buenas noticias para este lío.
Cuando me dé tiempo analizo respuesta que me ha dado verifactu para los distintos escenarios de errores en el cliente, y de principio parece que es con registro de subsanación.
Facil no?
Leo más detenidamente la respuesta y después os pongo la copia.

Pasate la info cuando puedas, mañana me tenia que poner justo a eso, cambiar destinatario de factura por error en el mismo...

[ermendalenda]

Empezado por bmfranky

Pasate la info cuando puedas, mañana me tenia que poner justo a eso, cambiar destinatario de factura por error en el mismo...

Hola, estaba de copas jeje, pero como veo que la necesitas y me has ayudado mucho te la paso, yo creo que es fácil de analizar pero erra largo de leer:

Integración VERIFACTU - Duda Funcional

*

Buenos días:

Le respondemos a los casos planteados:

Caso 1:
* *Incidencia:
* *El cliente solicita factura de una simplificada (tipo F2), para lo cual emito la sustitutiva o canje de la misma (tipo F3).

* * El usuario se equivoca y selecciona un cliente erróneo, pero no se le entrega al cliente


En cuanto el usuario corrige el NIF y emite una nueva factura, el SIF debe generar un nuevo registro de alta del tipo "ALTA DE SUBSANACIÓN", corrigiendo el NIF, *siempre y cuando no corresponda la emisión de una factura rectificativa. No es necesario realizar previamente una anulación de ese registro ya que deberían generar entonces dos registros sobre ese mismo IDFactura, uno de anulación y el posterior registro de alta de subsanación.


Caso 2:
* *Incidencia:
* *El cliente solicita factura de una simplificada (tipo F2), para lo cual emito la sustitutiva o canje de la misma (tipo F3).
* *El usuario se equivoca en algún dato del cliente pero en ese momento no lo sabe,
* *Se le entrega copia al cliente
* *Al siguiente reclama que se le subsane, cuando observa el error en por ejemplo Nombre de Empresa

Mismo procedimiento que en el caso anterior, en cuanto tengan conocimiento del error y emitan la nueva factura con el nombre de empresa corregido, el SIF debe generar un registro de ALTA DE SUBSANACION sobre ese IDFactura con el dato corregido, siempre y cuando no corresponda la emisión de una factura rectificativa.

Les recomendamos revisar los apartados de la documentación respecto a estas cuestiones. En concreto, pueden revisar el documento de diseño de registro y las hojas correspondientes a los cuadros de las operativas de altas y anulaciones. También pueden revisar en el documento de descripción del servicio web, el apartado "8. Anexo II: Operativa de «VERI*FACTU».*" donde se detalla la operativa en caso de altas iniciales, de subsanación, anulaciones, etc.

Además, le planteamos nuevos ejemplos para tratar de aclararlo en la medida de lo posible:

1. Usuario rellena factura y envía.

• Se rechaza en el momento de envío por algún motivo de error.

• Si el error no está contemplado en el registro de facturación (ejemplo: rechazo porque el NIF del destinatario es erróneo porque se han confundido al teclearlo) procede alta por rechazo. Se crea un NUEVO registro de facturación *con los datos corregidos, pero que sigue tratándose de la misma factura (mismo número de serie, NIF obligado y fecha de expedición). Se envía usando "Alta por rechazo" (· <Subsanacion>=S *<RechazoPrevio>=X).

• Si el motivo del rechazo es un error contemplado en el registro de facturación, y que se debe solucionar con una NUEVA FACTURA (con otro numero de serie, etc) entonces no procede el alta por rechazo, sino, que se deberá generar un nuevo registro de facturación que corresponderá con una nueva factura (distinto número de serie, NIF y fecha que correspondan), tendrá el indicativo de tipo de factura RX, y será un "alta" sencillo.



2) Supongamos que es el USUARIO quien se da cuenta de que emitieron la factura errónea, pero en su momento se aceptó correctamente. La casuística sería:

• Si el error que detecta el usuario posteriormente no está contemplado en el registro de facturación, (por ejemplo, quieren corregir el nombre que está mal, pero los apellidos estaban bien y por similitud se aceptó el registro) procede alta por subsanación. Se crea un NUEVO registro de facturación *con los datos corregidos, pero que sigue tratándose de la misma factura (mismo número de serie, NIF obligado y fecha de expedición). Se envía usando "Alta por subsanación" (<Subsanacion>=S y No informar <RechazoPrevio> o informarlo con valor N).

• Si el error que detecta el usuario es un error contemplado en el registro de facturación (se equivocan en el tipo impositivo) y que se debe solucionar con una NUEVA FACTURA (con otro numero de serie, etc). entonces no procede el alta por subsanación sino, que se deberá generar un nuevo registro de facturación que corresponderá con una nueva factura (distinto número de serie, NIF y fecha que correspondan), tendrá el indicativo de tipo de factura RX, y será un "alta" con la información que establezca el reglamento de facturación.



Es importante tener claro que el RD no modifica el reglamento de facturación. La misma forma de "solventar errores" que existía es la que se debe aplicar ahora. Esto requiere de conocimientos de la persona que emite una factura (igual que lo ha requerido anteriormente) para discernir si debe o no hacer una factura rectificativa, o si puede hacer una subsanación.

Para ello se publicarán FAQS con todas estas situaciones y documentación de ayuda, antes de la implantación obligatoria, en la SEDE de la AEAT.


Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email:*[email protected]

[ermendalenda]

Bien, ya me he leído esto de los cambios de clientes.
Como veis, mi consulta era sobre facturas sustitutivas, pero evidentemente en la respuesta se intuye que la operativa es igual para facturas normales. Con lo cual, al menos a mi, me va a facilitar muchísimo la programación de esta parte y por supuesto es más claro, lo único es que internamente tenemos que tener en cuenta algunas cosas para que esas modificaciones no nos cree problemas fiscales por que perdamos o damos.un salto aparentemente irregular en esa trazabilidad y en algún momento pueden provocar inconsistencia de datos a la hora de las declaraciones, hay que analizar bien esto según el particular desarrollo de cada uno.
Que tengo que tener en cuenta en mi caso:
1. No dejar al usuario hacer esos cambios sin una autorización analizando bien la situación, dejar cambiar los datos del cliente en una factura es un tema delicado.
2.informar a contabilidad adecuadamente y eficientemente de dicho cambio, sobre todo si corre peligro de haber recibido ya la factura con el dato erroneo.
3. Guardar correctamente en nuestras bases de datos el cambio y crear logs de dicha trazabilodad para que nosotros podamos saber que ha pasado ante una duda, incluso, como serán pocas incidencias, crear unas logs separadas para estos casos que pueden ser hasta un correo electrónico. Yo estoy usando mucho esto último para determinadas operativas
4. Atentos a los que estén en SII, por que si se ha presentado incorrectamente esos registros hay que modificarlos, para lo cual si no te lo permite el programa que tengas de SII en la web del SII te permite ese cambio durante bastante tiempo, creo que durante el año en curso.
5. Para nuestra gestion y si ha pasado mucho tiempo desde que se emitió la factura voy a pasar al plan B y hacer abono al cliente erroneo y hacer de nuevo la factura e incluso bloquear las facturas para que no se puedan hacer modificaciones de clientes pasado x meses.
6. En nuestra base de datos queda asignado internamente el tiquet al cliente y también tengo que reasignarlo, por que lo tengo que tener en cuenta por si hay que hacer rectificativas posteriormente.
7. Si hacéis un cambio de cliente debéis revisar en vuestra base de datos si ha habido rectificativas de esa factura al cliente erroneo, en ese caso hay que "obligar" o al menos avisar claramente de que las posibles rectificativas también hay que modificarlas y una de dos, o que se modifiquen automáticamente o informar de cuáles son.

Nadie dice que esto sea fácil pero yo creo que mejor que la otra operativa que obligaba a emitir nuevos registros y nuevas facturas , abonos...
De esta forma modificamos, legalmente, el mismo registro de nuestra base de datos y no se emiten negativas, positivas etc que además para temas estadísticos complicaria el desarrollo y lectura de los datos

[bmfranky]

Empezado por ermendalenda

Bien, ya me he leído esto de los cambios de clientes.
Como veis, mi consulta era sobre facturas sustitutivas, pero evidentemente en la respuesta se intuye que la operativa es igual para facturas normales. Con lo cual, al menos a mi, me va a facilitar muchísimo la programación de esta parte y por supuesto es más claro, lo único es que internamente tenemos que tener en cuenta algunas cosas para que esas modificaciones no nos cree problemas fiscales por que perdamos o damos.un salto aparentemente irregular en esa trazabilidad y en algún momento pueden provocar inconsistencia de datos a la hora de las declaraciones, hay que analizar bien esto según el particular desarrollo de cada uno.
Que tengo que tener en cuenta en mi caso:
1. No dejar al usuario hacer esos cambios sin una autorización analizando bien la situación, dejar cambiar los datos del cliente en una factura es un tema delicado.
2.informar a contabilidad adecuadamente y eficientemente de dicho cambio, sobre todo si corre peligro de haber recibido ya la factura con el dato erroneo.
3. Guardar correctamente en nuestras bases de datos el cambio y crear logs de dicha trazabilodad para que nosotros podamos saber que ha pasado ante una duda, incluso, como serán pocas incidencias, crear unas logs separadas para estos casos que pueden ser hasta un correo electrónico. Yo estoy usando mucho esto último para determinadas operativas
4. Atentos a los que estén en SII, por que si se ha presentado incorrectamente esos registros hay que modificarlos, para lo cual si no te lo permite el programa que tengas de SII en la web del SII te permite ese cambio durante bastante tiempo, creo que durante el año en curso.
5. Para nuestra gestion y si ha pasado mucho tiempo desde que se emitió la factura voy a pasar al plan B y hacer abono al cliente erroneo y hacer de nuevo la factura e incluso bloquear las facturas para que no se puedan hacer modificaciones de clientes pasado x meses.
6. En nuestra base de datos queda asignado internamente el tiquet al cliente y también tengo que reasignarlo, por que lo tengo que tener en cuenta por si hay que hacer rectificativas posteriormente.
7. Si hacéis un cambio de cliente debéis revisar en vuestra base de datos si ha habido rectificativas de esa factura al cliente erroneo, en ese caso hay que "obligar" o al menos avisar claramente de que las posibles rectificativas también hay que modificarlas y una de dos, o que se modifiquen automáticamente o informar de cuáles son.

Nadie dice que esto sea fácil pero yo creo que mejor que la otra operativa que obligaba a emitir nuevos registros y nuevas facturas , abonos...
De esta forma modificamos, legalmente, el mismo registro de nuestra base de datos y no se emiten negativas, positivas etc que además para temas estadísticos complicaria el desarrollo y lectura de los datos

Hola, gracias por la info y la explicacion, en mi caso como son facturas simples, simplemente hago el alta de subsanacion y como intuyo, cambio en mi base de datos , en el reguistro de la factura un cliente por otro y reimprimo la factura con los mismos campos, iva,numero, etc..
A la gestoria , y en su caso al cliente le doy la factura con los datos ya correctos , sin mas.
Es asi?