Demo con código Verifactu.dll para (delphi 7)

[Matorral]

Empezado por starlet

Buenas:

Ya tengo el componente bien integrado en mi aplicación y funciona todo según lo esperado excepto las subsanaciones que o no lo entiendo bien o hay algún error.

- Mando una factura con el DNI mal a propósito para que me la rechace la AEAT, cosa que obviamente hace.

- Mando una subsanación con el mismo número de factura, DNI corregido y mismos datos y marco los campos Rechazoprevio y Subsanación a True.

- Me contesta que "No existe el registro de facturación"

- Si la envío sin Rechazoprevio y Subsanación, y con los datos correctos la acepta.

Contestación de la AEAT a este caso:

En el caso de que el registro original sea rechazado, esto implica que no ha sido aceptado en el sistema. Por tanto, aquí es cuando debemos emplear el valor <RechazoPrevio>=X (puede ver más detalles en el documento de diseño de registro, en su hoja "A)Cuadro Operativa Alta").

Por ejemplo, en el caso que nos mencionaba, en el que un registro de facturación ha sido rechazado. Aquí corresponde revisar si el Reglamento de Facturación estipula la emisión de una factura rectificativa y generar su registro de alta inicial. En cambio, si fuese un dato que solo aparece en los registros de facturación, la corrección del error pasaría por generar un registro de "Alta por rechazo" con los valores <Subsanacion>=S y <RechazoPrevio>=X. Puede ver más información en la pregunta 17 del documento de FAQs para desarrolladores.


Qué estoy haciendo mal???.

Saludos,

Buenas Starlet¡¡

Acabo de hacer algo parecido...
Envie una simplificada con importe negativo para provocar el rechazo. (el componente lo marca como R5 y al no especificar la factura a la que rectifica lo rechaza).
Luego corregi la factura y le puse importe positivo y la volvi a enviar con Subsanacion='S' y Rechazoprevio='S' y la volvio a rechazar.

Modifiqué el xml : puse Subsanacion='S' y Rechazoprevio='X' y la envié desde la página de comprobación de XML y la tragó.

(desde esta página ....

https://prewww1.aeat.es/static_files...ws/opciones.js

El problema es que el componente no acepta el valor 'X' en la propiedad rechazoPrevio (es de tipo boolean).

Espero que te ayude.

[Matorral]

Hola starlet¡¡

lo resuelves poniendo...

Código Delphi [-]
  subsanacion:=True;
  rechazoprevioNOExiste:=True;

al poner rechazoprevioNOExiste a True, la unit uVerifactuFuncs le asigna el valor 'X' a rechazoprevio en el XML.

Código Delphi [-]

    if facturaRegistro.subsanacion then
        Factura.RegistroAlta.Subsanacion:=SubsanacionType.S;

    if facturaRegistro.rechazoPrevioExiste then
        Factura.RegistroAlta.RechazoPrevio:=RechazoPrevioType.S;

    if facturaRegistro.rechazoPrevioNoExiste then
        Factura.RegistroAlta.RechazoPrevio:=RechazoPrevioType.X;

[DarkDudae]

La AEAT no acepta facturas cuyo NIF no sea correcto, por eso no les consta en sus bases de datos como subidas.
Lo que nosotros hacemos, es utilizar la característica del componente de comprobar NIF, así no enviamos nunca nada cuyo NIF no haya sido comprobado previamente.

[starlet]

Hola:

Si, eso hago yo y creo que es lo correcto. Lo que tenemos que tener en cuenta es que a veces, ese servicio puede no estar disponible. Yo verifico las letras antes de hacer la consulta a la AEAT, además de.

Lo que quería era probar subsanaciones, y para subsanar hice que me rechazara por ese motivo.

Y en las subsanaciones no sabía como poner X en rechazoprevio y con la explicación de Matorral ya lo veo.

Muchas gracias a todos.

[seccion_31]

Viendo los posts anteriores, me quedo gratamente sorprendido.

Solo me queda desearos a todos un feliz verano !!

[Matorral]

Empezado por seccion_31

Viendo los posts anteriores, me quedo gratamente sorprendido.

Solo me queda desearos a todos un feliz verano !!

Jajaja, tu si que te mereces un Feliz verano Crack¡¡¡

Yo este año estoy castigado sin Verano.

[DarkDudae]

Buenos días compañeros:

He estado haciendo pruebas modificando el componente para "aceptar" un tipo de factura de forma forzada y no automátca (F1, F2, F3, R1, R2, R3, R4, R5). Es una propiedad nueva de tipo string[2] del TRegistroFactura llamada "forzarTipo".

El motivo básicamente era hacer pruebas y ver restricciones de la propia AEAT.

Os comento mis observaciones:

-El componente ahora mismo en todas las facturas simples, para emitir rectificativas usa el tipo R5, lo cual es correcto. Todas las rectificativas son en Importe (no sustitutivas), así que creo que no sería necesario abonar un ticket completo y crear uno nuevo, sino simplemente meter en el ticket y/o factura nueva la línea o líneas eliminadas de la factura que se rectifica. Hasta ahí todo bien. El problema es que es bastante habitual (sobre todo con tickets) que un cliente te diga: "me he equivocado de leche, yo la quería desnatada y la he cogido entera". Y entonces hagas el ticket recfificativo con la leche entera en negativo y luego la línea en positivo de la leche desnatada, que resulta ser más cara que la leche entera. Así que el ticket "rectificativo" es positivo, no negativo. No obstante, el componente decide internamente mediante el importe si lo cataloga como una F2 o como una R5.

De ahí que con esta nueva propiedad, podamos "forzar" la R5 en estos casos (enviando el bloque con la factura rectificada también). Además, confirmo que la AEAT la acepta en los envíos sin problema.

Otro caso es el tema de las facturas simples con cliente identificado. Hacienda las distingue perfectamente de las facturas ordinarias. Por ejemplo en las facturas simples la dirección del cliente no es necesaria que conste en la misma, pero no obstante, es válida (siempre que esté el NIF y el nombre) para que el cliente pueda desgravarse el gasto. Así que intenté enviar una factura como F2 con Destinatario mediante mi modificación del componente (Forzando una F2 en vez de una F1), pero como dato, Hacienda no permite que incorporemos el bloque "Destinatario" para F2 y R5. Así que en estos casos, aunque nuestro software identifique al cliente en el ticket, la factura simple se enviaría sin datos del cliente.

Sigo haciendo pruebas e incorporando estas restricciones a mi modificación. Por supuesto, estas modificaciones en el componente, si lo estima oportuno seccion_31, estarán disponibles para todos si lo ve necesario.

Un saludo y feliz agosto (yo soy también de los que les toca pringar este mes)