Respaldo & Seguridad

Permite exportar e importar una copia completa de los datos del CRM en formato JSON. Funciona tanto en modo local como en la nube, y es el mecanismo oficial de portabilidad (derecho de exportar) cuando quieras cambiar de proveedor o auditar tu información fuera del sistema.

Cómo usarlo

1. Abre Configuración → Respaldo.
2. Para descargar, pulsa Export Full Backup (JSON). El archivo queda en tu carpeta de Descargas con el nombre SimplifyCRM_Backup_<modo>_<fecha>.json.
3. Para restaurar, usa Import Backup y selecciona un archivo .json previamente exportado.
4. Para exportar una tabla concreta en CSV, abre el acordeón Individual CSV Exports.

Qué incluye el respaldo

• Contactos, oportunidades, proyectos, tareas.
• Facturas, cotizaciones, gastos, SOPs.
• Servicios, catálogo de productos/servicios unificado, bundles.
• Contratos de servicio.
• Secuencias NCF (rangos B-series autorizados por DGII).
• Visibilidad de registros y configuración del tenant.
• API keys, webhooks y addons activos (solo en modo local).

Tablas DGII (solo en modo nube)

A partir de v5 del formato de respaldo, en modo nube el JSON también incluye:

• feEmittedEcf — todos los e-CFs emitidos: eNCF, tipo, RNC emisor/comprador, montos, estado DGII, trackId, security_code, qr_url. Hasta 5,000 registros más recientes.
• feReceivedEcf — e-CFs recibidos de proveedores. Hasta 5,000 registros.
• feEcfSequences — rangos E-series autorizados por DGII con sus contadores actuales.
• feBncfSequences — rangos B-series con sus contadores actuales.
• feJournalCreationErrors — tabla forense de errores en creación de asientos contables al recibir e-CFs.
• feQrImportsFailed — tabla forense de imports de QR fallidos.

No incluye el XML firmado de cada e-CF (xml_signed / xml_unsigned / xml_content). Esto mantiene el JSON manejable (5–50 MB típicos vs varios GB con XMLs).

Si tu respaldo trae el flag dgiiBackupTruncated, significa que alguna tabla excedió el límite por tabla y el snapshot es parcial. Para archivo legal completo (auditoría DGII, IR-2 retroactivo) aguardá la próxima función de export server-side que incluye los XMLs firmados completos.

Certificado P12 (descarga aparte)

Tu certificado digital DGII (P12) NO se incluye en el respaldo JSON. Se descarga con un botón aparte:

• Por qué: quien tenga el P12 + contraseña puede emitir e-CFs en tu nombre. Forzar separación física del JSON añade defensa en profundidad.
• Cómo: botón 📥 Descargar certificado P12 en la sección Respaldo (solo modo nube).
• Dónde guardarlo: USB cifrado, gestor de contraseñas o caja fuerte. NUNCA en el mismo lugar que el JSON.
• Si lo perdés: no podés autenticarte con DGII ni emitir e-CFs hasta cargar uno nuevo. Re-emitir un certificado en Viafirma toma días + costo.

Importante: Supabase respalda automáticamente tu base de datos cada día (7 días de retención) pero NO respalda los archivos de Storage, incluyendo el P12. La descarga manual es la única forma de tener una copia portable.

Modo local vs modo nube

• Local: el respaldo refleja lo que hay en este dispositivo. La importación reemplaza los datos de este dispositivo. Las tablas DGII no aplican (la emisión de e-CF requiere modo nube).
• Nube: el respaldo refleja lo que hay en Supabase para tu tenant. La importación reemplaza los datos del tenant para todas las personas y dispositivos que usan esa cuenta. Por eso el sistema pide escribir REPLACE para confirmar.

Restauración de tablas DGII — política de seguridad

Si el respaldo JSON contiene tablas DGII fiscales y vas a importarlo en modo nube, el sistema te muestra:

• Cuántas secuencias activas hay actualmente en la base de datos.
• Cuántas trae el respaldo.
• Cuántos e-CFs emitidos hay en la base de datos.

Por defecto NO se restauran las tablas DGII. Restaurar contadores viejos puede:

• Re-emitir un eNCF que ya fue autorizado por DGII (multa fiscal).
• Sobrescribir secuencias activas que están emitiendo en el momento.
• Romper la trazabilidad IR-2 / 606 / 607.

Solo si entendés las consecuencias y necesitás restaurar (escenario raro: recuperación de catastrofe en tenant nuevo), escribí literalmente DGII-OK cuando el sistema lo pida. Aún así, los triggers fiscales en la base de datos (migración 20260430000002_fe_sequences_fiscal_hardening.sql) bloquean transiciones inválidas como voided→active y DELETEs de secuencias usadas — el sistema te protege incluso si el JSON está malicioso.

Notas sobre migración local → nube

Cuando creas una cuenta en la nube con datos locales previos, el sistema ofrece migrar automáticamente. Ese flujo es distinto del respaldo:

• La migración transfiere todas las tablas soportadas de una sola vez.
• Las secuencias NCF no se migran automáticamente porque son estado fiscal sensible (contadores vivos autorizados por DGII). Después de migrar, reconfigúralas desde Config → NCF usando los mismos rangos que te otorgó la Oficina Virtual.
• Las integraciones (API keys, webhooks) son parte del respaldo JSON pero no tienen esquema en la nube: se re-crean desde el panel de Integraciones del tenant.

Buenas prácticas

• Exporta un respaldo antes de un cambio grande (importación masiva, cambios de configuración contable, o cierre de período).
• Guarda los respaldos fuera del dispositivo (Google Drive, Dropbox, disco externo).
• Mantén al menos 3 copias en ubicaciones distintas.
• En entornos compartidos (firmas que administran múltiples tenants), exporta antes de cada cierre fiscal.

Permisos

Solo roles con acceso al módulo Config pueden exportar o importar. La importación en modo nube tiene doble confirmación para evitar sobrescritura accidental por un miembro del equipo.