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

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

Empezado por keys

El certificado le he puesto uno nuestro y le pasa lo mismo. Por algún motivo no puede acceder a la clave privada de los certificados.

No se si es lo mismo (no creo, pero por si acaso), pero si son certificados que están instalados en la máquina (no como usuario local), hay problemas al acceder a ellos.
Necesitas elevación de permisos.

[Ramon88]

Sigo con el error y ellos sin contestar, creo que no soy el único que está con el error 400.
Subo las cabeceras por si veis algo raro, no se por donde tirar la verdad.


He visto que el Json esta bien formado, lo armo con una funcion de .Net que lo hace solo.

Código SQL [-]
{
Accept-Encoding: gzip
Content-Encoding: gzip
eus-bizkaia-n3-version: 1.0
eus-bizkaia-n3-content-type: application/xml
Encoding: gzip
Content-Type: application/octet-stream; charset=utf-8
eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":[{"nif":"A99800237","nrs":"GLe7VAi7qZ","ap1":"PuWn2yvAaQ","ap2":"BjvRzNGZq5"}],"drs":[{"mode":"140","ejer":"2021"}]}
}

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

Modifico los parámetros que has enviado para iguarlarlos con los mios:

Código PHP:

Accept-Encoding:gzip
Content-Encoding:gzip
eus-bizkaia-n3-version: 1.0
eus-bizkaia-n3-content-type: application/xml
eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":[{"nif":"A99800237","nrs":"GLe7VAi7qZ","ap1":"PuWn2yvAaQ","ap2":"BjvRzNGZq5"}],"drs":[{"mode":"140","ejer":"2021"}]}
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/octet-stream 


Las llaves no se porque aparecen en tus parámetros, porque el conjunto no es un único parámetro, sino que son diferentes parámetros como HEADERS. Uno de ellos sí es un JSON.
¿No lo estarás enviando todo como un único JSON?

[Ramon88]

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

Modifico los parámetros que has enviado para iguarlarlos con los mios:

Código PHP:

Accept-Encoding:gzip
Content-Encoding:gzip
eus-bizkaia-n3-version: 1.0
eus-bizkaia-n3-content-type: application/xml
eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":[{"nif":"A99800237","nrs":"GLe7VAi7qZ","ap1":"PuWn2yvAaQ","ap2":"BjvRzNGZq5"}],"drs":[{"mode":"140","ejer":"2021"}]}
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/octet-stream 


Las llaves no se porque aparecen en tus parámetros, porque el conjunto no es un único parámetro, sino que son diferentes parámetros como HEADERS. Uno de ellos sí es un JSON.
¿No lo estarás enviando todo como un único JSON?

No, lo que pasa que lo he cogido desde el debug y sale así, pero eso esta bien.
Lo que veo distinto es el orden y lo de Accept... voy a ver si me tomo un cafe y sigo probando!

[Ramon88]

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

Modifico los parámetros que has enviado para iguarlarlos con los mios:

Código PHP:

Accept-Encoding:gzip
Content-Encoding:gzip
eus-bizkaia-n3-version: 1.0
eus-bizkaia-n3-content-type: application/xml
eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":[{"nif":"A99800237","nrs":"GLe7VAi7qZ","ap1":"PuWn2yvAaQ","ap2":"BjvRzNGZq5"}],"drs":[{"mode":"140","ejer":"2021"}]}
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/octet-stream 


Las llaves no se porque aparecen en tus parámetros, porque el conjunto no es un único parámetro, sino que son diferentes parámetros como HEADERS. Uno de ellos sí es un JSON.
¿No lo estarás enviando todo como un único JSON?

Si pongo la cabacera Accept me da error:
El encabezado 'Accept' se debe modificar con la propiedad o metodo adecuados.

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

Nosotros los añadimos así:

Código Delphi [-]
// Estas dos son como propiedades del componente
CompEnvioRESTClient.Accept := 'application/json, text/plain; q=0.9, text/html;q=0.8,';
CompEnvioRESTClient.AcceptCharset := 'utf-8, *;q=0.8';
// El resto como headers
CompEnvioRESTClient.AddParameter('Accept-Encoding', 'gzip', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('Content-Encoding', 'gzip', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('Content-Type', 'application/octet-stream', pkHTTPHEADER, [poDoNotEncode]);
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-version', '1.0', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-content-type', 'application/xml', pkHTTPHEADER, [poDoNotEncode] );
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-data', JSON, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]);

Y es resultado es este:

Código Delphi [-]
Accept-Encoding=gzip
Content-Encoding=gzip
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": "_CIF_","nrs": "_RAZON_SOCIAL_"},"drs":{"mode": "240","ejer": "2021"}}

[Ramon88]

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

Nosotros los añadimos así:
Código Delphi [-]// Estas dos son como propiedades del componente CompEnvioRESTClient.Accept := 'application/json, text/plain; q=0.9, text/html;q=0.8,'; CompEnvioRESTClient.AcceptCharset := 'utf-8, *;q=0.8'; // El resto como headers CompEnvioRESTClient.AddParameter('Accept-Encoding', 'gzip', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('Content-Encoding', 'gzip', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('Content-Type', 'application/octet-stream', pkHTTPHEADER, [poDoNotEncode]); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-version', '1.0', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-content-type', 'application/xml', pkHTTPHEADER, [poDoNotEncode] ); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-data', JSON, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]);



Y es resultado es este:
Código Delphi [-]Accept-Encoding=gzip Content-Encoding=gzip 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": "_CIF_","nrs": "_RAZON_SOCIAL_"},"drs":{"mode": "240","ejer": "2021"}}

Según me han contestado, el problema lo tengo en los [] en el Json. Voy a ver si puedo quitarlos y lo pruebo.


Una duda que tengo, cuando subo una anulación, esta no lleva consecutivo, entonces la siguiente factura que subes, tiene que hacer referencia a alguna factura? a la anterior de la anulación?

[Sistel]

Empezado por Ramon88

Según me han contestado, el problema lo tengo en los [] en el Json. Voy a ver si puedo quitarlos y lo pruebo.
Una duda que tengo, cuando subo una anulación, esta no lleva consecutivo, entonces la siguiente factura que subes, tiene que hacer referencia a alguna factura? a la anterior de la anulación?

Hola Ramon88,

Mi opinión:
La referencia de una nueva factura debe ser a la factura anterior, esté o no anulada.
La anulación sólo es un estado fiscal para que Hacienda no considere sus importes a efectos IVA, IRPF, IS, etc.
Pero una factura anulada es una factura válida para TicketBAI con su serie, número, fecha y firma como las demás.
Aparte de que una factura puede anularse en cualquier momento, aunque haya otras posteriores.

Se admiten opiniones alternativas.

Saludos

[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.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

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

Un saludo

[ermendalenda]

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.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

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

Un saludo

Buen caso. Gracias. Esperamos la respuesta.

[Sistel]

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.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

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

Un saludo

Hola espinete,

Yo también espero ansioso la respuesta que te den porque es un tema que me interesa (y también a mis clientes) muchísimo.
Gracias.

Saludos

[ermendalenda]

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.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

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

Un saludo

De todas formas los temas de facturación, no ticketbai, si quieres una Respuesta rápida, tiene que ser consulta telefónic, y pasa a ser una respuesta sin validez oficial.
Si quieres esperar a la escrita te va a tardar varios meses, eso me dijeron en una consulta a la Aeat.

[adolphsys]

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.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

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

Un saludo

Hola espinete, no esperes gran cosa en cuanto a la respuesta de ninguna Hacienda, cuando yo les he planteado algo similar me han contestado lo siguiente:

Kaixo,

En primer lugar, disculpas por el retraso en contestar.
En cuanto a las cuestiones planteadas, responder que Batuz y TicketBai no modifican ni la normativa de IVA ni el reglamento de facturación. Por tanto, los casos en que se puede emitir una factura rectificativa son los mismos que hasta ahora, y serían casos diferentes en los que se permite la anulación de una operación. Recomendamos ver las preguntas frecuentes 19, 20 y 54 en la web https://www.batuz.eus/es/preguntas-frecuentes
Sobre la forma de emitir una factura rectificativa, se dan dos opciones: por diferencias o por sustitución. Recomendamos ver las preguntas frecuentes 45 y 47 a 54.
También quisiéremos explicar el proceso de funcionamiento de TicketBai y de Batuz, para aclarar que la emisión de una factura, rectificativa o no, no está vinculado a la remisión y a la aceptación o no del envío por Hacienda (no está vinculado a que esté subida y aceptada).
...
bla, bla, bla... no pongo más por no aburrir a la audiencia...


Conclusión (en mi modesta opinión): Dado que el reglamento de facturación español es del año 2012, y si hasta ahora se hacían abonos (facturas en negativo) para hacer una devolución y Hacienda no se ha metido para nada con usted, siga haciéndolo.

Saludos,

[ermendalenda]

Empezado por adolphsys

Hola espinete, no esperes gran cosa en cuanto a la respuesta de ninguna Hacienda, cuando yo les he planteado algo similar me han contestado lo siguiente:

Kaixo,

En primer lugar, disculpas por el retraso en contestar.
En cuanto a las cuestiones planteadas, responder que Batuz y TicketBai no modifican ni la normativa de IVA ni el reglamento de facturación. Por tanto, los casos en que se puede emitir una factura rectificativa son los mismos que hasta ahora, y serían casos diferentes en los que se permite la anulación de una operación. Recomendamos ver las preguntas frecuentes 19, 20 y 54 en la web https://www.batuz.eus/es/preguntas-frecuentes
Sobre la forma de emitir una factura rectificativa, se dan dos opciones: por diferencias o por sustitución. Recomendamos ver las preguntas frecuentes 45 y 47 a 54.
También quisiéremos explicar el proceso de funcionamiento de TicketBai y de Batuz, para aclarar que la emisión de una factura, rectificativa o no, no está vinculado a la remisión y a la aceptación o no del envío por Hacienda (no está vinculado a que esté subida y aceptada).
...
bla, bla, bla... no pongo más por no aburrir a la audiencia...


Conclusión (en mi modesta opinión): Dado que el reglamento de facturación español es del año 2012, y si hasta ahora se hacían abonos (facturas en negativo) para hacer una devolución y Hacienda no se ha metido para nada con usted, siga haciéndolo.

Saludos,

Yo lo veo un pelin arriesgado.
Antes de ticketbai, para comprobarlo tenían que levantar inspección, ahora lo tienen a huevo, primero comprueban y a raíz de los datos mandan la inspección, van a tener muy fácil automatizar las inspecciones, me imagino por la mañana un correo automatizado(o una aplicación portable en L que les informe de las inspecciones del día y la ruta a seguir) a los inspectores de zonas por el boot de ticketbai que repasa los datos que no están según normativa. Fácil de hacer y muchos ingresos a las arcas.

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

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

[keys]

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

No se si es lo mismo (no creo, pero por si acaso), pero si son certificados que están instalados en la máquina (no como usuario local), hay problemas al acceder a ellos.
Necesitas elevación de permisos.

Hola a todos.

Ejecutando como administrador pasa lo mismo.

Haciendo pruebas tontas he visto que si lo ejecuto desde un programa de pruebas (.exe) funciona correctamente, pero desde una dll que es donde lo tenemos todo metido no. He copiado todo a una carpeta nueva y FUNCIONA, es decir copio y pego toda la carpeta del programa y funciona bien desde una dll.

Magia

[ermendalenda]

Empezado por keys

Hola a todos.

Ejecutando como administrador pasa lo mismo.

Haciendo pruebas tontas he visto que si lo ejecuto desde un programa de pruebas (.exe) funciona correctamente, pero desde una dll que es donde lo tenemos todo metido no. He copiado todo a una carpeta nueva y FUNCIONA, es decir copio y pego toda la carpeta del programa y funciona bien desde una dll.

Magia

Comprueba Sí la dll es win32 o win64, si es win32 y el sistema es de 64 seguramente tengas que meter la dll en windows\syswow64 en vez de system32 y registra lo allí como administrador con regsvr32.exe

[keys]

Empezado por ermendalenda

Comprueba Sí la dll es win32 o win64, si es win32 y el sistema es de 64 seguramente tengas que meter la dll en windows\syswow64 en vez de system32 y registra lo allí como administrador con regsvr32.exe

La dll es la misma tanto en una carpeta como en otra, lo único que hago es copiar todo el programa de una carpeta a otra y funciona. Algo ha pasado con los permisos en la carpeta original.

Además no las puedo registrar por que no son registrables. Al final me vale con moverle el programa a otra carpeta.