Vous consultez une page technique concernant le logiciel de gestion Mercator. Celle-ci contient des informations spécifiques destinées aux professionnels de Mercator. Souhaitez-vous être redirigés vers des informations plus générales ?


   Ne plus poser cette question

Gestion commerciale Aruba - phase 2 : différences avec la version legacy

0000002254     -      24/12/2015

La gestion commerciale 8.3 présente notamment ces différences avec la version legacy :

  • Transferts de dépôts et inventaires (mouvements divers de stock)
    • Les transferts de dépôts et les inventaires sont à présent dotés d’un point de menu "Outils / Séquences Mouvements Divers". Cela permet de gérer la numérotation, les customizers, les modèles d’impression, les formules, les duplicatas PDF, les niveaux de masque, … ainsi que certains évènements (encodage référence, bouclage sur séquence, impression étiquettes, … ).Tant les inventaires que les transferts de dépôts se font à présent dans des écrans customizables. Dans la table SEQUENC, on reconnaît les mouvements divers avec module=7.
       
    • Une table PIEDS_D est ajoutée : elle contient les enregistrements des pieds de mouvements divers. (Cette table est ajoutée automatiquement, elle ne doit pas être migrée). Un enregistrement de PIEDS_D est automatiquement généré lors de l'ouverture (et la sauvegarde) d'un transfert de dépôt encodé au préalable avec la version legacy.
      attention Cette table n'existe pas en DBF. Son contenu ne peut donc être "démigré" ni sauvegardé vers pieds_d.dbf.
       
    • Les inventaires encodés en Aruba peuvent être réouverts pour être modifiés via le menu "Fenêtres / Historiques Inventaires". (on ne pourra pas réouvrir un inventaire encodé en legacy car la table LIGNES_D contient trop peu d’information). Une limite s’impose toutefois en ce qui concerne un inventaire contenant des numéros de série de niveau 3 : il ne peut être réouvert en modification. Il est donc conseillé d’inventorier les articles à n° de série à part.
       
    • Dans la fiche utilisateur, onglet "Profil", a été ajouté un point "Inventaires" permettant de bloquer la création et/ou la modification d’inventaires.
       
    • Le bouton "disquette" (sauver un inventaire dans un fichier plat sur disque) a été remplacé par un système de préparations d’inventaire. L’inventaire est, dans ce cas, bien stocké dans LIGNES_D mais avec Q=0, ainsi cela ne produit pas de mouvement de stock. Une préparation d’inventaire peut ensuite être transformée en "inventaire définitif" via le bouton de transformation habituel.

      invent_transform
      Le menu "Gestion / Inventaires" contient donc un point de menu permettant de commencer un inventaire définitif et un autre pour une préparation.

      menu_inventaire
       
    • Le processus habituel d’inventaire commence en général par une remise à zéro des quantités pour tous les articles. Etant donné que le framework .net travaille en mettant tout en mémoire RAM et qu’un fichier articles peut contenir un nombre très important d'enregistrements, Mercator met à disposition une procédure de remise à zéro qui s'exécute sans faire apparaître toutes les lignes à l’écran, donc exclusivement sur le serveur SQL. C’est l’objet du nouveau point de menu "Gestion / Inventaires / Remise à Zéro Rapide".
      attention Dans ce cas, les customizers sur inventaires ne seront pas exécutés et l’inventaire ne sera pas modifiable via l’interface (ce qui est logique puisqu’on ne veut pas afficher ce grand nombre de lignes).
       
    • Dans les inventaires, la notion de "date de référence" pour l’inventaire à date a été abandonnée. En Aruba, c’est la date de l’inventaire (PIEDS_D.DATE) qui est prise en compte, tant comme date de mouvement de stock, que comme date de référence. (Ces deux dates distinctes en legacy prêtaient à confusion)
       
    • Les inventaires et transferts de dépôts peuvent contenir des lignes de commentaire. (Pour assurer la compatibilité avec les reportings existants, ces lignes ne sont pas stockées dans LIGNES_D, mais sous forme d'une table XML placée dans le champ PIEDS_D.INVENT_ZERO)
       
    • Au niveau de la programmation, on retrouve très logiquement :
      • InventoryForm
      • InventoryEngine
      • TransferForm
      • TransferEngine
         
    • La gestion In/Out des numéros de série (niveau 3) est fondée sur des triggers sur la base de données SQL.
       
    • Dans les inventaires et transferts de dépôts, possibilité de créer une relation dans les lignes avec :
      • les projets : ID_PROJET C(10) à ajouter dans LIGNES_D
      • le 4ème signalétique : ID_DESTIN C(10) à ajouter dans LIGNES_D
         
    • Les groupes de colonnes "Projet" et "4ème signalétique" dans le LinesEditor sont prévus à cet effet.
       
  • Les rapports standards (et modifiables) du menu "Gestion" sont :
    • Caisse : CashState.repx
    • Tableau de bord : Dashboard.repx
    • Mouvements journaliers : DailyOperationsV.repx et DailyOperationsA.repx
    • Historique détaillé des encaissements : EncashmentsFull.repx
    • Historique condensé des encaissements : EncashmentsSummary.repx
    • Documents annulés : DeletedDocuments.repx
    • Réapprovisionnement : Restock.repx
       
    • Dans ces rapports standards, possibilité d'agir via le customizer Gescom. Par exemple : Filtrer les mouvements journaliers sur ventes en fonction du représentant
       
  • Dépôts en caisse et remises en banque :
    • En Majuro, le dernier numéro est stocké dans la table OPTIONS de la base de données SQL (En Aruba, dans params.dbf, comme en legacy)
    • Le rapport associé et modifiable : CashDepositBankRemitting.repx
       
  • Les regroupements automatiques (facturation de livraisons, livraison des commandes, commande des préparations, génération de la contremarque, génération des abonnements)
    • Ils ne sont plus effectués dans une "grande" transaction SQL unique, mais dans une transaction gérée par le billingEngine document par document. Cela améliore les performances et diminue la probabilité de conflits multi-utilisateurs.
       
    • Lors de la sélection des documents à transformer, Mercator effectue un contrôle préventif vérifiant si aucun document sélectionné n'est en cours de modification sur un autre poste. Cela évite les conflits multi-utilisateurs ultérieurs. Dans le cas de conflits, les lignes correspondant à ces documents apparaissent en rouge.
      multi_lock
    • Tous ces regroupements peuvent être lancés par code sans passer par la boîte de dialogue de sélection des critères. Les méthodes à utiliser se trouvent dans la classe statique MercatorUi.Forms.Gescom.GescomProcedures.Procedures. Elles portent le même nom que le point de menu correspondant dans l'interface de Mercator en anglais. Pour éviter la boîte de dialogue, il faut utiliser la signature de cette méthode avec le paramètre AskRet, qui va contenir les critères d'exécution.
       
    • Possibilité d'intervenir par customizer sur les boîtes de dialogue de sélection des paramètres de ces regroupements automatiques. Exemple : Dans la boîte de dialogue de la facturation automatique, cocher par défaut la case "Date sur toutes les lignes".
       
    • Tous ces regroupements sont effectués via le BillingEngine. Toutefois, les méthodes ApplyCustomerSupplier, ApplyCliLiv, InsertItem, ... ne sont pas utilisées puisque ces documents arrivent déjà avec un contenu formaté. Par contre, les méthodes UpdateAmounts et Save sont bien utilisées. Cela donne donc toute liberté pour utiliser dans des customizers les évènements liés à ces deux méthodes. Afin d'exécuter un code uniquement en regroupement automatique, ou a contrario, jamais dans le cadre d'un regroupement automatique, il faut utiliser :
      • la propriété Context du BillingEngine qui fait référence à une de ces valeurs : UserInterface, PrintPrev, Import, Other, FromAction, Restock, OrdersDelivery, DeliveriesInvoicing, PreparationsOrdering, SubscriptionsGeneration, SubscriptionsMaintenance, Countermark, GenerateCountermarks, ExchangeEmit, ExchangeReceive
      • ou la méthode IsContextAutomaticProcedure du BillingEngine, qui renvoie true dans le cas d'un regroupement automatique.
         
    • En facturation automatique : nouvelle case à cocher permettant de mettre la date de la livraison en début de désignation sur toutes les lignes.
       
    • Lors de la génération des contremarques : possibilité de fixer un montant minimum pour le total de la commande fournisseur, en deçà duquel la commande fournisseur ne sera pas générée.
       
    • En simulation de livraison de commandes clients :
      • Le rapport modifiable est OrdersDeliveryAutomaticV.repx
      • La procédure peut ne pas terminer par l'impression du rapport. Pour cela, il faut intercepter l'évènement statique SimulationDoneEventArgs de la classe statique MercatorUi.Forms.Gescom.GescomProcedures.Procedures. Cet évènement reçoit en paramètre un SimulationDoneEventArgs avec ces propriétés :
        • CancelPrint : à mettre à true pour ne pas imprimer le rapport
        • DialogChoices : une classe contenant les choix de la boîte de dialogue de départ
        • DsForReport : le DataSet conçu pour le rapport et contenant toutes le données de simulation (pieds, lignes, clients)
        • ParamsForReport : les paramètres passés au rapport
           
    • Les regroupements automatiques peuvent être exécutés par code C# en mode silencieux : voir par exemple Déclencher la facturation automatique sans boîte de dialogue
       
  • Outils / Remises : possibilité d'imprimer le tableau : Allowances.repx
     
  • Maintenance des abonnements :
    • possibilité d'effectuer la maintenance d'abonnements sélectionnés sur base d'une périodicité hebdomadaire
    • possibilité de prolonger les périodicités hebdomadaires
       
  • Version Majuro et comptabilités externes : voir cette page
     
  • Possibilité d'utiliser simulanément jusque 3 terminaux codes-barres portables différents (seulement en Majuro)