Muchas gracias Neftalí.

Antes lo hacia con un filestream y me hacia lo mismo, ya no se que hacer, probaré con los componentes que me comenta keys.

Hola en el primer y segundo mensaje de este tema tienes ejemplos de como hacerlo. Lo digo por no repetir más mensajes, si tienes algún problema me dices.

A nosotros nos pasó (en uno de los casos) y al final lo que hicimos fue, grabar a disco en hexadecimal después cada uno de los pasos, desde la generación hasta el envío.
Al final detectamos una asignación que nos cambiaba la codificación.

Solo queria dar las gracias a Bilbur por el firmador.php que puso por aquí

Estaba usando el autofirma y es mas lento que.... por lo que obviamente los clientes se quejaban.
Con el firmador.php lo hace super rapido. Lo he subido a un subdominio de una web nuestra para que se pueda usar desde fuera, y ya que lo tenia hecho, he puesto que si por lo que sea no puede conectar a la web, use el autofirma :D

Consulta función GetCrc8
 

Hola, unomasmas
Igual te sorprende una respuesta a tu post 4 años después de publicarlo, pero estoy con un programa de TicketBai que no consigo rematar.
Tu código me puede ser útil, pero me falta el punto más importante para mí código:

¿Cuál es la implementación para tu función "GetCrc8"?

Estoy creando links de QR con Batuz, Bizkaia, y me falla siempre el código CRC. He probado varias funciones. El algoritmo de la documentación está en java. He hecho "mi versión" del mismo, pero los códigos CRC siguen siendo incorrectos.
Un saludo

No viene directamente a mí la pregunta pero yo también lo tengo hecho en C#, así que tal vez te pueda echar una mano aunque a mi función no la he llamado "GetCrc8".
Te paso la clase completa:

Código Delphi [-]
    public class CRC8Calc
    {
        private const string UTF_8 = "UTF-8";
        private static byte[] crc8_table = new byte[] { (byte) 0x00, (byte) 0x07, (byte) 0x0E, (byte) 0x09, (byte) 0x1C, (byte) 0x1B, (byte) 0x12, (byte) 0x15,
(byte) 0x38, (byte) 0x3F, (byte) 0x36, (byte) 0x31, (byte) 0x24, (byte) 0x23, (byte) 0x2A, (byte) 0x2D,
(byte) 0x70, (byte) 0x77, (byte) 0x7E, (byte) 0x79, (byte) 0x6C, (byte) 0x6B, (byte) 0x62, (byte) 0x65,
(byte) 0x48, (byte) 0x4F, (byte) 0x46, (byte) 0x41, (byte) 0x54, (byte) 0x53, (byte) 0x5A, (byte) 0x5D,
(byte) 0xE0, (byte) 0xE7, (byte) 0xEE, (byte) 0xE9, (byte) 0xFC, (byte) 0xFB, (byte) 0xF2, (byte) 0xF5,
(byte) 0xD8, (byte) 0xDF, (byte) 0xD6, (byte) 0xD1, (byte) 0xC4, (byte) 0xC3, (byte) 0xCA, (byte) 0xCD,
(byte) 0x90, (byte) 0x97, (byte) 0x9E, (byte) 0x99, (byte) 0x8C, (byte) 0x8B, (byte) 0x82, (byte) 0x85,
(byte) 0xA8, (byte) 0xAF, (byte) 0xA6, (byte) 0xA1, (byte) 0xB4, (byte) 0xB3, (byte) 0xBA, (byte) 0xBD,
(byte) 0xC7, (byte) 0xC0, (byte) 0xC9, (byte) 0xCE, (byte) 0xDB, (byte) 0xDC, (byte) 0xD5, (byte) 0xD2,
(byte) 0xFF, (byte) 0xF8, (byte) 0xF1, (byte) 0xF6, (byte) 0xE3, (byte) 0xE4, (byte) 0xED, (byte) 0xEA,
(byte) 0xB7, (byte) 0xB0, (byte) 0xB9, (byte) 0xBE, (byte) 0xAB, (byte) 0xAC, (byte) 0xA5, (byte) 0xA2,
(byte) 0x8F, (byte) 0x88, (byte) 0x81, (byte) 0x86, (byte) 0x93, (byte) 0x94, (byte) 0x9D, (byte) 0x9A,
(byte) 0x27, (byte) 0x20, (byte) 0x29, (byte) 0x2E, (byte) 0x3B, (byte) 0x3C, (byte) 0x35, (byte) 0x32,
(byte) 0x1F, (byte) 0x18, (byte) 0x11, (byte) 0x16, (byte) 0x03, (byte) 0x04, (byte) 0x0D, (byte) 0x0A,
(byte) 0x57, (byte) 0x50, (byte) 0x59, (byte) 0x5E, (byte) 0x4B, (byte) 0x4C, (byte) 0x45, (byte) 0x42,
(byte) 0x6F, (byte) 0x68, (byte) 0x61, (byte) 0x66, (byte) 0x73, (byte) 0x74, (byte) 0x7D, (byte) 0x7A,
(byte) 0x89, (byte) 0x8E, (byte) 0x87, (byte) 0x80, (byte) 0x95, (byte) 0x92, (byte) 0x9B, (byte) 0x9C,
(byte) 0xB1, (byte) 0xB6, (byte) 0xBF, (byte) 0xB8, (byte) 0xAD, (byte) 0xAA, (byte) 0xA3, (byte) 0xA4,
(byte) 0xF9, (byte) 0xFE, (byte) 0xF7, (byte) 0xF0, (byte) 0xE5, (byte) 0xE2, (byte) 0xEB, (byte) 0xEC,
(byte) 0xC1, (byte) 0xC6, (byte) 0xCF, (byte) 0xC8, (byte) 0xDD, (byte) 0xDA, (byte) 0xD3, (byte) 0xD4,
(byte) 0x69, (byte) 0x6E, (byte) 0x67, (byte) 0x60, (byte) 0x75, (byte) 0x72, (byte) 0x7B, (byte) 0x7C,
(byte) 0x51, (byte) 0x56, (byte) 0x5F, (byte) 0x58, (byte) 0x4D, (byte) 0x4A, (byte) 0x43, (byte) 0x44,
(byte) 0x19, (byte) 0x1E, (byte) 0x17, (byte) 0x10, (byte) 0x05, (byte) 0x02, (byte) 0x0B, (byte) 0x0C,
(byte) 0x21, (byte) 0x26, (byte) 0x2F, (byte) 0x28, (byte) 0x3D, (byte) 0x3A, (byte) 0x33, (byte) 0x34,
(byte) 0x4E, (byte) 0x49, (byte) 0x40, (byte) 0x47, (byte) 0x52, (byte) 0x55, (byte) 0x5C, (byte) 0x5B,
(byte) 0x76, (byte) 0x71, (byte) 0x78, (byte) 0x7F, (byte) 0x6A, (byte) 0x6D, (byte) 0x64, (byte) 0x63,
(byte) 0x3E, (byte) 0x39, (byte) 0x30, (byte) 0x37, (byte) 0x22, (byte) 0x25, (byte) 0x2C, (byte) 0x2B,
(byte) 0x06, (byte) 0x01, (byte) 0x08, (byte) 0x0F, (byte) 0x1A, (byte) 0x1D, (byte) 0x14, (byte) 0x13,
(byte) 0xAE, (byte) 0xA9, (byte) 0xA0, (byte) 0xA7, (byte) 0xB2, (byte) 0xB5, (byte) 0xBC, (byte) 0xBB,
(byte) 0x96, (byte) 0x91, (byte) 0x98, (byte) 0x9F, (byte) 0x8A, (byte) 0x8D, (byte) 0x84, (byte) 0x83,
(byte) 0xDE, (byte) 0xD9, (byte) 0xD0, (byte) 0xD7, (byte) 0xC2, (byte) 0xC5, (byte) 0xCC, (byte) 0xCB,
(byte) 0xE6, (byte) 0xE1, (byte) 0xE8, (byte) 0xEF, (byte) 0xFA, (byte) 0xFD, (byte) 0xF4, (byte) 0xF3 };
        public static String Calculate(string input)
        {
            byte[] data = Encoding.ASCII.GetBytes(input);
            int len = data.Length;
            int crc = 0;
            for (int i = 0; i < len; i++)
            {
                crc = CRC8Calc.crc8_table[(crc ^ data[i]) & 0xff];
            }
            return String.Format("{0:000}", crc & 0xFFL);
        }
    }

Gracias!
 

Pruebo con tu código.
¡Muchas gracias!

Al inicio de este hilo, en el mensaje 2, hay links a implementaciones de código de diferentes temas, entre ellos varias implementaciones del CRC8.

validar xml con xsd
 

Hola!
He estado revisando en el hilo si alguien validaba los xml generados contra los xsd y no veo que nadie lo haga. No es buena práctica? me estoy planteando validarlos antes de enviarlos para minimizar los errores.
Gracias!

Hola,

Yo utilizo PHP y valido en XML creado contra el XSD
Eso sí, la función DOMDocument::schemaValidate de PHP no permite que la URL del schemaLocation sea externa.
Así que tuve que cambiar la línea de import del XSD a:
y guardar el fichero xmldsig-core-schema.xsd en el mismo directorio.

Pero funciona perfecto y valida frente al XSD.

Saludos

Así es como lo tengo yo:

Hola,

Hemos recibido email, de TicketBAI de Gipuzkoa, de aviso de cambios de la estructura de los XML a partir del 1 de enero de 2024.
Se acompaña de los nuevos XSD.

No puedo subir el documento porque el foro no me permite ese tamaño de fichero.
Si el administrador puede subirlo, se agradece.

Saludos

Yo e recibido el mail.
Creo que las modificaciones de las que habla, son la que ya han comentado las otras administraciones.
De todas formas, pone que en "breve se publicarán" los esquemas. Yo los descargué ayer y siguen estando en la web los de la v.1.2.1 .

Si disponéis de los nuevos de la versión 1.2.2, dímelo y me los envías por privado y los subo a la web.

Me corrijo yo mismo. En la web de Guipuzcoa y de Álava está la v.1.2.1, pero en la de Vizcaya ya está la v.1.2.2 (alta / anulación)

Los subo al FTP y modifico el mensaje #1 del hilo.

Hola,

Os paso los nuevos XSD de la versión 1.2.2 enviados por Gipuzkoa.

Saludos

Gracias. ^\||/
Los subo por separado y actualizo el primer mensaje, porque los de TicketBAI deberían ser iguales para las 3 administraciones, OSATU y ZUZENDU sólo para Guipuzcoa.

Muchas gracias a todos. También recibí el correo y después de revisarlo, creo que en nuestro caso no nos afecta.
Los nuevos campos no los utilizamos y los que pasan a ser obligatorios ya los rellenamos.
Según comentan los actuales esquemas seguirán siendo válidos, por lo que de momento no haremos ningún cambio.
Espero no arrepentirme:p

Buenas...

Desde ayer nuestros clientes no pueden hacer envíos de TicketBAI (Gipuzkoa). Obtienen el siguiente error al hacer el envío:

Server Certificate invalid or nor present

¿Se trata de un error general de Gipuzkoa o es que ha cambiado algo casualmente ayer? ¿Le pasa a alguien más?

Yo creo que es un problema de hacienda. A nuestros clientes también les estas pasando. En el entorno de pruebas también me ha dado el mismo error pero parece que ya funciona.

El certificado del servidor de la Hacienda de Gipuzkoa se habia caducado:

Common Name (CN)
*.egoitza.gipuzkoa.eus
Organization (O)
INFORMATIKA ZERBITZUEN FORU ELKARTEA - SOCIEDAD FORAL DE SERVICI
Organizational Unit (OU)
<Not Part Of Certificate>
Issued By
Common Name (CN)
EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
Organization (O)
IZENPE S.A.
Organizational Unit (OU)
AZZ Ziurtagiri publikoa - Certificado publico SCA
Validity Period
Issued On
Thursday, November 10, 2022 at 2:10:24 PM
Expires On
Sunday, December 10, 2023 at 2:10:24 PM

Me confirmaron por email los técnicos de gipuzkoa.

Menos mal que están preparados :cool:

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

He visto que la estructura es casi exactamente igual que la del envío de una Factura, y por lo que he leído, es para "subsanar" envíos que hayan sido rechazados previamente; y que el envío se hace a una URL distinta a la de Alta de Facturas, etc.
En el diagrama que hay en la web de Gipuzkoa indica que cuando el envío de una factura devuelva "avisos de errores" y el error tiene "reflejo en la factura" (vete tu a saber qué quieren decir con eso), hay que subsanarla con un "zuzendu modificar". Pero...
¿A qué errores se refieren exactamente? ¿Por qué no me ha hecho falta hasta ahora hacer un envío de zuzendu, con cientos de clientes enviando facturas desde hace más de un año? ¿Para qué casos concretos habría que hacer esto?

Extraído de la documentación:

Cuando el fichero de alta TicketBAI o el fichero de subsanación del fichero de
alta TicketBAI sea recibido con aviso de errores que no exijan la emisión de una
factura rectificativa, pero sean consecuencia de no superar las validaciones de
consolidación del resto de datos que deban informarse en el fichero, se deberá
generar un fichero de modificación que será enviado a través del servicio
zuzendu.
Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

Y espérate, que después de leer que hay diferencias entre "modificar" y "subsanar" y, por si fuera poco confuso:
- Ficheros de subsanación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de subsanación de los ficheros de alta TicketBAI

No sé si es que estoy realmente cansado de todo este tema, pero la verdad es que ahora mismo no se me ocurre un caso concreto en el que sea necesario enviar una modificación/zuzendu, y mucho menos, una "baja de zuzendu".
Lo que está claro es que dejar que el propio usuario final pueda enviar zuzendus cuando le de la gana, no es buena idea.

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

Buenos días, ¿alguien está teniendo hoy problemas en Guipúzcoa? Parece que nos está tardando en transmitir los tickets (unos sí y otros no)

Hola,

Sí. Parece que está caído.

Saludos

Si, está dando timeouts

Si, justo me ha comentado un cliente que le estaba dando error en el envio

Hola,

Realmente es una lástima como funcionan los sistemas informáticos de las Haciendas Forales que atienden a los servicios TicketBAI.
Cuando no es por una cosa es por otra.

- Ahora que si no funcionan los envíos a Gipuzkoa.
- Ayer que si tenían caducado (y sin darse cuenta) su certificado.
- Otros días que si el sistema que emplean de verificación de certificados (el desastroso Izenpe) no verifica bien.
...

No entiendo que a nosotros se nos exijan sistemas estables, fiables y seguros y las Administraciones se tomen a chufla el estado de sus servicios.
¡¡¡ Un poco de seriedad, por favor !!!

(Es sólo por desahogarme)

Saludos

Ya verás qué divertido va a ser cuando implanten VeriFactu a nivel nacional ;)

Si, ese es el protocolo, pero lo que no entiendo es en qué casos concretamente se debe hacer una "subsanación".
Si no entra un Alta normal, no basta con volver a intentarlo? Hacienda aún no tiene la factura, no? Otra cosa es que se haya enviado PERO con avisos/errores y Hacienda se la haya tragado (que debería ser problema de ellos por habérsela comido, pero bueno).

Es decir, si se envía una factura, pero con error/aviso, ahí entiendo que sí haya que hacer una "subsanación", después de haber corregido la causa del error. Imagino que dependerá de qué tipo de error sea exactamente.

Luego está lo de "modificar una factura". Lo siento, pero sigo sin entender la diferencia. En ambos casos (subsanar y modificar) lo que tenemos que hacer es modificar algo en la factura. ¿En qué casos concretos se requiere subsanación y en qué casos modificación?

Subsanación si Hacienda se traga una factura incorrecta y modificación si nosotros voluntariamente queremos reenviarla? ¿Para esto último no sería más correcto una rectificativa? Al menos eso es lo que nos ha reiterado Hacienda últimamente: "Modificar mal. Rectificativa bien"...

Y siguiendo con las exigencias de tener que hacer rectificativas... ¿por qué entonces se permiten las "bajas"?

Hola,

Para aclarar cuando hacer una rectificativa, un Zuzendu de modificación o un Zuzendu de subsanación, viene muy bien este gráfico que anexo.

Saludos

Hola,

Hay veces que no tiene mucho sentido hacer rectificativas sino anular la factura y hacerla de nuevo.
Ejemplos:

- Vendes un pantalón y en el momento de entregar la factura al cliente, te das cuenta de que has puesto jersey.
Anulas la factura, la rompes antes de entregarla al cliente y vuelves a hacerla bien.

- Haces una factura de 100€ y a continuación te das cuenta de que se te había quedado trabada la tecla del cero y te aparece 1.000.000€ como importe.
Anulas la factura, desencajas la tecla bloqueada y vuelves a hacer la factura.

- Después de hacer una factura te das cuenta de que has puesto como destinatario a un ex-cliente de hace muchos años (con el que quedaste a mal).
Ni se te ocurriría enviarle la factura emitida y una rectificativa.
Anulas la factura y eliges bien el destinatario al hacer la nueva.

- Estás cobrándole a un cliente en la tienda y, en el último momento, cuando vas a darle la factura, el cliente te dice que se arrepiente y no quiere el producto.
Anulación al canto.

Hay infinidad de casos en los que no es lógico hacer una rectificativa sino una anulación.

Saludos

Entiendo los casos, y de hecho sería lo lógico. Pero... ¿no se supone que esto implicaría ir en contra de lo que precisamente Hacienda no quiere que hagamos?

Cómo demuestra el empresario que esa factura realmente no se llegó a entregar al cliente final? ¿No estaríamos permitiendo defraudar/esconder esa factura?

Al anular/baja una factura... ¿su número queda libre de nuevo para hacer otra factura usando ese mismo número?

Creo que es lógico que Hacienda permita anular facturas que no deberían haberse emitido.
Otra cosa es si después Hacienda ve que hay muchas facturas sospechosas de ese tipo y le da por hacer una inspección.

Es que puede incluso anularse después de habérsele entregado al cliente.
Por supuesto, en ese caso, debe informar al cliente que se ha anulado esa factura por tal motivo.

Hacienda puede pedir explicaciones del por qué de una anulación.
Pero si hay una razón suficiente, no debe haber ningún problema.

No. El número no se recupera.
Y si se comprueba con el código QR, se verá que está anulada.

Saludos

Encadenamiento
 

Buenos días,


Una pregunta os quiero hacer sobre el tema del encadenamiento de facturas


Si en un paquete de 40 facturas hay una rechazada por datos mal grabados, nif incorrecto etc...


Qué hacéis?


Parar el resto del envío hasta que se corrija la incidencia o enviar el resto y provocar un error de encadenamiento cuando la factura rechazada ya esté correcta y pueda subir


Gracias de antemano

Hablando del verifactu, sabéis si en bizkaia, gipuzkoa o alava el verifactu es obligatorio? porque entiendo que con ticketbai ya estas cumpliendo no? porque he estado mirando y el verifactu es otra cosa como ticketbai o parecido...
¿Sabéis algo?

Verifactu no se aplica en el PV

Hola a todos.

Como todos sabréis a partir del 1 de enero ha entrado una nueva versión de TicketBAI. Pues tenemos un cliente que esta dentro de unos de esos cambios, en concreto con una de las nuevas causas de no sujeción. Al intentar enviar la primera factura del año de este tipo hacienda de Gipuzkoa nos devuelve un error de que no se cumple el XSD.

Hablamos con hacienda y nos responden lo siguiente. Solo era por desahogarme. :cool:

Resumiendo y sin entrar en mucho detalle:
- BAJA es un servicio independiente igual que ALTA, pero anula la factura, y no se debe usar alegremente, es solo para casos concretos (facturas rechazadas por el cliente, servicios que no se han llegado a prestar...).
- La solicitud de baja puede fallar, y hay un servicio exclusivo de ZUZENDU-BAJA, donde reenvías la solicitud, corregida.
- ZUZENDU se usa para corregir facturas, pero tiene las variantes SUBSANAR y MODIFICAR.

Después comento esto un poco más.

Cuidado con ZUZENDU. Te cito lo que me dijeron desde Hacienda a raíz de unas incidencias:

Pero incluso esto tiene sus matices, porque una factura aunque haya sido aceptada con avisos, puede requerir una NUEVA factura rectificativa, sin ZUZENDU que valga.

Dicho esto, yo en su día tenía montado un sistema donde dependiendo del tipo de error, enviaba a ZUZENDU, o bien generaba una nueva factura rectificativa.

Iba bien hasta que un día empezó el primer problema con una factura que se intentaba corregir pero no se podía.

Después de hablar con Hacienda por teléfono, un técnico me dijo que una forma de ir a lo seguro es: si una factura se acepta con errores, se envía una nueva sustitutiva y listo. Con esto te evitas toda la problemática de si los datos que estás modificando son "visibles" o no, etc.

En mi caso el software que desarrollé es para uso de la empresa donde trabajo, así que el funcionamiento que decidamos solo nos afecta a nosotros.

Lógicamente dependiendo de lo que tengas montado, si es para revender terceros, etc. quizás sea matar moscas a cañonazos y saltarte ZUZENDU-MODIFICAR pueda dar problemas a la larga.

En resumen, yo lo que hago eso:
- Rechazada?: Zuzendu-Subsanar.
- Aceptada con errores?: Nueva factura sustitutiva.
- Queremos editar una factura (importes, líneas..)?: Nueva factura sustitutiva.

Un saludo.

Impresionante, no dejan de sorprender ..., al Ticketbai y más allá.

Buenos días y feliz año a tod@s

Off topic: aplicación de contabilidad País Vasco
 

Hola a todos,

Sé que este mensaje no tiene relación con TicketBAI, pero entiendo que todos somos desarrolladores de diferentes aplicaciones que contemplan el Régimen Foral del País Vasco, y mi propuesta puede ser de interés.

Debido a una próxima reestructuración en mi empresa estamos planteando dejar de dar soporte de nuestra aplicación de Contabilidad-Fiscal, y quisiera saber si alguno de vosotros desarrolláis una aplicación de contabilidad que soporte la Hacienda de Gipuzkoa (imprescindible) y del resto del País Vasco (muy deseable). Si además soporta la Hacienda Estatal e incluso la Navarra, tanto mejor.

Esta aplicación debería contemplar lo siguiente:
- Retenciones: 110, 216, 190, 296
- Arrendamientos: 115 y 180.
- Iva: 300/330; 390
- Pago fraccionado: 130
- Legalización de libros
- Trasvase cuentas contables para el impuesto de sociedades.

Nos consta que la aplicación DiamaCon de Comeralia cubriría nuestras necesidades, pero queremos conocer más alternativas.
La idea es analizar las aplicaciones sugeridas y la que consideremos más apropiada recomendarla a nuestros clientes para su progresiva implantación.

Por favor, las sugerencias enviadlas a [email protected] para no cargar este foro.
Gracias a todos.