Options de recherche (Page 5 de 6)

D'accord avec Gérard, comme je l'ai déjà expliqué par mél perso. On n'est pas au supermarché, donc les prix se terminant par 9, c'est pour le caddie, pas pour le service

Pour le prix, j'ai aussi proposé à André de l'associer à la version majeure. Version 3 expert : 90 €. Future version 4 expert : plus cher (mais pas trop !), car plus de fonctions. Passage de la version 3 à 4 : la différence de prix entre les deux.

Mais pour cela, il faut une clé d'activation liée à la version majeure...

André:

"Le contrat d’entretien doit faire partie des grandes nouveautés ; avec lui viennent de nouveaux fichiers dont la liste des bâtiments, des contrats, des enquêtes… et bien sûr les travaux."

MFLD:

"Sur le sujet de l'extension de la gestion des travaux au delà du seul aspect comptable (automatisation du carnet d'entretien), c'est un axe intéressant, mais encore une fois, je ne suis pas persuadé que ce soit une priorité."

André:

"Pour les fusions et génération avec Open Office : je m’y étais engagé, j’ai laissé trainé mais OK, ça sera opérationnel d’ici quelques semaines. J’ai récupéré quelques bouts de code et les premiers essais sont prometteurs malgré les différences et particularités de Open Office. Pour le moment je suis encore sur la version 3.4 mais je pense que ça sera compatible avec la version 4.0, il faudra également que je vérifie entre Apache Open Office et Libre Office mais ça ne devrait pas poser trop de problèmes."

MFLD:

"Pour les exportations vers Open Document, ce serait un plus, mais cela m'apparait comme une basse priorité, tout simplement parce que la base installée de vos clients est probablement majoritairement en MS Office. Je pense que cet axe de développement serait plus à envisager sur la base d'un partenariat que dans votre feuille de route. D'autant plus que les "Free Office" s'interfacent avec MS Office, et que la réciproque commence à se faire."

MFLD:

"Reste l'évolution de la gestion des tiers... là réside à mon avis la priorité dans notre discussion pour améliorer la conception du produit et lui redonner de la souplesse en terme d'application pour qu'il puisse attaquer le segment des grosses copropriétés.

Je crois comprendre dans votre prototypage que vous êtes parti uniquement sur la notion de "type de tiers" directement comme attribut de ce tiers. Cela m'apparait comme une limitation. En effet, j'ai le cas par exemple d'un tiers dans ma copro qui est à la fois propriétaire occupant de son logement, mandataire d'une indivision successorale propriétaire d'un autre logement loué, et associé dans une SCI propriétaire de plusieurs lots formant un cabinet médical (ouf !).

A vu de cet exemple, il m'apparait que le type de tiers, attribut de ce tiers isolé, n'est pas suffisant, et qu'il faut ajouter un attribut dans son association avec le lot.

Pour respecter la terminologie de votre prototype, je vous propose donc deux notions différentes : le type du tiers qui ne concerne que le tiers sur sa forme juridique (particulier, entreprise, etc), et le rôle du tiers (propriétaire, locataire, mandataire, etc) dans sa relation avec le lot.

Qu'en pensez-vous ?"

MFLD:

"Distribution:

Il est plus rapide pour moi de faire une requête sur ma base annexe, en triant par rue et numéro de bâtiment, que d'affecter des numéros d'ordres par copropriétaire. Ce point rejoint celui de la structure de la base, exposé plus loin.

Structure de base:

En fait, le principal reproche que je ferais sur la conception actuelle de ValCompta porte sur la gestion des lots et des tiers. Par exemple, il ne me semble pas logique que l'adresse d'un lot soit dans la table des copropriétaires, puisque cette adresse est lié au lot et ne change pas en cas de mutation.

Autre exemple, il manque un onglet pour les agences ou les mandataires, et rien n'est prévu pour la gestion des associés.

Je suis obligé de retravailler les adresses pour rediriger les courriers vers les agences de location ou les quelques mandataires (succession ou tutelle).

Dans ma base annnexe, j'ai le schéma suivant en trois parties:

TIERS
- Table des tiers (copro, locataire, agence, founisseur), avec les adresses, les téléphones, etc.

LOTS
- Table des rues
- Table des bâtiments, dont le n° dans la rue
- Table des lots, avec leur localisation dans le bâtiment (étage, coté, numéro de porte, etc)

AFFECTATIONS
- Table des affectations TIERS <-> LOTS avec un champ qui spécifie la nature de l'affectation (propriétaire, locataire, gérant, etc), et un indicateur pour le propriétaire occupant (pour avoir directement son adresse sans saisie)

Auparavant la table des affectations contenait deux champs (date entrée, date sortie), mais je les ai retiré comme expliqué plus haut, car l'historisation n'est pas nécessaire.

Avoir une table séparée pour les bâtiments me permet également d'automatiser le calcul des clés de répartition par bâtiment collectif.

Si j'avais mis les fournisseurs également dans la table des tiers, c'était en prévoyange d'une numérotation des comptes en deux clés : le préfixe suivant la nomenclature, et le suffixe avec le numéro du tiers. Exemple : 401.1024 avec 1024 étant le numéro du tiers EDF, ou 450.124, où 124 est le numéro du tiers copro.

Cela me permettait d'éviter de gérer des coordonnées dans deux tables différentes "copros" et "fournisseurs", et d'unifier le code et l'interface utilisateur gérant ces coordonnées (la partie "annuaire" de l'application).

Cela permet également d'éviter d'avoir comme aujourdhui un nom de copropriétaire d'un coté, qui n'est pas forcémment le même que l'intitulé du compte."

André:

"Beaucoup de choses dans votre mail, je commence par le moins bon (pour moi) ; voilà que vous me faites douter sur l’historisation. Je trouvais que l’affectation sans notion de date était un point faible surtout dans les cas de reprises sur plusieurs années et j’avais également l’impression qu’on trouvait une telle gestion chez la plupart de mes concurrents…

J’ai commencé à mettre en place et modifier les structures de fichier et les écrans et je suis désormais perplexe sur les suites à donner ; laisser tout ça dans la version 3.5, créer une version 4…"

MFLD:

"Je note également avec plaisir que vous explorez l'application via internet, ce qui m'apparait comme une excellente idée, pour un tas de raisons que nous connaissons tous les deux : positionnement sur le marché, processus de mises à jour, travail collaboratif syndic / CS / copropriétaire, etc.

Mais qui dit application via internet dit établissement d'une stratégie claire par rapport au déploiement de l'application : je ne pense pas que vous ayez aujourdhui la capacité non seulement de développer un produit, mais aussi d'exploiter l'infrastructure qui hébergera les N clients potentiels.

ValCompta sous sa forme actuelle est vendu comme un programme qu'on installe dans un répertoire unique et qui tourne sur chaque poste client. ValCompta sur internet, ce serait non seulement un programme, mais aussi un site internet multi-client à haute disponibilité, des bases de données à administrer, encore plus de support car ouverture à plusieurs clients par copropriétés, et la prise en charge de l'archivage.

Distribuer ValCompta internet comme package à installer ne concernera que les quelques clients qui savent déjà administrer un site internet, pas le syndic bénévole ou coopératif moyen qui, à en juger les discussions sur les forums, est plus attiré par une solution clé en main (et gratuite de préférence !).

Donc si vous voulez vous positionner sur ce segment, il me semble qu'une stratégie intermédiaire serait pertinente. Elle consisterait à externaliser uniquement la base de donnée qui actuellement est intégrée dans le produit. En gros, garder l'application sur le poste client, mais avec un accès à une base sur réseau ou sur internet, ce qui ouvrirait la possibilité du multi-poste. C'est un réel besoin car aujourdhui, mon vice-président synchronise son poste en recevant les sauvegardes totales que je lui fais régulièrment, et ne peut que l'utiliser qu'en consultation.

Et si cette base n'est pas sur un réseau local mais sur internet, rien n'interdit de construire une partie "consultation par le CS ou les copropriétaires" qui interrogereait cette base.

Là encore, qu'en pensez-vous ?"