Transferencias entre compañías¶
Para quién es esta guía
Para operaciones y contabilidad cuando los equipos deben cambiar de propietario entre Reyder Enterprises y Axis Mobile; por ejemplo, Reyder compró inventario a un proveedor y luego Axis compra una parte para revenderla.
Qué logrará: transferir un lote de equipos de una compañía a otra y dejar reflejada la contabilidad: venta en la compañía origen y recepción en la compañía destino.
Cuándo usar este flujo¶
- Reyder recibió una PO de proveedor, pero Axis comprará algunos de esos equipos.
- Axis compró inventario directamente, pero el almacén de Reyder lo guardará y venderá; la propiedad debe pasar a Reyder.
- Una compañía transfiere inventario a la otra por razones operativas.
Para mover equipos entre ubicaciones de la misma compañía, use una tarea de almacén Relocate. Las transferencias entre compañías se usan específicamente cuando cambia la propiedad.
Cómo funciona la transferencia¶
Una orden de transferencia genera dos documentos enlazados mediante Device Inventory:
- una sales order en la compañía origen; la compañía A vende a la B;
- una purchase order en la compañía destino; la compañía B compra a la A.
El módulo enlaza ambos documentos. El manifiesto de recepción destino no se crea al confirmar la PO. Se crea cuando se completa el delivery manifest de origen, para evitar manifiestos duplicados. Por eso el destino espera hasta que el origen realmente envíe.
Transfer Order → SO de origen (confirmada)
↓ Device Inventory crea y enlaza
PO destino (creada y confirmada; espera el envío)
↓
Se completa el delivery manifest de origen
↓
Receiving Manifest destino (se crea en este momento)
↓
Verificar + Complete Receipt
↓
Los equipos pertenecen ahora a la compañía destino
Paso 1 — Crear la orden de transferencia¶
Abra Device Ops → Fulfillment → Inter-Company Transfers → New.
Complete:
- Source Company — compañía propietaria actual de los equipos.
- Destination Company — compañía que será propietaria después de la transferencia.
- Source Location — almacén o estante desde donde salen.
- Destination Location — ubicación de llegada en la otra compañía.
Seleccionar los equipos¶
Elija el Selection Mode correspondiente:
| Modo | Qué hace |
|---|---|
| By Manifest | Incluye todos los equipos disponibles y aptos para transferir de un receiving manifest; sirve para un envío entrante completo |
| By Purchase Order | Incluye todos los equipos disponibles y aptos de una PO, aunque se recibieran en varios manifiestos |
| By Product Group | Filtra por modelo, capacidad y Supplier/PO Grade; sirve para transferir parte de un lote homogéneo |
Seleccione los equipos. El precio toma automáticamente el purchase_cost; las
transferencias entre compañías se hacen al costo, sin margen adicional.
Un lote recién recibido no tiene que terminar QC primero
La transferencia vende los equipos como As Received (Supplier/PO Grade). Un equipo en Pending QC se puede seleccionar inmediatamente después de recibirlo. Un equipo que ya está In QC o que se conoce como QC Failed permanece bloqueado. En la vista previa verifique IMEI, modelo, capacidad, color, Supplier/PO Grade, Intake Lock, estado de QC y costo; no sustituya un equipo que solo parece similar.
Si la cantidad de la vista previa es menor que el lote físico, deténgase y revise los IMEI faltantes. Pueden estar reservados o vendidos, estar en QC, haber fallado QC, tener una reserva minorista o no tener costo unitario positivo. No suponga que By Manifest omite esas protecciones.
Paso 2 — Confirmar la transferencia¶
- Revise los equipos seleccionados y pulse Confirm.
- Cuando la transferencia esté Confirmed, pulse Create Sale Order.
El segundo botón no está disponible antes de la primera confirmación, a propósito.
El sistema:
- Crea y confirma automáticamente una sales order en la compañía origen para el contacto de la compañía destino.
- Device Inventory crea y enlaza una purchase order equivalente en la compañía destino, con el contacto de la compañía origen como proveedor. La PO se confirma automáticamente.
- La SO origen crea un delivery manifest precargado con los IMEI.
- Todavía no crea el receiving manifest destino. Se creará cuando el delivery manifest de origen se marque Complete. El destino debe esperar a que el origen envíe.
La SO generada nunca convierte un manifiesto mixto en una sola fila genérica del modelo. Crea una fila As Received separada para cada combinación exacta de:
- modelo;
- capacidad;
- color;
- grado de entrada Supplier/PO normalizado;
- estado de bloqueo de entrada; y
- costo unitario.
Dos teléfonos con la misma promesa y el mismo costo pueden compartir una fila. Una
diferencia de capacidad, color, grado, bloqueo o costo queda en otra fila. Cada IMEI
exacto conserva su propio purchase_cost. No combine ni haga menos estrictas estas
filas generadas: son la protección que permite escanear correctamente los IMEI
precargados, incluidos los equipos Pending QC.
La transferencia cambia a Sale Order Created. El origen tiene un delivery manifest que procesar; el destino tiene una PO en espera.
Paso 3 — El origen envía¶
El equipo de almacén de la compañía origen procesa una entrega normal:
- Abra el delivery manifest desde el botón inteligente de la SO origen.
- Pulse Scan IMEIs y escanee cada teléfono físico contra los requisitos precargados; consulte Manifiestos de entrega.
- Pulse Finish IMEI Scan, revise la confirmación y después pulse Complete Delivery cuando los teléfonos salgan físicamente. Una caja es opcional y no se crea automáticamente para esta transferencia.
Al enviar:
- los equipos siguen Reserved y continúan perteneciendo al origen mientras el comprador verifica la recepción exacta; todavía no son una venta
Solda cliente externo; - para toda transferencia con costo positivo, el asiento COGS configurado es obligatorio en la contabilidad de origen. Si falta configuración contable en el origen, Complete Delivery se bloquea; no omita ese control;
- se crea una factura de cliente entre compañías (
out_invoice) y, mediante el reflejo de Odoo, aparece una factura de proveedor en Draft por el mismo importe en el destino.
Paso 4 — El destino recibe¶
Cuando se completa el delivery manifest del origen, el sistema crea automáticamente el receiving manifest destino. El almacén de la compañía destino procesa una recepción normal:
- Abra el receiving manifest desde el botón inteligente de la PO destino; aparece después de que el origen envía.
- Pulse Verify Supplier IMEI List y escanee cada IMEI físico contra la lista exacta creada por el envío de origen.
- Pulse Complete Receiving, revise el diálogo y después pulse Complete Receipt.
Si todavía no aparece el receiving manifest
Revise el delivery manifest de origen. Si sigue In Progress o Draft, el manifiesto destino todavía no debe existir; solo se crea cuando el origen llega a Complete. El destino debe esperar ese traspaso y no crear un manifiesto manual.
Al recibir:
owner_company_idcambia a la compañía destino;- los equipos vuelven a Available bajo la compañía destino después de verificar el traspaso exacto;
- el
stock.quantde cada equipo queda en el almacén de la compañía destino; - cuando la configuración contable del destino es válida y el valor recibido es distinto de cero, se publica el asiento de recepción, débito a Valuation / crédito a GRNI. Un valor cero o una configuración faltante puede completar la recepción con advertencia y sin asiento; Contabilidad debe revisar esa advertencia o asiento faltante antes de cerrar la conciliación de la transferencia.
Los equipos ya pertenecen y están almacenados en la compañía destino.
Entrega directa a la propietaria (opcional)¶
Si la compañía destino quiere que el proveedor envíe los equipos directamente a su ubicación, sin pasar por el almacén de origen, marque Direct to Owner en la PO del proveedor creada en el origen. Los equipos viajan del proveedor al destino.
Este caso se usa, por ejemplo, cuando Axis compra equipos que Reyder ordena en su nombre, pero Reyder no debe manipularlos físicamente.
Complete todo el traspaso:
- En Reyder, cree la PO al proveedor externo.
- Configure For Company = Axis Mobile y active Direct to Owner.
- Confirme la PO de Reyder. Odoo crea la SO entre compañías y la PO compradora enlazada.
- En la PO de Reyder/origen, use Upload Supplier IMEI List. Este manifiesto de origen es solamente para cargar el archivo; no escanee físicamente los teléfonos en Reyder.
- Revise la vista previa e importe. Odoo refleja esa lista exacta en el Receiving Manifest de la PO de Axis/compradora.
- Cambie a la compañía Axis y abra la PO compradora enlazada.
- Cuando lleguen los teléfonos, abra Verify Supplier IMEI List, escanee el traspaso exacto y complete la recepción.
No cree directamente en Axis una PO al proveedor externo. La cadena entre compañías crea la PO de Axis y su proveedor debe seguir siendo Reyder.
Resumen contable¶
Compañía origen¶
| Evento | Asiento |
|---|---|
| Se envía la entrega | Para equipos con costo positivo, débito a COGS / crédito a Device Valuation obligatorio; si falta configuración en origen, se bloquea la finalización |
| Factura de cliente | out_invoice para la compañía destino, publicada automáticamente |
Compañía destino¶
| Evento | Asiento |
|---|---|
| Se completa el receiving manifest | Débito a Device Valuation / crédito a GRNI solo con configuración válida en destino y valor recibido distinto de cero; de lo contrario Contabilidad revisa la advertencia o asiento faltante |
| Factura de proveedor | in_invoice de la compañía origen en Draft; requiere publicación manual |
La factura de proveedor Draft en el destino es intencional. Contabilidad la revisa antes de publicarla para confirmar el traspaso entre compañías.
Antes de publicar, contabilidad debe comparar la factura de cliente de origen, la factura de proveedor Draft del destino y la asignación de cuentas aprobada. La política contable detallada pertenece al manual privado de finanzas.
Configuración necesaria¶
Antes de la primera transferencia, compruebe estos ajustes en Settings → Inventory → Inter-Company Device Transfers:
- Inter-Company Partner — contacto que representa a la compañía cuyos ajustes está editando; Reyder selecciona el contacto de Reyder y Axis el de Axis.
- Device Proxy Purchase Vendor — normalmente Reyder en Axis, para impedir que una PO de equipos al proveedor externo se cree en la compañía equivocada.
- Inter-Company Sale Journal — diario de ventas para facturas entre compañías.
- Default Transfer Location — ubicación predeterminada de las recepciones.
- un diario Purchase activo en la compañía destino.
- acceso a la compañía destino para la persona que completa/publica el traspaso de origen.
Los ajustes pertenecen a cada compañía. Configure ambos lados en su contexto correspondiente. Cada uno usa el contacto que lo representa a sí mismo, o el contacto principal de la compañía cuando el ajuste opcional está vacío.
Problemas comunes¶
La PO entre compañías no se creó automáticamente
Revise Inter-Company Partner y el contacto principal de la compañía destino. La SO origen confirmada debe usar un contacto que coincida con el contacto de la compañía destino o con su contacto entre compañías configurado. Corrija la configuración; no imite el enlace con campos de texto libre.
El destino tiene una PO, pero no un receiving manifest
Es lo esperado hasta que el origen envíe. El manifiesto destino aparece únicamente cuando el delivery manifest de origen llega a Complete. Si sigue In Progress, espere. Si el origen ya muestra Complete y el destino sigue sin manifiesto, envíe a soporte las dos referencias y la hora de finalización.
Los equipos aparecen en las dos compañías después de transferir
Identifique el paso que falta. La propiedad cambia al completar el receiving manifest. Si el origen envió, pero el destino no completó la recepción, los equipos siguen perteneciendo al origen. Complete el manifiesto destino; no edite el campo de propiedad manualmente.
La factura de proveedor destino no coincide con la factura de cliente origen
Ambos importes se calculan sumando purchase_cost de los IMEI transferidos. Si no
coinciden, alguien probablemente editó uno de los documentos después de crearlo.
Compare los IMEI y valores de purchase_cost línea por línea y siga el proceso
contable aprobado para corregir o volver a publicar.
¿Puedo cancelar una transferencia en curso?
La cancelación normal solo es segura antes de Complete Delivery en el origen. Después de la entrega origen ya existen efectos de COGS y factura, aunque el comprador no haya recibido. Deténgase y pida a inventario y contabilidad una reversión controlada; no cancele documentos por separado. Después de la recepción destino, use un proceso aprobado de transferencia inversa y no edite campos de propiedad.