![]() |
Problema con los XML generados
Tengo un problema con mis XML y acabo de darme cuenta ahora. la verdad es que no sé cuándo pudo empezar, estoy revisando XML antiguos y son correctos, pero tras algún cambio me ocurre lo siguiente.
Algunos nodos del XML aparecen como <item> en vez del nombre correcto. Por ejemplo este: Código:
<Desglose>Aquí va una porción simplificada del código: Código:
// Desglose de impuestosEse archivo XML ya está mal guardado, con los nodos <item>, así que creo que el problema en la forma de guardarlos. Para guardar el RF como XML uso esta función que alguien publicó en el foro: Código:
function ExtraerXMLdelRF(RegistroFactura: RegistroFacturaType): String;Agradecería cualquier pista, o si alguien usa otra forma de guardar el XML estaría agradecido de estudiarla y ver si me sirve, teniendo en cuenta que después tengo que volver a convertir ese XML en el RF para el envío. Por cierto, aunque el XML tenga esos nodos <item>, los RF se envían sin problema a Hacienda y no da error, pero me preocupa por si en un futuro empiezan a fallar. |
tienes razon, en que tiene ese comportamiento, tambien en el componente que diseñe lo hace asi. He revisado exportaciones de RF antiguas y asi estan.
aparentemente es el modo normal de delphi de exportar arrays que tiene esa funcion. (segun chatgpt) chatgpt propone renombrar esas etiquetas una vez generado el XML. ¿ por curiosidad donde envias los registros de facturacion exportados ? (no digo que hagais esto, ¿eh? ) para los que estamos en solo verifactu, segun hacienda, tras el envio no habria que conservada nada, puesto que ya esta en el servidor de ellos. tengo una consulta respondida de esta forma via email. de todas formas, y por curiosidad lo probare mañana y vere si funciona bien el codigo que me dio chatgpt. Saludos ! |
Gracias por la respuesta. Efectivamente, empezó a generar los XML así cuando cambié la forma de generar y enviar los RF, para que la aplicación solo generara los XML pero otra aplicación los enviara. Para ello, necesito primero generarlos y guardarlos y luego abrirlos desde la otra app (que puede estar en otro PC incluso).
Confirmo que funciona, incluso con esos <item>. Actualmente lo que hago es modificarlo a mano antes de guardarlo, detectando si existen esos nodos y poniéndoles el nombre correcto |
El "problema" viene desde el WSDL, todos los que usen la funcion ObjectToSOAP obtendran el mismo resultado.
En principio no estamos haciendo nada mal, si la definicion del WSDL viniera de otra forma, la funcion ObjectToSOAP lo haria "correcto". Manipular el XML cuando ha salido me da un poco de mal rollo, he probado distintas alternativas y manipular el XML con funciones de nodos, etc... no funciona bien. Lo mejor a mi parecer es directamente manipular el archivo de texto: Código:
function ReemplazarItemEnSeccion(const XMLText, Seccion, NombreViejo, NombreNuevo: string): string;Código:
xmlText := ReemplazarItemEnSeccion(xmlText, 'Destinatarios', 'item', 'IDDestinatario');Sinceramente no se que hacer, esto funciona. pero como digo me da "mal rollo" tocar un XML que ha salido limpio. Tengo que recopilar que arrays existen y colocarlo, quizas como opcion. Pero como digo no se si tocarlo o no. Porque en modo verifactu, no hay que enviar el RF, y tenerlo como esta ahora, no creo que sea problema. Maximo cuando la AEAT ya lo tiene. Saludos ! Pienso que no vas a tener problemas en enviar los RF, mientras no toquen el WSDL para cambiar la generacion de las etiquetas de los arrays. Y creo que eso no lo van a tocar. Es mas yo creo que ni se han preocupado de ello. Me gustaria tener alguna opinion. |
Por lo pronto, Hacienda acepta el XML aunque ponga <item> en vez de <DetalleDesglose>. También ocurre en el nodo <Destinatarios>. Pero lo dicho, se lo traga como si estuviera bien.
En nuestro caso, nosotros guardamos el RF en la BD, porque luego otra aplicación se encarga de hacer los envíos a Hacienda desde el Servidor, así que hay que "leer" ese XML y volver a convertirlo en objeto, para poder firmarlo y enviarlo. Nosotros hemos optado por modificar el texto a mano, por si acaso algún día se pongan tiquismiquis con los nombres de esos nodos y deje de funcionar. Concretamente hacemos esto: Código:
// Reemplazamos el nodo raíz con el generadoO eso, o usar la función ReemplazarItemEnSeccion() que has facilitado, que es más genérica y servirá para cualquier otra incidencia que pueda surgir. Nosotros guardamos el XML/RF de cada factura en disco, pero solo por tener más seguridad y que en caso de algún error poder revisarlo todo más cómoda y rápidamente. En realidad el RF se guarda en la BD también, así que los archivos "sobran", pero es más rápido buscar/abrir un archivo en el disco que hacerlo en la BD. |
Ok. entiendo tu proceso para que te veas un poco obligado a ese cambio
la verdad me ha sorprendido tu forma de reemplazo: por cierto, tengo una duda: ¿ con varios desgloses funcionara ? Saludos ! en el caso del componente, lo dejare tal cual esta, sin reemplazo, aunque guardare el código comentado en la DLL por si acaso. |
Probablemente haya otra forma mejor de hacer el reemplazo, pero me vi apurado ayer y lo hice así en plan rápido porque si no no dormía :D
Creo que hay un error aquí: MyXML.XML.Text := stringreplace(MyXML.XML.Text,'</IDDestinatario></item>','</IDDestinatario></Destinatarios>',[rfReplaceAll]); Debería ser así. me equivoqué al copiar/pegar: MyXML.XML.Text := stringreplace(MyXML.XML.Text,'</item></Destinatarios>','</IDDestinatario></Destinatarios>',[rfReplaceAll]); Esto solo funciona si el XML generado antes de llamar a FormatXMLData contiene todo el XML en una sola línea, porque es la única forma de que se encuentre esa cadena exacta a reemplazar. Si ya estuviera formateado, con cada nodo en una línea del archivo, el reemplazo no funciona (no existe esa cadena seguida tal cual), y habría que usar la función comentada anteriormente, que está más currada. Ojo, yo he detectado lo de <item> solo en estos dos nodos, pero puede que ocurra también en otros y habrá que estar atentos. |
| La franja horaria es GMT +2. Ahora son las 15:08:17. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi