Client

Une start-up du Royaume-Uni a utilisé les services d'Elinext pour développer un logiciel d'affacturage web et mobile pour aider les fournisseurs et acheteurs à éviter des délais dans la livraison de la marchandise.

Défi

Trop souvent, les fournisseurs ne sont pas payés en avance ou même juste après avoir livré la marchandise à leurs acheteurs. En fait, le paiement est généralement retardé jusqu'à trois mois en raison de toute la bureaucratie. Cela perturbe l'influx de liquidités du fournisseur.

De nombreuses banques proposent des services pour régler ce problème. Ce qu'elles font est qu'elles achètent la dette du vendeur en payant le fournisseur pour la marchandise. Mais dès qu'une banque entre en jeu, il y a beaucoup de bureaucratie et de délais. Une start-up britannique a donc conçu une solution alternative.

L'idée des fondateurs était de créer un système d'affacturage qui imiterait les services fournis par les banques de façon simplifiée et numérique. Pour donner vie à cette idée, la start-up s'est associée à un développeur web en 2020 et ils ont collaboré pendant presque un an. Mais ce développeur n'a pas su répondre à la demande du client et l'entreprise a donc cherché à le remplacer.

La start-up a finalement fait la rencontre d'Elinext. Nous avons rapidement répondu et fourni le CV de notre programmeur de façon proactive, ce qui a décidé le client à nous choisir.

Processus

Le directeur technique de la start-up n'était pas favorable aux structures de développement formelles, que ce soit les réunions Scrum ou autres pratiques Agiles auxquelles nous étions habitués. Mais ce n'était pas un problème pour notre équipe: nous nous sommes adaptés à leur approche et à leur rythme et le client nous a fait confiance pour que nous faisions notre travail sans supervision constante.

Pour suivre nos progrès, nous avons utilisé des tickets et stories dans Microsoft Azure. Nous appelions aussi le client quotidiennement ou discutions sur le chat Slack.

Au départ, nous avions un développeur et analyste commercial; ensuite, nos développeurs ont remplacé les autres membres de leur équipe originale et le DevOps a rejoint l'équipe peu de temps après.

Le travail s'est généralement déroulé sans accrocs et le seul défi auquel nous avons dû faire face était l'illettrisme de certains fournisseurs. Dans certains pays, connus comme le centre de production mondial, les utilisateurs avaient du mal à remplir les modèles de factures. Nous avons donc simplifié l'interface utilisateur et l'expérience client (UI/UX) autant que possible pour que tout le monde puisse utiliser le système.

Produit

Nous avons construit l'application à l'aide d'une architecture basée sur les microservices. L'application réussit ainsi à simplifier la procédure et à réduire les délais de paiement par un tierce plus que par les services offerts par les banques. Voici comment ça marche.

Un fournisseur télécharge une facture dans le système et se fait payer par notre client, qui va ensuite facturer l'acheteur du fournisseur. Ainsi, le fournisseur obtient l'argent rapidement après avoir livré la marchandise, tandis que l'acheteur peut prendre plus de temps à la payer, mais au lieu de payer le fournisseur, il va payer notre client.

Examinons les modules clés de l'application.

Shipment Wizard (Wizard d'expédition)

Le module principal avec lequel travaillent les deux parties est le Shipment Wizard. Voici comment il fonctionne.

Tout commence lorsque le fournisseur s'est mis d'accord avec l'acheteur pour que le paiement passe par le système de notre client. À partir de là, le fournisseur crée une transaction respective dans le système en y attachant la facture, qui sera ensuite traitée par notre client.

Une fois que notre client en a vérifié les détails et approuvé la transaction, l'acheteur la voit dans la liste en attente d'approbation sur son tableau de bord. C'est maintenant son tour de vérifier la transaction. Si tout est correct, il peut cliquer sur le bouton «Approuver» et, si nécessaire, télécharger un document d'approbation avec une signature électronique. L'ajout d'un document signé de type IPU/IPA lors de la création de la transaction est obligatoire, tandis que les documents optionnels n'ont pas besoin d'être signés.

Globalement, la transaction passe par plusieurs changements de statuts au long de son cycle de vie, jusqu'à ce qu'elle soit «Payée» et, finalement «Complétée». Ces deux statuts seront assignés manuellement par notre client après que les deux autres parties ont approuvé la finalisation.

Reconnaissance de Texte Automatique

Nous avons simplifié la saisie de données des factures dans le système en utilisant l'outil de reconnaissance de texte par intelligence artificielle Conpend. Une fois que vous avez téléchargé une facture au format PDF, l'outil extrait le texte du fichier et le place dans les champs correspondants. Si l'algorithme ne parvient pas à reconnaître du texte et à l'associer aux champs appropriés, vous pouvez toujours ajouter les éléments manquants manuellement.

Back Office

Le Back Office est attribué exclusivement à notre client dans le système. Une fois qu'une transaction a été soumise, l'opérateur situé dans le pays du fournisseur la voit dans la liste des transactions en attente d'approbation. C'est là qu'il peut vérifier les détails de la transaction en consultant la facture originale au format PDF et les champs qui contiennent les informations de ce fichier.

L'opérateur peut alors corriger toute erreur, vérifier à nouveau avec les deux parties et, après avoir obtenu leur accord écrit, approuver numériquement la transaction dans le système.

Résultats

Cela nous a pris un peu moins d'un an pour construire cette application basée sur les microservices. Ce produit est désormais utilisé par certains des plus grands revendeurs de mode en ligne et par d'autres sociétés de revente à l'international. À ce jour, environ dix personnes œuvrent sur ce projet. Nous travaillons aussi sur une autre partie de l'écosystème de ce client: une plateforme consacrée aux critères environnementaux, sociaux et de gouvernance (ESG).