Choisir un ERP auto-hébergé pour gérer plusieurs devises : une grille d’évaluation pratique

Pourquoi « prend en charge plusieurs devises » ne suffit pas

La présence d’un sélecteur de devise ne prouve pas qu’une application peut prendre en charge votre processus comptable. Vous devez savoir à quels éléments les devises s’appliquent, comment les montants sont convertis, quelles données sont enregistrées et comment les chiffres qui en résultent apparaissent dans les rapports.

Considérez les affirmations sur le produit comme des pistes de test, et non comme des réponses. Consultez la documentation officielle du fournisseur pour la version que vous prévoyez d’utiliser, puis reproduisez vos processus réels dans une instance de test. La documentation peut expliquer le comportement prévu ; un test peut révéler si la configuration convient à votre organisation.

La documentation officielle d’ERPNext sur les devises multiples est un exemple utile des distinctions à examiner : elle décrit séparément les rôles des devises de l’entreprise, des comptes, des transactions et des listes de prix. Il s’agit d’un exemple, et non d’une garantie qu’un autre produit utilise le même modèle.

• Notez les devises réellement utilisées par votre entreprise et l’usage de chacune.
• Indiquez les rapports et les décisions qui dépendent des montants convertis.
• Consignez chaque question non résolue comme une exigence produit à vérifier, et non comme une supposition.

Cartographier les usages de chaque devise

Suivez une transaction depuis le premier montant présenté au client jusqu’à son écriture comptable finale. Un devis ou une liste de prix peut utiliser une devise, tandis que la facture, la comptabilité de l’entreprise et le compte de paiement en utilisent d’autres. Le processus d’achat peut être différent.

Testez les devis ou les listes de prix, les factures de vente, les factures d’achat et les paiements comme des processus distincts. Ne supposez pas que le choix d’une devise dans une partie du système configure les comptes du grand livre correspondants ou les paramètres par défaut des clients et des fournisseurs. La documentation d’ERPNext sur les devises, par exemple, distingue la disponibilité d’une devise de la configuration des comptes en devises étrangères et des paramètres par défaut des tiers.

À chaque étape, notez la devise saisie par l’utilisateur, celle conservée dans l’enregistrement et celle qui apparaît dans le grand livre ou le rapport. Demandez ce qui se passe lorsque la devise d’un compte ne correspond pas à celle du document ou à celle de l’entreprise.

• Devis client : quelle devise apparaît sur le devis et sur les éventuelles listes de prix ?
• Facture de vente : quelle devise est saisie, et quel montant est comptabilisé dans la devise de l’entreprise ?
• Facture fournisseur : peut-elle être enregistrée dans sa devise d’origine ?
• Paiement : quelles sont les devises disponibles pour le compte et le paiement, et comment le paiement est-il imputé ?
• Rapports : pouvez-vous identifier à la fois le montant initial de la transaction et le montant converti ?

Distinguer la devise de transaction de la devise de base ou de présentation

Demandez au fournisseur de définir les termes employés par le système pour parler des devises. La devise de base ou de l’entreprise n’est pas nécessairement identique à la devise d’une transaction, à la devise fixe d’un compte ou à celle d’une liste de prix. Un système peut convertir une transaction dans la devise de l’entreprise à des fins comptables, tout en conservant le montant en devise étrangère sur le document.

Utilisez un scénario simple pour vérifier cette distinction : émettez une facture dans la devise d’un client, puis examinez la facture, l’écriture du grand livre, le solde client et le rapport à l’échelle de l’entreprise. Vérifiez quels chiffres sont les montants d’origine et lesquels sont convertis. Demandez aussi si les utilisateurs peuvent les distinguer sans exporter les données ni effectuer de calcul manuel.

Indiquez clairement le traitement attendu dans vos notes d’évaluation. Si les termes du fournisseur ne sont pas clairs, demandez une démonstration fondée sur votre scénario plutôt que de vous fier à une affirmation générale selon laquelle le logiciel gère plusieurs devises.

• Documentez la devise prévue pour l’organisation ou les rapports.
• Repérez les comptes qui doivent conserver des soldes dans une devise donnée.
• Confirmez que la devise et le montant d’origine d’une transaction restent visibles après sa comptabilisation.
• Vérifiez si la conversion de la devise d’une liste de prix est distincte de la conversion comptable.

Vérifier comment les taux de change sont obtenus, datés et enregistrés

Un taux n’a de sens qu’avec sa date, sa source, son sens de conversion et son usage. Vérifiez si les taux sont saisis manuellement, importés depuis un fournisseur configuré, ou les deux. Déterminez qui peut les approuver ou les modifier et comment les utilisateurs peuvent savoir quel taux a été appliqué à une transaction.

Testez une transaction dont la date du document diffère de la date de saisie. Saisissez ensuite une autre transaction après un changement de taux. Vérifiez si l’application sélectionne un taux en fonction de la date pertinente, autorise l’utilisation d’un taux manuel approuvé et conserve une trace du taux utilisé. Ne supposez pas que le paramètre par défaut de l’application correspond à votre politique comptable.

La documentation d’ERPNext sur les taux de change décrit des enregistrements comportant des dates de validité, des devises source et cible, un taux et une applicabilité à l’achat ou à la vente. Consultez la documentation officielle à jour du produit retenu pour confirmer ses propres champs et règles de sélection.

• Qui peut ajouter, modifier ou approuver un taux de change ?
• L’utilisateur peut-il voir le taux, la date et la source appliqués à un document comptabilisé ?
• Que se passe-t-il si aucun taux n’existe pour la date de la transaction ?
• Le système peut-il utiliser un taux manuel approuvé lorsqu’un taux automatisé est disponible ?
• La modification d’un taux ne concerne-t-elle que les nouvelles transactions, ou peut-elle aussi modifier les enregistrements existants ?

Tester les arrondis, les paiements partiels, les remboursements et les avoirs

Utilisez des montants représentatifs de vos factures et de vos moyens de paiement habituels. Vérifiez à la fois la précision affichée aux utilisateurs et le montant finalement comptabilisé. Le nombre de décimales affichées ne suffit pas à établir les règles d’arrondi de chaque calcul ou écriture du grand livre ; la documentation d’ERPNext sur la précision distingue la précision monétaire de la méthode d’arrondi.

Enregistrez ensuite un paiement partiel à un taux de change différent de celui de la facture. Examinez le solde restant, l’imputation du paiement et tout écart de change réalisé. Effectuez un deuxième test pour régler le solde de la facture et vérifier l’imputation finale ainsi que les soldes.

Testez un avoir partiel, un remboursement et, si votre processus l’exige, l’utilisation d’un crédit client pour régler une autre facture. Vérifiez la devise affichée sur chaque document et la façon dont les montants correspondants sont reflétés dans les comptes. La documentation d’ERPNext sur les paiements et les avoirs présente ces opérations comme distinctes ; confirmez le comportement propre à l’application retenue.

• Créez une facture avec un montant comportant une fraction et examinez les valeurs affichées et comptabilisées.
• Réglez une partie de la facture à un taux différent de celui appliqué à la facture ; examinez le solde résiduel et l’écart réalisé.
• Terminez le paiement et vérifiez que la facture est clôturée comme prévu.
• Émettez un avoir partiel et testez le remboursement ou le processus d’imputation que vous utilisez réellement.
• Répétez les calculs les plus importants avec la précision monétaire et les paramètres d’arrondi que vous utilisez normalement.

Se renseigner sur la réévaluation en fin de période et les rapports historiques

Un écart de change constaté lors du règlement n’est pas la même chose que la réévaluation, en fin de période, d’un solde ouvert en devise étrangère. La réévaluation ajuste la valeur comptable en devise de l’entreprise des soldes ouverts concernés, tout en laissant inchangés leurs montants en devise étrangère. Demandez quels comptes et soldes sont concernés, quel taux et quelle date sont utilisés, et comment l’ajustement est extourné ou reporté dans votre processus.

Testez un solde ouvert en devise étrangère à deux dates de rapport. Après la réévaluation, comparez le montant en devise étrangère, la valeur comptable en devise de l’entreprise et l’enregistrement de transaction d’origine. Générez ensuite les rapports pour ces deux dates. Vous devez vérifier qu’une évaluation ultérieure ne réécrit pas discrètement la facture d’origine, le paiement ou l’enregistrement historique du taux.

La documentation d’ERPNext sur la réévaluation des taux de change décrit la réévaluation séparément des écarts réalisés liés aux paiements et explique l’utilisation d’une valeur comptable ultérieure et d’un taux de clôture. Considérez cela comme un exemple propre à ce produit et consultez la documentation et les paramètres comptables à jour de l’application retenue.

• Pouvez-vous repérer les soldes ouverts en devises étrangères qui doivent être réévalués ?
• Quelle date de taux est utilisée pour chaque ajustement de fin de période ?
• Les utilisateurs peuvent-ils distinguer la réévaluation non réalisée des écarts réalisés au règlement ?
• Les rapports historiques conservent-ils les montants et les taux applicables à leurs dates de référence ?
• Pouvez-vous relier un ajustement de réévaluation au solde et à l’écriture d’origine ?

Vérifier les imports, les exports, les intégrations et les traces d’audit

La gestion des devises doit fonctionner au-delà de la saisie manuelle. Testez les modèles de tableur, la validation des imports et les champs d’export que vous comptez utiliser. Incluez les codes de devise, les dates, les taux de change, les montants et les champs de compte ou de tiers concernés. Vérifiez comment le système traite les devises manquantes, les codes non valides, les lignes en double et les montants qui nécessitent une précision supérieure au format d’affichage.

Si une autre application envoie ou reçoit des enregistrements financiers, testez un échange complet à petite échelle plutôt que de supposer que des noms de champs identiques impliquent une sémantique identique. Vérifiez si l’intégration transfère, lorsque cela est nécessaire, le montant d’origine, la devise, le taux, la date du taux et le montant converti.

Vérifiez la piste d’audit pour les modifications des taux de change, des documents et des imputations. Pour les imports, examinez les avertissements et les journaux, ainsi que les enregistrements obtenus. La documentation d’ERPNext sur l’import de données décrit les modèles de tableur, les avertissements de validation, les journaux d’import et les exports de tables enfant ; vérifiez le comportement correspondant dans le produit retenu.

• Importez un petit fichier contenant des lignes de devise valides et volontairement non valides.
• Comparez les enregistrements importés au fichier source et examinez les messages de validation.
• Exportez les mêmes enregistrements et vérifiez si les champs de devise et de taux sont inclus.
• Testez une intégration représentative dans les deux sens, le cas échéant.
• Confirmez qui peut apporter des modifications et quelles traces de ces changements sont disponibles.

Établir une petite matrice de test avant de choisir

Une matrice concise permet des comparaisons plus fiables qu’une simple liste de fonctionnalités. Utilisez les mêmes scénarios, devises, dates et résultats attendus pour chaque application évaluée. Indiquez si chaque résultat est réussi, échoué ou non vérifié, et conservez des captures d’écran ou des sorties de rapport lorsque cela est utile.

Distinguez l’adéquation du processus de l’adéquation du déploiement. Établissez d’abord si l’application répond à vos besoins en matière de devises et de comptabilité. Évaluez ensuite son mode d’exploitation : qui contrôle les accès, les données, les sauvegardes, les mises à niveau et la reprise, et quelles responsabilités d’hébergement restent à la charge de votre équipe.

Pour un déploiement auto-hébergé, vérifiez la configuration de production et les exigences opérationnelles propres à l’application. Les recommandations de Docker pour Compose en production, par exemple, traitent de la configuration spécifique à la production ; c’est une question distincte de la façon dont un ERP calcule les montants en devises. Un déploiement géré peut prendre en charge une partie de l’infrastructure, mais ne vous dispense pas de vos responsabilités concernant les données, les accès et les choix de gouvernance.

Airbip propose un déploiement géré pour les applications de son catalogue public, dont ERPNext. Les capacités d’infrastructure annoncées comprennent des instances basées sur Docker, l’automatisation du routage et des certificats TLS, les vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Vérifiez les conditions en vigueur sur le site Airbip et déterminez si l’infrastructure gérée vous convient ; cela ne prouve pas qu’une application répond à vos exigences comptables.

• Scénario
• Résultat attendu
• Résultat observé et éléments de preuve
• Réussi, échoué ou non vérifié
• Question en suspens, responsable et prochaine étape
• Jeu de tests minimal : facture en devise étrangère, facture fournisseur, changement de taux, paiement partiel, avoir ou remboursement, réévaluation de fin de période et import/export.