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

[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

[iMia]

Empezado por pablog2k

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

No me lo dijeron directamente a mi, se lo dijeron a un cliente, este se lo dijo a nuestro asistente, y este me lo dijo a mi... (el juego del teléfono... )

Ahora y, tal y como lo explicas, lo veo perfectamente lógico. Mil gracias!

Ahí si podría intervenir yo si se ponen muy farrucos los técnicos... que sería desde la aplicación, en la generación de facturas, si es un abono, hacer que sea en la serie rectificativa y que indiquen la factura que abona.... y ya estaría...

Gracias de nuevo.

[YellowStone]

Empezado por iMia

No me lo dijeron directamente a mi, se lo dijeron a un cliente, este se lo dijo a nuestro asistente, y este me lo dijo a mi... (el juego del teléfono... )

Ahora y, tal y como lo explicas, lo veo perfectamente lógico. Mil gracias!

Ahí si podría intervenir yo si se ponen muy farrucos los técnicos... que sería desde la aplicación, en la generación de facturas, si es un abono, hacer que sea en la serie rectificativa y que indiquen la factura que abona.... y ya estaría...

Gracias de nuevo.

Por poner un ejemplo, en una facturación de crédito del mes pasado, le facturo 50 albaranes del mes a un cliente, con un saldo positivo para nuestra empresa, a cobrar, de 2000 euros.

Me devuelve varias cosas este mes de distintos albaranes, que yo le pongo en nuevos albaranes en negativo, le facturo los albaranes a fin de mes, y resulta que que el resultado le sale a favor del cliente, negativo 100 euros, por ejemplo. ¿No puedo enviar esa factura porque su resultado es negativo?

¿Qué pretenden que haga? Es absurdo.

[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.