Campos modificables de una factura

[Faneka]

Tengo la duda de si hay algún campo de la factura que una vez emitida, enviada y demás se pueda modificar sin que afecte al Veri*Factu y sea legal, por ejemplo aquí en la empresa me han pedido que habilite una opción en la factura para en principio poder modificar la forma de cobro, porque si una vez emitida, el cliente nos dice que ahora en vez de al contado lo quiere giro a 30 días por ejemplo, pues no haya que hacer ningún abono, rectificativa, ... que se podría cambiar la forma de cobro y listo, ya que no es un dato que viaja en el XML. La pregunta es ¿esto es factible? o realmente no es posible modificar ningún campo de la factura una vez emitida/enviada.

[CarlosMz]

Hola,

En la documentación indica que se puede modificar campos en la factura siempre y cuando NO afecten al RF, como cuotas, NIF.....

Es decir, se puede modificar para poner observaciones, marcarla impagada, apuntar cobros recibidos...

[Neftali [Germán.Estévez]]

Empezado por Faneka

Tengo la duda de si hay algún campo de la factura que una vez emitida, enviada y demás se pueda modificar sin que afecte al Veri*Factu y sea legal, por ejemplo aquí en la empresa me han pedido que habilite una opción en la factura para en principio poder modificar la forma de cobro, porque si una vez emitida, el cliente nos dice que ahora en vez de al contado lo quiere giro a 30 días por ejemplo, pues no haya que hacer ningún abono, rectificativa, ... que se podría cambiar la forma de cobro y listo, ya que no es un dato que viaja en el XML. La pregunta es ¿esto es factible? o realmente no es posible modificar ningún campo de la factura una vez emitida/enviada.

Deberías poder modificar cualquier campo de la factura que no afecte al RF.
Nosotros lo que hacemos es generar un nuevo RF después de la modificación y lo comparamos con el anterior (sin tener en cuenta campos como fecha, huella,...). Simplificando un poco.

Si el nuevo RF es igual que el anterior, es que ese campo no afecta y por lo tanto se puede guardar la factura.

[CarlosMz]

Interesante mecanismo de control y validación

[Neftali [Germán.Estévez]]

Empezado por Neftali [Germán.Estévez]

Nosotros lo que hacemos es generar un nuevo RF después de la modificación y lo comparamos con el anterior (sin tener en cuenta campos como fecha, huella,...). Simplificando un poco.

Amplío un poco la idea por si a alguien le interesa.
Realmente no se comparan XMLs directamente, si no que se convierten a objetos delphi y lo que realmente se comparan son los objetos.
¿Porqué este paso de más?
Porque comparar objetos nos permite más libertad en algunos casos. Por ejemplo, si en una versión 1.2 se amplían los decimales de un campo total (como ya pasó en ticketBAI), al comparar XMLs devolvería que son diferentes, si comparamos objetos (delphi) podemos decir que 13.05 es lo mismo que 13.0500. También para solventar problemas con nuevos campos en versiones posteriores o cambios de campos que pasan de obligatorio a no-obligatorio y al revés.
Por experiencia en TBAI, los objetos dan más potencia y libertad en estos casos.

[Faneka]

Perfecto, muchas gracias por la aclaración.

[[newtron]]

Empezado por Neftali [Germán.Estévez]

Deberías poder modificar cualquier campo de la factura que no afecte al RF.
Nosotros lo que hacemos es generar un nuevo RF después de la modificación y lo comparamos con el anterior (sin tener en cuenta campos como fecha, huella,...). Simplificando un poco.

Si el nuevo RF es igual que el anterior, es que ese campo no afecta y por lo tanto se puede guardar la factura.

Buena idea compañero. Gracias.