Empezado por ermendalenda (Mensaje 544329)

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.

Empezado por Galaxian (Mensaje 540583)

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');

Empezado por unomasmas (Mensaje 544263)

Muchas gracias. Eso aclara todo mi problema :-)

Empezado por bilbur (Mensaje 540886)

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

.....

Empezado por AlbertPujol (Mensaje 544385)

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?

Empezado por espinete (Mensaje 544200)

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

Empezado por sEngine (Mensaje 544391)

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

Empezado por espinete (Mensaje 544392)

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 ;)

Empezado por Sistel (Mensaje 544393)

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

Empezado por espinete (Mensaje 544392)

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 ;)

Empezado por sEngine (Mensaje 544396)

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?

Empezado por yasmNote (Mensaje 544382)

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?

Empezado por Ramon88 (Mensaje 544381)

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 ?