endefrit

Spécification de gestion des frais

Du justificatif du salarié à la demande examinée et au remboursement enregistré. Cette spécification commence par les utilisateurs, puis définit saisie, règles, approbations et responsabilités financières.

Version 1.0 · 11 septembre 2026 · Module en développement. « Actuel » décrit le code de main, pas une disponibilité vérifiée en production. « Requis » désigne les critères de livraison proposés. Ce document ne certifie pas la disponibilité en production.

Lire la spécification du suivi du temps

Qui utilise ces modules et comment y accéder

Les équipes de production, de vente et de bureau utilisent une même identité personnelle pour le temps et les frais. Les parcours ci-dessous décrivent la cible. Application mobile, accès sans e-mail, bornes partagées et saisie hors ligne sont des exigences en développement, pas une déclaration de disponibilité.

Personnel de production

Au début du poste, s’identifier sur une borne fournie par l’employeur ou dans l’application mobile, puis démarrer le travail. Enregistrer les pauses et la fin du poste, y compris la nuit. Ni téléphone personnel ni e-mail ne doivent être obligatoires. La borne revient à l’écran verrouillé après chaque action et ne révèle jamais les heures, justificatifs ou comptes des collègues.

Pour un achat ponctuel, par exemple du matériel convenu ou un déplacement, joindre le justificatif dans l’application ou dans une session privée sur un appareil de l’entreprise. En cas d’aide, une personne autorisée indique qui a payé, qui a saisi la demande et pourquoi ; le salarié confirme avant l’envoi. Un responsable ne peut pas demander le remboursement d’un collègue en son propre nom. Cette saisie assistée reste à développer.

Vente et équipes itinérantes

Entre les visites clients, utiliser l’application iOS ou Android pour démarrer ou corriger le temps, choisir un projet, distinguer déplacement professionnel et privé, puis photographier le justificatif. Vérifier montant, devise, catégorie et payeur avant l’envoi. Une visite ou une position GPS ne devient pas automatiquement du travail approuvé. Le traitement des déplacements suit la règle convenue avec l’employeur.

Sans réseau, conserver les événements horaires et brouillons de frais de façon sécurisée sur l’appareil, avec la mention « pas encore synchronisé ». La reconnexion ne doit créer ni heures ni demandes en double. Un échec de téléversement conserve le brouillon ; l’envoi attend la confirmation du serveur et les pièces obligatoires. Aucun élément hors ligne ne peut apparaître approuvé ou remboursé.

Personnel de bureau

Utiliser l’application web sur ordinateur pour saisir le temps, l’affecter aux projets, vérifier la semaine et joindre les justificatifs. L’application mobile est facultative pour les reçus ou le travail hors du bureau. L’e-mail professionnel est pratique, mais le poste de travail ne détermine ni l’identité ni les droits. Confirmation du temps et envoi des frais restent deux actions distinctes.

Créer un compte sans e-mail professionnel

Comportement actuel du code : inscription, invitations et récupération du mot de passe reposent sur une identité e-mail. Une adresse personnelle convient au champ ; le schéma d’inscription n’impose pas de domaine d’entreprise. Le formulaire d’invitation peut omettre l’adresse, déjà fournie par l’invitation. Ce n’est pas une inscription sans e-mail. L’accès par téléphone seul, matricule ou borne n’est pas implémenté.

Exigence cible : un administrateur crée ou importe le salarié dans la bonne organisation, lui attribue un responsable, un lieu de travail, un horaire et des modules, puis remet un code d’activation à usage unique en personne ou par un canal approuvé. Le salarié active son propre compte, choisit sa langue et définit un accès privé. Aucun e-mail fictif, compte partagé du responsable, téléphone personnel ou abonnement acheté par le salarié n’est requis. Le code ne permet jamais de choisir librement employeur ou rôle.

Récupération, appareils partagés et départ

Connexion proposée : code d’organisation, identifiant salarié et secret personnel. Un PIN court est réservé aux bornes d’entreprise enregistrées, avec limite de tentatives et session restreinte ; un matricule ou badge seul ne prouve pas l’identité. Les codes expirent après 48 heures ou une utilisation. Après vérification d’identité, un administrateur autorisé peut délivrer un remplacement et révoquer les sessions ; chaque récupération est tracée. Ne jamais afficher ni envoyer l’ancien secret.

Un appareil perdu peut être révoqué sans supprimer les données du salarié. Au départ, retirer l’accès à l’organisation et refuser les actions mobiles en attente ; transmettre temps et frais non réglés au responsable et au référent finance désignés. Les RH définissent comment remettre ses relevés à l’ancien salarié. Un changement d’employeur ne doit jamais donner accès aux données de l’ancienne organisation.

Périmètre de l’application et validation

La direction déjà retenue est une application React Native pour iOS et Android, en complément du web. Première version salariée proposée : activation et connexion, temps et pauses, corrections, revue hebdomadaire, justificatifs, envoi et suivi des frais. Responsables et administrateurs commencent sur le web. L’installation sur un appareil personnel est facultative ; l’employeur fournit une alternative utilisable. Version native, accès sans e-mail et borne nécessitent chacun une validation.

Avant le déploiement, démontrer trois parcours complets : un salarié de production sans e-mail ni téléphone termine un poste et envoie un justificatif ; un commercial enregistre visite et reçu hors ligne, synchronisés une seule fois ; un salarié de bureau corrige sa semaine et suit un remboursement. Vérifier les quatre langues, erreurs compréhensibles, clavier et lecteur d’écran, confidentialité entre utilisateurs de la borne et décisions visibles sans notification e-mail. Il s’agit de critères de lancement, pas de tests déjà réussis.

Saisie et vérification du justificatif

Actuel : le salarié crée son brouillon avec vendeur, date, montant dans la devise de l’organisation, catégorie et moyen de paiement. Description, justificatif, projet et indicateur facturable complètent le contexte ; montant et devise d’origine peuvent être conservés séparément. Les catégories couvrent voyages, repas, hébergement, transport, logiciels, fournitures, représentation, formation, équipement et autres achats.

Actuel : la lecture JPEG, PNG, WebP ou PDF exige Frais et IA. Le lecteur multipart accepte jusqu’à 10 Mio. Il extrait les champs de frais et les coordonnées fournisseur/client, dates et numéros de facture, ventilations fiscales, lignes, modalités de paiement, texte lisible et champs supplémentaires. Les montants détaillés restent dans la devise de la facture. La pièce originale est conservée et les champs extraits sont modifiables.

Actuel : le contrat d’extraction demande null pour les inconnues, des avertissements en cas d’ambiguïté et aucune date, devise ou taxe inventée. C’est une instruction au modèle, pas une garantie d’exactitude. Le salarié vérifie chaque champ ; la saisie manuelle reste possible sans IA. Requis : tester documents illisibles ou multiples, afficher les avertissements, conserver le brouillon en cas d’échec et ne jamais assimiler suggestion et approbation. Lire un avoir ne signifie pas prendre en charge un processus de remboursement fournisseur.

Montants, devises et payeur

Actuel : fonds personnels et carte d’entreprise sont distincts. Un reçu étranger conserve montant et devise d’origine, sans conversion automatique par un service de change. Le salarié vérifie et saisit le montant dans la devise de l’organisation ; la lecture peut initialement copier le total étranger dans ce champ. L’indicateur facturable signale une charge client possible, sans créer de facture.

Requis : afficher les deux codes de devise et faire confirmer explicitement la conversion. Enregistrer taux, date, source ou justification manuelle et arrondi. Pour EUR 100 remboursés CHF 95, approbation, règles et totaux financiers utilisent CHF 95 ; le reçu reste à EUR 100. Conserver la devise de chaque montant historique si la devise par défaut change. Ne pas additionner des devises différentes ni traiter les dépenses par carte comme une dette envers le salarié.

Règles par catégorie et exceptions

Actuel : les administrateurs définissent catégories interdites, plafond et seuil de justificatif. Une catégorie interdite ou un justificatif absent pour un montant strictement supérieur au seuil bloque l’envoi. Dépasser le plafond produit un avertissement mais permet l’examen. Au seuil exact, la condition « au-dessus » ne s’applique pas. Une catégorie sans règle configurée n’a pas de restriction de catégorie.

Requis : expliquer chaque violation et conserver le brouillon si l’envoi est bloqué. Montrer la version des règles à l’envoi et à l’examen ; un changement ne réécrit pas une décision passée. Une approbation au-delà du plafond nécessite une raison enregistrée. Une exception sans reçu exige un examinateur désigné et des éléments probants, pas une pièce fictive. Versionnement et exceptions sont proposés ; actuellement les avertissements sont recalculés à la lecture et les blocages vérifiés à l’envoi.

Brouillon, examen et remboursement

Actuel : une demande commence en Brouillon. Son auteur modifie ou supprime Brouillon et Rejetée, puis les envoie. L’envoi les passe à Soumise et efface les anciens champs de décision. Le responsable passe à Approuvée ou Rejetée ; le formulaire exige une note de rejet. Le salarié corrige et renvoie. Les salariés ordinaires ne modifient pas Soumise, Approuvée ou Remboursée. Les administrateurs peuvent corriger les demandes hors brouillon, y compris les leurs, sans changer le statut ; cela ne permet pas l’auto-approbation.

Actuel : seul un administrateur peut marquer Remboursée une demande Approuvée payée personnellement, après paiement hors Flipp. Les demandes par carte d’entreprise s’arrêtent à Approuvée. Personne ne peut approuver, rejeter ou marquer remboursée sa propre demande. Requis : conserver chaque décision et nouvel envoi, traiter sûrement les transitions périmées ou répétées, distinguer « approuvée, paiement attendu » de « remboursée ». Enregistrer date et référence du paiement ; le marquage ne déclenche jamais de virement.

Responsabilités du salarié, du responsable et de la finance

Actuel : les salariés gèrent leurs demandes modifiables. Les responsables examinent leur hiérarchie ; les administrateurs, l’organisation. Rapports et export Excel appliquent le même périmètre. Le module Frais doit être activé. Un intitulé de poste en finance ne donne aucun droit : marquer un remboursement exige actuellement les droits administrateur, sans auto-examen.

Requis : désigner un suppléant et un autre approbateur pour les demandes des responsables et administrateurs. À défaut, conserver la demande en attente d’une décision organisationnelle autorisée ; ne pas contourner l’interdiction d’auto-examen. Proposer un droit finance limité au suivi des paiements et rapports utiles. Fixer délais d’examen et de paiement, montrer les files en retard et rappeler ou escalader sans approuver automatiquement.

Rapports, corrections et transmission à la finance

Actuel : les rapports filtrent dates, catégorie et statut, avec totaux par catégorie, auteur, statut et mois. Excel contient montants, moyen de paiement, statut, projet et responsable, plus des feuilles de lignes, taxes, champs supplémentaires et texte liées par ID de dépense. Les corrections administratives enregistrent avant/après, auteur et date atomiquement, refusent les versions périmées et affichent l’historique. Elles préservent approbation et remboursement. Un rapport avec brouillons ou rejets n’est pas un solde à payer ; aucun paiement ni échange comptable n’est exécuté.

Requis : la finance reçoit un lot identifiable de demandes approuvées sur fonds personnels encore impayées, avec IDs, devises et statuts rapprochés du rapport. Réexporter ne doit pas provoquer un autre paiement. Séparer cartes et demandes payées. Modifier un montant approuvé exige une raison et un nouvel examen ; une demande remboursée nécessite un ajustement préservant le montant payé. L’historique actuel ne suffit pas puisque les corrections conservent le statut. Clôture, date/référence de paiement et contrôles des lots restent proposés.

Confidentialité et limites du produit

Requis : protéger les justificatifs comme les demandes, y compris liens, exports et caches des appareils partagés. Montrer ce qui part au traitement IA et permettre la saisie manuelle si la lecture est désactivée ou échoue. Ne pas collecter localisation continue, activité privée ou identifiants bancaires pour saisir temps ou frais. Convenir avec le client de la conservation, suppression autorisée, conservation de l’audit et accès après départ avant lancement ; aucune durée n’est promise ici.

Cette spécification ne livre pas d’applications natives, comptes sans e-mail, bornes, synchronisation hors ligne, barèmes kilométriques, indemnités, avances, demandes fractionnées, détection automatique de doublons, détermination fiscale/TVA, paiements ou intégrations comptables. Lire les taxes imprimées ne détermine pas leur admissibilité fiscale. L’IA n’autorise ni dépenses ni remboursements.

Scénarios de validation des frais

Critères de lancement : démontrer une demande sur fonds personnels du brouillon au rejet, correction, approbation et remboursement ; une carte d’entreprise s’arrête à l’approbation. Avec plafond 100 et seuil 50, 50 sans reçu ne déclenche pas le seuil, 50.01 le déclenche, et 100.01 avec reçu avertit mais permet l’envoi. Vérifier EUR 100 / CHF 95, lecture échouée complétée manuellement, échec d’envoi de pièce et nouvelle tentative hors ligne sans doublons.

Démontrer aussi qu’un responsable ne voit pas une équipe sans lien, qu’une autre organisation ne peut obtenir pièce ou export et que personne ne révise sa demande. Tester absence du responsable, décisions concurrentes, correction du montant approuvé, départ avec demande impayée et export répété. Montrer historique sauvegardé, statut visible au salarié et totaux rapprochés. Ces scénarios définissent la cible ; leur réussite doit être démontrée avant le déploiement.