Découvrez comment créer un système interne de demandes d’achat avec des articles de catalogue, des contrôles budgétaires, des approbations claires et un transfert fluide vers les bons de commande.
La plupart des retards d’achat commencent avant même qu’une personne approuve ou refuse une demande. Un employé demande un ordinateur portable par e-mail, partage un prix dans une conversation, puis ajoute une ligne dans un tableur pour les finances. Chaque endroit ne contient qu’une partie de la demande. L’acheteur doit ensuite réunir le fournisseur, le coût, le motif professionnel, le responsable du budget et la date limite.
Cela crée du travail en double. Un responsable demande des informations que l’employé a déjà envoyées aux finances. L’équipe financière vérifie le budget, mais ne sait pas si le responsable du service a approuvé le besoin. L’employé ne sait pas où en est la demande ni qui doit agir ensuite.
Un circuit d’approbation des achats ralentit lorsque la demande ne contient pas les informations dont chaque intervenant a besoin. Les oublis les plus courants sont les suivants :
Un seul oubli peut renvoyer la demande au point de départ. Un chef d’équipe peut approuver le renouvellement d’un logiciel à 1 200 $, puis les finances découvrent que personne n’a indiqué le budget concerné. Au lieu de passer la commande, l’équipe perd plusieurs jours à chercher la personne responsable de cette dépense.
Un système interne de demandes d’achat regroupe toute la demande, de l’envoi initial jusqu’au transfert vers le bon de commande. Le demandeur saisit le besoin une seule fois. Les responsables, les équipes financières et les acheteurs voient les mêmes informations, ajoutent leurs commentaires au même enregistrement et disposent d’un historique visible des décisions.
Des libellés de statut clairs réduisent les relances inutiles. Une demande peut indiquer si elle attend un contrôle budgétaire, l’approbation d’un responsable, l’action d’un acheteur ou des informations sur le fournisseur. Chaque étape doit avoir une personne ou un rôle désigné, ainsi qu’une règle de remplacement en cas d’absence.
Une application d’achats sans code rend cette organisation possible sans laisser les équipes opérationnelles gérer seules des formulaires et des tableurs. AppMaster peut regrouper les formulaires de demande, les champs budgétaires, la logique d’approbation et la file d’attente des acheteurs dans une seule application. Chaque demande doit avoir un espace unique, un responsable actuel et suffisamment d’informations pour avancer vers une commande.
Un formulaire de demande doit donner aux responsables et aux acheteurs assez d’informations pour décider rapidement. Si les employés doivent expliquer les faits essentiels dans des messages de suivi, le formulaire est trop limité. S’il demande des informations financières qu’ils ne peuvent pas connaître, ils vont les deviner ou abandonner.
Chaque demande doit comporter le nom de l’article, la quantité, le fournisseur, le coût unitaire estimé, le coût total et le motif professionnel. Ajoutez le service, le centre de coûts, le demandeur et la date souhaitée lorsque ces informations ont une incidence sur le budget ou la livraison. Après sa connexion, l’employé peut être renseigné automatiquement comme demandeur, avec son service.
Un motif court fonctionne mieux qu’une grande zone de texte vide. Par exemple : « Cinq accès supplémentaires au support client pour la nouvelle équipe du soir. » L’approbateur comprend ainsi le besoin concret, la quantité et le lien avec le travail actuel.
Les achats sur catalogue et les achats ponctuels ont besoin de formulaires différents. Un article du catalogue possède déjà une description approuvée, un fournisseur, un prix et parfois une référence de contrat. Les employés peuvent le sélectionner, indiquer une quantité et expliquer le besoin. Les demandes courantes restent ainsi cohérentes.
Un achat ponctuel demande davantage de contexte, car les achats doivent l’évaluer avant de passer commande. Demandez la description de l’article ou du service, le fournisseur privilégié et son contact s’ils sont connus, le devis ou le coût estimé, la quantité et la fréquence de facturation, le motif professionnel et la date de livraison souhaitée.
N’obligez pas les employés à trouver un fournisseur avant de pouvoir demander quelque chose. Ils peuvent savoir qu’ils ont besoin d’un bureau assis-debout sans savoir quel fournisseur respecte les règles de l’entreprise. Les achats pourront compléter cette partie plus tard.
Rendez un champ obligatoire uniquement lorsqu’une personne en a besoin pour approuver, budgéter ou acheter. L’article, la quantité, le coût estimé, le centre de coûts et le motif font généralement partie de ce groupe. Les pièces jointes ne devraient être obligatoires qu’au-delà d’un certain montant ou pour des catégories comme les abonnements logiciels.
Les champs conditionnels rendent le formulaire plus simple à remplir. Une demande de logiciel peut demander le nombre d’utilisateurs, la date de renouvellement et si le logiciel traitera des données clients. Un article physique peut demander une adresse de livraison à la place. Chaque circuit d’approbation des achats obtient les informations nécessaires sans imposer un long formulaire à tous les employés.
Avant le lancement, envoyez trois demandes de test : un article du catalogue, un achat auprès d’un nouveau fournisseur et un service récurrent. Si un approbateur pose encore une question évidente, ajoutez un champ ou rendez un champ existant plus clair.
Un catalogue élimine les tâches répétitives. Au lieu de demander à chaque employé de décrire un ordinateur portable, une licence logicielle ou une chaise de bureau à partir de zéro, proposez une courte liste de choix approuvés.
Chaque article du catalogue doit inclure une description simple, son prix unitaire habituel et son fournisseur privilégié. Ajoutez les informations qui évitent les échanges supplémentaires, comme un code article, la durée du contrat, les tailles disponibles ou l’obligation pour un responsable de confirmer le besoin.
Une entrée « Ordinateur portable standard » peut par exemple indiquer le modèle, le fournisseur approuvé, le prix de 1 200 $ et une garantie de trois ans. Le demandeur sélectionne une quantité et explique qui utilisera les ordinateurs. Les achats reçoivent ainsi des informations utiles et cohérentes à chaque demande.
Ne transformez pas le catalogue en copie de chaque site fournisseur. Commencez par les articles que les employés commandent souvent, puis ajoutez des entrées lorsqu’une même demande en saisie libre revient régulièrement. Un catalogue long et mal organisé crée un nouveau retard.
Regroupez les articles dans des catégories familières, comme les logiciels, le matériel, les fournitures de bureau et les services professionnels. Utilisez la recherche et des noms courts pour que chacun puisse trouver un article avant de commencer à rédiger une description.
Une entrée de catalogue contient généralement le nom de l’article, sa description, son prix unitaire ou sa fourchette prévue, son fournisseur privilégié, son unité de facturation et les éventuelles restrictions. Un abonnement peut par exemple afficher « par utilisateur et par mois » et préciser qu’il doit être approuvé par un responsable.
Les employés auront parfois besoin d’un article qui ne figure pas dans la liste. Conservez une option de saisie libre, mais demandez suffisamment d’informations pour permettre l’étape suivante : le besoin, le coût estimé, le fournisseur s’il est connu et le motif professionnel.
Considérez les demandes en saisie libre comme une file de demandes à examiner, et non comme un échec du catalogue. Les achats peuvent comparer les devis, approuver un fournisseur ou décider d’ajouter l’article au catalogue pour les prochaines demandes.
Dans une application d’achats sans code créée avec AppMaster, la sélection d’un article du catalogue peut remplir automatiquement le prix, le fournisseur et les champs de la demande. Le processus d’approbation budgétaire repose ainsi sur des données plus propres et les corrections nécessaires avant le transfert vers le bon de commande sont réduites.
Une demande doit présenter son contexte financier avant qu’une personne commence une tâche d’approbation. Demandez au demandeur de sélectionner un service et un centre de coûts, puis d’indiquer le montant et la devise. Le système peut utiliser ces champs pour trouver le budget concerné.
Le contrôle doit rester simple pour les demandeurs. Ils doivent voir le total de la demande, le budget disponible et le montant restant après approbation. Un message comme « Cette demande dépasse le budget restant de 420 $ » évite qu’un responsable découvre le problème plus tard dans une conversation par e-mail.
Les finances doivent être responsables des chiffres budgétaires. Le personnel peut mettre à jour le montant approuvé pour chaque service ou centre de coûts au début d’une période et le modifier lorsque les plans changent. Le système interne de demandes d’achat doit aussi suivre les demandes approuvées qui ne sont pas encore devenues des factures. Sinon, un service peut sembler disposer d’argent alors qu’il a déjà engagé ces fonds.
Calculez ce que les achats paieront réellement. Incluez les quantités, les prix unitaires, les taxes, la livraison, les frais de mise en place et les charges récurrentes lorsqu’elles s’appliquent. Un abonnement logiciel à 900 $ avec 150 $ de frais de mise en œuvre représente une demande de 1 050 $.
Lancez le processus d’approbation budgétaire lorsque le demandeur envoie le formulaire, avant que le système ne le transmette à un approbateur. Vous éviterez ainsi de faire perdre du temps à l’équipe et permettrez au demandeur de corriger le centre de coûts, de réduire la commande ou d’expliquer une exception.
Dans une application d’achats sans code, cela peut prendre la forme d’une règle visuelle : lire le centre de coûts sélectionné, comparer le total de la demande au budget restant et enregistrer le résultat dans la demande. AppMaster peut modéliser les données de la demande, créer la logique dans son Business Process Editor et afficher le résultat dans un formulaire interne.
Ne laissez pas une demande dépassant le budget dans un statut ambigu. Donnez-lui un circuit défini, conforme à la politique de dépenses. Vous pouvez la renvoyer au demandeur en affichant l’écart, l’envoyer au responsable du budget pour obtenir une exception, transmettre un besoin urgent aux finances ou la mettre en attente jusqu’à la prochaine période budgétaire avec une date et un motif.
Enregistrez le résultat du contrôle budgétaire et toute décision d’exception. Lorsque les achats commencent la commande, le personnel doit pouvoir vérifier si la dépense respecte le budget initial et qui a approuvé le montant supplémentaire. Les finances peuvent aussi expliquer pourquoi un centre de coûts a dépassé ses prévisions.
Un système interne de demandes d’achat a besoin de règles d’orientation avant l’envoi de la moindre demande. Transmettez chaque demande aux personnes capables d’évaluer la dépense, plutôt qu’à une boîte de réception générique consultée de temps en temps.
Basez le circuit sur les informations déjà saisies dans le formulaire. Le service, le centre de coûts, la catégorie d’achat et le montant total offrent généralement assez de contexte. Une demande de 40 $ pour des fournitures de bureau peut nécessiter uniquement l’approbation d’un responsable d’équipe. Un nouveau contrat logiciel peut nécessiter l’avis du responsable du budget, de l’informatique, de la sécurité et des achats.
Gardez les circuits courts lorsque le risque est faible. Ajouter des approbateurs « au cas où » transforme un circuit d’approbation simple en une suite de retards. Chaque approbateur doit avoir une raison claire d’approuver, de refuser ou de demander des informations supplémentaires.
Les employés doivent savoir où leur demande sera envoyée avant de l’envoyer. Des règles prévisibles réduisent aussi les désaccords lorsqu’une demande prend du retard.
Une entreprise peut par exemple appliquer les règles suivantes :
Les règles ne doivent pas forcément être identiques dans tous les services. Les ventes peuvent demander une approbation pour les outils destinés aux clients, tandis que les opérations peuvent avoir besoin d’un contrôle supplémentaire pour le matériel. Utilisez la même logique de base dans toute l’entreprise afin que les employés n’aient pas à réapprendre le processus à chaque demande.
Chaque approbateur doit avoir un remplaçant. Si un responsable est absent, le système doit envoyer les nouvelles demandes à un suppléant désigné ou permettre à un administrateur de réattribuer les tâches en attente. Les demandeurs ne devraient pas avoir à chercher quelqu’un par e-mail ou dans une conversation.
Fixez un délai de réponse. Vous pouvez par exemple avertir un approbateur après deux jours ouvrés et envoyer la demande à un remplaçant après cinq jours. L’escalade doit faire avancer la demande tout en conservant le circuit initial et l’historique des décisions.
Conservez chaque décision dans l’enregistrement de la demande. Indiquez qui l’a approuvée ou refusée, quand la décision a été prise et les commentaires associés. Un refus comme « Utilisez la licence d’équipe existante jusqu’au renouvellement » donne au demandeur une prochaine étape concrète et fournit aux achats le contexte nécessaire pour la commande.
AppMaster permet aux équipes de modéliser les champs des demandes, de créer la logique d’approbation dans un processus métier visuel et d’afficher le statut actuel aux demandeurs. Les responsabilités restent visibles au lieu de se perdre dans les échanges d’e-mails.
Un circuit clair empêche les achats simples de disparaître dans les e-mails. Chaque statut doit décrire l’état actuel et chaque personne doit savoir quand elle doit agir.
Commencez avec un petit ensemble de statuts : Brouillon, Envoyée, Approuvée, Rejetée, Commandée et Reçue. Évitez les libellés presque identiques, comme « en cours d’examen » et « en attente d’approbation ». Les utilisateurs les emploieraient de façon incohérente et les rapports en pâtiraient.
Une demande commence à l’état Brouillon. Le demandeur peut l’enregistrer, modifier l’article ou la quantité, ou la supprimer. À cette étape, le système ne doit pas envoyer de notifications ni réserver de budget.
Lorsque le demandeur envoie le formulaire, le statut devient Envoyée. Verrouillez le prix, les informations sur le fournisseur et le montant demandé, sauf si quelqu’un renvoie la demande pour modification. L’approbateur peut l’approuver, la refuser ou la renvoyer avec un court commentaire.
Après l’approbation, transmettez la demande aux achats. Le personnel ne doit la marquer comme Commandée qu’après avoir créé ou passé le bon de commande. L’autorisation de dépenser ne prouve pas que quelqu’un a acheté l’article.
Lorsque les marchandises arrivent, que l’accès au service commence ou qu’un abonnement est confirmé, la personne chargée de la réception marque la demande comme Reçue. Les finances et les demandeurs disposent ainsi d’un historique fiable de ce qui a été reçu.
Un système interne simple de demandes d’achat fonctionne mieux lorsque les changements de statut ont des responsables. N’autorisez pas tous les utilisateurs à modifier toutes les demandes envoyées.
Un administrateur doit gérer les exceptions, par exemple lorsqu’un approbateur quitte l’entreprise ou lorsqu’une demande est en double. Conservez une piste d’audit pour chaque changement de statut, avec son auteur, sa date et les éventuels commentaires.
Envoyez une notification lorsqu’une demande envoyée arrive chez un approbateur. Incluez le titre de la demande, le montant, le service et la décision attendue. Un message vague comme « Vous avez une nouvelle tâche » ralentit l’action, car il faut rechercher le contexte.
Prévenez le demandeur lorsqu’une personne approuve, refuse ou renvoie la demande. Exigez un commentaire en cas de refus ou de renvoi. « Budget indisponible ce trimestre » donne une indication utile au demandeur, contrairement à « Non ».
Les achats doivent recevoir une notification après l’approbation finale. Le demandeur doit être informé lorsque les achats marquent la demande comme Commandée puis Reçue. Si personne n’agit pendant une période définie, rappelez la demande au responsable actuel et mettez l’approbateur suppléant en copie.
Avec AppMaster, une application d’achats sans code peut modéliser les statuts dans le Data Designer et contrôler les changements autorisés dans le Business Process Editor. Chaque transfert reste enregistré au même endroit au lieu de dépendre de la mémoire de quelqu’un.
Maya, responsable marketing, a besoin de 15 abonnements à un outil de planification des réseaux sociaux. Elle ouvre le système interne de demandes d’achat et sélectionne l’outil dans le catalogue logiciel au lieu de créer une demande libre.
L’entrée du catalogue contient le fournisseur, le type de forfait, le prix par utilisateur, le cycle de facturation et l’équipe responsable du contrat. Maya indique 15 accès, sélectionne le centre de coûts Marketing et ajoute le motif suivant : l’équipe a besoin de planifier les publications ensemble et de les faire approuver.
L’application calcule le coût annuel avant l’envoi. Le marketing dispose d’un budget logiciel suffisant, la demande passe donc le contrôle budgétaire. Si le budget était insuffisant, l’application pourrait bloquer la demande et demander à Maya de choisir un autre centre de coûts ou de solliciter un financement supplémentaire. Cela évite qu’un responsable approuve un achat que les finances ne pourront pas payer.
La responsable du service de Maya reçoit la demande, car son montant reste dans la limite de dépenses de la responsable. L’écran d’approbation affiche le coût, le nombre d’utilisateurs, le motif professionnel et le solde budgétaire. La responsable approuve la demande.
Les achats reçoivent un dossier complet avec le fournisseur et le forfait, le total annuel et la date de renouvellement, le centre de coûts et le résultat budgétaire, le motif de Maya ainsi que l’approbation horodatée de la responsable. Un coordinateur des achats vérifie si l’entreprise possède déjà un accord avec le fournisseur. Si c’est le cas, il crée le bon de commande à partir des informations enregistrées. Sinon, il lance l’évaluation du fournisseur avant de passer la commande.
Le coordinateur enregistre le numéro du bon de commande et marque la demande comme Commandée. Maya voit la mise à jour sans avoir à contacter les achats. Lorsque le fournisseur confirme les 15 licences, le coordinateur marque la demande comme Reçue et indique qui administrera le compte.
Ce circuit rattache chaque décision à la demande. Les finances peuvent voir pourquoi l’équipe a acheté le logiciel, quel budget l’a financé et qui a approuvé la dépense.
Un processus d’achat peut sembler simple sur un schéma et pourtant frustrer ses utilisateurs. Les problèmes apparaissent généralement lorsque le système traite chaque demande comme un cas particulier ou ne contrôle plus les changements après approbation.
De nombreuses équipes envoient chaque demande à un seul responsable senior. Cette personne devient le point de passage pour les articles courants, comme un clavier de remplacement, le renouvellement mensuel d’un logiciel ou les fournitures sous un petit seuil de dépenses. Si elle est absente pendant deux jours, tout le monde attend.
Adaptez les circuits d’approbation au coût, au service et au type de demande. Un chef d’équipe peut approuver un article standard du catalogue sous un certain seuil. Un responsable de service peut examiner les achats plus importants. Les finances peuvent intervenir lorsqu’une demande a une incidence sur le budget ou dépasse une limite. Les dirigeants doivent recevoir les exceptions, pas les demandes ordinaires.
L’approbation finale porte sur un article, une quantité, un fournisseur et un prix précis. Si quelqu’un modifie ces éléments ensuite, l’approbation peut ne plus correspondre à la dépense.
Définissez des règles pour les modifications importantes. Le passage de 10 à 12 licences ou de 500 $ à 1 200 $ doit renvoyer la demande à l’évaluateur concerné. Des notes mineures, comme le contact chargé de la livraison, peuvent rester modifiables sans relancer le circuit d’approbation des achats.
Une application d’achats sans code peut conserver l’historique des modifications et rouvrir l’approbation lorsque des champs contrôlés changent. Les écarts sont ainsi évités lorsque les finances comparent le montant approuvé à une facture.
L’approbation ne marque pas la fin des achats. L’équipe doit encore enregistrer le fournisseur, le numéro du bon de commande, le prix final, la date de commande et le statut de livraison. Si quelqu’un clôture la demande avant que ces informations existent, le personnel devra ensuite les rechercher dans les e-mails et les tableurs.
Utilisez des statuts clairs comme Approuvée, Commandée, Reçue et Clôturée. Ne passez une demande à Clôturée qu’après l’enregistrement des détails de la commande et la confirmation du transfert par les achats. Un abonnement annuel approuvé doit rester au statut Approuvée jusqu’à ce que l’acheteur enregistre la commande du fournisseur ou la référence de renouvellement.
Cette distinction rend les rapports plus fiables. Les équipes voient quelles demandes approuvées nécessitent encore une action, quelles commandes attendent une livraison et quels achats sont terminés.
Un court test permet de détecter la plupart des problèmes avant que les employés ne dépendent du système interne de demandes d’achat. Demandez à un petit groupe d’envoyer des demandes réalistes, comme des fournitures de bureau, un renouvellement logiciel et un contrat de service. Incluez des demandeurs, des approbateurs et les personnes qui créent les bons de commande.
Chaque demande doit avoir un responsable clair et un statut visible. Le responsable doit changer lorsque la responsabilité passe du demandeur à un responsable ou à un acheteur. Les libellés doivent expliquer ce qui s’est passé, par exemple Brouillon, Envoyée, Approuvée, Rejetée ou Transmise aux achats.
Avant d’ouvrir l’application à tous, vérifiez que chaque demande affiche son responsable, son statut actuel, son montant et son prochain approbateur. Comparez les règles d’approbation aux limites de dépenses et aux règles réelles de chaque service. Vérifiez que les achats voient le fournisseur, le prix du devis, la quantité approuvée et la date de livraison souhaitée.
Testez une demande dépassant le budget et confirmez que l’application la bloque ou l’envoie à la bonne personne. Refusez une autre demande avec un motif clair, puis vérifiez que le demandeur reçoit ce motif et peut modifier le formulaire.
Utilisez de vrais montants pour tester le budget. Donnez à une équipe un budget mensuel restant de 2 000 $, puis envoyez une demande de 2 400 $. Décidez si le système doit la bloquer, demander l’approbation des finances ou permettre au responsable budgétaire de déplacer des fonds. Toutes les personnes concernées doivent voir le même résultat.
Testez aussi les modifications après approbation. Un demandeur peut augmenter une commande de 10 à 15 écrans, ou un fournisseur peut relever le prix indiqué dans son devis. Le circuit d’approbation des achats doit renvoyer la demande pour une nouvelle approbation ou identifier clairement les changements qui ne nécessitent pas de nouvel examen. Les modifications silencieuses créent des désaccords par la suite.
Enfin, testez le transfert vers le bon de commande. Les achats doivent recevoir les informations approuvées au même endroit, sans les recopier depuis un e-mail ou une conversation. Dans AppMaster, les équipes peuvent tester ces circuits avec des enregistrements d’exemple et ajuster les règles visuelles avant de publier l’application. Tenez un court journal des tests qui ont échoué, corrigez la règle à l’origine de chaque problème et recommencez le test.
Commencez par un service qui effectue des achats récurrents et dont le circuit d’approbation reste facile à gérer. Les logiciels informatiques, les fournitures de bureau ou les abonnements marketing sont de bons points de départ. Donnez à ce groupe un court catalogue avec les articles courants, les prix estimés et les informations nécessaires aux achats.
Gardez la première version ciblée. Le demandeur doit pouvoir envoyer un besoin clair, l’approbateur doit voir le coût et le statut budgétaire, et les achats doivent recevoir une demande complète après approbation. Ajoutez les types de demandes inhabituels lorsque le circuit de base fonctionne de manière fiable.
Demandez l’avis des personnes qui utilisent chaque partie du système interne de demandes d’achat après les premières semaines. Les demandeurs peuvent signaler les champs difficiles à comprendre. Les approbateurs peuvent expliquer où ils ont besoin de davantage de contexte. Les équipes achats peuvent indiquer les informations fournisseurs manquantes ou les demandes qui arrivent encore en dehors de l’application.
Utilisez ces retours pour supprimer les champs inutilisés, ajouter des articles pour les achats récurrents, clarifier les limites d’approbation, afficher le prochain responsable et enregistrer le motif d’un renvoi ou d’un refus.
AppMaster peut aider les équipes à créer une application d’achats sans code sans commencer par un projet technique vide. Elles peuvent créer les formulaires de demande des employés, utiliser le Business Process Editor pour les contrôles budgétaires et les circuits d’approbation, et concevoir des écrans distincts pour les responsables et les achats. Le Data Designer peut regrouper les articles du catalogue, les services, les fournisseurs, les budgets et les demandes au même endroit.
Un petit pilote permet de faire apparaître rapidement les problèmes pratiques. Si les employés continuent à envoyer leurs demandes par e-mail, cherchez pourquoi avant d’ajouter d’autres règles. Créez un circuit que les utilisateurs choisissent parce qu’il est plus clair et plus rapide que la solution de contournement. Une fois le pilote stabilisé, adaptez la structure au service suivant en conservant son catalogue et ses règles d’approbation, liés à sa manière de dépenser.
Pourquoi les demandes d’achat restent-elles bloquées ?Regroupez chaque demande dans un enregistrement partagé, du premier brouillon jusqu’à la commande et la réception. Ajoutez l’article, le coût, le centre de coûts, le motif professionnel, le responsable actuel, les commentaires et l’historique des décisions afin que personne n’ait à reconstituer les informations à partir des e-mails et des conversations.
Quelles informations un formulaire de demande d’achat doit-il contenir ?Demandez l’article ou le service, la quantité, le coût estimé, le centre de coûts, le motif professionnel et la date souhaitée. Ajoutez les informations sur le fournisseur et les devis lorsque le demandeur les possède, mais ne demandez pas aux employés de trouver un fournisseur avant de pouvoir envoyer leur demande.
Faut-il utiliser un catalogue pour les demandes d’achat ?Utilisez un catalogue pour les achats courants et préapprouvés, comme les ordinateurs portables, les licences logicielles et les fournitures de bureau. Les employés peuvent sélectionner un article dont le prix et les informations fournisseur sont déjà enregistrés, tout en conservant une option de saisie libre pour les besoins inhabituels.
Quand le système doit-il contrôler le budget ?Affichez le montant total de la demande, le budget disponible et le solde restant avant le début de l’approbation. Incluez les taxes, la livraison, les frais de mise en place et les charges récurrentes afin que le contrôle budgétaire corresponde au montant que l’entreprise prévoit réellement de payer.
Que se passe-t-il lorsqu’une demande dépasse le budget ?Définissez un circuit précis pour les demandes dépassant le budget au lieu de les laisser dans un statut d’attente vague. Renvoyez la demande pour modification, envoyez-la au responsable du budget pour obtenir une exception ou transmettez les cas urgents aux finances, puis enregistrez la décision dans la demande.
Comment les circuits d’approbation doivent-ils fonctionner ?Orientez les demandes selon leur montant, leur service, leur centre de coûts et leur catégorie d’achat. Les articles courants de faible montant peuvent nécessiter un seul responsable, tandis qu’un nouveau logiciel ou un contrat important peut aussi demander l’avis des finances, de l’informatique, de la sécurité ou des achats.
Comment éviter que l’absence d’un approbateur bloque les demandes ?Désignez un approbateur suppléant et fixez des délais de réponse. Par exemple, rappelez la demande au responsable après deux jours ouvrés et réattribuez-la après cinq jours si personne n’a agi.
Quels statuts une demande d’achat doit-elle comporter ?Commencez par les statuts Brouillon, Envoyée, Approuvée, Rejetée, Commandée et Reçue. Gardez Approuvée séparé de Commandée : l’approbation autorise la dépense, tandis que le statut Commandée confirme que les achats ont créé ou passé la commande.
Que faire si une demande approuvée est modifiée ?Renvoyez la demande dans le circuit d’approbation concerné lorsqu’une personne modifie de manière importante la quantité, le fournisseur ou le prix. Les détails mineurs, comme le contact chargé de la livraison, peuvent rester modifiables sans imposer un nouvel examen.
Comment tester un système de demandes d’achat avant son lancement ?Testez un achat sur catalogue, une demande auprès d’un nouveau fournisseur, un service récurrent et une demande dépassant le budget avec de vrais utilisateurs. AppMaster permet de créer les formulaires, règles budgétaires, circuits d’approbation et écrans destinés aux achats dans une seule application sans code, puis d’ajuster les règles visuelles après chaque test.
14 juil. 2026
11 min
13 juil. 20267 min
08 juil. 20269 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
