Garbi,
A nosotros no nos importa pagar por el uso de una libreria que nos pudiera facilitar el trabajo, e incluso si alguien de vosotros nos ofreciera el trabajo hecho, lo consideraríamos, porque como he indicado, a mi (que es a quien le ha caído el marrón de hacerlo) se me hace un mundo, tanto hacer el xml, como la interpretación y que este todo correcto respecto a AEAT (que es lo que más miedo me da). Por que para 3 aplicaciones que necesitamos hacer, tenernos que darnos de alta como desarrolladores y tenerlo todo al 100% con la AEAT me preocupa muchísimo.
No estimado, no.
Nadie te puede hacer lo que realmente necesitas y que es lo complicado, es decir, la integración con tu programa: Es decir, los datos que necesitas enviar y los datos que vas a recibir y debes guardar. Sólo lo puedes hacer tu a no ser que contrates a alguien que coja tu programa y lo adapte.
Es mi opinión con el ánimo de centrar el partido y la jugada.
La generación del .xml es lo de menos. Lo he comentado varias veces.
Hay que ver de ver de donde coger los datos que van a ir al .xml. Algunos pueden necesitar campos nuevos. Es cosa tuya. Recomiendo grabar todos los .xml y todo lo que se envie.
Hay que ver de ver donde se van a grabar los campos de la respuesta parseada y tambien la respuesta con su CSV o como se llame. Tambien guardar el .xml recibido
Basicamente el grueso de nuestro trabajo consiste en generar un API, nuestra API y no existe ninguna otra en el mundo, que interaccione con nuestro programa y el envio y con la respuesta y nuestro programa. Ahí está el quizz gordo de la cuestión.
Que tampoco es para tanto. Teniendo claro lo que hay que hacer, tampoco es para tanto.
Lo de los eventos que comentas de la OM. Hasta ayer los eventos sólo eran para programa no verifactu.
A ver si Victor nos hace el favor de hacernos un resumen cuando haya leído la OM o al menos si ha encontrado alguna novedad novedosa.
Hazte, si lo ves por conveniente, un bosquejo y si quieres nos lo pones aqui y vamos entre todos apuntando cosas