Aprende a crear un sistema interno de solicitudes de compra con artículos de catálogo, controles presupuestarios, aprobaciones claras y un traspaso sencillo a las órdenes de compra.
La mayoría de los retrasos en las compras empiezan antes de que alguien apruebe o rechace una solicitud. Un empleado pide un portátil por correo, comparte un precio en el chat y después añade una fila en una hoja de cálculo para finanzas. Cada lugar contiene una parte de la solicitud. Luego, el comprador tiene que reunir el proveedor, el coste, el motivo empresarial, el responsable del presupuesto y la fecha límite.
Esto genera trabajo duplicado. Un responsable pide datos que el empleado ya envió a finanzas. Finanzas comprueba el presupuesto, pero no puede ver si la persona responsable del departamento aprobó la necesidad. El empleado no sabe en qué punto está la solicitud ni quién debe actuar a continuación.
Un flujo de aprobación de compras se ralentiza cuando la solicitud no contiene la información que necesita cada persona. Entre las carencias habituales están:
Una sola omisión puede devolver la solicitud al principio. Un responsable de equipo puede aprobar la renovación de un software de 1.200 $, y después finanzas descubre que nadie identificó el presupuesto. En lugar de hacer el pedido, el equipo pasa días buscando a la persona responsable de ese gasto.
Un sistema interno de solicitudes de compra mantiene toda la información reunida desde el envío hasta el traspaso a la orden de compra. El solicitante introduce la necesidad una sola vez. Responsables, personal de finanzas y compradores ven los mismos datos, añaden comentarios al mismo registro y dejan un historial visible de las decisiones.
Las etiquetas de estado claras reducen las consultas innecesarias. Una solicitud puede indicar si necesita una revisión presupuestaria, la aprobación de un responsable, una acción del comprador o datos del proveedor. Cada etapa necesita una persona o función asignada, además de una regla de sustitución para las ausencias.
Una aplicación de compras sin código hace que esto sea posible sin obligar a los equipos de operaciones a mantener formularios y hojas de cálculo. AppMaster puede gestionar formularios de solicitud, campos presupuestarios, lógica de aprobación y una cola de compradores en una sola aplicación. Cada solicitud debe tener un único lugar, un responsable actual y los datos suficientes para avanzar hacia un pedido.
Un formulario de solicitud debe dar a responsables y compradores la información necesaria para decidir con rapidez. Si los empleados tienen que explicar los datos básicos en mensajes posteriores, el formulario es demasiado limitado. Si pide datos financieros que no pueden conocer, la gente hará suposiciones o abandonará el proceso.
Todas las solicitudes necesitan un nombre de artículo, cantidad, proveedor, coste unitario estimado, coste total y motivo empresarial. Añade el departamento, el centro de costes, el solicitante y la fecha en que se necesita cuando esos datos afecten al presupuesto o a la entrega. Después de iniciar sesión, el sistema puede completar automáticamente el nombre y el departamento del empleado.
Un motivo breve funciona mejor que un cuadro de texto grande y vacío. Por ejemplo: «Cinco licencias adicionales de atención al cliente para el nuevo turno de tarde». Ofrece al aprobador un motivo práctico, una cantidad y una relación con el trabajo actual.
Las compras de catálogo y las compras puntuales necesitan formularios distintos. Un artículo del catálogo ya tiene una descripción aprobada, un proveedor, un precio y, en algunos casos, una referencia contractual. Los empleados pueden seleccionarlo, introducir una cantidad y explicar la necesidad. Así, las solicitudes habituales mantienen un formato coherente.
Una compra puntual necesita más contexto porque compras debe evaluarla antes de hacer el pedido. Solicita la descripción del artículo o servicio, el proveedor preferido y su contacto si se conocen, el presupuesto o coste estimado, la cantidad y la frecuencia de facturación, el motivo empresarial y la fecha de entrega solicitada.
No obligues a los empleados a encontrar un proveedor antes de poder solicitar algo. Pueden saber que necesitan un escritorio de pie sin saber qué proveedor cumple las normas de la empresa. Compras puede completar esa parte más adelante.
Exige un campo solo cuando alguien lo necesite para aprobar, presupuestar o comprar la solicitud. El artículo, la cantidad, el coste estimado, el centro de costes y el motivo suelen formar parte de ese grupo. Los archivos adjuntos solo deberían ser obligatorios por encima de cierto límite de gasto o para categorías como las suscripciones de software.
Los campos condicionales hacen que el formulario sea más fácil de usar. Una solicitud de software puede preguntar por el número de usuarios, la fecha de renovación y si gestionará datos de clientes. Para un artículo físico puede pedir una dirección de entrega. Cada flujo de aprobación de compras obtiene los datos que necesita sin obligar a todos los empleados a completar un formulario largo.
Antes del lanzamiento, envía tres solicitudes de prueba: un artículo del catálogo, una compra a un proveedor nuevo y un servicio recurrente. Si un aprobador sigue haciendo una pregunta evidente, añade un campo o aclara uno existente.
Un catálogo elimina el trabajo repetitivo. En lugar de pedir a cada empleado que describa desde cero un portátil, una licencia de software o una silla de oficina, ofrece una lista breve de opciones aprobadas.
Cada artículo del catálogo debe incluir una descripción sencilla, el precio unitario habitual y el proveedor preferido. Añade los datos que eviten mensajes posteriores, como el código del artículo, la duración del contrato, las tallas disponibles o la necesidad de que un responsable confirme la compra.
Por ejemplo, una entrada llamada «Portátil estándar» podría indicar el modelo, el proveedor aprobado, un precio de 1.200 $ y una garantía de tres años. El solicitante selecciona la cantidad y explica quién lo utilizará. Compras recibe siempre la misma información útil.
No conviertas el catálogo en una copia de todos los sitios web de proveedores. Empieza por los artículos que los empleados piden con frecuencia y añade nuevas entradas cuando la misma solicitud de texto libre aparezca repetidamente. Un catálogo largo y mal organizado crea otro retraso.
Agrupa los artículos en categorías conocidas, como software, equipos, material de oficina y servicios profesionales. Usa búsquedas y nombres breves para que las personas encuentren un artículo antes de empezar a escribir una descripción.
Una entrada de catálogo suele necesitar el nombre y la descripción del artículo, el precio unitario o el intervalo previsto, el proveedor preferido, la unidad de facturación y las restricciones aplicables. Por ejemplo, una suscripción puede indicar «por usuario y por mes» y señalar que necesita la aprobación de un responsable.
A veces los empleados necesitarán algo que no aparece en la lista. Conserva una opción de texto libre, pero solicita suficiente información para que el siguiente paso sea posible: la necesidad, el coste estimado, el proveedor si se conoce y el motivo empresarial.
Trata las solicitudes de texto libre como una cola de revisión, no como un fallo del catálogo. Compras puede comparar presupuestos, aprobar un proveedor o decidir añadir el artículo al catálogo para futuras solicitudes.
En una aplicación de compras sin código creada con AppMaster, seleccionar un artículo del catálogo puede completar el precio, el proveedor y los campos de la solicitud. Esto proporciona datos más limpios para el proceso de aprobación presupuestaria y reduce el trabajo de corrección antes del traspaso a la orden de compra.
Una solicitud debe mostrar su contexto financiero antes de que alguien empiece una tarea de aprobación. Pide al solicitante que seleccione un departamento y un centro de costes, y registra después el importe y la divisa. El sistema puede usar esos campos para encontrar el presupuesto correspondiente.
Haz que el control sea sencillo para los solicitantes. Deben ver el total de la solicitud, el presupuesto disponible y el importe que quedaría después de aprobarla. Un mensaje como «Esta solicitud supera en 420 $ el presupuesto restante» evita que un responsable descubra el problema más tarde en una cadena de correos.
Finanzas debe encargarse de los datos presupuestarios. El personal puede actualizar el importe aprobado de cada departamento o centro de costes al comienzo de un periodo y revisarlo cuando cambien los planes. El sistema interno de solicitudes de compra también debe registrar las solicitudes aprobadas que aún no se han convertido en facturas. De lo contrario, un equipo puede parecer que aún tiene dinero disponible aunque ya haya comprometido esos fondos.
Calcula cuánto pagará realmente compras. Incluye cantidades, precios unitarios, impuestos, envío, gastos de configuración y cargos recurrentes cuando corresponda. Una suscripción de software de 900 $ con un gasto de implementación de 150 $ representa una solicitud de 1.050 $.
Ejecuta el proceso de aprobación presupuestaria cuando el solicitante envíe el formulario, antes de que el sistema lo remita a un aprobador. Así se evita perder tiempo en revisiones y el solicitante puede corregir el centro de costes, reducir el pedido o explicar una excepción.
En una aplicación de compras sin código, esto puede ser una regla visual: leer el centro de costes seleccionado, comparar el total de la solicitud con el presupuesto restante y guardar el resultado en la solicitud. AppMaster puede modelar los datos, crear la lógica en su Business Process Editor y mostrar el resultado en un formulario interno.
No dejes una solicitud que supera el presupuesto en un estado poco claro. Asígnale una ruta definida que coincida con la política de gasto. Puedes devolverla al solicitante mostrando la diferencia, enviarla al responsable del presupuesto para que autorice una excepción, remitir una necesidad urgente a finanzas o mantenerla en espera hasta el siguiente periodo presupuestario con una fecha y un motivo.
Registra el resultado presupuestario y cualquier decisión sobre excepciones. Cuando compras empiece el pedido, el personal podrá ver si el gasto encaja en el presupuesto original y quién aprobó el importe adicional. Finanzas también podrá explicar por qué un centro de costes superó el plan.
Un sistema interno de solicitudes de compra necesita reglas de encaminamiento antes de que alguien envíe una solicitud. Envía cada solicitud a las personas capaces de valorar el gasto, en lugar de a una bandeja genérica que alguien revisa de vez en cuando.
Basa la ruta en la información que ya recoge el formulario. El departamento, el centro de costes, la categoría de compra y el importe total suelen aportar suficiente contexto. Una solicitud de 40 $ para material de oficina puede necesitar solo al responsable del equipo. Un contrato de software nuevo puede requerir la aprobación del responsable del presupuesto, TI, seguridad y compras.
Mantén las rutas cortas cuando el riesgo sea bajo. Añadir aprobadores «por si acaso» convierte un flujo sencillo de aprobación de compras en una cadena de retrasos. Cada aprobador debe tener un motivo claro para aprobar, rechazar o pedir más información.
Los empleados deben saber adónde irá su solicitud antes de enviarla. Las reglas previsibles también reducen las discusiones cuando una solicitud se detiene.
Por ejemplo, una empresa podría usar reglas como estas:
Las reglas no tienen que ser idénticas en todos los departamentos. Ventas puede necesitar aprobación para herramientas orientadas al cliente, mientras que operaciones puede requerir una comprobación adicional de equipos. Usa la misma lógica básica en toda la empresa para que el personal no tenga que aprender de nuevo el proceso cada vez.
Cada aprobador necesita un suplente. Si un responsable está de permiso, el sistema debe enviar las nuevas solicitudes a una persona sustituta concreta o permitir que un administrador reasigne el trabajo pendiente. Los solicitantes no deberían tener que perseguir a nadie por correo o chat.
Establece un plazo de respuesta. Por ejemplo, notifica al aprobador después de dos días laborables y envía la solicitud a un suplente después de cinco. La escalada debe hacer avanzar la solicitud sin perder la ruta original ni el historial de decisiones.
Conserva cada decisión en el registro de la solicitud. Muestra quién la aprobó o rechazó, cuándo actuó y sus comentarios. Un rechazo como «Usa la licencia existente del equipo hasta la renovación» da al solicitante un siguiente paso práctico y proporciona a compras el contexto del pedido.
AppMaster permite modelar campos de solicitudes, crear la lógica de aprobación en un proceso empresarial visual y mostrar a los solicitantes el estado actual. La responsabilidad permanece visible en lugar de desaparecer en cadenas de correos.
Un flujo claro evita que las compras sencillas desaparezcan en el correo electrónico. Cada estado debe describir la situación actual y cada persona debe saber cuándo tiene que actuar.
Empieza con un conjunto reducido de estados: Borrador, Enviada, Aprobada, Rechazada, Pedida y Recibida. Evita etiquetas con significados casi idénticos, como «pendiente de revisión» y «a la espera de aprobación». La gente las usará de forma irregular y los informes perderán fiabilidad.
Una solicitud comienza como borrador. El solicitante puede guardarla, cambiar el artículo o la cantidad, o eliminarla. En esta etapa, el sistema no debe enviar notificaciones ni reservar presupuesto.
Cuando el solicitante envía el formulario, el estado cambia a Enviada. Bloquea el precio, los datos del proveedor y el importe solicitado, salvo que alguien devuelva la solicitud para que se modifique. El aprobador puede aprobarla, rechazarla o devolverla con un comentario breve.
Después de la aprobación, entrega la solicitud al equipo de compras. El personal debe marcarla como Pedida solo después de crear o realizar la orden de compra. Tener permiso para gastar no demuestra que alguien haya comprado el artículo.
Cuando llegan los productos, comienza el acceso al servicio o se confirma una suscripción, la persona encargada de la recepción marca la solicitud como Recibida. Así, finanzas y los solicitantes disponen de un registro fiable de lo que llegó.
Un sistema interno sencillo de solicitudes de compra funciona mejor cuando cada cambio de estado tiene un responsable. No permitas que cualquier usuario edite cualquier solicitud enviada.
Un administrador debe gestionar las excepciones, como la salida de un aprobador de la empresa o una solicitud duplicada. Mantén un registro de auditoría de cada cambio de estado, con la persona que lo hizo, la fecha y cualquier comentario.
Envía una notificación cuando una solicitud enviada llegue a un aprobador. Incluye el título de la solicitud, el importe, el departamento y la decisión necesaria. Un mensaje impreciso como «Tienes una nueva tarea» retrasa la acción porque obliga a buscar el contexto.
Notifica al solicitante cuando alguien apruebe, rechace o devuelva la solicitud. Exige un comentario para los rechazos y las devoluciones. «No hay presupuesto disponible este trimestre» orienta al solicitante. «No» no lo hace.
Compras debe recibir un aviso después de la aprobación final. El solicitante debe recibir actualizaciones cuando compras marque la solicitud como Pedida y Recibida. Si nadie actúa durante un periodo establecido, recuerda la tarea al responsable actual y copia al aprobador suplente.
Con AppMaster, una aplicación de compras sin código puede modelar los estados en Data Designer y aplicar los cambios permitidos en Business Process Editor. Cada traspaso permanece en el registro en lugar de depender de que alguien lo recuerde.
Maya, responsable de marketing, necesita 15 suscripciones de una herramienta de planificación de redes sociales. Abre el sistema interno de solicitudes de compra y selecciona la herramienta del catálogo de software en lugar de crear una solicitud de texto libre.
La entrada del catálogo contiene el proveedor, el tipo de plan, el precio por usuario, el ciclo de facturación y el equipo responsable del contrato. Maya introduce 15 licencias, selecciona el centro de costes de Marketing y añade un motivo: el equipo necesita programación compartida y aprobación de las publicaciones de campaña.
La aplicación calcula el coste anual antes de que Maya envíe la solicitud. Marketing tiene suficiente presupuesto para software, por lo que la solicitud supera el control presupuestario. Si el presupuesto fuera insuficiente, la aplicación podría detener la solicitud y pedir a Maya que eligiera otro centro de costes o solicitara financiación adicional. Así se evita que un responsable apruebe una compra que finanzas no puede pagar.
La responsable del departamento de Maya recibe la solicitud porque está dentro de su límite de gasto. La pantalla de aprobación muestra el coste, el número de usuarios, el motivo empresarial y el saldo presupuestario. La responsable la aprueba.
Compras recibe un registro completo con el proveedor y el plan, el total anual y la fecha de renovación, el centro de costes y el resultado presupuestario, el motivo de Maya y la aprobación de la responsable con fecha y hora. Una coordinadora de compras comprueba si la empresa ya tiene un acuerdo con el proveedor. Si existe, crea la orden de compra a partir de los datos guardados. Si no existe, inicia la revisión del proveedor antes de hacer el pedido.
La coordinadora registra el número de la orden de compra y marca la solicitud como Pedida. Maya puede ver la actualización sin preguntar a compras. Cuando el proveedor confirma las 15 licencias, la coordinadora marca la solicitud como Recibida y registra quién administrará la cuenta.
Este flujo mantiene cada decisión vinculada a la solicitud. Finanzas puede ver por qué el equipo compró el software, qué presupuesto lo pagó y quién aprobó el gasto.
Un proceso de compras puede parecer sencillo en un diagrama y aun así frustrar a sus usuarios. Los problemas suelen aparecer cuando el sistema trata cada solicitud como algo excepcional o pierde el control de los cambios después de la aprobación.
Muchos equipos envían todas las solicitudes a un único responsable sénior. Esa persona se convierte en el cuello de botella de artículos rutinarios, como un teclado de sustitución, una renovación mensual de software o material por debajo de un límite de gasto pequeño. Si se ausenta durante dos días, todo el mundo espera.
Adapta las rutas de aprobación al coste, al departamento y al tipo de solicitud. Un responsable de equipo puede aprobar un artículo estándar del catálogo por debajo de un límite determinado. El responsable de un departamento puede revisar compras de mayor importe. Finanzas puede intervenir cuando una solicitud afecta a un presupuesto o supera un límite. Los directivos deberían recibir excepciones, no solicitudes normales.
La aprobación final se aplica a un artículo, una cantidad, un proveedor y un precio concretos. Si alguien cambia esos datos después, la aprobación puede dejar de corresponderse con el gasto.
Establece reglas para las modificaciones relevantes. Un cambio de 10 a 12 licencias o de 500 $ a 1.200 $ debe devolver la solicitud al revisor correspondiente. Las notas menores, como un contacto de entrega, pueden seguir siendo editables sin reiniciar el flujo de aprobación de compras.
Una aplicación de compras sin código puede conservar el historial de cambios y volver a abrir la aprobación cuando cambien campos controlados. Así se evitan sorpresas cuando finanzas compara el importe aprobado con una factura.
La aprobación no es el final de la compra. El equipo de compras todavía debe registrar el proveedor, el número de la orden de compra, el precio final, la fecha del pedido y el estado de la entrega. Si alguien cierra una solicitud antes de que existan esos datos, el personal tendrá que buscarlos después en correos y hojas de cálculo.
Usa estados claros como Aprobada, Pedida, Recibida y Cerrada. Pasa una solicitud a Cerrada solo después de que compras haya registrado los datos del pedido y confirmado el traspaso. Una suscripción anual aprobada debe permanecer como Aprobada hasta que el comprador registre el pedido o la referencia de renovación del proveedor.
Esta distinción hace que los informes sean más fiables. Los equipos pueden ver qué solicitudes aprobadas aún necesitan una acción, qué pedidos esperan la entrega y qué compras han terminado.
Una prueba breve detecta la mayoría de los problemas antes de que los empleados dependan del sistema interno de solicitudes de compra. Pide a un grupo pequeño que envíe solicitudes realistas, como material de oficina, una renovación de software y un contrato de servicios. Incluye a solicitantes, aprobadores y personal que crea órdenes de compra.
Cada solicitud necesita un responsable claro y un estado visible. El responsable debe cambiar cuando la responsabilidad pase del solicitante a un responsable o comprador. Las etiquetas de estado deben explicar lo ocurrido, como Borrador, Enviada, Aprobada, Rechazada o Entregada a compras.
Antes de abrir la aplicación a todo el mundo, confirma que cada solicitud muestra su responsable, estado actual, importe y próximo aprobador. Compara las reglas de aprobación con los límites de gasto reales y las normas departamentales. Comprueba que compras pueda ver el proveedor, el precio presupuestado, la cantidad aprobada y la fecha de entrega solicitada.
Prueba una solicitud que supere el presupuesto y confirma que la aplicación la detiene o la envía a la persona adecuada. Rechaza otra solicitud con un motivo claro y comprueba que el solicitante recibe ese motivo y puede actualizar el formulario.
Usa cifras reales para las pruebas presupuestarias. Asigna a un equipo un presupuesto mensual restante de 2.000 $ y envía una solicitud de 2.400 $. Decide si el sistema debe bloquearla, pedir la aprobación de finanzas o permitir que el responsable del presupuesto transfiera fondos. Todas las personas implicadas deben ver el mismo resultado.
Prueba también los cambios posteriores a la aprobación. Un solicitante puede aumentar un pedido de 10 a 15 monitores, o un proveedor puede subir el precio presupuestado. El flujo de aprobación de compras debe volver a enviar la solicitud a aprobación o identificar claramente los cambios que no necesitan otra revisión. Los cambios silenciosos provocan discusiones más adelante.
Por último, prueba el traspaso a la orden de compra. Compras debe recibir los datos aprobados en un único lugar en vez de volver a escribirlos desde un correo o un chat. En AppMaster, los equipos pueden probar estos recorridos con registros de ejemplo y ajustar las reglas visuales antes de publicar la aplicación. Mantén un registro breve de las pruebas fallidas, corrige la regla responsable de cada fallo y vuelve a ejecutar la prueba.
Empieza con un departamento que realice compras repetitivas y tenga una cadena de aprobación manejable. El software de TI, el material de oficina o las suscripciones de marketing son buenos puntos de partida. Ofrece a ese grupo un catálogo breve con artículos habituales, precios estimados y la información que necesita compras.
Mantén enfocada la primera versión. El solicitante debe poder enviar una necesidad clara, el aprobador debe ver el coste y el estado del presupuesto, y compras debe recibir una solicitud completa después de la aprobación. Añade tipos de solicitud poco habituales cuando el recorrido básico funcione de forma fiable.
Pide opinión a las personas que utilizan cada parte del sistema interno de solicitudes de compra después de las primeras semanas. Los solicitantes pueden identificar campos confusos. Los aprobadores pueden explicar dónde necesitan más contexto. El personal de compras puede señalar datos de proveedores que faltan o solicitudes que todavía llegan fuera de la aplicación.
Usa esos comentarios para eliminar campos que nadie utiliza, añadir entradas para compras recurrentes, aclarar los límites de aprobación, mostrar a la siguiente persona responsable y registrar por qué alguien devuelve o rechaza una solicitud.
AppMaster puede ayudar a los equipos a crear una aplicación de compras sin código sin empezar con un proyecto técnico vacío. Los equipos pueden crear formularios de solicitud para empleados, usar Business Process Editor para los controles presupuestarios y las rutas de aprobación, y crear pantallas separadas para responsables y personal de compras. Data Designer puede mantener en un único lugar los artículos del catálogo, departamentos, proveedores, presupuestos y solicitudes.
Un piloto pequeño muestra rápidamente los problemas prácticos. Si los empleados siguen enviando solicitudes por correo, averigua por qué antes de añadir más reglas. Crea un recorrido que elijan porque es más claro y rápido que la alternativa. Cuando el piloto funcione sin problemas, adapta la estructura al siguiente departamento y conserva su catálogo y sus reglas de aprobación vinculados a la forma en que ese equipo gasta el dinero.
¿Por qué se atascan las solicitudes de compra?Coloca cada solicitud en un registro compartido desde el primer borrador hasta el pedido y la recepción. Incluye el artículo, el coste, el centro de costes, el motivo empresarial, el responsable actual, los comentarios y el historial de decisiones para que nadie tenga que reconstruir la información a partir de correos y chats.
¿Qué datos debe incluir un formulario de solicitud de compra?Solicita el artículo o servicio, la cantidad, el coste estimado, el centro de costes, el motivo empresarial y la fecha en que se necesita. Añade los datos del proveedor y los presupuestos cuando el solicitante los tenga, pero no obligues a nadie a encontrar un proveedor antes de enviar la solicitud.
¿Deberíamos usar un catálogo para las solicitudes de compra?Usa un catálogo para compras habituales y preaprobadas, como portátiles, licencias de software y material de oficina. Permite que los empleados seleccionen un artículo con el precio y los datos del proveedor guardados, pero conserva una opción de texto libre para necesidades poco habituales.
¿Cuándo debe comprobar el sistema el presupuesto?Muestra el total de la solicitud, el presupuesto disponible y el saldo restante antes de iniciar la aprobación. Incluye impuestos, envío, gastos de configuración y cargos recurrentes para que el control presupuestario refleje el importe que la empresa espera pagar.
¿Qué ocurre cuando una solicitud supera el presupuesto?Asigna a las solicitudes que superen el presupuesto una ruta concreta en lugar de dejarlas con un estado pendiente poco claro. Devuelve la solicitud para que se modifique, envíala al responsable del presupuesto para que autorice una excepción o dirige los casos urgentes a finanzas. Después, registra la decisión en la propia solicitud.
¿Cómo deben funcionar las rutas de aprobación?Dirige las solicitudes según el importe, el departamento, el centro de costes y la categoría de compra. Los artículos rutinarios de bajo coste pueden necesitar solo la aprobación de un responsable, mientras que el software nuevo o los contratos de mayor importe pueden requerir también la revisión de presupuesto, TI, seguridad o compras.
¿Cómo evitamos que las ausencias de los aprobadores bloqueen las solicitudes?Asigna un aprobador suplente concreto y establece plazos de respuesta. Por ejemplo, recuerda la solicitud al responsable después de dos días laborables y reasígnala después de cinco si nadie actúa.
¿Qué estados debe tener una solicitud de compra?Empieza con los estados Borrador, Enviada, Aprobada, Rechazada, Pedida y Recibida. Mantén Aprobada separado de Pedida porque la aprobación autoriza el gasto, mientras que Pedida confirma que compras creó o realizó el pedido.
¿Qué debe ocurrir si cambia una solicitud aprobada?Devuelve la solicitud a la ruta de aprobación correspondiente cuando alguien cambie de forma significativa la cantidad, el proveedor o el precio. Mantén editables los detalles menores, como el contacto de entrega, sin obligar a iniciar una nueva revisión.
¿Cómo podemos probar un sistema de solicitudes de compra antes de lanzarlo?Prueba una compra de catálogo, una solicitud a un proveedor nuevo, un servicio recurrente y una solicitud que supere el presupuesto con usuarios reales. AppMaster permite crear formularios, reglas presupuestarias, rutas de aprobación y pantallas de compras en una sola aplicación sin código, y ajustar después la lógica visual a partir de cada prueba.
14 jul 2026
8 min
13 jul 20269 min
08 jul 202610 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
