Note de version 4.04 échéance du 18/02/2022

Note de version pour la mise à jour du 18 février 2022

API ASSURANCES 1
	3967	Anomalie	Bug sur déclarations automatisées
Contrôle des déclarations automatisées et des modifications de dossier.
Commande Collective 6
	4106	Anomalie	Import d’un commentaire dans la commande collective
L’import d’un commentaire via une liste de participant n’est pas pris en compte. Le commentaire apparait bien pendant le process d’import mais n’apparait plus une fois l’import réalisé.
	4098	Anomalie	duplication de lignes de commandes dans la commande collectice
L’enregistrement génère des duplications de lignes.
	4090	Anomalie	Workflow commande collective
certaines commandes collectives disposent de logs antérieurs à la date de création de la commande.
	4054	Evolution	Correction des calculs import ufcv
	3968	Anomalie	Fonction mail de la commande collective
le Pdf de Commande pour un représentant légal ne s’ajoute pas au mail.
	3954	Anomalie	Commande collective- gestion des présence
A la validation d’une commande fille, mon participant est tagué automatiquement en absent. Il doit être considéré comme présent par défaut.
CRM Vackelys 1
	4094	Anomalie	CRM 37 Nom du contact
Dans le crm 37, Il semblerait que les variables « Bonjour #CIVI_CONT #NOM_CONT, » ne gère pas le critère RL ou Client tel que défini dans le profil client. Les mails envoyés aux RL sont avec le nom prénom du Client.
Fonction Commerciale 2
	3931	Histoire	Commande – affectation d’un commercial
chaque commande peut être attachée à un commercial. Par défaut une commande est attachée au commercial lié au client. Si aucun commercial n’est lié au client l’utilisateur qui crèe la commande est automatiquement affecté. Il est possible de changer l’affectation automatique d’un commercial à une commande. Une commande Internet n’a pas de commercial affecté. Un droit est nécessaire. Par défaut ce droit est affecté au super admin et admin. La fonction de modification du commercial est dans l’onglet workflow, au dessus des volets documents et actions. Dans cet espace est aussi déplacé la fonction provenance.
	3930	Histoire	Ecran client – Affectation d’un commercial
Dans le client l’opérateur pourra affecter un commercial. Un commercial est un utilisateur de back office de Vackélys. Prévoir la possibilité d’affecter plusieurs commerciaux. Fonction select2 multiple. Un droit est attaché à cette fonction. Par défaut il faut être superadmin ou admin pour affecter un commercial.
Front office sites mutualisés 8
	4052	Evolution	Tarif par défaut des villes de départ
Dans la table ville il existe un critère « tarif » Ce tarif est par défaut à zéro. Il faudrait que ce tarif soit par défaut vide et non égal à zéro. En effet dans la création des tarifs avec la fonction pré acheminement il n’est possible d’ajouter que les villes dont les tarif est différent de zéro. Certains utilisateurs auraient besoin de publier des offres de pré acheminement à zéro €. Il faudrait modifier la fonction pré acheminement pour n’afficher que les villes dont le tarif est non vide.
	4051	Anomalie	Compte client: Menu mon compte
Ce menu est sur un fond de couleur différent. Du coup si on active un fond de css blanc, ce dernier n’apparait plus.
	4027	Anomalie	Décalage affichage bandeau supérieur
Au niveau du bandeau supérieur, il y a un décalage avec le numéro de téléphone. A partir d’un zoom + 130% le bandeau dépasse en dessous du numéro.
	3960	Anomalie	Marge décalée au niveau de l’hébergement
Sur le front, le contenu présent dans la partie « Situation / Hébergement » n’est pas aligné. La marge disparait.
	3959	Anomalie	Détail destination dans la map
L’onglet « détail » lorsque l’on clique sur une destination de la map est coupé.
	3957	Anomalie	Remontée des saisons séjours type forfait
Les saisons ne remontent pas sur le front pour tous les séjours type forfait.
	3942	Evolution	optimisation page de recherche
Lorsqu’il y a un prix barré l’affichage se chevauche
	2793	Histoire	produit annexe – Modification du process de commande.
Commande front : injecter l’image qui n’est à ce jour pas injectée dans la page de choix de produits annexes. L’image doit représenter 25% de la largeur de la page. Les produits annexes proposés au client sont les produits annexes de type commande plus les produits annexes affectés au séjour commandé.
Module comptable 8
	4047	Anomalie	Export comptable Sage avec Auxiliarisation
L’export comptable présente des erreurs de ventilation Il y a un problème de concordance entre les critères Comptnum du client et le type client
	4014	Tâche	Modification des process de création de clients
Si le type client comprend une matrice, lors de l’enregistrement d’un nouveau client le code client est automatiquement renseigné. Modifier tout les process de création de client dans les commandes et dans commercial<commandes nouveau client
	4013	Histoire	Génération automatisé des codes comptables clients
Permettre une génération automatisé selon un masque prédéfini des codes comptables client. Le principe étant qu’un nouveau client dispose automatiquement d’un code comptable. Configuration<gestion<type client Dans l’onglet Facturation ajout d’un nouveau volet en dessous des paramètres de facturation. « Codes comptable » Matrice des codes comptables : Cette matrice présente un champ texte alphanumérique. L’opérateur pourra alors saisir par type client la matrice souhaitée par type client. Exemple : Si la matrice des types clients particulier est CLS, chaque nouveau client prendra comme code comptable, automatiquement lors de sa création, CLS+ID
	4012	Histoire	Modèle d’export comptable SAGE-Auxiliarisation 11 colones
Développement d’un nouveau format d’export comptable qui déroge aux règles actuellement en place. Il reprend le modèle SAGE avec cette notion de Dans ce modèle: Les colonnes EcritureNum, JournalLib, ComptLib, ComptAuxLIb ne sont pas remontées. Une colonne type de pièce est ajoutée : Elle remonte BQ pour les journaux de banque Elle remonte FC pour les journaux de vente La colonne CompAuxNum remonte le code analytique de la catégorie mère du séjour. La colonne Ecriturelib est codée de la façon suivante : CO353 – NOM DU CLIENT / SEJOUR / DATE DE SEJOUR ou s’il s’agit d’un produit annexe ou d’une remise CO334 – ASSURANCE – NOM DU CLIENT / SEJOUR / DATE DE SEJOUR Il n’y a pas une colonne débit et une colonne crédit mais une colonne avec C ou D et une colonne Montant Le critère analytique est géré par trois type de lettre dans la colonne EcritureLet Si journal de banque ou OD la lettre G est injectée Si journal de vente: La contre partie client 4XXXXXX la lettre X est injectée Chaque ligne de produit est doublé avec une lettre G et une lettre A Une colonne Etablissement est ajouté avec la mention SIEGE ——————- Journal de banque : Dans cet export particulier le journal de banque n’est pas lié à la banque mais au mode de règlement. Evolution de la table règlement. Création d’un critère journal non obligatoire. Chaque écriture de banque comporte donc le journal du règlement et le compte attaché au règlement quelques soit le règlement. (chq, cb, prl…)
	4002	Histoire	Evolution des tables de données pour exports comptables spécifiques
Les tables de données suivantes s’enrichissent d’un critère Code Analytique. Suivant les exports comptables validés ces derniers pourront venir prendre ce code spécifique. Tables dans lesquelles intégrer ce code analytique Saisons Activités Catégories Destination
	4001	Histoire	Modification de la table factures de services pour remonté analytique en comptabilité.
Le principe de cette évolution permettre à une instance de pouvoir remonter des critères analytiques pour des factures de service et de pouvoir, par exemple rattacher un produit facturé au sein d’une facture au code analytique d’un séjour. Lors de la création d’une facture de service et pour chaque produit ajouté injection d’un nouveau critère « Code Ana » (critère alpha numérique) situé entre la description et le prix unitaire. A l’enregistrement de la facture le code analytique est stocké en Bdd Le code analytique reste modifiable même une fois que la facture est validée. Il n’est plus modifiable lorsque cette facture est exportée, tout comme les règlements attachés.
	4000	Histoire	Export comptable avec auxiliarisation – Analytic
Sur la base de l’export comptable standard; création d’un nouvel création d’un codage analytique spécifique en 5 critères. Voir document ci joint : Sur la base de l’export comptable standard Modification du codage analytique: Le codage analytique remonte actuellement dans la colonne « datelet » du fichier csv un code analytique comprenant MMCodeaffaire MM=mois du départ Code affaire = code affaire renseigné dans le séjour. Ce codage dynamique est remplacé par le codage ci après ————————————– Descriptif du codage analytique + journal de vente : Factures de séjours de type FA, FAV+ code en 7 critères Critère 1 : Première lettre organisateur Entité Maître Critère 2 : Code comptable table destination Créer ce critère en back office écran <destination: champ alphanumérique Critère 3: Code comptable table catégorie Créer ce critère dans l’écran configuration<production<séjours<catégorie: champ alphanumérique Un séjour pouvant être attaché à plusieurs catégories; remonter le code de la catégorie mère. critère 4 : Code comptable saison : Créer ce critère dans l’écran configuration<production<séjours<saisons : champ alphanumérique le test se réalise sur la date de départ de la commande. Une date de départ pouvant être éligible à plusieurs saisons l’opérateur devra éviter de créer des saisons à chevauchement ou renseigner le même code comptable sur les saisons en chevauchement. Si le cas se présente le programme validera la saison disposant du plus petit ID. Critère 5 : ID séjour : format numérique à 3 chiffres : l’ID du séjour 1 sera remonté suivant le format 001. Critère 6 : Second chiffre de numérotation de l’ID Séjour Critère 7 : 3ème chiffre de numérotation de l’ID Séjour > Journal de vente : factures de services type FAS Un champ code comptable est disponible dans chaque produit de la facture de service. Il devra être renseigné par l’opérateur comptable avant export comptable. Il sera remonté tel quel dans l’export comptable colonne « datelet » ——————— Module social: modification de l’export salariés dans Social<contrat<Menu action Ajout d’une colonne à l’extrémité du fichier csv « Code analytique » Ce code est alimenté par le même codage Le test se réalise sur la date de début de contrat. Si le contrat n’est affecté qu’à une destination sans séjours le code injecté sera 000 Ainsi on obtiendra TDCH000 si l’animateur dispose d’un contrat sur l’hébergement du séjour 001 sans qu’il ait été affecté au séjour 001 Le code sera TDCH001 si l’animateur est affecté au séjour 1 dans son contrat de travail sans être spécifiquement affecté à la destination D
	3914	Histoire	Export comptable avec auxiliarisation et analytique format EBP
Création d’un nouveau format d’export comptable: Nom : Export comptable avec auxiliarisation format EBP L’import EBP ne peut gérer deux types d’information différentes dans une même colonne. Ce qui est actuellement le cas dans l’export standard avec auxiliarisation. En effet dans la colonne Compte Auxiliaire Num (colonne G) ne peut contenir des données analytiques en liens avec le produit et un compte auxiliaire client. Dans cet export EBP nous déportons les éléments suivants dans la colonne « Date Lettrage » (colonne O) Dans un journal de vente les lignes produit (comptes 7) sont ventilés dans la colonne O au lieu de la colonne G Cet export intègre aussi un plan analytique Colonne N : renommée plan analytique On injecte dans cette colonne « Séjour » si compte compris entre 7041100 et 7042900 On injecte dans cette colonne « Fonctionnement » si comptes compris entre706100 et 790000 Rendre cette gestion dynamique par un paramétrage en configuration<comptabilité En dessous de la liste des comptes types mettre un volet « Plan analytique » intégrez les champs permettant de paramétrer les libellés et les plages de comptes.
Module Multi Enseignes 3
	4029	Anomalie	Filtre enseigne non fonctionnel
Le filtre enseigne de l’écran stock-planning doit remonter les périodes pour lesquelles il y existe des commandes sur l’enseigne sélectionnée
	3956	Evolution	Intégration filtre enseigne
Ajouter une colonne avec filtre pour les enseignes sur les écrans suivants: – Alertes – Tableau de bord : Commandes sans carnet de voyage – Tableau de bord : Commandes sans convocation – Tableau de bord : Dossiers incomplets – Tableau de bord : Commandes abandonnées – Écran liste devis – Écran liste facturation – Ecran liste avis Ajouter un filtre enseigne: – Onglet revendeur dans la fiche client collectif
	3929	Evolution	Multi enseigne écran liste séjours
Intégration d’une colonne enseignes à coté de la colonne organisateur. Le filtre par enseigne devra être fonctionnel
MODULE SEPA 14
	4110	Tâche	Gestion SEPA Compte tiers back office
Lors de la création d’un mandat de prélèvement SEPA en back ou front les informations bancaires iban bic sont injectées dans le compte du tiers (client ou RL) Si un mandat de prélèvement est validé on retrouve les mandats dans un nouvel onglet à droite de factures de services : « Moyens de paiement » On retire de l’écran principal les informations liées à l’iban.
	4093	Histoire	Ecran commercial<règlement<virements
Ce nouvel écran centralise l’ensemble des règlements de type virements disposant d’un signe négatif. l’écran reprend la présentation de l’écran de prélèvement SEPA la colonne date prélèvement est remplacée par date virement. la colonne n° de RUM est remplacée par Iban (est injecté dans cette colonne l’iban du tiers destinataire du virement) Un menu action présente les fonctions imprimer, exporter et généré un fichier de virements La génération d’un fichier de virement contrôle l’existence d’un iban valide pour le tiers On ne peut regrouper dans un fichier que les virements émis depuis une même banque La génération d’un fichier de virement alimente la colonne date virement. Cette date alimente la date de valeur du virement. Un onglet historique permet de retrouver tous les fichiers de virement déjà émis et présente le fichier xml ainsi qu’un fichier pdf. lorsqu’un virement est attaché à un fichier xml il n’est plus modifiable dans la commande.
	4033	Tâche	Modification de la table comptes bancaires
dans configuration<gestion<comptes bancaires ajout du critère : N° ICS Identifiant du créancier – ICS (Prélèvement Ce numéro sera injecté dans les fichiers XML de prélèvement
	3898	Tâche	Traitement des règlements par prélèvement dans la commande
Un nouveau mode de règlement est créé en table règlement: Le prélèvement : PRL type Rgt immédiat Il est intégré en datafixture et non modifiable Pour chaque mandat de prélèvement signé par le client les lignes de règlement PRL sont injectées dans la commande libellé « Prélèvement n° « date : date de l’échéance Mode : PRL Lors du passage du statut « transmis » à « Payé » du prélèvement réalisé dans l’écran Commercial<règlement<prélèvements le règlement devient non modifiable dans la commande. Le premier PRL sous statut payé fait passer la commande du statut option vers le statut validée. A coté du bouton « Paiement CB » présence d’un bouton action « Prélèvement ». Cette fonction permet à l’opérateur de générer un prélèvement automatique et d’alimenter le calendrier des échéances. Il valide la date de prélèvement théorique. Lors du clic sur ce bouton si aucun mandat de prélèvement n’est attaché au client le process ouvre la fonction de création du mandat. Si le mandat existe déjà l’opérateur peut directement saisir le prélèvement. la validation de l’échéancier de prélèvement génère les lignes de PRL en compte client et en back.
	3897	Histoire	Commercial<règlements<prélèvements
Ce menu est localisé sous règlement multiple l’écran présente un écran équivalent à celui des règlements. La colonne tiers payant n’est pas présente. La colonne N° de remise est remplacé par N° RUM; (Référence Unique de Mandat) Référence générée automatiquement pour chaque mandat de prélèvement validé. Une colonne statut est présente à droite. (5 statuts possibles En attente, Emis, transmis, payé,archivé). Statut en attente à la création. Dans cet écran est injecté l’ensemble des échéances de Prélèvements validés. Par défaut ne sont affichés que les échéances dont statut = En attente Un menu action<générer un prélèvement est présent. Cette fonction génère un fichier de prélèvement SEPA en XML regroupant l’ensemble des échéances sélectionnées. La colonne statut bascule au statut « Emis » Etant donné que le compte bancaire attaché au mandat SEPA peut évoluer dans le temps, le process de génération du fichier XML devra prendre en compte les références bancaires actives au moment de la génération du fichier et non forcément celles active le jour de la génération du mandat. Chaque fichier XML généré dispose d’une référence unique au format PS-AAMM-XXX. Un onglet historique est présent Il présente à la manière des historiques de remise de chèque, le détail de chaque bon de prélèvement et présente un picto XML permettant de télécharger le fichier de prélèvement. Une colonne pdf est également présente permettant de télécharger un fichier pdf des prélèvements. Ce fichier reprend le template des remises de chèques. l’ID est représentée par la ref PS-AAMM-XXX Une colonne statut est présente. Par défaut les fichiers ont le statut « émis » Le menu action est présent dans cet écran historique. Il permet de passer l’ensemble du fichier et des prélèvements intégrés à « transmis » puis à payé. Un menu action<Transmis permet de taguer le fichier de prélèvements comme ayant été transmis à la banque Un menu action<Payé permet de taguer les échéances de prélèvement comme payées. Avant de pouvoir valider le paiement l’opérateur doit renseigner la date d’encaissement en banque. Date qui sera injectée dans l’onglet règlement de la commande. A la manière d’un règlement multiple les commandes sont alors mises à jours les prélèvements sont enregistrés dans l’onglet règlement de la commande. L’opérateur pourra archiver un ou plusieurs prélèvements depuis l’écran de prélèvement. Ce prélèvement prendra le statut archivé. L’opérateur pourra retirer un prélèvement d’un historique: cette action repositionne le prélèvement dans les prélèvements en attente afin qu’il puisse être ré intégré dans un nouveau fichier xml. Le retrait d’un prélèvement de l’historique génère une ligne de prélèvement négatif dans la commande.
	3896	Histoire	Prélèvements : Comptes représentants légaux
Permettre aux RL de pouvoir accéder au prélèvement automatique. Il est possible d’accéder au prélèvement automatique pour un RL dans la mesure où une prise en charge ou quotte part lui est affectée dans la commande. Le calcul de l’échéancier est sur la base de cette quotte part. Les comptes RL bénéficient de paramétrages particulier. Il est ainsi possible de masquer la fonction règlement CB. Il faut associer l’affichage de la fonction Prélèvement à l’affichage de la fonction CB. Un échéancier de règlement par prélèvement pour un RL nécessite d’affecter le participant pour lequel le paiement est prévu dans l’onglet règlement de la commande. L’écran commercial<prélèvement remonte l’ensemble des règlements clients et RL. Il sera possible de générer des fichiers xml de prélèvement mêlant clients et RL
	3895	Histoire	Prélèvement : compte client
le formulaire client de front office s’enrichit du couple IBAN BIC et autres critères bancaires nécessaire au prélèvement automatique. Un menu « Moyens de paiement » est créé Il présente les caractéristiques du mandat de prélèvement. Il peut télécharger le mandat de prélèvement. Il peut supprimer le mandat de prélèvement sauf si des échéances supérieures à date système existe encore. Il peut modifier ces coordonnées bancaires par défaut : A l’enregistrement un nouveau pdf de mandat est généré avecles nouvelles références bancaires. Dans l’onglet règlement le client pourra constater l’ensemble des échéances. (voir histoire 3898) A coté du bouton solder par CB présence d’un bouton Prélèvement automatique. Ce bouton est absent si un échéancier de prélèvement est déjà validé pour la commande. Le process est alors le même que celui du process de commande. la base de calcul de l’échéancier est alors le solde restant à régler si un acompte a déjà été versé. Si le client dispose déjà d’un mandat SEPA le bouton propose directement le calendrier des prélèvements
	3894	Tâche	création d’une fonction d’activation du prélèvement SEPA
Cette fonction permet l’activation du moyen de paiement SEPA en commande front et back. Et l’activation des écrans SEPA front et back – Compte client – Autres écrans back Cette fonction est disponible en configuration<gestion<commande<paiement en ligne
	3893	Tâche	Génération du pdf de prélèvement automatique
Il reprend le modèle de l’histoire mère. les cases de signature sont remplacées par « signé électroniquement le dd/jj/aaaa »
	3892	Histoire	Prélèvement SEPA commande standard
Le même process est proposé en commande standard.
	3891	Histoire	Prélèvement : Modification du process de commande front
Si la fonction prélèvement SEPA est proposée un nouveau module vient s’ajouter en plus du paiement CB et du paiement par autre moyen de paiement. Il faudra donc prévoir une modification de la page étape 5 : Revoir la présentation afin que les trois modes de paiement tiennent sur la largeur de page. Front : Validation du prélèvement SEPA par le client: Si le client clique sur le moyen de paiement SEPA le programme ouvre une fenêtre modale comme pour la transaction CB. Cette dernière comprend les champs de saisie suivant. Certains sont optionnels Nom de la banque* Domiciliation Pays* France sélectionné par défaut. IBAN BIC (faire le point sur la norme SEPA. Normalement si l’iban commence par FR76 la récupération du BIC peut se réaliser de manière automatique via une API) Le couple IBAN BIC est contrôlé A ce sujet pour l’instant nous ne contrôlons que la clé Iban. Nous pourrions contrôler le couple BIC – IBAN. Je n’ai pas trouvé d’open data sur le sujet. Par contre il existe des services peu coûteux pour contrôler un ces deux critères via une api comme https://ssl.ibanrechner.de/ cela peut valoir le coût d’étudier la solution. En dessous est injecté l’échéancier des prélèvements automatiques; La règle étant la suivante Premier prélèvement P1 Jour de validation du prélèvement. Dernier prélèvement Px J-échéance de règlement avant départ Le programme calcul le nombre de mois entre P1 et Px et propose une échéance par mois: P2=P1+30… Px=Jdépart-date échéance CGV. Si l’internaute a saisi l’ensemble des critères obligatoires il peut valider par un système de double clic permettant de valider l’autorisation de prélèvement automatique. La date de validation est stockée. Si le client dispose déjà d’un mandat de prélèvement SEPA lors du clic sur le bouton de paiement par prélèvement la modale affiche directement l’échéancier. L’étape 5 du process de commande est alors affichée. Le client peut télécharger un pdf d’autorisation de prélèvement automatique (voir modèle dans histoire mère comprenant Les informations du client, du formulaire. Le numéro de RUM est rempli. Le mode de prélèvement est RECUR (récurrent) La date de validation est alimentée. La commande reste sous statut option tant que le premier prélèvement n’est pas collecté. Une table permet de stocker l’ensemble des prélèvements valider pour l’ensemble des clients et permettra de contrôler les échéanciers de prélèvement.
	3890	Histoire	Gestion des prélèvements SEPA
Cette histoire regroupe les taches pour : la modification du process de commande front la modification du process de commande back le suivi des fichiers de prélèvement. Dans cette première version les process de transfert de prélèvement seront réalisés manuellement par l’opérateur. Aucune connexion API bancaire n’est envisagée à cette étape de gestion du module. En préambule il faut comprendre que pour pouvoir activer des prélèvements automatiques, l’organisateur doit disposer d’une autorisation de prélèvement automatique qui est attaché au client et non à la commande. Ainsi il sera possible de générer des prélèvements SEPA sur des commandes différentes.
	3889	Tâche	Etude de la documentation SEPA pour codage
Etude de la documentation technique de la norme SEPA pour génération des fichiers xml de génération de fichiers SEPA – fichiers de prélèvements automatiques – fichiers de virement
	3502	Tâche	Etude technique de paiement norme SEPA
Un nouveau client prospect utilise actuellement dans sa solution de gestion le paiement par prélèvement automatique SEPA; SEPA est une norme de transfert de fichiers inter bancaires. Au niveau du client il prend la forme d’un fichier xml qui peut être transféré à sa banque afin d’automatiser des paiements. Un client peut fabriquer sous cette norme, soit des fichiers de virement sepa, soit des fichiers de prélèvement SEPA. Cette norme peut remplacer le paiement CB (par le prélèvement SEPA) et le remboursement CB (par le virement SEPA) Il faudrait étudier la possibilité d’implémenter ce nouveau mode de paiement dans Vackélys. Ci joint des documentations techniques sur la génération du fichier xml. il existe des sites de test des fichiers xml https://www.mesfluxdepaiement.fr/testez-vos-fichiers-sepa/ http://www.azzana-consulting.com/xmlsolver/ Phase 1 Il faut donc estimer le temps de développement pour générer ce fichier xml Sepa à partir d’une liste de règlements saisi sur Vackélys Phase 2: Modification des process Vackélys. Table comptes bancaires : probables modifications, ajout de critères d’identification de la banque qui devront être injecté dans le fichier xml Table entité maître : Fonction proposant l’activation des virements SEPA et fonction d’activation du prélèvement SEPA Process de commande front : Si la fonction prélèvement SEPA est proposée un nouveau module vient s’ajouter en plus du paiement CB et du paiement par autre moyen de paiement. Il faudra donc prévoir une modification de la page étape 5 Front : Validation du prélèvement SEPA par le client: Si le client clique sur le moyen de paiement SEPA le programme ouvre une fenêtre modale comme pour la transaction CB. Cette dernière comprend les champs de saisie suivant. Certains sont optionnels Nom de la banque* Domiciliation Pays* France sélectionné par défaut. IBAN BIC Le couple IBAN BIC est contrôlé A ce sujet pour l’instant nous ne contrôlons que la clé Iban. Nous pourrions contrôler le couple BIC – IBAN. Je n’ai pas trouvé d’open data sur le sujet. Par contre il existe des services peu coûteux pour contrôler un ces deux critères via une api comme https://ssl.ibanrechner.de/ cela peut valoir le coût d’étudier la solution. En dessous est injecté l’échéancier des prélèvements automatiques; La règle étant la suivante Premier prélèvement P1 Jour de validation du prélèvement. Dernier prélèvement Px J-échéance de règlement avant départ Le programme calcul le nombre de mois entre P1 et Px et propose une échéance par mois: P2=P1+30… Px=Jdépart-date échéance CGV. Si l’internaute a saisi l’ensemble des critères obligatoires il peut valider par un système de double clic permettant de valider l’autorisation de prélèvement automatique. La date de validation est stockée. L’étape 5 du process de commande et alors affichée. Le client peut télécharger un pdf d’autorisation de prélèvement automatique (voir modèle ci joint)comprenant Les informations du client, du formulaire. Le numéro de RUM est rempli. Le mode de prélèvement est RECUR (récurrent) La date de validation est alimentée. La commande reste sous statut option Une table permet de stocker l’ensemble des prélèvements valider pour l’ensemble des clients. Compte client: Dans son Workflow il dispose du pdf de mandat SEPA A coté du bouton solder par CB présence d’un bouton Prélèvement automatique Le process est alors le même que celui du process de commande. la base de calcul de l’échéancier est alors le solde restant à régler si un acompte a déjà été versé. le formulaire client de front office s’enrichit du couple IBAN BIC. Back office Le process SEPA est proposé à la fin de la commande standard. Le process SEPA est proposé dans l’écran de modification de commande standard par un menu action. Back office Commercial<règlements<Mandats Ce menu est localisé sous règlement multiple Il reprend le mode de fonctionnement de l’écran d’export comptable. Il présente l’ensemble des fichier de prélèvement SEPA au format XML déjà émis. un clic sur le nom du fichier permet de le télécharger. Une colonne statut (Emis, transmis, payé) est présente. Une fonction Nouveau fichier de prélèvement est proposée Un menu action permettant de taguer un fichier comme « transmis » et comme « payé » est présent; l’écran propose une période avec date du jour en date de fin de période. L’opérateur peut modifier cette période. il présente l’ensemble des échéances comprises dans la période non déjà traitée dans un fichier de prélèvement Une fonction permet de sélectionner toutes les échéances dont date d’échéance <= date système. Un menu action Générer Prélèvement SEPA est proposé. La fonction Action<Payé : traite les échéances du fichier XML et met à jour les commandes en saisissant les règlements avec le mode de règlement prélèvement. Commande onglet règlement A la validation d’un fichier de prélèvement SEPA pour un client il faudrait que l’opérateur puisse visualiser les échéances. La validation d’un mandat de prélèvement écris donc les échéances dans le module de règlement. Ces échéances sont considérées comme des règlements différés qui vont donc solder la commande et éviter les relances automatiques. L’opérateur peut supprimer une ou plusieurs échéances Phase 3 process de virement SEPA Dans la commande l’opérateur peut choisir de rembourser un client en activant le mode de règlement virement sepa. Un nouvel écran est créé commercial<règlement virement SEPA Cet écran liste tous les virements SEPA saisis non traités. Une fonction « Généré un fichier de virement SEPA » permet de générer le fichier xml de virement SEPA. Les Virement SEPA attaché à un fichier sont alors tagués comme traités
Module social 6
	4113	Anomalie	Formulaire de candidature petite annonce
Il est demandé au candidat d’entrer le « numéro de rue » puis son « adresse ». Le champ « numéro de rue » se déverse dans le champ « adresse » en back office. Et le champ « adresse » se déverse dans « complément d’adresse » du back office. Le champs pays de naissance FR est pré-renseigné mais en back office il se retrouve avec USA Il faudrait ré affecter les champs dans les bons critères.
	4107	Evolution	Social<contrats : Export salariés
Optimisation de la gestion des codes pays dans l’export salariés la colonne X Pays de naissance doit être alimenté Il se trouve que ce critère n’est pas obligatoire pour générer un contrat de travail. Il faut rendre ce critère obligatoire (back et Front) en reprenant la liste déroulante déjà proposée dans pays de résidence. Injecter le code iso pays à 2 caractères dans la colonne Y Colonne O : pays de résidence : Ajouter une colonne après la colonne O : Code pays résidence Injecter le code iso Ajouter une colonne civilité à droite de la colonne genre Coder 01 si genre = masculin coder 02 si genre = féminin colonne nationalité injecter le code pays iso Pour cela modification du critère nationalité dans le profil (back et front) remplacer par une liste déroulante pays. colonne iban injecter les iban sans les espaces En front office le moyen de paiement par Iban est pré sélectionné
	4030	Anomalie	Offre d’emploi – critère désignation
Rendre obligatoire le remplissage du champ « désignation » lors de la réponse à une offre d’emploi.
	3991	Evolution	Worflow- log création front
Création d’un log de création de profil par un collaborateur lors de la saisie d’un formulaire de recrutement
	3926	Evolution	Doc animateurs et doc directeurs
Evolution de la gestion des docs animateurs dans les séjours. Les docs peuvent maintenant avoir un tag directeur avec une case à cocher. Ces documents tagués directeurs ne seront consultables que par les directeurs dans leur espace personnel Le programme contrôle dons en front le statut du contrat de travail lié à un statut utilisateur directeur pour la consultation de ces documents.
	3924	Evolution	fontion d’archivage des modèles de contrats
Création d’une fonction archivage d’un modèle de contrat de travail dans configuration<social<modèle de contrats. Un contrat archivé n’est plus affiché dans la liste des modèles. Une case à cocher : « afficher tous les contrats » est présente. Dans l’écran social<contrat fonction création d’un contrat de travail un modèle de contrat archivé n’est pas proposé. Dans l’écran configuration<social<fonction : un modèle de contrat archivé n’est pas proposé.
Module Transport 3
	4078	Anomalie	Pdf feuille de route
Mettre « Je transmets » au lieu de « je transmet ».
	4045	Evolution	Module transport feuille de route – Gestion des J+-1
Un segment de transport peut être paramétré en départ J+1 ou J-1 Cette notion doit être mieux spécifié dans la feuille de route. Un segment avec un critère en J-1 est antérieur à un segment en Jour J Il doit donc être classé en premier dans l’écran « mes déplacements » du compte collaborateur Un segment avec un critère en J+1 est postérieur à un segment en Jour J. Il doit donc être classé en dernier dans l’écran « mes déplacements » du compte collaborateur La feuille de route respecte le même classement des segments. Afin que cette information soit plus claire pour l’accompagnateur le champs ETAPE est enrichie de la date de départ écrite et sur lignée en rouge, si elle est < ou > date du jour.
	4031	Anomalie	Message d’erreur – filtres
Il est impossible de mettre le filtre « ville arrivée » et « ville départ » en même temps. DataTables warning: table id=listeVilleSegment – Ajax error. For more information about this error, please see http://datatables.net/tn/7
SEO VACKELYS 2
	3910	Tâche	Corriger la hiérarchie des balises Head : page ‘produit’
Même principe que la tâche #3909, on va cette fois corriger la hiérarchie des balises Head de la page ‘produit’ Actuellement, la hiérarchie est plutôt maigre, on va l’étoffer en exploitant tout ou partie des sections des contenus existants. La page qui nous sert d’exemple est : https://www.capjuniors.com/vacances-adaptees-les-sens-dans-tous-les-sens Explications : H1 déjà traité dans une tache précédente. H2 : SLOGAN H2 ACTIVITEMERE# H3 ACTIVITESFILLES H2 ENTETES DE PARAGRAPHE H3 1ère phrase de § jusqu’au premier élément de ponctuation. H2 :Formalités obligatoire H3 les formalités H2 : Options disponibles H3 les options H2 les séjours que vous pourriez aimer H3 les séjours H2 les avis Eléments du footer* Enfin nous retrouvons à peu près les même élements du footer que dans les autres pages dynamiques. Nous les reclassons de la même façon.
	3909	Tâche	Corriger la hiérarchie des balises Head des pages dynamiques
Définition : Optimisations de la hiérarchie des balises Head Cette tâche concerne les pages : ‘catégorie’, ‘activité’, ‘pays’, ‘ville’, ‘saison’, ‘age’ Constat général Au fil du temps, la hiérarchie des balises Head de l’ensemble des pages vackélys s’est déstructurée, appauvrissant ainsi leur scoring éditorial. Pour chacune des 6 pages Vackélys concernées, il faut restructurer la hiérarchie des balises Head afin de renforcer la thématique de la page. Les 6 pages sont fabriquées sur le même template déclaratif des balises Head. On peut donc leur appliquer les même corrections avec le ‘Template hiérarchie’ en 3ème colonne. Explications : – L’ECP reste l’unique H1 de la page – Tous les noms de produits affichés dans la page, deviennent des H2 – On prend le slogan de chaque produit affiché, puis on le déclare en H3. On comprend que plus une page dynamique affiche de produits, plus elle alimente la hiérarchie des Head, plus elle renforce le scoring éditorial. Enfin, on reclasse les éléments du footer (informations de navigation de la page qui n’ont rien à faire dans les H2 ou H3) comme indiqué dans le template.
V3-Facturation 6
	3988	Evolution	Facture sur commande archivée
Rendre impossible la facturation d’une commande archivée
	3972	Anomalie	règlement factures de services
On ne doit pas pouvoir saisir de règlements égal à zéro dans le module de factures de services.
	3971	Evolution	Modale de facturation
Ajout d’un champ texte à droite du champ commentaire Notes internes (non publié) Ce champ permet aux opérateurs de noter des informations en lien avec la facturation de la commande.
	3951	Evolution	Intégration du critère « validé » dans la modale de facturation
Intégrer un visuel permettant à l’opérateur de savoir si la ligne de commande présente dans la modale de facturation est validée ou en option dans le cadre de la commande collective. Possibilité de reprendre la coche verte de la commande?
	3947	Anomalie	Facture commande collective
bug autorisant la suppression d’une commande déjà facturée
	3915	Evolution	Règlements dans factures de services;
Dans la liste des règlements disponibles ne remonter que les règlements immédiats. En effet les règlements différés ne peuvent pas être gérés dans les FAS.
VACKELYS 5
	4104	Evolution	pdf de facture
Dans une commande collective certains client vont conserver une ligne de XX pax mais affecter un nom de RL. Cela peut être le cas pour les classes de découvertes. L’opérateur intègre un Nom de RL pour le professeur. Actuellement le nom du RL n’est injecté que si le participant est désigné. Dans cette évolution il faut injecter le nom du RL même si la ligne est en XX NOM PRENOM
	4102	Anomalie	Date de départ érronnée
La date de départ injectée dans le mail de confirmation de commande et dans le pdf de commande est décalée d’un jour.
	4056	Evolution	Gestion de la 404 sur compte RL non validé
Si un RL n’a pas d’adresse mail, son compte personnel n’est pas fonctionnel. Si un opérateur clic sur l’œil e visualisation il est redirigé vers une 404. Il serait préférable de lui afficher un message système lui disant : « Vous ne pouvez accéder à ce compte personnel car le tiers ne dispose pas d’adresse mail. Son espace n’a pas été activé »
	2792	Histoire	Affectation de produits annexes à des séjours.
Permettre à un opérateur de pouvoir vendre des produits annexes qui seraient en lien avec un ou plusieurs séjours. Configuration<gestion<commande<produits annexes: L’opérateur peut dans chaque produit annexe affecter un critère Commande ou un critère Séjour. Par défaut les produits annexes sont attachés à un critère commande. Modification de l’écran séjour Ajout d’un onglet produits annexes listant les produits annexes de type séjours avec tarif et descriptif. L’opérateur peut affecter un ou plusieurs produits annexes au séjour.
	1313	Histoire	Ecran de commande – Problème javascript sur le calcul des arrondis de produits annexes
Suivant le navigateur l’arrondi sur les calculs de produits annexe en % du forfait se réalise sur le 1/100ème de centime sup ou inf. Sur Edge +0.01 sur Chrôme -0.01 Une modification du javascript est mise en place les arrondis seront systématiquement réalisés au 100ème supérieur.
VACKELYS Connect API 7
	3937	Histoire	Envoi de mail en cas d’exception
envoi d’un mail d’alerte automatique au support en cas d’exception au traitement du script Python.
	3936	Histoire	Création d’une page admin pour les erreurs du script de synchronisation
	3935	Histoire	Création des accès sur vConnect pour les superadmins des instances vackélys
	3934	Histoire	création des clés api pour les instances vackelys sur vConnect
dev supernova capj
	3933	Histoire	redirection https de vackelys connect
	3932	Histoire	Création du système d’authentification par lien depuis le back vackélys
	3916	Tâche	Synchro Vackélys Connect supernova – capjuniors
Ci joint le fichier des séjours supernova qui devront être synchronisé sur CAP JUNIORS et qui sont normalement déjà présent sur CAPJ Ainsi que le fichier des séjours CAP JUNIORS qui devront être synchronisés sur supernova
VACKELYS V3 57
	4108	Tâche	CGOS Optimisation ergonomique de la saisie des offres
De manière générale : A l’enregistrement d’un des trois onglets l’opérateur doit se retrouver sur l’onglet sur lequel il était positionné. Onglet règles la fonction de classement du tableau n’est pas fonctionnelle pour les trois colonnes. Onglet markup et Prise en charge Classer les règles dans un ordre inversement chronologique Prévoir un affichage uniquement des règles dont échéances < date système. Prévoir une case à cocher « Afficher les règles archivées » Le bouton enregistrer n’est pas visible en bas à droite. Le positionner plutôt en haut à droite au dessus du tableau. Le renommer « Enregistrer la modification » Modale de création Markup et prise en charge plutôt qu’une liste déroulante simple prévoir plutôt un système de sélection multiple pour les deux critères séjours et types d’offres. Soit des cases à cocher soit un select2 multiples.
	4103	Anomalie	statistique<ca<date de facture
la remontée des volumes présente des incohérences. Les totaux ne sont pas bon.
	4097	Evolution	augmentation du nombre de critère du code supervision
Passage du code supervision de 10 à 16 critères. contrôle de la saisie en front et back et de la taille de champ de saisie
	4083	Anomalie	Liste séjours – dates incohérentes
Dans la liste séjours, les dates injectées dans « Du » et « Au » ne sont pas cohérentes lorsque je n’ai pas de départs dans le futur. Actuellement on affiche de « date du jour » à « dernière date de départ » On peut donc potentiellement obtenir une date de retour antérieur à la date de départ. Évolution du système d’affichage. par défaut l’écran intègre un filtre dans la colonne date de départ équivalent à la date système. Le tableau n’affiche que les séjours disposants d’un départ supérieur à date système. Si l’utilisateur supprime ce filtre l’écran affiche les séjours en reprenant la première date de départ existante en base de données et la dernière date de retour existante en base de donnée.
	4081	Evolution	Sélection des dates dans une commande avec forfait jour ou nuit
Dans les trois modes de commande lors de la sélection de la date de départ, le calendrier de la date de retour doit se positionner sur le même mois que la date de départ et non sur le mois de la date du jour.
	4079	Anomalie	Intégration critère « Niveau dans la discipline principale » dans lliste présent
Intégrer les réponses des participants à la question » Niveau dans la discipline principale » de leur profil dans l’export des stats<Liste-présent.
	4072	Tâche	Intégration d’un nouveau fichier UFCV
L’UFCV a modifié sont fichier d’export des données en rajoutant deux colonnes. Etudier le temps de développement nécessaire pour l’intégration de ce fichier.
	4060	Anomalie	Suppression de rôles
La suppression d’un rôle est impossible s’il existe un « . » ou un caractère spécial dans le titre.
	4059	Anomalie	filtes et exports factures de services
Les filtres de l’écran factures de services ne sont pas tous fonctionnels Les exports n’exportent pas toutes les factures et ne respectent pas les filtres sélectionnés
	4058	Anomalie	Regeneration quotidien des pdf de devis
Bug Cron task
	4049	Anomalie	Export statistiques<liste clients
Il existe un problème d’injection des données dans l’export CSV ajouter adresse et CP
	4048	Anomalie	Affectation des quottes part au RL dans les commandes standards
dans une commande standard si l’opérateur affecte une quotte part au participant : – Cette quotte part n’apparait pas dans la module de règlement, liste déroulante du participant. – Cette quotte part n’est pas remontée dans la modale de facturation. Il n’est de ce fait impossible de facturer un RL
	4039	Anomalie	Suppression séjour – 404
La suppression d’un séjour ayant des séjours similaire affectés entraine une 404. J’ai également l’erreur suivante: http://acsv.vackelys.fr/app_dev.php/_profiler/cb8e7d?panel=exception
	4038	Anomalie	Statut des carnets de voyages individuels
Un carnet de voyage individuel dispose d’un statut valide ou invalide. Lors du passage du statut invalide à valide un mail transactionnel est envoyé au client afin qu’il puisse télécharger l’ensemble des documents qui composent son carnet de voyage. Or il s’avère que si des pièces jointes sont affectées à ce carnet de voyage individuel et que ce dernier est invalide. Les clients peuvent tout de même les télécharger. La disponibilité des pièces jointes et du carnet de voyage groupé dans le compte client doit être lié au statut du carnet de voyage individuel dans la commande. S’il est invalide, le client ne peut visualiser aucune pièce jointe.
	4028	Anomalie	Création de commande – Base prospect
Lors de la création d’une commande, mes prospects ne sont pas proposés dans la liste sélectionnable. Si je reprend l’adresse mail de mon prospect pour créer mon client, on m’informe que l’adresse mail existe déjà. Il faudrait que je puisse sélectionner un prospect existant. Le prospect bascule en client lors de la création de la commande.
	4016	Anomalie	Commande front sur séjours mode de commercialisation adultes
Lors d’une commande d’un séjour commercialisé en mode adulte le RL égal au client créé n’est pas remonté dans la commande standard. Du coup le RL attaché au différents pax restent en Nom Prénom. Par conséquence les coordonnées, adresses… ne sont pas remontés dans certaines listes. Il faut donc bien contrôlé que dans le mode de commande adulte le RL soit bien alimenté. Le RL doit être le participant si le participant est majeur Le RL est le client si le participant est mineur.
	4011	Tâche	Modification des process de commande pour intégration des modèles de documents commerciaux
Modification des 3 process de commande afin de prendre en compte les modèles de documents commerciaux validés dans le client.
	4010	Histoire	Création d’un modèle de commande sans détail ni transport
libellé « commande sans détail » Il reprend le descriptif du devis sans détail. Cette commande reprend le modèle de la commande standard et de la commande collective sans le détail de tarif des options et sans le détail des tarifs des produits annexes. Le tarif du forfait injecté est le tarif terrestre + transport. La colonne transport n’est pas alimentée. Seul les tarifs des produits annexes de type assurance sont injectés. Il en existe une version pour la commande standard et une version pour la commande collective.
	4009	Histoire	Création d’un modèle de devis sans détail ni transport
Nom du modèle « devis sans détail, ni transport » Descriptif : Ce devis reprend le modèle de la commande standard et de la commande collective sans le détail de tarif des options et sans le détail des tarifs des produits annexes. Le tarif du forfait injecté est le tarif terrestre + transport. La colonne transport n’est pas alimentée. Seul les tarifs des produits annexes de type assurance sont injectés.
	4008	Histoire	Création d’un modèle de commande sans détail
libellé « commande sans détail » Il reprend le descriptif du devis sans détail. Cette commande reprend le modèle de la commande standard et de la commande collective sans le détail de tarif des options et sans le détail des tarifs des produits annexes. Seul les tarifs des produits annexes de type assurance sont injectés. Il en existe une version pour la commande standard et une version pour la commande collective.
	4007	Histoire	Création d’un modèle de devis sans détail
Nom du modèle « devis sans détail » Descriptif : Ce devis reprend le modèle de la commande standard et de la commande collective sans le détail de tarif des options et sans le détail des tarifs des produits annexes. Seul les tarifs des produits annexes de type assurance sont injectés.
	4006	Tâche	Modification de la table client
Un nouvel onglet est intégré Docs Commerciaux Il reprend le paramétrage du type client Mais l’opérateur a la possibilité de déroger à la règle du type client en choisissant un nouveau modèle de documents.
	4005	Histoire	Modification de la table type client – ajout des modèles de documents commerciaux
Pour chaque type client l’opérateur peut définir un modèle de documents Un nouvel onglet est ajouté : Doc Commerciaux Une liste déroulante permet de choisir le modèle pour les devis et le modèle pour les commandes. Par défaut le modèle est le modèle est le modèle standard. Pour chaque modèle choisi, le descriptif du modèle est injecté à droite de la liste déroulante.
	4004	Histoire	Gestion de modèles de documents commerciaux
A ce jour il est possible de modifier les modèles pdfs des factures mais il n’existe qu’un seul modèle de devis ou commandes. Cette histoire a pour but de créer des modèles de Devis ou Commandes. Par définition : les modèles actuels seront les modèles standard Les autres modèles disposeront d’une nouvelle dénomination. Un modèle de documents commerciaux pourra être défini par type client, puis par client.
	3994	Evolution	PDF convocation transport
Il faut recadrer un peu les champs – Le bloc adresse : Un peu plus à gauche et un cran plus haut – l’url du site internet : Remonter d’une ligne – les bloc gris injectant la date : il est trop haut. Il pourrait contenir 3 lignes alors que seulement 2 sont injectées. – Enlever deux interlignes entre le moyen de transport qui est en bold et le descriptif du déplacement Supprimer le champ « N°d’agrément DDCS » lorsque celui ci est vide ou que le séjour est tagué comme le disposant pas d’agrément. Dans les blocs gris, supprimer « arrivée le » lorsque date départ = date retour. Changer « mode de transport » en « Moyen de transport ».
	3989	Anomalie	Erreur 404 paiement des RL sur le front
Les RL ne peuvent plus payer sur le front.
	3986	Anomalie	pdf liste transport dans statistique
Le logo est dupliqué.
	3982	Anomalie	Alertes non mises à jour
Le nombre d’alertes affichées dans le tableau de bord et au niveau de la cloche ne sont pas les mêmes. Voir PJ.
	3979	Anomalie	Format pdf remise de chèque
Rebasculer le pdf des remises de chèques en format paysage.
	3978	Histoire	Tiers payant mark up
la structure de la bdd des services pour calcul markup et pec, obtenir liste séjour et liste départ interface dans le page tiers payant
	3977	Anomalie	Recherche clients auto-completion backoffice
Dans la recherche clients la recherche auto complétion et l’affichage doit se faire sur le nom et le prénom pour un type particulier sur la raison sociale pour un type professionnel
	3973	Evolution	Comptes clients
Dans l’onglet commande Ajout d’une colonne « Règlements » entre Total et Solde On remonte les règlements attachés à la commande
	3965	Evolution	Optimisation Ergonomie – Commande collective – convention
le menu convention passe très rapidement en seconde ligne suivant le zoom ou la taille de l’écran. Renommer le menu en « Convention » plutôt que « Ajouter une convention » Contrôler que ce menu reste sur la même ligne que les autres.
	3964	Evolution	Optimisation ergonomie – onglet workflow de la commande
Avec la commande collective les données remontées dans l’onglet workflow, que ce soit pour l’espace Action ou l’espace documents peuvent être très long. Intégration d’un ascenseur sur ces deux espaces au delà de 10 lignes. Pour les commandes collectives et les commandes standards.
	3963	Evolution	Optimisation Ergonomie – gestion des menus.
L’utilisation des menus latéraux nécessite souvent de nombreux allers et retours sur les menus après enregistrement. Proposition d’intégrer des menus verticaux déroulant dans les fils d’Ariane afin que l’opérateur puisse naviguer de manière plus fluide. Le passage de la souris sur un menu du fil d’Ariane déroule l’ensemble des sous menus La fonction permettant au menu latéral de se replier, laisse apparaitre la ligne du fil d’Arianne
	3962	Anomalie	Création d’un participant dans une commande standard
Lors de la création d’un participant dans une commande standard : sélectionner<nouveau participant: Un message system informe l’opérateur que le participant a bien été créé, cependant il est nécessaire de recharger la commande pour que ce dernier apparaisse dans la liste des participants. Faire évoluer la fonction afin que l’opérateur puisse constater cette création dès l’enregistrement
	3961	Evolution	Optimisation – Attestation de présence
A corriger: La variable option ne remonte pas les options de la commande. Ajouter les variables suivantes: – Adresse RL – Adresse client – Age participant – Adresse du séjour – Durée du séjour – Date d’édition du document (JJ/MM/AA) – N° DDCS – Surcoût lié au handicap – Quote part client – Quote part RL – Enseigne – Adresse de l’entité maître
	3958	Evolution	Blocage modification date séjours type forfait
Si l’on fait une erreur lors de la saisie de nos dates à la création d’un séjour type forfait, le champ date n’est plus modifiable. Par contre, il est possible de modifier via le calendrier. La modification ne s’enregistre pas, mais cela porte à confusion. Il faut soit rendre tout modifiable et ne rien griser, soit tout griser pour que l’on ne puisse pas modifier. A voir selon ce qui a été développé initialement.
	3955	Anomalie	Ecran facturation
Dans l’écran Commercial<Facturation le total indiqué dans le tableau n’est pas bon. Il n’est pas sur la bonne colonne et ne correspond à rien.
	3953	Evolution	Affichage écran destination
Sur l’écran des destinations, on affiche en localisation PAYS – Code postal. Il faudrait pour plus de facilité à rechercher, ajouter la commune.
	3952	Evolution	Gérer des destinations sans hébergement
Dans le cadre de journées récréatives notamment, le séjour n’est pas rattaché à un hébergement. Il est alors nécessaire de créer une destination « SANS HÉBERGEMENT ». Aujourd’hui, tous les champs liés à l’adresse de la destination sont obligatoires. Il faudrait pouvoir intégrer un code postal type « 00000 » qui serait relié uniquement à la France pour réutiliser cette destination sur toutes les journées récréatives. Au niveau du front on a l’affichage suivant: commune – Département – n° département – Pays. Il faudrait avec ce fonctionnement n’afficher que le Pays.
	3950	Anomalie	Affichage PDF
Commande et devis: Champ libre top position doit se situer en dessous du logo. De ce fait, le Champ libre baseline descend et le titre aussi. Le Champ libre pied de page ne remonte pas. Pour les commandes, pourquoi mon « Champ libre 1 » et « Champ libre 2 » remontent ? Ce n’est pas que pour les devis et factures? Facture: Champ libre top position et Champ libre baseline sont inversés. Le bloc « facture, ref, date, total » est trop proche du tableau et du champ libre 2 lors d’une proforma. (Et du tampon facture acquittée lorsque c’est le cas). Le Champ libre pied de page ne remonte pas. Facture de service Champ libre top position doit également descendre sous le logo. J’ai aussi Champ libre 2 mais pas tous les autres champs
	3949	Anomalie	Le même email pour deux client sur Capj
client: 56384 et 52387
	3948	Anomalie	Pdf Remise de chèques
Suite à la refonte du module de pdfs, les remises de chèques ne sont plus générées
	3946	Anomalie	Config > Pays
404 a l’ouverture de la page
	3945	Anomalie	Alertes mails
Les alertes mails ne doivent plus remonter.
	3944	Anomalie	Problème affichage facture de service
Les pdf des factures de services ne s’affichent pas correctement
	3943	Anomalie	Bug commandes annulées
Les commandes annulées ne doivent plus être modifiables.
	3940	Anomalie	Description produit dans facture de service
La description d’un produit dans une facture de service disparait lorsque l’on ajoute un règlement.
	3925	Evolution	Duplication de séjours – Ajout de critères
Ajouter les critères docs animateur et docs clients lors de la duplication de séjour.
	3920	Tâche	Injection des tags de suivis dans commandes non soldées
Une colonne Tags est injectée dans l’écran commandes non soldées Elle est injectée à gauche de la colonne facture. l’opérateur pourra filtrer par Tag
	3919	Tâche	Intégration des tags de suivis dans les commandes.
Commande et collective standard Onglet règlement modification du template Ajout d’un volet « tags de suivis » sous le volet règlement. Une fonction select2 multiple permet de sélectionner un TAG A l’enregistrement la date de saisie du tag est également enregistrée. Elle apparait en tooltype du tag
	3918	Tâche	Gestion des tags de suivi de commande
Modification de l’écran configuration<gestion<commandes<provenance il est renommé configuration<gestion<commandes<Tags Cet écran comprend deux onglets l’onglet provenance Un nouvel onglet Tags de suivis A la manière de l’écran provenance l’opérateur peut créer des tags.
	3901	Histoire	Contrôle des doublons de participants
lors d’une commande Pendant la saisie du participant le programme contrôle un potentiel doublon. Le contrôle s’effectue sur le Nom + prénom + date de naissance. le contrôle s’effectue sur l’ensemble des participants quelque soit le RL et le Client. Une modale s’affiche à l’opérateur pour l’informer d’un potentiel doublon. Les potentiels participants est en litige sont écrits en rouge.
	3900	Histoire	Gestion d’un critère litige sur participant
L’opérateur pourra taguer un participant en litige. le nom du participant s’affichera en rouge dans la commande et lors de la création de commande standard.
	3899	Evolution	Enseignes dans commercial<commandes
Ajoute d’une colonne Enseignes dans commercial<commande
	3856	Anomalie	Date d »échéance de l’option dans une commande standard
La date d’échéance d’une option dans une commande standard ou dans une commande internet doit être bornée à J-1 avant date de départ. Elle ne peut être après le départ. Modification également de la donnée injectée dans le pdf de commande.