Prise en main de la Gestion Commerciale

[Laurent Roche]

Salut,

J'ai décidé de me mettre sérieusement à Tryton. Dans un premier temps, je veux explorer le coté fonctionnel (pour des TPE et PME) : le CRM, la gestion commerciale et les feuilles de présence. Je compte l'utiliser pour mon besoin propre avant la fin de l'été (à l'heure actuelle, j'utilise Odoo).
Une fois que j'aurai maîtrisé la bête ;-) , je publierai des tutoriels vidéos (dans un premier temps en Français puis en Anglais) qui permettront à tous les nouveaux utilisateurs de prendre en main Tryton sans trop se prendre la tête.


Maintenant que les présentations sont faites, j'ai des questions sur la partie Gestion Commerciale  (le lettrage sert juste de référence pour faciliter les réponses) :
 
A) Dans un devis/facture, si je rentre une ligne "libre" (i.e pas d'un produit du catalogue), je ne peux pas lui affecter de compte comptable ? Je sais qu'on peut définir un compte par défaut (ça c'est bien) mais si je veux un compte comptable spécifique, est-ce que j'ai un moyen ... à part de passer par un produit du catalogue ?

 B) Comment modifier un template Devis ? J'ai modifié le fichier template ODT mais comment l'installer sur le serveur ?

 C) Peut-on générer des rapport en autre chose que des odt : idéalement un pdf  ?

 D) Comment envoyer, par e-mail, les devis, factures etc ? J'ai bien trouvé le bouton "Raport par Email" sur l'appli [GTK] mais rien dans l'appli [Web]), mais tout ce que ça fait, c'est ouvrir un e-mail vide avec le rapport en ODT comme pièce jointe : pas de modèle d'e-mail, pas d'adresse e-mail de destinataire ! !

 E) Que veut dire "Poster" une Facture ?

 F) Le cheminement des Ventes (tel que je l'ai compris) : Brouillon => Devis => Facture. Ou est le bon de commande ?


Merci d'avance pour vos réponses.

[Dominique Chabord]

Le 20 juin 2017 à 17:58, 'Laurent Roche' via tryton-fr
<tryt...@googlegroups.com> a écrit :

>
> A) Dans un devis/facture, si je rentre une ligne "libre" (i.e pas d'un
> produit du catalogue), je ne peux pas lui affecter de compte comptable ? Je
> sais qu'on peut définir un compte par défaut (ça c'est bien) mais si je veux
> un compte comptable spécifique, est-ce que j'ai un moyen ... à part de
> passer par un produit du catalogue ?
>
> B) Comment modifier un template Devis ? J'ai modifié le fichier template
> ODT mais comment l'installer sur le serveur ?

soit par un module (cf doc), soit en substituant le modèle d'origine
par le nouveau modèle, soit en uploadant le nouveau modèe par le menu
admin

>
> C) Peut-on générer des rapport en autre chose que des odt : idéalement un
> pdf ?

Oui si le serveur est complètement installé.
Dans la définition du rapport, on choisit le format de sortie

>
> D) Comment envoyer, par e-mail, les devis, factures etc ? J'ai bien trouvé
> le bouton "Raport par Email" sur l'appli [GTK] mais rien dans l'appli
> [Web]), mais tout ce que ça fait, c'est ouvrir un e-mail vide avec le
> rapport en ODT comme pièce jointe : pas de modèle d'e-mail, pas d'adresse
> e-mail de destinataire ! !

Il y a une discussion ouverte sur ce sujet pour obtenir des templates.
les paramètres mail sont définis avec les rapports.

>
> E) Que veut dire "Poster" une Facture ?

C'est la saisir en comptabilité.

>
> F) Le cheminement des Ventes (tel que je l'ai compris) : Brouillon => Devis
> => Facture. Ou est le bon de commande ?
>

non, c'est :
Brouillon => Devis => Commande

> => Facture. Ou est le bon de commande ?

Ca c'est du Odoo.
>

[Cédric Krier]

Pour compléter

On 2017-06-20 19:35, Dominique Chabord wrote:
> Le 20 juin 2017 à 17:58, 'Laurent Roche' via tryton-fr
> <tryt...@googlegroups.com> a écrit :
>
> >
> > A) Dans un devis/facture, si je rentre une ligne "libre" (i.e pas d'un
> > produit du catalogue), je ne peux pas lui affecter de compte comptable ? Je
> > sais qu'on peut définir un compte par défaut (ça c'est bien) mais si je veux
> > un compte comptable spécifique, est-ce que j'ai un moyen ... à part de
> > passer par un produit du catalogue ?

Il suffit de remplir le champs "Compte" et de laisser vide le champs
"Produit".

Par contre en parlant de devis, je ne suis pas sûr qu'on parle vraiment
de facture et pas de vente. Si c'est une vente, les vendeurs ne sont pas
sensé savoir les comptes à utiliser, il faut passer par des produits.

> > B) Comment modifier un template Devis ? J'ai modifié le fichier template
> > ODT mais comment l'installer sur le serveur ?
>
> soit par un module (cf doc), soit en substituant le modèle d'origine
> par le nouveau modèle,

Voir http://doc.tryton.org/4.4/trytond/doc/topics/reports/index.html#replacing-existing-tryton-reports

> soit en uploadant le nouveau modèe par le menu
> admin

Administration > Interface Utilisateur > Actions > Rapports

> > C) Peut-on générer des rapport en autre chose que des odt : idéalement un
> > pdf ?
>
> Oui si le serveur est complètement installé.
> Dans la définition du rapport, on choisit le format de sortie

Pour cela, il faut avoir unoconv installé.

> > D) Comment envoyer, par e-mail, les devis, factures etc ? J'ai bien trouvé
> > le bouton "Raport par Email" sur l'appli [GTK] mais rien dans l'appli
> > [Web]), mais tout ce que ça fait, c'est ouvrir un e-mail vide avec le
> > rapport en ODT comme pièce jointe : pas de modèle d'e-mail, pas d'adresse
> > e-mail de destinataire ! !
>
> Il y a une discussion ouverte sur ce sujet pour obtenir des templates.
> les paramètres mail sont définis avec les rapports.

Je suppose que Dominique parle de https://discuss.tryton.org/t/email-notification/71
C'est des emails envoyés automatiquement lors de certains évènements.
Pour l'instant le prototype ne permet pas d'avoir des attachements. Mais
je pense qu'un module complémentaire arrivera assez vite.

Sinon pour l'action depuis le client, si on veut avoir des champs
pré-remplit, il faut configurer le champs 'email' du rapport. C'est une
expression PYSON qui sera évaluée avec l'enregistrement courant. Du
coup, il faut que les adresses emails soient définies sur
l'enregistrement.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Laurent Roche]

Le mardi 20 juin 2017 21:55:06 UTC+2, Cédric Krier a écrit :

Pour compléter

On 2017-06-20 19:35, Dominique Chabord wrote:
> Le 20 juin 2017 à 17:58, 'Laurent Roche' via tryton-fr
> <tryt...@googlegroups.com> a écrit :
>
> >
> > A) Dans un devis/facture, si je rentre une ligne "libre" (i.e pas d'un
> > produit du catalogue), je ne peux pas lui affecter de compte comptable ? Je
> > sais qu'on peut définir un compte par défaut (ça c'est bien) mais si je veux
> > un compte comptable spécifique, est-ce que j'ai un moyen ... à part de
> > passer par un produit du catalogue ?

Il suffit de remplir le champs "Compte" et de laisser vide le champs
"Produit".

Effectivemen, c'était pourtant bien en évidence !

Par contre en parlant de devis, je ne suis pas sûr qu'on parle vraiment
de facture et pas de vente. Si c'est une vente, les vendeurs ne sont pas
sensé savoir les comptes à utiliser, il faut passer par des produits.

On est d'accord.

> >  B) Comment modifier un template Devis ? J'ai modifié le fichier template
> > ODT mais comment l'installer sur le serveur ?
>
> soit par un module (cf doc), soit en substituant le modèle d'origine
> par le nouveau modèle,

Voir http://doc.tryton.org/4.4/trytond/doc/topics/reports/index.html#replacing-existing-tryton-reports

> soit en uploadant le nouveau modèe par le menu
> admin

Administration > Interface Utilisateur > Actions > Rapports

J'avais bien trouvé cet écran d'administration pour gérer les rapports ... mais la manipulation pour télécharger un fichier n'est pas bien claire : je n'y étais pas arrivé !:(
Là, en bataillant, j'ai fini par y arriver : je vais faire des tests supplémentaires pour être sur d'avoir la bonne démarche

> >  C) Peut-on générer des rapport en autre chose que des odt : idéalement un
> > pdf  ?
>
> Oui si le serveur est complètement installé.
> Dans la définition du rapport, on choisit le format de sortie

Pour cela, il faut avoir unoconv installé.

Le premier rapport a généré une erreur, mais tous les suivants ont créé un PDF sans souci.

> >  D) Comment envoyer, par e-mail, les devis, factures etc ? J'ai bien trouvé
> > le bouton "Raport par Email" sur l'appli [GTK] mais rien dans l'appli
> > [Web]), mais tout ce que ça fait, c'est ouvrir un e-mail vide avec le
> > rapport en ODT comme pièce jointe : pas de modèle d'e-mail, pas d'adresse
> > e-mail de destinataire ! !
>
> Il y a une discussion ouverte sur ce sujet pour obtenir des templates.
> les paramètres mail sont définis avec les rapports.

Je suppose que Dominique parle de https://discuss.tryton.org/t/email-notification/71
C'est des emails envoyés automatiquement lors de certains évènements.
Pour l'instant le prototype ne permet pas d'avoir des attachements. Mais
je pense qu'un module complémentaire arrivera assez vite.

Sinon pour l'action depuis le client, si on veut avoir des champs
pré-remplit, il faut configurer le champs 'email' du rapport. C'est une
expression PYSON qui sera évaluée avec l'enregistrement courant. Du
coup, il faut que les adresses emails soient définies sur
l'enregistrement.

Ce n'est pas bien clair pour moi : je vais creuser l'expression PYSON.
Par contre, on ne peut pas envoyer d'email depuis l'interface Web ?
 

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

MERCI à tous les 2 pour vos réponses.

[Cédric Krier]

On 2017-06-21 16:13, 'Laurent Roche' via tryton-fr wrote:
> > > > D) Comment envoyer, par e-mail, les devis, factures etc ? J'ai bien
> > trouvé
> > > > le bouton "Raport par Email" sur l'appli [GTK] mais rien dans l'appli
> > > > [Web]), mais tout ce que ça fait, c'est ouvrir un e-mail vide avec le
> > > > rapport en ODT comme pièce jointe : pas de modèle d'e-mail, pas
> > d'adresse
> > > > e-mail de destinataire ! !
> > >
> > > Il y a une discussion ouverte sur ce sujet pour obtenir des templates.
> > > les paramètres mail sont définis avec les rapports.
> >
> > Je suppose que Dominique parle de
> > https://discuss.tryton.org/t/email-notification/71

> > <https://www.google.com/url?q=https%3A%2F%2Fdiscuss.tryton.org%2Ft%2Femail-notification%2F71&sa=D&sntz=1&usg=AFQjCNHBvaIcgrtCttB5T66KrpDiaFDmSA>

> > C'est des emails envoyés automatiquement lors de certains évènements.
> > Pour l'instant le prototype ne permet pas d'avoir des attachements. Mais
> > je pense qu'un module complémentaire arrivera assez vite.
> >
> > Sinon pour l'action depuis le client, si on veut avoir des champs
> > pré-remplit, il faut configurer le champs 'email' du rapport. C'est une
> > expression PYSON qui sera évaluée avec l'enregistrement courant. Du
> > coup, il faut que les adresses emails soient définies sur
> > l'enregistrement.
> >
> > Ce n'est pas bien clair pour moi : je vais creuser l'expression PYSON.
> Par contre, on ne peut pas envoyer d'email depuis l'interface Web ?

http://catb.org/jargon/html/Z/Zawinskis-Law.html

En fait, on s'est toujours empêcher se genre de développement car ce
serait toujours un client email limité (faire un client email est un
projet en soit). On privilégie l'interopérabilité et les protocoles
standards.
Maintenant, je pense que ce module [1] diminuera le besoin d'envoyer des
emails manuellement.


[1] https://discuss.tryton.org/t/email-notification/71

[Dominique Chabord]

Le 22 juin 2017 à 09:27, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2017-06-21 16:13, 'Laurent Roche' via tryton-fr wrote:

>

> http://catb.org/jargon/html/Z/Zawinskis-Law.html

Je crois qu'on ne parle que de smtp ici, correct ?

>
> En fait, on s'est toujours empêcher se genre de développement car ce
> serait toujours un client email limité (faire un client email est un
> projet en soit). On privilégie l'interopérabilité et les protocoles
> standards.
> Maintenant, je pense que ce module [1] diminuera le besoin d'envoyer des
> emails manuellement.
>

Je me demande si l'envoi manuel sera encore possible avec la
dématérialisation des factures. Il va falloir signer la facture et
peut-être le mail dans son ensemble.

[Laurent Roche]

Le jeudi 22 juin 2017 09:53:43 UTC+2, Dominique Chabord a écrit :

Le 22 juin 2017 à 09:27, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2017-06-21 16:13, 'Laurent Roche' via tryton-fr wrote:

>
> http://catb.org/jargon/html/Z/Zawinskis-Law.html

Je crois qu'on ne parle que de smtp ici, correct ?

Effectivement, le besoin fonctionnellement est assez simple : lorsqu'une pièce commerciale (Devis, Commande, Facture) est prête, on veut l'envoyer par e-mail (la plupart de mes clients ne fonctionnent que par e-mail et très peu de courrier papier) en 2 clics (1 clic sur un bouton "envoyer e-mail", 1 clic sur le bouton "Valider" de la fenêtre modale qui est apparu avec le sujet et message par défaut -à noter que ceux-ci incluent des informations de la pièce comptable : nom de la pièce, n°, nom du Tiers, montant TTC, montant HT etc- et la ou les adresses e-mails du Tiers de la pièce).
C'est ce que font la plupart des ERP que j'utilise/connais Odoo, sollo, Sellsy, Zoho, optimizze, Oxygene,   ...

Techniquement, il y a 2 solutions possibles :

• en envoyant un email avec le mailer du client : c'est ce que fait (en partie) l'application GTK. Mais en partie seulement, il n'y a ni sujet, ni texte de message, ni adresses emails : je vais regarder du coté de l'expression PYSON comme recommandé par Cédric. Et il faut un clic de plus pour envoyer l'e-mail ;-).
  Je comprends bien que cette solution n'est pas simple à mettre en oeuvre dans l'application Web : le protocole mailto ne permet pas de joindre des pièces jointes, et l'option attachment n'est pas reconnu par tous les clients e-mail.
  
• en envoyant un e-mail via un serveur SMTP (e.g. en utilisant la smtplib.py). Bien entendu, cela implique d'avoir saisi au préalable les informations SMTP (serveur, port, identifiant, mot de passe) quelque part. Ca fonctionne bien, avec la limitation qu'on n'aura pas l'e-mail envoyé dans le dossier des envoyés (sauf avec gmail qui le fait) : on peut toujours s'envoyer l'e-mail en CCI (si on veut) mais on peut aussi enregistrer les envois d'e-mail dans un log dans Tryton.
  Il me semble que c'est la solution la plus universelle et qui permettrait d'avoir un envoi des pièces comptables par e-mails simple, efficace et unifié (Web et GTK).
  C'est la solution qu'on choisit tous les ERP que j'ai utilisé (avec sollo qui permet aussi l'envoi via Outlook, en adressant directement Outlook).

Est-ce que c'est quelque chose qui est possible dans Tryton aujourd'hui ? Sinon, est-ce que c'est envisagé ?

La discussion sur la notification par e-mail indiqué par Cédric est intéressante mais n'est pas vraiment la même chose (ou bien quelque chose m'a échappé).

[Cédric Krier]

On 2017-06-22 03:02, 'Laurent Roche' via tryton-fr wrote:
>
>
>
> Le jeudi 22 juin 2017 09:53:43 UTC+2, Dominique Chabord a écrit :
> >

> > Le 22 juin 2017 à 09:27, Cédric Krier <cedric...@b2ck.com <javascript:>>

> > a écrit :
> > > On 2017-06-21 16:13, 'Laurent Roche' via tryton-fr wrote:
> >
> > >
> > > http://catb.org/jargon/html/Z/Zawinskis-Law.html
> >
> > Je crois qu'on ne parle que de smtp ici, correct ?
> >

> > Effectivement, le besoin *fonctionnellement* est assez simple :

> lorsqu'une pièce commerciale (Devis, Commande, Facture) est prête, on veut
> l'envoyer par e-mail (la plupart de mes clients ne fonctionnent que par
> e-mail et très peu de courrier papier) en 2 clics (1 clic sur un bouton
> "envoyer e-mail", 1 clic sur le bouton "Valider" de la fenêtre modale qui
> est apparu avec le sujet et message par défaut -à noter que ceux-ci
> incluent des informations de la pièce comptable : nom de la pièce, n°, nom
> du Tiers, montant TTC, montant HT etc- et la ou les adresses e-mails du
> Tiers de la pièce).

Je ne vois pas l'intérêt que l'utilisateur ait une action à faire. Si
vous voulez envoyer un email à certaines étapes de workflow, le module
notification_email est la solution.
Il manquerait pour l'instant à ce module, la possibilité d'ajouter des
attachements à l'email envoyé.

[Laurent ROCHE]

Mon expérience diffère peut-être de la votre, mais jusqu'à présent mes
utilisateurs veulent pouvoir gérer l'envoi de l'e-mail et pas un e-mail
qui part tout seul. Tout simplement, parce que très souvent, on va
vouloir ajouter une note personnelle en supplément au template de de
l'e-mail.
Pour moi, il est donc impératif que l'envoi des pièces commerciales se
fassent en appuyant sur un bouton qui affiche une fenêtre modale avec le
sujet et message par défaut, mais ce que j'avais oublié de préciser dans
mon précédent message, c'est qu'on la fenêtre modale permet de modifier
les informations (sujet, corps du message, destinataires, pièces
jointes) avant de cliquer sur le bouton Valider (ou Envoyer).

A propos de l'envoi par SMTP, y a-t'il des travaux en ce sens, dans Tryton ?

[Cédric Krier]

Donc c'est une envoie adhoc avec aucune garantie que l'email soit bien
envoyé à une certaine étape du workflow.

> Tout simplement, parce que très souvent, on va
> vouloir ajouter une note personnelle en supplément au template de de
> l'e-mail.
> Pour moi, il est donc impératif que l'envoi des pièces commerciales se
> fassent en appuyant sur un bouton qui affiche une fenêtre modale avec le
> sujet et message par défaut, mais ce que j'avais oublié de préciser dans
> mon précédent message, c'est qu'on la fenêtre modale permet de modifier
> les informations (sujet, corps du message, destinataires, pièces
> jointes) avant de cliquer sur le bouton Valider (ou Envoyer).

Et bien c'est tout à fait ce que l'option d'envoie de rapport par email.
Mais pour cela, il faut correctement configurer le champs email du
rapport et le client de chaque utilisateur pour correctement ouvrir le
client mail. (Il y a probablement des améliorations à faire sur cette
fonctionnalité pour la rendre plus simple.)

Comme je l'ai déjà indiqué, nous ne sommes pas vraiment intéressés à
implémenter un MUA dans Tryton.

Sinon il y a quand même moyen d'utiliser le module notification_email en
combinaison avec un wizard qui créerait un enregistrement avec les
informations encodées par l'utilisateur et qui servirait de base de
déclenchement de la notification. Mais je ne pense pas que ce soit en
adéquation avec la ligne de développent de Tryton et donc un tel
développement ne serait pas de base.

[Dominique Chabord]

Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :

>
> Comme je l'ai déjà indiqué, nous ne sommes pas vraiment intéressés à
> implémenter un MUA dans Tryton.

Comment fera t on quand les factures seront dématérialisées signées ?
Il faudra bien les émettre depuis le serveur et bnon depuis le PC d'un
utilisateur.

>
> Sinon il y a quand même moyen d'utiliser le module notification_email en
> combinaison avec un wizard qui créerait un enregistrement avec les
> informations encodées par l'utilisateur et qui servirait de base de
> déclenchement de la notification. Mais je ne pense pas que ce soit en
> adéquation avec la ligne de développent de Tryton et donc un tel
> développement ne serait pas de base.

Ca me semble tout à fait adéquat. Je partage aussi le besoin de
contrôler le message et l'envoi. Par exemple, un utilisateur prépare
la facture et le message et c'est un autre qui l'envoie. Si en plus,
une transaction me garantit que le message a bien été envoyé et fait
progresser un état, c'est parfait.

[Cédric Krier]

On 2017-06-25 23:23, Dominique Chabord wrote:
> Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :
>
> >
> > Comme je l'ai déjà indiqué, nous ne sommes pas vraiment intéressés à
> > implémenter un MUA dans Tryton.
>
> Comment fera t on quand les factures seront dématérialisées signées ?
> Il faudra bien les émettre depuis le serveur et bnon depuis le PC d'un
> utilisateur.

Je ne vois pas pourquoi.
La signature d'un OpenDocument est dans le document. J'imagine que la
majorité de tels standards seront similaires. Et si la signature doit
être stockée séparément, on générera une archive qui contiendra les
deux.

> > Sinon il y a quand même moyen d'utiliser le module notification_email en
> > combinaison avec un wizard qui créerait un enregistrement avec les
> > informations encodées par l'utilisateur et qui servirait de base de
> > déclenchement de la notification. Mais je ne pense pas que ce soit en
> > adéquation avec la ligne de développent de Tryton et donc un tel
> > développement ne serait pas de base.
>
> Ca me semble tout à fait adéquat. Je partage aussi le besoin de
> contrôler le message et l'envoi. Par exemple, un utilisateur prépare
> la facture et le message et c'est un autre qui l'envoie. Si en plus,
> une transaction me garantit que le message a bien été envoyé et fait
> progresser un état, c'est parfait.

Je pense que c'est une perte de temps et d'efficacité. Le but d'un ERP
est de mettre en place des procédures normalisées et d'automatiser un
maximum.
Si on reprend les exemples comme l'envoie d'une confirmation de commande
ou bien un facture. Elles sont chaque fois basées sur une étape de
workflow et s'il y a besoin d'une validation c'est sur le workflow
qu'elle doit se trouver.

[Dominique Chabord]

Le 25 juin 2017 à 23:50, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2017-06-25 23:23, Dominique Chabord wrote:

>>
>> Comment fera t on quand les factures seront dématérialisées signées ?
>> Il faudra bien les émettre depuis le serveur et bnon depuis le PC d'un
>> utilisateur.
>
> Je ne vois pas pourquoi.
> La signature d'un OpenDocument est dans le document. J'imagine que la
> majorité de tels standards seront similaires. Et si la signature doit
> être stockée séparément, on générera une archive qui contiendra les
> deux.

Mouais, ça se tient. Ca m'ennuie de dépendre du poste client.

> Si on reprend les exemples comme l'envoie d'une confirmation de commande
> ou bien un facture. Elles sont chaque fois basées sur une étape de
> workflow et s'il y a besoin d'une validation c'est sur le workflow
> qu'elle doit se trouver.

Oui, ça c'est convaincant. Donc on n'aurait pas un outil général "send
that by mail" comme Odoo qui ensuite définit des templates par
contexte ( envoi devis, envoi facture...), mais soit ça se fait
automatiquement, soit on ajouter une étape "send to customer" pour
faire progresser le workflow. Ca me paraît mieux.

[Laurent ROCHE]

Le 25/06/2017 à 23:50, Cédric Krier a écrit :

On 2017-06-25 23:23, Dominique Chabord wrote:

Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :

Et bien c'est tout à fait ce que l'option d'envoie de rapport par email.
Mais pour cela, il faut correctement configurer le champs email du
rapport et le client de chaque utilisateur pour correctement ouvrir le
client mail. (Il y a probablement des améliorations à faire sur cette
fonctionnalité pour la rendre plus simple.)

Comme je l'ai déjà indiqué, nous ne sommes pas vraiment intéressés à
implémenter un MUA dans Tryton.

Je n'ai jamais parlé d'implémenter un MUA dans Tryton : juste de pouvoir envoyer des e-mails par SMTP, car à l'usage c'est le plus rapide.
De plus, pour autant que je sache c'est la seule solution avec l'interface web.
Je n'ai pas trouvé de commandes pour l'envoi de rapport par e-mail dans l'interface web.

Sinon il y a quand même moyen d'utiliser le module notification_email en
combinaison avec un wizard qui créerait un enregistrement avec les
informations encodées par l'utilisateur et qui servirait de base de
déclenchement de la notification. Mais je ne pense pas que ce soit en
adéquation avec la ligne de développent de Tryton et donc un tel
développement ne serait pas de base.

Ca me semble tout à fait adéquat. Je partage aussi le besoin de
contrôler le message et l'envoi. Par exemple, un utilisateur prépare
la facture et le message et c'est un autre qui l'envoie. Si en plus,
une transaction me garantit que le message a bien été envoyé et fait
progresser un état, c'est parfait.

Je pense que c'est une perte de temps et d'efficacité. Le but d'un ERP
est de mettre en place des procédures normalisées et d'automatiser un
maximum.
Si on reprend les exemples comme l'envoie d'une confirmation de commande
ou bien un facture. Elles sont chaque fois basées sur une étape de
workflow et s'il y a besoin d'une validation c'est sur le workflow
qu'elle doit se trouver.

Ce n'est pas le retour d'expérience que j'ai de mes utilisateurs (avec d'autres ERPs que Tryton, pour le moment) : ils veulent pouvoir envoyer des e-mails différents selon les cas. Par exemple, des e-mails avec un tutoiement de l'interlocuteur, et un autre e-mail avec un vouvoiement, ou bien un e-mail avec en pièce jointe une plaquette commerciale et un autre e-mail avec un document technique.
Bref, oui un ERP doit automatiser les tâches mais il doit aussi permettre une souplesse d'utilisation, en quelques clics.

-- 
---
Cheers,
L@u
The Computing Froggy
http://computing.travellingfroggy.info

[Nicolas Évrard]

* 'Laurent ROCHE' via tryton-fr [2017-06-26 20:02 +0200]:

>Le 25/06/2017 à 23:50, Cédric Krier a écrit :
>>On 2017-06-25 23:23, Dominique Chabord wrote:
>>>Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :

Salut,

>Je n'ai jamais parlé d'implémenter un MUA dans Tryton : juste de
>pouvoir envoyer des e-mails par SMTP, car à l'usage c'est le plus
>rapide.

Que veux tu dire par "envoyer des emails par SMTP" ? Car tous les
emails du monde sont acheminés par SMTP :).

>>>>Sinon il y a quand même moyen d'utiliser le module notification_email en
>>>>combinaison avec un wizard qui créerait un enregistrement avec les
>>>>informations encodées par l'utilisateur et qui servirait de base de
>>>>déclenchement de la notification. Mais je ne pense pas que ce soit en
>>>>adéquation avec la ligne de développent de Tryton et donc un tel
>>>>développement ne serait pas de base.
>>>Ca me semble tout à fait adéquat. Je partage aussi le besoin de
>>>contrôler le message et l'envoi. Par exemple, un utilisateur prépare
>>>la facture et le message et c'est un autre qui l'envoie. Si en plus,
>>>une transaction me garantit que le message a bien été envoyé et fait
>>>progresser un état, c'est parfait.
>>Je pense que c'est une perte de temps et d'efficacité. Le but d'un ERP
>>est de mettre en place des procédures normalisées et d'automatiser un
>>maximum.
>>Si on reprend les exemples comme l'envoie d'une confirmation de commande
>>ou bien un facture. Elles sont chaque fois basées sur une étape de
>>workflow et s'il y a besoin d'une validation c'est sur le workflow
>>qu'elle doit se trouver.
>>
>Ce n'est pas le retour d'expérience que j'ai de mes utilisateurs (avec

>d'autres ERPs que /Tryton/, pour le moment) : ils veulent pouvoir

>envoyer des e-mails différents selon les cas. Par exemple, des e-mails
>avec un tutoiement de l'interlocuteur, et un autre e-mail avec un
>vouvoiement, ou bien un e-mail avec en pièce jointe une plaquette
>commerciale et un autre e-mail avec un document technique.

Si je comprends bien ce que tu veux dire, il faudrait que l'ERP
permette de:

- écrire le texte de l'email
- gérer les attachements de cet email
- probablement aussi ajouter des destinataires
- chiffrer l'email pourrait être intéressant aussi probablement
- avoir de la correction orthographique, ce serait pas mal non
plus
- …

Tu as compris où je veux en venir :D. On s'approche dangereusement de
la fenêtre composition d'un MUA :).

>Bref, oui un ERP doit automatiser les tâches mais il doit aussi
>permettre une souplesse d'utilisation, en quelques clics.

Avec libreoffice, le document ODT s'ouvre et il y a l'option "Envoyer
le document par email" (je me demande même si LO ne fait pas la
transformation en PDF aussi avant l'envoi), ce qui est - je suppose -
globalement équivalent à l'envoi par email de Tryton.

Le problème avec la procédure ci-dessus étant que l'adresse email doit
être trouvée et mise correctement par l'utilisateur, ce que fait
l'envoi par email de Tryton (qu'il y a peut-être moyen d'améliorer, je
n'y ai pas réfléchi).

Il y a quelques avantages au fait d'utiliser le MUA habituel:

- Le logiciel est fait pour ça (mine de rien, ça compte car il y a
ses habitudes, la correction de l'orthographe, etc)
- Le logiciel est intégré à son compte de messagerie (en ces temps
où les gens veulent pouvoir accéder aux infos depuis leurs
téléphones / tablettes / frigo ça peut être utile).

Au final, mon opinion c'est que Tryton ne doit pas être un MUA ni même
en simuler un. Par contre, l'intégration passe par le protocole
mailto: et c'est perfectible ; s'il y a moyen de l'améliorer pourquoi
pas (bien que je n'aie moi-même pas réfléchi au sujet néanmoins je
serais très étonné si, sous Windows au moins, il n'y avait pas moyen
de faire mieux).

--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com

[Dominique Chabord]

Le 27 juin 2017 à 12:00, Nicolas Évrard <nicolas...@b2ck.com> a écrit :
> * 'Laurent ROCHE' via tryton-fr [2017-06-26 20:02 +0200]:
>>
>> Le 25/06/2017 à 23:50, Cédric Krier a écrit :
>>>
>>> On 2017-06-25 23:23, Dominique Chabord wrote:
>>>>
>>>> Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :
>
>
> Salut,
>
>> Je n'ai jamais parlé d'implémenter un MUA dans Tryton : juste de pouvoir
>> envoyer des e-mails par SMTP, car à l'usage c'est le plus rapide.
>
>
> Que veux tu dire par "envoyer des emails par SMTP" ? Car tous les
> emails du monde sont acheminés par SMTP :).

Je croyais que le MUA ne servait qu'en réception. Après vérification,
c'est aussi une fonction en émission. Je pense donc qu'on parle tous
de la même chose.

>
> Si je comprends bien ce que tu veux dire, il faudrait que l'ERP
> permette de:
>
> - écrire le texte de l'email

utiliser un template pour créer un brouillon de mail éditable

> - gérer les attachements de cet email

éventuellement, sauf si on utilise cette fonction pour émettre un
document (devis, facture, relance)

> - probablement aussi ajouter des destinataires

Pourquoi pas

> - chiffrer l'email pourrait être intéressant aussi probablement

Je ne pense pas, je vois plutôt une signature du mail

> - avoir de la correction orthographique, ce serait pas mal non
> plus

Non, ni aucune fonction de composition html.

> - …
>
> Tu as compris où je veux en venir :D. On s'approche dangereusement de
> la fenêtre composition d'un MUA :).

plutôt de ce que sait faire un script shell de moins de 20 lignes
d'ailleurs, si j'ai bien compris mailx est un MUA.

>
>> Bref, oui un ERP doit automatiser les tâches mais il doit aussi permettre
>> une souplesse d'utilisation, en quelques clics.
>
>
> Avec libreoffice, le document ODT s'ouvre et il y a l'option "Envoyer
> le document par email" (je me demande même si LO ne fait pas la
> transformation en PDF aussi avant l'envoi), ce qui est - je suppose -
> globalement équivalent à l'envoi par email de Tryton.

non, c'est pas équivalent. C'est ce qu'on essaie de dire.
Les points qui m'embêtent actuellement :
1- il faut un utlisateur sur PC, pas possible depuis un téléphione
2- sur mon PC, je suis hors périmètre de sécurité/traçabilité, je ne
souhaite pas que ce mail passe par un outlook express et que mon
client reçoive du spam (ou pire).
3- je souhaite que mon client reçoive un mail de smtp.sisalp.fr, pas
de vero...@free.fr via le smtp orange de sa ligne adsl.

>
> Le problème avec la procédure ci-dessus étant que l'adresse email doit
> être trouvée et mise correctement par l'utilisateur, ce que fait
> l'envoi par email de Tryton (qu'il y a peut-être moyen d'améliorer, je
> n'y ai pas réfléchi).
>
> Il y a quelques avantages au fait d'utiliser le MUA habituel:
>
> - Le logiciel est fait pour ça (mine de rien, ça compte car il y a
> ses habitudes, la correction de l'orthographe, etc)
> - Le logiciel est intégré à son compte de messagerie (en ces temps
> où les gens veulent pouvoir accéder aux infos depuis leurs
> téléphones / tablettes / frigo ça peut être utile).

bof...

>
> Au final, mon opinion c'est que Tryton ne doit pas être un MUA ni même
> en simuler un. Par contre, l'intégration passe par le protocole
> mailto: et c'est perfectible ; s'il y a moyen de l'améliorer pourquoi
> pas (bien que je n'aie moi-même pas réfléchi au sujet néanmoins je
> serais très étonné si, sous Windows au moins, il n'y avait pas moyen
> de faire mieux).

A mon avis, il vaudrait mieux ne rien faire que mailto:
je dis ça je dis rien.
A+
>

[Dominique Chabord]

et j'ai oublié le reply-to:
bien sûr, hors de question que le client réponde sur la boite privée
du collaborateur. ;-)

[Nicolas Évrard]

* Dominique Chabord [2017-06-27 12:37 +0200]:

>Le 27 juin 2017 à 12:00, Nicolas Évrard <nicolas...@b2ck.com> a écrit :
>> * 'Laurent ROCHE' via tryton-fr [2017-06-26 20:02 +0200]:
>>>
>>> Le 25/06/2017 à 23:50, Cédric Krier a écrit :
>>>>
>>>> On 2017-06-25 23:23, Dominique Chabord wrote:
>>>>>
>>>>> Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a écrit :
>>
>>
>> Salut,
>>
>>> Je n'ai jamais parlé d'implémenter un MUA dans Tryton : juste de pouvoir
>>> envoyer des e-mails par SMTP, car à l'usage c'est le plus rapide.
>>
>>
>> Que veux tu dire par "envoyer des emails par SMTP" ? Car tous les
>> emails du monde sont acheminés par SMTP :).
>
>Je croyais que le MUA ne servait qu'en réception. Après vérification,
>c'est aussi une fonction en émission. Je pense donc qu'on parle tous
>de la même chose.
>
>>
>> Si je comprends bien ce que tu veux dire, il faudrait que l'ERP
>> permette de:
>>
>> - écrire le texte de l'email
>
>utiliser un template pour créer un brouillon de mail éditable

Bah, le protocole mailto: permet de spécifier le contenu du body.

>> - gérer les attachements de cet email
>
>éventuellement, sauf si on utilise cette fonction pour émettre un
>document (devis, facture, relance)

Éventuellement ? Si tu souhaites utiliser la fonction email de ton ERP
pour n'envoyer qu'éventuellement des documents alors je ne comprends
pas.

>> - chiffrer l'email pourrait être intéressant aussi probablement
>
>Je ne pense pas, je vois plutôt une signature du mail

Si tu peux signer l'email, tu peux le chiffre aussi :D.

>> - avoir de la correction orthographique, ce serait pas mal non
>> plus
>
>Non, ni aucune fonction de composition html.

Et pourquoi donc, si tu commences à permettre aux gens de modifier
le contenu de leur email, ils voudront pouvoir corriger leurs fautes.

>> Tu as compris où je veux en venir :D. On s'approche dangereusement de
>> la fenêtre composition d'un MUA :).
>
>plutôt de ce que sait faire un script shell de moins de 20 lignes
>d'ailleurs, si j'ai bien compris mailx est un MUA.

Si tu en arrives au point où tu scriptes ton envoi d'email alors on ne
parle plus de MUA mais du module email_notification, à priori.

>>> Bref, oui un ERP doit automatiser les tâches mais il doit aussi permettre
>>> une souplesse d'utilisation, en quelques clics.
>>
>>
>> Avec libreoffice, le document ODT s'ouvre et il y a l'option "Envoyer
>> le document par email" (je me demande même si LO ne fait pas la
>> transformation en PDF aussi avant l'envoi), ce qui est - je suppose -
>> globalement équivalent à l'envoi par email de Tryton.
>
>non, c'est pas équivalent. C'est ce qu'on essaie de dire.

Je veux dire qu'à mon avis ce que LO fait est globablement équivalent
à ce que fait Tryton.

>Les points qui m'embêtent actuellement :
>1- il faut un utlisateur sur PC, pas possible depuis un téléphione
>2- sur mon PC, je suis hors périmètre de sécurité/traçabilité, je ne
>souhaite pas que ce mail passe par un outlook express et que mon
>client reçoive du spam (ou pire).
>3- je souhaite que mon client reçoive un mail de smtp.sisalp.fr, pas
>de vero...@free.fr via le smtp orange de sa ligne adsl.

Donc tu veux que Tryton soit un MUA, Laurent ne le souhaite pas lui
(et nous non plus :P).

Mais si tu as ces contraintes, je me demande alors pourquoi les
collaborateurs peuvent utiliser Tryton hors du boulot. En effet, s'il
le peuvent, rien ne les empêche de: 1) Télécharger le document, 2)
Utiliser leur Outlook express pour envoyer l'email, 3) E-mail qui
passe par le smtp d'orange.

>> Au final, mon opinion c'est que Tryton ne doit pas être un MUA ni même
>> en simuler un. Par contre, l'intégration passe par le protocole
>> mailto: et c'est perfectible ; s'il y a moyen de l'améliorer pourquoi
>> pas (bien que je n'aie moi-même pas réfléchi au sujet néanmoins je
>> serais très étonné si, sous Windows au moins, il n'y avait pas moyen
>> de faire mieux).
>
>A mon avis, il vaudrait mieux ne rien faire que mailto:
>je dis ça je dis rien.

En fait, en écrivant ma réponse c'était ce qui m'est passé par la
tête.

Je me demande si on ne devrait pas retirer cette fonctionnalité et
laisser aux gens qui le souhaite la possibilité d'utiliser un greffon
pour leurs clients Tryton.

[Dominique Chabord]

un peu bizarre ta réponse, c'est ce qu'on appelle en anglais du "push-back"

mais sans polémique, je precise certains points :

Le 27 juin 2017 à 13:52, Nicolas Évrard <nicolas...@b2ck.com> a écrit :
> * Dominique Chabord [2017-06-27 12:37 +0200]:

>

>>> - gérer les attachements de cet email
>>
>>
>> éventuellement, sauf si on utilise cette fonction pour émettre un
>> document (devis, facture, relance)
>
>
> Éventuellement ? Si tu souhaites utiliser la fonction email de ton ERP
> pour n'envoyer qu'éventuellement des documents alors je ne comprends
> pas.

On peut "éventuellement" gérer des attachements (par exemple en
ajouter : use case conditions générales, IBAN...). Sinon, dans le cas
où on veut transmettre une facture, soit on attache la facture (c'est
peut-être ce que tu indiques par "gerer les attachements"), soit on
transmet un lien de téléchargement, ou bien autre chose, je ne suis
pas spécialiste.

>
>>> - chiffrer l'email pourrait être intéressant aussi probablement
>>
>>
>> Je ne pense pas, je vois plutôt une signature du mail
>
>
> Si tu peux signer l'email, tu peux le chiffre aussi :D.

On peut tout faire, mais ce qui me serait utile c'est une signature,
pas un chiffrement.

>
>>> - avoir de la correction orthographique, ce serait pas mal non
>>> plus
>>
>>
>> Non, ni aucune fonction de composition html.
>
>
> Et pourquoi donc, si tu commences à permettre aux gens de modifier
> le contenu de leur email, ils voudront pouvoir corriger leurs fautes.

Parce que je donne mon avis. Il y a une correction d'orthographe sur
les autres saisies de Tryton ? Non alors pourquoi sur-spécifier dans
ce cas ?

>
>>> Tu as compris où je veux en venir :D. On s'approche dangereusement de
>>> la fenêtre composition d'un MUA :).
>>
>>
>> plutôt de ce que sait faire un script shell de moins de 20 lignes
>> d'ailleurs, si j'ai bien compris mailx est un MUA.
>
>
> Si tu en arrives au point où tu scriptes ton envoi d'email alors on ne
> parle plus de MUA mais du module email_notification, à priori.

Relis ce thread, ça a été évoqué. Ce dont on a besoin, est proche de
la notification par email, je pense.

>
>>>> Bref, oui un ERP doit automatiser les tâches mais il doit aussi
>>>> permettre
>>>> une souplesse d'utilisation, en quelques clics.
>>>
>>>
>>>
>>> Avec libreoffice, le document ODT s'ouvre et il y a l'option "Envoyer
>>> le document par email" (je me demande même si LO ne fait pas la
>>> transformation en PDF aussi avant l'envoi), ce qui est - je suppose -
>>> globalement équivalent à l'envoi par email de Tryton.
>>
>>
>> non, c'est pas équivalent. C'est ce qu'on essaie de dire.
>
>
> Je veux dire qu'à mon avis ce que LO fait est globablement équivalent
> à ce que fait Tryton.

Sauf qu'il le fait sur un poste client et non sur le serveur.

>
>> Les points qui m'embêtent actuellement :
>> 1- il faut un utlisateur sur PC, pas possible depuis un téléphione
>> 2- sur mon PC, je suis hors périmètre de sécurité/traçabilité, je ne
>> souhaite pas que ce mail passe par un outlook express et que mon
>> client reçoive du spam (ou pire).
>> 3- je souhaite que mon client reçoive un mail de smtp.sisalp.fr, pas
>> de vero...@free.fr via le smtp orange de sa ligne adsl.
>
>
> Donc tu veux que Tryton soit un MUA, Laurent ne le souhaite pas lui
> (et nous non plus :P).

En tout cas, un script shell le fait parfaitement.

>
> Mais si tu as ces contraintes, je me demande alors pourquoi les
> collaborateurs peuvent utiliser Tryton hors du boulot. En effet, s'il
> le peuvent, rien ne les empêche de: 1) Télécharger le document, 2)
> Utiliser leur Outlook express pour envoyer l'email, 3) E-mail qui
> passe par le smtp d'orange.

Ils le peuvent. C'est pas le sujet. Je veux qu'ils puissent aussi
bosser correctement.
Ils n'ont pas à discuter en privé avec les clients de leur employeur.

>>
>>
>> A mon avis, il vaudrait mieux ne rien faire que mailto:
>> je dis ça je dis rien.
>
>
> En fait, en écrivant ma réponse c'était ce qui m'est passé par la
> tête.
>
> Je me demande si on ne devrait pas retirer cette fonctionnalité et
> laisser aux gens qui le souhaite la possibilité d'utiliser un greffon
> pour leurs clients Tryton.

Peu importe, c'est pourri dès que ça sort du serveur.
>

[Laurent ROCHE]

Le 27/06/2017 à 12:00, Nicolas Évrard a écrit :
> * 'Laurent ROCHE' via tryton-fr [2017-06-26 20:02 +0200]:
>> Le 25/06/2017 à 23:50, Cédric Krier a écrit :
>>> On 2017-06-25 23:23, Dominique Chabord wrote:
>>>> Le 25 juin 2017 à 21:06, Cédric Krier <cedric...@b2ck.com> a
>>>> écrit :
>
> Salut,
>
>> Je n'ai jamais parlé d'implémenter un MUA dans Tryton : juste de
>> pouvoir envoyer des e-mails par SMTP, car à l'usage c'est le plus
>> rapide.
>
> Que veux tu dire par "envoyer des emails par SMTP" ? Car tous les
> emails du monde sont acheminés par SMTP :).

OK, je n'étais pas clair : effectivement tous les e-mails partent depuis
un serveur SMTP. Je voulais dire : envoyer directement un e-mail en
adressant un serveur SMTP, comme on peut le faire dans la plupart des
langages de programmation (y compris Python).

>
>>>
>> Ce n'est pas le retour d'expérience que j'ai de mes utilisateurs
>> (avec d'autres ERPs que /Tryton/, pour le moment) : ils veulent
>> pouvoir envoyer des e-mails différents selon les cas. Par exemple,
>> des e-mails avec un tutoiement de l'interlocuteur, et un autre e-mail
>> avec un vouvoiement, ou bien un e-mail avec en pièce jointe une
>> plaquette commerciale et un autre e-mail avec un document technique.
>
> Si je comprends bien ce que tu veux dire, il faudrait que l'ERP
> permette de:
>
> - écrire le texte de l'email
> - gérer les attachements de cet email
> - probablement aussi ajouter des destinataires
> - chiffrer l'email pourrait être intéressant aussi probablement
> - avoir de la correction orthographique, ce serait pas mal non
> plus
> - …
>
> Tu as compris où je veux en venir :D. On s'approche dangereusement de
> la fenêtre composition d'un MUA :).

Alors, oui effectivement, d'après mon expérience et les besoins de mes
utilisateurs, il faut pouvoir envoyer un e-mail depuis l'ERP. Car c'est
beaucoup plus rapide et plus facile à gérer que d'envoyer un e-mail
depuis le MUA habituel.
Pour mes utilisateurs, le MUA habituel c'est dans 98% des cas soit
Outlook, soit un web mail qui ne sont pas des solutions faciles à adresser.

>
>> Bref, oui un ERP doit automatiser les tâches mais il doit aussi
>> permettre une souplesse d'utilisation, en quelques clics.
>
> Avec libreoffice, le document ODT s'ouvre et il y a l'option "Envoyer
> le document par email" (je me demande même si LO ne fait pas la
> transformation en PDF aussi avant l'envoi), ce qui est - je suppose -
> globalement équivalent à l'envoi par email de Tryton.

Oui, effectivement l'envoi par e-mail au format PDF depuis LO, en
théorie c'est possible (même si pour moi - Xubuntu 16.04- cela ne
fonctionne pas : pas de pièce jointe). Ceci étant cela n'amène aucune
fonction par rapport à l'envoi depuis l'appli GTK. Et même si cela
fonctionne depuis l'appli Web, cela nécessite LO installé sur le device
... ce qui va, pour moi, à l'encontre de l'atout de l'appli web :
pouvoir être exécuté de n'importe quel device connecté. Si maintenant
juste pour envoyer mon devis, il me faut LO sur le device. :-(

>
> Le problème avec la procédure ci-dessus étant que l'adresse email doit
> être trouvée et mise correctement par l'utilisateur, ce que fait
> l'envoi par email de Tryton (qu'il y a peut-être moyen d'améliorer, je
> n'y ai pas réfléchi).
>
> Il y a quelques avantages au fait d'utiliser le MUA habituel:
>
> - Le logiciel est fait pour ça (mine de rien, ça compte car il y a
> ses habitudes, la correction de l'orthographe, etc)
> - Le logiciel est intégré à son compte de messagerie (en ces temps
> où les gens veulent pouvoir accéder aux infos depuis leurs
> téléphones / tablettes / frigo ça peut être utile).
>
> Au final, mon opinion c'est que Tryton ne doit pas être un MUA ni même
> en simuler un. Par contre, l'intégration passe par le protocole
> mailto: et c'est perfectible ; s'il y a moyen de l'améliorer pourquoi
> pas (bien que je n'aie moi-même pas réfléchi au sujet néanmoins je
> serais très étonné si, sous Windows au moins, il n'y avait pas moyen
> de faire mieux).
>

OK, je vois que nos opinions divergent sur le sujet, et j'en prends note.

[Dominique Chabord]

Bonjour,

Désolé, ce message est long, je n'ai pas eu le talent de faire court :-)

Jusque la, j'ai de la peine à organiser les besoins, les contraintes
et les solutions.

Après discussion avec Cédric, en prenant le temps d'examiner les
différents aspects de la question, j'ai essayé de mettre de l'ordre
dans mes idées et je vous les soumets.

1- Tryton doit pouvoir être facilement utilisable par tout le monde :
depuis une personne seule jusqu'à une société importante qui dispose
d'une infrastructure mail.
Tryton doit donc fournir un service utilisable, sans court-circuiter
une infrastructure aux règles de l'art.

2- Tryton doit rester fiable et simple. Il ne doit pas intégrer des
fonctions qui doivent être administrables hors ERP, comme
l'infrastructure mail.

Ces deux premiers points, doivent nous amener à ne pas reproduire dans
Tryton un client MUA approximatif, comme on pourrait être tenté de le
faire. C'était pourtant l'idée De Sharoon Thomas sur TinyERP, qui a
donné la solution reprise sur Odoo aujourd'hui. Si j'ai bien compris,
NanTic a reproduit cette fonction dans des modules Tryton. Si ça peut
correspondre à des clients particuliers, je suis convaincu que cette
solution ne doit pas être la proposition de base de Tryton.

3- La version actuelle de Tryton évacue le problème de l'envoi de
documents de mails chez l'utilisateur (mailto:). Il est fait
l'hypothèse que l'utilisateur dispose sur un PC d'un outil d'envoi de
mail adéquat. Cela correspond bien au cas où on veut émettre un
message depuis un compte d'un utilisateur identifié et donner à cet
utilisateur la liberté de faire ce qu'il veut avec le document et avec
le message qui l'accompagne.

Ce point 3- est logique pour les documents créés au format ODF dans
l'idée qu'un utilisateur peut vouloir le modifier avant envoi. Le plus
naturel est d'éditer le document sur un PC disposant de LibreOffice et
de l'envoyer par mail sous son identité. (ici, je fais le raccourcis
selon lequel un fichier ODF a vocation à être édité et un fichier PDF
a vocation à être transmis). Cependant, j'ai une nette préférence pour
les solutions qui n'échappent pas au périmètre contrôlé par
l'administrateur du serveur, surtout si on n'a aucune autorité sur les
postes utilisateurs.

4- Il y a un besoin d'automatisation de messages de notification qui
doit être couvert dans l'ERP parce que ces messages doivent être émis
lors d'une progression du workflow. C'est le sens d'un développement
en cours pour un cas réel.

De ce point 4-, il ressort qu'il est normal que l'ERP se charge de
l'envoi d'un message si cet envoi doit être automatisé.
L'automatisation nécessite que tous les paramètres de l'action soit
corrects au moment où l'action se déclenche. Il faut donc que les
informations de contrôles (to: cc: adresse...) et compléments (contenu
du message) soient pré-renseignés quelque part et qu'aucune
intervention manuelle soit nécessaire. Le contenu du message est issu
d'un template. Si le template est compliqué à écrire, il serait
logique d'utiliser un outil indépendant de Tryton, par exemple un
générateur html (moi, je préfère le texte), comme on le fait pour les
documents en utilisant libre office

5- Si un document est créé au format PDF, il est logique qu'on
souhaite son envoi automatique quand il atteint une étape du workflow.
Par exemple, le document devis commande pourrait être envoyé à la
transition brouillon->devis, et/ou devis->commande validée et/ou
validée->traitée etc..

Sur ce point 5-, la contrainte est qu'il faut oublier la modification
manuelle avant envoi, sinon il n'y a plus d'automatisation possible.

6- Alors qu'une notification d'étape n'a de sens qu'à l'instant de la
transition du workflow, la ré-expédition d'un document par la suite
peut avoir du sens dans certains cas. Je pense maintenant que cette
ré-expédition par un bouton peut être considérée comme gadget et qu'on
peut s'en passer.

J'ai été convaincu par les arguments de Cédric à ce sujet. Faut il
faire plaisir à l'utilisateur qui sera rassuré par cette possibilité
ou faut il garder le système le plus simple possible et expliquer
qu'il n'y a pas de bouton parce que c'est mieux qu'il n'y en ait pas ?
Je n'ai pas de doute sur ce qui sera préféré. Le point important est
que dans ce cas aussi, il n'est pas du tout logique de vouloir
transformer le contenu du message avant re-expédition par le serveur,
tout au plus les destinataires et l'objet.

7- Je suis maintenant aussi convaincu qu'il est préférable de ne pas
étendre cette possibilité d'envoi par le serveur vers une fonction de
"message préparé par l'ERP et édité dans l'ERP", à la Odoo. Cela
contrevient aux points 1- et 2-, mais ça ne sera jamais complètement
satisfaisant (je viens de tester sur Odoo et je n'obtiens pas ce que
je voudrais). Il vaut mieux s'imposer la règle simple suivante :
l'ERP traite efficacement ce qui est systématique et l'utilisateur
traite le personnalisé sur sa propre bureautique qui est conçue pour
cela.

Il est logique, sur ce point 7-, de faciliter le travail de l'artiste
en pré-remplissant les champs du mail et l'attachement. Il faut aussi
que la bureautique, l'infrastructure mail et la gestion de la sécurité
soient correctes. Pour ma part, la majorité de mes clients font
n'importe quoi avec leurs postes clients et je leur préconiserai de
contribuer à la réalisation du point 5- pour qu'à terme on puisse
émettre automatiquement des messages standardisés comportant les
documents en attachement directement du serveur.



voili

[Cédric Krier]

On 2017-06-28 09:30, Dominique Chabord wrote:
> 6- Alors qu'une notification d'étape n'a de sens qu'à l'instant de la
> transition du workflow, la ré-expédition d'un document par la suite
> peut avoir du sens dans certains cas. Je pense maintenant que cette
> ré-expédition par un bouton peut être considérée comme gadget et qu'on
> peut s'en passer.
>
> J'ai été convaincu par les arguments de Cédric à ce sujet. Faut il
> faire plaisir à l'utilisateur qui sera rassuré par cette possibilité
> ou faut il garder le système le plus simple possible et expliquer
> qu'il n'y a pas de bouton parce que c'est mieux qu'il n'y en ait pas ?
> Je n'ai pas de doute sur ce qui sera préféré. Le point important est
> que dans ce cas aussi, il n'est pas du tout logique de vouloir
> transformer le contenu du message avant re-expédition par le serveur,
> tout au plus les destinataires et l'objet.

J'ai écrit un blueprint sur ce sujet:
https://discuss.tryton.org/t/re-send-email-notification/386

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com