Blog éclectique & sans sujet précis

Nous avons vu le genre de céphalée que peut représenter une simple commande quand on a plusieurs intermédiaires et prestataires impliqués.

Avec un peu d’aspirine, tous ces concepts finissent modélisés sous forme de tables informatiques dans une grosse base de données SQL. Les ERP fournissent d’ailleurs la solution clés en main, dont la compréhension est à peu près aussi longue et pénible que tout recréer soi-même (au moins est-ce débogué).

Il faut ensuite se poser la question de remplir les données. Si on agit au fil de l’eau (l’administration des ventes ou un télévendeur remplit tout sur le champ), on court le risque de voir des doublons dans son fichier client. Dans certaines branches on a le luxe de recevoir une liste de ses clients finaux, soigneusement numérotés, avec leurs adresses, de la part du donneur d’ordres ou d’un intermédiaire financier ou technique.

L’erreur est de croire que l’on peut intégrer aveuglément cette liste extérieure dans sa base de clients. Les adresses notamment doivent éveiller la plus grande méfiance^[1].

Si la liste est propre, elle comprendra deux ou trois champs d’adresse séparés des codes postaux et des noms de ville.
Si elle ne l’est pas (par exemple si elle provient d’une certaine multinationale que je ne citerai pas^[2]), il faudra quasiment développer une intelligence artificielle capable de différencier un code postal d’un code TVA dans le magma informe que ces champs d’adresse seront devenus. Il est en général plus efficace de laisser une secrétaire revoir manuellement ces adresses.
S’il y en a dix mille, couvrant cinquante pays dans le monde, la tâche devient « intéressante » dans le sens démoniaque du terme.
Il existe des logiciels interfacés avec les bases de données de la Poste et de ses équivalents étrangers, pour reformater automatiquement ces adresses. J’ignore leur prix, il doit être aussi indécent que leur utilité est grande.

Pour corser la chose, cette liste ne comprend pas uniquement les clients mais aussi leurs premières commandes^[3], et de gros problèmes de conversion de jeux de caractères entre l’Excel en Unicode et l’Oracle en Latin-9^[4].

Reprenons notre commande. Elle peut se réduire à une ligne d’un article avec une quantité, un prix. Que ce soit 1 ampoule à 0,5 € ou 200 palettes de téléphones portables à 1000 € pièce, la complexité informatique est la même. Elle peut donc sembler simple à gérer au premier abord. Mais beaucoup de choses peuvent se dérouler par derrière :

• Certains systèmes (SAP notamment) rajoutent une notion d’échéances en dessous de la notion de ligne de commande. Il peut y en avoir beaucoup quand il s’agit de livraisons étalées sur des mois. La commande doit donc être partiellement livrée et payée avant même d’être totalement renseignée.
  On notera au passage qu’il n’y a absolument pas de rapport de un-pour-un entre commande et livraison, ni entre commande et facture (on est déjà content si ce rapport existe au niveau de la ligne ou de l’échéance).
  

• Un conteneur peut être consigné et ajouté automatiquement (à la commande d’une caisse de bières par exemple), et ce même conteneur être récupéré à la livraison suivante, pour donner lieu à une déconsigne qui, subtilité, n’apparaîtra pas forcément sur la commande mais uniquement sur la facture.
  Le terme facture est lui-même trompeur, car un livreur n’arrive qu’avec un borderau de livraison (ou facture pro forma) et la vraie facture comptable, comprenant les déconsignes, et faisant foi auprès de l’administration, n’est jamais imprimée.
  Subtilité : le numéro de cette facture n’existe pas au moment où le client reçoit la pro forma, ce qui pose d’intéressants problèmes de rapprochements si le client paye dès la réception...
  

• L’unité à prendre en compte peut être l’unité (objets manufacturés), une unité de volume classique (le litre), ou qui dépend d’une autre et qui dépend de l’article (dans la distribution de boissons, un col peut faire 0,30 comme 1,75 litre, une caisse peut faire 12 cols, etc.).
  

• La mise en place du calcul du prix est un poème ; certains consultants y consacrent leur vie : prix de base (dans quelle unité ?), remise sur quantité, remise positive (qui permet d’afficher des prix artificiellement bas), frais de transports, frais de facturation, marges arrières plus ou moins claires, attribution gratuite d’articles en plus ou au sein de la quantité commandé... tout ceci variant dans le temps, l’espace, la sous-société qui reçoit la commande, la tête du client final et sa capacité de négociation, les habitudes de tel ou tel commercial et les traditions des différents services.
  

• Il est rare qu’il y ait de vente sans commercial. Celui-ci exigera peut-être sa part, et le système stockera quelque part la commission qu’il doit toucher. Lui aussi doit être payé.
  

• De même, le prix annoncé au client n’est pas forcément celui qui sera payé au fournisseur si un intermédiaire quelconque prélève sa commission (grande centrale, groupement, ou simplement affacturage).
  

• Murphy oblige, la fonctionnalité critique du cœur de métier du client, qui ne se rencontre nulle part ailleurs, n’est pas prévue dans le logiciel. Ou alors elle possède une limitation majeure (à première vue arbitraire et débile mais liée à l’historique de développement de l’ERP).
  C’est là qu’intervient la SSII, qui bénit le client pour ses excentricités, et maudit l’éditeur pour la difficulté d’adaptation (quoiqu’il faille distinguer entre le développeur qui s’arrache les cheveux et le commercial qui s’en moque, il a fait son boulot de décrocheur de contrat).