Projet

Général

Profil

Anomalie #14874

Les champs de fusion sont remplacé par le dernier expéditeur lors d’un projet de réponse par publipostage en utilisant un modèle onlyoffice

Ajouté par Robin SALDINGER il y a plus de 3 ans. Mis à jour il y a presque 3 ans.

Statut:
Clôturé
Priorité:
2-Sérieux
Assigné à:
Version cible:
Début:
20/07/2020
Echéance:
Version applicable MC:
Tags Courrier:

Description

Message du client :

Étape :
- Créer un courrier arrivé avec plusieurs expéditeur
- Cliquer sur ajouter une pièce jointe
La pièce jointe est en mode publipostage
- Sélectionner un modèle de document comportant des champs de fusion

Constaté :
Les champ de fusion sont remplacé par les informations du derniers expéditeur de la liste

Souhaité :
avant le clic sur «publiposter» les champs de fusion ne sont par remplacés
au moment du publipostage, les champs de fusions sont remplacé pour chaque expéditeur du courrier départ

En pièce jointe le modèle de document utilisé

Analyse de Maarch :
Henri :

Bonjour,

Il semble que les champs de fusion utilisés ne sont pas les bons .

Vous utilisez les champs de fusion :

Destinataire
Les champs listés ci-dessous ne sont disponibles qu'avec un seul destinataire.
Libellé Champs de fusion
Civilité du contact [recipient.civility]
Prénom du contact [recipient.firstname]
Nom du contact [recipient.lastname]
Société [recipient.company]

Il faut utiliser les champs de fusion de cette partie de la doc:

Destinataire de la pièce jointe
Libellé Champs de fusion
Civilité du contact [attachmentRecipient.civility]
Prénom du contact [attachmentRecipient.firstname]
Nom du contact [attachmentRecipient.lastname]
Société [attachmentRecipient.company]
Service de la société [attachmentRecipient.department]
Fonction du contact [attachmentRecipient.function]

Ci-dessous la doc en ligne pour les champs de fusion:

https://docs.maarch.org/gitbook/html/MaarchCourrier/20.03/guaf/guaf_templates/merge_fields.html

Bien cordialement,

-------> retour négatif du client

Robin : Après vérification il s’avère que les champs de fusion évoqués par Henri ne sont pas interprétés. Si le client publiposte un projet de réponse avec les champs de fusion qu'il utilisait initialement, le projet de réponse est dupliqué en x versions mais avec toujours le même contact.

Voir ticket client pour plus d'informations

lettre_adjoint_-_septembre_2016-sans-en-tete-bloc-signature.docx (23,7 ko) lettre_adjoint_-_septembre_2016-sans-en-tete-bloc-signature.docx François-Xavier Lyonnet du Moutier, 20/07/2020 15:07
Screenshot_2020-07-20 MAARCH COURRIER 20 03.png (44,3 ko) Screenshot_2020-07-20 MAARCH COURRIER 20 03.png François-Xavier Lyonnet du Moutier, 20/07/2020 15:09
Screenshot_2020-07-20 MAARCH COURRIER 20 03(1).png (92,1 ko) Screenshot_2020-07-20 MAARCH COURRIER 20 03(1).png François-Xavier Lyonnet du Moutier, 20/07/2020 15:10
Screenshot_2020-07-20 MAARCH COURRIER 20 03(2).png (84,4 ko) Screenshot_2020-07-20 MAARCH COURRIER 20 03(2).png François-Xavier Lyonnet du Moutier, 20/07/2020 15:13
Screenshot_2020-07-20 MAARCH COURRIER 20 03(3).png (13 ko) Screenshot_2020-07-20 MAARCH COURRIER 20 03(3).png François-Xavier Lyonnet du Moutier, 20/07/2020 15:13
Screenshot_2020-07-21 MAARCH COURRIER 20 03(3).png (73 ko) Screenshot_2020-07-21 MAARCH COURRIER 20 03(3).png François-Xavier Lyonnet du Moutier, 21/07/2020 11:53
Screenshot_2020-07-21 MAARCH COURRIER 20 03(4).png (83,3 ko) Screenshot_2020-07-21 MAARCH COURRIER 20 03(4).png François-Xavier Lyonnet du Moutier, 21/07/2020 11:54
Screenshot_2020-07-21 Parapheur Electronique.png (122 ko) Screenshot_2020-07-21 Parapheur Electronique.png François-Xavier Lyonnet du Moutier, 21/07/2020 11:55
1.png (108 ko) 1.png Robin SALDINGER, 19/10/2020 17:03
2.png (103 ko) 2.png Robin SALDINGER, 19/10/2020 17:03
lettre_adjoint_-_septembre_2016-sans-en-tete-bloc-signature_piecejointe.docx (23,4 ko) lettre_adjoint_-_septembre_2016-sans-en-tete-bloc-signature_piecejointe.docx Robin SALDINGER, 19/10/2020 17:04
6003
6004
6005
6006
6007
6008
6009
6293
6294

Historique

#2 Mis à jour par Support Maarch il y a plus de 3 ans

  • Statut changé de A qualifier à A traiter

#3 Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de A traiter à 17
  • Assigné à changé de Emmanuel DILLARD à Robin SALDINGER

Reproduit avant inscription backlog ?

Non reproduit en 20.03.11.

  • Courrier Arrivée
  • 4 expéditeurs
  • édition de PJ via OnlyOffice (modèle PR générique)
  • validation
  • Bouton publipostage
  • PJ sont bien générées pour chaque destinataire (avec les bonnes informations pour chaque contact)

Les champs de fusion utilisés par le modèle sont :

attachmentRecipient.XXXXXXX
exemple : attachmentRecipient.postal_address

Voir documentation sur https://docs.maarch.org/gitbook/html/MaarchCourrier/20.03/guaf/guaf_templates/merge_fields.html

Note : les champs utilisés dans le modèle en pièce jointe à ce ticket ne sont pas adaptés au publipostage.

Solution : Modifier le modèle avec les données de fusion adaptées (voir modèles génériques PR)

#4 Mis à jour par Robin SALDINGER il y a plus de 3 ans

6293
6294

Tests effectués par le client :

Bonjour,

Je constate toujours le problème, malgré la discussion avec Emmanuel Dillard.

J’ai testé sur la demo : http://demo.maarchcourrier.com/apps/maarch_entreprise/index.php#/process/users/9/groups/2/baskets/4/resId/21

En pièce jointe mon modèle de document.


#5 Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de A traiter à Complément d'Informations
  • Assigné à changé de Emmanuel DILLARD à Robin SALDINGER

Le document transmis ne fusionne pas correctement la variable utilisée.
En remplaçant la variable de fusion dans le modèle par copier/coller, le publipostage fonctionne correctement avec le modèle soumis pour tests.

[attachmentRecipient.postal_address;strconv=no]

La paramètre strconv=no concerne les sauts de ligne sur certaines versions plus anciennes de MS Word qu n'étaients pas pris en compte

Avec OnlyOffice, privilégier :

[attachmentRecipient.postal_address]

-> il y a peut-être une coquille sur le document original

#6 Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de Complément d'Informations à 17

#7 Mis à jour par Robin SALDINGER il y a environ 3 ans

  • Statut changé de 17 à A traiter
  • Assigné à changé de Robin SALDINGER à Emmanuel DILLARD

Plus de nouvelles depuis 4 mois suite à la dernière solution apporté, à marquer comme résolu.

#8 Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Statut changé de A traiter à Clôturé

#9 Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Projet changé de Backlog à Backlog Courrier
  • Version cible changé de 20.03 (Fin de vie) à 20.03 (Sécurité)

Formats disponibles : Atom PDF