Paramétrage des dossiers mobiles

Owned by Khouloud Achouri (Unlicensed)
Last updated: 08/02/2022 by Bertrand Littel
6 min read

Remarques générales

Chemins


Dans chaque dossier mobile, il est possible de paramétrer plusieurs chemins pointant sur des répertoires ou des chemins.
Les chemins du dossier mobile commun devront être créés avec le dossier commun en ligne. Ainsi, il est conseillé de créer, en une fois, tous les chemins dans le dossier commun ; ils seront alors accessibles depuis tous les dossiers.
De plus, il est conseillé de créer des fichiers et répertoires Windows car le programme lit et écrit dans des fichiers plats et communique avec des éléments externes.


Dossiers


Le paramétrage de la synchronisation se fait par un zoom dont l’appel est situé dans le menu du module ‘Administration’.



Dossier commun

 

Généralités


Le code société est lié au dossier.
Le dossier commun doit obligatoirement être présent et actif (case à cocher (1)) pour effectuer une synchronisation. C'est pourquoi la case sera toujours cochée et non modifiable pour ce dossier.
La case à cocher (2) permet d'inhiber la gestion de la table des utilisateurs mobiles : le code utilisateur mobile sera alors le code du commercial,
lors d'une synchronisation mobile vers infinity, lorsque nous aurons besoin d'un code utilisateur ERP, nous prendrons celui précisé dans le champ collaborateur de la fiche commerciale.


Infinity -> Mobile





Le dossier commun permettra de définir :
le chemin d'extraction des fichiers *.txt,
les chemins des batch de pré et post traitement,
le type de synchronisation infinity vers mobile par défaut (1) : Totale (FULL) ou Différentielle (DELTA),
le nom d'un module externe (2) (xxx.dhop).

Le nom du module externe permet de bénéficier d'ouvertures supplémentaires dans le module saisi:

  1. Traitement_Initialisation : située avant l'entrée en saisie du masque de sélection,

  2. Traitement_DebutSociete : avant traitement d'un dossier,

  3. Traitement_FinSociete : après traitement d'un dossier,

  4. Traitement_AvantBatchFin : avant le traitement du batch de fin.






Mobile -> Infinity


Le dossier commun permettra de définir les chemins par défaut, des batch de pré et post traitement ; en effet, si on n'en précise aucun dans les autres dossiers, ceux-ci seront pris par défaut.

Autre(s) dossier(s) / société(s)



Généralités




Pour les dossiers (hors commun), la case à cocher (1) permettra de définir si on prend ce dossier en compte dans la synchronisation.


Infinity -> Mobile


Pour les dossiers, différents du dossier commun, on pourra définir pour chacun d'eux :
le chemin d'extraction des fichiers liés à l'article (fichiers joints, images),
les différents périmètres d'extraction des pièces et événements. Pour les événements, on pourra également préciser d'extraire au moins X éléments,
si on veut exporter uniquement les articles autorisés en saisie de pièce ou tous les articles,
le seuil d'évolution de CA qui permettra de calculer la tendance du CA de l'année N par rapport à l'année N-1,
paramétrage des pièces (devis, commande, BL, facture) :
« Calculer les quantités d'origine sur les lignes » : permet de calculer les quantités d'origine d'une ligne en cas de validation partielle,
« Calculer montant dû sur factures » : permet de calculer le montant restant dû d'une facture en cas de paiement (partiel ou en totalité – si présence du module Règlement).
le paramétrage des familles statistiques : sélection d'une famille et niveau de découpage du dossier pour représenter les grandes familles, familles et sous-familles.



Mobile -> Infinity


Pour les dossiers, différents du commun, on pourra définir pour chacun d'eux :
le chemin des fichiers *.txt à intégrer dans infinity, les batch de pré et posttraitement,
le répertoire des fichiers joints issus du front ; par défaut, il devra s'appeler FileUpload et se situer au même niveau que le répertoire \Export : par exemple, D:\Mobile\EchangeErp\998\FileUpload.
les états à positionner lors d'une création de devis/commande,
si on supprime réellement un événement ou si on le passe à l'état "Annulé".



Concernant l'état des pièces lors d'une intégration, il faudra absolument mettre sur Actif, si des livraisons sont faites à la suite. En effet, lors d'une validation de commande en BL par exemple, il faudra que la commande soit active pour qu'elle puisse être validée.


Gestion des utilisateurs mobiles


Le paramétrage utilisateur s'effectue par le biais de plusieurs tables et accessibles au menu Administration depuis Mobilité → Utilisateurs :



Profil




Les profils correspondent à des profils de paramétrage existants dans infinity for mobile. En standard, cette table est renseignée avec les profils standards et connus côté front :
VE : commercial (par défaut, dans le standard), TE : technicien,
TC : technico-commercial.

Chaque ajout dans cette table d'une entité autre que ces 3 éléments devra être suivi d'un paramétrage d'un nouveau profil côté front pour pouvoir être pris en compte par l'application mobile.


Utilisateur mobile




Cette table permet de lister tous les utilisateurs mobiles desquels on synchronisera les données dans la base mobile.
Elle est constituée de :
un code utilisateur mobile,
un nom et prénom (qui sera transféré dans la table des user de la base mobile) : il est saisissable,
s'il est laissé vide, il sera renseigné par le nom de l'utilisateur ERP à sa sélection,
un code utilisateur ERP (obligatoire),
un profil (obligatoire) : voir description au chapitre précédent,
un code dépôt : lors d'une création de document sur le front, ce code dépôt sera pris par défaut.
Le lien entre l'utilisateur mobile et les commerciaux est implicite, par le champ collaborateur de la fiche du commercial.
Lors d'une synchronisation infinity vers mobile :
le programme parcourra tous les liens commerciaux/utilisateur ERP pour extraire les données commerciales.
si le profil d'un utilisateur n'est pas renseigné, le profil VE sera utilisé par défaut.
Lors d'une synchronisation mobile vers infinity, une limitation existe dans le fait que le programme prendra le premier commercial trouvé lié à l'utilisateur ERP – et par extension, l'utilisateur mobile.



Groupe d'utilisateurs




Pour pallier l'impossibilité de modéliser une hiérarchie des utilisateurs, on a créé une table des
groupes d'utilisateurs mobiles. Elle nous permet :
de lui attribuer un code et un libellé (ces données ne seront pour l'instant pas transférer dans la base mobile, elles ne servent qu'à modéliser la hiérarchie),
un code responsable :
c'est un utilisateur mobile,
il héritera de toutes les données des membres de son groupe sans pour autant que son utilisateur ERP ne soit lié à un commercial.
il pourra avoir ses données commerciales propres si un commercial est lié à son utilisateur ERP.
un clic sur le bouton permettra de définir les éléments du groupe.




Membre de groupe


Un groupe peut être composé :
d'utilisateurs mobiles : ici, GRO-OUES, de groupes : ici, EST.



Références circulaires entre groupes


Il faudra faire attention aux références circulaires, les groupes ne doivent pas être constitués d'eux- mêmes. Une sécurité au sein du programme de synchronisation a été mise en place pour ne pas dépasser une certaine profondeur, mais cela ne dispense pas de créer son arborescence avec logique.
Exemple :
soit 3 groupes GROUPE1, GROUPE2, GROUPE3
GROUPE1 est constitué de GROUPE2 et GROUPE3. GROUPE3 est constitué de GROUPE1. GROUPE1 est donc constitué de GROUPE2 et GROUPE1, donc de GROUPE2, GROUPE2, GROUPE1, etc…



Scénarii non infinity, issus de l'application mobile


Certains scénarii ne sont pas définis dans l'ERP car spécifiques à l'application mobile et dont la structure n'est pas reproductibles dans l'ERP.
On a décidé d'intégrer ces scénarii de la façon suivante :
création d'un événement pour chaque réponse donnée,
le libellé de l'événement sera constitué du titre du scénario,
le corps du message de l'événement sera constitué des triplets suivants : questions, réponses et commentaires.
Pour effectuer ce traitement, on a besoin de connaître : les types de scénario existant dans la base mobile,
une correspondance entre ces types et les codes événements de l'ERP.

Type de scénario mobile


Pour intégrer les scénarii propres à la base mobile, il faut impérativement que les types de scénario soient renseignés dans cette table, et même que le type et le code type scénario soient identiques à ceux de la base mobile.
On peut préciser :

  • un libellé,

  • une syntaxe du critère attendue : en effet, le champ MOBYScenario.Critere contiendra le code tiers auquel se rattache le scénario.

Dans l'exemple ci-dessus, on attend pour ce scénario un critère de la forme [CUST]CUSTOM ; cela signifie qu'on attend un code client suivi par la chaîne 'CUSTOM'. Par exemple, si on reçoit le critère C0000001CUSTOM{}, on saura qu'on a affaire au client NEBOUT pour la visite guidée Papyrus.


Correspondance type – code événement




Les correspondances type scénario – code événement permettent de pouvoir créer un événement de type prédéfini.

La liste des correspondances est limitée aux types de scénario définie dans le chapitre précédent :