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

[CarlosArjonomia]

Empezado por ermendalenda

Esto es como todos los curros. Habrá gente que trabaja, gente que no y gente que se pone las medallas. El marrón nos lo comemos los que empecemos los que vengan después ya tendrán todo frito y cocido con mil herramientas.
Hay una cosa que no entiendo. Por que cojones hacienda no Dan un programa que se ejecute en segundo plano que haga todo el tema de envíos aunque dejemos todos los ficheros en alguna carpeta. Y que lo instalen y comprueben ellos tanto dejarnos responsabilidades.
Algo así como el tem de tpv datáfonos.

Algo así acabarán haciendo y todo el trabajo no habrá servido para nada. La culpa la tenemos los picateclas (cariñosamente) que tragamos con todo.

[Kang]

Empezado por Galaxian

Código Delphi [-]
var
success: Boolean;
xmlToSign: HCkXml;
gen: HCkXmlDSigGen;
object1: HCkXml;
cert: HCkCert;
sbXml: HCkStringBuilder;
verifier: HCkXmlDSig;
numSigs: Integer;
verifyIdx: Integer;
verified: Boolean;

begin
success := True;
//  Load the XML to be signed from a file...
xmlToSign := CkXml_Create();
CkXml_LoadXmlFile(xmlToSign,'xmlToSign.xml');

gen := CkXmlDSigGen_Create();

CkXmlDSigGen_putSigLocation(gen,'T:TicketBai');
CkXmlDSigGen_putSigLocationMod(gen,0);
CkXmlDSigGen_putSigId(gen,'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-Signature');
CkXmlDSigGen_putSigNamespacePrefix(gen,'ds');
CkXmlDSigGen_putSigNamespaceUri(gen,'h_t_t_p:w_w_w_.w3.org/2000/09/xmldsig#');
CkXmlDSigGen_putSigValueId(gen,'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-SignatureValue');
CkXmlDSigGen_putSignedInfoCanonAlg(gen,'C14N');
CkXmlDSigGen_putSignedInfoDigestMethod(gen,'sha256');

Utilicé el código anterior, pero no puedo completar la firma y no hay cambios en el archivo XML. ¿Hay algo que me haya perdido?

[YellowStone]

Esta es una función que me he montado en una DLL externa para firmar los XML con las Chilkat, por si te sirve de ayuda. Me base en los posts de Galaxian, aunque haciendo ciertas modificaciones porque tampoco me iban, aparte de que hay que retocar direcciones por vienen, por ejemplo, con h_t_t_p y no http.

Código PHP:

function Firma_CLK(var Hacienda: WideString; var Pfx: WideString; var Password: WideString; var Fichero: WideString): boolean; stdcall;
var
  xmlToSign: HCkXml;
  gen: HCkXmlDSigGen;
  object1: HCkXml;
  cert: HCkCert;
  sbXml: HCkStringBuilder;
begin

  //  Load the XML to be signed from a file...
  xmlToSign := CkXml_Create();
  try
    CkXml_LoadXmlFile(xmlToSign, PWideChar(Fichero));

    gen := CkXmlDSigGen_Create();
    CkXmlDSigGen_putBehaviors(gen, 'TransformSignatureXPath, LocalSigningTime, IndentedSignature'); // Añadido LocalSigningTime para que salga la hora como con Autofirma

    CkXmlDSigGen_putSigLocation(gen, 'T:TicketBai');
    CkXmlDSigGen_putSigLocationMod(gen, 0);
    CkXmlDSigGen_putSigId(gen, 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-Signature');
    CkXmlDSigGen_putSigValueId(gen, 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-SignatureValue');
    CkXmlDSigGen_putSigNamespacePrefix(gen, 'ds');
    CkXmlDSigGen_putSigNamespaceUri(gen, 'http://www.w3.org/2000/09/xmldsig#');  // Aquí faltaban las '//' despues de http:
    CkXmlDSigGen_putSignedInfoCanonAlg(gen, 'C14N');
    CkXmlDSigGen_putSignedInfoDigestMethod(gen, 'sha512'); // Cambiado a sha512, en el ejemplo viene sha256

    //  Set the KeyInfoId before adding references..
    CkXmlDSigGen_putKeyInfoId(gen, 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-KeyInfo');

    //  Create an Object to be added to the Signature.
    object1 := CkXml_Create();

    CkXml_putTag(object1, 'xades:QualifyingProperties');
    CkXml_AddAttribute(object1, 'Id', 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-QualifyingProperties');
    CkXml_AddAttribute(object1, 'Target', '#Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-Signature');
    CkXml_AddAttribute(object1, 'xmlns:ds', 'http://www.w3.org/2000/09/xmldsig#');
    CkXml_AddAttribute(object1, 'xmlns:xades', 'http://uri.etsi.org/01903/v1.3.2#');
    CkXml_UpdateAttrAt(object1, 'xades:SignedProperties', True, 'Id', 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-SignedProperties');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SigningTime', 'TO BE GENERATED BY CHILKAT');
    CkXml_UpdateAttrAt(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SigningCertificate|xades:Cert|xades:CertDigest|ds:DigestMethod', True, 'Algorithm','http://www.w3.org/2001/04/xmlenc#sha512');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SigningCertificate|xades:Cert|xades:CertDigest|ds:DigestValue', 'TO BE GENERATED BY CHILKAT');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SigningCertificate|xades:Cert|xades:IssuerSerial|ds:X509IssuerName', 'TO BE GENERATED BY CHILKAT');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SigningCertificate|xades:Cert|xades:IssuerSerial|ds:X509SerialNumber', 'TO BE GENERATED BY CHILKAT');

    // Según la Hacienda Foral
    if Hacienda = '01' then // Araba
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyId|xades:Identifier', 'https://ticketbai.araba.eus/tbai/sinadura/')
    else if Hacienda = '20' then // Gipuzkoa
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyId|xades:Identifier', 'https://www.gipuzkoa.eus/ticketbai/sinadura')
    else if Hacienda = '48' then // Bizkaia
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyId|xades:Identifier', 'https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf');

    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyId|xades:Description', '');
    CkXml_UpdateAttrAt(object1,'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyHash|ds:DigestMethod',True,'Algorithm','http://www.w3.org/2001/04/xmlenc#sha256');

    // Según la Hacienda Foral
    if Hacienda = '01' then // Araba
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyHash|ds:DigestValue', 'iOgvkX7/yHIDRRiPy/LYQ0UUn7QV8/11D1BFbs8yMuQ=')
    else if Hacienda = '20' then // Gipuzkoa
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyHash|ds:DigestValue', '6NrKAm60o7u62FUQwzZew24ra2ve9PRQYwC21AM6In0=')
    else if Hacienda = '48' then // Bizkaia
      CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedSignatureProperties|xades:SignaturePolicyIdentifier|xades:SignaturePolicyId|xades:SigPolicyHash|ds:DigestValue', 'Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=');

    CkXml_UpdateAttrAt(object1, 'xades:SignedProperties|xades:SignedDataObjectProperties|xades:DataObjectFormat', True, 'ObjectReference', '#Reference-7e6f3481-4acc-47de-90fd-67878ad15e8e');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedDataObjectProperties|xades:DataObjectFormat|xades:Description', '');
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedDataObjectProperties|xades:DataObjectFormat|xades:MimeType', 'application/octet-stream'); // Cambio a octet-stream como Autofirma
    CkXml_UpdateChildContent(object1, 'xades:SignedProperties|xades:SignedDataObjectProperties|xades:DataObjectFormat|xades:Encoding', '');

    CkXmlDSigGen_AddObject(gen, '', CkXml__getXml(object1), '', '');

    //  -------- Reference 1 --------
    CkXmlDSigGen_AddSameDocRef(gen, '', 'sha512', 'C14N', '', 'http://www.w3.org/2000/09/xmldsig#Object');
    CkXmlDSigGen_SetRefIdAttr(gen, '', 'Reference-7e6f3481-4acc-47de-90fd-67878ad15e8e');

    //  -------- Reference 2 --------
    CkXmlDSigGen_AddObjectRef(gen, 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-SignedProperties', 'sha512', '', '', 'http://uri.etsi.org/01903#SignedProperties');

    //  -------- Reference 3 --------
    CkXmlDSigGen_AddSameDocRef(gen, 'Signature-63c35f38-2b5f-4600-b3da-3ddee86d62b3-KeyInfo', 'sha512' , '', '', '');

    //  Load a certificate that has been pre-installed on the Windows system
    //  This includes certificates on smartcards and USB tokens
    cert := CkCert_Create();
    result := CkCert_LoadPfxFile(cert, PWideChar(Pfx), PWideChar(Password));
    if (not result) then
      begin
        ShowMessage('Fallo al cargar el certificado PFX: '+Pfx+' / '+Password);
        Exit;
      end;

    CkXmlDSigGen_SetX509Cert(gen, cert, True);

    // Cambiado Certificate a CertChain para que salgan todos los certificados incluidos,
    // porque en certificados como los de UANATACA se incluyen varios certificados en x509Certificate
    // y con Certificate sólo aparece el primero, que no tiene porque ser el que necesitamos
    CkXmlDSigGen_putX509Type(gen,'CertChain');
    CkXmlDSigGen_putKeyInfoType(gen,'X509Data+KeyValue');

    //  Load XML to be signed...
    sbXml := CkStringBuilder_Create();
    CkXml_GetXmlSb(xmlToSign, sbXml);

    //  Sign the XML...
    result := CkXmlDSigGen_CreateXmlDSigSb(gen, sbXml);

    if (not result) then
      begin
        ShowMessage('Fallo en la firma');
        Exit;
      end;

    // Save the signed XML to a file.
    // Utilizo el mismo fichero de entrada
    // El último parámetro es False (no BOM o true BOM)
    result := CkStringBuilder_WriteFile(sbXml, PWideChar(Fichero), 'utf-8', False);
  except
    ShowMessage('Error de excepcion');
    result := False;
  end;

end; 


[YellowStone]

Aunque pone que es PHP, es Delphi; con el código DELPHI pone emoticonos en ciertas partes del código que lo hacen ilegible, y no permite más de 10 y no se puede subir.

[Ramon88]

Pues parece que mi problema con Bizkaia es algo de ellos...


Esta fué su respuesta:
Estamos analizando qué ocurre con el certificado de autónomo e intentaremos responderle lo antes posible.

¿Puede utilizar por favor otro certificado para la realización de las pruebas?

[Ramon88]

Una duda que tengo, cuando analizais el XML comaprado contra el esquema, lo haceis despues de firmarlo ?? si es así y hay un fallo, entiendo que no se puede subir, y que hay que paralizar la facturación o la subida de ficheros hasta que se subsane manualmente entiendo, el error en el xml ?

[yasmNote]

Empezado por unomasmas

Muchas gracias. Eso aclara todo mi problema :-)

Buenas,
Me está ocurriendo lo mismo con un cliente que está en RE y me dice que factura con un 26,2% (21 + 5,2) esto es posible? o simplemente en la factura hay que informar del 21% porque ya les estás diciendo en el campo "OperacionEnRecargoDeEquivalenciaORegimenSimplificado =’S’ " que tiene recargo de equivalencia no?

[yasmNote]

Empezado por bilbur

Como ya me funciona bien lo de los envíos a batuz os dejo el código


Lo primero que hago es separar por ejercicios el envío, no sea que en enero quira enviar facturas de diciembre y de enero

.....

Buenos días,
Muchísimas gracias por compartir tu código.
Me gustaría saber si habéis conseguido desarrollar para el modelo 140?
Gracias

[AlbertPujol]

Hola,

Estamos intentando integrarnos con el servicio de envío de facturas de Ingreso TicketBai de Bizkaia. Pero no conseguimos hacerlo con éxito ni con los datos que generamos nosotros ni con los datos de ejemplo que proporciona la diputación.
Hacemos un post a pruesarrerak . bizkaia .eus / N3B4000M / aurkezpena
Los certificados que usamos son los adjuntos que proporcionan de IZENPE.

Los headers de la petición son:
Accept-Encoding : gzip
Content-Encoding : gzip
Content-Length : 412
Content-Type : application/octet-stream
eus-bizkaia-n3-version : 1.0
eus-bizkaia-n3-content-type : application/xml
eus-bizkaia-n3-data : {"con": "LROE", "apa": "1.1", "inte": {"nif": "B00000034","nrs":"HOTEL ADIBIDEZ"},"drs": {"mode": "240","ejer": "2022"}}

¿Alguna idea de lo que nos puede estar pasando?

Muchas gracias

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

Empezado por AlbertPujol

Estamos intentando integrarnos con el servicio de envío de facturas de Ingreso TicketBai de Bizkaia. Pero no conseguimos hacerlo con éxito ni con los datos que generamos nosotros ni con los datos de ejemplo que proporciona la diputación.
Hacemos un post a https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena
Los certificados que usamos son los adjuntos que proporcionan de IZENPE.

Los headers de la petición son:
Accept-Encoding : gzip
Content-Encoding : gzip
Content-Length : 412
Content-Type : application/octet-stream
eus-bizkaia-n3-version : 1.0
eus-bizkaia-n3-content-type : application/xml
eus-bizkaia-n3-data : {"con": "LROE", "apa": "1.1", "inte": {"nif": "B00000034","nrs":"HOTEL ADIBIDEZ"},"drs": {"mode": "240","ejer": "2022"}}

¿Alguna idea de lo que nos puede estar pasando?

El content-Length normalmente no hace falta ponerlo porque se calcula automáticamente, aunque no creo que eso sea el problema.
En el ejercicio estás colocando 2022, cuando deberías estar mandando 2021.
Por lo demás no veo nada raro.
¿Qué error te está dando?

[sEngine]

Buenos dias, me ha surgido una duda
Nosotros tenemos un programa en el que el cliente puede venir y reservar algo que pagará a plazos.
Entonces en el caso de ticketbai, que habría que enviar? Los distintos pagos que hace o el total en el momento de la reserva? No he conseguido ver por ningun sitio como habria que proceder para estos casos

[espinete]

Empezado por espinete

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Ya tengo respuesta de Gipuzkoa y de Araba. Lo resumo:

Gipuzkoa (han copiado y pegado lo que dice Hacienda):

En el caso de modificación de la base imponible como consecuencia de la devolución de mercancías o de envases y embalajes que se realicen con ocasión de un posterior suministro que tenga el mismo destinatario y por la operación en la que se entregaron se hubiera expedido factura, no será necesaria la expedición de una rectificativa, sino que se podrá practicar la rectificación en la factura que se expida por dicho suministro, restando el importe de las mercancías o de los envases y embalajes devueltos del importe de dicha operación posterior.

En el resto de casos se ha de efectuar una factura rectificativa. Esta puede ser por sustitución o por diferencias, a elección del contribuyente. Se registra una factura rectificativa*que sería una devolución o cambio de mercancía con reflejo en la minoración de la base imponible y cuota y devolución de los importes.

Es decir, sigo con la misma duda. ¿Se emite o no se emite rectificativa? A mí es que cuando se ponen a hablar de "devolución de mercancías o envases/embalajes" me da la sensación de que no se refiere a ventas minoristas al público, sino más bien a la devolución de mercancía a un proveedor, pero bueno, así son las leyes, ambiguas.

Más adelante aclaran lo siguiente:

...existe la posibilidad de no hacer una factura rectificativa. Se trata del caso de la devolución con ocasión de un posterior suministro al mismo destinatario.

Entiendo que se refieren a un "cambio". En este caso no se necesita hacer rectificativa, supongo que únicamente si se trata de un cambio por el MISMO importe.

Y también dicen esto:

En el caso de la devolución, que efectivamente la práctica de muchas empresas sea la de expedir una nueva factura ordinaria con signo negativo, no implica que sea una práctica correcta.

Ya, pero tampoco implica que sea incorrecta. El 100% de los comercios lo hacen así, desde hace años. Suerte si pretenden cambiar la forma de hacer cambios y devoluciones a los comercios. Si ahora van a exigir hacer rectificativa, cambiar de serie de facturación, etc. lo veo un lío, no solo para los fabricantes de software sino para los propios usuarios finales.

Esto me dicen desde Araba:

Tal y como nos indica en su consulta, una devolución o cambio de mercancías no es un error en la factura. Pero esto no significa que no se deba expedir una factura rectificativa.

Yo pensaba que era requisito indispensable...

Cuando se produce la devolución de una prenda, es preceptivo expedir una factura rectificativa, lo normal es expedir una nueva factura simplificada con signo negativo, lo que se conoce como “nota de abono” que sí es una factura rectificativa.

No es necesario hacer factura rectificativa por una devolución de mercaderías, únicamente cuando a ese mismo cliente se le vaya a suministrar posteriormente otras mercaderías, en cuyo caso basta con restarlas en la siguiente factura que se le expedida.

Cuando se produce el cambio de una prenda por otra, es preceptivo hacer factura rectificativa. Lo normal es hacer lo que usted comenta en su pregunta: una nueva factura simplificada con signo positivo o negativo, según la nueva prenda sea de mayor o menor importe. Pues bien: esta última factura simplificada sí es una factura rectificativa, concretamente por diferencias.

Se requiera o no hacer rectificativa para los cambios y devoluciones, sea 100% correcto o no, etc. opino personalmente que va a ser una locura si los empleados tienen que "cambiar el chip" para hacer simples cambios o devoluciones.
Por no hablar de lo que nos supone a nosotros adaptar los programas para que los cambios y devoluciones vayan en otra serie de facturación distinta. No todos los programas de TPV permiten series de facturación.
Además hay que tener en cuenta que cuando hagamos "la rectificativa de una rectificativa", el usuario tendrá que buscar la venta anterior en dos historiales distintos. Y todo esto porque así lo requieren solo 3 provincias.

Pero bueno, supongo que estoy un poco cansado de todo esto y quien habla en realidad es el estrés

[Sistel]

Empezado por sEngine

Buenos dias, me ha surgido una duda
Nosotros tenemos un programa en el que el cliente puede venir y reservar algo que pagará a plazos.
Entonces en el caso de ticketbai, que habría que enviar? Los distintos pagos que hace o el total en el momento de la reserva? No he conseguido ver por ningun sitio como habria que proceder para estos casos

Hola sEngine,

Puedes crear presupuestos, facturas proforma (que no son realmente facturas sino presupuestos), pedidos, albaranes de entrega, recibos, cobros por anticipado, pagos a plazos, pagos en diferido ... o cualquier otro documento.
Pero ninguno de ellos tiene nada que ver con TicketBAI.
Son temas de contabilidad, pero no de facturación.

TicketBAI se aplica sólo a facturas (documentos con nombre factura o factura simplificada y con número de factura y fecha)

Saludos

[Sistel]

Empezado por espinete

Ya tengo respuesta de Gipuzkoa y de Araba. Lo resumo:

Gipuzkoa (han copiado y pegado lo que dice Hacienda):



Es decir, sigo con la misma duda. ¿Se emite o no se emite rectificativa? A mí es que cuando se ponen a hablar de "devolución de mercancías o envases/embalajes" me da la sensación de que no se refiere a ventas minoristas al público, sino más bien a la devolución de mercancía a un proveedor, pero bueno, así son las leyes, ambiguas.

Más adelante aclaran lo siguiente:



Entiendo que se refieren a un "cambio". En este caso no se necesita hacer rectificativa, supongo que únicamente si se trata de un cambio por el MISMO importe.

Y también dicen esto:



Ya, pero tampoco implica que sea incorrecta. El 100% de los comercios lo hacen así, desde hace años. Suerte si pretenden cambiar la forma de hacer cambios y devoluciones a los comercios. Si ahora van a exigir hacer rectificativa, cambiar de serie de facturación, etc. lo veo un lío, no solo para los fabricantes de software sino para los propios usuarios finales.

Esto me dicen desde Araba:



Yo pensaba que era requisito indispensable...



Se requiera o no hacer rectificativa para los cambios y devoluciones, sea 100% correcto o no, etc. opino personalmente que va a ser una locura si los empleados tienen que "cambiar el chip" para hacer simples cambios o devoluciones.
Por no hablar de lo que nos supone a nosotros adaptar los programas para que los cambios y devoluciones vayan en otra serie de facturación distinta. No todos los programas de TPV permiten series de facturación.
Además hay que tener en cuenta que cuando hagamos "la rectificativa de una rectificativa", el usuario tendrá que buscar la venta anterior en dos historiales distintos. Y todo esto porque así lo requieren solo 3 provincias.

Pero bueno, supongo que estoy un poco cansado de todo esto y quien habla en realidad es el estrés

Hola espinete,

Muchas gracias por el esfuerzo y por compartir las respuestas.

Pero ya me suponía que no se iban a mojar en el tema.
Se remiten siempre a las normativas sobre facturación y les trae sin cuidado cómo lo haga uno (siempre que se envíe el fichero TicketBAI, que es lo que les preocupa a ellos).

Creo que no nos queda más opción que seguir haciéndolo como siempre lo hayamos hecho:
Si en un programa de facturación se hacían facturas negativas, pues a seguir con el mismo sistema.
Si un programa de facturación ya tiene la opción de facturas rectificativas por sustitución o por diferencias (o por las dos) y no implica tener que añadir nada nuevo, pues facturas rectificativas.

Pero está claro que TicketBAI no se va a meter nunca con ese tema.
Puede ser tema de inspección de Hacienda (aunque un tema menor, como otros muchos de las normativas absurdas de facturación)

Saludos

[dimony]

Hola buenos dias,



enviando "Facturas Emitidas" a Vizcaya (LROE)



me da el siguiente error:

<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(EPES: S ALGORITMO: rsa-sha256:2048 POLITICA: N CERTIFICADO_ADMITIDO: S )</DescripcionErrorRegistroES>
                <DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(EPES: S ALGORITMO: rsa-sha256:2048 POLITICA: N CERTIFICADO_ADMITIDO: S )</DescripcionErrorRegistroEU>

Les he preguntado a servicio tecnico de Vizcaya y su respuesta es la siguiente:

En la firma del fichero TicketBAI no se está especificando el id y el Hash correctamente.En los ejemplos de las especificaciones podéis encontrar cómo indicarlo:
 
 <xades:SignaturePolicyIdentifier>
                              <xades:SignaturePolicyId>
                                 <xades:SigPolicyId>
                                      <xades:Identifier>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf</xades:Identifier>
                                      <xades:Description />
                                  </xades:SigPolicyId>
                                  <xades:SigPolicyHash>
                                      <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"  />
                                      <ds:DigestValue>Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=</ds:DigestValue>
                                  </xades:SigPolicyHash>
                                  <xades:SigPolicyQualifiers>
                                      <xades:SigPolicyQualifier>
                                          <xades:SPURI>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf</xades:SPURI>
                                      </xades:SigPolicyQualifier>
                                  </xades:SigPolicyQualifiers>
                              </xades:SignaturePolicyId>
                          </xades:SignaturePolicyIdentifier>

¿Alguien sabría indicarme cual es el problema?

[sEngine]

Empezado por Sistel

Hola sEngine,

Puedes crear presupuestos, facturas proforma (que no son realmente facturas sino presupuestos), pedidos, albaranes de entrega, recibos, cobros por anticipado, pagos a plazos, pagos en diferido ... o cualquier otro documento.
Pero ninguno de ellos tiene nada que ver con TicketBAI.
Son temas de contabilidad, pero no de facturación.

TicketBAI se aplica sólo a facturas (documentos con nombre factura o factura simplificada y con número de factura y fecha)

Saludos

Es que nosotros generamos ticket (con su numero y fecha) tanto para el momento de la reserva como para los siguientes pagos que se hacen. Entonces eso si que habria que enviarlo, no?

[ermendalenda]

Empezado por espinete

Ya tengo respuesta de Gipuzkoa y de Araba. Lo resumo:

Gipuzkoa (han copiado y pegado lo que dice Hacienda):



Es decir, sigo con la misma duda. ¿Se emite o no se emite rectificativa? A mí es que cuando se ponen a hablar de "devolución de mercancías o envases/embalajes" me da la sensación de que no se refiere a ventas minoristas al público, sino más bien a la devolución de mercancía a un proveedor, pero bueno, así son las leyes, ambiguas.

Más adelante aclaran lo siguiente:



Entiendo que se refieren a un "cambio". En este caso no se necesita hacer rectificativa, supongo que únicamente si se trata de un cambio por el MISMO importe.

Y también dicen esto:



Ya, pero tampoco implica que sea incorrecta. El 100% de los comercios lo hacen así, desde hace años. Suerte si pretenden cambiar la forma de hacer cambios y devoluciones a los comercios. Si ahora van a exigir hacer rectificativa, cambiar de serie de facturación, etc. lo veo un lío, no solo para los fabricantes de software sino para los propios usuarios finales.

Esto me dicen desde Araba:



Yo pensaba que era requisito indispensable...



Se requiera o no hacer rectificativa para los cambios y devoluciones, sea 100% correcto o no, etc. opino personalmente que va a ser una locura si los empleados tienen que "cambiar el chip" para hacer simples cambios o devoluciones.
Por no hablar de lo que nos supone a nosotros adaptar los programas para que los cambios y devoluciones vayan en otra serie de facturación distinta. No todos los programas de TPV permiten series de facturación.
Además hay que tener en cuenta que cuando hagamos "la rectificativa de una rectificativa", el usuario tendrá que buscar la venta anterior en dos historiales distintos. Y todo esto porque así lo requieren solo 3 provincias.

Pero bueno, supongo que estoy un poco cansado de todo esto y quien habla en realidad es el estrés

Yo lo estoy dejando para el final, pero lo haré por mi tranquilidad.
Es una currada para los que programamos y para los operadores pero quiero dormir tranquilo.

[Sistel]

Empezado por sEngine

Es que nosotros generamos ticket (con su numero y fecha) tanto para el momento de la reserva como para los siguientes pagos que se hacen. Entonces eso si que habria que enviarlo, no?

Hola sEngine,

Lo que antiguamente se llamaban "tickets", con el actual Reglamento de Facturación pasaron a llamarse "facturas simplificadas".
Las únicas diferencias de una factura simplificada respecto a una factura completa (la normal) son:
- En el título del documento debe aparecer "FACTURA SIMPLIFICADA" en lugar de "FACTURA".
- No son obligatorios los datos del destinatario (nombre, NIF y domicilio), aunque puede llevarlos
- Deben llevar, obligatoriamente, una serie diferente a la de las facturas normales (con su propia numeración) y fecha
- Su importe total no puede ser mayor de 3.000 € (y en algunos casos específicos no puede ser mayor de 400 €)
- Puede no desglosar base imponible y cuota de IVA en el caso de un solo tipo de IVA y, en ese caso debe incluir la frase "IVA INCLUÍDO"

Tienes un resumen de la normativa aquí

Saludos

[unomasmas]

Empezado por yasmNote

Buenas,
Me está ocurriendo lo mismo con un cliente que está en RE y me dice que factura con un 26,2% (21 + 5,2) esto es posible? o simplemente en la factura hay que informar del 21% porque ya les estás diciendo en el campo "OperacionEnRecargoDeEquivalenciaORegimenSimplificado =’S’ " que tiene recargo de equivalencia no?

Como yo lo he entendido:
a) Cuando el emisor está en RE, al menos normalmente, se informa doblemente este hecho. OperacionEnRecargoDeEquivalenciaORegimenSimplificado=S y ClaveRegimenIvaOpTrascendencia=51. En esta circunstancia no puede facturarse al cliente una cuota de RE y, por tanto, no cabe indicar un 26,2% de impuesto.

b) Si el emisor no está en RE: Entoces sí se puede cargar ese 5,2% adicional de RE al cliente que esté incluido en el ámbito de RE pero OperacionEnRecargoDeEquivalenciaORegimenSimplificado=N y ClaveRegimenIvaOpTrascendencia=01 (o lo que sea, pero no 51).

Al menos, con carácter general. Ten en cuenta que no tengo ni idea de temas fiscales :-(

[unomasmas]

Empezado por Ramon88

Una duda que tengo, cuando analizais el XML comaprado contra el esquema, lo haceis despues de firmarlo ?? si es así y hay un fallo, entiendo que no se puede subir, y que hay que paralizar la facturación o la subida de ficheros hasta que se subsane manualmente entiendo, el error en el xml ?

Si te da error, aunque esté firmado, digamos que es una firma no válida, no se generará código QR porque también sería inválido, etc. y debes parar el proceso: no emitir factura (ni imprimir ni entregar al cliente ni enviar a la Diputación), corregir el problema y volver a firmar. Así lo veo yo.