Utiliza este esquema de app de solicitudes de compras para diseñar aprobaciones, comprobaciones presupuestarias, órdenes de compra y la comunicación con proveedores con roles y estados claros.
Los hilos de correo y las hojas de cálculo fallan de manera predecible. Las solicitudes se pierden. Los archivos se multiplican en versiones como "final_v7". Las aprobaciones ocurren en chats paralelos sin registro. Cuando alguien pregunta "¿podemos comprar esto?" la respuesta depende de quién esté en línea y de qué hoja se confíe.
Una app de solicitudes debe hacer el estado obvio en cualquier momento. Debes poder abrir una solicitud y ver de inmediato quién la creó, qué se quiere comprar, el coste estimado y qué sigue. También necesita un historial limpio: quién aprobó o rechazó, cuándo lo hizo y qué cambió después.
Como mínimo, cada solicitud debe responder estas preguntas sin cavar:
El alcance es donde muchos equipos sobreconstruyen. Decide temprano si cubres solo desde la solicitud hasta la orden de compra, o también pasos posteriores como conciliación de facturas y recepción de bienes. Solicitud a PO suele ser el mejor primer hito: obliga a aprobaciones y comprobaciones presupuestarias limpias, pero mantiene el proyecto contenido.
Mantén la primera versión simple. Empieza con un equipo, un camino de aprobación y una definición clara de “hecho”. Por ejemplo, las solicitudes de TI por debajo de $1,000 pueden necesitar solo la aprobación del manager, mientras compras mayores se enrutan a finanzas.
Si quieres construir esto rápido sin escribir código, AppMaster es una opción práctica. Puedes modelar los datos de solicitud, configurar pasos de aprobación y generar una app web y móvil lista para producción desde el mismo esquema.
Una app de solicitudes de compras vive o muere por los permisos. Si la persona equivocada puede cambiar una solicitud tras la aprobación, o los equipos no ven lo que necesitan, el proceso se vuelve lento y riesgoso.
Empieza nombrando roles claros. Los títulos varían por empresa, pero la mayoría de apps necesita responsabilidades estables: solicitantes (crean solicitudes y responden preguntas), managers (confirman necesidad y timing), procurement (validan proveedores y crean POs), finanzas (confirman presupuesto y política) y uno o más aprobadores (autoridad de firma). Algunos flujos incluyen un contacto limitado del proveedor para detalles externos compartidos.
Luego define qué puede hacer cada rol en cada etapa. Una regla evita muchas disputas: una vez enviada la solicitud, el solicitante solo puede editar aclaraciones (notas, adjuntos, detalles de entrega). Precio, proveedor, cantidad, moneda y centro de costo deben ser campos rígidos que requieran un cambio formal y re-aprobación.
Las reglas de visibilidad deben ser igual de claras. Los solicitantes deben ver sus propias solicitudes y estados. Los managers deben ver solicitudes de sus reportes directos. Procurement y finanzas suelen necesitar visibilidad cross-department. Los contactos de proveedores nunca deben ver notas internas, datos presupuestarios ni otros proveedores.
La delegación importa porque las aprobaciones no pueden pararse cuando alguien está fuera. Soporta delegación planificada (vacaciones) y respaldo de emergencia (bajas). La delegación debe transferir derechos de aprobación, pero no la capacidad de reescribir la solicitud.
Las solicitudes entre departamentos son comunes (por ejemplo, TI comprando software para Marketing). Separa “equipo solicitante” de “propietario del centro de costo”. Enruta aprobaciones al propietario del centro de costo y muestra ambos en el registro para que quede claro quién solicitó y quién paga.
En AppMaster puedes modelar roles, propiedad de registros y acciones por etapa en el modelo de datos y en procesos de negocio, de modo que las mismas reglas apliquen en web y móvil.
Una buena app de solicitudes de compras empieza con un modelo de datos limpio. Si tus tablas están claras, las aprobaciones, las comprobaciones presupuestarias y las órdenes de compra son más fáciles de automatizar y reportar.
La mayoría de equipos cubre la mayoría de casos con un conjunto pequeño de entidades:
Para Requests, incluye campos que ayuden al enrutamiento y reduzcan el ir y venir: solicitante, departamento, centro de costo, fecha necesaria, justificación de negocio y adjuntos (cotizaciones, especificaciones, capturas). Una referencia simple a proveedor preferido ayuda, aunque la selección final del proveedor ocurra después.
Los estados funcionan mejor cuando son explícitos y respaldados por marcas de tiempo. Mantén un campo de estado en Requests (Draft, Submitted, Approved, Rejected, Ordered, Closed) y guarda fechas clave como submitted_at, approved_at, rejected_at, ordered_at y closed_at. Esto facilita informes (tiempo de ciclo, envejecimiento, cuellos de botella) sin adivinar a partir de logs.
Para PurchaseOrders, separa la cabecera de la PO (número, proveedor, ship-to, bill-to, términos de pago) de las líneas de la PO y enlaza de vuelta a la solicitud y a los ítems originales. Esa trazabilidad importa cuando cambian precios.
Las aprobaciones son tu rastro de auditoría, pero normalmente necesitas más que "aprobado/rechazado". Guarda quién actuó, cuándo, qué decidió y por qué.
Un enfoque ligero es una tabla Activity/Audit que registre actor_user_id, entity_type, entity_id, action, old_value, new_value y created_at. En AppMaster esto mapea bien en el Data Designer y puede llenarse automáticamente desde procesos de negocio para que cada cambio sea trazable.
Una app de compras solo funciona cuando todos usan los mismos datos de proveedor. Trata la tabla de proveedores como la única fuente de verdad, no algo que la gente reescriba en cada solicitud. Cuando los detalles del proveedor viven en un solo lugar, las aprobaciones avanzan más rápido y finanzas ve menos sorpresas.
Empieza con un registro de proveedor que guarde lo básico que se reutiliza: nombre legal, nombre a mostrar, identificación fiscal (si se usa), moneda por defecto, dirección de facturación y términos de pago. Guarda el email principal de cuentas a pagar y permite múltiples contactos para usar a la persona adecuada para cotizaciones vs facturas.
Añade un estado de proveedor para que la app pueda bloquear compras riesgosas de forma consistente: Active (puede seleccionarse), Pending review (permitido pero enruta a validación extra) y Blocked (no puede usarse sin revisión).
El seguimiento de comunicaciones evita el problema de “quién les escribió por última vez?”. Crea una entidad Communication (o VendorInteraction) vinculada al Vendor y, cuando sea posible, también a una Request, Quote o Purchase Order específica. Cada registro debe capturar canal (email, llamada, reunión), dirección (saliente/entrante), marca temporal, propietario y un breve resumen. Si colectas cotizaciones, guárdalas como registros estructurados (monto, moneda, fecha de validez) y adjunta archivos cuando sea necesario.
Unas pocas reglas suelen mantener limpios los datos de proveedores sin ralentizar a la gente:
Si lo construyes en AppMaster, puedes modelar Vendor, VendorContact y VendorCommunication en el Data Designer y mostrar una línea de tiempo en las pantallas de solicitud y PO para que el historial completo esté a un clic.
Una comprobación presupuestaria responde a una pregunta simple: ¿tenemos suficiente dinero aprobado para esta solicitud ahora mismo? Decide temprano si la empresa trata el presupuesto como un bloqueo estricto (no puede avanzar) o una advertencia (puede continuar, pero necesita aprobación extra). Esa elección cambia toda la experiencia.
El presupuesto puede venir de distintos sitios; haz explícita la fuente. Opciones comunes: presupuesto anual del departamento, presupuesto por proyecto o un tope mensual para un centro de costo. Si una solicitud puede dividirse entre fuentes, captura montos por fuente para que los informes se mantengan limpios.
Para evitar sorpresas, calcula el gasto esperado de la misma manera que finanzas lo hará más tarde. Una app de solicitudes solo es útil si todos ven el mismo número antes de aprobar.
Una lista de verificación de cálculo simple incluye el total de líneas (cantidad x precio unitario), descuentos, impuestos, envío y handling, y conversión de moneda (almacena la tasa y la fecha). Luego compara el gasto esperado con el presupuesto disponible (presupuesto menos compromisos ya asumidos). Si rastreas compromisos, incluye solicitudes pendientes y POs abiertas, no solo facturas pagadas.
Cuando falta presupuesto, no obligues al solicitante a adivinar. Elige un camino y codifícalo en el flujo: enrutar al propietario del presupuesto para asignar la fuente, permitir una excepción con aprobación de finanzas, devolver la solicitud con una tarea de “detalles de presupuesto” o rechazar automáticamente categorías que siempre requieren presupuesto.
Ejemplo: un equipo solicita un paquete de portátil. La app calcula costo de ítems más impuestos y envío, lo convierte a la moneda del departamento y marca que hay $900 disponibles frente a una solicitud de $1,150. Si lo tratas como advertencia, puede seguir al manager, pero se requiere aprobación adicional de finanzas.
En AppMaster puedes modelar fuentes de presupuesto en el Data Designer y ejecutar la comprobación como un paso de Business Process antes de la primera decisión de aprobación.
Las aprobaciones son donde una app de solicitudes o ahorra tiempo o se convierte en un retransmisor de bandejas de entrada. Mantén el camino por defecto simple y añade reglas solo donde previenen riesgo real.
Empieza definiendo qué protege cada aprobación. Un conjunto común es: aprobación del manager (necesidad y prioridad), aprobación de finanzas (presupuesto y contabilidad) y aprobación de procurement (proveedor y método de compra). Añade seguridad y legal solo cuando ciertas categorías o proveedores lo requieran.
Las reglas de enrutamiento deben ser predecibles. La gente debe poder adivinar qué pasa después antes de hacer clic en Enviar. Factores típicos: umbrales de monto, enrutamiento por categoría (software a seguridad, contratos a legal), nivel de riesgo del proveedor, reglas por departamento o centro de costo y tipo de compra (CapEx vs OpEx, suscripción vs único).
Usa aprobaciones secuenciales cuando el orden importe. Por ejemplo, finanzas puede bloquear una solicitud que no tenga centro de costo, así que es mejor detectarlo antes de que procurement gaste tiempo negociando. Usa aprobaciones en paralelo cuando equipos puedan revisar independientemente, como seguridad y legal en paralelo mientras finanzas comprueba el presupuesto.
Planifica un bucle de rework claro. Cuando un aprobador devuelve una solicitud, el solicitante debe añadir detalles faltantes y reenviar sin perder historial. Mantén un registro de aprobaciones con marcas de tiempo, comentarios y la versión de campos clave como monto, proveedor y categoría.
Ejemplo: una herramienta SaaS de $12,000 se enruta primero a manager y finanzas. Tras ambas aprobaciones, seguridad y procurement corren en paralelo. Si seguridad marca información faltante, vuelve al solicitante y, al corregirse, retorna al mismo paso con el rastro de auditoría intacto.
Si lo construyes en AppMaster, modela estados de flujo y transiciones en un Business Process para que el enrutamiento sea visible y fácil de ajustar conforme evolucione la política.
Un buen flujo mantiene las solicitudes en movimiento sin que los detalles se dispersen. Captura suficiente información temprano y luego congela lo que importa una vez que comienzan las revisiones.
Una secuencia práctica:
Ejemplo: un equipo de soporte solicita 10 auriculares. Adjuntan la cotización, seleccionan la categoría IT Supplies y envían. La app revisa el presupuesto de TI, lo enruta al líder de equipo (por debajo de $1,000) y luego a finanzas (por encima de $500). Tras la aprobación, se genera la PO y se envía; el comprador registra la confirmación y la fecha de entrega.
En una herramienta no-code como AppMaster, esto suele convertirse en unas pocas pantallas (Draft, Review, PO) más un Business Process que bloquea campos, ejecuta la lógica presupuestaria y crea el registro PO automáticamente.
Una orden de compra (PO) solo es útil si es consistente, trazable y difícil de cambiar por accidente. En tu flujo, la PO debe ser un registro estable que proveedores y finanzas puedan confiar.
Genera el número de PO cuando la PO se emita oficialmente al proveedor, no cuando alguien empieza a redactarla. Los borradores se eliminan, reinician y fusionan; así surgen huecos y duplicados.
Para evitar duplicados, guarda el siguiente número de PO en un solo lugar controlado y asígnalo con un paso atómico (una acción que o bien tiene éxito por completo o falla). Si quieres números amigables, añade un prefijo como entidad legal o año, pero conserva el contador único como la parte que nunca se repite.
Separa la PO en cabecera y líneas. La cabecera guarda contexto; las líneas lo que compras.
Mantén la cabecera enfocada: proveedor y contacto, ship-to y bill-to, moneda, términos de pago, fecha de entrega esperada, estado (Draft, Issued, Acknowledged, Closed) y referencia de cotización.
Las líneas deben ser estrictas para la conciliación de facturas: descripción, cantidad, unidad, precio unitario, impuesto, descuento y un centro de costo o código presupuestario. Los totales deben calcularse, no teclearse.
Decide de antemano cuándo se permite una revisión. Cambios pequeños como fecha de entrega o notas pueden ser una versión revisada (por ejemplo, PO-1042 v2) con un enlace claro de “supersede v1”. Cambios grandes como proveedor, moneda o un cambio material en el total suelen merecer “cancelar y reemitir” para evitar que alguien envíe contra un documento equivocado.
Ejemplo: se aprueba una solicitud para 10 portátiles, pero la cotización del proveedor cambia el plazo de entrega de 2 semanas a 8 semanas. Crea una revisión con la nueva fecha de entrega y conserva los detalles de la cotización original para que la PO siempre coincida con lo acordado.
Si lo construyes en AppMaster, modela la cabecera PO, las líneas y las versiones PO como entidades separadas para que las revisiones sean limpias y auditables.
Las notificaciones determinan si un flujo interno de compras parece fluido o se convierte en una caza de hilos. Trata los mensajes como parte del proceso y asócialos a un cambio de estado o a una acción siguiente clara.
Empieza con un conjunto pequeño de actualizaciones internas para que la gente no las ignore: aprobado/rechazado, comprobación presupuestaria fallida o necesita aclaración, PO creada y lista para enviar, aprobación atrasada o entrega atrasada, y PO cambiada o cancelada.
Cada notificación debe leerse en 10 segundos. Usa una plantilla consistente con título de la solicitud, importe total, estado actual y exactamente qué debe hacer el destinatario a continuación. Para aprobadores, incluye una breve razón del gasto y las líneas más importantes.
La comunicación con proveedores debe estructurarse también. Los proveedores principalmente necesitan envío de PO, cambio de PO, cancelación y preguntas de entrega. Guarda cada mensaje saliente y entrante en el hilo del proveedor para esa PO o solicitud. Rastrea resultados con campos simples como status (draft, sent, delivered, failed), vendor_response (none, replied, bounced), follow_up_needed (yes/no) y follow_up_date.
Ejemplo: una solicitud de portátil se aprueba, la PO se envía y el proveedor responde que el modelo está en backorder. La app registra la respuesta, marca follow_up_needed en yes y notifica al solicitante para elegir una alternativa. En AppMaster puedes conectar cambios de estado a pasos de email/SMS/Telegram y guardar el resultado del mensaje junto a la PO.
El mayor riesgo no es dejar fuera funciones. Es construir reglas equivocadas y enseñar a la empresa a evitarlas.
Un fallo común es convertir la solicitud en un laberinto de estados. Si la gente no entiende la diferencia entre “Pending validation” y “Under review”, dejan de actualizarlo y tus datos se vuelven ruido. Mantén los estados ligados a acciones y responsables claros. Cada estado debe responder: “¿qué sigue y quién lo hace?”
Otra trampa es aprobaciones sin propietario o plazo. Las solicitudes se atascan cuando el aprobador está de baja o el rol es ambiguo (“Finanzas” no es una persona). Añade cobertura de respaldo y una expectativa de tiempo, aunque sea informal.
Estos errores causan más retrabajo:
Las ediciones tras la aprobación merecen atención especial porque pequeños cambios “inofensivos” suelen alterar el riesgo. Si alguien obtiene aprobación para 10 portátiles a $900 cada uno y luego cambia a un modelo más caro o aumenta la cantidad, puedes quedarte con aprobaciones que no reflejan lo comprado.
Además, no trates la validación presupuestaria como un campo sí/no. Finanzas suele preocuparse por cómo se reporta el gasto: departamento, proyecto, cuenta GL y ventana temporal. Si tu app verifica presupuestos mensualmente pero finanzas reporta trimestralmente, tu “presupuesto disponible” siempre parecerá incorrecto.
Si lo construyes en AppMaster, bloquea campos clave tras la aprobación y registra cada excepción como un evento (quién, cuándo, qué cambió y por qué). Ese rastro de auditoría te salvará en disputas y auditorías.
Antes del lanzamiento, escribe lo básico. La mayoría del “caos de aprobaciones” ocurre porque falta una regla pequeña o un campo requerido.
Una lista de chequeo sencilla:
Una vez existan esas reglas, añade validaciones rápidas que se ejecuten antes de que una solicitud avance: selección de proveedor (o ruta clara para nuevo proveedor), cobertura presupuestaria para el periodo correcto, evidencia de precios, detalles completos de envío/facturación y una razón de negocio real.
Escenario de ejemplo: un líder de equipo envía una solicitud de portátil para una nueva incorporación la semana siguiente. Elige el proveedor preferido, adjunta la cotización y etiqueta el centro de costo correcto. El manager aprueba porque coincide con el plan de contratación. Finanzas aprueba tras pasar la comprobación presupuestaria. Procurement crea la PO, la envía al proveedor y registra la confirmación del proveedor y la fecha de entrega esperada en el mismo registro para que el solicitante pueda seguir el progreso sin correos adicionales.
Siguientes pasos: prototipa tu modelo de datos y reglas de flujo, luego prueba con un equipo piloto y una o dos categorías de compra. En AppMaster puedes construir las tablas en el Data Designer y mapear la lógica de enrutamiento en el Business Process Editor. Ejecuta un piloto corto, revisa dónde se atascan las solicitudes, ajusta campos obligatorios y luego expándelo. Si quieres ver cómo este enfoque se traduce en una construcción real de app, AppMaster (appmaster.io) está diseñado para crear herramientas internas completas con lógica de aprobaciones, APIs e interfaces web y móviles nativas desde el mismo modelo.
¿Cuál debería ser el primer hito para una app de solicitudes de compras?Comienza con solicitud a orden de compra (PO). Obliga a aprobaciones claras, comprobaciones presupuestarias y trazabilidad sin arrastrarte a la conciliación de facturas y recepción de mercancías desde el inicio. Puedes añadir pasos posteriores cuando el equipo confíe en el primer hito.
¿Qué estados de solicitud deberíamos usar para que la gente no se confunda?Usa un conjunto pequeño y explícito como Draft, Submitted, Approved, Rejected, Ordered y Closed. Cada estado debe indicar claramente quién es el responsable del siguiente paso y qué acción se espera, para que nadie interprete etiquetas vagas.
¿Cómo evitamos que la gente cambie precio o proveedor después de la aprobación?Bloquea los campos clave al enviar y exige un cambio formal que dispare la re-aprobación para cualquier cosa que afecte el riesgo o el gasto (proveedor, moneda, cantidad, precio unitario, centro de costo o total). Permite solo aclaraciones (notas, adjuntos, detalles de entrega) sin reiniciar todo el proceso.
¿Qué roles y permisos son esenciales en un flujo de solicitudes de compras?Define primero los roles y luego lo que cada rol puede hacer en cada etapa. Un esquema simple: los solicitantes ven y editan sus borradores, los managers ven solicitudes de sus reportes directos, y finanzas/procurement tienen visibilidad entre departamentos. Los contactos de proveedores nunca deben ver notas internas ni datos presupuestarios.
¿Cómo debe funcionar la delegación de aprobaciones cuando alguien está de vacaciones?Haz de la delegación una función integrada, no una excepción. La delegación debe transferir derechos de aprobación por un intervalo de tiempo, pero no permitir que el delegado reescriba el contenido de la solicitud, para mantener la responsabilidad clara.
¿Cómo manejamos solicitudes entre departamentos como TI comprando para Marketing?Separa quién solicita la compra de quién la paga. Dirige las aprobaciones al propietario del centro de costo aunque el solicitante sea de otro equipo, y guarda ambos roles en el registro para que siempre esté claro quién inició y quién es responsable del presupuesto.
¿Cuál es la forma más simple de implementar comprobaciones presupuestarias que finanzas confiará?Calcula el gasto esperado exactamente como lo hará finanzas después: incluye impuestos, envío, descuentos y conversión de moneda (almacenando la tasa y la fecha). Decide desde el inicio si la falta de presupuesto bloquea el flujo o permite una escalada con aprobación adicional.
¿Cómo mantenemos limpias las datos de proveedores y prevenimos compras riesgosas?Mantén una tabla maestra de proveedores como única fuente de verdad y selecciona proveedores desde una lista en lugar de texto libre. Añade estados como Active, Pending review y Blocked para que los proveedores de riesgo se gestionen de forma consistente.
¿Cuándo deberíamos generar un número de PO y cómo evitamos duplicados?Genera el número de PO solo cuando la PO se emite oficialmente al proveedor, no durante el borrador. Asígalo en un paso controlado y atómico para evitar duplicados, y mantén la PO estructurada (cabecera y líneas) para que los totales se calculen automáticamente.
¿Podemos construir esto sin programar y qué aporta AppMaster?Sí. Si necesitas una construcción rápida sin código, AppMaster te permite modelar datos, definir permisos por etapa y enrutamiento de aprobaciones, y generar apps web y móviles de producción a partir del mismo modelo, manteniendo el flujo consistente en dispositivos.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
