TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[unomasmas]

Empezado por Irreo

Creo que tienes algunos conceptos algo erróneos.

Una cosa es CORREGIR una factura que ha sido rechazada, y otra RECTIFICAR una factura.

En el primer caso, estás reenviando una factura ya enviada previamente, pero con datos correctos (bien sean del XML, o datos de la factura, que ocasionaron un rechazo).

En el segundo caso, estás emitiendo una NUEVA factura, rectificando una factura previa, bien porque ha habido una devolución, se cambian datos del cliente, se corrigen importes erróneos, hacienda la ha aceptado pero ha dado algún aviso, etc...

Dicho esto, sigo sin entender por qué insistes en lo de sustitutiva con el mismo número y serie.

Si es sustitutiva, es una factura rectificativa, y por lo tanto lleva su serie y su número.

Es decir, no tienes que anular nada.... si lo que quieres es sustituir esa factura, simplemente emite una nueva factura, rectificativa por sustitución, haciendo referencia a ella.

Umm, creo que no nos entendemos. Esta es la situación.

1.- Factura creada, imprimida y enviada a la Diputación sin problemas.

2.- Después se detecta un error. Se hace rectificativa de esa primera factura, pero la rectificativa se hace mal (se asigna la misma serie y el mismo número y la misma fecha). Se genera el fichero XML de esta factura rectificativa y se intenta enviar a la Diputación pero, obivamente, la Diputación la rechaza porque dice que esa factura ya la tiene.

En este punto hay una factura emitida (la segunda, que es la rectificativa) pero que no puedo corregir (porque ya se ha emitido el fichero TicketBAI) y que tampoco puedo enviar a la Diputación (porque no la acepta). Se me ocurre como única solución eliminarla/anularla y crear una nueva rectificativa bien hecha. Me gustaría confirmar con vosotros si este proceder es correcto o, de lo contrario ¿Cómo me deshago de la factura rectificativa mal creada en el paso 2?

[Irreo]

Empezado por unomasmas

Umm, creo que no nos entendemos. Esta es la situación.

1.- Factura creada, imprimida y enviada a la Diputación sin problemas.

2.- Después se detecta un error. Se hace rectificativa de esa primera factura, pero la rectificativa se hace mal (se asigna la misma serie y el mismo número y la misma fecha). Se genera el fichero XML de esta factura rectificativa y se intenta enviar a la Diputación pero, obivamente, la Diputación la rechaza porque dice que esa factura ya la tiene.

En este punto hay una factura emitida (la segunda, que es la rectificativa) pero que no puedo corregir (porque ya se ha emitido el fichero TicketBAI) y que tampoco puedo enviar a la Diputación (porque no la acepta). Se me ocurre como única solución eliminarla/anularla y crear una nueva rectificativa bien hecha. Me gustaría confirmar con vosotros si este proceder es correcto o, de lo contrario ¿Cómo me deshago de la factura rectificativa mal creada en el paso 2?

Vale, ahora SÍ te he entendido, perdona por el lío

Por un lado, yo diría que Hacienda no ha registrado ninguna factura nueva.

Al haberle enviado una factura con un emisor + serie + número ya existente, te devuelve el error "005" y listo.

Es decir, la anulación procedería si hay una factura que exista (por ejemplo un intento de rectificación con su número y serie, pero que finalmente no procede y quieres anular)

En tu caso, entiendo que no habrá sido así, me extraña que hayan creado OTRA factura nueva (por mucho que hayas enviado de tipo rectificativa) con el mismo número y serie, para el mismo emisor.

Entra a la sede electrónica por confirmarlo.

[unomasmas]

Empezado por HerensugeBeltz

Entiendo que la factura rectificativa que enviaste con mismo nº de factura ha tenido que ser rechazada, porque esa factura ya estaba comunicada. Es decir, a Hacienda no le consta este último envío. Tienes que proceder como te han comentado los compañeros, con una nueva factura rectificativa (y revisar tu sistema para que no te deje crear una factura con una serie y número ya existente ).

Empezado por Irreo

Vale, ahora SÍ te he entendido, perdona por el lío
Por un lado, yo diría que Hacienda no ha registrado ninguna factura nueva.
Al haberle enviado una factura con un emisor + serie + número ya existente, te devuelve el error "005" y listo.
Es decir, la anulación procedería si hay una factura que exista (por ejemplo un intento de rectificación con su número y serie, pero que finalmente no procede y quieres anular)
En tu caso, entiendo que no habrá sido así, me extraña que hayan creado OTRA factura nueva (por mucho que hayas enviado de tipo rectificativa) con el mismo número y serie, para el mismo emisor.
Entra a la sede electrónica por confirmarlo.

Gracias a ambos. Sí, el proceder es el comentado. Confirmo que también me lo han dicho así en la Diputación. Lo de la revisión del sistema para bloquear la posibilidad de cambio de serie ya estaba haciéndose mientras preguntaba esto, claro . Muchas gracias

[Sanduzelai]

Buenas,
tengo un error en algunas facturas enviadas y me dicen que para solucionarlo debo hacer una rectificativa por sustitución y tengo varias dudas:

1. ¿Esta factura rectificativa habría que mandarla a la URL de alta?

2. ¿El bloque de encadenamiento de la factura con errores habría que actualizarlo para que la rectificativa "apunte" a la última enviada o simplemente tendría que cambiar los datos incorrectos y añadir el nodo <FacturaRectificativa>? Esto lo pregunto porque me he dado cuenta del error yo pero las facturas han sido recibidas sin errores y por lo tanto, después de estas, se han enviado otras correctas.

3. En el nodo <FacturaRectificativa> no tengo muy claro que son exactamente los valores que hay que poner en <BaseRectificada> y <CuotaRectificada>. Por ejemplo, si el caso es que he vendido una coca-cola de 2€ ¿qué valores se supone que deberían tener BaseRectificada y CuotaRectificada?


Muchas gracias de antemano, estoy un poco perdido con las rectificativas...

[Irreo]

Empezado por Sanduzelai

Buenas,
tengo un error en algunas facturas enviadas y me dicen que para solucionarlo debo hacer una rectificativa por sustitución y tengo varias dudas:

1. ¿Esta factura rectificativa habría que mandarla a la URL de alta?

2. ¿El bloque de encadenamiento de la factura con errores habría que actualizarlo para que la rectificativa "apunte" a la última enviada o simplemente tendría que cambiar los datos incorrectos y añadir el nodo <FacturaRectificativa>? Esto lo pregunto porque me he dado cuenta del error yo pero las facturas han sido recibidas sin errores y por lo tanto, después de estas, se han enviado otras correctas.

3. En el nodo <FacturaRectificativa> no tengo muy claro que son exactamente los valores que hay que poner en <BaseRectificada> y <CuotaRectificada>. Por ejemplo, si el caso es que he vendido una coca-cola de 2€ ¿qué valores se supone que deberían tener BaseRectificada y CuotaRectificada?

Muchas gracias de antemano, estoy un poco perdido con las rectificativas...

1. Las facturas rectificativas son facturas nuevas, por lo tanto, sí, se mandan al servicio ALTA.

2. El encadenamiento debe apuntar siempre a la última factura emitida por ese dispositivo y emisor, independientemente de la serie, de si ha habido errores, etc.
Si lo tienes automático (como debería ser, entiendo) no tienes que actualizar nada... de hecho incluso facturas que den error, sean rechazadas, etc. se tienen en cuenta para el encadenamiento.

3. Cuando la factura es por sustitución, en Base y Cuota rectificadas estás indicando el importe que estás "anulando". En tu caso, si los 2€ son el total de la factura, en la base serían los 2€ sin el IVA, y en la cuota sería el IVA, que entre los dos sumarían 2€.
Con esto, le estás diciendo a Hacienda que 2€ de esa factura sustituida dejan de computar, y la nueva factura emitida quedaría como debería haber sido la anterior, computando todo lo que indiques.

Luego ya las facturas rectificativas por diferencias son otro asunto...

[Sanduzelai]

Empezado por Irreo

1. Las facturas rectificativas son facturas nuevas, por lo tanto, sí, se mandan al servicio ALTA.

2. El encadenamiento debe apuntar siempre a la última factura emitida por ese dispositivo y emisor, independientemente de la serie, de si ha habido errores, etc.
Si lo tienes automático (como debería ser, entiendo) no tienes que actualizar nada... de hecho incluso facturas que den error, sean rechazadas, etc. se tienen en cuenta para el encadenamiento.

3. Cuando la factura es por sustitución, en Base y Cuota rectificadas estás indicando el importe que estás "anulando". En tu caso, si los 2€ son el total de la factura, en la base serían los 2€ sin el IVA, y en la cuota sería el IVA, que entre los dos sumarían 2€.
Con esto, le estás diciendo a Hacienda que 2€ de esa factura sustituida dejan de computar, y la nueva factura emitida quedaría como debería haber sido la anterior, computando todo lo que indiques.

Luego ya las facturas rectificativas por diferencias son otro asunto...

Muchas gracias por la ayuda!

[Maska10]

Buenos días a todos

Seguimos sin poder finalizar el proceso de envío con Vizcaya, ahora tenemos el siguiente problema .. cuando firmamos el filchero Ticket Bai, si NO incluimos los siguiente parámetros en la firma:

\npolicyIdentifier=EL ENLACE A POLICYIDENTIFIER
\npolicyIdentifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=
\npolicyIdentifierHashAlgorithm=EL ENLACE A HASHALGORITHM
\npolicyQualifier=EL ENLACE A POLICYQUALIFIER

El resultado es que a la hora del envío el servidor de Batuz nos devuelve un error de validación de certificado (lógico al no incluir los parámetros), pero si los incluimos nos devuelve un error de decodificación de base64 .. el caso es que cuando decodificamos el Ticket Bai lo hacemos sin problema.

Saludos.

[AlbertPujol]

Hola,

Os comento por si a alguien más le han aparecido una serie de errores desde el 3 de noviembre en algunas facturas enviadas a TBAI Gipuzkoa:

(5016) La suma de los importes indicados en el desglose Sujeto y NoExento no coincide con lo recogido en las lí¬neas de detalle. Esta validación no se aplicará cuando alguna clave de régimen sea 03, 05, 06 o 09 o cuando TipoRectificativa sea I o tipo de...
(5017) Los importes indicados en los desgloses NoSujeto o Exento no coinciden con lo recogido en las líneas de detalle. Esta validación no se aplicará cuando alguna clave de régimen sea 03, 05, 06 o 09
(5018) El IVA calculado de alguna de las lí¬neas no es un tipo aceptado. Asegúrese de haber informado del ImporteUnitario sin IVA, el ImporteTotal de la línea con IVA y de indicar siempre en euros el Descuento aplicado. Esta validación no se aplicará...

Nos hemos puesto en contacto con la diputación y nos han contestado lo siguiente:

Buenos días,

Hemos tenido una incidencia a la hora de validar facturas con conceptos no sujetas o exentas, es por eso que han recibido esos errores, en realidad no deberían recibir esos errores.

Disculpamos las molestias

Saludos

Así que parece que han tenido algunos problemas con las validaciones desde el día 3 de noviembre.

[Zósimo]

Sé que he preguntado antes torpemente y sin investigar, pese a todo quisiera que alguien me dijera ¿con qué hay que certificar los envíos del XML ya firmado por XADES?

Me explico .

Tengo un c12 expedido por Izenpe hace unos meses. Si llamo al archivo del certificado no parece reconocerlo:

Código PHP:

curl_setopt($ch, CURLOPT_URL, $server);
curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
curl_setopt($ch, CURLOPT_POSTFIELDS, $texto);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_SSLCERTTYPE, "PFX");
curl_setopt($ch, CURLOPT_CAPATH, $camino);
curl_setopt($ch, CURLOPT_CAINFO, $file);
curl_setopt($ch, CURLOPT_SSLCERTPASSWD, $pass);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 


Tampoco me ha funcionado si en lugar de llamar al certificado lo abro, extraigo solo el certificado como tal y lo envío como una variable, tampoco si lo limpio de cabeceras, retornos de carro y demás. Siempre me devuelve el error 01 de que el certificado no es válido o está caducado.
Lo he convertido a PEM como dicen en varios sitios, pero así lo que se mete en el nuevo archivo que yo he llamado cert.pem es la clave privada, sin embargo, otros dicen que eso les funciona. Yo lo envío con este otro código:

Código PHP:

curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSLCERTTYPE, "PEM");
curl_setopt($ch, CURLOPT_SSLCERT,$camino.'cert.pem');
//curl_setopt($ch, CURLOPT_SSLKEY, $certs['pkey']);
curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $pass);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_ 


Al parecer es el indicado para el formato pem según dice la documentación oficial de PHP. Aquí no responde nada el servidor de la Diputación, absolutamente nada.

Por puesto he preguntado a la diputación y no parecen saber nada.

¿Qué estoy haciendo mal? ¿Qué no he entendido? ¿debo limpiar el archivo pem que he creado de código como "-----BEGIN PRIVATE KEY-----" o "Bag Attributes"? ¿no lo debo hacer en mi ordenador sino directamente en el servidor por aquello del "localKeyID"?

[Irreo]

Empezado por Zósimo

Sé que he preguntado antes torpemente y sin investigar, pese a todo quisiera que alguien me dijera ¿con qué hay que certificar los envíos del XML ya firmado por XADES?

¿Qué estoy haciendo mal? ¿Qué no he entendido? ¿debo limpiar el archivo pem que he creado de código como "-----BEGIN PRIVATE KEY-----" o "Bag Attributes"? ¿no lo debo hacer en mi ordenador sino directamente en el servidor por aquello del "localKeyID"?

Te remito a una respuesta que publiqué hace poco con el código que utilizo yo, por si te sirve:

https://www.clubdelphi.com/foros/sho...postcount=3540

[Zósimo]

Por cierto. No te he dado las gracias por el detalle de responder. Voy a probarlo

[Sanduzelai]

Empezado por Zósimo

Sé que he preguntado antes torpemente y sin investigar, pese a todo quisiera que alguien me dijera ¿con qué hay que certificar los envíos del XML ya firmado por XADES?

Me explico .

Tengo un c12 expedido por Izenpe hace unos meses. Si llamo al archivo del certificado no parece reconocerlo:

Código PHP:

curl_setopt($ch, CURLOPT_URL, $server);
curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
curl_setopt($ch, CURLOPT_POSTFIELDS, $texto);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_SSLCERTTYPE, "PFX");
curl_setopt($ch, CURLOPT_CAPATH, $camino);
curl_setopt($ch, CURLOPT_CAINFO, $file);
curl_setopt($ch, CURLOPT_SSLCERTPASSWD, $pass);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 


Tampoco me ha funcionado si en lugar de llamar al certificado lo abro, extraigo solo el certificado como tal y lo envío como una variable, tampoco si lo limpio de cabeceras, retornos de carro y demás. Siempre me devuelve el error 01 de que el certificado no es válido o está caducado.
Lo he convertido a PEM como dicen en varios sitios, pero así lo que se mete en el nuevo archivo que yo he llamado cert.pem es la clave privada, sin embargo, otros dicen que eso les funciona. Yo lo envío con este otro código:

Código PHP:

curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSLCERTTYPE, "PEM");
curl_setopt($ch, CURLOPT_SSLCERT,$camino.'cert.pem');
//curl_setopt($ch, CURLOPT_SSLKEY, $certs['pkey']);
curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $pass);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_ 


Al parecer es el indicado para el formato pem según dice la documentación oficial de PHP. Aquí no responde nada el servidor de la Diputación, absolutamente nada.

Por puesto he preguntado a la diputación y no parecen saber nada.

¿Qué estoy haciendo mal? ¿Qué no he entendido? ¿debo limpiar el archivo pem que he creado de código como "-----BEGIN PRIVATE KEY-----" o "Bag Attributes"? ¿no lo debo hacer en mi ordenador sino directamente en el servidor por aquello del "localKeyID"?

Yo tuve un problema hace poco con mi certificado porque se revocó el que estaba usando y tuve que poner otro nuevo. Te pongo lo que hice porque también me daba error 01 las primeras veces por culpa del .pem que generaba.

Yo tengo esto:

Código PHP:

        $soap_do = curl_init();
        curl_setopt($soap_do, CURLOPT_URL, $url);
        curl_setopt($soap_do, CURLOPT_CONNECTTIMEOUT, 100);
        curl_setopt($soap_do, CURLOPT_TIMEOUT,        100);
        curl_setopt($soap_do, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($soap_do, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($soap_do, CURLOPT_SSL_VERIFYPEER, false);
        curl_setopt($soap_do, CURLOPT_SSL_VERIFYHOST, false);
        curl_setopt($soap_do, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)');
        curl_setopt($soap_do, CURLOPT_POST,           true );
        curl_setopt($soap_do, CURLOPT_SSLCERT,        $pem);
        curl_setopt($soap_do, CURLOPT_POSTFIELDS,     $xml);
        curl_setopt($soap_do, CURLOPT_HTTPHEADER,     $header_soap);

        $xmlResponse = curl_exec($soap_do); 


donde $pem es mi path a a mi certificado.pem
Este lo he creado asi:

Código PHP:

openssl pkcs12 -in path.p12 -out newfile.crt.pem -clcerts -nokeys
openssl pkcs12 -in path.p12 -out newfile.key.pem -nocerts -nodes    
openssl pkcs12 -in path.p12 -out newfile.pem -nodes 


El newfile.pem final es el que he usado y ahora me manda bien las facturas.