La manière coûteuse de modifier un taux d’imposition
Un ministre des finances annonce une modification de la TVA. Dans un locataire Dynamics 365 bien conçu, c’est un code fiscal daté, une période de règlement et un test de publication. Dans un projet mal conçu, c’est un projet : trouver le X++ qui a codé en dur 16 %, l’AL qui a pris un groupe fiscal, le rapport qui a multiplié le montant de la ligne par une constante, et l’intégration qui a envoyé une chaîne d’imposition qu’une banque n’accepte plus.
Nous avons hérité de programmes où un changement statutaire signifiait six semaines de développement. Ce n’est pas un problème fiscal. C’est un problème d’architecture. Si votre prochain changement de tarif nécessite un développeur, le dernier partenaire vous a créé une application personnalisée qui repose sur Dynamics 365.
La taxe appartient à la configuration, pas au code
Dynamics 365 a déjà les objets suivants : codes fiscaux, groupes fiscaux, groupes d’impôt sur les articles, retenue à la source, exemption, frais inversés, périodes fiscales, et, à Finance & Operations, service de calcul fiscal et Déclaration électronique. Le rôle d’un déploiement mondial est de les utiliser. La personnalisation concerne l’écart que le produit n’exprime pas, et elle suit un atelier plutôt que de le remplacer.
Sur chaque programme, nous avons une règle : si un avocat ou une autorité fiscale peut changer le numéro, il doit rester dans une configuration datée. Les promoteurs ne possèdent pas les taux d’imposition. La finance en possède, avec une piste d’approbation.
Une machine fiscale, beaucoup de livres
Une entité kényane, une entité sud-africaine et une entité allemande n’ont pas besoin de trois plans fiscaux. Ils ont besoin d’un seul modèle fiscal avec des codes spécifiques à chaque pays, des dates et des mises en page de déclaration. Le graphique, les dimensions et les profils de publication restent partagés. Ce qui change à la frontière, c’est la couche légale : TVA, GST ou retenue, le format de la déclaration, l’appel de facturation électronique.
C’est ainsi qu’un groupe effectue un changement de taux à Nairobi sans rouvrir le modèle allemand. Software Dynamics publie eTIMS annonce interne pour le Kenya et la paie pour KE, NG et ZA pour la même raison : la partie statutaire est un produit configuré, pas un cas unique. Votre prochain pays devrait suivre le même schéma.
Ce que nous refusons de personnaliser
Nous ne coderons pas en dur un taux, un seuil ou une ligne de retour en X++ ou AL. Nous ne calculerons pas la taxe dans un fichier Excel qui publie un journal. Nous ne laisserons pas une intégration contourner le moteur fiscal pour qu’un marketplace ou un POS puisse « simplement envoyer le net ». Ces décisions semblent rapides au deuxième mois et deviennent un programme la deuxième année, quand l’autorité change la règle et que personne ne se souvient de quelle interface a pris l’ancienne.
Comment un déploiement Software Dynamics est conçu pour absorber le changement
Discover nomme chaque impôt que le groupe dépose réellement, pas ceux sur une diapositive. Design place chacun d’eux sur un code daté avec un propriétaire. Deploy teste un changement de taux dans le bac à sable comme critère de mise en service : les changements financiers de 16 % à 18 % sans nous, et c’est le test de mise en ligne. Le support est une mise à jour de configuration, pas une demande de modification du code.
Si vous choisissez un partenaire pour un programme de Dynamics 365 multi-pays, demandez-lui de vous montrer la dernière modification statutaire qu’il a livrée en configuration. Si la réponse est une estimation de développement, continuez à chercher. Si vous souhaitez un design qui survivra au prochain discours budgétaire, contactez-nous.