#194 [Compras] Recepción de facturas electrónicas vía bandeja compartida de Outlook — definir requisitos técnicos
Contexto
En la sesión de trabajo del 2026-09-12, David preguntó si el ERP puede integrarse con Outlook para recibir automáticamente las facturas electrónicas que hoy llegan a un correo específico de CONSOF, de manera que aparezcan directamente en una bandeja dentro del módulo de Compras/Cuentas por Pagar, en vez de tener que revisarlas manualmente en el correo.
La idea propuesta por David es usar una bandeja compartida de Outlook (shared mailbox de Microsoft 365) — no una cuenta de correo individual — para que el equipo de Compras reciba ahí las facturas, y que el ERP pueda leer esa bandeja.
Qué necesitamos de Indunnova
Antes de poder pedirle a CONSOF que gestione accesos con su administrador de Microsoft 365, necesitamos que el equipo técnico confirme:
- Qué enfoque técnico se usaría para leer la bandeja (ej. Microsoft Graph API, IMAP, u otro), y por qué.
- La lista exacta de datos/accesos que CONSOF debe proveer para configurarlo (ej. si es vía Graph API: Tenant ID, Client ID, Client Secret o certificado, y los permisos específicos que debe autorizar el administrador de Microsoft 365 de CONSOF — idealmente con el alcance más restringido posible, limitado solo a la bandeja compartida en cuestión, no a todo el correo de la organización).
- Qué debe pasar con cada correo/factura recibida — ¿se necesita que el ERP marque los correos como procesados para no leerlos dos veces?, ¿se requiere permiso de solo lectura o también de escritura/movimiento de correos?
Preguntas de alcance para definir con CONSOF una vez tengamos la lista técnica
- ¿Qué debe generar el sistema al llegar un correo con factura? (¿un registro pendiente de validación en Compras/CxP automáticamente, o solo mostrar el correo en una lista para que alguien lo procese manualmente?)
- ¿Con qué frecuencia se debe revisar la bandeja? (tiempo real vía notificación/webhook, o revisión periódica)
- ¿Qué hacer con correos que no traen un adjunto reconocible como factura (PDF/XML válido)?
Resultado esperado de este issue
Que el equipo confirme el enfoque técnico y la lista de datos/accesos necesarios, para poder coordinar con el administrador de Microsoft 365 de CONSOF y avanzar con el alcance funcional completo en un issue de seguimiento.
Comentarios (9)
🤖 Pre-análisis automático (NOVA) — ✅ completo
Requerimiento completo — pasa el gate de completitud del pre-triage.
Tabla de entregables sembrada (gate anti-FIX_INCOMPLETO): es la lista contra la que se valida el cierre — ninguna fila sin ✅ puede ir 🟢.
| # | Entregable | Evidencia esperada (URL/campo/comportamiento) | Estado |
|---|---|---|---|
| 1 | Confirmar enfoque técnico para leer la bandeja compartida de Outlook | Documento o descripción del enfoque técnico propuesto (ej. Microsoft Graph API, IMAP) y su justificación. | ⬜ |
| 2 | Listar datos/accesos exactos que CONSOF debe proveer | Lista detallada de credenciales (ej. Tenant ID, Client ID, Client Secret/certificado) y permisos específicos de Microsoft 365 requeridos, con el alcance más restringido posible. | ⬜ |
| 3 | Definir comportamiento esperado para cada correo/factura recibida | Especificación sobre si los correos deben marcarse como procesados y qué tipo de permisos (solo lectura, escritura, movimiento) son necesarios para la bandeja compartida. | ⬜ |
Si al ejecutar aparece un sub-requisito no listado, agregarlo a la tabla ANTES de cerrar.
Ampliación de alcance: también necesitamos envío de correos (no solo recepción)
Además de la recepción de facturas descrita arriba, tenemos otra necesidad pendiente relacionada con correo electrónico, que puede compartir la misma infraestructura de Microsoft 365: el envío de correos transaccionales.
El caso concreto hoy es el Portal de Terceros (#85): el flujo de acceso con OTP debe enviarle al contratista externo un código de 6 dígitos por correo, y hoy eso no llega porque el envío de correos no está configurado — quedó documentado en #85 que estamos usando un link de acceso manual como workaround mientras tanto.
Esto es una dirección distinta a la de recepción de facturas (enviar vs. recibir), por lo que probablemente requiera un permiso distinto (Mail.Send en vez de Mail.Read, si se usa Microsoft Graph API), o incluso un servicio de envío transaccional separado (SMTP relay, SendGrid, Mailgun, etc.), dependiendo de lo que recomiende el equipo técnico.
Pedimos que el equipo confirme, junto con lo ya solicitado arriba:
- Qué enfoque recomienda para el envío saliente (Graph API
Mail.Senddesde una cuenta/bandeja de CONSOF, vs. un servicio externo de envío transaccional). - Si se puede reutilizar el mismo registro de aplicación en Azure AD que se configure para la recepción de facturas (con el permiso adicional de envío), o si conviene mantenerlos separados.
- La lista de datos/accesos adicionales que se necesitarían para habilitar el envío (si es distinta a lo ya pedido para la recepción).
Con esto, el ERP podría empezar a enviar automáticamente notificaciones por correo (códigos OTP, alertas, etc.), no solo recibirlas.
🔁 Devuelto por Andrea — no quedó validado.
ejecutar
— Andrea vía NOVA
Requisitos técnicos para recibir facturas desde un buzón compartido de Outlook (y para el envío)
David, estas son las respuestas técnicas. Lo que CONSOF debe preparar también quedó en el ERP, en Config → Correos y alertas (ver #320).
1. Enfoque técnico
Microsoft Graph, con un registro de aplicación en Microsoft Entra (Azure AD) de CONSOF. No recomendamos IMAP: Microsoft retiró la autenticación básica para IMAP en Microsoft 365 y obligaría a manejar contraseñas de buzón. Con Graph el ERP entra con una identidad de aplicación y el acceso se puede limitar a un solo buzón.
2. Datos y accesos que CONSOF debe proveer
| Dato | Detalle |
|---|---|
| Buzón compartido | Dirección del buzón para facturas, por ejemplo facturas@… |
| Tenant ID | Identificador del inquilino de Microsoft 365 de CONSOF |
| Client ID | Identificador del registro de aplicación que cree su administrador |
| Certificado o secreto del cliente | Preferimos certificado. Se entrega por un canal privado y se guarda en el gestor de secretos; no va en tickets ni correos |
| Permiso | Mail.ReadWrite de aplicación, con consentimiento del administrador |
| Restricción | Su administrador limita la aplicación solo a ese buzón con una política de acceso de aplicaciones de Exchange (o RBAC para aplicaciones). Así no puede leer ningún otro correo de CONSOF |
3. Qué pasa con cada correo
- El ERP lee los correos nuevos, toma los adjuntos PDF y XML, y crea el documento en la bandeja de Facturas para revisión. Ese flujo ya existe en el ERP (lectura del XML de la DIAN, detección de duplicados, cruce con la orden de compra, retenciones e imputación).
- Para no leer dos veces, el ERP mueve el correo a una carpeta «Procesados» del mismo buzón. Por eso pedimos Mail.ReadWrite y no solo lectura. Si prefieren solo lectura (Mail.Read), también funciona: el ERP lleva su propio registro de los correos ya leídos, pero el buzón no queda ordenado.
- Correos sin adjunto reconocible (propuesta): quedan registrados como «sin documento» para que alguien los revise; no se descartan solos. Confírmennos si están de acuerdo.
- Frecuencia propuesta: revisión cada 15 minutos.
Envío de correos (su ampliación del 13-sep)
- Enfoque: una cuenta de Microsoft 365 solo para el ERP, por ejemplo
notificaciones@…, con envío autenticado (SMTP AUTH). Es lo que ya espera el ERP para invitaciones y recuperación de contraseña (#184). - ¿Mismo registro de aplicación? Recomendamos mantenerlos separados: el de recepción solo toca el buzón de facturas; el envío usa su propia cuenta. Si un acceso se compromete, el otro no.
- Datos adicionales: la dirección de esa cuenta, el nombre que verá el destinatario y su contraseña (por canal privado).
Estado
| # | Entregable | Estado |
|---|---|---|
| 1 | Enfoque técnico | ✅ Microsoft Graph |
| 2 | Datos y accesos exactos, con el alcance más restringido | ✅ tabla arriba |
| 3 | Qué pasa con cada correo y qué permisos | ✅ arriba |
| 4 | Envío: enfoque, si se reutiliza el registro y datos adicionales | ✅ arriba |
| 5 | Conector de Graph que lee el buzón | ❌ hoy el conector existe pero está apagado; se activa cuando CONSOF entregue los datos |
Lo que sigue
Cuando su administrador tenga el registro de aplicación y la cuenta de envío, nos avisan aquí y coordinamos la entrega privada de los datos para activar ambos.
✅ Listo para que lo valides — probado por Andrea (Indunnova).
Queda pendiente de validación, hasta que se activen los correos
Si quedó bien, márcalo como resuelto en tu ticket. Si algo falta, responde aquí mismo.
Hola, Miguel y equipo. Confirmamos que CONSOF ya organizó el buzón compartido para recepción de facturas. La dirección definitiva es recepcion.facturas@consof.com.co; reemplaza la referencia anterior a facturacion@consof.com.co para esta integración.
El envío de notificaciones sigue por notificaciones@consof.com.co, mediante Microsoft Graph y RBAC, según lo acordado en el #320. La información de esa aplicación ya se entregó a Miguel por el canal privado; corresponde al envío y no acredita acceso de lectura al buzón de facturas. La instrucción de SMTP AUTH/contraseña del 23 de octubre quedó reemplazada para el envío.
Al revisar hoy Config → Correos y alertas, la sección de recepción dice que la lectura todavía no está activa y que por ahora no es necesario otorgar permisos. Aquí en el #194 se indicó que el conector existe y se activa al entregar los datos. Para continuar sin configurar accesos innecesarios, por favor confirmen:
- Si el conector de recepción ya está listo para activarlo con este buzón y cuál es el paso que sigue del lado de CONSOF.
- La lista vigente de datos y el rol exacto para la aplicación de recepción: Application Mail.Read si solo lee y controla los correos procesados en el ERP, o Application Mail.ReadWrite si mueve los mensajes a «Procesados». Mantener el acceso limitado exclusivamente a recepcion.facturas@consof.com.co mediante RBAC y precisar la aplicación separada de recepción que recomendaron.
- Cómo coordinamos una prueba controlada de recepción de PDF/XML, detección de duplicados y registro pendiente de revisión en Facturas, una vez configurado.
Quedan por acordar con CONSOF la modalidad de lectura/movimiento de mensajes, la frecuencia propuesta de 15 minutos y el manejo de correos sin adjuntos reconocibles. Este comentario confirma el buzón; no declara activada ni validada la integración.
Referencia técnica de RBAC de Exchange: https://learn.microsoft.com/es-es/exchange/permissions-exo/application-rbac
🔁 Devuelto por Andrea — no quedó validado.
Ejecutar cambios mientra se rtermina de organiar lo de los correos
— Andrea vía NOVA
🟡 El lector del buzón recepcion.facturas@consof.com.co ya está listo (solo lectura): falta la aplicación de recepción de CONSOF
Revisión: consof-00215-77d (100 % del tráfico, cuenta sa-consof) · PR #343
David, respondemos sus tres preguntas del 6 de noviembre.
1. ¿El conector está listo? ¿Qué sigue del lado de CONSOF?
Sí. Hasta esta semana el conector de Microsoft Graph era solo la estructura; ya quedó implementado y desplegado, y sigue apagado hasta tener las credenciales. El paso que sigue es de CONSOF (punto 2).
2. Datos y rol exactos de la aplicación de recepción
Recomendamos una aplicación separada de la de envío, por ejemplo «ERP CONSOF Recepción Facturas», con el mismo esquema que ya usaron para notificaciones:
| Qué | Detalle |
|---|---|
| Rol | Application Mail.Read (RBAC para aplicaciones de Exchange), sin permisos globales en Entra |
| Ámbito | Un ámbito de administración limitado solo a recepcion.facturas@consof.com.co |
| Comprobación | Test-ServicePrincipalAuthorization: InScope=True para recepcion.facturas@ y False para cualquier otro buzón |
| Datos a entregar (por el canal privado, como en #320) | Id. de directorio (tenant), Id. de la aplicación y valor del secreto, con su fecha de vencimiento |
Modalidad: solo lectura (Mail.Read). El ERP no mueve ni borra correos. Lleva su propio registro de los correos ya leídos, por su identificador, y no vuelve a importarlos. Por eso no hace falta Mail.ReadWrite ni la carpeta «Procesados».
3. Prueba controlada
Con las credenciales cargadas, activamos el buzón y les pedimos enviar a recepcion.facturas@ tres correos:
- (a) una factura con PDF y XML;
- (b) una cuenta de cobro solo en PDF;
- (c) un correo sin adjunto.
Lo que debe verse en la Bandeja de facturas:
- (a) queda como un solo documento con su representación gráfica.
- (b) queda pendiente de revisión, disponible para revisar.
- (c) queda registrado como «correo sin PDF ni XML reconocible», para revisar; no se descarta.
- Al reenviar el correo (a), no se duplica.
- Cada documento conserva el remitente, el asunto y la fecha y hora reales de recepción.
Puntos por acordar (los dejamos propuestos)
| Punto | Propuesta |
|---|---|
| Modalidad | Solo lectura, como arriba |
| Frecuencia | Cada 15 minutos |
| Correos sin adjunto reconocible | Quedan registrados para revisión, como arriba |
| # | Entregable | Estado |
|---|---|---|
| 1 | Conector que lee el buzón compartido por Graph | 🟡 desplegado, apagado hasta tener credenciales |
| 2 | Datos y rol exactos, limitados a recepcion.facturas@ | ✅ arriba |
| 3 | Cuentas de cobro solo en PDF, para revisión | 🟡 probado con pruebas automáticas; prueba real al activar |
| 4 | Sin duplicados al leer de nuevo | 🟡 probado con pruebas automáticas |
| 5 | Instrucciones en Config → Correos y alertas | 🟡 actualizadas con este procedimiento |
| ⏸ | Activación y prueba real | Cuando CONSOF entregue los datos de la aplicación de recepción |
| Ciberseguridad | ✅ cumple: aplicación separada, solo lectura y limitada a un buzón; el secreto irá al almacén de secretos del servidor | ✅ |
Lo que verificamos:
- Pruebas automáticas con Microsoft Graph simulado: lee PDF, XML y .zip; ignora imágenes incrustadas; no repite correos ya leídos; un correo sin adjunto queda para revisión; un error de conexión queda visible.
- En producción responden «Correos y alertas» (con el nuevo procedimiento), la bandeja y la configuración del buzón.
✅ Listo para que lo valides — probado por Andrea (Indunnova).
Si quedó bien, márcalo como resuelto en tu ticket. Si algo falta, responde aquí mismo.