Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por CarlosMz

Me he explicado mal, me refiero a ¿Cuántos caracteres se admiten por cada concepto de factura?, ¿Permitís saltos de línea en las descripciones de los conceptos de factura?
He visto que con FacturaE el campo ItemDescription tiene un máximo de 2500 caracteres.
Es por ir haciendo cambios por si en el futuro solicitaran las líneas de factura también

En verifactu no hay líneas.
En facturae, efectivamente 2500
Lo que tienes que tener en cuenta que los caracteres especiales tienen que ser pasados a utf8 para que el xml lo interprete correctamente y que además no den errores en el envío. Un retorno de carro no va a funcionar como tal al rescatar la información si no lo traduces, bajo mi criterio, si puedes evitarlo te puedes ahorrar errores de interpretación de esos datos con los receptores que tengan problemas para leer esos caracteres.

[antoine0]

Empezado por ermendalenda

Lo que tienes que tener en cuenta que los caracteres especiales tienen que ser pasados a utf8 para que el xml lo interprete correctamente y que además no den errores en el envío.

Para las finales de línea «normales», no solo hay que pasarlos a UTF-8, hay además que pasarlos a Entities XML. Un retorno de carro (CR) se escribirá "
", un cambio de línea (LF) se escribirá "
" (sin las apostrofes, sin las cursivas, pero con los punto comas)
Cuidado de hacerlo después de haber traducido los eventuales & a "&"

Un retorno de carro no va a funcionar como tal al rescatar la información si no lo traduces, bajo mi criterio, si puedes evitarlo te puedes ahorrar errores de interpretación de esos datos con los receptores que tengan problemas para leer esos caracteres.

Buen consejo.
También te ahorras las variaciones en la interpretación de las posibles convenciones de final de línea, CR|LF|CR+LF, que pueden ser interpretadas de manera distinta en recepción y dar un resultado difícil de entender (salto de línea suplementario o líneas mal alineadas).

[ermendalenda]

Por si os sirve
Me estaba volviendo loco con el dichoso mensaje de No responde y elija la opción de esperar o cerrar.
A veces se produce una acción consulta externa, grabación...que tiene algún pequeño retardo y no puedo realizarlo asincronamente ya que tengo que esperar la respuesta. Me sucedia que si el usuario empieza a darle clicks a la pantalla del software, Windows pensaba que el programa podia estar bloqueado y "actuaba de oficio" y te daba la opción a interrumpir el programa, claro el usuario a veces le daba a cerrar, y esto a veces rompia la hilera de grabación y por lo tanto me podía romper el dichoso encadenamiento...
Pues nada ya he insertado en cada acción, que pueda tener retardo, un bloqueo de teclado y ratón antes y desbloqueo después y solucionado, pero claro, hay que hacerlo con extremada precaución, ya que el bloqueo es total, y si en medio de ese bloqueo desbloqueo el usuario tiene que ejecutar alguna acción de responder a algún mensaje, aceptar, ok... no podrá e irremediablemente tendrá que reiniciar el equipo.

[ermendalenda]

Nodos unificados en FechaHoraHusoGenRegistro

Fecha, hora y huso horario de generación del registro de facturación. El huso horario es el que está usando el sistema informático de facturación en el momento de generación del registro de facturación.

DateTime. Formato: YYYY-MM-DDThh:mm:ssTZD

(ej: 2024-01-01T19:20:30+01:00) (ISO 8601)

Vosotros entendeis el ejemplo?

Hay que añadir lo de la ISO 8601?

[ermendalenda]

Empezado por ermendalenda

Nodos unificados en FechaHoraHusoGenRegistro




Vosotros entendeis el ejemplo?

Hay que añadir lo de la ISO 8601?

nada me respondo to mismo
no hay que ponerlo es una aclaracion, ha sido una pregunta tonta

[xevi]

¿Se sigue sin reglamentación oficial??
Estamos a Abril, y 9 meses ya nos vamos a 2025, o sea que tenemos todo este año para poder ofrecer nuestros servicios de mantenimiento de programas de gestión/facturación... si no tengo mal entendido, y a este paso, igual van a plazar el 1 de Julio del 2025 como fecha de entrada en vigor.

[CarlosR]

Empezado por xevi

¿Se sigue sin reglamentación oficial??
Estamos a Abril, y 9 meses ya nos vamos a 2025, o sea que tenemos todo este año para poder ofrecer nuestros servicios de mantenimiento de programas de gestión/facturación... si no tengo mal entendido, y a este paso, igual van a plazar el 1 de Julio del 2025 como fecha de entrada en vigor.

Que no te resulte extraño. Primero hay que crear miedo para que todos se pongan firmes !!!





Tengo dos dudas con respecto a las facturas anuladas:


1- La ley determina que se pueden anular facturas. Esto me parece bien desde un punto de vista puramente contable. Se supone que incluso contablemente el registro de iva tendrá huecos con las facturas anuladas. ¿ No ?



2- Desde un punto de vista de gestión de facturación una vez emitida una factura lleva inherentes uno o varios albaranes, Cada albarán lleva implícitas unas salidas de almacén con sus respectivas estadísticas. La pregunta que me asoma por encima de los hombros es, ¿ qué hacemos con esos movimientos ?


Lo que entiendo apriori es que la Agencia Tributaria quiere sí o sí que hagamos facturas rectificativas. Pero esto lleva a un callejón sin salida puesto que ya no se trata de modificar importes sino el propio titular y la ley de facturación impide rectificar las facturas de otro titular.


Ya que el reglamente definitivo antifraude no acaba de salir a la luz en su modelo definitivo, ¿ a alguien le ha preocupado esto ?


Un saludo.

[CarlosR]

Empezado por ermendalenda

Por si os sirve
Me estaba volviendo loco con el dichoso mensaje de No responde y elija la opción de esperar o cerrar.
A veces se produce una acción consulta externa, grabación...que tiene algún pequeño retardo y no puedo realizarlo asincronamente ya que tengo que esperar la respuesta. Me sucedia que si el usuario empieza a darle clicks a la pantalla del software, Windows pensaba que el programa podia estar bloqueado y "actuaba de oficio" y te daba la opción a interrumpir el programa, claro el usuario a veces le daba a cerrar, y esto a veces rompia la hilera de grabación y por lo tanto me podía romper el dichoso encadenamiento...
Pues nada ya he insertado en cada acción, que pueda tener retardo, un bloqueo de teclado y ratón antes y desbloqueo después y solucionado, pero claro, hay que hacerlo con extremada precaución, ya que el bloqueo es total, y si en medio de ese bloqueo desbloqueo el usuario tiene que ejecutar alguna acción de responder a algún mensaje, aceptar, ok... no podrá e irremediablemente tendrá que reiniciar el equipo.

Te propongo que el encadenamiento se haga de forma centralizada. Con un proceso único y centralizado (una cola temporal).
Cualquier bloqueo de un proceso local da al traste con todo el sistema de envíos y encadenamientos. Los DATAWARE de Delphi y C++ builder ya no sirven para eso. O al menos es mi impresión.

Un saludo.

[ermendalenda]

Empezado por CarlosR

Te propongo que el encadenamiento se haga de forma centralizada. Con un proceso único y centralizado (una cola temporal).
Cualquier bloqueo de un proceso local da al traste con todo el sistema de envíos y encadenamientos. Los DATAWARE de Delphi y C++ builder ya no sirven para eso. O al menos es mi impresión.

Un saludo.

Hollña gracias por la recomendación, el problema es que es un sistema antiguo de programación que no va demasiado bien el tema de las cachés de espera y y hay que hacer estragos para las colas, sobre todo con varias aplicaciones de escritorio en el mismo SIF, venta desasistida, pda y tpv, pero bueno con wl tema de bloqueos lo tengo ya bien atado para que no me de problemas.