4 Juillet 2013

La CS de la Riveraine se questionne : Et nos applications maison? (2 de 2)

Par Denis Marcoux | Type Information | Produit Mozaïk-AX - Finances et Approvisionnement | Audience(s)
Gestionnaire
Service informatique
Utilisateur

Bon début de mois de Juillet à tous. Enfin, le calendrier m'indique que c'est Juillet, pas la météo. Ça ne peut que s'améliorer! Passons aux choses sérieuses.

Cette nouvelle a pour objectif de poursuivre la réflexion sur les applications maison et leurs moyens d'interaction avec Mozaïk. La première nouvelle à ce sujet se terminait avec ceci : "... l'interrogation des données de Mozaïk par des applications maison passe par l'invocation de services Web exposés par Mozaïk, que ces derniers aient été développés par la Société GRICS ou par une commission scolaire (CS)." C'est un résumé à haut niveau, mais qui donne précisément l'orientation.

Je vous rappelle que cette série de deux nouvelles peut intéresser tout le monde, mais s'adresse d'abord à un public averti. Technologiquement parlant, du moins.

Maintenant, qu'en est-il de la modification des données de Mozaïk par des applications maison? Je reviens sur un principe énoncé dans le contexte de l'interrogation des données : « Le serveur d'application Mozaïk est roi et maître de l'accès aux données.»  C'est vrai pour l'interrogation et encore plus important dans un contexte de modification des données. Pourquoi? Pour que les règles d'affaires (la validation) et la confidentialité soient appliquées de la même manière que si l'utilisateur créait ces données à travers l'interface utilisateur de Mozaïk.

Si je reviens à la démonstration que la CS de la Riveraine nous a faite, il y a deux types de données qui sont créées par leurs applications maison et qui doivent aboutir dans les BD des applications GRICS :

Imputations comptables

Une application de reprographie développée par la CS de la Riveraine crée aujourd'hui un fichier d'imputations comptables qui est importé dans DOFIN.

Des systèmes externes à Mozaïk qui génèrent des transactions à imputer au GL continueront toujours d'exister, même avec Mozaïk. Ces applications pourraient avoir été développées par la Société GRICS, par une CS ou par une tierce partie (partenaire de la GRICS ou fournisseur CS). Mozaïk doit permettre le traitement de ces informations. Ainsi, un traitement permettra de sélectionner un fichier d'imputations et de l'importer dans Mozaïk. Toutes les règles d'affaires seront appliquées et l'information ne sera créée que si elle les respecte. Naturellement, seules les personnes autorisées à importer des fichiers d'imputation auront accès à cette fonctionnalité. Le format de fichier sera modernisé pour laisser de côté le format à position fixe utilisé par DOFIN. Il y aura nécessairement des ajustements à faire dans les applications maison. Notre objectif sera de publier la spécification du fichier d'imputation Mozaïk aussitôt que possible. Les CS pourront ainsi préparer une nouvelle version de leurs applications maison qui devront survivre même après l'implantation de Mozaïk.

Maintenant, si nous tentions de mettre la barre un peu plus haute? Il faudrait aussi que Mozaïk publie un service Web qui permettrait de traiter une ou plusieurs transactions d'imputation. C'est-à-dire qu'une application externe à Mozaïk (CS ou GRICS) pourrait appeler Mozaïk directement au moment où la transaction de reprographie a lieu.  Les effets dans le système financier seraient appliqués en « quasi » temps réel. Une initiative est en cours dans Mozaik pour déterminer comment cette interaction se concrétisera. Nous en avons besoin nous-mêmes pour notre interface avec PAIE et GRH. Ce  moyen d'interaction plus sophistiqué implique des investissements plus importants dans l'application externe à Mozaïk, mais permet d'éliminer la gestion et le traitement des fichiers d'imputation.

Paiements sur pièces

Une application de frais de déplacement de la Riveraine crée un fichier de paiements sur pièces qui est importé dans PAIE et GRH pour rembourser l'employé. Une application de gestion de la formation à distance crée également un fichier de paiements sur pièces pour rémunérer l'enseignant qui corrige des épreuves. Il y a aussi un lien avec TOSCA dans cette dernière application, mais j'en ferai abstraction pour le moment.

Le traitement de paiements sur pièces créés par des applications externes à Mozaïk s'intègre entièrement aux façons de faire mentionnées pour les imputations : 

  • Traitement de fichiers de paiements dans un format Mozaïk.
  • Création d'un ou plusieurs paiements sur pièces en "quasi" temps réel par un appel à un service Web Mozaïk.

 

Frais de déplacement

J'ouvre une parenthèse fonctionnelle sur les frais de déplacement. Nous l'avons déjà indiqué : Mozaïk offrira une fonctionnalité de gestion des frais de déplacement avec processus d'approbation.  L'intégration avec le GL en fait partie. Quel est l'enjeu relié aux applications maison? Cette fonctionnalité offrira des mécanismes pour paramétrer les règles de la politique de remboursement des frais de déplacement de la CS.  Exemple : Taux par km, maximum pour les repas,etc. Il est utopique de penser que les règles qui seront paramétrées permettront de valider 100% de la politique de remboursement pour toutes les CS. La CS devra décider si elle utilise la fonctionnalité Mozaïk à son maximum et valide par un humain certaines règles qui ne peuvent pas être paramétrées. Elle élimine par cette décision le besoin d'entretenir une application maison de gestion des frais de déplacement. La CS peut aussi décider de maintenir son investissement dans une application maison afin d'avoir une validation automatisée de 100% des règles de sa politique de remboursement. Deux options s'offrent à elle : La première est plus claire à ce jour : Avoir une application externe à Mozaïk qui applique toutes les règles de la politique et interagit avec Mozaïk (fichier ou services Web) pour créer les paiements sur pièces. La deuxième sera à préciser dans le futur et consiste au développement, par la CS, de la validation des règles d'affaires de la politique à l'intérieur même de Mozaïk.

 

En conclusion, si une CS décide de maintenir ou de développer une application maison parce qu'elle juge cet investissement justifié, cette application devra soit générer un fichier selon un format prévu pour importation dans Mozaïk ou elle devra invoquer un service Web qui a pour objectif de créer certaines données.

L'écriture de cette nouvelle impose par elle-même le sujet de la prochaine : Mais si la porte d'entrée pour créer la donnée X n'a pas été prévue dans Mozaïk? Ou sous une autre lumière : Requêtes SQL de modification de données par les clientsVoilà un sujet délicat s'il en est un. Nous en reparlerons sous peu.

Je vous souhaite un bel été....Ayons la foi!

 

Denis Marcoux