Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[novatico]

Día 11 de Enero, BOE-A-2023-625

En la Disposición adicional decimosexta.

Saludos.

[[newtron]]

¡¡Es que molestáis mucho caramba!!

[ermendalenda]

Empezado por novatico

Día 11 de Enero, BOE-A-2023-625

En la Disposición adicional decimosexta.

Saludos.

Pues sí, ese puesto de atención al cliente sobra, si no para que está el BOE?

[ramherfer]

Hola buenas tardes.
Bueno creo que he leido practicamente todo el hilo, pero a pesar de que algunos usuarios nombran el ayudarnos y colaborar; sin ofender a nadie no veo mucho de eso. Si listas para ponernos a leer como posesos , dos estructuras de como debe de ir la información, el vídeo y algunos enlaces más. Pero código orientativo nada. Repito espero no ofender a ninguna persona, nada estaría más lejos de la realidad.
Nosotros coginos a unos de estos que saben un montón y cobran "por lo que creen que valen" y despues de ver todo lo expuesto en el hilo, mi cara la tengo a cuadros, es un poema.
Hicimos un monton de cosas, log de la aplicación en una tabla y en texto plano con control de tamaño del archivo de texto plano, no se pueden modificar ni borrar facturas, la factura actual apunta a la anterior, se actualizó el maldito manual, la aplicación tiene una declaración responsable y no se cuantas cosas más que no valen para nada, ya que despues de leer este hilo, no es el formato que quiere la AEAT.
En fin que estamos como al principio y todo lo hecho a la basura. Y me encuentro a un año y pico vista de que el ERP no se pueda utilizar y por lo tanto no valga para nada y es más sea ilegal.
No se ni por donde empezar ni por donde cogerlo, no he usado estructuras xml en mi vida. Para no mentir en los archivos SEPA que crea la aplicación para subir las remesas al banco (sin usar la aplicación de cada uno de ellos) y que los creo manualmente linea a linea según la estructura que en su día se presento para tal efecto. No se si para generar el fichero xml, sería de la misma forma. No se como generar el hash, ni de que generarlo (fichero completo o algún contenido del fichero -según he leido de algún nodo completo-) y no se como enviarlo ya que no se si dispongo de la funcionalidad curl, aunque se me paso por la cabeza mientras leia utilizar algún enlace php con la aplicación de escritorio.
En fin, tengo tal empanadilla mental, que no se si estoy en el lugar correcto para poner todo en orden y ponerme a codificar como un loco y que sea lo que Dios quiera, o visitar a un psicólogo.
Por eso agradecería, eternamente no, hasta el infinito, si alguien me pudiese orientar por donde coger esto para empezar como crear el maldito xml si como texto plano, si con algún componente....
Venga muchas gracias por leerme y si por ayudarme si llega el caso.

[ermendalenda]

Empezado por ramherfer

Hola buenas tardes.
Bueno creo que he leido practicamente todo el hilo, pero a pesar de que algunos usuarios nombran el ayudarnos y colaborar; sin ofender a nadie no veo mucho de eso. Si listas para ponernos a leer como posesos , dos estructuras de como debe de ir la información, el vídeo y algunos enlaces más. Pero código orientativo nada. Repito espero no ofender a ninguna persona, nada estaría más lejos de la realidad.
Nosotros coginos a unos de estos que saben un montón y cobran "por lo que creen que valen" y despues de ver todo lo expuesto en el hilo, mi cara la tengo a cuadros, es un poema.
Hicimos un monton de cosas, log de la aplicación en una tabla y en texto plano con control de tamaño del archivo de texto plano, no se pueden modificar ni borrar facturas, la factura actual apunta a la anterior, se actualizó el maldito manual, la aplicación tiene una declaración responsable y no se cuantas cosas más que no valen para nada, ya que despues de leer este hilo, no es el formato que quiere la AEAT.
En fin que estamos como al principio y todo lo hecho a la basura. Y me encuentro a un año y pico vista de que el ERP no se pueda utilizar y por lo tanto no valga para nada y es más sea ilegal.
No se ni por donde empezar ni por donde cogerlo, no he usado estructuras xml en mi vida. Para no mentir en los archivos SEPA que crea la aplicación para subir las remesas al banco (sin usar la aplicación de cada uno de ellos) y que los creo manualmente linea a linea según la estructura que en su día se presento para tal efecto. No se si para generar el fichero xml, sería de la misma forma. No se como generar el hash, ni de que generarlo (fichero completo o algún contenido del fichero -según he leido de algún nodo completo-) y no se como enviarlo ya que no se si dispongo de la funcionalidad curl, aunque se me paso por la cabeza mientras leia utilizar algún enlace php con la aplicación de escritorio.
En fin, tengo tal empanadilla mental, que no se si estoy en el lugar correcto para poner todo en orden y ponerme a codificar como un loco y que sea lo que Dios quiera, o visitar a un psicólogo.
Por eso agradecería, eternamente no, hasta el infinito, si alguien me pudiese orientar por donde coger esto para empezar como crear el maldito xml si como texto plano, si con algún componente....
Venga muchas gracias por leerme y si por ayudarme si llega el caso.

Jeje
Se puede linea a línea,. En unos días vuelvo a poner ejemplos de xmls de varios tipos de facturas xml en el actual formato xml con encadenamiento.
El hash, pues eso es un hash 256, que depende de que programa de desarrollo usas te puedo indicar o no.

[ramherfer]

Empezado por ermendalenda

Jeje
Se puede linea a línea,. En unos días vuelvo a poner ejemplos de xmls de varios tipos de facturas xml en el actual formato xml con encadenamiento.
El hash, pues eso es un hash 256, que depende de que programa de desarrollo usas te puedo indicar o no.

Estupendo ermendalenda. Si hay alguna forma de generar el xml que resulte más cómoda y elegante, pues ya me pongo a generar el maldito xml y ya llegará el señor Hash con Don Delphi 7 (casi nada), pero no se si el hash es del fichero o creo que leí de un solo nodo del contenido.
Tengo algo hecho para enlazar el ERP con una aplicación SII encargada de enviar los datos a la AEAT y que según la tabla de códigos de los xml en el encabezado del hilo de alta facturas y anulación de facturas me vendrá bien quitarles el polvo.

Agradezco tus dos líneas, no te puedes imaginar cuanto.

[[newtron]]

A ver si me he perdido algo.....

¿Hay ya normativa con lo que hay que hacer de forma definitiva? porque yo no la conozco.

[ramherfer]

Empezado por newtron

A ver si me he perdido algo.....

¿Hay ya normativa con lo que hay que hacer de forma definitiva? porque yo no la conozco.

¿Hay algo en lo que empezar a trabajar?
Ya tenemos algo. Hombre no quisiera yo esperar a última hora, para deprisa y corriendo empezar a hacer cosas. Por lo menos que genere los xml según lo que hay descrito, encadene los registros y sea capaz de enviarlos. Si se declarase mi ERP ilegal sería mi ruina y llevo con esto (la maldita ley del pico y pala) meses engañado por un desaprensivo oportunista.
Que sea definitivo o no, pero que funcione con lo que tengo. Luego si hay que invertir tiempo en modificar lo hecho e ir dandole forma, yo lo preferiría a tener que empezar desde cero.
Ojo es mi parecer y mi punto de vista (muy personal), no quiero decir que sea el correcto.

[ermendalenda]

XML
Es un tipo de fichero para almacenar información estructurada. Está estructura puede venir marcadas por unos formatos a partir de unas especificaciones (fichero XSD). La mayoría de los lenguajes actuales tienen funciones para facilitar su creación y lectura, aunque también podemos generarlo con lenguajes más antiguos con simples outputs a un fichero secuencial. Si los editas verás que son ficheros relativamente fáciles de entender.

XSD
Es un fichero que contiene las especificaciones para poder generar el XML, este fichero se usa para generar y comprobar correctamente los formatos de los XML. Normalmente se usa con funciones propias de cada lenguaje, pero se puede editar también manualmente.
HASH
Es el resultado de un algoritmo que genera una cadena de longitud fija (hash) a partir de otra cadena (o un fichero), la longitud de la cadena obtenida depende de la función hash que hayamos seleccionado, siendo las más comunes 2 del tipo Sha2: sha256 y sha512, ya se dejó de usar el tipo Sha1 ya que, a pesar de sus 160bits, se ha conseguido romper "fácilmente" la seguridad de la misma. Estas funciones devuelven una cadena de longitud fija, resultante de la aplicación de un algoritmo, por ejemplo la de sha256 devuelve una cadena de 256 bits(64 caracteres hexadecimales), cada vez que generamos el hash de una cadena, con la misma función, siempre nos va a devolver el mismo hash. El Hash no es reversible, es decir, no podemos extraer la cadena inicial desde un hash. Gracias al Hash podemos dar seguridad a las firmas.

UTF-8
Es un formato de codificación de caracteres que se usa para la codificación de correos y páginas webs.
Para generar los XML será necesario convertir determinados caracteres eapeciales(ñáé…) a este tipo de formato

URI ENCODE
Es otro formato que se usa en las direcciones de las páginas webs, para que los navegadores puedan interpretar ciertos caracteres y no es otra cosa que convertir una cadena a su valor hexadecimal de cada valor ascii de la cadena agregándole como prefijo el carácter "%" para que los navegadores lo interpreten y traduzcan adecuadamente. Nos será útil para generar el la cadena del QR para evitar los caracteres extraños que nos pueden dar problemas en la lectura de ese QR. O sea convierte caracteres (/+) por su equivalente hexadecimal y así al escanear el QR no tendremos problemas

BASE64 (ENCODE/DECODE)
Otro sistema de conversión de cadenas que usa 64 como base.
Cuando calculamos un HASH con la intención de utilizarlo para encadenamientos: generar QR, imprimir parte de ellos e insertarlo en un XML, hay que tener en cuenta que estos se generan con caracteres que pueden dar problemas en interpretación de los XML e incluso dependiendo el sistema de transmisión que utilicemos, puede dar problemas en la comunicación, por lo tanto, es necesario su conversión a este sistema, Base64.
El alfabeto Base64 se pueden agrupar en cuatro grupos:
Letras mayúsculas (0-25): ABCDEFGHIJKLMNOPQRSTUVWXYZ
Letras minúsculas (26-51): abcdefghijklmnopqrstuvwxyz
Dígitos decimales (52-61): 0123456789
Símbolos especiales (62-63): +/
Si abrimos un XML firmado y buscamos el identificador de la firma sólo nos vamos a encontrar estos caracteres.
Ya que parte del Hash en base64 va en el QR, podemos encontrarnos un problema a la hora, no de generarlo, si no a la hora de leerlo, ya que los 2 caracteres especiales +/ son interpretados de forma diferente al que necesitamos, por todos los navegadores, para no tener este problema convertimos esos 2 caracteres a URI*, pero esto no hay que realizarlo para el identificador Verifactu, que en este caso si debe/puede contenerlos.
Por otro lado hay que tener en cuenta que para calcular el CRC8 del QR si debe estar convertido esos caracteres a URI* pero, al igual que antes, no en el identificador.


ENCADENAMIENTO
Es la parte del blockchain que incluye ciertos datos de una factura(bloque de datos) anterior, estos datos son representativos de esa factura anterior, en el caso de las facturas son: el hash, la serie, el número y la fecha de emisión, incluyendose en la siguiente factura, reforzando, principalmente, la inviolabilidad de la factura anterior y así creando una cadena de datos continuo que si se modificará, posteriormente, rompería la cadena.

HUELLA
Son datos incluidos en un XML, que identifican con que software y dispositivo se ha emitido la factura: nombre, fabricante, licencia, versión y N. Serie del dispositivo.

[ermendalenda]

Aunque os he hablado antes de Base 64, este sistema de representación es el que se ha utilizado para los hash de firmas de TicketBai.
En Verifactu, aunque no está claro. parece que va a ser su representación en Hexadecimal, que es la representación por defecto, además piden un hash 256 y dejan un campo de 64 caracteres.

[ermendalenda]

¿Por donde empezamos?:
1. Investigar las herramientas que necesitaremos para:

● Generar XMLS (se puede generar como un fichero de texto)
● Comprobar un XML contra un XSD
● Firmar un XML con un certificado electrónico (Solo si vas a preprara el software para conservar los xmls sin enviar, no lo recomiendo)

● Generar un HASH de un nodo del XML generado.
● Enviar un fichero por WebService.


2. Adaptar lo máximo nuestro software al reglamento de facturación:


https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696
3. Adaptar nuestro software para poder generar los ficheros necesarios que tendremos que guardar o enviar para los tipos de facturas siguientes:



● SIMPLIFICADA
● FACTURA NORMAL/ORDINARIA
● SUSTITUTIVA O CANJE

● RECTIFICATIVA (POR SUSTIRUCION O POR DIFERENCIAS)
● ANULACIóN DE CUALQUIERA DE LAS ANTERIORES (TENIENDO EN CUENTA QUE HAY ANULACIONES QUE NO SE PUEDEN/DEBEN HACER, EJEMPLO, NO ES LOGICO ANULAR UNA FACTURA SIMPLIFICADA SI HAS EMITIDO UNA RECTIUFICATIVA DE ÉSTA .

● ETC.

Factura simplificada.

Son facturas en la que no constan los datos del receptor y se suele hacer por pequeños comercios en importes que no superen los 3000 euros o 400 en el resto no minoristas.

Factura sustitutiva o de canje.

Son las facturas emitidas por canje de las simplificadas en las que se hace constar los datos del receptor.

Duplicado de facturas(sin verifactu)

Se emite en sustitución de la original con los mismos datos de la original por pérdida, extravío, deterioro o por que haya que dárselo a varios pagadores... Hay que poner que es un Duplicado

Copia de facturas(sin verifactu)

Son una o varias copias para el emisor.

Factura proforma(sin verifactu)

Equivale a un presupuesto

[ermendalenda]

QUE ES CURL.EXE

Potente herramienta gratuita que funciona Para Linux y todos los Windows desde XP.
Se puede usar para transferir los datos a la AEAT.
Soporta los protocolos: ftp, ftps, http, tftp, scp, sftp, telnet, dict, file y ldap.
Autentificación: por usuario y contraseña o con certificado.

[ermendalenda]

Consejos

● Evitar en la medida de lo posible permitir cambios de fecha ni de hora del sistema donde está el software, además de siempre comprobar al generar una factura nueva que la fecha y hora del sistema no es anterior a la última factura generada.
● Al generar una factura Comprobar los identificadores y datos de clientes, CIF, NIF. NIE, nombre… con una entidad verificadora autorizada.
● No permitir generar facturas en el sistema si existen errores en los que el proceso de encadenamiento no se vaya a realizar correctamente.
Si vas a usar un certificado digital para la opción de no enviar los XMLS, verificar, si es posible, en cada firma que dicho certificado no ha sido revocado o ha caducado (avisad unos días antes de la caducidad). Es conveniente tener 2 certificados generados por 2 entidades diferentes, por ejemplo: FNMT e IZENPE, con fechas de generación diferentes, esto nos servirá para cambiar de certificado en el software antes de su renovación, ya que se revocará el que está en uso en ese momento de la renovación

● Los avisos a los usuarios deben ser entendibles para ellos.
● Cada error, ya sea por problemas en la generación del XML o por un error recibido por los servidores de verifactu, debe ser tratado lo más convenientemente posible según el grado del problema, por ejemplo enviar un mensaje inmediato a la persona adecuada y siempre registrar el evento también de la forma adecuada.
● Revisa tu software para que el numerador de facturas no de saltos por errores o por bloqueos.

● Los envíos de las facturas se harán en orden PEPS(primero en entrar primero en salir, también llamado FIFO), independientemente de si se emiten varias series en la misma máquina. Ejemplo, emisión de facturas: 3-245 después la 1-222 y a continuación la 3-246, se enviarán en ese mismo orden cronológico de generación, primero la 3-245, después la 1-222 y a continuación la 3-246.
● Al igual que los envíos, el encadenamiento de las facturas se efectuará independientemente de la serie, pudiendo encadenarse distintas series.
● Al generar un pdf hay que incluir los mismos datos, QR. Pero por ejemplo en la EFactura no hay que incluir el QR pero si el identificador de ese QR
● Si no hay conexión para enviar los ficheros, y se ha seleccionado modalidad de envío, ésta debe realizarse en cuanto se restablezca el servicio y en el orden en que se generaron.


La selección de modalidad con envío implica que debe realizarse así durante todo el ejercicio



-Siempre que se reimprima o se envie a un cliente hay que poneer que es "Duplicado"
-Para el emisor, puede pedir 1 copia o varias hay que poner que es "Copia"
-Comprobación datos clientes contra la aeat y el vies

[ermendalenda]

Espero que os ayude para poder entrar en materia, como veis, si quereis minimizar riesgos, hay que tener mas cosas en cuenta de las que parecia.

[ermendalenda]

Aqui os dejo unos xmls de ejemplos, los ficheros están numerados según orden cronológico en el que se realizaron las facturas.
La primera factura, por lógica, no está encadenada, por lo cual se omite el nodo de encadenamiento.

[ermendalenda]

Aqui les adjunto los pdfs relaacionados a las facturas de los xmls anteriores.
E insertado en las facturas un QR inventado basado en ticketbai, ya que aún no han mencionado estructura ni medidas.
Saludos

[[newtron]]

Joder... esto es lo que yo llamo una Clase Magistral.

Muchas gracias compañero. Estoy seguro que todo esto nos vendrá bien a muuuuuuuuuuuucha gente.

[keys]

Menudo curro

[afxe]

Ermendalenda, te lo has currado... la verdad es que RamHerFer tiene razón... deberíamos haber trabajado más en equipo para escribir un workflow, tener una biblioteca de herramientas externas y otra de código. Y no vendría mal un apartado de "Preguntas Frecuentes". Pero no me miréis a mí, no tengo ni idea de cómo hacer todo eso, pero me encantaría participar.

Al final, con tantos aplazamientos del desarrollo técnico, el que más y el que menos hemos bajado los brazos esperando a que se aclaren, porque cada vez que dicen algo nos ponemos a desarrollar y luego se retractan, cambian, modifican, deshacen... para dejarnos con cara de tontos. Por lo cual la decisión más sabia que he leído en el foro es esperar a que desplieguen el desarrollo técnico y aclaremos dudas... y sinceramente, creo que ellos están más perdidos que nosotros, por lo que he decidido tomármelo con calma.

No podemos elegir trabajar enganchado permanentemente con la AEAT, pues implicaría que si se pierde conexión no se puede facturar... hace poco una obra cortó una fibra en un polígono y dejó a muchos negocios, incluso 3 grandes supermercados, sin internet durante 2 días.

En cuanto al encadenamiento, tenía entendido que se podía y debía hacer por serie, ya que en un sistema de facturación NO centralizada (cada puesto o dispositivo puede emitir facturas), no puede hacer el encadenamiento con las facturas emitidas por otros dispositivos.

Lo veo todo muy verde aún... pero a lo mejor es mi desidia por este asunto.

[ermendalenda]

Buenas, independientemente de que software de desarrollo useis existe una libreria de
windows para generar los hash "advapi32.dll", el desarrollo si lo buscais por internet seguro que lo encontrais, la declaración en vb sería:

Declare Function CryptCreateHash Lib "advapi32.dll" _
(ByVal hProv As Long, ByVal Algid As Long, ByVal hKey As Long, ByVal dwFlags As Long, _
ByRef phHash As Long) As Long
Declare Function CryptReleaseContext Lib "advapi32.dll" _
(ByVal hProv As Long, ByVal dwFlags As Long) As Long
Declare Function CryptCreateHash Lib "advapi32.dll" _
(ByVal hProv As Long, ByVal Algid As Long, ByVal hKey As Long, ByVal dwFlags As Long, _
ByRef phHash As Long) As Long
Declare Function CryptDestroyHash Lib "advapi32.dll" _
(ByVal hHash As Long) As Long
Declare Function CryptHashData Lib "advapi32.dll" _
(ByVal hHash As Long, pbData As Any, ByVal cbData As Long, ByVal dwFlags As Long) As Long
Declare Function CryptGetHashParam Lib "advapi32.dll" _
(ByVal hHash As Long, ByVal dwParam As Long, pbData As Any, ByRef pcbData As Long, _
ByVal dwFlags As Long) As Long

Y aquí las constantes que declaro para facilitar su uso

Private Const PROV_RSA_FULL As Long = 1
Private Const PROV_RSA_AES As Long = 24
Private Const CRYPT_VERIFYCONTEXT As Long = &HF0000000

Private Const HP_HASHVAL As Long = 2
Private Const HP_HASHSIZE As Long = 4

Private Const ALG_TYPE_ANY As Long = 0
Private Const ALG_CLASS_HASH As Long = 32768

Private Const ALG_SID_MD2 As Long = 1
Private Const ALG_SID_MD4 As Long = 2
Private Const ALG_SID_MD5 As Long = 3
Private Const ALG_SID_SHA As Long = 4
Private Const ALG_SID_SHA_256 As Long = 12
Private Const ALG_SID_SHA_384 As Long = 13
Private Const ALG_SID_SHA_512 As Long = 14

Private Const CALG_MD2 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_MD2)
Private Const CALG_MD4 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_MD4)
Private Const CALG_MD5 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_MD5)
Private Const CALG_SHA As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_SHA)
Public Const CALG_SHA_256 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_SHA_256)
Public Const CALG_SHA_384 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_SHA_384)
Public Const CALG_SHA_512 As Long = (ALG_CLASS_HASH Or ALG_TYPE_ANY Or ALG_SID_SHA_512)
Private pvToByteArray1() As Byte