FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
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? |
#2
|
|||
|
|||
Cita:
|
#3
|
|||
|
|||
Cita:
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". |
#4
|
||||
|
||||
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. |
#5
|
||||
|
||||
Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.
Cita:
|
#6
|
|||
|
|||
Cita:
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. |
#7
|
||||
|
||||
Cita:
https://pruebas-ticketbai.araba.eus/...2537.70&cr=017 |
#8
|
|||
|
|||
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"; … Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor? Muchas gracias!! |
#9
|
|||
|
|||
Cita:
|
#10
|
|||
|
|||
Cita:
A mí me sale crc=036, calculado sobre el enlace que has puesto quitando &crc=017 |
#11
|
|||
|
|||
Cita:
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. |
#12
|
|||
|
|||
Cita:
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... |
#13
|
|||
|
|||
Cita:
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? |
#14
|
|||
|
|||
Cita:
|
#15
|
|||
|
|||
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). |
#16
|
|||
|
|||
Cita:
¿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? |
#17
|
||||
|
||||
Cita:
Si se comprime un fichero XML firmado, al descomprimirse, la firma sigue siendo válida? Gracias. |
#18
|
||||
|
||||
Cita:
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. |
|
|
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 |
|