Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Internet
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 19-10-2021
espinete espinete is offline
Miembro
 
Registrado: mar 2009
Posts: 233
Poder: 16
espinete Va camino a la fama
Pregunta tonta sobre el encadenamiento en Bizkaia

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?
Responder Con Cita
  #2  
Antiguo 19-10-2021
adolphsys adolphsys is offline
Miembro
 
Registrado: abr 2006
Posts: 68
Poder: 19
adolphsys Va por buen camino
Cita:
Empezado por espinete Ver Mensaje
Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?
Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.
Responder Con Cita
  #3  
Antiguo 19-10-2021
espinete espinete is offline
Miembro
 
Registrado: mar 2009
Posts: 233
Poder: 16
espinete Va camino a la fama
Cita:
Empezado por adolphsys Ver Mensaje
Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.
Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".
Responder Con Cita
  #4  
Antiguo 19-10-2021
Avatar de keys
keys keys is offline
Miembro
 
Registrado: sep 2003
Ubicación: Bilbao
Posts: 1.035
Poder: 22
keys Va por buen camino
Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

Yo no consigo que me de 017. No se sobre que lo estan aplicando.
Responder Con Cita
  #5  
Antiguo 19-10-2021
Avatar de keys
keys keys is offline
Miembro
 
Registrado: sep 2003
Ubicación: Bilbao
Posts: 1.035
Poder: 22
keys Va por buen camino
Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

Cita:
URL de acceso a la aplicación web de lectura del QR, específica para cada Administración tributaria:
o Araba/Álava: https://ticketbai.araba.eus/TBAI/QRTBAI (sin “/” para el cálculo del CRC).
o Bizkaia: https://batuz.eus/QRTBAI/ (con “/” al final para el cálculo del CRC).
o Gipuzkoa: https://tbai.egoitza.gipuzkoa.eus/qr/ (con “/” al final para el cálculo del CRC).
Responder Con Cita
  #6  
Antiguo 19-10-2021
YellowStone YellowStone is offline
Miembro
 
Registrado: feb 2007
Ubicación: Adeje
Posts: 34
Poder: 0
YellowStone Va por buen camino
Cita:
Empezado por keys Ver Mensaje
Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas:


https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

Pero también falla.
Responder Con Cita
  #7  
Antiguo 20-10-2021
Avatar de keys
keys keys is offline
Miembro
 
Registrado: sep 2003
Ubicación: Bilbao
Posts: 1.035
Poder: 22
keys Va por buen camino
Cita:
Empezado por YellowStone Ver Mensaje
La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas:


https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

Pero también falla.
Ya la direccion ya se que es la que ponéis, pero me refiero por tener en cuenta o no la / para calcular el crc. Que parece que se calcula distinto que en las otras haciendas. Por cierto hoy el propio enlace del ejemplo de la hacienda de ALAVA da error.

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017
Responder Con Cita
  #8  
Antiguo 19-10-2021
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 143
Poder: 4
rci Va por buen camino
Question C# .Net envio TBAI desde un servicio => certificados

Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest


Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor.
Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente.

El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System).

En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío.

Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo:

Código:
    var httpWebRequest = HttpWebRequest.CreateHttp(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(this.certificate);
    httpWebRequest.Method = "POST";
    …
Pues bien, parece que cuando ejecutamos como servicio de windows, como arranca con el usuario system, el HttpWebRequest no tiene acceso al almacén de certificados de los otros usuarios, por ejemplo el usuario con que se inicia sesión en el servidor y donde instalamos el certificado en el navegador.

Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?


Muchas gracias!!
Responder Con Cita
  #9  
Antiguo 19-10-2021
adolphsys adolphsys is offline
Miembro
 
Registrado: abr 2006
Posts: 68
Poder: 19
adolphsys Va por buen camino
Cita:
Empezado por rci Ver Mensaje
Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest


Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor.
Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente.

El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System).

En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío.

Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo:

Código:
    var httpWebRequest = HttpWebRequest.CreateHttp(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(this.certificate);
    httpWebRequest.Method = "POST";
    …
Pues bien, parece que cuando ejecutamos como servicio de windows, como arranca con el usuario system, el HttpWebRequest no tiene acceso al almacén de certificados de los otros usuarios, por ejemplo el usuario con que se inicia sesión en el servidor y donde instalamos el certificado en el navegador.

Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?


Muchas gracias!!
Hola, si nos detallas un poco más el problema tal vez alguien pueda ayudarte:
  • Te refieres a un servicio de Windows puro y duro, o se consume mediante Internet Information Services (IIS)?
  • Se trata de un entorno Terminal Services?
  • Cómo se conectan los usuarios?
  • Cada uno tendrá su propio certificado o utilizan todos el mismo?
Aunque no trabajo en .Net, si el certificado está instalado para el usuario XXX lógicamente no será accesible por el usuario YYY.
Responder Con Cita
  #10  
Antiguo 19-10-2021
hago_preguntas hago_preguntas is offline
Registrado
 
Registrado: oct 2021
Posts: 8
Poder: 0
hago_preguntas Va por buen camino
Cita:
Empezado por keys Ver Mensaje
Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo


Yo no consigo que me de 017. No se sobre que lo estan aplicando.
¿De donde has sacado el ejemplo?

A mí me sale crc=036, calculado sobre el enlace que has puesto quitando &crc=017
Responder Con Cita
  #11  
Antiguo 19-10-2021
adolphsys adolphsys is offline
Miembro
 
Registrado: abr 2006
Posts: 68
Poder: 19
adolphsys Va por buen camino
Cita:
Empezado por espinete Ver Mensaje
Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".
Eso es, ya sabes que al cliente final hay que permitirle seguir facturando haya enviado o no la factura a Hacienda.

A Vizcaya puedes enviar un bloque por ejemplo de 10 facturas, e igual aceptan seis, y cuatro se rechazan, así que tienes que examinar el XML de respuesta y leer el estado de cada factura de forma individualizada.
Responder Con Cita
  #12  
Antiguo 19-10-2021
unomasmas unomasmas is offline
Miembro
 
Registrado: dic 2019
Posts: 112
Poder: 5
unomasmas Va por buen camino
Cita:
Empezado por espinete Ver Mensaje
Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

Una cosa es la generación de la factura (del XML firmado y con QR generado) y otra el envío. Son procesos independientes. Puedes (debes) firmar el XML y generar su correspondiente código QR antes de imprimir (de hecho, lo necesitas para imprimirlo en la factura). Una vez generada puede enviarse inmediatamente o quedarse ahí y enviarla después junto con otras...
Responder Con Cita
  #13  
Antiguo 20-10-2021
espinete espinete is offline
Miembro
 
Registrado: mar 2009
Posts: 233
Poder: 16
espinete Va camino a la fama
Cita:
Empezado por unomasmas Ver Mensaje
Una cosa es la generación de la factura (del XML firmado y con QR generado) y otra el envío. Son procesos independientes. Puedes (debes) firmar el XML y generar su correspondiente código QR antes de imprimir (de hecho, lo necesitas para imprimirlo en la factura). Una vez generada puede enviarse inmediatamente o quedarse ahí y enviarla después junto con otras...
Gracias por la aclaración. Estaba acostumbrado a la factura electrónica de algunos países de Latinoamérica y, como ellos no requieren el "encadenamiento" me estaba liando intentando hacerlo igual con Ticketbai.

No obstante, me surge entonces otra duda... Si la generación y firma del XML hay que hacerla en el momento de hacer la venta (ya que se necesita el QR para imprimirlo en la factura o tícket), PERO el envío puede ser ahora o dentro de unos días... ¿debo entonces guardar en algún sitio el XML firmado, ya que me hará falta para adjuntarlo al XML del envío de facturas, no?

Me refiero a Bizkaia, pero supongo que se aplica también a Gipuzkoa y Araba, ya que pueden ocurrir errores de conexión, etc. y necesitemos hacer los envíos más adelante.

En el envío, sea de la provincia que sea, se necesita el XML firmado de la factura. Si el envío se puede hacer en cualquier otro momento, independientemente de la firma, necesitaré ese XML a posteriori, por lo que en algún sitio habrá que guardarlo, no?

No es un poco locura almacenar los XML de (presumiblemente) miles de facturas, ya sea en archivos sueltos o en la propia base de datos?
Responder Con Cita
  #14  
Antiguo 21-10-2021
unomasmas unomasmas is offline
Miembro
 
Registrado: dic 2019
Posts: 112
Poder: 5
unomasmas Va por buen camino
Cita:
Empezado por espinete Ver Mensaje
Gracias por la aclaración. Estaba acostumbrado a la factura electrónica de algunos países de Latinoamérica y, como ellos no requieren el "encadenamiento" me estaba liando intentando hacerlo igual con Ticketbai.

No obstante, me surge entonces otra duda... Si la generación y firma del XML hay que hacerla en el momento de hacer la venta (ya que se necesita el QR para imprimirlo en la factura o tícket), PERO el envío puede ser ahora o dentro de unos días... ¿debo entonces guardar en algún sitio el XML firmado, ya que me hará falta para adjuntarlo al XML del envío de facturas, no?

Me refiero a Bizkaia, pero supongo que se aplica también a Gipuzkoa y Araba, ya que pueden ocurrir errores de conexión, etc. y necesitemos hacer los envíos más adelante.

En el envío, sea de la provincia que sea, se necesita el XML firmado de la factura. Si el envío se puede hacer en cualquier otro momento, independientemente de la firma, necesitaré ese XML a posteriori, por lo que en algún sitio habrá que guardarlo, no?

No es un poco locura almacenar los XML de (presumiblemente) miles de facturas, ya sea en archivos sueltos o en la propia base de datos?
Pues sí, has de conservarlo no solo hasta que lo envíes sino siempre (al menos, quizás, mientras dure la obligación de conservar las facturas, pienso yo) y en ese sentido sí puede considerarse que es una locura teniendo en cuenta que ya se lo enviaste a ellos...
Responder Con Cita
  #15  
Antiguo 21-10-2021
edari edari is offline
Miembro
 
Registrado: jun 2021
Posts: 178
Poder: 3
edari Va por buen camino
Y en Vizcaya todavía se multiplica el número de fichero a las otras dos Haciendas (1 por factura).



En Vizcaya está


- El xml de la factura firmada (por no hablar del inicial que está sin firmar)
- El xml de la factura firmada convertido a Base64
- el XML resumen (o como se llame) con todas las facturas que vas a subir empaquetadas en Base64
- El fichero comprimido






Yo de momento crearé una carpeta por \empresa\ejercicio\mes y luego una \exporta (para la que subo) y otra \importa (para las respuestas).
Responder Con Cita
  #16  
Antiguo 21-10-2021
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 143
Poder: 4
rci Va por buen camino
Question

Cita:
Empezado por edari Ver Mensaje
Y en Vizcaya todavía se multiplica el número de fichero a las otras dos Haciendas (1 por factura).



En Vizcaya está


- El xml de la factura firmada (por no hablar del inicial que está sin firmar)
- El xml de la factura firmada convertido a Base64
- el XML resumen (o como se llame) con todas las facturas que vas a subir empaquetadas en Base64
- El fichero comprimido






Yo de momento crearé una carpeta por \empresa\ejercicio\mes y luego una \exporta (para la que subo) y otra \importa (para las respuestas).

¿Es necesario guardar todo esto?
Nosotros solamente guardamos el fichero firmado ticketBAI, comprimido dentro de un campo de la base de datos.
Las respuestas no las guardamos, solamente si se ha enviado correctamente o no y el error si es el caso.
Para batuz, a partir del fichero firmado ticketBAI siempre podemos volver a generar los otros...

¿Lo estamos haciendo mal?
Responder Con Cita
  #17  
Antiguo 21-10-2021
Avatar de HerensugeBeltz
HerensugeBeltz HerensugeBeltz is offline
Miembro
 
Registrado: may 2021
Ubicación: Hondarribia
Posts: 88
Poder: 3
HerensugeBeltz Va por buen camino
Cita:
Empezado por rci Ver Mensaje
Nosotros solamente guardamos el fichero firmado ticketBAI, comprimido dentro de un campo de la base de datos.
Esto me suscita una duda que espero me pueda aclarar alguien:
Si se comprime un fichero XML firmado, al descomprimirse, la firma sigue siendo válida?
Gracias.
Responder Con Cita
  #18  
Antiguo 21-10-2021
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.289
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por rci Ver Mensaje
¿Es necesario guardar todo esto?
Nosotros solamente guardamos el fichero firmado ticketBAI, comprimido dentro de un campo de la base de datos.
Las respuestas no las guardamos, solamente si se ha enviado correctamente o no y el error si es el caso.
Para batuz, a partir del fichero firmado ticketBAI siempre podemos volver a generar los otros...
¿Lo estamos haciendo mal?

Creo que lo único necesario es el XML firmado de cada factura (a efectos de inspecciones).
Nosotros tampoco guardamos ni los envíos (BATUZ), ni las respuestas, ni lo generado en pasos intermedios.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice newtron Internet 3557 Hace 1 Semana 17:42:47
Como utilizar la ayuda del nuevo Sistema Operativo gluglu Humor 3 24-09-2007 09:39:05
Aplicacion Agencia De Viajes ArdiIIa Varios 9 20-01-2007 16:49:53
El Vasco Aguirre Al González La Taberna 5 26-05-2006 09:22:28
Microsoft ha lanzado su nuevo sistema operativo DarkByte Humor 0 25-01-2004 09:21:14


La franja horaria es GMT +2. Ahora son las 09:10:28.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi