EGA Futura » Capacitación y Soporte
Un pedido es el momento en que una intención de compra se vuelve un compromiso, con cantidad, precio y fecha ya acordados.
Antes del pedido hay conversaciones y presupuestos; después del pedido hay mercadería que se reserva y dinero que se espera.
Por eso el pedido es la bisagra del proceso comercial: es el primer documento que el resto del ERP toma en serio.
Una cotización es una propuesta que el cliente puede aceptar o no, y por eso no compromete stock ni genera obligaciones.
Un pedido ya está aceptado, así que compromete existencias y habilita la facturación.
Confundir los dos es el error clásico que hace que el inventario muestre disponible algo que ya está vendido.
Armar un pedido parte de registros que ya deben estar creados.
Hacen falta los productos cargados y una lista de precios que los contenga, porque cada línea toma su precio de esa lista.
Conviene tener también el canal de venta y el empleado de ventas, que no son obligatorios pero son lo que después permite analizar de dónde vino cada venta.
Cada pedido se asocia a una única lista de precios, y esa decisión ordena todo lo que se le agrega después.
Al cargar las líneas, las opciones disponibles son los productos de esa lista.
Esa regla es lo que evita que dos vendedores facturen el mismo artículo a precios distintos sin que nadie lo note.
Lo habitual es que un pedido apunte a una sola cuenta de cliente, que es quien lo solicita y a quien se le factura.
Además puede apuntar a un contrato, y ahí el contrato funciona como el marco del que cuelgan varios pedidos.
Ese esquema es el habitual en servicios recurrentes, donde el acuerdo se firma una vez y las entregas se piden muchas.
El pedido guarda por separado la dirección de facturación y la de envío, y también los contactos de cada una.
Esa separación parece un detalle hasta que aparece el caso real: la casa central paga y la sucursal recibe.
También hay lugar para el número y la fecha de la orden de compra del cliente, que es el dato con el que el cliente va a reclamar si algo no coincide.
El pedido lleva una fecha de inicio obligatoria y una fecha de fin opcional.
La de fin tiene sentido cuando lo que se pide se entrega a lo largo del tiempo, como una suscripción o un servicio con vigencia.
Para una venta de mostrador esa segunda fecha simplemente queda vacía.
El pedido tiene su propio objeto en el ERP, y a él se llega desde el Iniciador de aplicación (Waffle) igual que a cualquier otro.
Su Página de registro reúne los datos de cabecera y, debajo, la Lista relacionada con los productos pedidos, que son las líneas del pedido.
Cada línea toma su precio de la lista de precios elegida, así que el precio no se escribe suelto sino que viene de un registro.
Sobre el pedido, el ERP suma dos campos propios: Canal de venta y Empleado de ventas.
Los dos son referencias a objetos aparte, no texto libre, y por eso se pueden agrupar en un Informe sin trabajo extra.
Esa es la diferencia entre saber cuánto se vendió y saber quién vendió y por qué canal.
El ERP tiene además un objeto llamado Ventas, y conviene no confundirlo con el pedido.
La Venta puede apuntar al pedido que le dio origen, así que la relación entre los dos queda registrada en lugar de deducirse.
La Venta tiene sus propias líneas y un total de líneas que la Plataforma suma sola.
También tiene su propio ciclo de estados, con seis valores que van de Borrador hasta Cerrada pasando por Facturada.
El estado es obligatorio y es lo que separa un pedido que todavía se está armando de uno que ya está firme.
Mientras está en borrador se puede seguir tocando; una vez activado pasa a ser un documento que otros procesos leen.
El conjunto de estados es configurable, así que cada empresa lo ajusta a su circuito de venta.
Un cliente corporativo pide cincuenta unidades de un artículo, con entrega en dos tandas.
Se crea el pedido apuntando a la cuenta del cliente y a la lista de precios mayorista, que es la que corresponde a ese segmento.
Se cargan las líneas, se completa el número de orden de compra que mandó el cliente y se pone la dirección de envío del depósito del cliente, distinta de la de facturación.
Con el pedido activado, el importe queda registrado y el compromiso es visible para quien mira el inventario.
Cada entrega parcial se resuelve después con los documentos de envío, sin tener que crear un pedido nuevo.
El ERP permite etiquetar pedidos con las mismas etiquetas transversales que usa en otros objetos.
Sirve para marcar campañas, promociones o casos especiales sin tener que crear un campo nuevo cada vez.
Todos los secretos de un pedido y un paso a paso completo están en este tutorial.
Sí, y lo más prolijo es hacerlo con las líneas todavía vacías, porque cada línea toma su precio de la lista elegida.
Si el pedido ya tiene líneas, se vacían primero y se vuelven a cargar con los precios nuevos.
Cuando el pedido ya está activado, conviene crear uno nuevo con la lista que corresponde.
El pedido es la solicitud acordada con el cliente, con sus productos, su lista de precios y sus direcciones.
La Venta es un objeto aparte del ERP que puede apuntar al pedido y que suma sola el total de sus propias líneas.
En un circuito completo el pedido llega primero y la Venta queda vinculada a él.
No, el contrato es opcional.
Tiene sentido cuando varios pedidos comparten un mismo acuerdo marco, como pasa en servicios recurrentes.
En una venta suelta el pedido se apoya solo en la cuenta del cliente.
Porque quien paga y quien recibe no siempre son el mismo.
La dirección de facturación va al comprobante y la de envío va al remito.
Cada una tiene además su propio contacto, para saber a quién avisarle de cada cosa.
El objeto se llama Order en la base de datos: es un objeto estándar de la Plataforma al que EGA Futura le pone la etiqueta Pedido.
Tiene 43 campos en total y 2 son personalizados de EGA Futura: EGAFutura__Canal_venta__c y EGAFutura__Empleado_ventas__c.
Son obligatorios EffectiveDate (fecha de inicio), Status, CurrencyIsoCode, TotalAmount y OwnerId.
OrderNumber también figura como no nulo, pero es un número automático que no se carga a mano.
Dato importante para quien programa: AccountId y Pricebook2Id admiten nulo en la base de datos.
Status tiene cuatro valores: Draft, Nuevo, En progreso y Activated.
Todo informe o automatización que dependa del estado trabaja con el valor almacenado y no con la etiqueta que se ve en pantalla.
OrderNumber es un número automático.
TotalAmount es un campo de divisa que vive en el propio registro.
El resto de solo lectura son los campos de auditoría habituales, más ActivatedById y ActivatedDate.
Las líneas del pedido son registros de OrderItem, y los precios salen de PricebookEntry.
El objeto EGAFutura__Sales_Order__c (etiqueta Venta) tiene el campo EGAFutura__Order__c, que es una búsqueda opcional hacia Order.
Esa Venta tiene además un campo de resumen, EGAFutura__LinesTotal__c, que suma las Líneas de venta y no admite escritura.
Su lista de estados propia es: Borrador (predeterminado), En progreso, Confirmada, Facturada, Cerrada y Cancelada.