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

[keys]

Empezado por MaeseKvothe

Tengo una pequeña duda sobre los plazos y la obligatoriedad de Batuz. En mi caso hablo de Bizkaia para el modelo 240.

¿Las fechas de obligatoriedad afectan sólo al capitulo de facturas emitidas o también a la parte de compras, gastos, etc.?

Los plazos son para todo. Si entras en Batuz entras en todo no solo en TicketBAI.

[skatologiko]

Buenas , en Guipúzcoa tenemos el siguiente problema con la codificacióndesde el principio , nos estamos volviendo locos y no encontramos la solución. A ver si alguien puede arrojarme luz
Nuestro programa está hecho en visual basic y utilizamos las librerías chilkat para transmitir, así como un certificado de la FNMT de representación de mi cliente

El código con el que enviamos cada ticket o factura es el siguiente. Como se ve, estamos transmitiendo con codificación utf-8.

Dim Resp As ChilkatHttpResponse
Call http.setRequestHeader("Content-Type", "application/xml")
Set Resp = http.PostXml(Url, sbXml.GetAsString, "utf-8")

El texto del archivo una vez firmado con el certificado de Representación incluye la siguiente línea ( el acento de la o no lo ponemos nosotros, si no la librería en el momento de firmar):
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Pero a la Hacienda Foral de Guipúzcoa le llega lo siguiente :
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El ticket se genera correctamente con el QR y se puede consultar sin problemas, pero todos los lunes recibimos una notificación de Ticket Bai diciendo que 19 tickets (cada semana) son incorrectos por error en la verificación de firma. obviamente se transmiten todos por igual pero esos 19 son los que comprueban de manera aleatoria

[espinete]

Nos ha surgido otro problema con respecto a las rectificativas de facturas simplificadas, debido a una característica opcional de nuestro software (que utiliza la mayoría de clientes, de hecho).

Nuestro software permite realizar facturas ordinarias y tíckets (TPV), y el usuario elige si quiere enumeración independiente para cada cosa.
Es decir, las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.

El problema surge con las facturas rectificativas:

- Si hago una rectificativa de una factura ordinaria #25, ésta se guardará con el número 1 en la serie "R", rectificando la factura 25.
- Si casualmente luego hago una rectificativa de la factura simplificada #25, ésta se guardará con el número 2 en la serie "R", rectificando a la factura simplificada 25

El problema es que TicketBAI Gipuzkoa me dice que no puede haber dos rectificativas que rectifican a la "misma" factura, aunque en realidad no es la misma: una es ordinaria y otra es simplificada.
Y además, añaden que no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R".

¿En serio te obligan a usar solo una serie?

Lo ideal sería que tanto facturas ordinarias como simplificadas se guardaran en el mismo historial, con numeración correlativa, sin importar si son facturas o tíckets. Pero esto es opcional en nuestro software, y el 99% de los clientes lo tienen separado.
Decirles ahora que lo guarden todo junto va a ser una locura.

Todo esto surge a raíz de la "obligación" se hacer rectificativas para los tíckets en vez de una simple venta en negativo. La verdad es que el tema ya me está cansando un poco.

[keys]

Empezado por espinete

Nos ha surgido otro problema con respecto a las rectificativas de facturas simplificadas, debido a una característica opcional de nuestro software (que utiliza la mayoría de clientes, de hecho).

Nuestro software permite realizar facturas ordinarias y tíckets (TPV), y el usuario elige si quiere enumeración independiente para cada cosa.
Es decir, las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.

El problema surge con las facturas rectificativas:

- Si hago una rectificativa de una factura ordinaria #25, ésta se guardará con el número 1 en la serie "R", rectificando la factura 25.
- Si casualmente luego hago una rectificativa de la factura simplificada #25, ésta se guardará con el número 2 en la serie "R", rectificando a la factura simplificada 25

El problema es que TicketBAI Gipuzkoa me dice que no puede haber dos rectificativas que rectifican a la "misma" factura, aunque en realidad no es la misma: una es ordinaria y otra es simplificada.
Y además, añaden que no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R".

¿En serio te obligan a usar solo una serie?

Lo ideal sería que tanto facturas ordinarias como simplificadas se guardaran en el mismo historial, con numeración correlativa, sin importar si son facturas o tíckets. Pero esto es opcional en nuestro software, y el 99% de los clientes lo tienen separado.
Decirles ahora que lo guarden todo junto va a ser una locura.

Todo esto surge a raíz de la "obligación" se hacer rectificativas para los tíckets en vez de una simple venta en negativo. La verdad es que el tema ya me está cansando un poco.

Hola, No puedes tener dos facturas con el #25, aunque una sea simplificada y otra normal. Fíjate que la segunda que presentes te estará devolviendo una aviso y la primera que presentas ya no vale. Lo que te dice ahora es que la #25 no se puede rectificar dos veces (lógicamente).

El problema parte de que Gipuzkoa si le envías la misma factura #25 dos veces (con fechas distintas) no genera un error, sino un aviso. Y se quedan con la última que envías.

[espinete]

Empezado por keys

Hola, No puedes tener dos facturas con el #25, aunque una sea simplificada y otra normal. Fíjate que la segunda que presentes te estará devolviendo una aviso y la primera que presentas ya no vale. Lo que te dice ahora es que la #25 no se puede rectificar dos veces (lógicamente).

El problema parte de que Gipuzkoa si le envías la misma factura #25 dos veces (con fechas distintas) no genera un error, sino un aviso. Y se quedan con la última que envías.

Pues entonces tenemos un problema gordo. La mayoría de clientes lo han preferido hacer así: separar los historiales/numeración, para tener las facturas por un lado y los tíckets por otro.
El software permite hacer eso desde el año 2000, y nunca ha habido problema. Que ahora no se pueda hacer eso por culpa de TicketBAI, supondrá un problema serio para los clientes que envíen a TicketBAI.

La solución sería decirles que a partir de ahora todo se guarde en el mismo historial/numeración, y punto, pero a saber con qué nuevos problemas nos encontraremos después

Vamos a tener que darle muchas vueltas a este tema antes de tomar una decisión.

[keys]

Empezado por espinete

Pues entonces tenemos un problema gordo. La mayoría de clientes lo han preferido hacer así: separar los historiales/numeración, para tener las facturas por un lado y los tíckets por otro.
El software permite hacer eso desde el año 2000, y nunca ha habido problema. Que ahora no se pueda hacer eso por culpa de TicketBAI, supondrá un problema serio para los clientes que envíen a TicketBAI.

La solución sería decirles que a partir de ahora todo se guarde en el mismo historial/numeración, y punto, pero a saber con qué nuevos problemas nos encontraremos después

Vamos a tener que darle muchas vueltas a este tema antes de tomar una decisión.

También puedes hacer una serie distinta para los tickets y otra para las normales.

[rci]

Empezado por espinete

Nos ha surgido otro problema con respecto a las rectificativas de facturas simplificadas, debido a una característica opcional de nuestro software (que utiliza la mayoría de clientes, de hecho).

Nuestro software permite realizar facturas ordinarias y tíckets (TPV), y el usuario elige si quiere enumeración independiente para cada cosa.
Es decir, las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.

El problema surge con las facturas rectificativas:

- Si hago una rectificativa de una factura ordinaria #25, ésta se guardará con el número 1 en la serie "R", rectificando la factura 25.
- Si casualmente luego hago una rectificativa de la factura simplificada #25, ésta se guardará con el número 2 en la serie "R", rectificando a la factura simplificada 25

El problema es que TicketBAI Gipuzkoa me dice que no puede haber dos rectificativas que rectifican a la "misma" factura, aunque en realidad no es la misma: una es ordinaria y otra es simplificada.
Y además, añaden que no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R".

¿En serio te obligan a usar solo una serie?

Lo ideal sería que tanto facturas ordinarias como simplificadas se guardaran en el mismo historial, con numeración correlativa, sin importar si son facturas o tíckets. Pero esto es opcional en nuestro software, y el 99% de los clientes lo tienen separado.
Decirles ahora que lo guarden todo junto va a ser una locura.

Todo esto surge a raíz de la "obligación" se hacer rectificativas para los tíckets en vez de una simple venta en negativo. La verdad es que el tema ya me está cansando un poco.

Hola espinete, donde dice que 'no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R"'??

Porque si esto es así, nosotros tendremos el mismo problema.
Ahora mismo las series de nuestro programa siempre son distintas tanto entre facturas simplificadas y otras facturas como entre rectificativas de simplificadas y rectificativas de otras facturas.
Pero claro no tenemos dos facturas 25 sin serie, tenemos una 25 con la serie vacía (facturas ordinaria) y una 25 con la serie FS (factura simplificada).

De momento no tenemos constancia de ninguna queja ni de ningún error al enviar a TicketBAI

Gracias

[espinete]

Empezado por rci

Hola espinete, donde dice que 'no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R"'??

Porque si esto es así, nosotros tendremos el mismo problema.
Ahora mismo las series de nuestro programa siempre son distintas tanto entre facturas simplificadas y otras facturas como entre rectificativas de simplificadas y rectificativas de otras facturas.
Pero claro no tenemos dos facturas 25 sin serie, tenemos una 25 con la serie vacía (facturas ordinaria) y una 25 con la serie FS (factura simplificada).

De momento no tenemos constancia de ninguna queja ni de ningún error al enviar a TicketBAI

Gracias

Hola, rci.

Nuestro cliente ha hablado con Gipuzkoa y es lo que le han dicho, pero de ahí a que sea cierto, hay una gran diferencia.
Yo no veo ningún problema en usar una serie "R" para las rectificativas de ordinarias y una serie "V" o lo que sea para las rectificativas de simplificadas.
Vamos, como si uso 20 series para lo que me de la gana, eso a ellos no debería importarles nada.

[rci]

Empezado por espinete

Hola, rci.

Nuestro cliente ha hablado con Gipuzkoa y es lo que le han dicho, pero de ahí a que sea cierto, hay una gran diferencia.
Yo no veo ningún problema en usar una serie "R" para las rectificativas de ordinarias y una serie "V" o lo que sea para las rectificativas de simplificadas.
Vamos, como si uso 20 series para lo que me de la gana, eso a ellos no debería importarles nada.

Gracias espinete, espero que solo sea algo que ha entendido mal el cliente.

Empezado por keys

También puedes hacer una serie distinta para los tickets y otra para las normales.

Exacto, estoy con keys.
Si como dices 'las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.', porque no ponerles una serie distinta para enviar a TicketBAI?

Saludos

[Sistel]

Empezado por rci

Gracias espinete, espero que solo sea algo que ha entendido mal el cliente.
Exacto, estoy con keys.
Si como dices 'las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.', porque no ponerles una serie distinta para enviar a TicketBAI?

Hola,

Por supuesto que puedes tener todas las series diferentes de facturas que quieras para organizar mejor tu negocio.
En nuestra aplicación, por defecto usamos, al menos, 5 series diferentes:
- C para facturas completas
- S para facturas simplificadas (tickets)
- CR para facturas rectificativas de facturas completas
- SR para facturas rectificativas de facturas simplificadas
- X para facturas completas de sustitución de simplificadas (antes llamadas facturas de canje)

Saludos

[Neftali [Germán.Estévez]]

Empezado por skatologiko

Buenas , en Guipúzcoa tenemos el siguiente problema con la codificacióndesde el principio , nos estamos volviendo locos y no encontramos la solución. A ver si alguien puede arrojarme luz
Nuestro programa está hecho en visual basic y utilizamos las librerías chilkat para transmitir, así como un certificado de la FNMT de representación de mi cliente

El código con el que enviamos cada ticket o factura es el siguiente. Como se ve, estamos transmitiendo con codificación utf-8.


El ticket se genera correctamente con el QR y se puede consultar sin problemas, pero todos los lunes recibimos una notificación de Ticket Bai diciendo que 19 tickets (cada semana) son incorrectos por error en la verificación de firma. obviamente se transmiten todos por igual pero esos 19 son los que comprueban de manera aleatoria

Nosotros desde el principio hemos tenido que hacer algo diferente para Guipuzkoa.
Pasamos a codificación ANSI antes de enviar, porque si o hacemos según la documentación nos daban los avisos.

No pasa nada si el TicketBAI no lleva caracteres extraños, pero si los lleva nos daba problemas.

[iMia]

Buenas, hace un par de días, me han reportado que los técnicos de la hacienda foral (Guipuzkoa), están diciendo que no se pueden hacer abonos, que se tiene que hacer facturas rectificativas.

No sé si el cliente y/o nuestro asistente no han entendido el mensaje o realmente están diciendo eso. ¿Alguien ha oído algo de eso? ¿alguien conoce alguna normativa sobre el tema?

gracias.

[Sistel]

Empezado por iMia

Buenas, hace un par de días, me han reportado que los técnicos de la hacienda foral (Guipuzkoa), están diciendo que no se pueden hacer abonos, que se tiene que hacer facturas rectificativas.
No sé si el cliente y/o nuestro asistente no han entendido el mensaje o realmente están diciendo eso. ¿Alguien ha oído algo de eso? ¿alguien conoce alguna normativa sobre el tema?
gracias.

Hola,

Por supuesto que lo más correcto es hacer (siempre que se pueda) facturas rectificativas.
Pero, como ya habíamos comentado en este hilo, en algunos casos es imposible por no poder acceder a los datos de la factura original.
Y, en estos casos, no queda otra opción que hacer una factura negativa.

Y, hasta ahora (que yo sepa), Hacienda no ha puesto ninguna objeción a hacer facturas negativas.

Saludos

[iMia]

Empezado por Sistel

Hola,

Por supuesto que lo más correcto es hacer (siempre que se pueda) facturas rectificativas.
Pero, como ya habíamos comentado en este hilo, en algunos casos es imposible por no poder acceder a los datos de la factura original.
Y, en estos casos, no queda otra opción que hacer una factura negativa.

Y, hasta ahora (que yo sepa), Hacienda no ha puesto ninguna objeción a hacer facturas negativas.

Saludos

Muchas gracias,

Sí, si sabemos sobre "lo mejor" y "lo posible" ...

Pero hasta para los clientes, ven que al equivocarse, lo anulan y lo vuelven a hacer y ya está. Si les metemos que los albaranes han sido rectificados, que generan movimientos de estoc que rectifican, documentos rectificados, que tienen dos estados (física cuántica) el original y el rectificado, Factura rectificativa, con una seria a parte, o como lo tengas que hacer en el sistema de gestión, etc etc se vuelven más locos aún o les da un ictus..., si ya les cuesta seguir albarán->factura->Firma->QR-> envío a TBAI ... ni te digo el flujo de las rectificativas y eso que sólo les he implementado las rectificativas por sustitución.

Es que sin legislación de por medio, no entendía cómo les dicen que no pueden hacer abonos...

Seguro que les han dicho "que es mejor", "más conveniente" o "adecuado" o algo así... y ya se lo han tomado de la tremenda...

gracias...

[pablog2k]

Empezado por iMia

Muchas gracias,

Sí, si sabemos sobre "lo mejor" y "lo posible" ...

Pero hasta para los clientes, ven que al equivocarse, lo anulan y lo vuelven a hacer y ya está. Si les metemos que los albaranes han sido rectificados, que generan movimientos de estoc que rectifican, documentos rectificados, que tienen dos estados (física cuántica) el original y el rectificado, Factura rectificativa, con una seria a parte, o como lo tengas que hacer en el sistema de gestión, etc etc se vuelven más locos aún o les da un ictus..., si ya les cuesta seguir albarán->factura->Firma->QR-> envío a TBAI ... ni te digo el flujo de las rectificativas y eso que sólo les he implementado las rectificativas por sustitución.

Es que sin legislación de por medio, no entendía cómo les dicen que no pueden hacer abonos...

Seguro que les han dicho "que es mejor", "más conveniente" o "adecuado" o algo así... y ya se lo han tomado de la tremenda...

gracias...

A lo que se refieren los técnicos que te dijeron eso (y lo que te dicen también los técnicos de hacienda, que estamos hartos de discutir con ellos), es que tú no puedes hacer un abono (vamos a llamar abono a una factura en negativo), que no sea una rectificativa. Toda factura en negativo (abono) , debe de ser una rectificativa, en su serie correspondiente (nada de en la misma serie que las facturas normales), y debes indicar a quien rectificas.
Otra cosa es que hagas facturas en negativo en tu serie normal y las subas al ticketbai, SII, o donde sea, y trague, pero en teoría, está mal

[Roberto Blasco]

Hola, no sé si tendrá que ver con tu pregunta, pero yo tenía problemas al enviar y chilkat utilizando caracteres especiales como la ñ o acentos y tuve que utilizar el método PBinary del objeto CkHttp, con eso corregí el problema.

// Response
CkXml xml;
xml.LoadXml(xmlData);
sbXml.Append(xml.getXml());
bool md5 = false;

CkByteData* byteData = new CkByteData();
byteData->put_Utf8(true);
byteData->appendStr(xmlData);

mTBAIEnviar[handle]->ckHttpResponse = mTBAIEnviar[handle]->ckHttp->PBinary(
"POST",
mTBAIEnviar[handle]->url.c_str(),
*byteData,
contentType,
false,
gzip);

delete byteData;
mTBAIEnviar[handle]->lastError = mTBAIEnviar[handle]->ckHttp->lastErrorText();
mTBAIEnviar[handle]->ckHttp->ClearHeaders();
if (!mTBAIEnviar[handle]->ckHttp->get_LastMethodSuccess()) {
mTBAIEnviar[handle]->lastErrorCode = INEOTBAI_ERROR::ERROR_HANDLE_INEOTBAI_ENVIAR;
}

Espero que te pueda servir. Un saludo. Roberto Blasco.

[skatologiko]

Empezado por Neftali [Germán.Estévez]

Nosotros desde el principio hemos tenido que hacer algo diferente para Guipuzkoa.
Pasamos a codificación ANSI antes de enviar, porque si o hacemos según la documentación nos daban los avisos.

No pasa nada si el TicketBAI no lleva caracteres extraños, pero si los lleva nos daba problemas.

Muchas gracias por contestar. Hemos probado ahora a enviar con codificación ANSI, pero nos dicen los técnicos lo siguiente:

Les adjuntamos el fichero recibido para esa factura, para que vean que sigue sufriendo modificación durante el envío.