Si su empresa es un ISP (proveedor de internet) en República Dominicana, lo más probable es que ya use Mikrowisp para gestionar la red, los routers, los planes de servicio y la facturación interna. Lo que no resuelve Mikrowisp por sí solo es la parte legal: emitir e-CFs certificados ante la DGII por cada factura que cobra.
La integración Mikrowisp-Axentra cierra ese círculo. Mikrowisp se queda haciendo lo que sabe hacer (manejar la red y generar las facturas mensuales), Axentra se encarga de:
Todo esto pasa de forma automática mediante un workflow durable que tolera caídas de Mikrowisp, de la DGII, o del propio Axentra sin perder facturas ni duplicar emisiones.
Axentra (su tenant)
Mikrowisp ┌────────────────────────────────────────────┐
(su servidor) │ │
┌──────────┐ poll/60s │ Workflow de sincronización (continuo) │
│ /api/v1 │ <───────── │ -> trae facturas no pagadas │
│ │ │ -> resuelve clientes (cache + API) │
│ token=X │ PaidInvoice│ -> upsert contactos por RNC/cédula │
│ │ <───────── │ -> crea factura AR + e-CF + asiento GL │
└──────────┘ │ │
│ Pago registrado en Axentra │
│ -> si la factura vino de Mikrowisp: │
│ workflow PaidInvoice │
│ -> POST de regreso a Mikrowisp │
└────────────────────────────────────────────┘
mikrowisp_external_invoices y mikrowisp_external_clients) que enlazan los IDs internos de Mikrowisp con los de Axentra.Vaya a ISP / Mikrowisp → Integración.
Smx2SVdkbUZIdjlCUlkxdFo1cUNMQT09)En la tarjeta Mikrowisp del tab Integración, complete:
| Campo | Valor |
|---|---|
| URL de la instalación | https://miempresa.mikrosystem.net (sin slash al final) |
| Token de la API | El token que copió arriba |
| Intervalo de sincronización | 60 segundos por defecto, mínimo 15 |
Haga clic en Conectar. Antes de guardar, Axentra hace un smoke probe contra la API de Mikrowisp para validar que las credenciales son correctas. Si el token está mal o la URL es incorrecta, recibirá un mensaje de error inline y la conexión no se persiste.
Una vez conectada, la tarjeta cambia al estado Conectado y muestra:
Use el botón Sincronizar ahora en la pestaña Resumen o dentro de la tarjeta de Integración. Mientras el workflow corre, la badge muestra Sincronización en curso y la página se actualiza automáticamente cada 3 segundos hasta que termine.
El botón Desconectar borra el token y desactiva la integración. El historial de mapeo se preserva — si decide reconectar más adelante, no se re-crearán las facturas ni los clientes que ya están sincronizados.
Vista general con tres tarjetas de estado (estado del último sync, última sincronización de facturas, última sincronización de clientes), botón de Sincronizar ahora y un mensaje de error si la última corrida tuvo problemas.
Lista paginada de los clientes de Mikrowisp que se sincronizaron como contactos en Axentra. Por columna verá:
ACTIVO o SUSPENDIDO según el último sync de Mikrowispmikrowisp-NNN@noemail.local (válido para emitir e-CFs pero el cliente no recibe el comprobante por mail)Filtros: búsqueda por nombre/RNC/correo y filtro por estado.
Hacer clic en una fila abre el detalle del contacto en /contacts/<id>.
Lista paginada de facturas de Mikrowisp con su contraparte en Axentra y el estado del e-CF. Columnas:
idfactura originalpagado pero Axentra todavía no recibió el ackFiltro por estado e-CF (todos / draft / signed / submitted / accepted / rejected). Hacer clic en una fila abre el detalle de la factura AR en /accounting/ar/<id>.
Si un e-CF fue rechazado, aparece un botón Reintentar en la fila que vuelve a firmar y enviar el comprobante. El motivo del rechazo se ve en el detalle del e-CF (panel rojo arriba del timeline).
Hosting de la tarjeta de conexión Mikrowisp. Acá se configura, se desconecta, y se ve el detalle del estado de credenciales.
La API de Mikrowisp expone un campo cedula que es freeform — en instalaciones multi-país puede traer RFC mexicanos, DNIs argentinos, o simplemente basura numérica. La DGII solo acepta:
Cualquier otro valor (alfanumérico, longitud distinta, vacío) se descarta y el contacto se crea sin RNC. Esto activa la emisión como E32 Factura de Consumo sin bloque de comprador, que es válido ante la DGII para consumidor final.
| Cédula original | Resultado | Doctype emitido |
|---|---|---|
131859933 |
RNC válido | E31 Crédito Fiscal |
40212345678 |
Cédula válida | E32 Consumo |
402-1234567-8 |
Cédula válida (se quitan guiones) | E32 Consumo |
MIMJ9109018J1 |
Inválido (RFC mexicano) | E32 sin RNC (consumidor final) |
8765457 |
Inválido (7 dígitos) | E32 sin RNC |
| `` (vacío) | Inválido | E32 sin RNC |
Cuando Axentra le pide facturas a Mikrowisp, solo trae las que están pendientes de pago (estado=1). Esto es deliberado:
estado=pagado, así que tampoco se pierden.Si quiere incluir histórico, abra un ticket de soporte y lo procesamos manualmente con un rango de fechas.
Si Mikrowisp le emitió una factura con fecha en un periodo fiscal cerrado en Axentra, el sync no puede crear el asiento contable y la factura se cuenta como omitida (no error). Aparece en el contador Skipped del resultado del sync.
Para procesarla:
Cada e-CF emitido desde una factura de Mikrowisp lleva una sola línea con descripción Servicio de internet - <mes> <año> (ejemplo: Servicio de internet - abril 2026).
Por qué no incluimos el plan específico: la API de Mikrowisp no expone un breakdown a nivel de factura — solo un total y el ITBIS. La lista de servicios del cliente (Servicios) es su plan actual, no necesariamente el que se le facturó en una factura específica (puede haber cambios de plan, prorrateos, multi-servicio facturado por separado). Estampar un nombre de plan en un e-CF legal que no coincida con lo que realmente se facturó sería un riesgo de cumplimiento que no asumimos.
Cuando se registra un pago en Axentra contra una factura AR que originó en Mikrowisp:
PaidInvoice en la API de Mikrowispmikrowisp_external_invoices se marca con payment_acked_atSi el POST a Mikrowisp falla (Mikrowisp caído, red inestable), el workflow reintenta hasta 10 veces con backoff exponencial (30s → 5min). El pago en Axentra nunca se revierte — el pago en sí es válido, solo no se notificó. El icono amarillo de "Pago acked" en la lista de Facturas indica esos casos para que el operador los revise.
El parámetro idtransaccion que enviamos a Mikrowisp es el UUID del pago en Axentra. Eso lo hace idempotente: si Mikrowisp recibe el mismo idtransaccion dos veces, lo trata como un solo pago.
| Permiso | Para qué sirve | Roles que lo tienen por defecto |
|---|---|---|
mikrowisp.read |
Ver el módulo /isp y sus pestañas | ADMIN, MANAGER, ACCOUNTANT |
mikrowisp.sync.manual |
Disparar Sincronizar ahora | ADMIN, MANAGER |
integration.mikrowisp.configure |
Conectar / desconectar credenciales | ADMIN |
mikrowisp.service.manage |
Suspender/activar servicio en Mikrowisp desde Axentra | (reservado para v2 — no implementado aún) |
mikrowisp.service.manage).Hover sobre el badge para ver el mensaje completo, o vea el campo de error en la pestaña Integración. Errores comunes:
fiscal period not open — abra el periodo en Contabilidad y resincronice (ver más arriba).invalid RNC or Cédula — revisión preventiva: si aparece, escríbanos. Es un edge case que no debería pasar con el sanitizador actual.token incorrecto — el token API expiró o fue revocado en Mikrowisp. Reconecte con un token nuevo.connection refused / timeout — la URL de Mikrowisp no responde. Verifique que el servidor esté arriba y accesible desde la red de Axentra.Abra el detalle del e-CF (clic en la fila → drawer). Arriba del timeline aparece el motivo exacto de la DGII en un panel rojo. Errores típicos en CerteCF:
El RNC Emisor X, no tiene una postulación activa — el tenant no completó (o le caducó) la postulación en CerteCF. Vuelva a correr el Asistente de Certificación.Secuencia NCF agotada — solicite una nueva secuencia desde la Oficina Virtual.Razón Social Emisor no coincide — revise Configuración → Empresa → Razón Social y vuélvalo a sincronizar.Para reintentar manualmente: botón Reintentar en la fila.
¿Algo no encaja? Escríbanos a soporte@axentra.com.do con: