MELUSINE / spécifications

SOSNOTAIRES.COM
et Mélusine

SPECIFICATIONS

Projet I
Système de traitement des actes

Le système n'est pas basé sur une matrice ou un canevas à trous, faisant appel à des macros, mais sur la réalisation de blocs entiers et autonomes, que l'on peut décomposer ainsi :

bloc 1	éléments constitutifs de l'acte	vendeur acquéreur désignation origine de propriété (effet relatif "amélioré") jouissance prix déclarations fiscales plus-values
bloc 2 (facultatif)	clauses accessoires	PPD réserve d'usufruit etc...
bloc 3	variables	formalités préalables (compromis - certificats - préemption ...) présence - énonciation des pouvoirs annexes
bloc 4	constantes (en fonction du type d'acte)	accord des parties conditions garanties paiement du prix clôture
bloc 5	origine	développement de l'origine de propriété origine antérieure (trentenaire)

       Observations
       Ce plan correspond à un acte de vente. Mais il est transposable pour pratiquement tout type d'acte (bail, emprunt ...).
       Il s'inspire du projet d'acte publié sur ce site, dans le dossier acte interactif.
       Un bloc peut parfaitement servir pour plusieurs actes (en cas d'actes en série ou répétitifs).
       Le montage n'est destiné à être effectué qu'en finale et au dernier moment. Il n'est pas indispensable de le sauvegarder en sa forme finale (=gain de place).
       On peut même envisager d'éditer les blocs séparément (en veillant uniquement au numérotage des pages). Inutile de tout rééditer pour une petite modification dans un bloc, comme cela est trop souvent le cas, avec des mises en page plus ou moins réussies.

Projet II
Automatisation du système

       Le projet I fait appel à un assemblage manuel. Même s'il peut suffire et n'est pas très compliqué à réaliser, le besoin se fera vite sentir, d'une assistance au montage et à l'assemblage.
       C'est le rôle d'un programme, qui pourra s'étoffer petit à petit.
       D'un simple canevas gérant les blocs, en fonction du type de dossier, il pourra évoluer vers une gestion simplifiée des dossiers.
       Le canevas pourra être établi par un simple traitement de texte, mais il sera nécessaire de passer par la programmation pour tout le reste. Delphi semble parfaitement adapté à la tâche.
       Evolution
       Le but à moyen ou long terme, est de fonctionner en réseau, éventuellement en mode client/serveur, ou mieux par le web et à distance. Peut-être faudra t'il faire le choix d'un autre langage (PHP?), ou associer plusieurs langages.
       Le Code source devra être structuré, clair et facilement compréhensible, afin d'en permettre l'évolution par d'autres programmeurs que le ou les concepteurs d'origine.
       Le type de fichiers supports devra être choisi (séquentiel indexé "maison", ou base de données -MySql?-).

Projet III
Développement de la norme XML

       La norme XML sera abordée sous 3 formes :
       création de fiches de type de document (DTD)
       Le XML autorise la création de son propre méta langage, en fonction de ses besoins. Par exemple, il est possible de créer une fiche, en vue de retraitements ultérieurs, avec utilisation des balises <vendeur>...</vendeur>, <acquereur>...</acquereur>, etc... (et possibilité de subdiviser s'il y en a plusieurs).
       Il est ainsi possible d'en créer autant que l'on veut. Mais cela n'est pas forcément souhaitable, et il semblerait préférable d'en limiter le nombre, et de n'en créer que le minimum, répondant au maximum de besoins, par exemple <ancienptaire>...</ancienptaire>, <nouveauptaire>...</nouveauptaire> ...
       Tous autres noms sont acceptés, mais il faut essayer de se limiter à des noms courts et faciles à mémoriser.
       Il faut avoir présent à l'esprit, que le but est de retraiter et récupérer le maximum de données, afin de les utiliser avec tous les autres programmes en service dans l'office (ou en ligne sur le web).
       création de feuilles de style (XSL)
       Le XML autorise également la création d'autant de feuilles de style que l'on en a besoin. Ce sont des fichiers précisant comment les données doivent être présentées ou éditées. Cela peut être une sortie papier au format RTF, PDF ou autre, une sortie en HTML pour publication sur le web. On peut même envisager des sorties sonores ou médias. Là aussi, on créée soi-même son propre meta langage, en fonction de ses besoins, et toujours au moyen de balises, par exemple <gras>...</gras>, <souligne>...</souligne>, etc...
       transfert de données
       L'intérêt du XML est de permettre l'échange de données entre programmes différents, et à priori incompabibles.
       Mais pour que cela fonctionne, il faut que les données soient "encapsulées" par le programme émetteur, et récupérables et compréhensibles par le programme receveur. Là encore, c'est la tâche des balises.
       Ainsi, un programme de taxe peut parfaitement récupérer le prix et le type d'acte en provenance du programme de traitement d'actes, pour effectuer la taxe, et la transmettre ensuite à la comptabilité. Le XML le permet, même si les programmes n'ont pas été réalisés par le même concepteur, et reposent sur des structures de fichiers différentes (mais à la condition que les programmes soient conçus pour gérer le XML).

Observations

Ces spécifications ne constituent qu'une base de travail.
Elles sont appelées à être complétées et affinées, au fur et à mesure de l'avancement des travaux, ou des observations ou suggestions qui seront faites, pratiques ou techniques.