En este artículo
Presupuestos de Odoo desde correo y PDF: revisa productos y precios
Un cliente pide tres cajas de tornillos y cinco juegos de juntas. El PDF se lee bien. La decisión comercial sigue pendiente: cuántas unidades contiene una caja, qué artículo corresponde y si el precio solicitado está aprobado.
Trata la revisión de presupuestos de Odoo desde correo y PDF como una transformación controlada. Conserva la solicitud, resuelve productos y unidades contra el catálogo aprobado y toma los precios de la fuente autorizada. Vincula la aprobación a la revisión exacta antes de enviar. Las líneas ambiguas y los cambios de condiciones deben volver a revisión.
Investigación revisada: 5 de noviembre de 2026. Los datos del producto proceden de la documentación oficial de Odoo 20.0. La solicitud, el catálogo y los precios son sintéticos. Las comprobaciones descargables no se ejecutaron en Odoo ni con un modelo de IA. Especifican lo que una implementación debe demostrar.
¿Qué debe crear el proceso de recepción?
El proceso debe crear un borrador de venta que conserve la solicitud y muestre cada línea sin resolver. La extracción y la preparación necesitan permisos limitados a ese trabajo. Enviar un presupuesto y confirmar un pedido son decisiones separadas: la revisión interna del borrador no demuestra que el cliente haya aceptado sus condiciones.
Odoo 20 documenta acciones separadas de envío y confirmación; confirmar crea un pedido de venta. También documenta el ajuste configurable Mandatory Product. Exigir un producto vinculado no demuestra que sea el solicitado por el cliente.
Define el resultado antes de elegir cómo recibir las solicitudes. Según nuestra política propuesta, la identidad técnica puede preparar el borrador y adjuntar pruebas para revisión. No puede enviarlo, confirmarlo, prometer entregas ni crear artículos del catálogo. Una persona autorizada libera el presupuesto revisado mediante el proceso de ventas aprobado.
Son requisitos que deben implementarse y probarse, no afirmaciones sobre los permisos predeterminados de Odoo. Ocultar un botón no demuestra que otra vía de escritura esté bloqueada. Pide al responsable que muestre el resultado con la identidad real de integración y los controles de la aplicación.
| Paso | Resultado permitido | Evidencia necesaria |
|---|---|---|
| Capturar la solicitud | Conservar mensaje y adjuntos con una referencia. | Contenido original y revisión recibida. |
| Preparar candidatos | Proponer cliente, productos, cantidades y condiciones. | Ubicación de origen de cada valor propuesto. |
| Resolver líneas comerciales | Seleccionar artículos, unidades y precios aprobados. | Identificadores resueltos, contexto de precios y pendientes. |
| Revisar el borrador | Aprobar la revisión actual para la siguiente acción permitida. | Revisor, versión y valores materiales revisados. |
| Liberar el presupuesto | Enviar mediante el proceso de ventas autorizado. | Aprobación vigente y documento exacto enviado. |
¿Qué funciones nativas de Odoo debes demostrar primero?
Demuestra la entrada necesaria y el presupuesto resultante en la versión instalada antes de definir desarrollo a medida. Comprueba qué aplicación, configuración o módulo recibe la solicitud, qué crea y qué acciones permite después. Una función documental puede resolver parte del proceso sin demostrar la coincidencia de productos ni la aprobación comercial.
La documentación de PDF Quote Builder describe la composición de presupuestos salientes. Esa página no establece una vía para procesar cualquier PDF recibido de un cliente.
Lleva una muestra real cuyo uso esté autorizado y registra el resultado. ¿Se conserva la línea original? ¿Qué ocurre con un código desconocido? ¿Puede enviarse una línea preparada antes de revisarla? Confirma versión, edición, alojamiento y módulos del camino propuesto; una aplicación con nombre parecido no prueba compatibilidad.
La documentación de listas de precios de Odoo indica que los precios sugeridos pueden sobrescribirse en el pedido de venta. Seleccionar una lista no demuestra por sí solo que se cumpla tu regla de aprobación.
Si necesitas un proceso externo, comprueba su acceso y alojamiento antes de implementarlo. Mantén el mismo contrato de revisión, sea cual sea el mecanismo que prepara el borrador. Este artículo evalúa la decisión comercial; no afirma que falten todas las opciones nativas de recepción ni que sea necesaria una IA a medida.
¿Qué debe ver el revisor en cada línea del presupuesto?
El revisor necesita la solicitud original junto a la línea comercial resuelta y los motivos que la mantienen pendiente. Distingue lo escrito por el cliente, lo sugerido por la extracción y lo aprobado por el negocio. Así puede detectar errores de producto, unidad o precio sin reconstruir toda la conversación.
| Evidencia | Ejemplo | Decisión que permite |
|---|---|---|
| Referencia de origen | RFQ-204.pdf, página 1, línea 1. | ¿El revisor puede localizar la solicitud? |
| Texto del cliente | «3 cajas BOLT-M8-20, 100 unidades cada una». | ¿Qué artículo y cantidad se pidieron? |
| Resolución del catálogo | Identificador aprobado y variante seleccionada. | ¿Es el artículo vendible que se pretendía solicitar? |
| Conversión de unidades | 3 cajas × 100 unidades = 300 unidades. | ¿La cantidad valorada utiliza la unidad correcta? |
| Contexto de precio | Cliente, moneda, fecha aplicable y regla aprobada. | ¿Por qué está permitido ese precio unitario? |
| Excepción | Dos candidatos del catálogo o una petición de cambiar el precio. | ¿Quién debe resolver la duda? |
| Referencia de aprobación | Revisor y versión del borrador. | ¿La aprobación cubre la línea actual? |
Separa la identidad del cliente de la resolución del producto. Reconocer el nombre de una empresa no basta si existen varias cuentas con condiciones distintas. Consulta la guía de identidad y autoridad de campos de cliente cuando HubSpot participe en esa transferencia.
Un modelo puede proponer una coincidencia, pero conserva el candidato y el motivo de selección en el paquete de revisión. Un código de pieza desconocido necesita una correspondencia aprobada o una aclaración. No debe convertirse silenciosamente en un artículo nuevo porque crear la línea resulte más fácil que resolver su significado.
¿Cómo cambian las unidades y los precios el borrador?
Resuelve las unidades y la autoridad del precio antes de presentar un importe como total del presupuesto. Una extracción correcta puede producir un importe comercial incorrecto si convierte una caja en una unidad o un precio objetivo en uno aprobado. Mantén visibles las líneas pendientes y marca como incompleto cualquier subtotal que las excluya.
La solicitud ficticia RFQ-204 contiene tres líneas. El catálogo y los precios aprobados se inventaron para este cálculo. No son valores predeterminados de Odoo, precios de mercado ni resultados de un modelo.
| Solicitud del cliente | Decisión de revisión | Cálculo ilustrativo | Acción pendiente |
|---|---|---|---|
| 3 cajas BOLT-M8-20, 100 unidades cada una. | Usar 300 unidades del artículo aprobado. | 3 × 100 × 0,18 € = 54,00 €. | Confirmar embalaje y precio aplicable. |
| 2 cartuchos de filtro FX-2. | FX2-A y FX2-B siguen siendo variantes plausibles. | No se seleccionan precio ni importe de línea. | Preguntar qué variante se necesita. |
| 5 juegos de juntas SK-4, objetivo de 12 € por juego. | Separar el precio solicitado del precio aprobado de ejemplo: 15 €. | 5 × 15 € = 75,00 €; importe solicitado: 60,00 €. | Aprobar el precio comercial o negociar la solicitud. |
Las líneas primera y tercera suman un subtotal parcial de 54,00 € + 75,00 € = 129,00 €. Faltan el filtro sin resolver, los impuestos y el envío. Presentar 129,00 € como oferta completa ocultaría una decisión pendiente.
La diferencia de precio de los cinco juegos es de 15,00 €. Si el proceso copia el objetivo del cliente al campo de precio aprobado, concede ese importe sin una decisión comercial. Conserva ambos valores para que el revisor vea qué implicaría aprobarlo.
Ahora elimina «100 unidades cada una» de la primera línea. El documento sigue pidiendo tres cajas, pero falta la conversión. Retén la línea salvo que el catálogo aprobado o un acuerdo con el cliente determine el contenido de la caja. Una estimación familiar del modelo no sustituye ese acuerdo.
Si una revisión cambia tres cajas por cuatro, vuelve a evaluar cantidad y contexto de precio. Con la misma tarifa ilustrativa, 400 unidades serían 72,00 €, pero también puede ser necesario revisar la regla aplicable. No mantengas la aprobación anterior solo porque no cambió el código del artículo.
¿Cuándo debe volver a revisión un presupuesto aprobado?
Un presupuesto debe revisarse otra vez cuando cambie un valor material cubierto por la aprobación. Define esos valores: cuenta del cliente, producto o variante, cantidad, unidad, precio, moneda y condiciones comerciales. Al liberarlo, compara la revisión aprobada con el borrador actual y exige otra decisión si ya no coinciden.
La política propuesta autoriza enviar una versión concreta del borrador. No autoriza confirmar el pedido, sustituir un producto o cambiar después el precio. Conserva el documento exacto liberado con su revisión para poder establecer qué recibió el cliente.
Aplica el control en todas las vías de liberación. Una comprobación de interfaz no protege una llamada de integración que pueda evitarla. Pide una demostración de la acción prohibida con la identidad de recepción e inspecciona después el registro de negocio y las pruebas del mensaje saliente.
También debes distinguir una solicitud duplicada de una nueva revisión. Una copia reenviada debe vincularse al registro existente según la regla de identidad acordada. Un adjunto modificado exige comparación y una nueva decisión. La guía de recuperación de Odoo y n8n aborda reintentos y efectos duplicados una vez hecha esa distinción comercial.
¿Cómo aceptas el proceso sin inventar precisión de IA?
Acepta el proceso mediante resultados de negocio observados sobre solicitudes acordadas, incluidas las ambiguas y modificadas. Mide al modelo solo después de ejecutarlo con esas entradas. Una lista diseñada permite especificar el comportamiento esperado, pero no establece precisión de extracción, tiempo de revisión ni fiabilidad de un conector que no se ha ejecutado.
La matriz de revisión con 12 casos incluye las líneas del ejemplo, tamaño de caja desconocido, códigos no resueltos, moneda ambigua, solicitudes repetidas, adjuntos cambiados e intentos prohibidos de envío o confirmación. Todos los estados comienzan como NOT_RUN.
- Delimita la recepción. Nombra tipos de documento, idiomas, clientes y familias del catálogo admitidos. El resto permanece en una cola manual.
- Aprueba el resultado comercial esperado. Un revisor de ventas determina producto, unidad, precio y retenciones antes de evaluar sugerencias del modelo.
- Conserva el paquete completo. Guarda ubicaciones de origen, candidatos, decisiones finales y revisión del borrador para cada línea.
- Inspecciona las transiciones bloqueadas. Demuestra que las líneas pendientes y las aprobaciones desactualizadas no permiten liberar el presupuesto.
- Registra correcciones y esfuerzo. Tras una ejecución real, mide el trabajo del revisor y los errores que llegan al borrador final.
- Define la ampliación a partir de fallos observados. Las variantes ambiguas repetidas pueden exigir trabajo de catálogo o aclaraciones antes que otro modelo.
Para propuestas de correspondencia en una importación mayor, consulta la guía de validación de asignaciones con IA en Odoo. Este paquete acepta las líneas comerciales del presupuesto; no es una evaluación general de extracción documental.
Acompaña cada acción prohibida con otra válida que sí funcione. Un proceso que rechaza todos los envíos evita enviar el presupuesto equivocado, pero no completa la tarea de ventas. Las pruebas deben mostrar que el documento correcto y revisado llega al siguiente paso permitido.
¿Qué automatizaríamos primero?
Empezaríamos por un catálogo limitado y una identidad que solo prepare borradores. Un revisor debe completar la decisión comercial con las fuentes visibles. Amplía el alcance después de observar correcciones y excepciones reales. Demuestra primero las funciones nativas y encarga solo el comportamiento que falte, con responsable y condición de aceptación claros.
La comparación entre software estándar y desarrollo a medida ayuda a elegir entre un módulo y un proceso mantenido. Para el servicio de integración de API de Wavect, aporta una solicitud representativa, el presupuesto aprobado y las excepciones que más revisión requieren. Eso define una primera entrega concreta.