Complemento TimbreFiscal

[acordovar]

Buenos dias a todos!

Recientemente verifiqué el XML generado por mi aplicación en la pagina del SAT https://www.consulta.sat.gob.mx/sicofi_web/moduloECFD_plus/ValidadorCFDI/Validador%20cfdi.html y me da el mensaje: Validación de estructura: Inválido xsi:schemaLocation del Complemento tfd:TimbreFiscalDigital no declarado.

Comparando mis XMLs con los de otros sistemas, veo que efectivamente me falta ese atributo, que el NameSpace. Si aguien ya lo tiene implementado, por favor ayudeme.

De antemano, gracias!

Saludos!

[isccarrasco]

Buen día @acordovar ... Veo que no tuviste respuesta por parte de la comunidad, pero me pregunto si pudiste resolver el tema del Timbre, ya que presento la misma situación actualmente...

Agradecería algún comentario u orientación al respecto en caso de haber podido resolver el tema...

Gracias de antemano.

Saludos.

[hortegag91]

Por la manera en la que uso dicha librería he ocupado meterle mucha mano, pero en mi caso, lo que hice fue que lo "automatizé" directo en el código en base a los complementos detectados de la siguiente manera: if (document.getComplemento() != null && document.getComplemento().getAny() != null) { for (Object o : document.getComplemento().getAny()) { if (o.toString().toUpperCase().contains("NOMINA")) { schemas += " http://www.sat.gob.mx/nomina http://www.sat.gob.mx/sitio_internet/cfd/nomina/nomina11.xsd"; } if (o.toString().toUpperCase().contains("IMPUESTOSLOCALES")) { schemas += " http://www.sat.gob.mx/implocal http://www.sat.gob.mx/sitio_internet/cfd/implocal/implocal.xsd"; } Validando cada complemento que requiere schemalocation, y al final solo lo agregué al Marshaller con la propiedad "JAXB_SCHEMA_LOCATION" Espero les haya sido de utilidad.

[acordovar]

Hola Mario, No recuerdo que pregunté aqui, pero dejame revisarlo y te respondo. Saludos!

Date: Fri, 9 Sep 2016 09:59:43 -0700 From: notifications@github.com To: factura-electronica@noreply.github.com CC: acordovar@outlook.com; mention@noreply.github.com Subject: Re: [bigdata-mx/factura-electronica] Complemento TimbreFiscal (#110)

Buen día @acordovar ...

Veo que no tuviste respuesta por parte de la comunidad, pero me pregunto si pudiste resolver el tema del Timbre, ya que presento la misma situación actualmente...

Agradecería algún comentario u orientación al respecto en caso de haber podido resolver el tema...

Gracias de antemano.

Saludos.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

Parece, reitero el parece, hay una confusión.

El nodo del timbre, lo agrega un PAC al timbrar, no debes de agregarlo tu en tu aplicación. Tu aplicación solo debe generar un documento válido técnicamente y enviarlo a timbrar a algún PAC, el cual le pone el nodo del timbre, y entonces si puedes validar en el servicio del SAT.

Saludos

[isccarrasco]

Muchas gracias por la respuesta @hortegag91 ... al parecer es el método que usaremos ...

Igual gracias por tu observación @mauriciobaeza , entiendo el punto, y en efecto, la aplicación genera el XML válido, el cual es enviado al PAC, quien a su vez timbra el XML y nos devuelve dicho timbre de forma correcta... cuando recibimos el timbre, viene con los datos de los schemas correspondientes...

Sin embargo, cuando a través del Marshall convertimos ese timbre del PAC hacia las clases correspondientes del TimbreFiscal, se pierden esos schemas (al menos es los que nos pasa)... y al guardar la información en la BD y querer "reimprimir o reenviar" el XML, el SAT no los valida por falta de los schemas del timbre.

Tal vez no sea la práctica correcta, pero en la BD guardamos cada segmento del Comprobante Fiscal en tablas diferentes...

La otra solución sería guardar el archivo XML en BD... ¿Lo consideran una buena práctica?

Gracias por sus comentarios.

[hortegag91]

Asi es, en mi caso tambien es uno de los procesos que usamos, recibimos la factura y la manejamos por medio de esta misma librería por lo que perdía ciertos valores (namespaces y schemas por lo general) es por eso que le hemos metido tanta mano. @isccarrasco , en nuestro caso, estamos guardando el XML tal y como viene del PAC, y tenemos una tabla distinta en donde guardamos los campos relevantes (para nuestras operaciones) ya deglozados, de tal manera que el cliente pueda consultar solo la información que necesite, o en su defecto abrir el XML completo. Saludos.

[isccarrasco]

Gracias por el comentario @hortegag91 ... justo es nuestro caso, haremos algunos ajustes para guardar el XML y tener disponible los datos y no perder información en la transformación con el marshall...

[hortegag91]

Asi es, te recomiendo que si usas SQL trates la tabla como una cadena de texto (si manejarán muchísimos registros) ya que aunque es un poco más tardado el estarlo transformando cada vez que lo lees, ocupará mucho menos espacio en BD. Saludos y éxito.

[isccarrasco]

Haré algunas pruebas... Ya que he leído la documentación del tipo de dato "xml" y al parecer brinda ventajas sobre los campos de tipo text para PostgreSQL.

Dejo la referencia: https://www.postgresql.org/docs/9.5/static/datatype-xml.html

Gracias... Saludos.

[hortegag91]

En efecto, se creó por alguna razón, en nuestro caso teníamos un cliente que tenía la versión express de MSSQL, por lo que su tamaño máximo era de 4gb, y en formato XML la lleno en 2 años aproximadamente, por lo que lo cambiamos a String y ya lleva 6 años sin problema (está casi llena la BD, pero como solo se ocupan respaldar 5 años, esto fue suficiente.

[ghost]

Es perfectamente valido guardar el XML, de hecho, es una buena practica, un XML timbrado, no debería, reitero el no debería, ser modificado nunca más...

Saludos