151 (edited by javdenech 2017-11-14 22:57:57)

Re: Nouveautés de la version de développement 0.7

Joshua wrote:

Si au lieu d'avoir :
"Numéro d'article", on avait "Numéro d'article fabricant"
et
"Numéro de commande", on avait "Numéro de commande fabricant"
Est-ce que cela supprimerait les confusions et contenterait tout le monde ?

PS
Les groupes de textes avancent nomicons/smile

numéro d'article fabricant (omron)
numéro de commande fournisseur (Rexel)

Alimentation découpage mono 240W 10 24VCC (374870)
Réf Rexel : OMRS8VK-G24024
Réf Fab : S8VK-G24024
EAN13 : 4548583357730

Re: Nouveautés de la version de développement 0.7

javdenech wrote:
Joshua wrote:

Si au lieu d'avoir :
"Numéro d'article", on avait "Numéro d'article fabricant"
et
"Numéro de commande", on avait "Numéro de commande fabricant"
Est-ce que cela supprimerait les confusions et contenterait tout le monde ?

PS
Les groupes de textes avancent nomicons/smile

numéro d'article fabricant (omron)
numéro de commande fournisseur (Rexel)

Alimentation découpage mono 240W 10 24VCC (374870)
Réf Rexel : OMRS8VK-G24024
Réf Fab : S8VK-G24024
EAN13 : 4548583357730

Je vois les choses comme cela aussi: bon exemple !

153

Re: Nouveautés de la version de développement 0.7

Attention nomicons/devil

les infos provenant des FABRICANTS sont pour ainsi dire universelles et identiques pour tout le monde.
Par contre, les infos provenant des FOURNISSEURS, c'est pas le cas du tout. Chacun achetant son matos là où il veut/peut.

Moi je fais que de la conception et mon boulot c'est aussi de spécifier le matériel.
Et quand on spécifie du matos, on précise, au minimum, le nom du FABRICANT, la référence, le numéro de commande et une petite description textuelle histoire de capter rapidement de quoi il s'agit.
Quand j'ai fini mes plans, j'envoie la nomenclature à mon client qui se débrouille tout seul avec ses FOURNISSEURS.
En fait, je connais quasiment jamais le nom des fournisseurs de mes clients, ca sort déjà du cadre de mon travail.

Mais maintenant, je crois que je comprends mieux ce que tu voulais dire galexis (grâce à l'exemple de javdenech).

Pour élargir un peu le débat et essayer de trouver une structure convenant à tout le monde, je pense qu'il faudrait réfléchir en regardant un peu plus loin vers l'avenir :
J'aimerais bien que la team QElectroTech utilise son site web pour mettre, en autre, des collections "articles constructeur" en partage.
Si un jour, le nombre de contributeurs augmente sensiblement, on va vite se rendre compte qu'on ne pourra pas intégrer toutes les collections dans la collection officielle QET. Ca va devenir un fichier monstrueux et forcément bordélique, ingérable, intraduisible et avec énormément de doublons. Bref, on va crouler sous les symboles, tous dessinés avec un autre style, avec différentes tailles de texte, etc.
Personne ici n'a le temps de gérer un fichier d'une telle ampleur (j'en sais quelque chose, j'avais réordonné la collec officielle en 2015 je crois, boulot atroce nomicons/sick que je suis pas prêt de recommencer).
Je pense par exemple à la collection "guitare" qui devrait être mis en partage sur le site et pas dans la collec officielle.


Bref, le but du jeu serait de fournir une collection QET bien fournie, qualitativement irréprochable et forcément plus ou moins sous la responsabilité de la team QElectroTech. Cela concerne surtout les symboles normés/normalisés qui doivent faire partie d'un bon éditeur de plan électrique. Pour ca, ca va, on tient maintenant le bon bout nomicons/rolleyes  (y'a qu'à comparer avec QET v0.2 nomicons/laughing ).

Ensuite, pour tous les autres types de symboles (dont les fameux "articles constructeurs"), je pense qu'il faudrait les mettre en partage sur le site. Et seul l'auteur de la collection est responsable de son boulot. La team QET n'offrirait que le partage en ligne, il n'y aurait plus de modération (qui coûte énormément de temps si on veut la faire sérieusement).
L'avantage, c'est qu'on pourra alors mettre des collections dédiées à des registres bien particuliers, comme par exemple, les schémas de guitares électriques, où on aime bien mettre des couleurs... Ou alors tous les trucs de plomberie dans une collection "plomberie solaire, auteur : super mario".

J'en reviens alors à nos moutons :
Quand vous partegerez vos collections "articles constructeurs", il faudra bien sûr dégager toutes les infos concernant les fournisseurs, car ces infos vous sont personnelles. Faudra vraisemblablement passer par un script.
Si un jour je télécharge les articles "OMRON" que galexis à mis en partage sur le site QET, je veux évidemment utiliser les symboles tout de suite, sans avoir à faire du nettoyage pendant des heures... Et galexis sera aussi ravi d'utiliser mes EATON et SIEMENS sans y passer des plombes...

Soit... pas sûr d'avoir été bien clair... malgré le roman...

Vous voyez le topo ? Grosso-modo ?!?

Re: Nouveautés de la version de développement 0.7

J'aimerais bien que la team QElectroTech utilise son site web pour mettre, en autre, des collections "articles constructeur" en partage.
Si un jour, le nombre de contributeurs augmente sensiblement, on va vite se rendre compte qu'on ne pourra pas intégrer toutes les collections dans la collection officielle QET. Ca va devenir un fichier monstrueux et forcément bordélique, ingérable, intraduisible et avec énormément de doublons. Bref, on va crouler sous les symboles, tous dessinés avec un autre style, avec différentes tailles de texte, etc.

@ Nuri : tu l'avais devant les yeux ... dans le répertoire éléments sur le serveur web, te suffisais de créer un nouveaux dossier Manufacturer_article.
Je t'explique en quelques mots : ça fonctionne comme un répertoire sur ton PC il suffit de rajouter de nouveaux dossiers par marques, etc, dans ce dossier distant, ensuite tu rajoutes tes elmt (elements QET) les scripts de conversion de Xavier se chargeront de convertir à la volée ces elmt en svg pour l'affichage WEB et permettre aussi le téléchargement, par élément, catégorie, etc

https://qelectrotech.org/showcategory.php

155

Re: Nouveautés de la version de développement 0.7

@ Laurent :
j'en suis pas encore là avec le site web !
Je suis déjà content d'avoir fait un menu en javascript relativement facile à maintenir et beaucoup plus facile à traduire en francais et allemand. Reste encore à faire le redirect vers en/fr/de en fonction de la provenance géographique du visiteur. Puis finir ces satanées release notes...

Je verai ce que je pourrai réutiliser du travail de Xavier pour présenter proprement les partages des différents contributeurs.

Re: Nouveautés de la version de développement 0.7

Faudra pas en mettre trop non plus (je parle des éléments) ! l'espace sur ce serveur m' est compté et je suis déjà dans le rouge. nomicons/wassat
Apres je peux surement truander avec quelques liens symboliques entre la web area et le serveur de download....

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

Et quand on spécifie du matos, on précise, au minimum, le nom du FABRICANT, la référence, le numéro de commande et une petite description textuelle histoire de capter rapidement de quoi il s'agit.
Quand j'ai fini mes plans, j'envoie la nomenclature à mon client qui se débrouille tout seul avec ses FOURNISSEURS.
En fait, je connais quasiment jamais le nom des fournisseurs de mes clients, ca sort déjà du cadre de mon travail.

Tu dit au minimum : Fabricant, référence, numéro de commande et petite description.
Ensuite tu dit "le client se débrouille avec sont fournisseur".
Mais le numéro de commande, c'est bien un numéro propre au fournisseur. Du coup tu devrais juste avoir à renseigner Fabricant, référence, et petite description.
Je me trompe ?
J'avoue n'avoir pas trop réfléchie au truc, je suis comme Laurent, quand je refais un schéma éléc, je renseigne uniquement le nom du fabricant, la référence "fabricant" du produit et un petit texte d’explication.

C'est le comble, je suis le développeur, mais j'utilise pas souvent QET dans mon boulot, et encore moins de manière aussi poussé que vous nomicons/laughing

Re: Nouveautés de la version de développement 0.7

Quand je commande du matériel, je donne une seule référence et non deux...et j'ai jamais eu de problème. Si je veux un automate siemens le ref 6ES7..... suffit.
Comme toi Joshua, trois info me suffisent.

Re: Nouveautés de la version de développement 0.7

@ Joshua : ben notre boulot en priorité sur nos sites industriels c'est de dépanner, les schémas ou autres cela se fait en dehors des pannes, nos schémas doivent être clairs et surtout justes ! pas besoin d'une nomenclature ici.

160 (edited by javdenech 2017-11-16 00:36:06)

Re: Nouveautés de la version de développement 0.7

Joshua wrote:
Nuri wrote:

Et quand on spécifie du matos, on précise, au minimum, le nom du FABRICANT, la référence, le numéro de commande et une petite description textuelle histoire de capter rapidement de quoi il s'agit.
Quand j'ai fini mes plans, j'envoie la nomenclature à mon client qui se débrouille tout seul avec ses FOURNISSEURS.
En fait, je connais quasiment jamais le nom des fournisseurs de mes clients, ca sort déjà du cadre de mon travail.

Tu dit au minimum : Fabricant, référence, numéro de commande et petite description.
Ensuite tu dit "le client se débrouille avec sont fournisseur".
Mais le numéro de commande, c'est bien un numéro propre au fournisseur. Du coup tu devrais juste avoir à renseigner Fabricant, référence, et petite description.
Je me trompe ?
J'avoue n'avoir pas trop réfléchie au truc, je suis comme Laurent, quand je refais un schéma éléc, je renseigne uniquement le nom du fabricant, la référence "fabricant" du produit et un petit texte d’explication.

C'est le comble, je suis le développeur, mais j'utilise pas souvent QET dans mon boulot, et encore moins de manière aussi poussé que vous nomicons/laughing

C'est pas faux joshua
Je le gère avec un fichier excel qui me retrouve les références fournisseur pour balancer automatiquement les commandes dans notre logiciel pmi ( qui au passage sait déjà gérer des codes articles interne ) mais on ne s'en sert pas, trop lourdingue. (c'est aussi ce que fait une gmao sur un site de production)
Pour l'évolution des prix, j'ai une fonction de mise à jour à chaque réception de devis avec un historique.
C'est avec ce même fichier excel que je balance mes nomenclatures en fin de schéma ( avec la réfèrence constructeur) le fournisseur n'étant pas forcément le constructeur...

161

Re: Nouveautés de la version de développement 0.7

Joshua wrote:

Tu dit au minimum : Fabricant, référence, numéro de commande et petite description.
Ensuite tu dit "le client se débrouille avec sont fournisseur".
Mais le numéro de commande, c'est bien un numéro propre au fournisseur. Du coup tu devrais juste avoir à renseigner Fabricant, référence, et petite description.
Je me trompe ?

Oui et non...
Le numéro de commande existe aussi chez beaucoup de fabricants, pas seulement chez les fournisseurs.
C'est bien d'avoir cette discussion, ca va permettre d'éclaircir quelques zones d'ombre.
Prenons par exemple cette borne :
borne pour bornier
Sa référence (ou numero d'article), c'est : ST 2,5
Son numéro de commande (chez Phoenix, qui est fabricant ET fournisseur), c'est : 3031212

Autre exemple :
disjoncteur
Sa référence (ou numero d'article), c'est : FAZ-B13/1
Son numéro de commande, c'est : 278533

Ou encore :
capteur inductif
Sa référence (ou numero d'article), c'est : BES 516-300-S135-D-PU-10
Son numéro de commande, c'est : BES02RJ

Si je reprend l'exemple de la borne Phoenix. Quand je vois "3031212" (le numéro de commande) dans une nomenclature, ca ne me dit rien du tout. Par contre, si je vois en plus "ST 2,5", je sais tout de suite, par habitude métier, de quelle borne il s'agit.
Bref, chez beaucoup de fabricants, il existe 2 numéros pour clairement identifier le matériel.

galexis wrote:

Quand je commande du matériel, je donne une seule référence et non deux...et j'ai jamais eu de problème. Si je veux un automate siemens le ref 6ES7..... suffit.

Oui, Siemens et Rittal sont 2 parfaits contre-exemples puisque ces fabricants (qui sont aussi fournisseurs de leur propre matériel) identifient leurs articles avec un seul et unique numéro.
Dans ce cas, pour moi, référence = numéro de commande. Y'a pas de souci !

Alors... que faire avec QET ?!?

Si j'ai bien compris, ce serait plutôt bienvenu si on séparait clairement les informations provenant du fabricant et celles provenant du fournisseur.

Je pense qu'il est grand temps d'établir une liste exhaustive de toutes les propriétés qu'on voudrait pouvoir entrer lors de la création des éléments. Je m'attèle donc à cette tâche...

162 (edited by Nuri 2017-11-16 05:37:33)

Re: Nouveautés de la version de développement 0.7

...euh... J'ai commencer à faire la liste de toutes les propriétés en m'inspirant du logiciel commercial allemand qu'on m'oblige à utiliser, puis je me suis dit : "mais attends, avant de passer 1 heure là-dessus, est-ce vraiment nécessaire ?"

Pour vous donner une idée, ces propriétés sont, en vrac :
- données fabricant (nom du fabricant, référence, description, etc.)
- données fournisseur (nom du fournisseur, numéro de cammande, etc.)
- données géométriques (hauteur, largeur, profondeur, diamètre)
- données commerciales (prix, monnaie, rabait, etc.)
- données pour la maintenance (pièce de rechange, article en fin de vie, etc.)
- ...
C'est un sacrée catalogue ! J'ai pas compté, mais c'est une bonne centaine de propriétés pour 1 seul article nomicons/blink
Certes, ces infos peuvent être intéressantes, mais personne n'a le temps de renseigner tous ces machins. J'ai cottoyé assez de bureaux d'étude pour savoir que la plupart des champs restent vides...

A tout bien y réfléchir, je pense que les données fournisseur (nom et numéro de commande) n'ont pas leur place dans QET car ce sont des données personnelles. Si on veut facilement partager nos collections, il faut exclure les données personnelles.

De toute facon, galexis et javdenech gèrent leurs achats avec des fichiers externes, si j'ai bien compris. C'est sûrement la bonne méthode. Comme ca les prix et autres données commerciales (délais de livraison, etc.) peuvent être actualisées par une personne autre que le concepteur des plans électriques (ce qui est très souvent le cas).

Perso, moi je suis satisfait avec les champs d'infos déjà disponibles dans QET. Si on en rajoute, on risque de transformer QET en usine à gaz...

@ galexis et javdenech :
pour votre "numéro de commande" fournisseur, vous devriez plutôt utliser le champ "numéro interne" car c'est le numéro que vous utilisez "en interne" pour faire le lien avec vos fichiers externe (xls, ods ou autre).
Enfin... vous bossez comme vous voulez, bien sûr, je voudrais juste qu'on se mette d'accord sur la structure des données pour faciliter plus tard les échanges.

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

...euh... J'ai commencer à faire la liste de toutes les propriétés en m'inspirant du logiciel commercial allemand qu'on m'oblige à utiliser, puis je me suis dit : "mais attends, avant de passer 1 heure là-dessus, est-ce vraiment nécessaire ?"

Pour vous donner une idée, ces propriétés sont, en vrac :
- données fabricant (nom du fabricant, référence, description, etc.)
- données fournisseur (nom du fournisseur, numéro de cammande, etc.)
- données géométriques (hauteur, largeur, profondeur, diamètre)
- données commerciales (prix, monnaie, rabait, etc.)
- données pour la maintenance (pièce de rechange, article en fin de vie, etc.)
- ...
C'est un sacrée catalogue ! J'ai pas compté, mais c'est une bonne centaine de propriétés pour 1 seul article nomicons/blink
Certes, ces infos peuvent être intéressantes, mais personne n'a le temps de renseigner tous ces machins. J'ai cottoyé assez de bureaux d'étude pour savoir que la plupart des champs restent vides...

A tout bien y réfléchir, je pense que les données fournisseur (nom et numéro de commande) n'ont pas leur place dans QET car ce sont des données personnelles. Si on veut facilement partager nos collections, il faut exclure les données personnelles.

De toute facon, galexis et javdenech gèrent leurs achats avec des fichiers externes, si j'ai bien compris. C'est sûrement la bonne méthode. Comme ca les prix et autres données commerciales (délais de livraison, etc.) peuvent être actualisées par une personne autre que le concepteur des plans électriques (ce qui est très souvent le cas).

Perso, moi je suis satisfait avec les champs d'infos déjà disponibles dans QET. Si on en rajoute, on risque de transformer QET en usine à gaz...

@ galexis et javdenech :
pour votre "numéro de commande" fournisseur, vous devriez plutôt utliser le champ "numéro interne" car c'est le numéro que vous utilisez "en interne" pour faire le lien avec vos fichiers externe (xls, ods ou autre).
Enfin... vous bossez comme vous voulez, bien sûr, je voudrais juste qu'on se mette d'accord sur la structure des données pour faciliter plus tard les échanges.

nuri
tu as bien raison finalement ca sert a rien
Suffit que phoenix te change le short item code et c'est mort.
je ne les utilise jamais, ingérable

Post's attachments

Capture.PNG, 43.5 kb, 1363 x 386
Capture.PNG 43.5 kb, 124 downloads since 2017-11-16 

Re: Nouveautés de la version de développement 0.7

a

Post's attachments

Attachment icon Capture1.PNG 107.72 kb, 67 downloads since 2017-11-16 

165 (edited by javdenech 2017-11-16 18:42:07)

Re: Nouveautés de la version de développement 0.7

b

Post's attachments

Attachment icon Capture3.PNG 62.85 kb, 58 downloads since 2017-11-16 

Re: Nouveautés de la version de développement 0.7

d

Post's attachments

Capture4.PNG, 79.47 kb, 1314 x 719
Capture4.PNG 79.47 kb, 137 downloads since 2017-11-16 

Re: Nouveautés de la version de développement 0.7

Bonjour,
Bonsoir,


QET est un programme de dessin et non un programme de base de données.

Vous créez une grande base de données.
Cette information peut être mieux saisie dans un autre programme.

libre Calc
genumeric
...............

le nom du FABRICANT, la référence, le numéro , ..............

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

C'est pour cette raison que j'avais proposé à Laurent et Joshua de rajouter une ligne dans l'export en csv. Cette ligne servirait d'en-tête universel où chaque colonne serait identifiée par un numéro ID unique en plus des descriptions "folio", "numéro d'article", etc situées une ligne plus bas. De cette facon, les scripts et macros de chacun chercheront les colonnes en fonction d'un ID invariable et non plus une chaîne de caractères qui change de place au gré des évolutions du logiciel (et qui change aussi quand on édite la nomenclature dans une autre langue que la sienne)
Ca donnerait un truc du genre (les ID sont dans la ligne jaune) :

@ Nuri : comme ça ?

https://download.tuxfamily.org/qet/forum_img/UUID_export_csv.png

Re: Nouveautés de la version de développement 0.7

Author:   scorpio810
Date:     2017-11-16 19:57:16 +0100 (Thu, 16 Nov 2017)
Log Message:
-----------
Add UUID field in nomenclature export

@ Nuri : tu peux déja l'essayer j'ai envoyé le commit.

170

Re: Nouveautés de la version de développement 0.7

@ laurent :
t'es sûr que c'est une bonne idée de passer par la génération d'UUID de Qt ?
Il va pas nous faire des nouveaux UUID à chaque fois ?

Je pensais que ce serait plus facile si on ajoutait des ID tout simples définis par nous même (par ex. A001, B001, etc.) mais j'avoue que j'ai pas encore testé nomicons/blush

Re: Nouveautés de la version de développement 0.7

scorpio810 wrote:

Author:   scorpio810
Date:     2017-11-16 19:57:16 +0100 (Thu, 16 Nov 2017)
Log Message:
-----------
Add UUID field in nomenclature export

@ Nuri : tu peux déja l'essayer j'ai envoyé le commit.

Le UUID est inséré au milieu de la "chaine" existante ou ajouté à la fin ?
Tu es sûr que c'est ce que demandait Nuri ? Il parlais des entête de colonne, non ?

Re: Nouveautés de la version de développement 0.7

Bah tu le déplaces ou tu veux ... avec un fichier données au format csv tu peut faire beaucoup de choses..
Bon pas le temps pour les builds ce soir, bientôt l'heure d'aller au taff, p-e demain matin en rentrant si vous avez pas changé d'avis entre temps ... nomicons/devil

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

@ laurent :
t'es sûr que c'est une bonne idée de passer par la génération d'UUID de Qt ?
Il va pas nous faire des nouveaux UUID à chaque fois ?

Je pensais que ce serait plus facile si on ajoutait des ID tout simples définis par nous même (par ex. A001, B001, etc.) mais j'avoue que j'ai pas encore testé nomicons/blush

Tu voulais pas un UUID différent par ligne, ou alors j'ai pas compris ta demande ?
Pourquoi se prendre le choux Qt le fait tout seul comme un grand, le commit c'est juste deux lignes que j'ai ajouté..

Re: Nouveautés de la version de développement 0.7

Je penses que Nuri parlait des entêtes de colonnes, pour justement palier au changement de format de la trame d'export.

Re: Nouveautés de la version de développement 0.7

Je vous laisse mijoter heuu réfléchir j'ai une nuit de boulot a faire, moi  et c'est l'heure d'y aller  ..