Búsquedas frecuentes
Tutoriales actualizados
Una Orden de venta es el momento en que una conversación comercial se vuelve un compromiso: hay un cliente, hay productos, hay cantidades y hay un precio acordado.
Es el documento que le dice al depósito qué preparar y al área de administración qué va a facturarse.
Todo lo que ocurre después en el circuito comercial hereda de este documento los datos que necesita.
Una cotización es una propuesta que el cliente puede aceptar o descartar sin que pase nada.
Una Orden de venta ya compromete a las dos partes y por eso empieza a reservar mercadería y a ocupar capacidad.
La cotización puede tener varias versiones, mientras que la Orden de venta suele ser única por operación.
La Orden de venta describe lo que se acordó entregar, la factura describe lo que se cobra.
Entre una y otra pueden aparecer diferencias reales: entregas parciales, faltantes de stock o cambios de último momento.
Mantenerlas separadas es lo que permite detectar esas diferencias en vez de taparlas.
Toda Orden de venta se organiza en dos niveles y esa división no es un capricho de diseño.
La cabecera guarda lo que vale para toda la operación: el cliente, la fecha, el canal y el estado.
Las líneas guardan lo que cambia producto por producto: la cantidad, el precio unitario y el descuento aplicado.
Una Orden de venta en borrador y una confirmada no tienen el mismo efecto sobre el stock ni sobre los números del mes.
Por eso el estado no es un adorno informativo: es lo que separa la intención del compromiso.
Los Informes de ventas serios siempre filtran por estado antes de sumar.
Una fábrica de envases recibe la confirmación de un cliente por doce mil unidades divididas en tres modelos.
Se carga una Orden de venta con tres líneas, cada una con su cantidad y su precio, y el total se arma solo.
Cuando el depósito prepara la mercadería, el envío se genera a partir de esa misma Orden y no hay que volver a tipear nada.
El error más frecuente es cargar la Orden de venta recién cuando se factura, para ahorrar un paso.
Eso deja al depósito trabajando de memoria y borra el rastro de lo que se prometió frente a lo que finalmente se entregó.
El hub de Plataforma EGA Futura ubica este concepto dentro de un proceso empresarial.
En Los mejores ERP para empresas medianas en 2026 » Comparativa honesta con Precios reales vemos cómo se aplica a decisiones y tareas concretas.
En la Plataforma este documento aparece con el nombre Venta y reúne 24 campos entre los de negocio y los de sistema.
Cada registro recibe dos identificadores automáticos: un Número de Venta correlativo y un EGA Futura ID.
El único campo que la Plataforma exige y que depende de quien carga es la Fecha de Venta.
El cliente, el estado y el total son opcionales a nivel de base de datos, lo cual permite abrir el documento y completarlo después.
Conviene igual completar el cliente cuanto antes, porque es el dato que lleva la Venta a los Informes de cuenta corriente.
La lista de Estado tiene seis valores exactos: Borrador, que es el que viene por defecto, En progreso, Confirmada, Facturada, Cerrada y Cancelada.
La secuencia habitual va de Borrador a Cerrada, y Cancelada funciona como salida en cualquier punto del recorrido.
Cada línea de venta exige tres datos: la venta a la que pertenece, la cantidad y el precio unitario.
La cantidad se guarda como número entero, de modo que para vender por peso conviene definir el producto en la unidad de medida más chica, por ejemplo gramos.
Con esos datos y el descuento opcional, la Plataforma calcula sola el total de cada línea y después suma todas las líneas en el campo Total de líneas de la cabecera.
La cabecera tiene dos campos de total y no son lo mismo.
Total de líneas es el que la Plataforma calcula sumando las líneas cargadas, mientras que Total es un campo de moneda que se completa a mano.
Comparar los dos es una forma barata de detectar líneas olvidadas o importes escritos mal.
La Venta se enlaza con la cuenta del cliente, con el canal de venta, con el empleado de ventas que la generó, con la cotización que le dio origen y con el pedido asociado.
Hacia adelante, tanto el envío como la orden de devolución apuntan de vuelta a la Venta, así que el documento queda como eje del circuito.
Una Vista de lista filtrada por Estado alcanza para el trabajo diario del área comercial.
Para el análisis conviene un Informe agrupado por canal de venta o por empleado de ventas, llevado después a un Panel de información.
Estas dudas aparecen al cargar pedidos en el sistema: qué exige el documento para existir, qué pasa con los productos que se venden por peso y cómo se marca uno ya facturado.
Sí, la Plataforma deja guardar la cabecera sin ninguna línea cargada.
El resultado es un documento con Total de líneas en cero, que sirve como reserva de numeración hasta que se cargan los productos.
La cantidad de cada línea se guarda como número entero, sin decimales.
Para vender por kilos o por litros conviene elegir una unidad de medida más chica, por ejemplo gramos.
No, el registro sigue existiendo con todos sus datos y sus líneas.
Cancelar es justamente lo contrario de borrar: deja el rastro de que la operación existió y de que después se dio de baja.
Con el valor Facturada de la lista de Estado, que es el que registra ese momento del circuito.
El disparo automático de la factura depende de la configuración de cada empresa.
El objeto es EGAFutura__Sales_Order__c, con etiqueta Venta y 24 campos.
Las líneas viven en EGAFutura__SalesOrderLine__c, con etiqueta Línea de venta y 16 campos.
Con IsNillable: false figuran Name (Auto Number, etiqueta Número de Venta), EGAFutura__EGA_Futura_ID__c (Auto Number) y EGAFutura__Sales_Order_Date__c (Date, etiqueta Fecha de Venta).
Este último es el único obligatorio que carga el usuario, porque los otros dos son autonuméricos.
EGAFutura__Cliente__c es Lookup(Account), EGAFutura__Canal_venta__c apunta a EGAFutura__Sales_Channel__c, EGAFutura__Empleado_ventas__c a EGAFutura__Sales_Employee__c, EGAFutura__Quote__c a EGAFutura__Quote__c y EGAFutura__Order__c al estándar Order.
EGAFutura__LinesTotal__c es un Roll-Up Summary (SUM Línea de venta), no un campo fórmula.
EGAFutura__Total__c es Currency(16, 2) editable, así que en la cabecera conviven un total calculado y un total cargado a mano.
En la línea, EGAFutura__LineTotal__c sí es Formula (Currency).
Obligatorios: EGAFutura__SalesOrder__c (Master-Detail hacia Venta), EGAFutura__Quantity__c (Number 18,0) y EGAFutura__UnitPrice__c (Currency 16,2).
Opcionales: EGAFutura__Product__c (Lookup(Product), es decir el objeto estándar Product2) y EGAFutura__DiscountPercent__c (Percent 5,2).
Cancelada, Borrador (valor por defecto), En progreso, Confirmada, Facturada y Cerrada.
Se leen por ui-api con /services/data/v66.0/ui-api/object-info/EGAFutura__Sales_Order__c/picklist-values/012000000000000AAA/EGAFutura__Status__c.
La cabecera y sus líneas se consultan juntas por la relación Master-Detail, que es la que garantiza que cada línea pertenezca a una sola Venta.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube