FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
A ver si me he perdido algo.....
¿Hay ya normativa con lo que hay que hacer de forma definitiva? porque yo no la conozco.
__________________
Be water my friend. |
#2
|
||||
|
||||
Cita:
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.
__________________
Se humilde para admitir tus errores, inteligente para aprender de ellos y maduro para corregirlos. |
#3
|
|||
|
|||
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. Última edición por ermendalenda fecha: 21-02-2023 a las 19:07:09. |
#4
|
|||
|
|||
Segumos, con el glosario de terminos...
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. |
#5
|
|||
|
|||
Por donde Empezamos...
¿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 |
#6
|
|||
|
|||
Curl
|
#7
|
|||
|
|||
Consejos
Consejos ● 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 Última edición por ermendalenda fecha: 21-02-2023 a las 19:53:02. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|