ABC est conçu pour minimiser l'effort requis par la gestion commerciale des PMEs. L'administration d'entreprise est évidemment indispensable. Sans cela, l'entreprise risque certainement d'échouer rapidement. Cependant, celle-ci coûte cher en temps et en énergie. Notamment, pour qui veut savoir précisément comment il vit, quels sont les en-cours, etc, mais dont le hobby n'est pas de produire du papier administratif.

Certes, l'entreprise doit faire ses factures, c'est le moins pénible, mais aussi ses commandes, publier ses listes de prix, faire ses payements gérer ses stocks. Ceci sont les documents essentiels. Il y en a bien d'autres. Leur nombre et leur forme dépendent du type d'activité. Soit, il faut bien les faire, les contrôler car une erreur peut coûter cher. De plus, il faut consigner dans la comptabilité les mouvements financiers qui y correspondent. Mais ensuite, il faut faire le suivi des débiteurs et des créances. Il faut trop souvent faire le bilan TVA.

Or, d'une part, beaucoup de documents sont liés, soit totalement soit partiellement. D'autre part presque toutes les écritures comptables sont la conséquence automatique d'un document commercial. Par exemple, une facture d'un fournisseur est, si tout se passe normalement, la version fournisseur d'un bon de commande. Certes, au passage, on peut entériner une remise exceptionnelle. Certes, cette facture il faut la payer mais pas trop tôt. Donc, ipso-facto cette facture devient une créance qu'il faudra payer à terme. Malheureusement, il ne faudra pas oublier cette échéance et faire alors un ordre de payement. Que d'opérations!

L'objectif numéro un d' ABC est de réduire tous ces travaux aux seules prises de décisions. La première prise de décision pourrait être de décider de commander à un certain fournisseur et de fixer les volumes. Le bon de commande est donc défini par l'utilisateur. La seconde étape est la réception de la facture du fournisseur. L'utilisateur doit l'approuver. Avec ABC on réalise cela en créant automatiquement l'équivalent de la facture du fournisseur à partir du bon de commande auquel il doit nécessairement se référer pour pouvoir prendre ses décisions en toute connaissance de cause. L'utilisateur pourra éventuellement fixer le délai de payement. C'est tout! La prise en compte de la créance sera automatique au niveau de la comptabilité (et le bilan mis à jour). La ventilation analytique sera également faite. Mais, ensuite, le document de payement sera automatiquement produit au bout du délai spécifié et soit imprimé soit transmis par voie électronique . Lorsque le payement sera déclenché, la décharge du compte créancier sera réalisée automatiquement au détriment du compte de liquidité utilisé pour ce faire. En résumé, il reste deux actions à charge de l'utilisateur: commander et approuver. Peut-on descendre en dessous?

Le second objectif est de minimiser les erreurs. Pour atteindre cet objectif, ABC minimise le nombre de saisie au clavier. L'essentiel des manipulations s'effectuent par tirer-lâcher. Ainsi, pour réaliser une facture pour un client, il suffit d'ouvrir l'éditeur pour ce modèle de document et de lâcher une adresse dans le trou ou le champ du destinataire. De même pour les produits fournis. Evidemment, il faudra indiquer la quantité fournie. La facture est prête. Plus court encore. Deux clients doivent recevoir la même facture. La première est réalisée comme nous venons de la décrire. Pour le second, on lâchera simplement l'adresse d'une part et d'autre part on lâchera la première facture dans le trou modèle. Le système complétera le document. Ici, une seule erreur est possible: mal fixer la quantité fournie. Peut-on descendre en dessous?

Le troisième objectif est la flexibilité. En conséquence, évidemment, le systèmes est polyglotte, il accepte plusieurs formateurs (traitement) de texte pour l'édition des forme papier ou autre des documents et des personnalisation individuelles et collectives. Mais, au-delà, tout les modèles de document et leur comportement sont définis en fonction du mode de fonctionnement de l'entreprise. ABC est caméléon. Dans la même optique, les collections, telles que les comptes terminaux, produits, adresses, peuvent être partitionnées de multiple façons. Elles peuvent ainsi être abordées selon divers points de vue. Par exemple, le comptable peut avoir un point de vue sur l'ensemble des adresses et le vendeur un autre. Le premier créera une hiérarchie selon une logique de solvabilité. Le vendeur verra des groupes de clients avec diverses potentialités. Une autre hiérarchie pourra être des classes de tarifications. La balance TVA n'est rien d'autre qu'une vue réduite sur l'ensemble des comptes focalisée sur les seules comptes concernés.

Enfin, ABC à une notion de projet et une notion dossier partenaire. Tous les documents d'un projet peuvent être automatiquement regrouper dans un dossier permettant une conduite et une évaluation des performances aisée. Les dossier partenaire permet d'évaluer et de contrôler la relation que l'on a aussi bien avec un client qu'un fournisseur. Le dossier client est l'outil de base pour les professions libérales. La notion de tuteur permet de découpler le sujet du payeur. Ceci permet donne une réponse confortable au pratique usuel dans des domaines tel que le médical, où le praticien opère sur un patient mais facture à une institution.

· Gérer tout document imaginable utile pour les fonctions commerciales ou de fabrication.

· Produire automatiquement toutes les écritures comptables sur base des événements affectant les documents.

Le produit est fourni sous forme d'une archive (zip ou tar.gz) ou d'un CDRom. Si vous partez d'une archive, il faut créer un répertoire temporaire d'installation puis se positionner dans celui-ci et extraire les fichiers hors de l'archive.

Lisez ensuite le README. Ce texte donne les instructions précises à suivre en fonction de la version et de la plate-forme. Si vous faites une mise à jour, il faut impérativement faire une sauvegarde tant des données que de l'ancienne distribution!

Pour une nouvelle installation, le système offre automatiquement une période d'essai libre. Des exemples de documents sont fournis avec le produit. Ils peuvent être copiés dans l'espace des données en lieu et place de vos données. Ceci permet un premier contact avec le système avant de le définir à votre main. En effet, ABC permet une adaptation poussée mais, cette adaptation n'est vraiment possible que pour autant que l'on ait saisi le fonctionnement. Notamment, la définitions des modèles de documents et de leurs comportements n'est pas triviale. Il est donc judicieux d'utiliser ceux proposés, de les modifier pour comprendre les mécanismes avant de se lancer dans la définition des documents d'exploitation. Le kit d'installation propose plusieurs modèles prédéfinis. Il est possible d'en installer plusieurs successivement ou simultanément. En installant deux modèles très différents tels que `vente' et `association' on peut très vite apercevoir à quel point ABC est adaptable à une activité quelconque. La seule condition étant de pouvoir formuler ses propres règles.

Il est judicieux de créer un répertoire spécifique pour recevoir le produit. De plus si vous voulez installer plusieurs versions, créez un sous répertoire pour chaque version. Ainsi, vous pourrez supprimer toute les versions inutiles en supprimant simplement les répertoires superflus. ABC ne copie rien en dehors des deux répertoires qu'il réclame durant la procédure d'installation. C'est répertoires sont par défaut des sous répertoires du répertoire de travail pour Linux et de C:\abc pour Windows.

Le système est prêt pour une phase d'apprentissage. Une fois celui-ci terminé, vous pourrez faire la mise en service définitive. Référez vous à la procédure décrite à cette effet sous le titre `mise en service'.

L'interface graphique est largement inspirée sur la métaphore du tirer-lâcher. Cette métaphore suggère l'idée qu'un objet est tiré depuis une source quelconque et que l'on transmet cet objet à un destinataire. Puis généralement, la source ne donne pas vraiment cet objet mais seulement un accès, une référence. Quand le destinataire à reçu et accepté cet objet, il peut agir dessus. Le destinataire est donc généralement un outil capable d'agir correctement sur le type d'objet reçu.

Graphiquement, ce mécanisme est mis en évidence par un curseur qui prend une forme symbolisant l'objet attaché. Un fil lie ce curseur à la source d'origine (ceci montre bien que la source reste liée). Les récepteurs typiques sont des boutons dont la forme suggère leur aptitude à recevoir l'objet transporté. Le mécanisme se déclenche en pressant puis en lâchant le bouton droit de la souris sur une source. L'objet est alors tiré. En pressant à nouveau sur ce même bouton de souris, on lâche l'objet. Si cela se fait sur un récepteur acceptant ce type d'objet, la transmission est terminée avec succès, sinon l'objet tombe à l'eau et rien ne se passe.

Ce mécanisme, quoi que encore peu usuel permet des interfaces compactes et puissantes. En effet, il n'est pas nécessaire de prévoir des mécanismes qui pour chaque source permettent d'atteindre chaque destinataire. De ce fait on évite l'explosion combinatoire de l'interface.

Nous supposons ici que le système est chargé de toutes les données utiles. Ceci est le cas si vous utilisez les exemples fournis, ou si vous avez déjà importé des données et défini le comportement spécifique. Ces parties sont expliquées au chapitre de la maintenance.

Toutes les fenêtres ont dans le coin supérieur droit un bouton de fermeture. Le panneau principal n'échappe pas à cette règle. Cependant, celui-ci demande une confirmation avant de quitter réellement l'application. Dans tous les autres cas, la fenêtre correspondante disparaît et oublie d'éventuelles modifications faites. Ceci évite de fastidieuses opérations de confirmation. Certes une sortie non appropriée fait perdre quelques opérations. Mais vu que le volume de travail pouvant être perdu est très minime, cela justifie le choix fait.

A gauche du bouton de fermeture, le bouton d'aide donne accès à un texte d'aide correspondant a la fenêtre. Ceci est vrai pour toutes les fenêtres.

Selon le travail que l'on fait le plus couramment ou celui que l'on doit interrompre, il est intéressant de mémoriser une configuration, de travail. Ceci se fait simplement en pressant le bouton de configuration (8) au bas du panneau principal. Toutes les fenêtres ouvertes seront remises en place dans la même disposition lors du prochain démarrage de l'application. Les deux boutons de restants sont réservés à la maintenance.

Le bouton de traduction (9) permet de modifier les textes associés aux éléments graphiques de l'interface utilisateur.

Le bouton de maintenance (11) permet d'accéder à des fonctions d'une part par moins usuelles mais aussi réservées aux personnes ayant un statut privilégié. Ce bouton est absent pour les personnes non autorisées.

Le bouton des préférences (10) permet de modifier les préférences personnelles. Parmi celles-ci l'un influence le style général de l'interface. Cette préférence s'appel "MS_STYLE". Elle accepte la valeur vrai (true) ou fausse (false). La figure ci-avant donne l'apparence du panneau si cette variable à pour valeur fausse (false). Dans le cas contraire, tous les dialogues ont une barre de menu supplémentaire en tête. Notons également qu'il existe deux jeux d'icones. L'un est en noir et blanc leur est en couleur. Le choix de ce jeu se fait également dans les préférences.

Dans la suite de ce document, nous ne décriront que le premier style. Le lecteur ne devrait pas avoir de difficulté à comprendre les équivalences entre menus et boutons.

Un catalogue a deux barres d'outils. Les outils de la première permettent de chercher dans le texte de la fenêtre, d'imprimer le contenu, d'appeler et de charger l'éditeur correspondant. Les deux boutons suivant permettent de supprimer un élément du catalogue et de renommer l'un deux.

La seconde barre permet de sélectionner un mode de présentation. Le premier est un mode séquentiel. Il liste les éléments dans l'ordre alphabétique des références. Le second est le mode hiérarchique. Dans ce mode, il faut choisir une hiérarchie parmi celles définies. Pour chaque catalogue, on peut définir autant de hiérarchies que l'on veut. En particulier, on peut classer une partie seulement des éléments. Dans ce cas, les éléments non classés vont automatiquement dans une partie dite ``non classée'' . Ceci permet notamment de créer une vie particulière des comptes, qui ne reprennent que les comptes concernés par la TVA.

Dans un catalogue, chaque élément est présenté par une ligne de texte comprenant sont identité et une courte description qui dépend de la nature de ces éléments. Par le biais des préférences personnels chaque utilisateur peut, cacher les identités.

Le choix d'une hiérarchie se fait soit en tapant le nom de celle-ci dans le champ de texte de la barre d'outil, soit en tapant un ``retour'' dans cette même fenêtre. A ce moment, un dialogue apparaît permettant de sélectionner le nom voulu.

Le dernier bouton permet de créer et modifier les hiérarchies correspondant au catalogue.

Tous les éléments de la fenêtre peuvent être ``tirés'' puis ``lâchés'' ailleurs et notamment dans un document.

On ouvre et l'on ferme une hiérarchie, alternativement, par simple sélection. On peut évidemment sélectionner une suite de partie en faisant glisser la souris sur plusieurs lignes en maintenant le bouton de sélection pressé. Pour ouvrir tous les niveaux sous-jacent d'une hiérarchie, il suffit de maintenir le bouton ``ctrl'' pressé en même temps que l'on effectue une sélection simple ou multiple.

Tous les éditeurs sont équipés d'une barre d'outil normalisée. Le premier bouton permet de charger l'élément à éditer. Sa forme laisse comprendre le type d'élément qu'il accepte. Le bouton suivant permet d'imprimer un texte présentant l'élément. Au milieux un champ présent l'identité de l'élément. A gauche de ce champ un bouton permet de vider l'éditeur. A droite, un bouton permet de sauver l'édition. Puis vient un bouton permettant d'ajouter un commentaire libre associé à l'élément. Le bouton suivant ressemble comme deux gouttes d'eau au premier de la barre d'outil. Mais sa fonction est différente. En fait il permet de charger les valeurs d'un élément compatible. Ainsi, il est possible de définir partiellement un élément puis de compléter la définition en chargeant le boutons dont question avec un élément compatible déjà complètement défini dont les valeurs peuvent être réutilisées.

Certains éditeurs peuvent avoir des champs en lecture seule. C'est le cas par exemple de l'éditeur de produit dont le champ de prix de vente est verrouillé. En effet, cette valeur est calculée au moyen de la fonction de vente associée.

Un produit peut être un objet un service. Il peut être acheté puis revendu, ou acheté puis incorporé dans un ensemble plus complexe et disparaître en cet ensemble. Le système reconnaît les charges pure, les services pures ou les produits ordinaires, c'est à dire ceux qui sont acheter et revendu. Le système refuse dans un document de sortie toute référence à une charge pure. De même, il refuse toute référence à un service pure dans un document d'entrée.

Un service pure est défini par un seule prix de vente. Une charge pure est définie par un seul prix d'achat. Sinon, un produit est normalement définit par un prix d'achat défini dans une certaine devise et soit une fonction de vente (recommandé) soit par un prix de vente.

Enfin, un produit peut être une composition de plusieur autres. Si prix d'achat n'est pas défini, est est évalué comme étant le coût de ses composant.

Un produit peu avoir un stock. Celui-ci peur être simple ou en mode de gestion par lots. Dans les deux cas, on peut définir des bornes inférieurs et suppérieurs qui pourront être utilisées dans le contexte de document d'approvisionnement automatique ou plus souvant semi automatique. Le type de stockage ne peut être changer que lorsque le stock est vide (0).

Comme tout autre ensemble de donnée appartenant à un catalogue, les produits on une identité unique. Celle-ci peux être un code à barres. Mais, en plus, un produit peut être référencé par des synonymes. Ceci permet d'avoir plusieurs producteurs qui étiquettent leurs produits avec leur propre code à barres pour un même produit. Si l'on supprime un produit du catalogue, automatiquement, tous les synonymes disparaissent. (Contrairement à la plupart des système d'exploitation, les liens symboliques ou raccourcis ne reste pas en place alors que leur cible n'existe plus!)

Le catalogue des produits à un outil supplémentaire qui permet d'introduire ces synonymes. Le lecteur de code à barre, lorsqu'il est confronté a un code inconnu, lance une procédure qui permet soit d'introduire le nouveau produit ou de définir le nouveau code comme synonyme d'un produit existant.

Une adresse définit aussi bien un fournisseur un client ou un employé ou encore tout autre relation. Notamment, une adresse peut être celle d'un représentant d'une société. C'est un contact important, mais du point de vue financier, il n'existe pas. Seule sa société est importante de ce point de vue. Dans ce cas, on définit un "tuteur" pour cette personne. Le tuteur sera utilisé en lieu et place de la personne pour toutes les opérations comptables. Il en sera de même pour un assuré pris en charge par un médecin ou tout autre forme d'agent de la santé.

En déactivant le signet de tuteur, le mécanisme correspondant est suspendu mais la liste de membre reste intacte.

Une liste est dédicacée à chaque modèle de document. A chaque liste est associé un éditeur mis en forme en fonction du modèle. Les listes de documents sont équipés de la première barre d'outil des catalogues.

La partie supérieur de l'éditeur concerne les actions applicables au document. Cette section n'est active que lorsque le document inclus est correctement édité. L'édition ayant été sauvée, le menu d'action peut être tiré. La première action est, nécessairement, de fermer le document. Cela signifie qu'il n'est plus éditable. La date de cette fermeture apparaît dans le champ dédié à cette effet. Ce champ n'est pas éditable. Les actions suivantes dépendent du concepteur du modèle. Donc, ces actions doivent refléter la complexité procédurière de l'entreprise.

Dans les cas les plus simples, l'action de fermeture peut être la première d'une séquence qui enchaîne toutes les autres jusqu'à un état final. On peut imaginer qu'un courrier ordinaire est fermé par son auteur et automatiquement expédié par lettre ou fax ou courrier électronique voir par les trois voies selon les décisions du concepteur du modèle. Mais alternativement, le concepteur peut décider que l'action d'expédition n'est pas automatique car il veut forcer l'auteur à décider la voie d'expédition.

La session suivante de l'éditeur est dédiée au champs de textes spécifiques du document. Certains d'entre eux peuvent être obligatoires. Par exemple le champ délai pour une facture. Celui-ci sera utilisé pour piloter les éventuelles rappels.

Les document proprement commerciaux, c'est à dire ceux qui concerne une liste de produits échangeables ou échangés, ont une section supplémentaire. Celle-ci comprend une ligne d'édition de ligne et la liste des produits inclus. Un récepteur permet de recevoir un produit, venant par exemple du catalogue. Si l'on ``lâche'' un produit dans ce récepteur, la ligne est presque entièrement définie. Seule reste à définir le quantité concernée. On peut évidement modifier le prix unitaire par exemple pour cause de conditions spéciales négociées. Mais, par contre, on ne peut se référer qu'à un produit connu du système. Le système de comptabilité analytique automatique en dépend.

Dans le bas de cette section, on voit apparaître les montants totaux et les taxes associées ainsi que la devise dans laquelle est libellée le document. Notons que généralement, les document tournés vers les fournisseurs seront définis implicitement en devise définie par la devise du premier produit inclus. Par contre, les documents destinés aux clients seront normalement en devise locale (devise de référence).

Il faut noter que l'on peut parfaitement créer un document destiné à un client a partir d'un document fournisseur. Le système transpose les prix dans le sens approprié en se basant sur les définitions des produits et les fonctions de vente associées.

La liste des documents montre l'état de chacun. Ceci permet de se rendre très rapidement compte des documents en suspend. Notons que tout action automatique, qui doit être faite dès qu'un document est resté plus d'un certain temps dans un état donné, peut être réalisée grâce a une action dite d'attente introduite dans la séquence des actions qui conduit au dit état. Si l'état du document est toujours le même lorsque le délai est expiré, alors l'action en attente réalisera la transition qui lui est assignée. Cette transition contient elle aussi une action à effectuer (cela peut être l'action nulle). Cette transition, si l'action est réussie, conduira dans un nouvel état. Pour une facture, l'action peut être d'envoyer un rappel automatiquement. Notons que le texte du rappel sera différent du texte original par le fait que le filtre de mise en page sera différent de celui utilisé pour la première version. En fait, le système cherche dans la table de filtre celui qui a le nom du modèle qualifié du nom de l'état. Ainsi, le concepteur des documents créera par exemple une version normale du filtre et une version qualifiée par``.attente'` . Dans tous les états le système utilisera la version de base, faute de trouver une version qualifiée de façon appropriée, sauf dans le cas ou l'on passe de l'état attente a un état de rappel. La version de rappel du filtre contiendra simplement quelques formules fixes rappelant le débiteur à ses engagements.

Ce processus peut être cascadé, on peut imaginer deux ou trois rappels, suivit de la génération d'un document directement transmis à un office spécialisé dans les poursuites. En combinant les attentes, les actions simples ou en séquence, y compris la génération automatique de sous-document, il est possible de couvrir des processus très souples et complexes.

Reprenons ici l'exemple d'une commande. L'entreprise veut commander quelque chose à un tiers. Il faut émettre un bon de commande. Ceci est très vite fait et de façon sûre car le système connaît toutes les données sauf les quantités souhaitées. Fixer ces données est le seul point auquel l'opérateur doit faire attention, mis à part un rabais exceptionnel consenti par le fournisseur! Ce document est transmis automatiquement par fax par exemple. Dès réception de la marchandise, on fait passer le bon de commande dans l'état reçu. Ceci à pour conséquence de générer une facture fournisseur dans l'état ``brouillon'' . Cette facture peut être modifiée dans la mesure ou l'on a constaté une discordance entre la commande et la réception. A la réception de la facture réelle du fournisseur, une simple vérification suffira. Si l'on est d'accord en tout points, l'on fermera notre version de la facture et on la fera passer à l'état en ``attente de payement'' . Le payement sera déclenché automatiquement au bout du délai imparti par la génération d'une formule de payement. Bien sûr, aux diverses étapes, les écritures comptables nécessaires seront faites. Par exemple, à l'approbation de la facture le compte créancier sera chargé du montant approprié ainsi que des comptes TVA d'entrée. La distribution analytique des achats, peut se faire à la réception soit de la marchandise soit à la réception de la facture réelle du fournisseur. Ceci est une question de point de vue. Il faut se reporter au chapitre comptable pour une discussion des actions comptables et de la gestion des taxes.

Le chapitre de maintenance discutera en détail les diverses actions possibles et leurs usages. Il est aussi recommandé d'imprimer les définitions des modèles fournis dans les exemples et de les interpréter. Ceux-ci mettent en oeuvre des mécanismes tels que décrit ci-devant.

Certain document spéciaux peuvent être équipe d'un filtre de génération et contrôle des données contenues dans chaque spécimen. C'est le cas par exemple d'une fiche de salaire, qui sera discutée plus loin, ou d'une fiche de travail spécifique à un métier.

Un filtre de génération de donnée fonctionne sensiblement de la même manière qu'autre filtre de présentation/édition. D'un part, un spécimen du modèle est créé et les champs de donnée qu'il évoque sont remplacés par les valeurs correspondante du document en cour d'édition. Le programme associé à ce type de filtre est ensuite exécuté. Celui-ci crée un fichier de sortie contenant les valeurs à introduire ou modifier dans le document en cour d'édition juste avant la sauvegarde. A ce moment, le test de validité et de complétude du document est effectué. Si celui-ci est satisfait, alors le document est sauvegardé. Les techniques de création de tels filtres sont discutés plus loin dans la section de maintenance.

Le catalogue des comptes terminaux présente la liste des comptes terminaux. Nous entendons par comptes terminaux ceux qui sont directement utilisés dans une écriture soit comme origine ou destination. Tous compte terminal a une identité unique. Il est présenté par cette identificateur et peut avoir une description complémentaire par le biais du commentaire associé (voir éditeur). On peut donc donner a un compte une identité nominative logique telle que ``caisse'' et un commentaire telle que ``1001 ...''. Le commentaire fournit ici la référence au numérotations traditionnelles (introduit par les balbutiement de la mécanographie). L'inverse est aussi possible. Au même compte ont peut donner l'identité 1001 et le commentaire ``caisse''. Rappelons au passage que chaque utilisateur peut, pour tout catalogue, cacher les identités. Ainsi, il y a devrait y avoir de quoi satisfaire tous le monde sauf peut être les autoritaires! Mais, rappelons que pour toute action comptable qui n'est pas automatique, ce sont les identificateurs qui sont utilisés. Ainsi par exemple si un payement peut ce faire par caisse, carte de crédit ou banque, si les identificateurs sont 1001, 1003, 1010 votre expert comptable sera heureux, mais l'utilisateur normal lui sera peut être un peu confus!

Comme pour les autres catalogues, on peut définir des hiérarchies (partitions) sur l'ensemble des comptes terminaux. C'est par ce biais que l'on crée des plans comptables. Bien entendu, toute partition couvre totalement l'ensemble des comptes terminaux. Les comptes globaux sont donc les parties ainsi constituées. IL est donc possible d'avoir divers points de vue sur une même réalité dans la mesure ou l'on peut affirmer que les comptes terminaux représentent la réalité!

Notons, que l'affichage d'une hiérarchie sur les comptes montre, pour autant que l'utilisateur ait les privilèges requis, la balance de chacun d'eux qu'ils soient terminaux ou globaux. En se concentrant sur le sommet d'un telle hiérarchie, construite selon des normes usuelles, on donne une vue instantanée du bilan (sans écriture de clôture bien évidemment, ceci reste de la seule responsabilité des utilisateurs).

A tout le moins, tout système devrait contenir deux hiérarchies. La première représente le plan comptable légale, la seconde représente le bilan des comptes de taxe, du moins en régime de TVA. Attention, toutes les présentations sont équivalentes et correctes du moins dans la mesure ou tous les comptes sont classés (c'est à dire que la partition automatique qui reprend tout les éléments n'ayant pas été explicitement classés est vide).

Mais on pourra ajouter divers points de vue analytiques. Lorsque l'on définit des produits, ont définit aussi des comptes spécifiques pour la comptabilité analytique. Ces comptes sont normalement créés automatiquement en respectant les règles de taxinomie définies dans le fichier des préférences systèmes. Les actions comptables automatiques engendrées par les documents permettent de maintenir cette comptabilité parfaitement à jour de façon totalement implicite.

Le catalogue des comptes à, dans sa barre d'outils, un bouton d'accès chargeable supplémentaire par rapport aux autres catalogues. Celui-ci permet de visualiser un compte quelconque.

Le bouton }1 permet de tranferer un ensemble de comptes vers un seul. Ceci est notamment utile pour clôturer les comptes de produit et charges.

Le second bouton de filtrage impression donne accés à la page de publication des comptes. Cette page permet de donnéer les limite temporelles de cette publication. La case à cocher "globale" indique au systéme s'il doit publier un compte global (donc un ensemble de comptes) comme s'il s'agissait d'un compte terminal. Les comptes considérés pour une publication dépend de la façon dont est déployées la hiérarchie de comptes. La partie non classée n'est pas publiée.

Parmi les actions comptables automatiques, il y a celles qui permettent d'enregistrer les flux de taxes en entrée et en sortie. Dans la définition d'un produit, on doit introduire le taux de taxe qui y correspond. Cette valeur est utilisée par les actions spécifiques de gestion des taxes (voir liste des actions).

Le système construit automatiquement des comptes d'entrée et de sortie pour chaque taux de taxe. Ainsi, les flux de taxe sont automatiquement comptabilisés sur des comptes séparés par niveau en entrée et sortie. Si il y a 5 niveaux, il y aura 10 comptes. On construira donc une hiérarchie avec ces comptes terminaux de telle sorte à disposer des données sous la forme souhaitée pour l'administration concernée. La figure suivante donne un exemple d'une telle structure.

Lors de la définition d'un produit, on peut définir le niveau du stock courant et les bornes minimum et maximum de ce stock. Si ces champs sont définis, alors, il est possible de créer des documents modèles qui permettent d'automatiser les rapprovisionnements.

Pour que ce mécanisme fonctionne, les conditions suivantes doivent être réunies.

· Certain documents ont un automate qui fait appel aux actions de stockage et de retrait du stock. Les uns pour constater les entrées de marchandises, les autres pour constater les sorties. (Voir la spécification des documents au chapitre de la maintenance). Grâce à ce premier mécanisme, le niveau de stock physique est automatiquement maintenu en correspondance avec la réalité, pour autant que l'un de ces documents tienne également compte de pertes éventuelles ou que l'on corrige manuellement les stocks dans de telles éventualités.

· Un document, que nous nommerons ici, modèle de commande, est défini. Il rassemble un ensemble de produits qui devraient être commandés ensembles. Cela peut être tous les produits que l'on commande nécessairement chez un même fournisseur. L'automate de ce modèle de commande est conçu de telle sorte a générer un bon de commande. Il est possible de lancer automatiquement la première transition du bon de commande ainsi générée. Cette transition peut fermer le document et le transmettre directement au fournisseur. Cependant, la prudence voudrait que l'on laisse le document généré dans l'état de brouillon de telle sorte à pouvoir le vérifier, y appliquer quelques retouches en fonction des circonstances. Puis on donnera l'ordre de transmission manuellement.

La boite à outil permet de définir des projets. Un nouveau projet consiste en un nouveau nom unique et un commentaire éventuel. Un fois crée, le projet apparaît dans le menu correspondant de la barre d'outils principale. Le dossier projet pourra recevoir tous les documents appartenant à un projet. Cette appartenance peut être définie manuellement ou automatiquement. Pour spécifier qu'document appartient à un projet il suffit de le saisir quelque part, typiquement dans une liste correspondant au modèle du document, puis de la lâcher dans le projet. Puis précisément dans la liste des documents du projet. Une telle liste est toujours triée chronologiquement. Mais, un document qui est créé a l'aide d'un autre document, appartient automatiquement au même projet que le document qui est utilisé comme source pour autant que celui-ci appartienne à un projet. Par exemple, si un bulletin de livraison génère automatiquement une facture, celle-ci appartient aussi au projet auquel appartient le bulletin de livraison.

Si donc, une entreprise travail essentiellement par projet, elle doit, dans ces modèles de document forcer le marqueur de lien. Ceci forcera la personne qui compose manuellement un document à ouvrir le projet auquel son document devra appartenir pour utiliser un document quelconque contenu dans le dossier du projet pour s'en servir comme modèle. Ceci implique qu'il existe un modèle de document, que l'on pourrait appeler "projet" qui lui n'impose pas de prédécesseur. Un spécimen d'un telle document sera alors placé dans chaque dossier projet comme racine du projet.

Le dossier projet rassemble donc tous les documents d'un projet. Il permet de visualiser immédiatement le déroulement temporel du projet et l'état financier de celui-ci. En effet, si la personne qui le consulte est privilégié il peux voir les montants engagés dans chaque document. Ainsi, en visualisant les seules factures fournisseurs et les factures clients, on obtient une bonne vue de la situation courante du projet.

Afin de permettre divers vue sur le projet, la fenêtre de visualisation est équipée d'un outil de filtrage. Cette outil reprend, comme dans un liste de documents homogènes, le moyen de filtrer le récipiendaire, un certain état et une plage temporelle. En outre, il permet d'exclure une liste de modèle de document. Pour définir cette liste, il suffit de saisir un spécimen représentatif d'un modèle que l'on veux masquer et de le lâcher dans le trou de masquage dont question.

L'éditeur d'adresse comprend un bouton d'accès au dossier personnel de la personne cible de l'éditeur. Ce dossier ressemble très fort à un dossier projet. Il y a néanmoins trois différences importante. La première est que tous les documents concernent une même adresse. Si par exemple il s'agit d'un client, ce dossier personnel ne mentionnera aucun document relatif aux achats fait pour satisfaire les besoins de ce client. En particulier si l'adresse contient un référence à un tuteur (voir adresse) aucun document relatif à ce tuteur ne sera visible dans ce dossier. La deuxième différence est qu'il n'y a aucune démarche préalable pour créer un tel dossier. Il suffit que l'adresse existe. La troisième est qu'il ne peut être limité dans le temps. Tant que l'adresse existe tout document relatif à cette adresse appartient au dossier. Il est cependant possible de ne visualiser qu'une certaine période temporelle.

Le dossier personnel n'est pas la solution universelle. C'est certes la solution de choix pour les professions libérales à faible consommation de ressources externes. Ce n'est pas le bon choix pour l'entrepreneur du bâtiment.

Un document appelé ``fiche de salaire'' peut créé afin de gérer les salaires. Il s'agira d'un document de type fournisseur. En effet, l'entreprise paye un service fourni exempt de TVA. Par contre, cette prestation s'accompagne de cotisations diverses. Celle-ci diffèrent de pays à pays. Généralement une partie du montant total du document est payée au prestataire des services. Les autres parties sont cumulées dans des comptes spécifiques faisant l'objet de décomptes séparés et différés.

Ces cotes part dépendent des législations de chaque pays, branche, etc. L'exemple d'un tel document est fournit avec le produit. Il est construit sur base de la réglementation suisse. L'exemple est basé sur une entreprise prestataire de service à domicile. Dans le catalogue des produits on trouve un produit appeler ``prestation'' côté à la valeur de la rémunération dite nette de l'employé. Deux autres produits existent dans le catalogue appelé ``AVS'' et ``AC''. Celle-ci sont côtés au taux de cotisation par francs de rémunération.

Un filtre de calcul est associé à ce modèle de document. Comme décrit plus haut, ce filtre est appelé avant la fermeture du document. La seule opération que l'utilisateur doit faire, est d'introduire le produit ``prestation'' et le nombre d'heures effectuées dans ce document appelé fiche de salaire. A la première transition, le filtre complète le document avec les cotisations. Dans l'exemple proposé, dés que le document est fermé, on peut lui appliquer l'événement ``payer''. Ceci entraîne la création d'une formule de paiement pour la part qui est effectivement versée à l'employé. En même temps, les comtes ``AVS'' et ``AC'' sont charger pour les montant adéquats.

Les automates et les actions associées aux documents permettent d'automatiser la gestion de bien d'autres problèmes. Vous trouverez dans les exemples fournis la gestion du travail du caviste. Cette automatisation est réalisée à l'aide de deux documents. Le premier, qui est le seul manipulé directement par le caviste, est nommé: ``mise en bouteilles''. Il utilise un filtre actif, comme pour la gestion des salaires, pour générer les apports axillaires à la mise en bouteilles. La caviste doit seulement préciser la capacité de son tonneau et la dénomination du vin. Plus précisément, il ``tire & lâche'' un produit de type vin XY en vrac dans le document, puis il spécifie la quantité, c'est a dire le volume du tonneau. Le filtre générateur de champs, ajoutera les entrants secondaires, c'est à dire les bouteilles, bouchons, etc. Lorsque le travail est terminé, il fera passé le document de l'état ``en cours'' à celui de terminé. Ce changement d'état provoquera le génération du second document nommé: ``création de bouteilles''. Ce second document n'est pas manipulé directement. Il peut même être totalement masqué à utilisation ordinaire.

Cet exemple à pour seule prétention de montrer une voie pour aborder toute sorte de problème de manutention de service et même des problèmes de productions.

Pour garder une trace des événements important, ABC offre plusieurs possibilités. La première consiste à utiliser, dans l'automate de certains documents, une ou plusieurs séquences d'action de sortie (voir plus loin le jeu actions) et de commande externe. On met donc ainsi une sélection de données du document à la disposition d'un système extérieur. Ce système peut être une base de donnée.

La second solution consiste à utiliser l'action spécialement conçue à cette effet. Celle-ci permet d'enregistrer une sélection de données du document dans le commentaire associé au document. Bien sur ces enregistrement peuvent également être ultérieurement extrait pour exploitation à l'aide d'autre outils ou pour publication. Ceci pouvant être fort utile notamment dans les domaines liés à l'agroalimentaire où la traçabilité devient une exigence.

Actuellement, le système n'est pas réellement "multi-postes" au sens ou tout peut être fait simultanément sur plusieurs postes de travail, avec l'éternel problème d'interblocage ou d'annulation de transaction au dernier moment. Par contre il est possible par un usage judicieux des actions exportation automatique de créer des postes spécialisés telle qu'une caisse.

Pour créer une poste subordonné, il faut créer une copie du répertoire des données du poste supérieur dans un répertoire réservé à ce poste subordonné. Puis, dans le ficher des préférences communes (sys_prf.txt) du poste subordonnée, il faut définir un canal de communication avec la station supérieures. Une telle définition prend la forme:

Localhost devant être remplacé par le nom `IP' (voir votre administrateur réseau) de la station supportant le poste supérieure. Export_port est numéro du port en protocole tcp.

Dans le poste supérieur on doit introduire dans le fichier sys_prf.txt correspondant une définitions d'écoute.

Ceci indique à se poste qu'il doit importer automatiquement des documents en provenance de postes subordonnées.

Les postes ainsi créés peuvent être géographiquement n'importe où. La communication peut avoir des trous. Le système est capable de gérer les défauts de communications.

L'action d'exportation peut définir une transition à effectuer automatiquement dès réception. Ainsi, la caisse peut envoyer un document dans l'état dit de brouillon et le faire passer à l'état terminé en traitant la transition étiquetée "fermer". Ceci permet d'effectuer les opérations comptables et la gestion des stockes.

Cette technique permet d'avoir un poste supérieur à jour en temps réel au coupure du réseau près. Par contre, les postes subordonnés, en principe spécialisés, ne sont pas au courant de ce qui se passe sur les autres postes. Pour les mettre à jour, il faut qu'il soient primo arrêter et ensuite que l'on mette a jour leurs fichiers de données. Soit les fichiers business.dmp. Ceci peut se faire sur une base journalière par exemple à la fermeture des caisses.

Ces trois collections ne sont accessibles que par le menu de maintenance pour des raisons de sécurité. En effet, seule un responsable de gestion peut modifier les cours des devises, ajouter ou supprimer des comptes, altérer les fonctions de vente. La manipulation de ces outils d'édition ne présente cependant aucune difficulté. Il faut cependant noter que ces collections sont aussi accessibles par tous les utilisateurs mais en mode de lecture seule.

Une fonction de vente permet de définir comment à partir d'un prix standard d'achat, on peut calculer un prix de vente en fonction de certains paramètres.

Les paramètres de base sont la remise obtenue du fournisseur, la marge brute unitaire et une constant éventuel. Le prix peut encore être modifier par un fonction à seuil en fonction de la quantité. En outre, un facteur de modification peut être définit par rapport au destinataire en associant le nom d'une partition sur les adresses. Si le nom de la partie qui contient un nombre sous l'un des formes: '*xx' ou '-xx'. La première forme désigne directement un facteur. La seconde forme désigne une remise en %. Exemple: Bon_clients-5 donne une remise de 5% pour les adresse contenue dans cette partie. Client_exceptionnel*0.9 provoque une multiplication du par 0.9. Soit une remise de 10%.

Enfin on peut également appeler une fonction extérieur ou à une expression algébrique. Pour définir une fonction, il suffit de donner sont nom. Il faut bien évidement que cette commande soit accessible pour ABC. Une expression est elle introduite par le signe '='. Les opérateurs sont : +,-,/,*,^ soit les quatre opérateurs arithmétiques classiques et l'exponentiel. De plus il y a les opérateurs inverse &, ¬. Le premier donne 1 pour un opérant à sa droite plus grand que zéro, sinon 0. Le second donne les résultat inverse.

· T: un entier qui représente la date du jour exprimée en seconde depuis le 1 janvier 1970 (unix tO)

Un champs optionnel nommé promotion à été défini pour les fiches produit. On désir que les produits qui ont un prix spécial pendant une période de promotion soit facturé au client à se prix la à l'exclusion de toute autre remise. La formule sera:

Le premier terme ("PF*¬promotion") vaut 0 si une promotion est définie et est égale au facteur personnel (FP) autrement (et donc 1 si la personne n'a pas de remise personnel). Le seconde terme vaut 0 si il n'y pas de promotion définie. Il est égale au facteur de modification du prix standard autrement.

Tout document est édité en partant d'un modèle. Les modèles doivent être définis par un responsable privilégié du système. La définition d'un mode comprend trois sections. Dans un premier temps, il faut choisir la classe de base du document, puis il faudra définir les champs de textes et enfin définir l'automate associé. Quatre classes de document sont reconnues actuellement: lettre, fournisseur, client, payement. La classe des lettres est la plus simple. Elle ne comprend que des champs de textes. Les classes client et fournisseur ont une liste de produits et des notions de valeurs et taxes. Et sont différenciées par la façon dont elles calculent leurs valeurs. La classe dite des payements sert à des actions après vente ou achat. Elle a des notions de valeur. L'usage le plus évident de cette classe est bien entendu de créer des formulaires de payement d'où le nom.

Tout document à une identification ou référence. Tout document à une identification unique pour son type. Le modèle définit le type référence. L'on peut choisir soit une numération continue absolue, soit une numérotation continue par année. En outre cette numérotation peut être précédée d'un préfixe. Il faut cependant noter que l'on ne peut changer le système de référence que si le classeur correspondant est vide, ceci pour une raison de cohérence.

Les documents commerciaux de type client ou fournisseur comprennent une liste de produits concernés avec pour chaque ligne une quantité, un prix unitaire, etc. Un tel document a une valeur et éventuellement un montant de taxe associé. La valeur du document plus la taxe donne une valeur totale. Pour de tels documents, il est nécessaire de préciser le régime de taxation. Soit ce régime doit être défini par l'utilisateur au moment de la rédaction d'un exemplaire, soit le modèle force un régime. Typiquement, on peut définir un modèle de facture-export tel que ces documents sont d'office hors taxe. Dans cette même section, on peut forcer une devise autre que la devise de référence. Notons au passage que la devise de référence à la vente est la devise de référence locale (voir devise). Alors que la devise implicite à l'achat est la devise du premier produit de la liste. L'assertion que les produits d'un fournisseur sont tous vendus dans une même devise à été faite.

L'étape suivante consiste à définir les champs spécifiques. Un champ peut être obligatoire ou facultatif. Le système supporte trois type de champs: texte, ou numérique (entier ou réel). Les champs numérique peuvent être des vecteurs (un suite de valeurs). Les champs de textes peuvent contenir une ou plusieurs lignes. Un champ de texte peut avoir une longueur infinie, Il suffit de lui attribuer un texte tournant. La liste des champs définis présente un champ facultatif entre crochet carrés. Les champs à multiples lignes indiquent leur nombre de lignes et ils sont souvent suivis du caractère `@' s'ils sont potentiellement sans limites. Pour modifier la définition d'un champ, il suffit de le sélectionner.

Ensuite la définition du comportement du document. En fonction de l'évolution d'une affaire, on fait évoluer l'état d'un document. On peut par exemple associer à une facture client les états: brouillon, approuvé, transmis, rappel, payer. A chaque état, on peut associer certains événements reconnus. Par exemple, une facture transmise accepte au moins deux événements: payement, délai-d'attente-expiré. Le premier événement conduira à l'état payé après avoir engendré l'action comptable qui traduit cet événement. Le document a donc un comportement automatique en fonction de ses états et événements reconnus.

Il existe un choix important d'actions possibles. Elle sont ici présentée groupe de nature analogue.

· Séquence: cette dernière action permet d'enchaîner plusieurs actions. Elle n'accepte que des actions automatiques. Elle permet de simplifier grandement un automate. Par exemple, un formulaire de payement peut n'avoir qu'un état initial, une seule transition vers un état final. La transition évoque une action composite qui réalise les étapes suivantes: fermer, envoyer, comptabiliser-le-payement.

· Fermer: fige le contenu éditable du document. Cette action est une precondition à certaines autres actions. Par contre, elle ne peut intervenir avant certaines autres. Au moment de la fermeture, le document est daté. Toutes les actions comptables exigent un document fermé. Pour les autres actions, une spécification est donnée pour celles qui exige une precondition.

· Signer: cette action ajoute la signature de l'utilisateur. Pour que cette action aboutisse, il faut qu'un fichier graphique compréhensible par l'outil de mise en page (filtre de mise en page) soit présent dans le sous répertoire de donnée ``signature''. Notons au passage que l'on peut préférer apposer sa signature manuscrite sur les documents postés, mais par contre, la signature ``électronique'' est préférable pour les versions ``faxées'' directement par modem. Précondition: le document est fermé.

· Générer: cette ultime action permet de générer automatiquement un document et éventuellement de lui faire exécuter une des transitions existantes dans l'état initial du document généré. Reprenons les exemples précédents. Quand une facture fournisseur arrive à échéance, un document de payement est généré et l' unique transition de ce document est activée. Ceci termine le cycle d'action propre au suivi des factures des fournisseurs. Ainsi, la dernière action réellement effectuée par un utilisateur est d'approuver la facture. (Il vaut mieux ne pas automatiser cette action!)

· Envoyer: cette action envoi automatiquement ou sur confirmation manuelle une version du document par poste et ou par fax et ou par courrier électronique. La mise en page et le canal de distribution sont déterminés par le fichier des préférences et un script spécifique à chaque plate-forme. Ces scripts peuvent être modifiés à volonté par le responsable de l'installation notamment en fonction des configurations matérielles. Précondition: le document est fermé.

· Comptabiliser en achat ou en vente: ces actions permettent d'enregistrer un mouvement de produit d'un compte d'achat (vente) vers un compte créancier (débiteur) correspondant au fournisseur (client, qui peut être le ``comptoir''). Cette action utilise le montant total taxe comprise du document.

· Comptabilité analytique: ces opérations sont complémentaires aux précédentes. Elle permettent de distribuer les achats et ventes sur des comptes spécifiques. Si vous autorisez la création automatique des comptes produits (voir préférences) ceux-ci sont créés dès que nécessaire par les actions dont question ici. Sinon, vous devez définir manuellement vos comptes produits lors de la définition de ceux-ci ou vous priver des capacités du système de comptabilité analytique ce qui n'est pas recommandable.

· Comptabilité des taxes: Ces actions gèrent, dans le contexte d'achat ou de vente, de distribuer des montants de taxe par niveau d'imposition. Ces actions sont indispensables pour tout assujetti à la TVA afin de pouvoir faire une déclaration fiscale en deux minutes.

· Payement : un choix d'action pour les payements fournisseurs et client existe tant pour le payement partiel ou total. Ces payements peuvent se faire par diverses voies, tels que la poste, banque carte de crédit ou caisse. On définit ces voies de payement dans l'action en ``tirant-lâchant'' les comptes correspondant dans la liste appropriée. Si une seule voie est définie, alors l'action correspondante est automatique. Sinon, au temps de l'exécution, l'utilisateur devra sélectionner la voie appropriée. Notons, qu'un niveau de paiement partiel (dans l'intervalle [0..1]) peut être définit d'avance. Dans ce cas l'action est automatique et peut être introduite dans une séquence. Cette technique est notamment utile pour la gestion des salaires ou certaine partie de salaire sont payée au salarié et d'autres à divers caisses de prévoyance sociales. Ces actions utilisent et modifie la balance (le solde) du document.

· Attendre: cette action permet de déclencher un événement automatique après un certain délai pour autant que le document soit dans l'état voulu au moment de l'expiration du délai. Par exemple, l'envoi d'un rappel pour un facture client encore en ``attente'' de payement, ou une facture fournisseur qui arrive à échéance. L'action automatique est définie par une transition que l'on tire depuis la liste des transitions possibles pour un état donné. Si la condition initiale est satisfaite, l'action est donc réalisée automatiquement et le document se retrouve dans l'état défini par la transition. Il est bien entendu qu'une action d'attente n'accepte que des actions parfaitement automatiques. Par exemple, une action d'attente n'accepte pas une transition dont l'action est un envoi en mode manuel.

Le delai d'attente peut être défini de plusieurs façons. Le plus simple est de fixer un nombre entier positif de jours. Une seconde façon, simple est de donner le mon d'un champs existant dans le document. Ce champs doit être du type spécial "délai". Une troisième solution est de définir une date dont certaines partie sont remplacées par le caractère `*', par exemple: 01/*/* pour le premier du mois. Ceci permet notamment de créer des opérations cycliques en phase avec le calendrier. Il faut noter que ce type d'écriture est aussi valable dans un champs de type "délai" dans le document.

· Stocker: cette action permet de manipuler les compteurs de stocks physiques lors d'acquisition de biens.

· Déstocker: c'est l'action complémentaire à la précédente. Elle est destinée à réduire les stocks lors des opérations de sortie de marchandises.

· create: cree un lot de produit en mode "brouillon". Le lot mentionné doit être nouveau (ne pas exister) , valide et associé à un produit existant ayant un stock géré en mode lot. Cette action doit précéder tout autre action de production de lot tel que assemblage et composition. Le produit cible est défini via deux champs de texte (ou identitifant)du document. L'un pour l'identifiant de produit et l'autre pour identification du lot. A la fin de l'action, les composants consommé ont été déstocké et supprimé de la liste

· Assemblage: cette action permet d'extraire depuis la liste du document les éléments nécessaires à la fabrication d'un produit. Si le paramètre 'netoyer' est activé la liste est alors vidée. Si le paramètre produire est activé, une nouvelle ligne décrit le produit résultant et ce résultat est stocké. Le lot cible est défini via un champs texte (ou identitifant) du document. Il doit avoir été crée par une action créer et être en mode brouillon.

· Composition: cette action fonctionne comme une action d'assemblage mais elle ne prend en compte aucune formule d'assemblage. Au contraire, elle consome tous le contenu de la liste. Le paramètre netoyage n'a donc pas de sens.

· produire:Cette action stock le resultat d'une précédante action d'assemblage ou de composition. Elle fait passer le lot du mode brouillon au mode actif. Une ligne correspondant a ce lot est ajoutée à la liste du document.

· trace: Cette action permet d'enregistrer des données dans le commentaire d'un document. Le processus de sélection de donnée est le même que pour un action de sortie qui est lui même identique à celui utilisé pour le formatage des documents à publier. Cependant, ici le texte résultant est ajouté au commentaire du document. Toute les traces sont ainsi groupées dans l'ordre chronologique dans une section du commentaire entre deux délimiteurs spécifiques. En outre on peut désigné un champs du document comme obligatoire pour les opérations de traçage. L'action peut également effacer automatique ce champs. Ceci permet de forcer l'utilisateur à remplir ce champs pour chaque événement tracé.

· Auto_stockage: cette action est semblable à une action `générer' en ce qu'elle génère un autre document. Mais elle diffère de la précédente dans la façon dont elle génère les lignes-produit du document ainsi généré. Pour chaque ligne de produit inclue dans le document source, elle crée une ligne dans le document généré (typiquement un bon de commande), si le niveau de stock du produit concerné est sous le seuil inférieur. Le niveau de commande est calculé de telle sorte à attendre le niveau supérieur augmenté du minimum nécessaire pour être compatible avec la résolution quantitative du produit. Le document ainsi généré contient finalement autant de lignes que de produits mentionnés, dans le document source, moins les produits dont le stock actuel est suffisant. L'action peut aussi lancer la première transition. Cependant, la prudence voudrait qu'un tel document ne soit pas transmis automatiquement sans un ultime contrôle d'un agent responsable.

· Retro_action: cette action permet de transmettre, à un document géniteur (voir commande générer), un événement. Si, le document géniteur est dans état qui reconnaît l'événement transmis, alors, il effectue les action correspondantes à cette événement et effectue la transition correspondante. Ce type de mécanisme permet de bloquer un document tant qu'un sous document n'as pa atteint un certain stade. On trouve sont usage dans les problèmes de suivi de production, la gestion de stock. L'exemple de gestion de stock fourni fait appel à cette action pour débloquer le document générateur de bon de commande.

· Sortie: cette action permet d'exporter des données correspondant à l'état actuel du document. Ces exportations ce fondent sur le même mécanisme que la production des vues des documents. Cela signifie que ces données sont exportées par substitution des variables mentionnée dans un document modèle rédiger dans un des langage supportés. Soit actuellement html, latex, rtf et bc. Typiquement, les exemples de mise en bouteille et de production des fichiers de salaire utilisent ce mécanisme. Puis précisément ils utilisent une séquence: sortir, commande et entrée.

· Exportation: Cette action permet d'exporter dans une ficher tout ou une partie des données du système. Les fragments possibles sont ceux défini au chapitre d'importation/exportation. Les texte exporter est conforme à la grammaire d'importation. Notons cependant que l'on peux forcer un séparateur de champs supplémentaire tel qu'un caractère ';' .

· Commande: (ou appel système) cette action permet de transmettre un ordre au système d'exploitation. Cette action peut notamment être utilisée en une action de sortie et une action d'entrée. Ainsi un programme extérieur peut utiliser les données d'ABC provenant d'un document, les traiter et fournir un résultat qui sera exploité par ABC grâce à l'action d'entrée. Une commande extérieur peut ainsi être utilisée pour un contrôle. Si la commande extérieur se termine avec un status d'erreur et un message d'erreur, la transition en cours sera bloquées et le message d'erreur transmis à l'utilisateur.

· Entrée: cette action permet de lire des données placées dans un fichier. Le texte de ce fichier doit respecter la grammaire définies au chapitre des filtre sous le titre `Entrées externes'. Cette action complète le mécanisme d'interaction avec des programme de traitement extérieur.

· Importation: Cette action permet d'importer des données depuis un fichier de texte conforme à la grammaire d'importation. Attention, ce fichier de texte ne doit pas comprendre de séparateur spécial tel qu'éventuellement défini dans une exportation.

Le traitement d'un document, commence toujours par un même état initial. Nous l'appellerons l'état ``brouillon'' . Par exemple, un bon de commande peut avoir au delà du brouillon initial, les états signé, attente, relance, reçu. Un tel document passe du brouillon à l'état signé après la séquence d'actions: fermé, signé. Le passage de signé à attente passe à l'état signé après la séquence d'action: envoyer, attendre. De cet état, deux voies sont possibles. La première voie correspond au déroulement espéré où la livraison se passe dans les délais souhaités. La seconde voie correspond à un débordement des délais. Dans le premier cas, l'utilisateur fera passer le document à l'état reçu à la réception des produits. Dans le second cas, le système fera passer le document à l'état ``relance-automatique'' en exécutant un action d'envoi du document. Notons en passant, que la composition de l'image (papier, fax, courrier électronique) de ce document dépend de l'état du document. Donc, la version de relance peut comporter une note spéciale. Quant à l'action qui permet d'arriver en l'état reçu, elle peut consister à générer une facture fournisseur.

Lorsque l'on définit une séquence d'actions, il est important de considérer les risques d'échec de chacune des actions. Par exemple, une action d'envoi peut toujours échouer parce que l'adresse associée ne comprend d'adresse valable pour le media considéré. Une séquence telle que: attendre puis envoyer est mauvaise. En effet, l'action d'attente est lancée alors que la transmission ne s'est pas faite. Ceci n'a d'une part pas de sens, mais en plus, cela conduira à placer deux demandes d'attente automatiques dans la seconde et se terminera avec un message d'erreur sans importance dans ce cas mais néanmoins perturbatrice pour l'utilisateur. Par contre, la séquence envoyer, attendre est saine, car dans ce cas l'action d'attente ne sera lancée que si l'envoi se passe bien.

Une séquence d'action ne peut comprendre que des actions parfaitement automatiques. Ainsi, une action de payement fournisseur peut souvent être inclue dans une séquence car il est parfaitement plausible de définir un seul compte à débiter. Par contre, une payement client peut comporter une indétermination entre plusieurs voies de payement: caisse, banques, poste, carte de crédit. Dans ce dernier cas, l'utilisateur devra choisir un compte manuellement. Il est cependant possible d'adopter une autre conception dans laquelle on définit des événements différents en fonction de la voie de payement adoptée par le client. Dans cette solution, on peut créer des séquences différentes pour chaque voie. Rappelons également que la première action sur un document est obligatoirement sa fermeture. Une fermeture est nécessairement la première action d'une séquence. Notez au passage qu'une fermeture peut échouer. En effet, on ne peut fermer un document que lorsqu'il peut être considéré comme complet.

La définition du comportement se fait grâce à la partie inférieure de l'outil de modélisation. Tout en bas, on trouve à gauche la liste des états déjà existants. A droite, la liste des événements possibles pour l'état sélectionné. Au dessus, se trouve l'éditeur de transition. En double cliquant un événement existant, on charge l'éditeur de transition pour modification.

Quatre champs se succèdent dans l'éditeur de transition. Ce sont les champs correspondants à:

1. L'état initial: soit un état déjà existant soit une nouvel état à créer. Ce champ peut être rempli en tirant une état existant.

2. L'événement: une étiquette qui définit le nom de l'événement qui déclenche la transition

3. L'action: définit l'action qui doit être exécutée pour l'événement correspondant. Ce champ peut être édité manuellement, mais il est bien plus simple de tirer un mode depuis la liste des actions possibles que l'on trouve dans la barre des outils. Dès qu'une action est insérée dans ce champ, elle peut être tirée et lâchée dans un éditeur d'action pour en préciser les paramètres. Ces éditeurs ont une configuration qui dépend du type d'action.

4. La destination: définit l'état final atteint après que l'action se soit terminée de façon satisfaisante.

Sous l'éditeur de transition on trouve un champ qui définit l'état initial du document. Ce champ doit contenir une état existant, normalement non terminal!

L'éditeur d'action comprend toujours une section pour définir les utilisateurs autorisés. Si cette section reste vide, cela signifie que tous peuvent exécuter l'action. Pour remplir la liste, il suffit de tirer les utilisateurs autorisés depuis la liste des utilisateurs reconnus.

Les actions comptables demandent généralement de définir un ou plusieurs comptes soit comme source soit comme destination. Ces listes sont elles aussi définies en tirant des comptes depuis la liste de ceux-ci ou toute autre source de compte telle que l'éditeur correspondant. Il faut noter que pour les actions comptables n'est automatique que si sa liste de compte possible ne comprend qu'un compte. Par exemple, si un payement client peut se faire soit par banque ou par caisse, il y a indétermination. L'action ne peut se faire automatiquement. L'utilisateur devra choisir la voie qui a été effectivement utilisée par le client. Il faut également noter que le second terme d'une transaction comptable enregistrée par une telle action est définie, en fonction de son sous-type dans les préférences. Ils est évidemment impératif que cela soit défini dans les préférences systèmes. Il est en effet impératif que ce type d'écriture soit le même quelque soit l'utilisateur.

Pour éditeur une action d'attente, il est nécessaire de définir la transition engendrée. Cette transition doit nécessairement provenir du même modèle. Pour tirer cette transition, il suffit de sélectionner l'état de départ de cette transition, qui est normalement l'état final de la transition en cours de définition, puis de tirer la transition voulue dans l'ensemble des transitions possibles présentées. Il ne faut pas double-cliquer la ligne correspondant à cette transition car cela changerait la cible de l'éditeur de transition. C'est d'ailleurs la justification du recours au double-clic pour charger l'éditeur. En effet, un ``simple-clic'' est trop vite arrivé.

Pour transmettre une image d'un document ABC, il faut lui donner une forme compatible avec le support de transmission, papier, fax, courrier électronique, et avec les traditions de présentation. Les outils actuels de mise en forme s'appellent des traitements de texte. Le système utilise les traitements de texte existants pour produire les versions textuelles d'un document en fonction de sont état courant. Il faut donc préparer pour chaque modèle de document un ou plusieurs filtres capables de générer l'image transmise au destinataire. Un filtre, n'est rien qu'une version générique du document pour un état donné. Une version générique a tous les attributs de présentation de l'image recherchée, mais les valeurs spécifiques sont remplacées par des symboles de substitution. La dénomination exacte des symboles est visible en actionnant le bouton .

Supposons que vous ayez défini un document appelé courrier. Celui contient seulement un destinataire et deux champs obligatoires nommés concerne et corps. La version générique comprendra, en plus des éléments fixes tels qu'un logo, entête et pied de page, les symboles nécessaires pour le transport par la poste. Les symboles concernés sont: name, firstname, place, city, cp, country. Notez qu'il n'y a pas d'obligation de tout utiliser. Pour des courriers nationaux, le symbole ``country'' n'est pas utile. Ceci dépend de la modélisation choisie. Soit on crée des modèles différenciés pour des courriers en fonction de diverses destinations, soit on a un seul modèle et l'on utilise un adressage excessif pour être sûr d'être complet. On peut également dans ce dernier cas utiliser les capacités du traitement de texte a réaliser certains assemblages conditionnels.

On placera ensuite le symbole de la date. Il est recommandé, sauf pour des raisons très particulières, d'utiliser la date du système ABC et non celle du traitement de texte. En effet, lorsque vous fermez votre document, il est automatiquement daté. Il est, normalement, envoyé dans la foulée et les délais, gérés automatiquement par le système, démarrent en même temps. La date qui sera inscrite sur la version papier sera bien celle qui fait référence dans le système de gestion. Si, vous devez renvoyer une seconde copie du document dix jours plus tard, la date doit rester la même en tous cas pour un document tel qu'une facture.

On placera ensuite les symboles ``concerne'' et ``corps'' muni des attributs typographiques souhaité. Rappelons que le corps du courrier peut avoir une longueur quelconque et peut donc s'étendre sur plusieurs paragraphes même si dans la version générique, il est représenté par un petit symbole.

Il est de bon ton d'ajouter à tout le moins le nom du signataire et selon le style de la société son prénom. Ceci est réalisé en plaçant les symboles: ``SignedByName'' et ``SignedByFirstname''.

Il est également possible d'ajouter la signature électronique en plaçant le symbole: ``graphicSignature''. Cette façon de faire n'est peut être pas souhaitable pour une version papier pour laquelle la signature manuscrite est souhaitable, mais elle est très judicieuse pour la version fax. Notons à ce sujet que ceci ne fonctionne que si, pour les personnes autorisées à signer, il y a un fichier graphique dans le répertoire des signatures correspondant à l'identité du signataire et que le format graphique est compris par le traitement de texte.

La liste des symboles présentés par l'outil d'édition des modèles ne présente que la partie logique du symbole de substitution. Dans le texte d'un document générique, chaque symbole doit être entouré d'un préfixe et d'un suffixe tel que les symboles ne puissent pas être confondu avec un mot ordinaires. Ces éléments sont définis dans préférences au niveau système. Dans les exemples fournis pour le processeur ``latex''¹ le préfixe est ``+§'' et le suffixe est ``§+''. Le symbole date doit donc être écrit dans le filtre générique sous la forme: ``+§date§+'' (sans les guillemets). Ces affixes doivent être choisis soigneusement pour éviter toute confusion et surtout en fonction des séquences de contrôle du traitement de texte choisi.

La description des lignes de produits doit elle aussi être signalée de façon particulière. Pour ``latex'', dans l'exemple fourni, la description générique d'une telle ligne est préfixée par ``\$\$\$'' .

Attention, si un document comprend des vecteurs (suite de valeurs) numériques leurs nommage suit une règle particulière. Soit un champ numérique nommé ``X'' avec 4 valeurs. Ce champs produit 4 variables de substitution nommées: ``X.1'', ``X.2'',``X.3'', ``X.4''.

Les fichiers filtres doivent être placés dans des répertoires en conformité avec les définitions données dans les préférences systèmes à cet effet. La première définition donne le répertoire de base. Ce répertoire doit contenir un sous répertoire au nom de chaque processeur utilisé en fonction du canal de transmission. Le système connaît 3 canaux: poste, fax, e-mail, et un pseudo canal pour les archives papier.

Les document de type “fournisseur” ou “client” contiennent aussi une liste de produits fournis ou reçus. Cette liste doit égalment être modélisé pour la presentation. dans le modèle on incluera la description de la presentation d'un ligne entre deux marqueurs. Soit en html entre “+$$$” et “$$$+” et en latex entre “+§§§” et “§§§+”. Entre ses marqueurs on place les varable de ligne souhaitée. Celle-ci sont aussi listée à la suite des variable de document. En outre, pour inclure l'historique (trace) d'un document on peut ajouter aux variables ordinaires une construction de la forme +$trace <marqueur_html>+$<chemin_access/fichier_model>$+ </marqueur_html> $trace$+ pour inclure cette historique. Exemple :+$trace <li>+$trace/trace.html>$+ </li> $trace$+.

Un prduit ou un document peut être généré par une document. Il y a donc un lien (link) qui va de l'élément généré vers le générateur. Il est donc possible de remonter ces chainages. Pour représenter ces liaisons on place une construction de la forme +$link$ non_répertoire $link$+.

Le nom du repertoire est relatif au répertoire contenant les modéles de document (ex. ../filtre/html/). Dans les exemples fournis, ils sont nommés respectivement links et traces. Pour les liens le nom du fichier sousmodele est comme pour les modeles principaux definit par le nom de type de document. Donc si un lien conduite a un document de type nommé “réception” il faut un sous modèle nommé “réception.html” dans le répertoire links du répertoire html (ex: ../html/links/réception.html).

Pour les traces historiques il faut donner explicitement le nom du fichier sous modèle (ex: ../html/trace/trace.html)

Parmi les exemples fournis, celui nommé “agro” est sécialement conçu pour traiter des question de traçabilité. Il est donc conseillé d'observé les modéles et sous modéles pour le document culture, vinification et conditionnement.

Chaque modèle doit avoir au moins un filtre qui porte son nom. Un modèle peut avoir plusieurs version en fonction de l'état du document. Ces versions sont différenciées par l'ajout d'une extension au nom du filtre. Cette extension est formée d'un ``.'' et du nom de l'état. Notez bien que ce nom l'état est celui du document au moment de l'action et non celui après la transition entraînée par le succès de l'action. Si une facture en attente normale de payement dans un état ``attente'', action qui consiste à renvoyer un rappel se fait au sein d'une transition de ``attente'' à rappel. Le filtre de publication utilisera la version ``facture.attente'' et non pas ``facture.rappel''. En effet l'état rappel ne sera en place qu'après l'action.

Les textes rédigés à l'attention d'ABC par un programme extérieur doivent respecter la grammaire définie ici.

L'identifiant est soit le nom d'un variable de texte reçue, soit le mot ``line_'' immédiatement suivit d'un nombre entier représentant un numéro de ligne, exemple ``line_2''. Pour une champ de texte, la valeur fournie remplacera le valeur présente dans le formulaire de saisie. Pour un ligne du tableau de produit les règles sont les suivantes.

Si le numéro de ligne invoqué est plus grand que le nombre de ligne existant dans le formulaire de saisie, alors, le système tente de créer un ligne supplémentaire à la suite de celles déjà existantes. Sinon, le système tente de modifier un ligne existante.

La valeur pour ligne de produit est un suite variable d'arguments. Le premier argument défini une quantité. Pour modifier une ligne existante, cette argument suffit. L'argument suivant est l'identifiant d'un produit. Il va de soit que cette valeur doit exister comme identifiant d'un produit. Ces deux premiers arguments suffisent pour créer un nouvelle ligne. Cependant il peut être suivi d'un troisième argument qui redéfinit le prix unitaire. Si un quatrième argument suit, celui-ci redéfinit le modifier. Rappelons que le modificateur implicite vaut 1 et qu'il est facteur de l'équation: prix_total = prix_unitaire * quantité * modificateur.

Le mécanisme à été éprouvé sous Linux avec l'utilitaire bc, awk et perl. L'exemple d'un tel filtre est fourni pour la création de fiches de salaire à la ``mode'' Suisse. Il à l'allure suivante.

La premier ligne permet de recevoir toutes les lignes produit de la fiche salaire. Le filtre ici espère que la seule ligne, ou du moins la dernière, soit le nombre d'heures effectuées. La variable q vaut alors ce nombres d'heures et put vaut le prix unitaire. Le filtre produit une première ligne qui représente le montant dit ``net''. Cette valeur ira dans le champs de même étiquette. Le filtre produit ensuite quatre lignes étiquetées ``ligne_100'' .. ``ligne_103'' qui seront ajoutées aux lignes existantes. Ces lignes font appel à quatre pseudo produits qui en fait sont des cotisations sociale dont la valeur dépend du salaire théorique donné par q*pu. La dernière ligne force la terminaison du programme bc.

Si le texte contient une ligne étiquetée: ABC_INPUT_ACTION_ERROR_MESSAGE suivi d'une valeur de texte, ce text sera présenté à l'utilisateur en temps que message d'erreur. La présence de cette étiquette annule tout traitement et la transition en cours est annulée. Cette étiquette peut être modifiée dans les préférences système.

Ce qui précède peut effrayer quelque peu les non initiés aux malignités de l'informatique. Or il est vrai que ABC est destiné avant tout aux entrepreneurs et non au ``gourou'' de la micro-informatique. Pour résoudre cette contradiction apparente il y a deux solutions. La première consiste à recopier les exemples fournis et à modifier le minimum pour qu'ils fonctionnent avec votre logo en lieu et place du nôtre ainsi qu'en remplaçant nos noms et adresses. La seconde solution consiste à bien comprendre que cette opération ne doit se faire qu'une fois lors de la mise en place du système puis, éventuellement après deux ans parce que l'on veut changer de style. Dans cette optique, l'entrepreneur efficace peut faire appel à un sous-traitant spécialisé qui lui connaît, toutes les ficelles des traitements de textes et qui devrait aussi pouvoir réaliser la description des modèles.

Pour définir une liste d'utilisateurs, il suffit de tirer les adresses correspondantes depuis la liste. Si l'identité de la personne ainsi captée ne correspond pas au nom d'un utilisateur au sens du système d'exploitation de la machine, il suffit, soit de corriger cette différence au niveau de la liste des adresses, soit de tirer la nouvelle entrée, depuis la liste des utilisateurs, dans l'outil de renommage et de lui affecter le nom connu du système d'exploitation.

Notons ici que pour les systèmes tel que Windows9X qui ne peuvent pas gérer des utilisateurs multiples, le seul usage sensé de la notion d'utilisateur est de définir un pseudo utilisateur représentant la société. Ce pseudo utilisateur sera affecté aux actions qui ne doivent s'exécuter qu'en mode automatique après un certain délai. Pour lever cette protection sous Windows9X, il suffit de définir une variable d'environnement USER = root.

Il existe un utilisateur privilégié implicite qui peut tout faire. Ceci permet d'effeadministrateurctuer des actions qui ne parviendrait pas à passer en automatique. Cet utilisateur est l'administrateur système.

Le système permet d'importer des données extérieures existant sous forme de texte. On peut, actuellement importer des données concernant, les adresses, produits, fonctions de vente et les transactions. La fonction d'importation a deux usages. Le premier est d'importer des données initiales en provenance d'un système existant. Les secondes permettent des mises à jour notamment en intégrant des listes de produits des fournisseurs. Un paramètre de préférence permet de définir si les éléments importés remplacent automatiquement les éléments de même identité. La règle implicite est de demander une confirmation pour toute substitution d'éléments.

La grammaire jointe en annexe définit la syntaxe des textes importables. Un exemple est aussi fourni dans le répertoire des exemples.

L'exportation poursuit également deux buts. Le premier est de produire un texte permettant une élaboration facile de listes de prix. La seconde est de permettre de passer à une révision majeure de système, pour laquelle des changements de structure de donnée nécessiterait une opération d'exportation-importation au niveau système. Ceci est une provision indispensable pour un système évolutif.

Il est de bonne tradition comptable de régulièrement faire quelques écritures dites de clôture et de tirer un bilan. Ces opérations faites, on considère que le journal des transactions antérieures est figé. Les écritures correspondantes n'ont alors plus d'intérêt pour la gestion courante. De plus une liste énorme ralenti le système. Il est donc utile d'éliminer les écritures qui ne sont plus d'actualité. La purge du journal permet cette opération. Notons, cependant que contrairement à bien d'autres système, cette opération est réversible puisque la purge du journal produit une version textuelle sous une forme qui peut être reprise par l'outil d'importation de donnée.

Les opérations d'import-export, peuvent éventuellement être utilisées dans des exercices de simulation. Dans ce cas, il est impératif de travailler dans un environnement de données strictement séparés de l'environnement d'exploitation.

Un éditeur de hiérarchie est associé à chaque catalogue. Il accessible par le bouton en forme de clef mécanique. La première ligne d'outil est semblable à celle des autres éditeurs. Seul un nouveau bouton(1) , permettant le tri alphabétique d'un groupe terminale, apparaît en plus.

Pour avoir accès à la liste des hiérarchies existantes, il suffit presser la touche retour (¿) dans le champs d'entête (2). Une liste (3) apparaît dans laquelle on peut sélectionner un élément. On peut aussi saisir directement le nom de la hiérarchie souhaitée.

Les hiérarchies de ABC, répondent au concept de partition. En conséquence, pour créer une nouvelle partie il faut définir au moins un élément inclus. Pour ce faire, on écrit d'abord le non de la nouvelle partie dans le second champs (1) de texte de cet éditeur. Puis il faut tire un élément ou une partie provenant du panneau inférieur ou un élément appartenant à la collection provenant d'une autre source. On lâche le contenu saisi dans le grand trou rond(2) à gauche de la nouvelle étiquette.

La nouvelle partie apparaît dans le panneau inférieur au plus haut niveau. On ensuite tirer cette partie pour la lâcher dans un partie de partie existante. On peut aussi définir une nouvelle étiquette et tirer la nouvelle partie dans le trou, round à nouveau, de la ligne d'édition de nouvelle partie. Dans ce cas le trou rond prend la forme de fente symbolisant une partie (ligne de séparation). Ceci montre que la partie en cours de définition ne peut contenir que d'autres parties.

Ce trou prend alors une forme correspondant au type d'entité reçu. Ceci assure que la partie créer sera homogène. Soit elle contiendra des élément de la collection, soit d'autre partie. On peut également tirer un ensemble d'éléments, provenant par exemple de la liste alphabétique de la collection. Lorsque l'on est satisfait des éléments placer dans cette nouvelle partie, on presse le bouton de confirmation (3) à droite de la nouvelle étiquette.

Il est ensuite possible de déplacer directement des parties ou des éléments dans le panneau inférieur au moyen du tirer & lâcher. Il faut noter ici que l'on ne peut déplacer ou supprimer la partie ``non classée''. Celle-ci est gérée automatiquement. Elle disparaît d'elle même dès que tous les éléments sont classés.

Le système supporte l'usage d'un lecteur de code à barres. Ceci se fait par une définition dans les préférences système (system). dans ce fichier on défini la variable "barcode_reader" avec pour valeur "stdin" si celui-ci est connectè au clavier ou le nom du port série (com1, com2 pour windows) (dev/ttyS0,... pour unix) si celui-ci est connecté à un tel port.

Avec une telle définition, le lecteur de code à barres est automatiquement connecté au champs de saisie du libellé de produit de l'éditeur de ligne du document qui à le contrôle des saisies. Ceci permet notamment de réaliser des postes spécialisés telle qu'une caisse ou un centre de réception.

Rappelons qu'un même produit peux avoir plusieurs synonymes (aliasses). Ceci permet, entre autre, de reconnaître des produits fabriquer et étiqueté par plusieurs manufactures.

L'administrateur système de la machine sur laquelle les données du système ABC sont stockées, peut réaliser certaines opérations normalement refusées. User de ces privilèges est dangereux. Il ne faut les utiliser qu'après mure réflexion.

Essentiellement, l'administrateur peut faire deux choses. En premier, il peut supprimer n'importe quel entité, appartenant à une collection quelconque. Cela se fait par`tirer-lacher' sur la corbeille.

D'autre part, l'administrateur peut forcer un changement d'état d'un document. Cette opération est réaliser en tapant un retour chariot `¿' sur le champs d'état. Un menu apparaît qui permet de choisir un état possible pour ce document. En choisissant parmi ceux-ci, on force cet état sans aucune action associée. Cette méthode, permet par exemple de forcer un document dans un état final `annulé'. Ceci permet de liquider un document que l'on ne peut faire évoluer conformément à la réalité suite à une faute de conception de l'automate associé à ce type de document. On peut ensuite, après avoir corrigé l'automate, créer un nouveau spéciment de document en partant de celui que l'on vient d'éliminer afin de poursuivre l'action dans de bonnes conditions. D'un point de vue des contrôles légaux cette solution est correct, car il reste une trace d'un document annulé ce qui peut aisément ce justifier, alors qu'il trou dans les références est plus gênant.

Chaque utilisateur peut choisir un dictionnaire qui contient les traductions des éléments de l'interface. Mais, au delà chacun peut modifier ce dictionnaire. Ceci se fait à l'aide d'une fenêtre graphique accessible depuis le panneau principal par le bouton .

Le bouton ``sélection'' déclenche le mécanisme de sélection. Un curseur en croix apparaît. Il suffit de le déplacer au dessus de l'élément graphique à modifier puis de presser à nouveau le bouton de sélection de la souris pour charger l'éditeur de traduction. Celui-ci travaille selon deux modes. Le mode générique ou le mode spécifique. Si le sélecteur générique est enfoncé, les traductions faites s'appliquent à tous les éléments portant la même identité sauf si une définition spécifique est trouvé pour un contexte donné. Le mode spécifique ne s'applique qu'à un élément dans un contexte. On peut ainsi décider que l'étiquette générique du bouton soit ``sortir'' mais que dans le contexte du panneau principale, son étiquette soit ``quitter l'application''.

Lorsque l'on a édité une traduction, il suffit de taper ¿ pour que la traduction prenne place dans le contexte de référence. Il faut cependant noter que l'effet générique n'est appliqué qu'au prochain lancement de l'application.

Au démarrage, le système charge les préférences de l'utilisateur, puis les préférences collectives aussi appelées préférences systèmes. Dans cet ordre, les préférences collectives prévalent sur les préférences individuelles. Si un utilisateur n'a pas de fichier propre de préférences, le système utilise un fichier situer dans les ressources standards. Le fichier de préférences est rechercher dans le répertoire de base de l'utilisateur. Ce fichier doit se nommer `.abcrc' sous UNIX et abc.txt sous Windows. On peut aussi définir un autre nom de fichier en ajoutant dans la ligne de commande une option: -preference=non_fichier. Cette façon de faire est d'ailleurs la seule valable sous Windows9X qui n'a pas de notion de répertoire de base d'un utilisateur.

Des exemples raisonnables et complets de fichier de préférences systèmes et individuels sont fournis dans la distribution.

Les préférences systèmes ne sont accessibles qu'aux manageurs. Elle sont groupées par groupes de nature analogue.

Notons ici que les fiches descriptives des adresses et des produits peuvent être étendues par des champs optionnels. Rappelons également que les champs supplémentaires des produits peuvent être utilisés pour dans les fonctions de vente dans les expressions algébriques.

ABC doit passer certaines commandes vers le système d'exploitation. Ces commandes, sont toutes faites au travers de fichiers de programmes de commandes. Ceci permet une adaptation facile a l'environnement et permet des personnalisations supplémentaires. Le système est distribué avec une version opérationnel de chacune des commandes nécessaires. Elle sont reprises en annexe avec un commentaire éventuel.

Nous supposons ici que le système fonction actuellement avec une base de donnée correspondant à un exemple fourni plus des données personnelles. Dans ce contexte voici une procédure à suivre globalement pour passer à la mise en service réel.

· Purger les documents jusqu'à cette même date. Pressez le bouton de suppression automatique si vous ne désirez pas repartir avec des numéro de références non nul.

· Quittez l'application et supprimez le fichier ``business.dmp'' dans votre répertoire de données.

Il faut ensuite importer votre état réel comptable. Si vous possédez un logiciel de comptabilité, il doit pouvoir vous fournir un fichier de texte qui comprend le nom et le solde de chaque compte. De plus la mise en page doit vous permettre de déduire les comptes positifs et négatifs (actif = +, passif = -). Pour certain logiciel vous trouverez dans le répertoire ``resources/tools'' un petit programme de conversion. Si par exemple vous utilisez ``winway'' , depuis un terminal tapez la commande:

Si votre logiciel ne correspond pas à l'un de ceux pour lesquels un tel filtre existe, il vous faudra faire un conversion manuel. Pour cela, prenez exemple sur le fichier d'importation ``import.txt'' qui à servi à créer votre environnement d'exercice. Il se trouve dans le répertoire de vos données ou sous ``resources/examples/*/import.txt''.

Il faut ensuite éditer le fichier que vous venez d'exportez depuis l'application ABC. Dans ce fichier de texte, vous remplacez la section des comptes par ceux que vous venez de préparer. Ensuite, dans ce fichier, vous supprimer les hiérarchies que vous n'utilisez pas et la section transactions.

La section document peut aussi être supprimée sauf si vous ne désirez repartir de numéros de référence particuliers. Si tel est le cas, Il faut garder un exemplaire de chaque document en état dit d'``archive''. Vous numérotez cette exemplaire avec la valeur initiale que vous souhaitez moins un.

Si vous n'avez pas supprimer toute les adresses, produits et devises inutiles, vous pouvez encore le faire maintenant. Cependant, dans ce contexte vous devez également supprimer manuellement, dans les hiérarchies, toutes références à une entité que vous supprimé.

Ce travail étant terminez, vous êtes prés a ré-importez vos données. Ceci peut se faire en appelant la programme de base ABC, puis en allant sous maintenance et importer. Mais il est plus confortable d'ouvrir un terminal et de lancer la commande:

<chemin d'accès>/import_abc <le fichier d'exportation modifier> <le répertoire de donnée>.

Il se peux que le programme d'importation détecte quelque erreurs dans votre fichier. Dans ce cas il ne produit aucun résultat à l'exception de messages d'erreur qui permettent de corriger le fichier source. Dès que l'importation est terminée, vous pouvez relancer le programme principal ABC. Vérifiez toutes vos données, surtout comptable. Si vous n'êtes pas satisfait, quittez à nouveau l'application, supprimez le fichier ``business.dmp'', et corriger votre fichier d'importation.

L'utilisateur, en particulier l'utilisateur privilégier, doit spécifier des nom de fichier et leur chemin d'accès. C'est notamment le cas pour les modèles faisant appel à des commandes au système d'exploitation. Ces spécification peuvent évidemment se faire en chemins absolu. Cependant cette méthode est trop rigide car elle pose des problèmes en cas de changement de configuration des machines. Ainsi plusieurs methode d'adressage symbolique ou relatifs ont été ajouté.

· une variable d'environnement. Ceci se fait en placant un caractère `$' devant le non d'un variable d'environnement.

Pour placer un résultat dans le même répertoire que celui du fichier de donnée:

Note: le caractère `/' est le séparateur pour Unix (Linux). Le caractère `\' est celui de DOS et donc de Windows. Cependant, ABC traduit automatiquement ce paramètre en fonction de la plate-forme en action.

Voici quelques exemples de modèles de documents. Les textes présentés sont ceux obtenus en pressant la touche d'impression-filtrage de l'éditeur de modèle.

../common/t/grammar.txt: Fichier ou répertoire inexistant../common/t/grammar.txt: Fichier ou répertoire inexistant

1Latex est un produit du monde académique, libre à la manière de Linux, et disponible sur toutes les plateformes. A l'origine, la version TeX à été concue par Donald Knuth.

Abstraction, Fbg de l'hôpital 18, 2000 Neuchâtel, Suisse.

Tél: +41 725 04 93 E-mail: info@abstraction.ch