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

[YellowStone]

Empezado por Band

Hola keys, gracias por la respuesta.
Mi problema es que no puedo usar el Txmldocument de momento
No sé si es problema del Msxml2.DOMDocument.6.0, porque así Código Delphi [-]Documento.DocumentElement.ChildNodes[4].ChildNodes[1].Text;

tampoco consigo referenciarlo.

Seguiré investigando.

Aparte del código proporcionado por Keys, yo lo he conseguido de la siguiente manera (código Delphi 2007):

Código Delphi [-]
function BuscaSignatureValue(documento: IXMLDocument): string;
var ANode1: IXMLNode;
    i: integer;
begin
  result := '';
  for i := 0 to documento.DocumentElement.ChildNodes.Count - 1 do
    begin
      if documento.DocumentElement.ChildNodes.Nodes[i].NodeName = 'ds:Signature' then
        begin
          ANode1 := documento.DocumentElement.ChildNodes.Nodes[i];
          if ANode1.ChildNodes.FindNode('ds:SignatureValue') <> nil then
            begin
              result := ANode1.ChildNodes['ds:SignatureValue'].Text;
              result := AnsiReplaceStr(result, #10, '');               // Quitamos los saltos de línea del nodo
              result := Copy(Trim(result), 1, 100);                    // Cogemos los 100 primeros caracteres
              break;
            end;
        end;
    end;
end;

La solución de Keys es estupenda, pero con el inconveniente de que si en algún momento se cambia o se añade algún nodo en el fichero, va a dejar de ser funcional.

[b4aronDeLaBirr4]

Buenas!

Os quería preguntar sobre la realización de la firma. Por ejemplo, en mi caso compongo mi archivo XML en C# rellenando aquellos campos normales (importe, nif....) pero ¿cómo procedo con la firma del documento cuando lo tengo ya rellenado? (Porque qué hacer con el campo Signature del XML?)
He estado leyendo sobre la política de firma y demás, pero tampoco es que me haya quedado claro del todo. Gracias de antemano.

Un saludo

[sEngine]

He estado mirando el de bizkaia (con LROE y demas) y me ha venido una duda.
Hay que enviar tanto las facturas y tickets de venta como las facturas de compra?

[Casimiro Notevi]

Empezado por YellowStone

...

[tejano]

Empezado por b4aronDeLaBirr4

Buenas!

Os quería preguntar sobre la realización de la firma. Por ejemplo, en mi caso compongo mi archivo XML en C# rellenando aquellos campos normales (importe, nif....) pero ¿cómo procedo con la firma del documento cuando lo tengo ya rellenado? (Porque qué hacer con el campo Signature del XML?)
He estado leyendo sobre la política de firma y demás, pero tampoco es que me haya quedado claro del todo. Gracias de antemano.

Un saludo

Yo utilizo el comando autofirmacommandline del programa Autofirma, pero tarda unos sg en firmar.

En mi caso no tengo mucho problema porque hacemos unas 200 facturas x mes, pero no sé para vosotros.

Si buscas en el foro, verás el comando que se utilza.

Saludos

[YellowStone]

A ver ahora:

Código Delphi [-]
function BuscaSignatureValue(documento: string): string;
var xml: IXMLDocument;
    ANode1: IXMLNode;
    i: integer;
begin
  result := '';
  try
    xml := LoadXmlDocument(documento);
    for i := 0 to xml.DocumentElement.ChildNodes.Count - 1 do
      begin
        if xml.DocumentElement.ChildNodes.Nodes[i].NodeName = 'ds:Signature' then
          begin
            ANode1 := xml.DocumentElement.ChildNodes.Nodes[i];
            if ANode1.ChildNodes.FindNode('ds:SignatureValue') <> nil then
              begin
                result := ANode1.ChildNodes['ds:SignatureValue'].Text;
                result := AnsiReplaceStr(result, #10, '');               // Quitamos los saltos de línea del nodo
                result := Copy(Trim(result), 1, 100);                    // Cogemos los 100 primeros caracteres
                break;
              end;
          end;
      end;
  finally
    FreeAndNil(xml);
  end;
end;

No sé por qué FindNode no encuentra "ds:Signature", de ahí el bucle buscando por el NoneName, que ahí si lo encuentra.

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

Empezado por Galaxian

Seguro que no se han dado cuenta de que el software que usan comprime automáticamente los datos si descubre el encabezado Content-Encoding: gzip, y lo digo porque las librerías que uso (Chilkat) hacen exactamente eso: comprimen y descomprimen automáticamente los datos si encuentra dicho encabezado. De hecho, al objeto html le envío datos xml y él los comprime y envía un gz, pero al recibir la respuesta, en vez de un XML recibo un GZ.

Como no podía ser de otra manera, lo primero que hice fue acceder a los datos realmente recibidos, descomprimí el gz y el resultado fue otro gz.

He optado por no decírselo a los de batuz porque hay ciertos "dioses de la programación" (entre los que se encuentran ellos según he comprobado en otras preguntas) que no reconocen un error ni ante el mismísimo Tomás de Torquemada.

Correcto.
A esa misma conclusión llegamos nosotros y se lo explicamos con detalle.

No es que ellos compriman 2 veces (que imaginábamos que no) sino que es su servidor o alguna pieza que tienen funcionando vuelve a comprimir lo que envían, de forma que se recibe un doble comprimido.

Les explicamos que no era tema de las librerías que usamos (porque otros usuarios usan otras), ni siquiera de Delphi (porque otros usuarios de otros lenguajes también se encuentran con esto). Todo ello, con los links correspondientes para consultar.
¿Crees que se lo han mirado?
La respuesta fue algo equivalente a "nosotros lo hacemos bien, el resto lo hacéis mal, revisad vuestro código".

Incluso les dijimos que con PostMan se puede comprobar esto. Pues nada, debe ser que la gente de Postman también hacen algo mal...


Otro con algo de seriedad al menos se lo miraría o pediría más datos. Ellos ni eso.

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

Empezado por sEngine

He estado mirando el de bizkaia (con LROE y demas) y me ha venido una duda.
Hay que enviar tanto las facturas y tickets de venta como las facturas de compra?

Si, son libros diferentes con esquemas diferentes.

[JoseLeeTo]

Hola a todos.

¿Conocéis las URL de envío y anulación para Álava?

Muchas gracias.
Un saludo.

[JoseLeeTo]

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

Si, son libros diferentes con esquemas diferentes.

Efectivamente,
Hay que diferenciar entre Ingresos con y sin Factura, así como Gastos con y sin factura. Son capítulos diferentes, con esquemas diferentes.
Solamente para Bizkaia, ya que en Guipuzcoa y en Alava, creo que solo requieren ingresos con factura.

Saludos.

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

Empezado por JoseLeeTo

¿Conocéis las URL de envío y anulación para Álava?

Que yo sepa no existe ni el servidor, por lo tanto la URL es difícil que esté...
La única que hay es la de consulta:

https://ticketbai.araba.eus/TBAI/QRTBAI
(que tampoco funciona)

Esto es lo que nos contestaron a nosotros.

Durante 2021 está previsto tener a disposición de los usuarios y empresas de software un entorno de pruebas que, de momento se encuentra en fase de desarrollo.
Esperamos tenerlo operativo a partir de septiembre.

[edari]

Sigo bloqueado con la subida de facturas a Gipuzkoa


Tengo bajados y revisados ejemplos de xml descargados de este hilo (Ejemplo_TicketBAI_......xml) pero están todas firmadas y para ver donde tengo el problema me serviría de bastante ayuda que alguno de vosotros pudiera subir aquí un xml de una factura normal y corriente SIN FIRMAR para ver si tengo algo mal


O también puedo subir yo mi ejemplo si lo preferís


Gracias de nuevo

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

Empezado por edari

...para ver donde tengo el problema me serviría de bastante ayuda que alguno de vosotros pudiera subir aquí un xml de una factura normal y corriente

¿Te refieres a esto?

Código PHP:

<Cabecera>
        <IDVersionTBAI>1.2</IDVersionTBAI>
    </Cabecera>
    <Sujetos>
        <Emisor>
            <NIF>J69552834</NIF>
            <ApellidosNombreRazonSocial>Empresa de Test</ApellidosNombreRazonSocial>
        </Emisor>
        <Destinatarios>
            <IDDestinatario>
                <NIF>A86868189</NIF>
                <ApellidosNombreRazonSocial>C1</ApellidosNombreRazonSocial>
                <CodigoPostal>22050</CodigoPostal>
                <Direccion>CL. Menor, 77, 20, 30, 40 - Mod</Direccion>
            </IDDestinatario>
        </Destinatarios>
        <VariosDestinatarios>N</VariosDestinatarios>
        <EmitidaPorTercerosODestinatario>N</EmitidaPorTercerosODestinatario>
    </Sujetos>
    <Factura>
        <CabeceraFactura>
            <SerieFactura/>
            <NumFactura>5</NumFactura>
            <FechaExpedicionFactura>20-04-2021</FechaExpedicionFactura>
            <HoraExpedicionFactura>00:00:00</HoraExpedicionFactura>
            <FacturaSimplificada>N</FacturaSimplificada>
            <FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
        </CabeceraFactura>
        <DatosFactura>
            <DescripcionFactura>Factura de ejemplos 1</DescripcionFactura>
            <DetallesFactura>
                <IDDetalleFactura>
                    <DescripcionDetalle/>
                    <Cantidad>1.00</Cantidad>
                    <ImporteUnitario>55.00000000</ImporteUnitario>
                    <Descuento>0.00</Descuento>
                    <ImporteTotal>66.55</ImporteTotal>
                </IDDetalleFactura>
            </DetallesFactura>
            <ImporteTotalFactura>66.55</ImporteTotalFactura>
            <Claves>
                <IDClave>
                    <ClaveRegimenIvaOpTrascendencia>51</ClaveRegimenIvaOpTrascendencia>
                </IDClave>
            </Claves>
        </DatosFactura>
        <TipoDesglose>
            <DesgloseFactura>
                <Sujeta>
                    <NoExenta>
                        <DetalleNoExenta>
                            <TipoNoExenta>S1</TipoNoExenta>
                            <DesgloseIVA>
                                <DetalleIVA>
                                    <BaseImponible>55.00</BaseImponible>
                                    <TipoImpositivo>21.00</TipoImpositivo>
                                    <CuotaImpuesto>11.55</CuotaImpuesto>
                                    <TipoRecargoEquivalencia>0.00</TipoRecargoEquivalencia>
                                    <CuotaRecargoEquivalencia>0.00</CuotaRecargoEquivalencia>
                                    <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>S</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                                </DetalleIVA>
                            </DesgloseIVA>
                        </DetalleNoExenta>
                    </NoExenta>
                </Sujeta>
            </DesgloseFactura>
        </TipoDesglose>
    </Factura> 


[tejano]

Hola, habéis enviado facturas recibidas de proveedores en la DFB?
Estoy enviando facturas recibidas y veo 2 problemas, el número de factura de Amazon es de más de 20 caracteres y el LROE de las recibidas solo permite 20 caracteres... como estáis solucionando esto?
Por otra parte, cuando hay una rectificativa de una factura recibida, hay que poner el número de serie de la factura rectificativa, pero solo sabemos el número completo, no se sabe a que parte corresponde a la serie de factura y que parte al número de factura.

No sé si es que todavía no lo tienen totalmente desarrollado, o que puede ser....

Saludos

[CMB]

He hecho una pequeña prueba usando uno de los ficheros de ejemplo de Batuz, y enviándolo al servidor de prueba de Gipuzkoa. El fichero Ejemplo_TicketBAI_79732487C_A2022_0399.xml está ligeramente modificado para cumplir con la spec actual de Gipuzkoa (se ha modificado las fechas para que no estén en el futuro, y se ha añadido la sección <DetallesFactura>).


Esta es la línea de comandos que uso para enviarlo:

curl.exe --data-binary @Ejemplo_TicketBAI_79732487C_A2022_0399.xml --cert-type P12 --cert sello_entidad_act.p12:IZProd2021 -H "Content-Type: application/xml;charset=UTF8" -X POST https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta

Y esta es la respuesta del servidor:

Código PHP:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>08-07-2021 18:24:48</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>005</Codigo>
            <Descripcion>Error: Fichero de alta TicketBAI ya registrado en el sistema.</Descripcion>
            <Azalpena>Errorea: TicketBAI fitxategia sisteman erregistratuta dago jada.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

Mi duda es la siguiente: No me sorprende que este fichero ya esté registrado (está claro que no soy el primero al que se le ocurre hacer esto), no obstante lo que me gustaría saber es qué criterio usan para determinar que una factura está duplicada. ¿Alguien tiene una idea?


He probado cambiar la serie y número de factura, sin éxito. También eliminar el encadenamiento (campo <EncadenamientoFacturaAnterior>) pero obtengo el mismo resultado.


Curiosamente no parece que al servidor le importe que tras todos estos cambios la firma en <ds:Signature> siga siendo la misma (aparentemente, esta comprobación es posterior).

[HerensugeBeltz]

Empezado por CMB

Mi duda es la siguiente: No me sorprende que este fichero ya esté registrado (está claro que no soy el primero al que se le ocurre hacer esto), no obstante lo que me gustaría saber es qué criterio usan para determinar que una factura está duplicada. ¿Alguien tiene una idea?

Te adjunto la respuesta de la Hacienda Foral a tu pregunta:

Egun on, buenos días

La validación que comprueba que una factura no esté ya enviada a TicketBAI y no suponga una duplicación comprueba que no exista otra factura con la misma clave funcional. Es decir que no contenga los mismos valores en los siguientes campos:

• NIF- Emisor + Serie + Numero + FechaExpedición

Si cambia la serie cambia la clave funcional, por lo que se considera otra factura. Es decir, MISERIE21-001 y MISERIE22-001 son dos facturas distintas.

Si no indica la serie, puede repetirse el número de factura pero la fecha de expedición ha de ser diferente.

Izan ongi,

[tejano]

Empezado por HerensugeBeltz

Te adjunto la respuesta de la Hacienda Foral a tu pregunta:

Egun on, buenos días

La validación que comprueba que una factura no esté ya enviada a TicketBAI y no suponga una duplicación comprueba que no exista otra factura con la misma clave funcional. Es decir que no contenga los mismos valores en los siguientes campos:

• NIF- Emisor + Serie + Numero + FechaExpedición

Si cambia la serie cambia la clave funcional, por lo que se considera otra factura. Es decir, MISERIE21-001 y MISERIE22-001 son dos facturas distintas.

Si no indica la serie, puede repetirse el número de factura pero la fecha de expedición ha de ser diferente.

Izan ongi,

Es decir, que si soy un "cabrón" y emito 50.000 facturas en el LROE de recibidas de Iberdrola, aunque no sean para mí, pero pongo como que sí, con su número y fecha porque quiero fastidiar el sistema. El resto de personas ya no van a poder enviarlas como recibidas??

[JoseLeeTo]

Empezado por tejano

Hola, habéis enviado facturas recibidas de proveedores en la DFB?
Estoy enviando facturas recibidas y veo 2 problemas, el número de factura de Amazon es de más de 20 caracteres y el LROE de las recibidas solo permite 20 caracteres... como estáis solucionando esto?
Por otra parte, cuando hay una rectificativa de una factura recibida, hay que poner el número de serie de la factura rectificativa, pero solo sabemos el número completo, no se sabe a que parte corresponde a la serie de factura y que parte al número de factura.

No sé si es que todavía no lo tienen totalmente desarrollado, o que puede ser....

Saludos

Hola. Sí que está desarrollado, tanto en Gastos con Factura como con los Gastos Sin Factura.
En el caso de los 20 caracteres, yo lo que hago es cortar la cadena a 20. No puedes hacer otra cosa.
Con el tema de la rectificativa, lo desconozco al igual que tú.
Lo que hago es subirla como si no fuese rectificativa, es decir, como si fuese una factura normal (que lo es).

[JoseLeeTo]

Empezado por tejano

Es decir, que si soy un "cabrón" y emito 50.000 facturas en el LROE de recibidas de Iberdrola, aunque no sean para mí, pero pongo como que sí, con su número y fecha porque quiero fastidiar el sistema. El resto de personas ya no van a poder enviarlas como recibidas??

Hombre, si todos tuviésemos el mismo NIF..... pero no es el caso.

[tejano]

Empezado por JoseLeeTo

Hombre, si todos tuviésemos el mismo NIF..... pero no es el caso.

Pensaba que estabais hablando de las facturas recibidas.

No sé si pondrán problemas si 2 CIF diferentes emiten en el LROE el mismo número de factura recibida, CIF EMISOR+SERIE+NUMERO+FECHA EXPEDICION, pero con diferentes CIF RECEPCTORES.