Configuración inicial¶
Para quién es esta guía
Para la persona que prepara el sistema por primera vez o verifica la configuración después de una migración. Los usuarios del día a día no necesitan esta página.
Qué logrará: configurar contabilidad, diarios, contactos entre compañías, integración con M360, grados y usuarios para que el módulo quede listo para producción.
Antes de empezar: el módulo Device Inventory ya debe estar instalado y deben existir las dos compañías, Reyder Enterprises y Axis Mobile. Si falta algo, resuélvalo primero.
Lista de configuración¶
Complete estos puntos en orden. Cada uno enlaza con su explicación detallada.
- [ ] Configurar la contabilidad de Device Inventory (un diario y tres cuentas)
- [ ] Configurar el diario de liquidaciones (diario de compras para facturas de proveedor)
- [ ] Configurar las transferencias de equipos entre compañías (contacto, diario y ubicación)
- [ ] Configurar Retail Return Storage Location para cada compañía que mantiene los equipos
- [ ] Revisar Device Proxy Purchase Vendor para cada compañía
- [ ] Tomar una decisión explícita sobre el riesgo de Temporary Zero-Cost Exception
- [ ] Configurar la integración de QC con M360 (credenciales y modo de API)
- [ ] Comprobar que existan los grados (Excellent, Good, Fair y Poor)
- [ ] Asignar usuarios a los grupos de seguridad
- [ ] Crear el primer acuerdo de consignación
- [ ] Cambiar la API de M360 de Testing a Live cuando esté listo para producción
Dónde están los ajustes¶
Todos los ajustes del módulo están en Settings → Inventory, agrupados al final de la página:
- Inter-Company Device Transfers
- Retail Operations
- Device Inventory Accounting
- Wholesale Device Sales
- Consignment Settlement
- M360 QC Integration
- Gemini Invoice OCR
- Quick Capture AI
Device Inventory crea y enlaza por sí mismo los documentos entre compañías. Configure los ajustes descritos aquí y no active otro mecanismo automático para sincronizar órdenes.
Función de cada compañía¶
El módulo está diseñado para un modelo de consignación entre dos compañías:
| Compañía | Función |
|---|---|
| Reyder Enterprises | Consignataria: opera el almacén, gestiona las ventas y factura a los clientes |
| Axis Mobile | Propietaria de los equipos: entrega inventario en consignación a Reyder y recibe los pagos de liquidación |
También puede usarse otra distribución. Cada acuerdo activo representa una pareja de propietaria y consignataria. Se admiten varias propietarias y varias consignatarias; Odoo bloquea únicamente un acuerdo duplicado para la misma pareja en el mismo orden.
Contabilidad de Device Inventory¶
Settings → Inventory → Device Inventory Accounting
Configure los cuatro campos antes de usar el módulo en producción. Los errores no se comportan igual en todos los casos: la entrega bloquea COGS y la venta minorista bloquea factura/COGS si falta configuración, pero una recepción puede mostrar una advertencia y dejar inventario disponible sin el asiento esperado. Cualquier advertencia contable significa detenerse y escalar.
Configurar no equivale a aprobar una política contable
El controlador o CPA debe aprobar la asignación de cuentas y el tratamiento de la consignación antes de usar producción. Esta guía explica dónde están los ajustes de Odoo; no define una política GAAP ni autoriza a un operador a reparar asientos.
| Ajuste | Qué es | Ejemplo |
|---|---|---|
| Device Stock Journal | Diario para movimientos de inventario de equipos: recepción, COGS y ajustes | Inventory Valuation |
| Device Valuation Account | Activo del balance que mantiene el valor del inventario disponible | Stock Valuation |
| Device Stock Input Account | Pasivo/gasto de mercancía recibida no facturada (GRNI), que se compensa cuando llega la factura del proveedor | Products to Receive |
| Device COGS Account | Gasto que se carga cuando se vende un equipo | Cost of Goods Sold |
Cómo se usan estas cuentas¶
- Recepción: débito a Valuation / crédito a Stock Input; aumenta el inventario y registra la obligación con el proveedor.
- Venta: débito a COGS / crédito a Valuation; mueve el valor de activo a gasto.
- Factura al cliente: débito a AR / crédito a Revenue; es el flujo estándar de Odoo y usa el diario de ventas de la compañía, no Device Stock Journal.
La política contable aprobada debe indicar la asignación definitiva para liquidaciones, ventas minoristas y operaciones entre compañías. Mantenga esa política en el manual privado de finanzas.
Pasos¶
- Abra Settings → Inventory y baje hasta Device Inventory Accounting.
- Seleccione Device Stock Journal; debe ser un diario Miscellaneous/general.
- Seleccione las tres cuentas.
- Pulse Save.
Liquidación de consignación¶
Está en la misma página, en la siguiente sección. Tiene un campo:
| Ajuste | Qué es |
|---|---|
| Settlement Journal | Diario de compras utilizado para crear las facturas de proveedor que se pagan a la propietaria de los equipos, Axis |
Cuando se confirma un informe de liquidación de la consignataria, el flujo normal crea y publica automáticamente una factura de proveedor para Axis por el total de la propietaria. Si no existe Settlement Journal ni otro diario de compras que pueda usarse, el informe puede quedar Confirmed, mostrar una advertencia y no tener factura. Es una detención contable: configure el diario y use el proceso de recuperación aprobado antes de pagar.
Pasos¶
- En la sección separada Consignment Settlement, busque Settlement Journal.
- Seleccione un diario de tipo Purchase.
- Pulse Save.
Transferencias de equipos entre compañías¶
Settings → Inventory → Inter-Company Device Transfers
Solo se necesita si utiliza órdenes de transferencia entre compañías. Omita esta sección si los equipos nunca cambian de propiedad entre Reyder y Axis.
| Ajuste | Qué seleccionar |
|---|---|
| Inter-Company Partner | Contacto que representa a esta compañía en los documentos de la otra. En los ajustes de Reyder, seleccione el contacto de Reyder; en los de Axis, el contacto de Axis. Déjelo vacío solo si el contacto principal de la compañía ya es correcto. |
| Device Proxy Purchase Vendor | Proveedor que esta compañía debe usar en las PO directas de equipos. En la configuración normal, Axis usa Reyder para que la PO al proveedor externo se cree en Reyder con For Company = Axis, nunca directamente en Axis. Déjelo vacío solamente si este control no se necesita de forma intencional. |
| Inter-Company Sale Journal | Diario de ventas usado para facturas entre compañías; normalmente el diario estándar Sales |
| Default Transfer Location | Ubicación donde se reciben las transferencias entrantes, por ejemplo WH/Input |
Configure cada compañía dentro de su propio contexto. Cada lado apunta al contacto que lo representa a sí mismo, no al contacto de la otra compañía.
Antes de la primera transferencia real, compruebe también que:
- la persona que completará la entrega de origen tenga permiso para entrar en la compañía destino;
- la compañía destino tenga un diario Purchase activo; y
- el almacén y la ubicación destino pertenezcan a la compañía destino.
Estos requisitos son indispensables para crear la factura de proveedor reflejada y completar el traspaso de recepción.
Operaciones minoristas¶
Settings → Inventory → Retail Operations
Configure Retail Return Storage Location por separado para cada compañía que mantiene físicamente equipos reservados para retail. Seleccione una ubicación interna marcada Storage y perteneciente a esa misma compañía. Odoo la copia a cada reserva para que Release o Cancel de una reserva activa devuelva los IMEI no vendidos a un destino determinista; nunca elige la primera ubicación de otra compañía.
Si el ajuste está vacío, Odoo solo permite una alternativa inequívoca de la compañía: una sola zona Storage o una sola ubicación principal de almacén. Si existen varios destinos posibles, bloquea la operación hasta que un administrador configure el campo.
No active una segunda ruta de sincronización
Device Inventory crea y enlaza directamente la PO destino al confirmar su SO entre compañías. No use además la automatización genérica de Odoo para sincronizar órdenes en este flujo; dos rutas de creación pueden producir documentos duplicados.
Integración de QC con M360¶
Settings → Inventory → M360 QC Integration
M360 aporta la evidencia de diagnóstico necesaria para el flujo actual QC Complete / Reyder QC Verified. Configúrelo antes de prometer resultados verificados por Reyder. Puede dejarlo desactivado solo si la operación venderá como As Received y no marcará los equipos como QC Complete.
| Ajuste | Qué es |
|---|---|
| Enable M360 Integration | Interruptor principal |
| Auth Code | Código proporcionado por M360 |
| Auth Token | Token proporcionado por M360 |
| Secondary Auth Code | Segunda cuenta de M360 opcional |
| Secondary Auth Token | Token de la segunda cuenta opcional |
| API Mode | Testing durante la preparación; Live en producción |
Pasos¶
- Marque Enable M360 Integration.
- Pegue el Auth Code y Auth Token del portal de M360.
- Si algunos equipos se prueban con una segunda cuenta, complete también Secondary Auth Code y Secondary Auth Token. Deje ambos vacíos si usa una sola cuenta.
- Establezca API Mode en Testing.
- Pulse Save.
- Pulse Test Connection para comprobar cada juego de credenciales configurado.
- En un equipo de prueba conocido, use Sync from M360. Si obtiene datos de cualquiera de las cuentas, las credenciales funcionan.
- Cambie API Mode a Live cuando esté listo.
Ventas mayoristas de equipos¶
Settings → Inventory → Wholesale Device Sales
Revise Temporary Zero-Cost Exception antes de salir a producción. Puede venir activada en una instalación nueva o por defecto para la compañía. Si está activa, una venta mayorista autorizada puede enviar un teléfono que coincide con los demás requisitos pero carece de costo de compra o tiene costo cero, siempre que se registre un motivo auditable. No omite los controles de modelo, capacidad, color, Selling As, grado, bloqueo, propiedad, fallo de QC, disponibilidad ni cantidad.
Decisión recomendada para producción:
- desactívela cuando completar el costo sea obligatorio; o
- déjela activa solo con autorización escrita de gerencia/contabilidad y revise cada excepción.
Registre la decisión y la persona que la aprobó en el manual privado de finanzas.
Grados de equipos¶
Device Ops → Configuration → Device Grades
El módulo instala cuatro grados estándar: Excellent, Good, Fair y Poor. Cubren la mayoría de los casos. No los cambie de nombre ni los elimine, porque los registros existentes apuntan a ellos.
Puede crear un grado adicional, por ejemplo “Refurbished”. Pulse New y complete:
- Grade Name, obligatorio;
- Code, obligatorio, de 10 caracteres como máximo y único para la Company elegida;
- la Company correspondiente, o déjela vacía únicamente si el grado se compartirá de forma intencional; y
- Description, opcional.
Pulse Save. No reutilice un código que ya exista para esa compañía.
Usuarios y permisos¶
Settings → Users & Companies → Users
Cada usuario necesita los grupos correspondientes a su función:
| Función | Grupos que se deben asignar |
|---|---|
| Operador de almacén | Stock User |
| Supervisor de almacén | Stock Manager |
| Ventas | Salesman + Stock User (necesario para abrir y escanear manifiestos IMEI) |
| Gerente de ventas | Sales Manager + Stock User |
| Contabilidad | Accountant + Stock User para leer informes de liquidación; añada Sales Manager solo si esa persona realmente administra ventas |
| Administrador | Todos los anteriores + ambas compañías |
Asignación de compañía: indispensable para la separación¶
- Una persona que trabaja solo para Axis debe tener Companies = Axis Mobile solamente.
- Una persona que trabaja solo para Reyder debe tener Reyder solamente.
- Una persona que trabaja para ambas puede tener ambas, pero esa cuenta no sirve para probar la separación de datos.
En el perfil usado para comprobar el aislamiento de la propietaria, Companies debe contener solamente la compañía propietaria. Cualquier compañía adicional invalida la prueba. Consulte Seguridad y varias compañías.
Primer acuerdo de consignación¶
Cuando termine la configuración, cree el acuerdo Reyder ↔ Axis para permitir que los equipos fluyan. Use la guía Acuerdos de consignación.
Sin un acuerdo activo, Reyder no puede ver los equipos de Axis, asignarlos ni venderlos. Es el paso final que convierte la configuración en un sistema operativo.
Problemas comunes de configuración¶
Completé los campos contables, pero los valores no se guardan
Probablemente está trabajando bajo la compañía equivocada. Cada compañía tiene sus propios ajustes de Device Inventory Accounting. Cambie la compañía en el selector del encabezado, vuelva a abrir Settings y configure cada lado por separado.
No aparece el menú Device Inventory
Compruebe que el usuario tenga por lo menos el grupo Stock User. El menú depende de
la pertenencia al grupo.
La integración de M360 falla continuamente con error 401
Primero compruebe la compañía activa, API Mode y cada par completo y vigente de Auth Code + Auth Token configurado para esa compañía. Test Connection prueba todos los pares configurados; conserve el texto exacto del error e identifique qué par etiquetado falló. Cambie un token solo cuando M360 confirme que venció o fue revocado; no sustituya credenciales únicamente para hacer desaparecer el error.
Después de neutralizar la base, algunas tareas programadas necesarias están desactivadas
--neutralize desactiva las acciones programadas a propósito. Un administrador del
sistema debe revisar y habilitar solamente las necesarias en Settings → Technical →
Scheduled Actions, con Developer Mode. Los operadores del día a día no deben cambiar
esas tareas ni ejecutar comandos de base de datos.