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

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

Empezado por xamminf

He visto que en el año 2022 se cambio la politica de firma a: vSe1CH7eAFVkGN0X2Y7Nl9XGUoBnziDA5BGUSsyt8mg=

En el primer mensaje del hilo tienes las políticas de firma actualizadas a Mayo del 2022.
Nosotros estamos con la "nueva" desde hace tiempo. Si como dice [keys] la vieja todavía funciona, no hay prisa, pero en algún momento deberás actualizar la constante.

[xamminf]

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

En el primer mensaje del hilo tienes las políticas de firma actualizadas a Mayo del 2022.
Nosotros estamos con la "nueva" desde hace tiempo. Si como dice [keys] la vieja todavía funciona, no hay prisa, pero en algún momento deberás actualizar la constante.

Gracias a ambos.

[espinete]

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

En el primer mensaje del hilo tienes las políticas de firma actualizadas a Mayo del 2022.
Nosotros estamos con la "nueva" desde hace tiempo. Si como dice [keys] la vieja todavía funciona, no hay prisa, pero en algún momento deberás actualizar la constante.

Acabo de darme cuenta de que yo la política de firma la tengo en HEX. ¿Vosotros usáis el valor tal cual, o convertido a HEX?

Lo curioso es que para Araba sí uso el valor normal, pero para Gipuzkoa y Bizkaia lo tengo en HEX.

[xamminf]

Hola,

Intentando firmar, despues de 6 horas de vueltas, con autofirmacommandline.exe con los parametros de mas abajo se cuelga. Si quito todo lo que hay despues de -config va bien.
Observo que autofirma.exe (el que tiene GUI) le pongo los parametros y me da tambien error. El siguiente error:

es.gob.afirma.signers.xml.InvalidXMLException: Las firmas XAdES Enveloped solo pueden realizarse sobre datos XML
at es.gob.afirma.signers.xades.XAdESSigner.sign(XAdESSigner.java:510)
at es.gob.afirma.signers.xades.AOXAdESSigner.sign(AOXAdESSigner.java:407)
at es.gob.afirma.standalone.ui.SignPanelSignTask.signData(SignPanelSignTask.java:554)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doSignature(SignPanelSignTask.java:314)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:133)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:73)
at java.desktop/javax.swing.SwingWorker$1.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.desktop/javax.swing.SwingWorker.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

Código PHP:

AutoFirmaCommandLine.exe sign -i FicheroSinFirmar.xml -o FicheroFirmado.xml -store windows -alias NombreDescriptivo -format xades -xml -config "format=XAdES Enveloped\npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf\npolicyIdent ifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=\npolicyIdentifierHashAlgorithm=http://www.w3.org/2001/04/xmlenc#sha256\npolicyQualifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf 


¿ Alguien tiene un ejemplo de autofirmacommandline.exe con la version 1.8.0 ?
¿ Puede ser el problema la ultima version la 1.8.0 ? ¿ Que puedo hacer para poder seguir integrando el ticket bai ?

[xamminf]

Este es el mensaje de error de autofirmacommandline.exe

[Fatal Error] :98:1: Las estructuras del documento XML deben empezar y finalizar en la misma entidad.
<afirma>
            <result>false</result>
            <response>
                            <msg>Error en la operacion de firma: Las firmas XAdES Enveloped solo pueden realizarse sobre datos XML</msg>
            </response>
</afirma>

Empezado por xamminf

Hola,

Intentando firmar, despues de 6 horas de vueltas, con autofirmacommandline.exe con los parametros de mas abajo se cuelga. Si quito todo lo que hay despues de -config va bien.
Observo que autofirma.exe (el que tiene GUI) le pongo los parametros y me da tambien error. El siguiente error:

es.gob.afirma.signers.xml.InvalidXMLException: Las firmas XAdES Enveloped solo pueden realizarse sobre datos XML
at es.gob.afirma.signers.xades.XAdESSigner.sign(XAdESSigner.java:510)
at es.gob.afirma.signers.xades.AOXAdESSigner.sign(AOXAdESSigner.java:407)
at es.gob.afirma.standalone.ui.SignPanelSignTask.signData(SignPanelSignTask.java:554)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doSignature(SignPanelSignTask.java:314)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:133)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:73)
at java.desktop/javax.swing.SwingWorker$1.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.desktop/javax.swing.SwingWorker.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

Código PHP:

AutoFirmaCommandLine.exe sign -i FicheroSinFirmar.xml -o FicheroFirmado.xml -store windows -alias NombreDescriptivo -format xades -xml -config "format=XAdES Enveloped\npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf\npolicyIdent ifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=\npolicyIdentifierHashAlgorithm=http://www.w3.org/2001/04/xmlenc#sha256\npolicyQualifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf 


¿ Alguien tiene un ejemplo de autofirmacommandline.exe con la version 1.8.0 ?
¿ Puede ser el problema la ultima version la 1.8.0 ? ¿ Que puedo hacer para poder seguir integrando el ticket bai ?

[xamminf]

Empezado por xamminf

Este es el mensaje de error de autofirmacommandline.exe

[Fatal Error] :98:1: Las estructuras del documento XML deben empezar y finalizar en la misma entidad.
<afirma>
            <result>false</result>
            <response>
                            <msg>Error en la operacion de firma: Las firmas XAdES Enveloped solo pueden realizarse sobre datos XML</msg>
            </response>
</afirma>

Solucionado !!!!!
Me faltaba el tag terminal </T:TicketBai>
En fin. Siento los disturbios

[fmblas]

Buenas tardes.

Este foro me ha traído viejos recuerdos, pues hace mas de 20 años trabajé con Delphi en las versiones 2 a 7. Como Borland no creía en su producto y cada vez se usaba menos me tuve que reconvertir a .NET en fin.

Estoy adaptando una aplicación para el TBai (de momento sólo para Álava) y la duda me surge con los errores en los datos identificativos de la factura, sobre todo del receptor, como pueden ser en NIF, la dirección, etc. y los importes correctos.

Para corregir esto se ha de hacer una factura rectificativa que supongo será por sustitución con los datos identificativos corregidos y mi pregunta es si los importes son correctos, hay que ponerlos o no en la nueva factura y como afecta todo esto en la generación del xml. He preguntado a la diputación de Alaba y me han puesto un copiar y pegar de los diferentes casos de facturas rectificativas, que sólo hacen referencia a la corrección de importes.

Gracias por vuestra ayuda.

[HerensugeBeltz]

Empezado por fmblas

Buenas tardes.

Estoy adaptando una aplicación para el TBai (de momento sólo para Álava) y la duda me surge con los errores en los datos identificativos de la factura, sobre todo del receptor, como pueden ser en NIF, la dirección, etc. y los importes correctos.

Para corregir esto se ha de hacer una factura rectificativa que supongo será por sustitución con los datos identificativos corregidos y mi pregunta es si los importes son correctos, hay que ponerlos o no en la nueva factura y como afecta todo esto en la generación del xml.
Gracias por vuestra ayuda.

En Gipuzkoa, si la factura es errónea, a priori, debes hacer un Zuzendu (dirección o NIF incorrecto del receptor, etc.). Si la has emitido a un receptor equivocado, por ejemplo, entonces deberás darla de baja y emitir una nueva con un nº de factura diferente.

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

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

[HerensugeBeltz]

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 bgngdatos@gmail.com para no cargar este foro.
Gracias a todos.

[rci]

Hola, alguien tiene claro que ocurre con el IVA del 5% en 2024 en Euskadi?

He intentado enviar una factura con el 5% a Gipuzkoa y su respuesta ha sido:

El valor del campo TipoImpositivo es incorrecto, el valor informado solo es permitido para fecha de operación posterior o igual a 1 de Julio de 2022 e inferior o igual a 31 de diciembre de 2023

En cambio he enviado otra factura con el 5% a Araba y ha sido aceptada sin problemas.

Según AEAT el 5% es válido hasta el 30/06/2024 pero no tengo claro que ocurre en Euskadi.

También podría ser que Gipuzkoa no haya actualizado sus validaciones...

Gracias por todo.
Saludos

[keys]

Empezado por rci

Hola, alguien tiene claro que ocurre con el IVA del 5% en 2024 en Euskadi?

He intentado enviar una factura con el 5% a Gipuzkoa y su respuesta ha sido:


En cambio he enviado otra factura con el 5% a Araba y ha sido aceptada sin problemas.

Según AEAT el 5% es válido hasta el 30/06/2024 pero no tengo claro que ocurre en Euskadi.

También podría ser que Gipuzkoa no haya actualizado sus validaciones...

Gracias por todo.
Saludos

Lo acabo de probar y me ocurre lo mismo. Yo mandaría la incidencia a hacienda por que parece que no lo han actualizado. El % es normativa estatal. La nueva versión deberían haberla puesto el día 1 y la pusieron el 3.