paquitohm wrote:
Un monton de horas le he echado yo al xmlspy sin poder sacar un xml completo de ejemplo. Le he hecho de todo. Quizas mis cortos conocimientos sobre el lenguaje de modelado xml me han pasado factura. He decidido que cuando empiece con eso lo haré con un ejemplo que haya por ahi como hice en su dia con el sii y con el ticketbai.
despues de estar trasteando con el SistemaFacturacion.wsdl me he dado cuenta que el propio fichero no es correcto, ahí estaba una de mis confusiones. El wsdl es el esquema del WebService, todos sus endpoints y esquemas de ficheros de envío y recepción, "pero" el que nos suministra hacienda está en
https://prewww2.aeat.es y en él se incluyen las referencias a los esquemas a utilizar para la creación de los xml, con la peculiaridad que los esquemas apuntan a la url
https://www2.agenciatributaria.gob.es/, por lo tanto si intentas procesar el wsdl pues te va a dar un 404 not found como una casa. Hay que cambiar las url por
https://prewww2.aeat.es/ para que te funcione, hasta la utilidad SoapUI da error. Conclusión, está a medio cocinar.
No obstante continuo indagando en wsdl con sus xsd adjuntos ya que ahí está todo lo necesario, tanto los esquemas de envío de facturas como los esquemas xml de respuesta.
paquitohm wrote:
A mi lo que me preocupa es cual va a ser el sistema que tenemos que usar. VF introduce una variable t desconocida hasta ahora: Flujo de datos. Eso obliga a acumular xmls en un mismo envio y por supuesto obliga tambien a esperar una respuesta multiple.
El tratamiento de las anulaciones tambien da para alguna charla
Yo creo que ahí simplemente hay que procesar el dato t que devuelve la petición, si te pone 10 minutos (por ejemplo) pues hasta 10 minutos no puedes enviar la siguiente factura. Que puede pasar? que tengas más de una factura por enviar. Solución? pues preparar el proceso de generación de xml para poder incluir n facturas, y cada vez que se genera un envío, mirar en el dbf de facturas las que no se han enviado y meterlas todas. Habrá que guardar el dato t que se recibe en algun fichero por si se sale y entra del programa tener constancia del último envío y del tiempo a esperar para el próximo.
Otra opción sería meter un timer que se ejecute cada minuto y haga la comprobación o incluso tener un thread exclusivo para eso, pero ahí ya entra la arquitectura que tenga montada cada uno en su aplicación
Garbi wrote:Vamos por partes.
1.- Crear fichero xml
Tenemos nuestros datos en .dbf
Con el ejemplo que hay de un ejemplo de xml podría usar las funciones
fcreate() para crear el xml
ir añadiendo lineas con outfile()
y una vez terminado todo con fclose() cerrar el fichero.
¿Con eso obtendría un fichero valido xml?
Es por empezar por algo, y saber si estoy perdiendo el tiempo o voy por buen camino.
¿Qué pensáis?
Ahí no te puedo ayudar mucho, yo los xml los trabajo mediante la librería chilkat
https://www.chilkatsoft.com/refdoc/xChilkatXmlRef.html tanto los que creo yo como los que recibo. Antes lo hacía a pelo como dices pero es más complejo y a la que te dejas un > o < ya la has liado. Otra opción es utilizar la TXml que también la gasté hace tiempo.
Realmente lo que menos me preocupa es la creación en sí del xml, se puede hacer de varias formas, lo importante es saber exactamente el contenido ( que ya se puede saber por la documentación de hacienda ) y hacer una estructura de clases ( una por dato ) como comenta paquito más arriba que ya te lo haga todo, incluso verificar si los datos son correctos.
Bueno, vamos a vanzando, poco pero hacia adelante.
Salud!
Grosso modo esto sería el tema: