Voir les détails de l’anomalie
| Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
|---|---|---|---|---|---|
| 0001812 | NOALYSS | new feature | public | 2020-07-02 12:53 | 2024-04-10 11:39 |
| Rapporteur | yanntemp | Affecté à | danydb | ||
| Priorité | basse | Sévérité | mineur | Reproductibilité | toujours |
| État | affecté | Résolution | ouvert | ||
| Résumé | 0001812: CATÉGORIES DE FICHES – Arborescence | ||||
| Description | Bonjour. Je reviens avec une vieille proposition: permettre une arborescence dans les catégories de fiches, sur plusieurs niveaux. Usages: — regroupement visuel pratique dans le menu des catégories en limitant la longueur du menu; — partout où il est possible d'afficher par catégorie, ça permet de regrouper les fiches par catégorie-(grand)parent et ainsi obtenir des affichages regroupés. Par exemple, dans la catégorie «salaires», pourvoir avoir des sous-catégorie selon le type de salaire, et ainsi pouvoir afficher la balance ou autre impression soit pour tous les salaires, soit pour une catégorie particulière; — très pratique aussi avec les menu déroulants dans la partie gestion (quand on à plusieurs catégorie pour un même menu comme «clients», «fournisseurs», etc') pour obtenir des affichage par sous-catégorie ou par catégories regroupées. J'imagine que tout cela est déjà possible avec RAPAV mais, là, ça permettrait une souplesse de premier niveau pour les affichages courants. | ||||
| Balises | Aucune balise n’est attachée. | ||||
| Extension Noalyss | Aucun | ||||
|
|
Argument supplémentaire en faveur des sous-catégories. Pour une association qui s'occupent de plusieurs activités (disons, «filiales», pour être grossier), il est très pratique de faire usage du potentiel de Noalyss et de procéder ainsi: Pour permettre une certaine autonomie de chaque «filiale», des fiches différentes sont utilisées pour les charges et produits. Ainsi, en affichant les soldes par fiche, on peut facilement voir, par exemple, la consommation d'électricité ou de papier, les recettes, dons, etc', de chaque filiale. Procéder ainsi, permet de renvoyer en comptabilité analytique une division encore plus fine de chaque filiale, et on a ainsi au moins deux niveaux analytique: 1. le niveau «en dur» dans la CG par filiale; 2. le niveau plus «souple» dans la CA pour chaque filiale. Libre ensuite de donner ou non un même poste aux différentes fiches pour les charges et produits par filiale si on veut voir apparaître le détail dans le bilan. Et c'est justement dans ce cas que les sous-catégories révèlent un fois de plus leur intérêt: si les fiches «électricité» de chaque filiale ont le même poste, et que leurs soldes respectifs sont donc «regroupés» dans le poste «électricité» de l'association; pouvoir regrouper toutes les fiches d'une même filiale dans une sous-catégorie (par exemple, [S&BD – filiale 1]; [S&BD – filiale 2]; etc') rend très facile d'afficher dans COMPTA/CARD les soldes par filiale. |
|
|
Dans le cas cité, les dépenses par entité, il est 1000 fois plus simple d'utiliser des journaux d'achat par filiale, la limite est 99 journaux d'achat mais on peut augmenter facilement, on peut filtrer par journaux les balances , je signale aussi qu'en comptabilité analytique on peut aussi faire des groupes de plusieurs postes. |
|
|
Je rejoins la réflexion de Yann sur les Fiches. Lorsque l'on a plusieurs dizaines d'employés, il serait intéressant de pouvoir créer une fiche maître avec toutes les coordonnées de l'employé et des "sous-fiches" avec des postes comptables spécifiques pour les salaires (455000), les notes de frais (440900) et l'une ou l'autre catégorie par employé nécessaire dans la société (Production, R&D, AS, "filiales", etc.). Avantage : une seule fiche créée et maintenue, les sous-fiche étant créées automatiquement (One set of data). On aurait, par exemple : Quickcode : Alex Nom : Legrand Prénom : Alexandre Adresse : rue de Macédoine, 1 Ville : Athènes Fiches : Salaires : SALALEX Poste comptable : 455000 Note de frais : NFALEX Poste comptable : 440900 |
|
|
Je comprends le principe , mais si on ajoute une arborescence des fiches, cela implique que quelque part on l'utilise, pour une balance par exemple, ou un report Par exemple , on pourrait vouloir connaître pour chaque "fiche maître" le solde des "fiches liées" ainsi que le total de la fiche liée pour toutes les fiches maîtres. Autre question : si on passe une OD , on donne soit la fiche maître , mais alors comment imputer sur la fiche liée, soit on utilise la fiche liée comment donner la fiche maître ? Comment ces fiches , liées ou maîtres, seront-elles utilisés et exploitées ? |
|
|
Punaise! Ça monte d'un cran en matière d'ambition. Deux idées différentes ici : — IDÉE PREMIÈRE DE LA TÂCHE : Je suggérais une arborescence de CATÉGORIES de fiche. C'est-à-dire que, dans le menu déroulant du menu FICHES, par exemple, on aurait les catégories habituelles (par exemple, salaires, fournisseurs, etc') et des sous-catégories (par exemples : salaires → employées/APE/étudiantes ; fournisseurs → grossistes/assurances/services). Rien que dans le menu FICHES option BALANCE, ça permettrait de directement afficher la balance par sous-catégorie. La suggestion de passer par des journaux différents est en effet partinente, MAIS ne recouvre pas entièrement l'affichage de la balance d'une fiche, laquelle peut être ventilée dans des opérations de journaux différents. Les fiches de la sous-catégorie «fournisseurs → grossistes», par exemple, le sera dans un journal d'achat et financier. Les catégories (et les éventuelles sous-catégores) permettent des regroupements qu'on ne retrouvent pas autrement. C'est un outil vraiment intéressant (et les sous-catégories ouvriraient des possibilités supplémentaires). Pour donner une idée peut-être plus parlante, les sous-catégories seraient une généralisation de ce qu'on trouve dans le menu GESTION : par exemple, les fiches d'une catégorie créée sur le modèle «fournisseurs» (ce qui serait le cas si on crée des catégorie de premier ordre comme «grossistes», «assurances», «services» sur le modèle de catégorie «fournisseurs») sont accessibles dans le menu GESTION/SUPP dans un menu déroulant qui reprend toutes ces catégories ; et on peut choisir de n'afficher qu'une de ces catégories ou toutes à la fois. Ici, dans le menu COMPTABILITÉ, on aurait accès à ces sous-catégories. La catégorie parent, quand elle est sélectionnée – par exemple dans le menu FICHES pour affichage par liste, historique ou balance – reprendrait toutes les sous-catégories (comme ci-dessous la catégorie-modèle «fournisseurs» rend les catégories basées dessus accèssibles dans les sous-menus de GESTION (SUPP, CLIENT, ADMINISTRATION, etc')), mais on pourrait aussi choisir une sous-catégorie et seules les fiches de celle-ci s'afficheraient. — IDÉE NOUVELLE de Marca (telle que je la comprends) : des «sous-fiches» ! Cette idée me rappelle celle que j'avais mentionnée concernant un dossier pour copropriété, mais je crois qu'elle est différente. J'avais rencontré le cas de plusieurs lots appartenant à une même propriétaire et je me disais qu'on pouvait vouloir afficher la balance d'une propriétaire comprenant les soldes des différents lots lui appartenant, plus éventuellement celui d'un compte courant interne pour frais payés par elle, etc'. L'idée m'était venue car dans l'extension COPRO, cette possiblité existe en partie, avec une fiche dont un des champs reprend une autre fiche et ventile celle-ci ou est ventilée par celle-ci (je ne sais plus). Ce qui est un peu le cas avec les quote-part pour dépenses non admises, etc', de certaines fiches, hormis que, là, ça fait intervenir plusieurs postes (la fiche principale et la contrepartie). Par contre, ici, l'idée de Marca semble ne concerner que la création automatique de sous-fiches, non leur usage ou la ventilation en cascade de l'une aux autres. Si? — Maintenant, ce que tu sembles ajouter, Dany, me fais penser au lien entre poste comptable et fiche : Le poste comptable étant «le maître» et les différentes fiches qui l'utilisent, «les liées». Si on utilise une fiche, le poste est ventilé ; par contre, si on utilise le poste directement, les fiches ne le sont pas. Ce que je comprends de ta question «Autre question : si on passe une OD ...». Dans ce cas, j'ai l'impression qu'une utilisation qui ne mênerait pas à des contradictions de soldes (comme quand on utilise tantôt le poste sans la fiche, tantôt la fiche) serait de pouvoir créer des fiches de «centralisation», sans poste comptable, qui regroupent les soldes de différentes fiches qui ont des postes différents. Comme une fiche ALEX qui regrouperait sa situation générale au sein de la structure (salaire, NDF, autres dettes et créances, etc'), ou comme l'exemple de la fiche d'une copropriétaire ci-dessus. Ou encore, le résultat annuel d'une filiale qui reprendrait tous les mouvement associés à ladite filiale (ce que j'entrevoyais de pouvoir faire grâce à une catégorie de fiches «Filiale 1» qui reprendrait différentes sous-catégories de fiches de la filiale (charges, dettes, etc')). Ce qui, dans mon cas, permettrait de renvoyer en comptabilité analytique un degré de détail supplémentaire pour chaque poste de chaque filiale. On aurait alors la comptabilité générale qui reprendrait l'ensemble sans distinction de filiale ; les affichages (fiches → balance, par exemple) par catégorie et sous-catégorie de fiches qui peuvent reprendre les soldes par filiale, par exemple ; et enfin la comptabilité analytique qui ajoute les détails par poste et la possibilité de "plans croisés" (avec les affichages correspondants). Quoi qu'il en soit, je dois encore réfléchir à la pertinence d'ajouter cette option et voir si elle ne pourrait pas être "simulée" en combinant catégories de fiches, journaux et analytique. |
|
|
[Pour résumer] La proposition ici ne devrait rien changer au comportement des fiches et des opérations. La différence n'apparaitrait que dans les menus déroulants de catégories de fiches. Exemple : -- Membres (nb de fiches) -- Membres adhérentes (nb f') -- Membres effectives (nb f') -- Fournisseuses (nb f') -- Grossistes (nb f') -- Gross' Belgique -- Gross' Europe -- Détail (nb f') -- Débitrices (nb f') ... Ce qui permettrait de jouer avec les affichages en comptabilité et en gestion, et donc d'avoir directement des balances et des soldes par ((sous-)sous-)catégorie. Un code pour indiquer la filiation entre catégories. Et celle-ci s'afficherait de manière évidente (retrait, flèches de développement et codes) dans le menu PARAM/MCARD/CCARD. A priori, vue d'ici (je n'y connais rien), ça n'affecterait rien d'autre que l'affichage des catégories. Qu'en dites-vous? Je propose d'ouvrir une autre tache pour la question des "fiches en cascades". |
|
|
Oui , je vois ce que tu veux faire, en fait ce sont seulement des groupes de catégories de fiches , Donc aujourd'hui on a des modéles de catégories de fiches et simplement des catégories de fiches , Exemple modèle Client et on peut avoir autant de catégories de clients qu'on veut et même en limiter l'utilisation par journaux. Donc il faudrait a) un menu pour créer des groupes et sous-groupes de catégories b) changer dans gestion pour classer par groupe et sous-groupe avec les totaux c) changer dans fiche pour afficher soit un groupe , soit un sous-groupe soit une catégorie de fiches, avec l'export en PDF - CSV Est-ce ce que tu aiùerais ? .D |
|
|
Alors... L'idée de «groupe de catégories» est encore autre chose MAIS pourrait même être plus générale que juste des (sous-)sous-catégories, et très intéressante. J'imaginais uniquement traiter les catégories comme une arborescence de dossiers : La catégorie «fournisseur», par exemple, contiendrait des sous-catégories (fournisseur-BE, fournisseur-UE, etc'). Ainsi, elles apparaîtraient regroupées dans le menu déroulant des catégories de fiches (en haut de la page du menu CARD), et donc ça rendrait le menu plus compact et les fiches mieux classées (par ex', «Charges → S&BD / Charges courantes / Charges fiscales») ET, surtout, permettrait, dans le menu CARD, d'afficher la liste des fiches en vue «balance», et d'avoir la balance par catégorie (comme maintenant) mais aussi par (sous-)sous-catégorie. Pareille dans le menu gestion. Des «groupes» de catégories permettraient la même chose (toutes les différentes catégories de fournisseurs pourraient être regroupées dans le «groupe» «Fournisseurs») MAIS permettraient même beaucoup plus, puisque certaines catégories pourraient se retrouver dans plusieurs groupes : Ce serait une réponse idéale à mon problème de "filiales". Je pourrais créer des fiches selon les différentes filiales et les regrouper en fonction des besoins : — «Groupe électricité» = «Électricité filiale 1» U «Électricité filiale 2» U «Électricité filiale 3» — «Groupe charges filiale 1» = toutes les fiches «charge» de la filiale 1 — «Groupe filiale 3» = toutes les fiches de la filiale 3 — ... Par contre, je pense que permettre de classer les catégories de fiches dans des «sur-catégories» éviterait de se retrouver avec un nombre trop élevés de catégories de premier niveau, et de s'y perdre aussi bien dans le menu de configuration → fiches → catégories de fiches, que dans le menu déroulant des catégories de fiches dans CARD. ! Ça serait le pendant de ce qui est possible dans la partie analytique : «Groupe» fait le même boulot, ça permet de regrouper des postes analytiques dans un ensemble qui n'est pas contraint par la nature des postes (toutes les charges courantes, par exemple). Ici, pareille : les catégories seraient classées selon leur nature ([charges → charges type 1 → charge type 1 filiale 1] ou [charges → charges filiale 1 → charges filiale 1 type 1], selon les besoins du dossier) en différents niveaux (= catégorie et (sous-)sous-catégories) ; et les groupes permettraient de faire des "tas" de fiches contre-nature pour les besoin d'affichage des balances et totaux (par exemple : «Gr' Filiale 1» = charges filiale 1 U produits filiale 1 ; ou «Gr' tiers filiale 3» = clientes filiale 3 U fournisseuses filiale 3). Qu'en dites-vous? |
| Date de modification | Nom d’utilisateur | Champ | Changement |
|---|---|---|---|
| 2020-07-02 12:53 | yanntemp | Nouvelle anomalie | |
| 2020-07-02 12:53 | yanntemp | État | nouveau => affecté |
| 2020-07-02 12:53 | yanntemp | Affecté à | => yanntemp |
| 2020-07-05 20:03 | yanntemp | Note ajoutée: 0004426 | |
| 2022-10-15 13:20 | yanntemp | Note modifiée: 0004426 | |
| 2022-10-15 13:24 | yanntemp | Affecté à | yanntemp => danydb |
| 2022-10-15 13:24 | yanntemp | Description mise à jour | |
| 2023-01-05 13:38 | danydb | Note ajoutée: 0005528 | |
| 2023-01-06 07:34 | Marca | Note ajoutée: 0005529 | |
| 2023-01-10 13:39 | danydb | Note ajoutée: 0005534 | |
| 2023-01-10 13:42 | danydb | Note modifiée: 0005534 | |
| 2023-01-10 13:46 | danydb | Note modifiée: 0005534 | |
| 2023-01-10 19:35 | yanntemp | Note ajoutée: 0005535 | |
| 2023-01-30 13:28 | yanntemp | Note ajoutée: 0005549 | |
| 2023-02-01 16:59 | danydb | Note ajoutée: 0005554 | |
| 2024-04-10 11:34 | yanntemp | Note ajoutée: 0005835 | |
| 2024-04-10 11:36 | yanntemp | Note modifiée: 0005835 | |
| 2024-04-10 11:39 | yanntemp | Note modifiée: 0005835 |
