ABC
Made in Eiffel
Privilèges de l'administrateur système
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.
ABC peut:
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.
Au démarrage, le système présente toujours un petit panneau de contrôle.
|
La barre d'outils comprend: 1. Le menu des classeurs des documents. 2. Le menu des éditeurs de document. 4. Les adresses 5. Les produits 6. Les mouvements de stock 7. Le journal 8. Sauvegarde de la configuration 9. Le Traducteur d'interface 10. Les Préférences 11. Les outils de maintenance 12. L'aide |
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.
L'éditeur de hiérarchie est expliquer dans la section maintenance.
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.
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.
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:
export_host: "localhost"
export_port: 10000
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.
import_port: 10000
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.
Les variables disponible pour expressions ou les fonctions externes sont:
Exemple
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:
= PF*¬promotion + promotion/SP
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 d'action possible.
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.
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.
Commande: 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.
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 chronologiquements 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é.
Précondition: le document est ouvert.
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''1 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.
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.
Entrées externes
Les textes rédigés à l'attention d'ABC par un programme extérieur doivent respecter la grammaire définie ici.
Identifiant `:' valeur
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.
$$$ q=+$quantity$+ ; pu=+$price$+
print "net:", q*pu*(1-(0.0505+0.015)), "\n"
print "line_100: ", q*pu, " AVS_PATRON" , "\n"
print "line_101: ", q*pu, " AVS_EMPLOYE" , "\n"
print "line_102: ", q*pu, " AC_PATRON" , "\n"
print "line_103: ", q*pu, " AC_EMPLOYE" , "\n"
halt
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.
Importer des données
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.
Exporter des données.
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.
Purger le journal
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.
Traduction de l'interface
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.
Préférences
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.
Commandes externes.
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.
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:
perl winway votre_fichier_rapport_winway > comptes.txt
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>.
Le chemin d'accès est le même que pour le programme principal.
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.
language: french
--Colors & Font & geometry
---------------------------
drag_corrector: 3
scrolling_list_font: "-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1"
label_font: "-adobe-courier-bold-r-normal--12-120-75-75-m-70-iso8859-1"
default_font: "-adobe-courier-bold-r-normal--12-120-75-75-m-70-iso8859-1"
read_write_field_color:
must_read_write_field_color:
read_only_field_color:
background_color:
label_background_color:
menu_color:
scroll_list_color:
default_color: grey
field_height:
tool_bar_widget_distance : 1
vertical_label_offset: 7
vertical_space_between_fields: 0
horizontal_space_between_fields: 0
--Other
check_spelling: true
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.
LETTER
state_control:
start_state: brouillon
états:
brouillon:
fermer:
action: CLOSE_ACTION
destination: pret
pret:
envoyer:
action: SEND_ACTION
mail: False
poste: False
fax: False
or_mode: False
automatic: False
copies: 0
destination: fait
archive:
fait:
private_type: lettre
SUPPLIER_DOC
state_control:
start_state: brouillon
états:
brouillon:
accepte:
action: COMPOSITE_ACTION
sequences:
CLOSE_ACTION
SEND_ACTION
mail: False
poste: True
fax: False
or_mode: False
automatic: True
copies: 1
ANALYTIC_BUY_ACTION
IN_DUTY_ACTION
BUY_ACCOUNTING_ACTION
WAIT_ACTION
start_state: acceptée
event: expire
delai: 10
destination: acceptée
archive:
payée:
acceptée:
expire:
action: COMPOSITE_ACTION
sequences:
GENERATE_ACTION
generated_document: paiement
PAYMENT_CREANCIER_ACTION
destination: payée
private_type: facture_fournisseur
duty_free: False
fix_duty_mode: False
currency_rate: 0
IMPORT_TOP : [CURRENCY_LIST_B] [ACCOUNT_LIST_B] [SALE_FUNCTION_LIST_B] [ADDRESS_LIST_B] [PRODUCT_LIST_B] [FOLDER_LIST_B] [TRANSACTION_LIST_B] END
CURRENCY_LIST_B : CURRENCIES [CURRENCY_LIST]
CURRENCY_LIST : CURRENCY_DESCR ..
CURRENCY_DESCR : RECORD_LABEL : CURRENCY_SYMBOLE NUMERIC_VALUE NUMERIC_VALUE [COMMENT_DESCR]
RECORD_LABEL : BOUNDED_IDENTIFIER | SIMPLE_IDENTIFIER | QUOTED_IDENTIFIER
CURRENCY_SYMBOLE : SYMBOL | CURRENCY_SPECIAL
COMMENT_DESCR : COMMENT = DESCRIPTION
DESCRIPTION : BOUNDED_STRING | QUOTED_STRING | VALUE_IDENTIFIER
ACCOUNT_LIST_B : ACCOUNTS [ACCOUNT_LIST] [PARTITION_LIST_B]
ACCOUNT_LIST : ACCOUNT_TYPE ..
ACCOUNT_TYPE : POSITVE_ACCOUNT_DESCR | NEGATIVE_ACCOUNT_DESCR | POSITIVE_ONLY_ACCOUNT_DESCR | NEGATIVE_ONLY_ACCOUNT_DESCR
POSITVE_ACCOUNT_DESCR : RECORD_LABEL : + [NUMERIC_VALUE] [COMMENT_DESCR]
NEGATIVE_ACCOUNT_DESCR : RECORD_LABEL : - [NUMERIC_VALUE] [COMMENT_DESCR]
POSITIVE_ONLY_ACCOUNT_DESCR : RECORD_LABEL : >= [NUMERIC_VALUE] [COMMENT_DESCR]
NEGATIVE_ONLY_ACCOUNT_DESCR : RECORD_LABEL : <= [NUMERIC_VALUE] [COMMENT_DESCR]
PARTITION_LIST_B : PARTITIONS [PARTITION_LIST]
PARTITION_LIST : SUBPARTITION_TYPE ..
SUBPARTITION_TYPE : PARTITION_DESCR | TERMINAL_PARTITION_DESCR
PARTITION_DESCR : ITEM_LABEL : { PARTITION_LIST }
ITEM_LABEL : QUOTED_STRING | VALUE_IDENTIFIER | BOUNDED_STRING
TERMINAL_PARTITION_DESCR : ITEM_LABEL : [ MEMBER_LIST ]
MEMBER_LIST : DESCRIPTION "," ..
SALE_FUNCTION_LIST_B : SALE_FUNCTIONS [SALE_FUNCTION_LIST]
SALE_FUNCTION_LIST : SALE_FUNCTION_SUBTYPE ..
SALE_FUNCTION_SUBTYPE : DISCOUNT_SALE_F_DESCR | COMPLEX_SALE_F_DESCR
DISCOUNT_SALE_F_DESCR : RECORD_LABEL : NUMERIC_VALUE NUMERIC_VALUE [NUMERIC_VALUE] [COMMENT_DESCR]
COMPLEX_SALE_F_DESCR : RECORD_LABEL : DESCRIPTION
ADDRESS_LIST_B : ADDRESSES [ADDRESS_LIST] [PARTITION_LIST_B]
ADDRESS_LIST : ADDRESS_DESCR ..
ADDRESS_DESCR : RECORD_LABEL : ADDRESS_TYPE ADDRESS_IDENT_DESCR POST_ADDRESS_DESCR [PHONE_NUMBER] [FAX_NUMBER] [EMAIL] [MEMBER_LIST_B] [OPTION_LIST_B] [COMMENT_DESCR]
ADDRESS_TYPE : RESERVED_ADDRESS_SHORTENING | RESERVED_ADDRESS_WORD | BOUNDED_ADDRESS_TITLE
ADDRESS_IDENT_DESCR : DESCRIPTION DESCRIPTION DESCRIPTION DESCRIPTION
POST_ADDRESS_DESCR : DESCRIPTION DESCRIPTION DESCRIPTION DESCRIPTION
MEMBER_LIST_B : [ MEMBER_LIST ]
OPTION_LIST_B : OPTIONS = [ OPTION_LIST ]
OPTION_LIST : OPTION_DESCR "," ..
OPTION_DESCR : DESCRIPTION : DESCRIPTION
PRODUCT_LIST_B : PRODUCTS [PRODUCT_LIST] [PARTITION_LIST_B]
PRODUCT_LIST : PRODUCT_DESCR ..
PRODUCT_DESCR : RECORD_LABEL : [CURRENCY_SYMBOLE] NUMERIC_VALUE DESCRIPTION SALE_FUNCTION_TYPES NUMERIC_VALUE NUMERIC_VALUE [NUMERIC_VALUE] [NUMERIC_VALUE] [NUMERIC_VALUE] DESCRIPTION DESCRIPTION [COMMENT_DESCR]
SALE_FUNCTION_TYPES : SALE_FUNCTION_ID | SALE_FUNCTION_VALUE
FOLDER_LIST_B : FOLDERS [FOLDER_LIST]
FOLDER_LIST : FOLDER_CONTENT ..
FOLDER_CONTENT : FOLDER_TYPE [ [DOCUMENT_LIST] ]
FOLDER_TYPE : CUSTOMER_DESCR | SUPPLIER_DESCR | LETTER_DESCR | PAYMENT_DESCR
CUSTOMER_DESCR : RECORD_LABEL : SALE_DOC REFERENCE_TYPE [COMMENT_DESCR]
REFERENCE_TYPE : YEAR_NUMERIC_REF_DESCR | NUMERIC_REF_DESCR
YEAR_NUMERIC_REF_DESCR : YEAR_NUMERIC_REF DESCRIPTION
NUMERIC_REF_DESCR : NUMERIC_REF DESCRIPTION
SUPPLIER_DESCR : RECORD_LABEL : SUPPLIER_DOC REFERENCE_TYPE [COMMENT_DESCR]
LETTER_DESCR : RECORD_LABEL : LETTER REFERENCE_TYPE [COMMENT_DESCR]
PAYMENT_DESCR : RECORD_LABEL : PAYMENT REFERENCE_TYPE [COMMENT_DESCR]
DOCUMENT_LIST : DOCUMENT_DESCR ..
DOCUMENT_DESCR : RECORD_LABEL : DESCRIPTION [MEMBER_LIST_B] DESCRIPTION DOCUMENT_BODY
DOCUMENT_BODY : LIVE_DOCUMENT | ARCHIVE_DOCUMENT
LIVE_DOCUMENT : [DATE_TEXT] TAGGED_TEXT_LIST_B [PRODUCT_DOC_DESCR]
TAGGED_TEXT_LIST_B : [ [TAGGED_TEXT_LIST] ]
TAGGED_TEXT_LIST : TAGGED_TEXT_DESCR "," ..
TAGGED_TEXT_DESCR : DESCRIPTION : DESCRIPTION
PRODUCT_DOC_DESCR : DOCUMENT_VALUE_SUMMERY DOC_LINE_LIST_B [NUMERIC_VALUE]
DOCUMENT_VALUE_SUMMERY : CURRENCY_SYMBOLE NUMERIC_VALUE NUMERIC_VALUE [NUMERIC_VALUE]
DOC_LINE_LIST_B : [ DOC_LINE_LIST ]
DOC_LINE_LIST : DOC_LINE_DESCR "," ..
DOC_LINE_DESCR : NUMERIC_VALUE DESCRIPTION NUMERIC_VALUE NUMERIC_VALUE
ARCHIVE_DOCUMENT : DESCRIPTION
TRANSACTION_LIST_B : TRANSACTIONS [TRANSACTION_LIST]
TRANSACTION_LIST : TRANSACTION_DESCR ..
TRANSACTION_DESCR : DATE_TEXT ACCOUNT_ID ACCOUNT_ID DESCRIPTION NUMERIC_VALUE
ACCOUNT_ID : QUOTED_STRING | VALUE_IDENTIFIER | BOUNDED_STRING
#!/usr/bin/perl
# lock
# This script is intended to lock the conccurent access to the data.
# DON'T SCRATCH-IT.
use Fcntl ':flock'; # import LOCK_* constants
open(DATA, @ARGV[0] . ".owner");
flock(DATA,LOCK_EX+LOCK_NB);
$success = $?;
if ($success eq 0) {
if (!(-e @ARGV[0]. ".owner")) {
system('whoami > ' . @ARGV[0] . '.owner');
$success=$?;
}
elsif ( -o @ARGV[0] . ".owner") {
#print "Auto-goal\n";
$success=2;
}
else {
#print "locked by some other person\n";
$success=1;
};
flock(DATA,LOCK_UN);
close(DATA);
}
else {
#print "write access\n";
$success=3;
};
exit ($success);
#!/usr/bin/perl
# unlock
# Unlock data file.
# DON'T SCRATCH IT
system('rm ' . @ARGV[0] . '.owner');
exit ($?);
../../resources/perl/bin/accounter: Fichier ou répertoire inexistant
../../resources/perl/bin/bc_translate_ABC: Fichier ou répertoire inexistant
../../resources/perl/bin/check_login_user: Fichier ou répertoire inexistant
#!/usr/bin/perl
system ('test `cat '.@ARGV[0].' | aspell -a -d francais | grep "^[#&]" | wc -l` -eq 0');
$status=$?/256;
exit($status);
#!/bin/sh
test -e /usr/bin/xterm && terminal=/usr/bin/xterm
test -e /usr/bin/konsole && terminal=/usr/bin/konsole
$terminal -e aspell check --lang=francais $1
status=$?/256;
#!/usr/bin/perl
# collection_filter
system ("umask 0");
$, = ' '; # set output field separator #--UNIX
$\ = "\n"; # set output record separator #--UNIX
$fn = @ARGV[0];
line: while (<>) { #--UNIX
if (/passif[ ,\t]+[+,-.,0-9]+/) { #--UNIX
system ('perl '."$ENV{'ABC_DELIVERY'}".'/resources/perl/bin/bilan.pm ' . $fn . '> /tmp/'."$ENV{'USER'}".'/bilan.html'); #--UNIX
system (''.' /tmp/'."$ENV{'USER'}".'/bilan.html'); #--UNIX
$status=$?/256; #--UNIX
exit($status); #--UNIX
} #--UNIX
if (/partition [:, ,\t]+TVA|partition [:, ,\t]+VAT/) { #--UNIX
system ('perl '."$ENV{'ABC_DELIVERY'}".'/resources/perl/bin/duty.pm ' . $fn . '> /tmp/'.$ENV{'USER'}.'/duty.txt'); #--UNIX
system ("$ENV{'TEXT_VIEWER'}".' /tmp/'."$ENV{'USER'}".'/duty.txt'); #--UNIX
$status=$?/256; #--UNIX
exit($status); #--UNIX
} #--UNIX
} #--UNIX
print ("$ENV{'TEXT_VIEWER'}".' '.$fn."\n");
system ("$ENV{'TEXT_VIEWER'}".' '.$fn);
$status=$?/256;
exit($status);
#!/usr/bin/perl
# editor_filter
# Display the edited component
system ("$ENV{'TEXT_VIEWER'}".' ' . @ARGV[0] );
$status=$?/256;
exit($status);
#!/usr/bin/perl
# specify the attachments .
$result = "";
$i = 0;
while ($i < $#ARGV + 1) {
open(FILE,@ARGV[$i]);
($Fld1) = readline(<FILE>);
# print "read file type for " . @ARGV[$i] ."\n";
# print "read file first line: " . $Fld1 ."\n";
@line1 = split(/ /,$Fld1);
@fn = split(/[\/\\]/, $ARGV[$i], 9999);
$fn = @fn[$#fn];
# print "fn: " . $fn ."\n";
if ($line1[0] eq "%!PS-Adobe-3.0") {
$result=$result." ".@ARGV[$i];
}
elsif ($line1[1] eq "html") {
system('html2ps '.@ARGV[$i].' > /tmp/'.$fn);
$result=$result." /tmp/".$fn;
}
elsif ($line1[1] eq "jpg") {
@fn=split(/[\.]/, $fn, 9999).".pbm";
system('convert '.$ARGV[$i].' pbm:/tmp/'.$fn[1]);
$result=$result." /tmp/".$fn;;
}
elsif ($line1[1] eq "gif") {
@fn=split(/[\.]/, $fn, 9999).".pbm";
system('convert '.$ARGV[$i].' pbm:/tmp/'.$fn[1]);
$result=$result." /tmp/".$fn;;
}
else {
$result=$result." ".$ARGV[$i];
};
$i++;
}
print $result;
../../resources/perl/bin/get_user_identity: Fichier ou répertoire inexistant
../../resources/perl/bin/html_document_filter: Fichier ou répertoire inexistant
#!/usr/bin/perl
# spool_mail
# Send mail trought the MIME multimedia $MAILER mail utility.
# Check il you have the $MAILER package.
# If not install them.
# $1 is the target E-mail address. $2 is the html main text file xxx.htm.
# following arguments are attachment files.
# PATH=$PATH:`echo $0 | awk 'BEGIN{FS="/"}{ll=length($NF);print substr($0,1,length($0)-ll-1)}'`
umask 000;
chdir '/tmp';
$from="EntrepriseEmail";
$subject="SUBJECT" ; #"`cat $2| gawk '/subject/ {sub(/subject:/,""); gsub(/ /,"_");print}'`"
$to=$ARGV[0];
$text=$ARGV[1];
shift; shift; # skip arguments 1 and 2
$i = 0;
while ($i <= $#ARGV) { $args = $args." ".$ARGV[$i], $i++}
#print "attachments ".$args."\n";
$attach_cmd = "$ENV{'ABC_DELIVERY'}".'/resources/perl/bin/mail_attachments '.$args;
#print "attachments command ".$attach_cmd."\n";
system ('/usr/bin/metasend'.' -b -S 10000000 -e "base64" -s '.$subject.' -F '.$from.' -t "'.$to.'" -f '.$text.' -m text/html '.`$attach_cmd`);
$status=$?/256;
exit($status);
#!/usr/bin/perl
eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
if $running_under_some_shell;
# this emulates #! processing on NIH machines.
# (remove #! line above if indigestible)
eval '$'.$1.'$2;' while $ARGV[0] =~ /^([A-Za-z_0-9]+=)(.*)/ && shift;
# process any FOO=bar switches
$[ = 1; # set array base to 1
for ($i = 1; $i <= ($ARGV[0]); $i++) {
system('' . ' /print("'.$ARGV[2].'")');
}
$status=$?/256;
exit($status);
#!/usr/bin/perl
system ('gswin32c -dSAFER -dNOPAUSE -sDEVICE=pcx256 -sOUTPUTFILE='.$ARGV[1].' -q - <'.$ARGV[0]);
$status=$?/256;
#!/usr/bin/perl
# Translate html version of a document into it's Poscript version
#
system ("$ENV{'ABC_DELIVERY'}".'/resources/linux/bin/html2ps -f '."$ENV{'ABC_DELIVERY'}".'/resources/linux/lib/html2ps/html2psrc '. $ARGV[0] ." > ".$ARGV[1]);
$status=$?/256;
exit($status);
../../resources/perl/bin/import_data: Fichier ou répertoire inexistant
../../resources/perl/bin/is_user_root: Fichier ou répertoire inexistant
#!/usr/bin/perl
# specify the attachment for $MAILER.
$result="";
$i = 0;
while ($i < $#ARGV + 1) {
open(FILE,@ARGV[$i]);
($Fld1) = readline(<FILE>);
# print "read file type for " . @ARGV[$i] ."\n";
# print "read file first line: " . $Fld1 ."\n";
@line1 = split(/ /,$Fld1);
if ($line1[0] eq "%!PS-Adobe-3.0") {
$m="application/postscript";
}
elsif ($line1[1] eq "html") {
$m="text/html";
}
elsif ($line1[1] eq "doc") {
$m="aplication/msword";
}
elsif ($line1[1] eq "jpg") {
$m="image/jpeg";
}
elsif ($line1[1] eq "gif") {
$m="image/gif";
}
else {
$m="text/plain";
};
@Fld = split(/[\/\\]/, $ARGV[$i], 9999);
$d= $Fld[$#Fld];
# print "d: ".$d."\n";
$fx=' -n -m '.$m.' -D '.$d.' -f '.$ARGV[$i];
# print "fx1: ".$fx."\n";
$result=$result.$fx;
$i++;
}
print ($result);
../../resources/perl/bin/manager: Fichier ou répertoire inexistant
#!/usr/bin/perl
system('echo " /V1 /NMANAGER /SNFAX /T1 /FI'.%2.' /AA | '.%1.' | " > fax.tmp');
system(''.' /Ifax.tmp');
$status=$?/256;
exit($status);
../../resources/perl/bin/ps_document_filter: Fichier ou répertoire inexistant
#!/usr/bin/perl
#print faxing
$to=$ARGV[0]; #--UNIX
$text=$ARGV[1]; #--UNIX
shift; shift; # skip arguments 1 and 2 #--UNIX
$i = 0; #--UNIX
while ($i <= $#ARGV) { $args = $args." ".$ARGV[$i], $i++} #--UNIX
#print "attachments ".$args."\n"; #--UNIX
$attach_cmd = "$ENV{'ABC_DELIVERY'}".'/resources/perl/bin/fax_attachments '.$args; #--UNIX
system ("$ENV{'FAXER'}".' '.$to.' '.$text.' '.$attach_cmd); #--UNIX
$status=$?/256; #--UNIX
exit($status); #--UNIX
#!/bin/sh
umask 000
n=$1; shift;
lpr -\#$n $* # > /dev/null
#!/usr/bin/perl
#
#
#
system("$ENV{'RTF_VIEWER'}" . " @ARGV[0]");
$status=$?/256;
exit($status);
#!/usr/bin/perl
# spool_mail
# Send mail trought the MIME multimedia $MAILER mail utility.
# Check il you have the $MAILER package.
# If not install them.
# $1 is the target E-mail address. $2 is the html main text file xxx.htm.
# following arguments are attachment files.
# PATH=$PATH:`echo $0 | awk 'BEGIN{FS="/"}{ll=length($NF);print substr($0,1,length($0)-ll-1)}'`
umask 000;
chdir '/tmp';
$from="EntrepriseEmail";
$subject="SUBJECT" ; #"`cat $2| gawk '/subject/ {sub(/subject:/,""); gsub(/ /,"_");print}'`"
$to=$ARGV[0];
system ('echo Seen attachments > '.'$SCRATCH/'.'seeatt.txt');
$text='$SCRATCH/'.'seeatt.txt';
shift; # skip arguments 1 and then put every thing in attachment even the real text
$i = 0;
while ($i <= $#ARGV) { $args = $args." ".$ARGV[$i], $i++}
#print "attachments ".$args."\n";
$attach_cmd = "$ENV{'ABC_DELIVERY'}".'/resources/perl/bin/mail_attachments '.$args;
system ("$ENV{'MAILER'}".' -b -S 10000000 -e "base64" -s '.$subject.' -F '.$from.' -t "'.$to.'" -f '.$text.' -m text/html '.`$attach_cmd`);
$status=$?/256;
exit($status);
#!/usr/bin/perl
eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
if $running_under_some_shell;
# this emulates #! processing on NIH machines.
# (remove #! line above if indigestible)
eval '$'.$1.'$2;' while $ARGV[0] =~ /^([A-Za-z_0-9]+=)(.*)/ && shift;
# process any FOO=bar switches
$[ = 1; # set array base to 1
for ($i = 1; $i <= ($ARGV[0]); $i++) {
system("$ENV{'RTF_VIEWER'}" . ' -Mprint '.$ARGV[2]);
}
$status=$?/256;
exit($status);
#!/usr/bin/perl
system ('gswin32c -dSAFER -dNOPAUSE -sDEVICE=pcx256 -sOUTPUTFILE='.$ARGV[1].' -q - <'.$ARGV[0]);
$status=$?/256;
#!/usr/bin/perl
#!/usr/bin/perl
if (@ARGV[2] == "a") {
$r=1;
$d = time;
$d1 = 946681200 ; # date --date '01/01/2000' +%s
$d2 = 978303600 ; # date --date '01/01/2001' +%s
if (( $d1 < $d ) && ( $d < $d2 )) {$r=0.5};
print $r ;
}
else {print "1"} ;
exit 0;
../../resources/perl/bin/show_archive_filter: Fichier ou répertoire inexistant
#!/usr/bin/perl
$old=$ARGV[0];
$new=$ARGV[1];
shift;
shift;
while ($i < $#ARGV + 1) {
# print "new file " .$i." " .$ARGV[$i]."\n";
open(FIL_IN,$ARGV[$i]);
open(FIL_OUT,">".$ARGV[$i].".tmp");
select(FIL_OUT);
while(<FIL_IN>){
s/$old/$new/;
print ;
}
close (FIL_IN);
close (FIL_OUT);
rename ($ARGV[$i].".tmp",$ARGV[$i]);
$i++;
};
$status=$?/256;
../../resources/perl/bin/valid_email_address: Fichier ou répertoire inexistant
../../resources/perl/bin/valid_phone_number: Fichier ou répertoire inexistant
../../resources/perl/bin/valid_post_address: Fichier ou répertoire inexistant
../../resources/perl/bin/valid_post_address: Fichier ou répertoire inexistant