feat(ir.attachment.facturae.mx) agrega nueva funcionalidad de generación de adendas y complementos al sistema
Como parte del Trabajo de extension de la forma de generación de Addendas se crea este MR.
Este MR:
- Hecho - Agrega el campo cfdi_adenda_id en el modelo ir.attachment.facturae.mx
- Hecho - Copia la addenda al objeto ir.attachment.facturae.mx desde el documento a Timbrar (account.invoice, account.voucher, etc).
- Hecho - Agregar función que Renderice la Addenda
- Hecho - Agregar función que fusione la Addenda generada al XML del CFDI.
-- Update Concentro aquí toda la información y MR relacionados para el desarrollo de esta funcionalidad de generación de Addendas y Complementos.
- l10n_mx!72 (merged) En este MR Agrego prácticamente dos campos:
- report_id para relacionar el reporte que contiene la definición de la Adenda o Complemento
- xml_prefix este campo va a contener el nombre del xmlns (Definición del Namespace en el caso de que sea un complemento o alguna Adenda que asi lo requiera. Es usado dicho campo para al final de la incorporación de la Adenda/Complemento realizar una limpieza del XML y con esto quitar las definiciones que no sean requeridas.
- xml_ns campo para establecer el Namespace del Complemento
- xml_xsd campo para definir la ruta hacia el xsd (URL)
- !274 (closed) (este mismo MR) Aqui se modifican dos modelos:
-
BaseCfdi se agrega un campo y se envía el valor del campo cfdi_adenda_id hacia el objeto ir.attachment.facturae.mx
- cfdi_adenda_id Campo relacionado al modelo cfdi.adenda
- función create_cfdi En esta función se envía el valor de la Adenda seleccionada en la Factura hacia el Objeto ir.attachment.facturae.mx
-
ir.attachment.facturae.mx Se agrega un campo y una función nueva para generación de la addenda. Modifica la funcion de la generación del XML y agrega campo cfdi_adenda_id a la vista.
- l10n_mx_facturae!95 (merged) En este MR solo se adapta el Template del XML para que sea compatible con este nuevo modelo de generación de Adendas y Complementos.
Prácticamente, fue solo quitar el nodo cfdi:Complemento/ que se tiene definido actualmente en el Template, para evitar duplicidad del propio Nodo al momento de la generación de una Factura con Complemento. Si se genera un Complemento, entonces, en programación agregamos el nodo.
-
l10n_mx_facturae_cdetallista!6 (merged) Este MR es para adaptar el Complemento Detallista al nuevo modelo de generación de Addendas. Especial atención en el inicio de la definición del template. No se debe agregar el nodo cfdi:Complemento o cfdi:Addenda, ya que solo se toma el nodo interno de la información respectiva del Complemento como tal (detallista:detallista) De igual manera, total atención en la definición del Nodo <detallista:detallista, ya que se define el Namespace correspondiente, de esta manera, evitamos errores al momento de la generacion del complemento, ya que al momento de leer el template, renderizar y luego convertir a XML Element, necesita el Namespace definido, luego en su inserción al Comprobante el mismo minidom lo quita de ahi.
-
l10n_mx_adendas!1 (closed) Este MR adapta la Adenda Pilgrim para trabajar en el nuevo modelo de generación de Adendas.
Mismas observaciones que en el Complemento Detallista.
La única diferencia, es que no se definira información de Namespace en la configuración de la Adenda, por lo tanto, el sistema asumirá que es es una cfdi:Addenda
* **