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

[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)

[Matorral]

Buenos dias¡¡
Da gusto ver que bien se lo pasa la gente los Domingos¡¡
(yo tambien estaba currando).

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

Ayer estaba intentando hacer algo parecido a lo de "forzarTipo" (yo le habia llamado "tipoFactura"), porque para rectificar una simplificada hago un abono total y luego hago la "buena". El problema es que el componente me transformaba en R5 el abono (por ser negativa) y la "buena" me la transformaba en F2.
Lo que intento hacer es el abono total como F2 y la "buena" como R5 (identificando la factura original).

Creo que en lugar de "forzar" el tipo de factura con la propiedad "forzarTipo" esto se solucionaría cambiando los

Código Delphi [-]
if facturaRegistro.total<0

por

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

en uVerifactuFuncs.pas, porque en mi caso siempre identifico la factura rectificada (en la factura rectificativa "la buena")

No se como lo ves, o si se ajusta a lo que tu quieres. (si entendiste el ladrillo que acabo de soltar, jaja).

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.

Yo en este caso "marcaré" las simplificadas con el código del cliente (sin guardar el nif ni el nombre), para luego hacer una completa al final de mes (en principio F1, porque con las F3 solo te deja canjear una simplificada), anulando las simplificadas incluidas en la F1. Bueno, esto es una paja mental que tengo ahora mismo, porque aun no lo tengo hecho, pero mi idea es esa.

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.

Pues entonces me espero, para no tener que recular mis modificaciones en uVerifactuFuncs, jaja.

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

Igualmente a todos¡¡

[DarkDudae]

Lo que comentas de usar:

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

Es perfectamente válido. Piensa que yo con la propiedad de forzarTipo lo que busco más bien es "buscarle las cosquillas" a lo que acepta o no la AEAT.

Nosotros tenemos muchos clientes a los que identificamos en tickets que van haciendo puntos que les canjean descuentos y demás, a pesar de que luego a final de mes no se les genera factura ordinaria. A ese respecto, esa sería otra de las futuras mejoras del componente, que en las F3 permitan un array de facturas sustituidas, y no solo una.

De todas formas ten cuidado con eso de generar un abono de un ticket completo para emitir el "correcto". La AEAT puede pensar que lo que estás haciendo es una baja de una factura por error total (cosa que permite el sistema bajo ciertos casos). Las rectificaciones por importe (que son las que soporta el componente a día de hoy) no están ideadas para este tipo de operaciones, sino para correcciones puntuales a algunos conceptos de la factura. Lo que estás haciendo sería más bien una factura sustitutiva, que tiene connotaciones totalmente distintas.

Te comento lo que hacemos nosotros por si te "cuadra" con la lógica de tu sistema:

Cuando le damos a Rectificar/Abonar factura, aparecen las líneas de la misma con un checkbox para seleccionar cual o cuales líneas quieres abonar. Eso genera una nueva ventana con esas líneas en negativo precargadas. Luego el usuario puede añadir nuevas líneas o modificar cantidades o lo que sea (como si tuviese un ticket/factura comenzado). Eso va a generar una factura rectificativa real de la original con el importe de la diferencia y los conceptos de la diferencia.

Esto hace que a nivel contable, todo cuadre tanto para tu propio sistema informático como para la AEAT.

[Matorral]

Empezado por DarkDudae

Lo que comentas de usar:

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

Es perfectamente válido. Piensa que yo con la propiedad de forzarTipo lo que busco más bien es "buscarle las cosquillas" a lo que acepta o no la AEAT.

Nosotros tenemos muchos clientes a los que identificamos en tickets que van haciendo puntos que les canjean descuentos y demás, a pesar de que luego a final de mes no se les genera factura ordinaria. A ese respecto, esa sería otra de las futuras mejoras del componente, que en las F3 permitan un array de facturas sustituidas, y no solo una.

De todas formas ten cuidado con eso de generar un abono de un ticket completo para emitir el "correcto". La AEAT puede pensar que lo que estás haciendo es una baja de una factura por error total (cosa que permite el sistema bajo ciertos casos). Las rectificaciones por importe (que son las que soporta el componente a día de hoy) no están ideadas para este tipo de operaciones, sino para correcciones puntuales a algunos conceptos de la factura. Lo que estás haciendo sería más bien una factura sustitutiva, que tiene connotaciones totalmente distintas.

Te comento lo que hacemos nosotros por si te "cuadra" con la lógica de tu sistema:

Cuando le damos a Rectificar/Abonar factura, aparecen las líneas de la misma con un checkbox para seleccionar cual o cuales líneas quieres abonar. Eso genera una nueva ventana con esas líneas en negativo precargadas. Luego el usuario puede añadir nuevas líneas o modificar cantidades o lo que sea (como si tuviese un ticket/factura comenzado). Eso va a generar una factura rectificativa real de la original con el importe de la diferencia y los conceptos de la diferencia.

Esto hace que a nivel contable, todo cuadre tanto para tu propio sistema informático como para la AEAT.

Pues me acabas de aclarar algo que tenía yo muy enrevesado¡¡¡¡¡

Me pongo a ello.

Un millón de gracias¡¡¡

[seccion_31]

hola !

parece que no nos vamos de veraneo... y estamos hackeando el componente.

La filosofía del componente, era cubrir los casos comunes de la forma mas simple.

Algunas cosas de las que habéis hablado, se pueden solucionar fácil, de echo las facturas sustitutivas iva a ser un array, pero los arrays deben ser de longitudes fijas. ¿de cuantos elementos estaríamos hablando?

por otro lado, crear una R4, R5 con importe positivo creo que se podría hacer de otra forma, por ejemplo actuando sobre: facturaRegistro.facturaRectificada y no creando otra estructura nueva, es decir, automatizamos R5,R4 con importe negativo, o bien mediante el campo facturaRectificada

El objetivo de este comentario es tratar de mantener la simplicidad del componente, queda claro para todos que si rellenamos facturaRegistro.facturaRectificada tenemos una rectificativa. Y asi no solo nos limitariamos por importe negativo.

Son ideas, y creo que deberiamos mantener el componente sin ramales, porque perderemos seguridad.

Saludos !

Y feliz verano. Estoy en mi correo disponible, para ajustar esto.

Tambien visto lo visto habria que pensar en crear documentacion....

[Matorral]

Empezado por seccion_31

hola !

parece que no nos vamos de veraneo... y estamos hackeando el componente.

La filosofía del componente, era cubrir los casos comunes de la forma mas simple.

Algunas cosas de las que habéis hablado, se pueden solucionar fácil, de echo las facturas sustitutivas iva a ser un array, pero los arrays deben ser de longitudes fijas. ¿de cuantos elementos estaríamos hablando?

Yo tengo clientes (restaurantes) que hacen facturación mensual de los "tickets" de algunos de sus clientes (empresas). Van a comer casi todos los días y al final del mes les hacen una factura agrupando todos los tickets del mes. Yo creo que limitando a 30 fras. simplificadas por cada F3 irían sobraos (es mi opinión).

por otro lado, crear una R4, R5 con importe positivo creo que se podría hacer de otra forma, por ejemplo actuando sobre: facturaRegistro.facturaRectificada y no creando otra estructura nueva, es decir, automatizamos R5,R4 con importe negativo, o bien mediante el campo facturaRectificada

El objetivo de este comentario es tratar de mantener la simplicidad del componente, queda claro para todos que si rellenamos facturaRegistro.facturaRectificada tenemos una rectificativa. Y asi no solo nos limitariamos por importe negativo.

Yo probé a hacer el cambio que me sugirió el compañero DarkDudae para hacer las rectificativas por diferencias ('I'), y cambié en uVerifactuFuncs los

Código Delphi [-]
if facturaRegistro.total <0 then

por

Código Delphi [-]
if facturaRegistro.facturaRectificada<>'' then

y van de cine. Me hace las rectificativas R5 con importes negativos y positivos.

Son ideas, y creo que deberiamos mantener el componente sin ramales, porque perderemos seguridad.

Totalmente de acuerdo¡¡¡¡¡

Saludos !

Y feliz verano. Estoy en mi correo disponible, para ajustar esto.

Gracias¡¡

Tambien visto lo visto habria que pensar en crear documentacion....

Yo me ofrezco voluntario.