Hola Ramon88,

A TicketBAI no le preocupa el tema de cobros o pagos.
Se desentiende de albaranes, recibos, pagos a cuenta y demás documentos intermedios.
Lo único importante para TicketBAI son las facturas.

Y da igual que sean facturas simplificadas o completas.
Mientras no hay factura, no hay nada que concierna a TicketBAI.

Otro tema es que Hacienda se interese si detecta trasiego de dineros sin emisión de facturas (completas o simplificadas, da igual) o que no se facturen suministros de servicios o productos en un cierto plazo de tiempo como mandan las normativas relativas a facturación.

Por supuesto, si no has emitido una factura, tiene poco sentido que la emitas para anularla a continuación.
Se supone que la anulación es un mecanismo muy restringido y sólo para casos en que ha habido errores en la factura ya emitida (o se ha emitido sin tener que hacerlo porque no se ha realizado la transacción).
Para cualquier otro caso de factura emitida, hay que hacer factura rectificativa.

Saludos

Yo entiendo que da lo mismo que declare facturas simplificadas o facturas.
Sinceramente, paso de las facturas rectificativas, me parece un rollo increible. Si una factura da error se supone que no esta subida a hacienda, entonces que la suban de nuevo. La anulación mi idea es subirla para cuando alguien viene con la mercancia y te dice que no la quiere por X motivo. Tienes que devolverle el dinero y crear una anulación, y si la cobré en 3 veces, tengo que crear 3 anulaciones.

Otro tema para los que queráis afinar en fiscalidad, ya que lo que veo venir es que "nuestra hacienda" necesita cash para pagar todo esto del covid,desasttes naturales etc. Es el tema de los autoconsumos, hasta ahora no se metían con cosas pequeñas, si se usa un coche de empresa para uso particular, si te pillas de tu tienda de ropa unos vaqueros, si regalas a los empleados los desayunos que tu produces, etc... . Eso hay que pagar el IVA del costo para que se anule el que te vas a desgravar de las compras. Y ahora van a poder cruzar más fácilmente los datos y además de que usan inteligencia artificial.

Hola Ramon88,

Efectivamente, da lo mismo que las facturas sean simplificadas o completas. Son facturas y punto pelota.
La única ventaja es que las facturas simplificadas pueden ir sin datos del destinatario y sin desglosar IVA, sólo con el texto "IVA incluído").
Aunque si el destinatario lo solicita (por ejemplo, para deducirse gastos) también pueden ir sus datos (en ese caso se llama factura simplificada cualificada y debe tener el desglose de IVAs).
Pero, a cambio, de su simplicidad, las facturas simplificadas tienen un límite de 400€ (para ventas al por menor y algunos otros servicios hasta 3.000€)

La factura está emitida desde el momento en que creas el XML y lo firmas, independientemente de que la imprimas o no y de que la envíes o no a Hacienda.
Recuerda que además las facturas van encadenadas unas a otras porque cada una lleva parte de la firma de la anterior. No se pueden borrar ni saltar.
Ojo: En Gipuzkoa y Álava cada factura emitida deben enviarse nada más emitirse. Y si te retrasas en su envío, Hacienda después puede pedirte explicaciones de por qué has tardado (tienen la fecha, hora, minuto y segundo de su emisión y firma).

Te aconsejo que consultes con un asesor el tema de los cobros anticipados sin emisión de factura (plazos, importes, documentación, ...)
Hacienda lo ve todo ... y cada día más.

Saludos

Yo creo que se refiere a dar margen al usuario. Mientras no la haya imprimido es una factura que no existe. En su sistema puede hacer lo que quiera con ella; incluso borrarla (borrar el registro) porque técnicamente no se ha emitido ¿no? y, por tanto, no puede haber delito :o

O tres rectificativas. No creo que a Hacienda le importe una cosa u otra. A fin de cuentas, el resultado es el mismo ¿no?

Me apuré al responder y es una respuesta "torpe". Me quedo con la explicación de Sistel

Hola unomasmas,

No estoy muy de acuerdo en que se pueda hacer lo que se quiera en su sistema.
Ahora ya no.
Mañana, 11 de octubre de 2021 entra en vigor la nueva Ley General Tributaria:
https://www.agenciatributaria.es/AEA...mentario.shtml
Ya no se pueden tener softwares con doble contabilidad o contabilidad "B".
Tampoco la alteración o borrado de registros de temas contables.

Y, por supuesto, para hacer cumplir la Ley, Hacienda necesitará ejecutar acciones ejemplarizantes contra alguna empresa o negocio (y sus informáticos responsables de dicho software).
Ya no se lleva lo de quemar en la plaza pública, pero seguro que habrá castigos ejemplares a los que se dará bombo y platillo en la prensa para sembrar el pánico de los posibles infractores.

Hay que estar preparado para ello.
Yo no me fió lo más mínimo de Hacienda, pero tampoco de los clientes "listillos" que siempre buscarán manipular el software o los registros de facturas a su favor.
Por eso mi servicio de TicketBAI es online y sin que los clientes puedan tocar nada del software ni alterar las facturas, porque están en un servidor mío al que no tienen acceso.
Toda medida de seguridad, en ese sentido, me parece poca.

Saludos

Duda con los encadenamientos...
 

Buenos días...

Estoy intentando enviar a Álava y me devuelve...

Factura a dar de alta o subsanar ya registrada en el sistema.

El problema es que no soy consciente de haber enviado nada nunca a Álava. No sé cómo es posible que ya exista esa factura registrada.

Pero pongamos que sí, que la envié hace meses y milagrosamente se envió sin ningún problema (cosa que dudo porque hasta hace unos días no conseguí enviar nunca a Gipuzkoa),

¿Qué se hace en este caso si no hay manera de consultar las facturas ya registradas? Si fuera posible consultar facturas (como Bizkaia), podría saber si realmente llegué a enviar esas facturas y qué firma tenía, para poder continuar con los envíos.
Pero si no... ¿cómo sé qué facturas he enviado y cómo obtengo la firma de la anterior?

El problema es que si pruebo a enviar la siguiente, me devuelve:

AVISO: Falta dato o el dato es erróneo [Firma Factura Anterior]

Que obviamente no tengo, porque en ningún sitio me consta como enviada.

¿No existe ningún servicio online para ver las facturas enviadas en el entorno de pruebas? No solo con Araba sino con Gipuzkoa, ya que estamos?

Para confirmarlo, prueba a enviar indicando una serie "rara" de forma que seguro no hayas enviado nada con ella.

Hola...

Ya he conseguido enviarlas cambiando la serie. Así me aseguro de que estoy empezando de "cero" y ya puedo registrar en la base de datos las que están enviadas y las que dio error.

Supongo que los errores/avisos tipo "AVISO: NIF emisor no es correcto, no es contribuyente alavés o no está registrado en IAE" son normales, al estar usando NIFs de prueba, y que podemos ignorarlos sin problema.

Por cierto... puedo enviar a Álava sin ningún problema usando NetHTTPClient y el mismo código que NO me funcionaba con Gipuzkoa. Sigue siendo un misterio.
Con Gipuzkoa solo puedo enviar usando idhttp, lo cual me supone un problema ya que idhttp no permite firmar la petición usando los certificados del almacén de certificados. Solo con los archivos directamente.

A ver si descubro algo usando Fiddler, etc.

Os pongo una respuesta que me ha enviada Álava esta mañana, con información:

En estos momento estamos en fase de desarrollo de la Consulta QR cono la de una aplicación web para la consulta de emisores desde la cual podréis consultar la información suministrada y también .

En cuanto se encuentre disponible, lo comunicaremos a través de nuestra página web donde publicaremos la URL correspondiente a dicha consulta en el entorno de Pruebas https://web.araba.eus/es/hacienda/ticketbai

No obstante lo anterior, esperamos tenerlo disponible a lo largo de las próximas semanas.

Y por último, en relación al encadenamiento, tenéis que indicar la última que se envió al sistema, aunque sea de otra serie.

La última parte hace referencia a una duda sobre qué encadenamiento utilizar cuando enviemos una factura de una serie (por ejemplo, B), aunque la factura anterior enviada haya sido de la seria "A".

Es decir, si el cliente tiene dos series de facturación, A y B, con numeraciones distintas, y se envía una factura de la A, luego otra de la B, y luego otra de la A... el encadenamiento tiene que indicar la última factura que se envió, aunque sea de otra serie.

Tenía esa duda y me respondieron, así que lo dejo por aquí por si a alguien más le quita el sueño.

¿Podría servir el servicio de consulta a través del código QR? En Álava: https://ticketbai.araba.eus/TBAI/QRTBAI

Hola a todos.

Que sepais que Bizkaia a puesto en marcha los servidores de producción. Como era de esperar sólo las empresas que estén dadas de alta en bizkaia como contribuyentes pueden enviar. :eek:

No me funciona esa URL, no sé si es temporal, si nunca ha funcionado o si estoy generando mal la URL.

Con Gipuzkoa tampoco me funciona. Siempre me devuelve "No se ha podido determinar el estado de la factura" :confused:

Mensaje de Bizkia de ahora mismo
 

Kaixo,

Zuekin harremanetan jartzen gara jakinarazteko jada irekita dagoela EEELren esparru erreala proba modura. Helburu bikoitza dauka: batetik, zergadunak sistema berriarekin ohitzea; bestetik, softwarea garatzen duten enpresek probak egin ahal izatea sarrera masiboen zerbitzuaren esparru errealaren gainean. Edonola ere, aldi horretan egiten diren oharrak proba gisa erregistratuko dira, eta ez dute zergetan transzendentziarik izango.

Esparru hori 2021eko abenduaren 10ean itxiko da.

Esparru horri buruzko informazio zehatza Batuzen webgunean argitaratuta dago (www.batuz.eus).

Os escribimos para informaros de que ya está abierto el entorno real del LROE en modo pruebas, con el doble objetivo de que, por un lado, las personas contribuyentes se familiaricen con el nuevo sistema, y, por otro lado, las empresas desarrolladoras de software puedan realizar pruebas sobre el entorno real del servicio de entradas masivas. En todo caso, las anotaciones que se realicen durante este periodo se registrarán a modo de prueba y no tendrán trascendencia tributaria.

Este entorno se cerrará el 10 de diciembre de 2021.

La información detallada de este entorno está publicada en la web de Batuz (www.batuz.eus).
Agur bat.

Dado que usas los componentes SecureBlackBox 2020, no sería más sencillo usarlos también para el envío?
Ejemplo en C++ Builder:

Bueno, pues esta mañana muy amablemente me han llamado desde Hacienda de gipuzkoa, dudas resueltas, generaré facturas simplificadas y ellos quieren rectificativas, pero yo cuando anulo una venta es por que la operación no se lleva a cabo, por lo que puedo generar anulación.

Alava creo que es igual que gipuzkoa por que he probado a enviar y me funciona todo, lo único que no he probado es el QR pero ya vi que tenia algun cambio.

Ahora voy con Bizkaia, y me están entrando tics nerviosos viendo la documentación, esto no tiene nada que ver a las demás?
Alguien puede resumirme un poco? no entiendo nada...

Tengo que generar facturas xml como siempre, y cada cuanto tengo que subirlas comprimidas? y la compresion va en 7z ? donde puedo ver toda esta info? es que he visto en este enlace mucha información, pero son mas de 1000 hojas en total.
https://www.batuz.eus/es/documentacion-tecnica#LROE


Un saludo,

El documento que más te puede servir es este.
Al final, tal y como dices, tienes que generar el fichero de TicketBAI igual que para Guipuzkoa, ese fichero va dentro de un XML, eso lo comprimes y lo envías utilizando una cabecera con varios campos tipo campo/valor.

En el primer mensaje de este hilo tienes bastante información.
Y en este hilo enlaces con referencias a los pasos más importantes.

Ojo con tipo de letra del Identificador TBAI
 

TBAI-A22222222-131021-lIk4jJXpKKzEE-041

TBAI-A22222222-131021-lIk4jJXpKKzEE-041


Aqui os dejo un pequeño problema que os puede volver locos y dar algún problema con el identificador TBAI al leerlo y copiarlo manualmente o que alguien lo malinterprete y tengais un lio:

Se ven iguales si usas para imprimir por ejemplo;
Tipo de letra System letra ele minúscula > "l" letra i mayúscula >"I"
Tipo de letra Arial letra ele minúscula > "l" letra i mayúscula >"I"

Ok, por ejemplo:
Tipo de letra Verdana letra ele minúscula > "l" letra i mayúscula >"I"



Saludos


Por ejemplo la web de comprobacion de QR de BIZKAIA tiene ese "problemilla"

¿Alguien puede decirme qué ha pasado con los envíos a Bizkaia últimamente? Tras terminar por fin Gipuzkoa y Araba, he vuelto a probar envíos con Bizkaia (antes funcionaba, tanto enviar como anular y consultar) y ahora ya no puedo enviar:

Error sending data: no se pudo resolver el nombre del servidor o su dirección.

Estoy enviando (obviamente en modo pruebas) a _tps :// pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena

Enviaron un email avisando de que ese entorno de pruebas lo deshabilitaban, y que, hasta el 10 de diciembre, se podra utilizar su entorno real en modo de pruebas. Es la misma URL, pero sin el "prue" delante, o sea, sarrerak.bizkaia....

Pego toda la info que enviaron en castellano:

Esto otro lo enviaron ya hace tiempo:

Pues hace ya tiempo anunciaron cambios y cierre en los servidores:
https://www.clubdelphi.com/foros/sho...postcount=1721


Y esta semana han avisado de que los han vuelto a poner en marcha (a medias y con cambios):
https://www.clubdelphi.com/foros/sho...postcount=1855

xml de ticketbai en primera factura. Si no hay anterior
 

Estoy teniendo problemas para el envío en caso de ser la primera factura. Sé que en este caso no es necesario enviar la huella TBAI, pero aun así, la validación me da error porque me pide los elementos XML propios de la Huella TBAI. Entonces, ¿alguien tiene claro qué elementos no se envían este caso, o si se envían, con qué valores??

En ese caso no mandes los campos de encadenamiento
<HuellaTBAI>
<Software>
<LicenciaTBAI>TBAIPRUEBA</LicenciaTBAI>

<EntidadDesarrolladora>
<NIF>Axxxxxxxxxz</NIF>

</EntidadDesarrolladora>


<Nombre>nombprograma</Nombre>

<Version>1.0.2626</Version>

</Software>


<NumSerieDispositivo>GuCF4BB2E79CA</NumSerieDispositivo>

</HuellaTBAI>

Y si no vas a meter numero de serie de dispositivo creo que tampoco hay que mandar el campo vacio, los de licencia y demas si hacen falta

Buenas a todos/as, primero de todo agradecer toda la ayuda que habéis aportado en este foro respecto a TicketBai ( podría decir lo mismo del SII la verdad :) )

Por otra parte, soy el único que la falla la validación de firma en el entorno de pruebas de Gipuzkoa? Hasta hace unos días me iba perfecto,y ahora la respuesta es 'Recibida' pero en Resultados de validación me da un error 008 y luego me pone el típico error de Java con un montón de lineas....(tipo así org.apache.axis.InternalException: org.apache.axis.ConfigurationException: java.lang.NullPointerException java.lang.NullPointerException at org.eclipse.osgi.internal.loader.BundleLoader.findResource(BundleLoader.java:585) at org.eclipse.osgi.internal.loader.BundleLoader.findResource.. .etc)

Gracias

En ese caso, si omito todo el bloque <EncadenamientoFacturaAnterior>, el error que obtengo es este:

Asi es como queda el bloque HuellaTBAI que no acepta:

Te faltan datos de la cabecera de factura

Hace unos días se publicó el mismo problema (página 80 o por ahí). Entiendo que las excepciones las genera el servicio, así que supongo que sólo en Gipuzkoa sepan explicar la razón.

Memoria registro
 

Ando a varios frentes... :-(. Todavía no tengo ni medio listo Bizkaia, pero estoy pensando ya en la memoria para solicitar la inscripción. No sé por dónde empezar a darle bocao. ¿Alguien amable la ha hecho? ¿Puede pasar una plantilla con los puntos a acometer? Gracias.

En Álava creo que efectivamente todavía no tienen activo ese servicio pero en Gipuzkoa a mi sí me funciona bien. ¿En qué estás programando?. Mi método está en C#; por si te pudiera servir, está aquí: https://www.clubdelphi.com/foros/sho...434#post543434

Qué ocurre si hay un fallo y no se pueden generar ficheros TBAI durante unas horas?
 

Hola

Supongamos el caso que nuestro programa en algún momento tiene un problema para generar el fichero XML TicketBAI, por lo que sea, que el certificado está mal o que hay un error interno del programa que impide generar el fichero XML.
Tal como tenemos desarrollado el programa, si no se puede generar el fichero TicketBAI, no se puede salvar la factura ni imprimirla. Por lo tanto la tienda que utiliza nuestro programa, si ocurre algún problema de este tipo, tiene que dejar de vender porque no puede hacer facturas.
En una tienda grande con muchos TPVs y mucha clientela esto no es aceptable, no pueden dejar de trabajar.
Mientras no podamos solucionar el problema, ya sea del certificado o arreglando el programa... pueden pasar horas.:eek:

¿Cómo podemos gestionar en este caso? :confused:



Si desactivamos temporalmente TicketBAI para que puedan vender y facturar, las facturas que hagan en ése período no estarán firmadas y no tendran el QR y no se enviarán. Esto no es posible tampoco...



Es un tema que nos preocupa mucho. A ver como lo haceis vosotros.


Muchas gracias

Permite que sigan facturando, pero al final del día, que entren a un apartado donde diga consulta TicketBai y donde vean si la factura esta "recibida", "sin subir"....etc, y permite que puedan subir todas las facturas que aparecen en modo "sin subir" en su orden lógico. No se, yo creo que haré algo así.

Gracias Ramon88, si falla el envio no es el problema, el problema es si no se firman.

Comunicado Araba
 

Esto me han enviado por email

Buenos días,

Nos dirigimos a usted como participante del período de pruebas del sistema TicketBai en Álava para informarle de lo siguiente:

• Por motivos técnicos, el próximo Martes 19 de Octubre desde las 07:30 de la mañana el entorno de pruebas de TicketBai Álava no estará disponible. En el momento en que vuelva a estar disponible le informaremos por este mismo medio.

• Así mismo les informamos que una vez restaurado el sistema estará disponible la web de verificación de QR del entorno de pruebas. La información al respecto se encontrará en el apartado Ticketbai de la web de la Diputación Foral de Álava en el apartado “Guía de entorno de pruebas TicketBai”.
Un saludo y disculpen las molestias.

Hay muchos casos distintos.
Para dormir tranquilo lo principal es que tecnicamente reduzcas riesgos, el problema que esta parte es la que mas curro puede tener.
1º) la cola de Firmas y envios. Tiene cierta complejidad por que hay que tener en cuenta todos los tiquets y facturas emitidas cronologicamente y un control de firmados/enviados.

2º)Por otra parte primero que yo haria es tener automatizado al menos 2 métodos de firma distintos, yo por ejemplo tengo 1 servidor phpp en local otro php en remoto y por útlimo, si fallan los 2, el autofirma que aunque más lento funciona bien, con lo cual es bastante improbable que se dé la situación que comentas (exceptuando caducidad del certificado)

Si ocurre que una factura no se firma por que se haya bloqueado justo el tpv en la firma o por cualquier causa, no debes firmar las demás

No se pueden imprimir facturas sin el QR, y si no están firmados no hay QR.



Imaginate que se vaya la luz del negocio, debes informar de inmediato por correo electronico a la agencia de la comunidad que pertenezca por ejemplo :

[email protected]

• Su identificación: Indicando su nombre o razón social y NIF/CIF.
• Causa que motiva la incidencia.
• En el asunto del correo electrónica se deberá indicar que se trata de una incidencia enumerada en el artículo 17.

y debes tener preparado un documento para los vendedores (con una serie especifica), vamos lo que viene a ser las libretas de facturas antiguas de toda la vida pero con una indicacion del motivo (una expresion), puedes tener alguna preparara de los motivos posibles, corte de luz, averia servidor, averia Tpv. Darle esa "factura" a los clientes y la tienda se quedan copia, que deben introducirla de manera correlativa en cuanto se solucione la incidencia y por supuesto si la imprimes es "DUPLICADO" o "COPIA" y volver a informar por correo que incidencia solucionada...

En resumen, contestando especificamente solo al supuesto que preguntas, no metas nada en el tpv, ten preparada libretas de facturas con la inscripcion de la causa (para que no tengan que escribirla)
Se me ocurre tener preparado el tpv que pueda sacar de la misma forma (en otra serie) esa factura despues de informar a la agencia tributaria, pero hay cierta ambiguedad, según el alma de la ley sobre evitar doble contabilidad) que no cuadra.

La verdad que yo veo muy poco probable que haya algun problema en la firma...
En latino america tengo un servicio parecido y el problema nunca está en la firma si no en su propio servidor...
El único fallo de firma que puede aver es que este caducado el certificado, y para esto, podrías instalarlo y comprobarlo, aun que yo perferia no instalarlo por experiencia.

Puedes comprobarlo, por ejemplo, abrir el XML firmado o firmando alguno manualmente y abrirlo con el autofirma, cambiando/agregando la extension a xsig. el software te dira si es firma caducada

Reglamento TicketBai
 

https://www.gipuzkoa.eus/documents/2...3-b2aa06f899a5
Sección 5.ª Incidencias en el cumplimiento de la obligación TicketBAI.
Artículo 17. Incidencias de carácter técnico en el cumplimiento
de la obligación TicketBAI.
1.En los supuestos excepcionales de interrupción del servicio eléctrico, de destrucción, fallo,
avería, rotura u otras circunstancias en las que el contribuyente no pueda generar ficheros
TicketBAI ni expedir factura o justificante empleando el software TicketBAI, y éstas deban ser
expedidas en el momento de realizarse la operación, dicha circunstancia se notificará a la
Administración tributaria y el contribuyente expedirá y entregará factura o justificante en papel a
la persona o entidad destinataria, conservando copia del mismo.
La factura o justificante se consignará en una serie específica que se destinará únicamente a las
facturas o justificantes expedidas en virtud de lo dispuesto en este artículo, y contendrá la
expresión «factura o justificante expedida según lo dispuesto en el artículo 17 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral .../../2020>>
2.El contribuyente, tan pronto desaparezca el motivo que imposibilite la generación de ficheros
TicketBAI y la expedición de factura o justificante empleando el software TicketBAI, deberá
introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas o
justificantes expedidas, generando los ficheros TicketBAI y enviándolos a la Administración
tributaria. La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado
En cualquier caso, la persona o entidad destinataria de la operación podrá solicitar
un duplicado de la factura o justificante emitido, que contemple el código TicketBAI y el código QR.
3.
En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio
telefónico o telemático, avería del sistema de envío u otras c
ircunstancias en las que el
contribuyente pueda generar ficheros TicketBAI, pero no pueda enviarlos a la Administración
tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI
generados y procederá a su envío tan pronto se re
establezca la conexión.


Yo dejaria un campo en la factura temmporal emitida para apuntar el correo de la persona que necesite la factura con el QR

Dios Bizkaia pone las cosas facilitas por lo que veo!


Estoy serializando el JSON, pero hay algo que no entiendo, el modelo 140/240 esto son temas contables, que tiene que ver con la factura? no entiendo nada...


Sabeis si puedo hacer lo mismo que con las demas haciendas, es decir:
1- Venta = Genero XML
2- Firmo XML y Comprimo en GZIP
3- Subo XML
*y volvemos a empezar...


Aqui cambia algo mas?

En Vizcaya,creo por lo que entiendo, tienes que subir no un fichero xml con cada factura si no un fichero "resumen" con las facturas que quieras subir, pasadas a base64 y cada factura "incluida" dentro del campo <TicketBai> de este ejemplo



https://www.batuz.eus/fitxategiak/ba..._B00000034.xml


Este es el fichero que creo que hay que subir y comprimir...pero ya te digo que con Vizcaya soy igual de profano que tú...


Y aprovecho para preguntar mi duda


Tengo claro que Alava y Guipuzcoa se suben factura a factura cada xml por separado en el momento de generar la factura. Y no hay que discutir.



Por contra Vizcaya funciona un poco como el SII, es decir, es al final de día, o mejor dicho hay un plazo de tiempo (¿3-4 días?) en el que debes subir todas las facturas generadas días atras.


Entiendo que el proceso que tengo que hacer es (en Vizcaya, modelo 240)



1) Al imprimir las facturas, genero el XML
2) Firmo el XML y dejo el fichero ahí


No subo nada de manera "automática" y luego desde un proceso en el que el usuario selecciona las facturas que quiere/tiene que subir


1) Seleccionas las facturas que tiene pendientes para subir
2) busco cada XML firmado que generé en su día (que esperemos que siga estando en su sitio y que nadie lo haya borrado :eek: ) que ha elegido el usuairo
3) Paso todas las facturas en ese momento a Base64

4) genero el fichero que le he puesto a mi compi Ramon88
5) Y lo subo


Sería así el proceso lógico??


Alava y Guipuzcoa tienen menos "riesgo" porque en medio miunuto tienes cada factura impresa, generada en xml, firmada y subida y ya no hay más que hacer...ya no puede meter la mano el usuario pero en Vizcaya me da mucho más miedo que puede pasar con esos ficheros. :confused:


Me dan ganas, fíjate, de hacer todo el proceso de subida a la vez de imprimir todas las facturas como en Alava y Guipuzcoa pero no tengo claro que es mejor...


p.d.
Odio a los vizcaínos


Firmado
Un vizcaíno