Comprar bien depende de una pregunta simple que muchas empresas responden de memoria: quién nos vende esto y a cuánto.
El Producto del proveedor es el registro que convierte esa memoria en un dato, guardando cada combinación de artículo y fuente con su precio.
El artículo es uno solo: tiene su código, su descripción y su unidad de medida.
El precio de compra, en cambio, cambia según quién lo venda, así que guardarlo dentro de la ficha del artículo obligaría a elegir una sola fuente y a perder el resto.
Guardarlo dentro del proveedor tampoco funciona, porque un mismo proveedor vende muchos artículos distintos.
La solución de modelo es un registro intermedio, que existe justamente para sostener los datos que solo tienen sentido en el cruce.
El registro tiene un lado que apunta al proveedor, otro que apunta al producto, y un dato propio que no vive en ninguno de los dos.
La relación con el proveedor es de las fuertes: el registro no existe sin su proveedor y desaparece con él.
La consecuencia práctica es que dar de baja a un proveedor limpia por sí solo todas las combinaciones de precio que dependían de esa relación.
La relación con el artículo es un campo de búsqueda, y apunta al catálogo de productos de tu empresa.
Al ser un vínculo más flexible, un mismo artículo aparece en tantos registros como fuentes tenga, y esa colección es la lista de proveedores alternativos de ese artículo.
El precio es el dato que justifica que el registro exista, y se guarda como un importe con su moneda.
Todo lo demás que el registro muestra sale de los dos lados que vincula, que es exactamente lo que se espera de una tabla de unión.
La primera es la comparación: con dos o tres fuentes cargadas para el mismo artículo, elegir deja de ser un recuerdo y pasa a ser una lectura.
La segunda es la continuidad. Cuando la fuente habitual de un insumo no responde, la lista de alternativas ya está escrita y no hay que reconstruirla con llamados.
La tercera es el análisis. Sumando los registros de un proveedor se ve cuántos artículos de tu empresa dependen de él, que es una medida de concentración de riesgo.
Una Lista de Precios guarda a cuánto vende tu empresa, y por eso mira hacia el cliente.
El Producto del proveedor guarda a cuánto compra, y por eso mira hacia el mercado de abastecimiento.
Los dos conviven sobre el mismo catálogo de artículos, y la diferencia entre uno y otro es lo que después se lee como margen.
Cada vez que un proveedor cotiza un artículo que ya está en el catálogo, aunque todavía no se le haya comprado.
Una cotización cargada vale tanto como una compra hecha, porque el valor del registro está en la comparación y no en el historial.
Y cuando el precio de una fuente cambia, actualizamos el registro existente en lugar de crear uno nuevo, así la lista se mantiene legible.
El registro se carga desde el proveedor, se consulta desde el artículo, y su utilidad aparece en el momento de decidir una compra.
Lo más cómodo es abrir la ficha del proveedor y usar la Lista relacionada de productos, porque desde ahí el lado del proveedor queda completo solo.
Después elegimos el artículo del catálogo y cargamos el precio con el que esa fuente lo ofrece.
Conviene cargar el precio en la moneda de la operación, ya que el importe se guarda con su moneda y eso es lo que después permite comparar sin convertir a mano.
Antes de emitir una Orden de compra, entramos al artículo y miramos qué fuentes tiene cargadas.
Con esa lista a la vista, elegir proveedor deja de depender de a quién le compramos la vez pasada.
Y desde la ficha del proveedor, la misma Lista relacionada funciona al revés: muestra todo lo que esa fuente provee, que es la vista que sirve para negociar un acuerdo global.
Nos conviene repasar los precios cargados con la periodicidad con la que se mueven en el mercado de tu empresa, porque un precio viejo lleva a una comparación falsa.
También revisamos que cada artículo importante tenga más de una fuente cargada, ya que la comparación necesita al menos dos.
Y cuando se da de baja a un proveedor, tenemos presente que sus combinaciones de artículo y precio se van con él, así que si algún dato hace falta para el historial conviene registrarlo antes en la orden de compra correspondiente.
Estas son las preguntas que aparecen al empezar a cargar la relación entre artículos y fuentes de abastecimiento en el ERP.
Sí, y es el uso principal del objeto.
Cada combinación de artículo y proveedor es un registro distinto, así que un artículo con cuatro fuentes tiene cuatro registros con su propio precio.
Se eliminan junto con él, porque la relación con el proveedor es del tipo que hace al registro dependiente del padre.
Es un comportamiento deseado: sin proveedor, la combinación deja de significar algo.
No. El precio del proveedor es lo que una fuente pide por el artículo, y el costo es lo que el artículo terminó valiendo para tu empresa.
Entre uno y otro pueden mediar fletes, impuestos y diferencias de cambio, según cómo lo defina la contabilidad de cada empresa.
No es un requisito del circuito, y aun así conviene cargarlo.
El registro es lo que permite que la próxima compra del mismo artículo se decida mirando datos en lugar de repitiendo la elección anterior.
El registro vincula el artículo del catálogo de tu empresa con esa fuente, y ese vínculo es el que traduce entre los dos mundos.
Cuando el código del proveedor tiene que quedar a la vista de quien compra, se pide como un campo de texto sobre este objeto, y ese pedido se redacta nombrando el objeto por su nombre de API.
Esta sección es para quien escribe requerimientos sobre el ERP y necesita nombrar los campos y las relaciones con precisión.
El objeto se llama EGAFutura__Supplier_Product__c, tiene tres campos propios además del nombre del registro, y es uno de los más chicos del módulo de Compras.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Numeración automática | Etiquetado EGA Futura ID, lo completa el sistema |
| EGAFutura__Proveedor__c | Master-Detail | Obligatorio, apunta a EGAFutura__Supplier__c |
| EGAFutura__Producto__c | Lookup | Apunta a Product2, que es el objeto estándar |
| EGAFutura__Precio__c | Moneda(16, 2) | Precio del proveedor para ese artículo |
Los dos lados del cruce se implementan de forma distinta, y esa diferencia es lo que define el comportamiento del objeto.
| Etiqueta | Nombre de API | Objeto destino |
|---|---|---|
| Proveedor | EGAFutura__Proveedor__c | EGAFutura__Supplier__c |
| Producto | EGAFutura__Producto__c | Product2 |
El nombre de API del proveedor es EGAFutura__Supplier__c, con la palabra en inglés, y no la forma en español que uno esperaría. Existe además un campo llamado EGAFutura__Proveedor__c en varios objetos, así que conviene aclarar en el requerimiento si se habla del objeto o del campo.
El Master-Detail hacia Proveedor tiene dos consecuencias que no se ven en la tabla. La primera es el borrado en cascada: al eliminar el proveedor se eliminan sus registros de producto. La segunda es que el registro no tiene propietario propio y hereda el del padre, así que cualquier requerimiento sobre visibilidad se resuelve sobre el proveedor y no sobre este objeto.
El lado del producto apunta al objeto estándar Product2, que es donde vive el catálogo. Eso significa que el objeto hereda todo lo que Product2 ya trae, y que un informe que cruce compras con artículos se arma contra ese objeto estándar.
El campo Name es una numeración automática, o sea que ningún registro tiene un título legible. Un requerimiento que pida ver el par de proveedor y artículo en la Vista de lista se traduce en un campo de fórmula de texto que concatene los dos nombres, y conviene pedirlo con esas palabras.
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