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

[tejano]

Buenos días, este es el primer mes que se hace automáticamente el modelo 303 del IVA en BFA con Batuz,

Los datos que tenemos en nuestra Base de Datos y los que ellos ponen nos descuadran totalmente.

Como consideráis vosotros el devengo del IVA, el el SII tenía en cuenta la fecha de operación en emitidas y la fecha de recepción en recibidas para la fecha de devengo

• Facturas emitidas, Devengo = fecha de operación o si esta no existe la fecha de factura
• Facturas recibidas, Devengo = fecha de Recepción de la factura en la empresa.

Podéis decirme si vosotros la consideráis de igual forma?

[keys]

Empezado por tejano

Buenos días, este es el primer mes que se hace automáticamente el modelo 303 del IVA en BFA con Batuz,

Los datos que tenemos en nuestra Base de Datos y los que ellos ponen nos descuadran totalmente.

Como consideráis vosotros el devengo del IVA, el el SII tenía en cuenta la fecha de operación en emitidas y la fecha de recepción en recibidas para la fecha de devengo

• Facturas emitidas, Devengo = fecha de operación o si esta no existe la fecha de factura
• Facturas recibidas, Devengo = fecha de Recepción de la factura en la empresa.

Podéis decirme si vosotros la consideráis de igual forma?

Hola, lo que consideramos nosotros no sirve de mucho. Hacienda hace lo siguiente https://www.batuz.eus/fitxategiak/sa...b24a83e2abf5c8, que es lo que tu pones.

[tejano]

Gracias Keys

[tejano]

Por si le puede interesar a alguien, me han respondido de la BFA y es como pensaba, por teléfono nos habían respondido diferente y generado la duda

Kaixo,

A efectos del devengo del IVA, se sigue este criterio:

- En las facturas expedidas, el devengo del IVA repercutido se produce en el periodo que corresponde a la fecha de operación. Si no hay fecha de operación, el devengo se produce en la fecha de expedición.
- En las facturas recibidas, el IVA soportado será deducible a partir del periodo al que corresponde la fecha de recepción, no antes. En las facturas recibidas se valida que la fecha de recepción no sea anterior a la fecha de expedición de la factura por el proveedor.
Agur bat.

Empezado por tejano

Buenos días, este es el primer mes que se hace automáticamente el modelo 303 del IVA en BFA con Batuz,

Los datos que tenemos en nuestra Base de Datos y los que ellos ponen nos descuadran totalmente.

Como consideráis vosotros el devengo del IVA, el el SII tenía en cuenta la fecha de operación en emitidas y la fecha de recepción en recibidas para la fecha de devengo

• Facturas emitidas, Devengo = fecha de operación o si esta no existe la fecha de factura
• Facturas recibidas, Devengo = fecha de Recepción de la factura en la empresa.

Podéis decirme si vosotros la consideráis de igual forma?

[Gherardo]

Buenos días a todos:

Tengo problemas al enviar el fichero xml a Guipúzcoa pues me cambia los acentos y caracteres como la ñ, y me devuelve el error '008 El mensaje ha sido modificado en transito'.
Utilizo Delphi 11 y componentes RESTClient, RESTRequest y RESTResponse. el fichero firmado tiene codificación utf-8.
pero al enviarlo parece que no se respeta.
El código que utilizo es este:

Código Delphi [-]
procedure TForm1.Button15Click(Sender: TObject);
var
  Texto:String;
  S,ArchivoString: TStrings;
  f1:TextFile;
 FicheroAEnviar,ArchivoRespuesta : String;
begin

 RESTRequest1.Method :=TRESTRequestMethod.rmPOST;
 RESTRequest1.Accept:='utf-8';
 RESTRequest1.AcceptCharset:='utf-8;q=0.8';

 RESTClient1.SecureProtocols :=[THTTPSecureProtocol.TLS11,THTTPSecureProtocol.TLS12];
 RESTClient1.ContentType:= 'application/xml;charset=UTF-8';
 RESTClient1.AcceptEncoding:='utf-8;q=0.8';
 RESTClient1.OnNeedClientCertificate:=RESTClient1NeedClientCertificate;

 Opendialog1.Execute();
 FicheroAEnviar:=OpenDialog1.FileName;
 ArchivoRespuesta:=Copy(FicheroAEnviar,1,Length(FicheroAEnviar)-4)+'resp';

 ArchivoString := TStringList.Create();
 try
  ArchivoString.LoadFromFile(FicheroAEnviar,Tencoding.UTF8);
  RESTRequest1.addbody(ArchivoString.Text,ctAPPLICATION_XML);
 finally
  ArchivoString.Free;
 end;

 RESTRequest1.Execute;

 var CodigoRespuesta := RESTRespuesta.StatusCode;
 var Respuesta           := RESTRespuesta.Content;
 var Cabeceras           := RESTRespuesta.Headers;

 s := TStringList.Create();
 S.Add(RESTRespuesta.Content);
 S.SaveToFile(ArchivoRespuesta, TEncoding.UTF8);

end;

Si alguien puede ayudar estaré agradecido, pues ando desesperado, llevo casi dos semanas atascado con este problema, y ya estoy pensando en dejar al cliente.

Muchas gracias.

[keys]

Hola.

¿Sólo te pasa con los envíos que tienen Ñ y acentos? Yo creo que el loadfromfile o el ArchivoString.Text te está cambiando algo en el fichero por la codificación. Yo los envíos los hago con TNetHTTPClient y no tengo ningún problema.

Un Saludo

[Gherardo]

Gracias Keys,
¿tendrías algún ejemplo de como se hace con estos componentes?

[keys]

Empezado por Gherardo

Gracias Keys,
¿tendrías algún ejemplo de como se hace con estos componentes?

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.

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

Yo te diría que cambies el código para no coger el body de un fichero. La mayoría de los problemas de cambio de codificación son al pasar por diferentes pasos.
Intenta generarlo en memoria (Stream) y asignarlo al componente directamente sin pasar por fichero.

[Gherardo]

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.

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

Empezado por Gherardo

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

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.

[sEngine]

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

[espinete]

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?

[keys]

Empezado por espinete

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.

[espinete]

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.

[DemonAscun]

Empezado por espinete

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.