Duda sobre campos en el xml
 

Hola buenas tengo una duda

Y es que no se si faltan por poner mas campos , por ejemplo yo al generar un xml solo uso los campos que se muestran en el boe : https://www.boe.es/boe/dias/2024/10/...2024-22138.pdf

Pero no se si falta por poner algun campo mas que se muestra ahi o como.

No sé exactamente a qué te refieres pero si envías y te devuelve un OK entiendo que lo que envíes estará correcto y que no faltará ningún campo.

Hola, le respondo, que lo que ha de tener en cuenta es la descripcion aqui,

Este es el documento de diseño de los registros de facturacion.
https://www.agenciatributaria.es/sta...VeriFactu.xlsx
que es la que actualizan y si sale alguna modificacion , estara alli antes que se publique en el boe.

Claro yo estoy usando los campos que aparecen ahi , por eso lo digo que me parecen pocos la verdad, ahora me da ok todo al enviar los xml asi que si funciona no lo toco.

Lo mismo te parecen pocos por que no hay que mandar los items(artículos facturados) como en otros reglamentos que si hay que mandarlo, como ticketbai y face

Si en el registro de facturación generado no se mandan las líneas de factura, ¿qué estáis usando para el campo DescripcionOperacion?

La descripción de la cuenta de Ventas y en su defecto "Ventas".

En mi caso depende de la factura, si es una reparacion, intenete poner la reparacion, pero me quedaba sin letras, asi que ahora pongo, en las de reparacion, "Factura reparacion realizada",venta, "Factura materiales servidos", en abonos, "Factura de abono, total/parcial de la factura nºxxxxx de 20xx", y asi con todas las diferentes.

Pues en nuestro software de facturación que no contiene contabilidad tendrá que ser "Ventas". No obstante, mandaré un mail a verifactu a ver qué me dicen al respecto, pero si no hay que mandar las líneas de factura veo absurdo pedir el campo DescripcionOperacion como obligatorio si lo que vas a poner siempre es "Ventas".

Hola, absurdo tampoco, tenga en cuenta que ahi es donde debes especificar por que emites ese registro, puede ser por ejemplo, no una venta sino el cambio de destinatario, por error, o por ejemplo en una que tuve que emitir un abono porque , con las prisas ,puse un cero de mas al poner las horas y multiplicaba por 10, entonces es una rectificativa, por diferencias, "Por error al tipear las horas".

¿Pero entonces lo rellenas tú desde código o pones un campo en pantalla para que el usuario indique lo que quiera? Para mi no tiene sentido ni una ni la otra, porque descripción breve de la operación puede ser miles de razones, y no tiene sentido añadir un campo para decirle al que está facturando que ponga las razones de por qué factura. De hecho, poner "Ventas" es también absurdo porque siempre son ventas, en Veri*Factu hablamos sólo de facturas emitidas.

Entonces lo que comentas es el llamado campo Observaciones que habitualmente se deja para indicar cosas como "factura que abona a tal por tal razón". Pero si esto es así, es lo que comentaba, que DescripcionOperacion debería ser un campo opcional.

No sé si te refieres a algun campo tuyo, observaciones no hay nodos.
De todas formas no te rayes demasiado con la descripción operación, pon algo genérico:venta, factura, rectificacion,... y cuando vayas avanzando lo vas afinando, no creo que vayan a profundizar en algo que no han descripto demasiado en el reglamento que sólo pone "descripción del objeto de la factura"

No hay nodos en el modelo de registro de facturación (XML), en cambio sí está el DescripcionOperacion. Pero me refería a que Observaciones es un campo habitual en los programas de facturación, y suele usarse para indicar por qué se hizo la operación, de ahí la similitud con el de DescripcionOperacion. El resto se supone que tú emites la factura por venta de productos o servicios, y por tanto no escribes nada ahí.

Yo tampoco le he visto nunca ningún sentido a que ese campo sea obligatorio.
En mi caso vi su obligatoriedad en TicketBai (tanto en ventas como en compras y gastos), y he estado poniendo "Venta" o "Rectificativa" en todas las ventas. Está en uso y explotación enviando a la hacienda foral sin ningún tipo de problema desde hace meses.


En Verifactu voy a seguir la misma filosofía o como mucho incluir el número o fecha de la factura.

El campo Descripción de Operación se usa para describir de forma breve el contenido de la operación realizada, por ejemplo, atendiendo a los departamentos o familias donde estén ubicados los productos que intervienen en la venta, podríamos poner si es una entrega de bienes, "Ventas de Combustibles y Tienda.", donde Combustibles y Tienda son los departamentos que engloban los diferentes ítems de venta en dicha operación. Si estamos hablando de prestación de servicios, podríamos poner "Realización de PreItv" siguiendo el mismo criterio.

Desaconsejan poner en este campo datos redundantes que ya aparecen en el registro de facturación, como que si es una rectificativa, la fecha, etc
Obviamente, este proceso es automático sin intervención del usuario

Si no hay intervención del usuario para el campo DescripcionOperacion, y mi factura tiene un concepto manual, ¿cómo sabe el programa que es por ejemplo "Inspección Pre-ITV"? Le tendré que mandar al menos 1 línea de la factura.

Cada vez me parece más claro que los que han redactado el reglamento no tienen mucha idea de programación, ni de cómo funciona internamente un programa de facturación.

Bueno, como solo es aconsejable, para ñas ventas en las que no es lógico poner cosas específicas se ponen descripciones generales

Aunque tenga un concepto manual, seguro que dicho concepto lo tienes ubicado en algún departamento, familia o grupo, depende de la jerarquización que hagas en tu programa de los ítems de venta. Si no envías ítems de venta, tu factura estará a cero y en este caso, cuando no hay ítems de venta, se suele poner "Factura Anulada".
Fíjate que ese campo tiene una longitud de 500 caracteres, la Aeat espera encontrar en él una descripción de la venta que has hecho sin llegar a poner cada ítem especificado con todos sus campos, uds, precio, descuentos, etc.

Esto nos lo transmitieron en su momento con el SII, y tuvimos que jerarquizar los ítems de venta de forma más clara parar poder rellenar este campo y que fuera informativo. No vale poner "Ventas" a secas

Está claro que estos han cogido el mismo campo que para el SII, de hecho se llama igual y tiene el mismo tamaño.
En contabilidad sí tiene sentido, porque le mandas el concepto del apunte contable que referencia a la factura. Pero en facturación, como dicen en mi tierra, esto es "liar la batata". Para mi gusto, sirve lo mismo que el campo Concepto del Bizum :D.

Y me pregunto yo, ¿no era más fácil aplicar el SII a todo el mundo y ya está? Después de toda esta "cochinada" vendrá la facturación electrónica, así que para entonces tendremos SII, Veri*Factu y facturación electrónica obligatoria funcionando simultáneamente. Parece que según el que esté al frente de la AEAT se le exigen cosas en su mandato o tiene que justificar presupuestos, porque si no no se explica. Al final como el dinero es de todos excepto de ellos, pues no les duele... Y mientras, los desarrolladores a trabajar para ellos, muchas veces de gratis.