Búsquedas frecuentes
Tutoriales actualizados
Una solicitud de compra es el pedido interno con el que un sector de la empresa avisa que necesita comprar algo, antes de que exista ningún compromiso con un proveedor. Es el documento que abre el circuito de compras y el que permite decidir si la necesidad se justifica, quién la aprueba y con quién conviene cerrarla. En el ERP de EGA Futura cada solicitud es un registro con número propio, fecha de solicitud, fecha solicitada, tipo de solicitud entre Productos y Servicios, propósito entre Consumo y Reabastecimiento, proveedor sugerido, total estimado y un estado que recorre Borrador, En revisión, Rechazada, Aprobada, Cancelada y Cerrada.
Una solicitud de compra es el pedido interno con el que un sector de la empresa avisa que necesita comprar algo.
Es un documento que circula puertas adentro, así que la empresa todavía queda libre de compromiso con cualquier proveedor y sin obligación de pagar nada.
Esa distinción es la que le da sentido a todo el circuito de compras.
La solicitud expresa una necesidad, mientras que la Orden de compra expresa una decisión ya tomada.
La primera se puede rechazar sin costo, porque nadie afuera de la empresa se enteró de que existía.
La segunda sale hacia el proveedor y genera un compromiso económico que más adelante vuelve en forma de factura.
Por eso el orden importa: primero se justifica la necesidad y después se compromete el dinero.
Una solicitud sirve cuando quien la revisa puede decidir sin volver a preguntar nada.
Eso suele resolverse con cuatro datos: qué se necesita, para cuándo, para qué se va a usar y cuánto se estima que cuesta.
El destino de lo pedido cambia la lógica por completo.
Si lo pedido se consume en la operación, se comporta como un gasto del área que lo solicitó.
Si en cambio repone existencias, entra al inventario y sigue siendo un activo de la empresa hasta que se venda o se use.
Un pedido de productos se describe con cantidades, especificaciones y una fecha de entrega.
Un pedido de servicios se describe con un alcance y un resultado esperado, y casi siempre necesita más texto que números.
La diferencia se vuelve concreta al recibir, porque una caja se cuenta y un servicio se acepta.
Es habitual que quien pide sepa perfectamente qué necesita pero no a quién comprárselo.
Dejar esa situación marcada desde el principio le ahorra tiempo al área de compras, porque convierte la búsqueda de proveedor en parte del pedido y no en una sorpresa posterior.
Sin solicitud, la primera noticia de una compra suele ser la factura.
En ese momento ya no queda margen para discutir el precio ni la necesidad, solo para pagar.
Con solicitud aparece un momento intermedio, y ahí alguien puede agrupar pedidos parecidos, negociar mejor o simplemente decir que no.
El segundo beneficio es de trazabilidad.
Cada compra queda unida a la persona que la pidió y al motivo original, que es exactamente lo que se busca cuando aparece una diferencia varios meses después.
La solicitud nace como borrador mientras se termina de completar.
Después se envía a revisión, y ahí se aprueba o se rechaza.
Una solicitud aprobada habilita la Orden de compra, que desemboca en la Recepción de mercadería y en la factura del proveedor.
Cuando el ciclo termina, la solicitud se cierra y queda como antecedente de por qué se compró lo que se compró.
El hub de Compras y gestión de proveedores ubica este concepto dentro de un proceso empresarial.
En Compras y Gastos bajo control: eProcurement para empresas medianas vemos cómo se aplica a decisiones y tareas concretas.
En el ERP de EGA Futura la Solicitud de compra es un objeto propio, con su Página de registro, su Vista de lista y su numerador independiente.
Cada registro nace con un número automático, así que ninguna solicitud depende de que alguien invente un código.
Hay dos fechas y no significan lo mismo.
Fecha de Solicitud de compra indica cuándo se pidió.
Fecha solicitada indica para cuándo se necesita.
La distancia entre ambas es lo que le dice al área de compras cuánto margen real tiene para negociar.
El campo Tipo de solicitud distingue entre Productos y Servicios.
El campo Propósito distingue entre Consumo y Reabastecimiento.
Las dos listas juntas resuelven la pregunta de fondo, que es si lo pedido se consume en el momento o se guarda como existencia.
La solicitud admite un Proveedor sugerido y un Total estimado expresado en la moneda del registro.
Existe además una casilla llamada Solicita nuevo proveedor, pensada justamente para el pedido que sale sin proveedor definido.
El campo Estado recorre seis valores: Borrador, En revisión, Rechazada, Aprobada, Cancelada y Cerrada.
Las solicitudes nuevas arrancan en Borrador de forma automática.
Al margen del estado existe un mecanismo de pausa, formado por la casilla En espera y el campo Motivo de la espera.
Sirve para frenar un pedido sin rechazarlo y dejar escrito por qué quedó detenido.
El campo Descripción es de texto largo y es donde conviene volcar el detalle de lo que se pide.
Cada solicitud tiene además un propietario, que queda registrado como responsable del pedido y permite filtrar la Vista de lista por sector o por persona.
Estas dudas aparecen cuando el pedido interno se separa de la compra propiamente dicha, y hay que definir quién carga y cómo se agrupan los pedidos.
No. Es un pedido interno y se puede rechazar o cancelar sin ninguna consecuencia hacia afuera.
El compromiso aparece recién con la Orden de compra, que es el documento que sale hacia el proveedor.
Lo habitual es que las cargue quien tiene la necesidad, no el área de compras.
De ese modo el pedido llega con el motivo original intacto, que es la información que después permite aprobar o rechazar con criterio.
Rechazar es una decisión de quien revisa: el pedido se evaluó y no se aprueba.
Cancelar es una decisión de quien pidió: la necesidad dejó de existir antes de que se resolviera.
Conservar los dos estados por separado es lo que permite después distinguir un problema de criterio de un cambio de planes.
Depende de si lo pedido comparte destino y fecha.
Cuando varias necesidades tienen el mismo propósito y la misma urgencia, agruparlas mejora el poder de negociación.
Cuando no lo comparten, separarlas evita que un ítem discutible frene a todos los demás.
El nombre de API del objeto es EGAFutura__Purchase_Requisition__c, y su etiqueta en la interfaz es Solicitud de compra.
El campo Name es un numerador automático con la etiqueta Número de Solicitud de compra, así que no admite escritura desde una integración.
Las fechas son EGAFutura__Fecha_Solicitud_compra__c y EGAFutura__Fecha_solicitada__c, ambas de tipo Date.
El importe es EGAFutura__Total__c, de tipo Currency con dos decimales.
La referencia al proveedor es EGAFutura__Proveedor__c, un Lookup que apunta al objeto EGAFutura__Supplier__c.
El texto largo es EGAFutura__Descripcion__c, y el identificador auxiliar es EGAFutura__EGA_Futura_ID__c.
En este objeto las tres listas almacenan el mismo texto que muestran, así que un filtro por API puede usar la etiqueta directamente.
EGAFutura__Estado__c almacena Borrador, En revisión, Rechazada, Aprobada, Cancelada y Cerrada, con Borrador como valor por omisión.
EGAFutura__Tipo_solicitud__c almacena Productos y Servicios.
EGAFutura__Proposito__c almacena Consumo y Reabastecimiento.
Conviene notar que los acentos forman parte del valor almacenado en En revisión, detalle que rompe cualquier comparación hecha con el texto sin tilde.
Las tres casillas del objeto son EGAFutura__En_espera__c, EGAFutura__Solicita_nuevo_proveedor__c y el texto asociado EGAFutura__Motivo_espera__c.
Al ser de tipo Checkbox, las dos primeras nunca aceptan valor nulo, de modo que un filtro por falso también devuelve los registros que nadie tocó.
Los términos del glosario que empiezan igual que este. Las demás letras se abren acá mismo, sin salir de la página.
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.
