Libro de descubrimiento de Odoo y preparación SUNAT para Perú
1. Cree un libro con propietario, versión y evidencia
Abra un libro compartido con permisos de lectura y comentario controlados. Asigne un propietario del cliente, un responsable de implementación y un revisor contable. Incluya hojas para contribuyentes, establecimientos, documentos, series, operaciones, impuestos, posiciones fiscales, canales, custodia de credenciales, proveedores, CDR, excepciones, volúmenes, datos maestros, adjuntos, retención, decisiones y aceptación.
Cada fila necesita identificador estable, estado, fuente, fecha, propietario, evidencia adjunta y decisión pendiente. Use estados comprensibles como borrador, esperando evidencia, aprobado y fuera de alcance. Si contabilidad y sucursal describen la misma venta de forma distinta, conserve ambas versiones y programe la decisión en lugar de elegir una sin registro.
«Revisado el 5 de noviembre de 2026». El contenido es una herramienta de descubrimiento; la obligación concreta se revalida con el contador peruano y los proveedores antes de configurar producción.
2. Documente contribuyente, régimen y obligación por entidad
Registre denominación, RUC, entidad legal, régimen confirmado, moneda, periodo contable, contador responsable y actividad. Añada quién emite, quién recibe, quién posee inventario y quién contrata al proveedor de emisión. No utilice el nombre comercial de una sucursal como sustituto de la entidad contribuyente.
La página de obligados CPE de SUNAT señala una obligación general con excepciones, incluido el Nuevo RUS (New RUS). El contador documenta si la entidad está obligada, para qué operaciones y desde qué condición verificada; no se generaliza una regla a otras entidades. Registre también documentos de compra recibidos, proveedores, validación y volumen esperado de entrada y salida. El marco del sistema de emisión del contribuyente ayuda a ordenar las preguntas sin reemplazar la decisión profesional.
3. Audite RUC, establecimientos e identificadores de las muestras
Para cada entidad y tercero de la muestra, registre tipo y número de identificación, denominación revisada y fuente. Use la consulta oficial del RUC para verificar por separado que el estado del contribuyente sea Activo y que la condición del domicilio fiscal sea Habido. Archive la evidencia, la fecha y el revisor. La ficha maestra solo cambia tras una revisión autorizada; la consulta no se convierte en una actualización automática de clientes o proveedores.
En otra hoja relacione entidad, establecimiento, código asignado, dirección operativa, almacén, diario y responsable. Añada UNSPSC por producto o servicio cuando aplique, con propietario de clasificación y estado. Las pruebas incluyen identificador ausente, formato no admitido, un estado o una condición que exija revisión, establecimiento equivocado y UNSPSC sin aprobar. No importe valores dudosos en masa para completar el prototipo.
4. Construya una matriz para los cuatro documentos del alcance
Cree filas separadas para Factura, Boleta, Nota de Crédito y Nota de Débito. Para cada una anote entidad, diario, serie, operación, requisitos de tercero, moneda, impuestos, posición fiscal, referencia al documento original y al flujo de corrección aplicable, representación PDF y canal. La localización peruana de Odoo 19 documenta estos cuatro flujos de cliente y sus secuencias; el libro no añade otros tipos de comprobante al compromiso.
Adjunte muestras válidas y casos negativos: identificador faltante, duplicado, serie incorrecta, importe inconsistente y referencia inválida. Compare pantalla, XML y PDF, incluidos nombres largos, caracteres especiales, varias páginas y adjuntos. Registre volumen diario, picos, cantidad máxima de líneas y documentos entrantes que requieren validación. La prueba de impresión o lectura del PDF no sustituye la revisión del XML ni la respuesta fiscal.
5. Decida el canal y la propiedad de credenciales antes del prototipo
Documente la opción elegida entre Odoo IAP/Digiflow, Digiflow directo o conexión directa con SUNAT, todas dentro del flujo UBL 2.1 documentado para Odoo 19. Registre el contrato, el ambiente, los endpoints o la configuración aplicable y los metadatos no sensibles del certificado y del usuario SOL cuando corresponda: custodio, referencia segura, fecha de renovación, acceso de emergencia y procedimiento de revocación. No incorpore al libro contraseñas, archivos de certificados, claves privadas ni credenciales completas.
La guía XML de Factura UBL 2.1 y el manual del programador de SUNAT sirven para revisar estructura y comunicación. Diseñe casos de credencial inválida, certificado vencido en la simulación, tiempo de espera y respuesta no disponible. La configuración técnica se aprueba con evidencias de cada ambiente y con un procedimiento para producción.
6. Distinga OSE, PSE y la responsabilidad del emisor
Si el modelo utiliza un OSE, registre que verifica requisitos de emisión y envía comprobantes validados y constancias a SUNAT conforme a la fuente oficial de OSE. Si utiliza un PSE, documente su servicio de emisión por cuenta del emisor según la fuente oficial de PSE. No mezcle las funciones ni atribuya una de ellas a Oakland o Odoo.
En la evaluación del proveedor incluya registro consultado por el cliente, documentos admitidos, canal, formato de respuesta, soporte, contingencia, reintentos técnicos previos a la aceptación, acceso a XML y CDR, retención y salida del servicio. Registre quién contrata, quién supervisa y quién decide un cambio. El emisor conserva su responsabilidad frente a SUNAT; el proveedor y el implementador ejecutan únicamente las tareas escritas en la matriz.
7. Diseñe CDR, correcciones, reintentos y retención como un ciclo completo
El tablero separa contabilizado, XML generado, enviado, respuesta recibida y evidencia archivada. La constancia de recepción (CDR) puede quedar aceptada, aceptada con observación o rechazada, según el documento y el canal. Para cada resultado registre código, descripción íntegra, documento, fecha, responsable, acción y archivo. La consulta de validez de SUNAT se guarda como evidencia complementaria cuando se utiliza y no reemplaza la constancia de recepción (CDR).
Distinga los errores técnicos o de validación previos a la aceptación, que pueden seguir un reintento controlado sin duplicar, de una CDR formalmente rechazada. Si un comprobante enviado individualmente recibe una CDR rechazada, carece de validez tributaria y el emisor genera un nuevo comprobante electrónico que corrige las causas del rechazo. Si la CDR rechazada corresponde a un Resumen Diario, se genera un nuevo resumen corregido conforme al procedimiento aprobado; no se duplican las Boletas incluidas ni se las declara inválidas solo por el rechazo del resumen. Una Nota de Crédito o de Débito no subsana una Factura rechazada. Las notas se aplican a una Factura con CDR aceptada o a una Boleta previamente otorgada (BVE otorgada), según el documento y el canal. Revise las fuentes oficiales de Nota de Crédito y Nota de Débito; las cancelaciones siguen la regla aprobada para cada documento y canal.
Para Boleta con envío directo a SUNAT, registre las ventas en el resumen diario y archive la CDR del resumen, documentada como aceptada o rechazada. La evidencia por venta vincula ticket, identificador del resumen y CDR de ese resumen; si el documento y el canal prevén una respuesta individual, vincule la CDR individual. Consulte la operatividad publicada por SUNAT para revisar el flujo aplicable. Un Resumen Diario rechazado exige un nuevo resumen corregido, no nuevas Boletas ni una declaración de invalidez de todas las incluidas solo por ese resultado. Añada retención de XML, PDF, tickets, CDR y adjuntos, roles de acceso, exportación, recuperación y borrado autorizado. Un estado enviado no se archiva como aceptación.
8. Relacione IGV, PCGE, reportes y PEN con decisiones contables
En la hoja de operaciones registre si la venta o compra está gravada, exonerada, es exportación o requiere otro análisis. La tasa del IGV aplicable a las operaciones gravadas es del 18 %, conforme al lineamiento oficial de IGV; la plantilla oficial de impuestos muestra su configuración de partida. El contador aprueba impuestos y posiciones fiscales por caso, no una aplicación universal.
Mapee el PCGE y las cuentas adaptadas, y defina revisiones de RVIE, RCE y PLE con archivo, parámetros, conciliación y firma. Estas salidas requieren revisión profesional y cualquier presentación sigue el procedimiento autorizado. Para PEN y moneda extranjera registre moneda de compañía y transacción, contravalor, fuente y fecha del tipo de cambio, residual y aprobador. La política de tipos de cambio de SUNAT obtenidos de forma automática o manual queda escrita y probada con cobros parciales.
9. Incorpore operación, proveedores, dispositivos y hosting al mismo descubrimiento
El libro no termina en contabilidad. Añada recepción, entrega, GRE 2.0 del remitente, valorización y cargos de importación; el alcance no incluye GRE del transportista. La GRE se envía directamente a SUNAT y no dispone de entorno de pruebas; incluso una guía generada por error se transmite a SUNAT. Por ello, su validación requiere un procedimiento específico aprobado por el responsable fiscal y no debe tratarse como un ejercicio ordinario en sandbox.
Para POS registre red, dispositivos, caja en PEN, clientes identificados o anónimos, pagos mixtos, cierre y reconexión. La evidencia fiscal por venta se vincula a la CDR individual o al ticket y resumen diario con la CDR de ese resumen, según el documento y el canal. Los pedidos pueden conservarse durante una interrupción; la factura electrónica se genera después de reconectar y las terminales de pago requieren conexión.
Registre Mercado Pago solo para la cuenta peruana validada, bancos y proveedores con importación de extractos alternativa, y necesidades de planillas como evaluación separada porque Perú no aparece en la lista revisada de localizaciones de nómina de Odoo 19. En hosting anote aplicaciones, producción, respaldos, restauración, ubicaciones, transferencias y proveedores. No marque una ubicación peruana de datos como resuelta sin evidencia específica del servicio contratado.
10. Termine con prototipo, responsabilidades y criterios de aceptación
Seleccione operaciones de alto impacto y ejecútelas con datos controlados de principio a fin. El prototipo debe mostrar el registro, validación, XML, transmisión, CDR individual o de resumen diario según corresponda, asiento, reporte y excepción. Clasifique cada brecha como configuración, procedimiento, reporte, integración soportada, desarrollo, decisión contable o elemento fuera de alcance. Asigne responsable y prueba de cierre.
Las sesiones educativas OXP2026 sobre datos maestros y aceptación electrónica, evidencias, correcciones y límites de versión y transformación por procesos y propiedad de localización pueden orientar el taller. Las empresas que aparecen no son clientes ni referencias de Oakland. Este material educativo no acredita obligaciones SUNAT, capacidades peruanas ni cumplimiento en Perú; las fuentes oficiales y las pruebas del proyecto conservan esa función.
Cierre con una matriz que diga quién aporta datos, limpia, configura, contrata, valida y firma. Exija muestras válidas y negativas, paridad XML/PDF, CDR gestionada según documento y canal, conciliación en PEN, revisión de reportes, accesos y retención. Las fechas del plan se elaboran después de conocer dependencias; no se deducen de este libro.
Continúe con el libro de migración y conciliación en PEN, la lista de verificación de sucursal y POS y el plan de formación de Odoo en español por roles.