Versión 7.8.01 - 10/05/2024

Solución de errores

Error 13560: Hotfix: Corrección en persistencia de correos ABR

Problema: El proceso de sincronización de información de terceros en ABR estaba trasladando únicamente el correo principal a Facturación Electrónica (FE), aun cuando el parámetro SYNC_ABR_ADQUIRIENTE_USAR_SOLO_CORREO_PRINCIPAL estaba desactivado. Esto generaba un comportamiento incorrecto, ya que no permitía la sincronización de más de un correo.

Análisis: El inconveniente surgió debido a una validación incorrecta en el procesamiento de correos en ABR. Aunque el parámetro mencionado indicaba que no debía limitarse el uso a un solo correo, el sistema no estaba aplicando esta regla de manera adecuada. Además, los documentos de consignación de inmuebles con origen "ABR_CIN" no estaban siendo considerados en el proceso de sincronización y persistencia de correos, lo que dejaba a los adquirientes sin sus correos sincronizados.

Solución: Se propone agregar el correo como llave/valor de relación dentro del procedimiento almacenado [FAE].[SincronizarInformacionTercerosABR] para evitar la eliminación de correos cuando no corresponda. Esto permitirá sincronizar más de un correo en el módulo de Facturación Electrónica (FE) para los casos de facturas de ABR. También se añadió el origen "ABR_CIN" para incluir los documentos de consignación de inmuebles en el proceso de sincronización.

Error 13561: Hotfix: Correccion en validacion de Nota credito/debito sin referencia a factura

Problema: La etiqueta correspondiente a la factura afectada se entregaba vacía en el módulo de FYC cuando la nota crédito/débito no referenciaba una factura. No obstante, desde el visor de documentos, la propiedad "FacturaAfectada" seguía mostrando un valor por defecto (comodín) utilizado para sincronizar estas notas, generando inconsistencia en la información.

Análisis: El manejo interno de datos provocaba que, para notas crédito/débito sin referencia a factura, la etiqueta de factura afectada se enviara vacía al módulo de FYC, pero al mismo tiempo, en el visor de documentos, un registro por defecto se mostraba en la propiedad "FacturaAfectada". Esto creaba discrepancias entre el visor y la funcionalidad en FYC, y podría afectar los procesos que dependen de esta etiqueta.

Solución: Se debe ajustar el visor de documentos para que muestre el valor correcto de la etiqueta "FacturaAfectada", es decir, dejarla como null cuando no hay una factura referenciada. Esta modificación debe aplicarse también a las validaciones y funcionalidades que utilizan esta etiqueta, garantizando así la coherencia de la información en todos los procesos.

Mejoras internas

Nuevas propiedades estructura base documento

Definición: Se agregan cuatro propiedades nuevas a la estructura base de los documentos: FechaGeneracion, FechaExpedicion, DireccionEntregaBienOServicio y ValorFirmaDigital. Estas propiedades contendrán información clave como la fecha del documento, la dirección del emisor, y el valor de la firma digital (extraído de la etiqueta SignatureValue dentro del XML).

Alcance: Estas propiedades deben estar disponibles al solicitar la generación de la representación gráfica en el módulo de FYC, permitiendo su correcta visualización. La propiedad ValorFirmaDigital se entregará únicamente cuando el documento haya sido firmado y enviado a la DIAN, dado que es en ese momento cuando se genera esta información.

Adición de tipo de identificación de terceros PPT

Definición: Se ha implementado el tipo de identificación "PPT (Permiso Protección Temporal)" como un nuevo tipo válido para la transmisión de documentos, acorde con las especificaciones del anexo 1.9.

Alcance: Este nuevo tipo de identificación estará disponible en los documentos que se transmitan, ajustándose a las siguientes ubicaciones en los anexos correspondientes:

• En el anexo 1.8: Se encuentra en la sección 11.2.1. Documento de identificación (Tipo de Identificador Fiscal).
• En el anexo 1.9: Se encuentra en la sección 13.2.7.1. Documento de identificación (Tipo de Identificador Fiscal).

Modificaciones a Notas Crédito y Debito sin referencia a Factura

Definición: Cuando una nota crédito/débito no referencia una factura, se realizarán ajustes en la estructura XML generada. Estos ajustes incluyen la adición de la propiedad InvoicePeriod, con las etiquetas StartDate y EndDate que especificarán el periodo contable de la afectación. Para las notas crédito, se modificarán los valores de las propiedades ResponseCode y Description dentro de DiscrepancyResponse, y se actualizarán las descripciones de algunos conceptos de corrección.

Alcance: InvoicePeriod se añadirá para todas las notas crédito/débito que no referencian facturas. El periodo contable abarcará desde el primer hasta el último día del mes del documento (por ejemplo, si la fecha es 16/01/2024, StartDate será 01/01/2024 y EndDate será 31/01/2024).
Los siguientes cambios aplicarán solo a notas crédito:

• ResponseCode se actualizará al valor 4, reemplazando el código 2.
• Description se establecerá en "Ajuste de precio" acorde al anexo 1.9.

Las descripciones de los conceptos de corrección se han actualizado:

• "Rebaja total aplicada" ahora será "Rebaja o descuento parcial o total".
• "Descuento total aplicado" ahora será "Ajuste de precio".
• "Rescisión: nulidad por falta de requisitos" será "Descuento comercial por pronto pago".
• "Otros" será "Descuento comercial por volumen de ventas".

Firma de documentos con fechas anteriores

Definición: Se implementará una regla de validación que verificará que la fecha del documento coincida con la fecha de firmado del XML emitido. Para manejar escenarios donde estas fechas no coincidan, se creará el parámetro DIAS_MARGEN_FIRMADO_DOCUMENTOS, el cual permitirá configurar un margen de días (con un valor por defecto de 10) para firmar documentos con fechas anteriores a la fecha actual.

Alcance:

• Si un documento tiene una fecha anterior a la fecha de envío, el sistema firmará el XML con la fecha del documento, siempre que esté dentro del margen configurado por el parámetro DIAS_MARGEN_FIRMADO_DOCUMENTOS. Por ejemplo, si un documento tiene fecha 24/01/2024 y se envía el 27/01/2024, el XML se firmará con la fecha 24/01/2024. Si el parámetro tiene un valor de 0, el documento se firmará con la fecha del envío (27/01/2024).
• Esta regla de validación no afectará la información transmitida en el XML, ni tendrá impacto visible para el cliente o la DIAN. Es una práctica que ya se ha utilizado en otros casos de recepción y seguirá aplicándose mientras sea permitido por la DIAN.

Envío de documentos con moneda extranjera en moneda COP

Definición: A partir de la entrada en operación del anexo 1.9, la DIAN solo admitirá documentos emitidos en moneda COP. Para implementar este cambio, se creará el parámetro ENVIO_ESTRUCTURA_EN_COP, que estará activado por defecto. Cuando este parámetro esté activo, el sistema validará la moneda de los documentos al generar el XML para la transmisión, y si es una moneda extranjera, asignará COP y aplicará la tasa de cambio correspondiente a todos los valores del documento.

Alcance:

• Si el parámetro ENVIO_ESTRUCTURA_EN_COP está activo, el sistema convertirá automáticamente los documentos con moneda extranjera a COP, aplicando la tasa de cambio sincronizada en el momento de la generación y transmisión del XML.
• Si el parámetro está inactivo, el documento será transmitido tal como fue sincronizado originalmente. Sin embargo, dado que la DIAN rechaza documentos emitidos en monedas diferentes a COP, desactivar este parámetro no es recomendable.
• El cambio de moneda y valores aplicando la tasa de cambio solo afectará la generación y transmisión del XML. La información original del documento (moneda y valores) se mantendrá intacta en la representación gráfica y en el ERP.

Bloqueo de integraciones diferentes al directo

Definición: A partir de la implementación del anexo 1.9, se dejará de ofrecer soporte a integraciones que no sean de envío directo. Como consecuencia, se bloquearán las opciones de envío de documentos y archivos planos para los clientes que no tengan activa la integración directa.
Alcance:

• El bloqueo afectará el envío de documentos soporte para los clientes con integración de proveedor, pero no afectará aquellos con integración mediante archivo plano.
• Además, se deshabilitará el proceso automático de envío de documentos hacia el proveedor en estos casos.
  *No será necesario inactivar o eliminar la integración con un proveedor una vez que la integración directa esté activa, ya que esto eliminará la restricción automáticamente.

Detener proceso de habilitación

Definición: Debido a que hay situaciones en las que la DIAN no responde al proceso de habilitación, se implementará un botón en el último paso de habilitación, que permitirá a los usuarios administradores detener el proceso dentro del módulo del ERP. Esto ayudará a reiniciar el proceso de habilitación si queda bloqueado en espera de una respuesta que no se proporcionará.

Alcance:

• El botón de detención estará disponible únicamente para usuarios administradores del sistema; los usuarios normales (clientes) no tendrán acceso a esta opción.
• La detención del proceso solo afectará el módulo del ERP y no impactará la solicitud o proceso de habilitación ante la DIAN.
• Al hacer clic en el botón, el proceso se detendrá, recargando la opción y dejándola en el primer paso, permitiendo iniciar un nuevo proceso de habilitación.
• Una vez que el proceso de habilitación se haya detenido, no será posible reanudarlo dentro del ERP.

Se actualiza instructivo incluyendo las mejoras y nuevas funcionalidades