Campos modificables de una factura

[RanNav]

Empezado por gcqZW

No confundir la descripción de la operación con la descripción de cada articulo.

Claro,
Pero este campo debería ir en la descripcionoperacion, no? Al menos así lo he interpretado yo en mi programa. Si no, no tiene sentido que sea obligatorio el campo "Descripción de las operaciones" y no haya ningún campo habilitado para ello en los RF que hay que mandar a la AEAT, a menos que tenga que ser un campo interno del programa que no se tenga que mandar...

[gcqZW]

Sisi, pero me refiero que aunque ponga lo mismo, no es lo mismo, nosotros en ese nodo ponemos algo genérico tipo "venta bollería y lácteos", y si queremos modificarlo tocaría subsanación ya que es un nodo del RF.

[Jarogo08]

Empezado por gcqZW

No confundir la descripción de la operación con la descripción de cada articulo.

Claro... yo estoy hablando de la descripción del artículo (que era lo que preguntaban), no la descripción de la operación

[RUBEN_SP]

Empezado por Jarogo08

Claro... yo estoy hablando de la descripción del artículo (que era lo que preguntaban), no la descripción de la operación

Según el ROF (BOE-A-2012-14696-consolidado: https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696) para cambiar la descripción de las líneas de la factura debes hacer una factura rectificativa.

[Jarogo08]

Empezado por RUBEN_SP

Según el ROF (BOE-A-2012-14696-consolidado: https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696) para cambiar la descripción de las líneas de la factura debes hacer una factura rectificativa.

y según el que me contestó a la pregunta que le hice no es necesario:

https://www.clubdelphi.com/foros/sho...1&postcount=16

así estamos... uno te dice una cosa y otro te dice la contraria

[RUBEN_SP]

Empezado por Jarogo08

y según el que me contestó a la pregunta que le hice no es necesario:

https://www.clubdelphi.com/foros/sho...1&postcount=16

así estamos... uno te dice una cosa y otro te dice la contraria

Pero el ROF es de obligado cumplimiento desde el 2012. La respuestas que te dan en [email protected] no son vinculantes. Si te das cuenta en esa misma respuesta ellos mismos se contradicen: Si los errores detectados tras la emisión NO están contemplados en el ROF... y eso esta claramente reflejado en el ROF que es uno de los datos inalterables de la factura tal como indica [RanNav] en su post

[ermendalenda]

Empezado por Jarogo08

y según el que me contestó a la pregunta que le hice no es necesario:

https://www.clubdelphi.com/foros/sho...1&postcount=16

así estamos... uno te dice una cosa y otro te dice la contraria

Bueno, es verdad que te contestó ambiguamente, pero veo que te ha dicho que si no está contemplado en el ROF(reglamento de facturacion) , pero las descripciones de los artículos sí que lo están.
Como te dicen los otros usuarios, tienes que hacer rectificativa. Y aunque esos datos no estén en verifactu no hay otra forma.

[gcqZW]

pero las descripciones de los artículos sí que lo están

Donde?? que yo en el ROF no consigo ver ninguna mención a la descripción de los artículos.

[ermendalenda]

Empezado por gcqZW

Donde?? que yo en el ROF no consigo ver ninguna mención a la descripción de los artículos.

Según el Rof la descripción debe ser determinante para calcular las cuotas, si es un error menor(tipográfico...) y no es determinante para saber que tipo de producto es, no es obligatorio, pero.... ahora tenemos la nueva normativ de la ley antifraude, en la que cada rectificacion debe tener una trazabilidad, inviolabilidad, etc... que para ello te dice que tienes que crear registros sobre esa modificacion, tu veras como lo haces. ¿Un evento o log?, aeemas, si vas a dejar al usuario cambiar descripciones te arriesgas a tener un problema, ya que el nuevo concepto(descripcion) puede no cumplir con lo que te he comentado.
Por otro lado verifactu no elimina los posibles requerimientos de facturas emitidas y libros de iva, así que ojito que lo que el cliente tenga coincida.

[gcqZW]

Entiendo que estamos hablando del punto "F" del articulo 6:

f) Descripción de las operaciones, consignándose todos los datos necesarios para la determinación de la base imponible del Impuesto, tal y como ésta se define por los artículos 78 y 79 de la Ley del Impuesto, correspondiente a aquéllas y su importe, incluyendo el precio unitario sin Impuesto de dichas operaciones, así como cualquier descuento o rebaja que no esté incluido en dicho precio unitario

Que de todas maneras, no dejamos cambiar las descripciones de los artículos de la factura ni prácticamente nada que no sea forma de pago, pero me resulta un tanto ambiguo. Y lo que no veo es que nodo del RF es el correspondiente, ya que el nodo <DescripcionOperacion> si no tengo entendido mal, se rellena con algo del palo: "Venta de productos lácteos y panadería". Que es el que me hace pensar que si queremos modificarlo de la factura tendríamos que subsanar y no rectificar.

[ermendalenda]

Empezado por gcqZW

Entiendo que estamos hablando del punto "F" del articulo 6:


Que de todas maneras, no dejamos cambiar las descripciones de los artículos de la factura ni prácticamente nada que no sea forma de pago, pero me resulta un tanto ambiguo. Y lo que no veo es que nodo del RF es el correspondiente, ya que el nodo <DescripcionOperacion> si no tengo entendido mal, se rellena con algo del palo: "Venta de productos lácteos y panadería". Que es el que me hace pensar que si queremos modificarlo de la factura tendríamos que subsanar y no rectificar.

Si, la normativa tiene lagunas, py no, no hay nodos correspondientes para las descripciones, ya que los items de la factura no se envian a verifactu, pero ten en cuenta que hay muchos desarrolladorws que tienen también tiketbai y ahi si que hay que mandarla y subsanar(rectificar) si eso cambia. Como ya te he comentado es arriesgado no rectifica, ya que si por ejemplo cambian el reglamento técnico y agregan los items, puede que no te acuerdes que hay que tenerlo en cuenta y después tendrás otro problema, en Factura electrónica van los items y tendrás que mandarlas a la aeat, y si cambias algo de lo dicho, irremediablemente tendrás que subsanar(rectificar).
La subsanacion no es correcta, por que verifacgu te dice que si no afecta a nada del registro de factura (nodo de registro de facturacion) verifactu, NI a ningún campo impreso(o pdf o electronico) puedes subsanar, o sea, no puedes emitir subsanacion si el arreglo es de cualquier cosa de la factura emitida VISIBLE.

[gcqZW]

Pues lo había entendido mal, yo pensaba que si afectaba al ROF - rectificativa, si estaba en un nodo del RF pero no afectaba el ROF - subsanación, y que todo lo demás se podía modificar sin más.

Gracias por la respuesta por cierto.

[ermendalenda]

Empezado por gcqZW

Pues lo había entendido mal, yo pensaba que si afectaba al ROF - rectificativa, si estaba en un nodo del RF pero no afectaba el ROF - subsanación, y que todo lo demás se podía modificar sin más.

Gracias por la respuesta por cierto.

Es casi igual, llos nodos que están en el nodo de facturación están contemplados en el ROF , no recuerdo si la descripción de la factura(no la descripción de los productos) está en el ROF, pero el resto si.

[ermendalenda]

Código PHP:

<RegistroFactura>
    <DatosFactura>
        <TipoFactura>F1</TipoFactura>
        <FechaExpedicionFacturaEmisor>2025-06-05</FechaExpedicionFacturaEmisor>
        <DescripcionFactura>Venta en restaurante</DescripcionFactura>
        <FacturaSimplificada>Sí</FacturaSimplificada>
        <ImporteTotal>86.90</ImporteTotal>
        <TipoDesglose>
            <DesgloseFactura>
                <Sujeta>
                    <NoExenta>
                        <DetalleIVA>
                            <TipoImpositivo>21.00</TipoImpositivo>
                            <BaseImponible>71.82</BaseImponible>
                            <CuotaRepercutida>15.08</CuotaRepercutida>
                        </DetalleIVA>
                    </NoExenta>
                </Sujeta>
            </DesgloseFactura>
        </TipoDesglose>
    </DatosFactura>
    <IDFactura>
        <IDEmisorFactura>
            <NIF>12345678Z</NIF>
        </IDEmisorFactura>
        <NumeroFactura>R-2025/321</NumeroFactura>
        <SerieFactura>R-2025</SerieFactura>
        <FechaExpedicionFacturaEmisor>2025-06-05</FechaExpedicionFacturaEmisor>
    </IDFactura>
</RegistroFactura> 


[bmfranky]

Empezado por ermendalenda

Código PHP:

<RegistroFactura>
    <DatosFactura>
        <TipoFactura>F1</TipoFactura>
        <FechaExpedicionFacturaEmisor>2025-06-05</FechaExpedicionFacturaEmisor>
        <DescripcionFactura>Venta en restaurante</DescripcionFactura>
        <FacturaSimplificada>Sí</FacturaSimplificada>
        <ImporteTotal>86.90</ImporteTotal>
        <TipoDesglose>
            <DesgloseFactura>
                <Sujeta>
                    <NoExenta>
                        <DetalleIVA>
                            <TipoImpositivo>21.00</TipoImpositivo>
                            <BaseImponible>71.82</BaseImponible>
                            <CuotaRepercutida>15.08</CuotaRepercutida>
                        </DetalleIVA>
                    </NoExenta>
                </Sujeta>
            </DesgloseFactura>
        </TipoDesglose>
    </DatosFactura>
    <IDFactura>
        <IDEmisorFactura>
            <NIF>12345678Z</NIF>
        </IDEmisorFactura>
        <NumeroFactura>R-2025/321</NumeroFactura>
        <SerieFactura>R-2025</SerieFactura>
        <FechaExpedicionFacturaEmisor>2025-06-05</FechaExpedicionFacturaEmisor>
    </IDFactura>
</RegistroFactura> 


Empezado por ermendalenda

Es casi igual, llos nodos que están en el nodo de facturación están contemplados en el ROF , no recuerdo si la descripción de la factura(no la descripción de los productos) está en el ROF, pero el resto si.

Una cosa, en mi caso cuando facturo una reparación, en el registro de mi factura, no el registro de verifactu, la tabla de la factura en si, lo que almaceno es un indice a la reparación realizada, no la reparación en si, si permito modificar la reparación, cuando vuelvo a cargar la factura, se muestra la modificada, eso en este caso seria ilegal?, debería poner un check, de facturada y a partir de entonces no dejar modificar en el histórico?
Gracias por tu respuesta como siempre.

[RanNav]

Empezado por bmfranky

Una cosa, en mi caso cuando facturo una reparación, en el registro de mi factura, no el registro de verifactu, la tabla de la factura en si, lo que almaceno es un indice a la reparación realizada, no la reparación en si, si permito modificar la reparación, cuando vuelvo a cargar la factura, se muestra la modificada, eso en este caso seria ilegal?, debería poner un check, de facturada y a partir de entonces no dejar modificar en el histórico?
Gracias por tu respuesta como siempre.

En un principio, si el cambiar la reparación afecta a importes, cuotas, descripciones, cantidades... cualquier campo que afecte al ROF o lo "visible" de la factura impresa deberías hacer una rectificativa, sino, y es que la factura está ligada a una tabla de reparaciones para saber qué reparaciones están en qué factura, entiendo que no tendrías que modificar nada en caso de no afectar a ningún campo de la factura...

[RanNav]

Empezado por ermendalenda

Es casi igual, llos nodos que están en el nodo de facturación están contemplados en el ROF , no recuerdo si la descripción de la factura(no la descripción de los productos) está en el ROF, pero el resto si.

No, las descripciones de los "movimientos" de una factura no están contemplados en el ROF, pero podemos interpretar que, como dice la AEAT, al ser un campo "visible" en las facturas impresas sí que requiere de una rectificativa.
Esto a mi parecer, no debería ser así, ya que vas a liar al usuario si simplemente ha cometido una falta de ortografía en la factura y quiere enviársela correcta al cliente. ¿Enserio en estos casos van a ser tan inflexibles de tener que crear una rectificativa...?
En fin, esto de VeriFactu va a complicar la facturación a los usuarios de una manera...

[bmfranky]

Empezado por RanNav

En un principio, si el cambiar la reparación afecta a importes, cuotas, descripciones, cantidades... cualquier campo que afecte al ROF o lo "visible" de la factura impresa deberías hacer una rectificativa, sino, y es que la factura está ligada a una tabla de reparaciones para saber qué reparaciones están en qué factura, entiendo que no tendrías que modificar nada en caso de no afectar a ningún campo de la factura...

Empezado por RanNav

No, las descripciones de los "movimientos" de una factura no están contemplados en el ROF, pero podemos interpretar que, como dice la AEAT, al ser un campo "visible" en las facturas impresas sí que requiere de una rectificativa.
Esto a mi parecer, no debería ser así, ya que vas a liar al usuario si simplemente ha cometido una falta de ortografía en la factura y quiere enviársela correcta al cliente. ¿Enserio en estos casos van a ser tan inflexibles de tener que crear una rectificativa...?
En fin, esto de VeriFactu va a complicar la facturación a los usuarios de una manera...

Hola, racias por la respuesta, en mi caso es la segunda, que cometo tropecientas faltas de ortografía, o a veces hay clientes que quieren que les especifiques mejor la reparación realizada, pero sin cambiar los importes, que por lo que pone en los faqs, sería una R4 de manual...

[gcqZW]

No, las descripciones de los "movimientos" de una factura no están contemplados en el ROF, pero podemos interpretar que, como dice la AEAT, al ser un campo "visible" en las facturas impresas sí que requiere de una rectificativa.

Entiendo... gracias.

que cometo tropecientas faltas de ortografía

Hace ya mucho que no te veo alguna falta grave jejejeje

[bmfranky]

Empezado por gcqZW

Entiendo... gracias.



Hace ya mucho que no te veo alguna falta grave jejejeje

, Es que al final he tenido que instalarme el corrector , en el Firefox...