Nouveautés
Finance - Factures
- Création d'avoir : motif de suspension et politique de suspension liés à des suspensions d'avoir - Jira-13225
Dans le cadre de la Recherche & Développement (R&D), l'équipe Produit a amélioré la gestion des factures d'avoir en proposant des motifs de suspension adaptés à toutes les configurations.
Paramétrage des motifs de suspension :
Le paramétrage des motifs de suspension s'effectue depuis Gestion - Suspensions et trois menus déroulants sont disponibles dont : motifs et politiques de suspension.
Si l'utilisateur clique sur la référence d'un des motifs, il a accès à deux nouvelles cases à cocher.
- La case à cocher "suspension d'avoir" est cochée - Le motif de suspension sera proposé lors de la création d'un avoir sur la facture
- La case à cocher "suspension d'avoir par défaut" est cochée - Le motif de suspension associé sera proposé par défaut lors de la création d'avoir depuis la facture. Un seul motif peut avoir cette case de cochée
Vigilances : - C'est bien la politique de suspension qui pilote, par conséquent, il faut que l'option "suspendre abonnement" soit bien cochée si l'utilisateur souhaite que les abonnements soient suspendus automatiquement après la création de l'avoir.
- Un motif de suspension de type avoir doit être associé à un type abonnement.
Paramétrage des politiques de suspension :
Si le motif de suspension est Suspension (Avoir), le type de ratio (mode de calcul) pour l'avoir sera restreint à : sans proratisation (total) ou sur reste à livrer (prorata)
Ajout de 8 motifs de suspensions d'avoir/politiques de suspensions :
Huit motifs de suspensions relatifs aux avoirs ont été créés et sont présents par défaut, dans la liste des motifs.
Ces motifs sont les suivants :
- Avoir total avec remboursement avec suspension
- Avoir total sans remboursement avec suspension
- Avoir partiel avec remboursement avec suspension
- Avoir partiel sans remboursement avec suspension
- Avoir total avec remboursement sans suspension
- Avoir total sans remboursement sans suspension
- Avoir partiel avec remboursement sans suspension
- Avoir partiel sans remboursement sans suspension
Le libellé est modifiable par l'utilisateur s'il le souhaite, en cliquant sur la référence du motif. Ces motifs sont tous topés "Suspension d'avoir".
En parallèle de l'ajout des 8 motifs ci-dessus, 8 politiques de suspensions ont également été paramétrées par défaut.
Leurs libellés sont similaires aux libellés des motifs. 
En cliquant sur la référence, l'utilisateur ouvre le paramétrage de la politique de suspension associée.
Exemple ci-après :
Si l'utilisateur crée une facture d'avoir avec le motif ci-dessous, un avoir total sera donc créé, l'abonnement sera suspendu.
L'avoir sera total et le règlement de l'avoir (remboursement) sera créé.
En tant qu'éditeur, vous avez la possibilité de modifier le paramétrage de votre politique. Si vous détenez un environnement de préproduction, notre préconisation est d'effectuer le paramétrage sur cet environnement dans un 1er temps, afin de s'assurer que cela répond bien à vos besoins et que le paramétrage est conforme à votre politique de gestion des abonnements.
Création d'un avoir sur la facture :
Cette fonctionnalité est accessible depuis la facture de l'abonné directement où avec la fonctionnalité "..." l'utilisateur peut faire "Ajouter un avoir"
La pop-up suivante s'affiche : dans les motifs proposés, il s'agit de ceux pour lesquels la case "suspension d'avoir" a été cochée.
Comme indiqué, si l'utilisateur ne sélectionne aucune ligne de facture, l'avoir portera sur l'ensemble de la facture.
Vigilance : Un message d'alerte n'apparaît pas si l'utilisateur souhaite créer un avoir sur une facture qui n'a pas de règlements
Selon le motif sélectionné et la politique associée, l'abonnement sera suspendu ou non, remboursé ou non, d'un avoir total ou partiel.
Exemple avec le motif "Motif d'avoir : Avoir total avec remboursement avec suspension "
* Sur la facture d'avoir, la mention "motif d'avoir : XXX" est présente
* La facture d'avoir est bien présente dans le bloc factures - Le remboursement est bien présent dans le bloc règlements - La suspension avec le motif associé est bien présente dans le bloc suspensions.
- Factures et règlements - Amélioration de la gestion des crédits - Jira-13938
Paramétrage :
Le paramétrage de la remontée au crédit et de la gestion des trop perçus est une des évolutions principales de cette nouvelle version.
Dans certains cas, les abonnés procèdent à un règlement supérieur au montant de l'abonnement.
Par exemple, l'abonnement est de 99 euros et l'abonné va envoyer un règlement d'un montant de 100 euros. L'éditeur a par conséquent un trop perçu de 1 euro. La somme étant trop faible, cela peut donc être considéré comme un trop perçu non remboursable.
Autre, exemple, l'abonnement est de 99 euros et l'abonné envoie un règlement de 199 euros. Il faut par conséquent effectuer une remontée au crédit, car le trop perçu est trop conséquent.
Le paramétrage de cette remontée au crédit si trop perçu est nouveau et est disponible dans Administration -> Société -> Règlement -> Option. Chaque éditeur choisit le montant qu'il souhaite paramétrer à ce niveau.
Si cette option n'est pas renseignée, il n'y a pas de remontée au crédit, par défaut. L'utilisateur peut néanmoins cocher la case "Remonter le trop perçu au crédit du client", mais son action est manuelle.
Cas concrets et informations financières sur le contact :
Cas 1 : La remontée au crédit est de 2 euros. Le règlement est de 24 euros mais l'abonné a payé 25 euros. La perte est de 1 euro et la case "Remonter le trop perçu au crédit du client" n'est pas cochée par défaut.
Cas 2 : La remontée au crédit est de 2 euros. Le règlement est de 24 euros mais l'abonné a payé 30 euros. La perte est de 6 euros et la case "Remonter le trop perçu au crédit du client" est cochée par défaut.
Ce trop perçu, correspondant au crédit disponible est visible dans le bloc "Informations financières" présent sur la fiche contact, dans la partie "Crédit disponible".
Utilisation du crédit sur une autre facture :
Le crédit disponible peut être utilisé sur une autre facture. Le mode de paiement associé est "utilisation d'un crédit".
Sur la facture, l'utilisateur fait "..." puis "Utiliser un crédit" et apparaît l'écran ci-après avec le crédit disponible et le mode de paiement "Utilisation d'un crédit". L'utilisateur peut faire le choix ou non d'utiliser la totalité du crédit.
Dans l'exemple ci-dessus, la facture et le règlement apparaissent comme ci-dessous :
Le règlement de la facture dont le montant est de 19.90 euros, était de 25 euros, soit 5.10 euros de trop perçu.
Le règlement de la facture d'après a pu être réglé en partie par le trop perçu qui apparaît comme un règlement de type "Crédit".
Le crédit peut être utilisé pour régler une facture d'AL, l'abonné peut choisir de ne pas utiliser l'intégralité de son crédit disponible.
Le crédit peut être généré ou utilisé dans le cadre d'un upgrade/downgrade
Notes :
- La remontée au crédit n'est pas possible en modification d'un règlement.
- La suppression d'un règlement avec crédit, est possible lorsque le crédit n'a pas été utilisé.
- La suppression d'un règlement avec crédit n'est pas possible lorsque le crédit a déjà été utilisé.
Exemple : l'utilisateur souhaite supprimer le chèque de 25 euros. Pour rappel, le montant de l'abonnement était de 19.90 donc le trop perçu (crédit) est de 5.10 euros. L'action de suppression lui renvoie donc un message d'alerte (cf. ci-dessous)
Liste des crédits :
Un nouvel écran a été développé et permet à l'utilisateur de visualiser les crédits disponibles ainsi que la facture d'origine et la facture qui a utilisé le crédit.
Cet écran est disponible via Finance puis Factures et "Liste des crédits" accessible depuis "...'
La liste des crédits apparaît donc ainsi :
Règlements groupés :
- Pour rappel, il n'est pas possible de créer des règlements groupés sur des factures de clients différents. Le message suivant va s'appliquer :
- Pour effectuer des règlements groupés, il faut donc sélectionner des factures non soldées sur le même abonné. L'utilisateur va dans l'écran Finance puis Factures. Il sélectionne les factures concernées, utilise la fonctionnalité "..." puis fais "Créer des règlements". La pop-up "Création des règlements groupés s'affiche". Si le montant réglé est supérieur, la case "Remonter le trop perçu au crédit du client" est coché par défaut.
Exemple ci-dessus. Le montant à régler est de 19.50 euros mais l'abonné paye 25 euros soit 5.50 euros de crédit.
Les deux factures sont réglées en intégralité.
Le montant du crédit est porté par la facture d'origine la plus ancienne.
Exemple ci-après :
Améliorations
Gestion - Contacts
- Ajout de l'option d'envoi de l'email de bienvenue au client de type "Payé par" sur les clients de type "Tiers" - Jira-9163
Cette option a été ajoutée seulement, sur les contacts de type Tiers. Pour pouvoir l'activer, l'utilisateur doit aller sur la fiche d'un contact dans le bloc appelé "Gestion client" puis sur le "..." via la fonctionnalité "Editer".
En faisant "Editer", la pop-up ci-dessous s'affiche et l'utilisateur peut venir cocher l'option "Email de bienvenue pour les payés" :
Par conséquent, lors d'une prise d'abonnement pour un payé par, c'est bien celui-ci qui recevra l'email de bienvenue si l'option est cochée. Si la case n'est pas cochée, aucun mail de bienvenue n'est envoyé.
- Amabis - Possibilité de forcer la ville - Jira-14568
Le référentiel des communes, associées à un code postal provenant d'Amabis, ne pouvait donc pas être géré par TBS. Dorénavant, pour les éditeurs utilisant AMABIS, lors du renseignement d'un code postal, l'item "Forcer la ville" a été ajouté en bas de la liste chargée, après saisie du code postal. L'utilisateur peut ensuite renseigner la commune.
Exemple ci-après :
Cette amélioration a été réalisée à trois niveaux :
* Via la fonctionnalité "+" puis "ajouter contact"
* Via l'adresse d'une fiche contact existante
* Via la création d'une autre adresse sur une fiche contact via le bloc "Adresses"
Aucune modification n'a été faite sur la création d'une société.
- Un prospect bascule automatiquement en abonné de type client quand il est associé à une offre payante ou à un Article Libre payant - Jira-14432
Pour toute commande issue du WEB ou bien lors d'une prise d'abonnement ou de réabonnement via Mahalo directement, sur une offre payante ou un AL payant, un abonné de type prospect devient un abonné de type client. Cette bascule est automatique et ne nécessite pas l'intervention de l'utilisateur.
Exemple ci-après :
Le client est de type prospect et ne possède aucun abonnement
Un abonnement est pris sur une offre payante, le client bascule en "client"
Gestion - Abonnements
- Facturer en série - Jira-14622
Cette fonctionnalité est disponible via le "..." et en ayant préalablement sélectionné des abonnements à facturer.
La facturation en série peut se faire : par client / par abonnement. Pour une meilleure compréhension, le libellé "Facture globale" a été remplacée par "Facture par client"
Par, exemple si un tiers est associé à deux payés par qui ont chacun un abonnement.
La facture par client va faire une seule facture qui sera portée, par le tiers. La facture par abonnement fera deux factures, soit une pour chaque abonnement (payé par) qui seront portées par le tiers.
- Possibilité de filtrer dans la colonne "Type règlement" de l'écran des abonnements - Jira-13013
La colonne était déjà présente auparavant, TBS a ajouté la possibilité de pouvoir effectuer un filtre sur le contenu de celle-ci.
Pour rappel, cette colonne n'est pas visible par défaut, il faut faire un clic droit avec la souris pour voir apparaître la liste des colonnes disponible et éventuellement, l'ajouter.
- Affichage du montant TTC en consultation d'un abonnement - Jira-12255
Les informations présentes en consultation d'un abonnement étaient auparavant : PU HT, Taux TVA, PU TTC et Remise
Les informations présentes sont désormais : Taux TVA, PU TTC, Remise, Montant TTC
Gestion - Commandes
- Les libellés des erreurs sur les commandes issues de la boutique sont plus génériques - Jira-12999
L'utilisateur peut être amené à traiter manuellement des commandes en erreur. Elles sont visibles dans l'écran général des commandes et ont le statut "Erreur". Un survol du statut avec la souris, permet de visualiser le libellé de l'erreur. Certains libellés d'erreur étant trop techniques, ceux-ci ont été remplacés par le libellé "Erreur de l'insertion de la commande dans le système".
Administration - Offres
- Contrôle de l'option "Gratuit" pour les abonnements de type consos (spécifiques PQR : Presse Quotidienne Régionale) Jira-14611
La case à cocher "Gratuit" n'est pas cochée par défaut sur une offre sur un titre de type "consommation", au moment de la création de celle-ci.
Administration - Formats
- Ajout d'une option invisible sur les formats d'import/d'export - Jira-14114
Certains formats ont vocation à ne plus être exploités, par les utilisateurs. Par conséquent, ceux-ci ne doivent plus être proposés lors des opérations d'exports ou d'imports.
Si un utilisateur clique sur la référence d'un format, il arrive sur l'écran général de celui-ci où il a la possibilité de cocher la case "invisible"
En parallèle, une colonne "Invisible" a été ajoutée dans la vue générale des formats avec la possibilité de filtrer sur oui/non/tous
Administration - Paramétrage
- Ajout de colonnes pour la lecture des codes de sélection - Jira-12896
Les codes de sélection sont paramétrés dans l'écran Paramétrage de l'onglet Administration. Ils sont paramétrables dans la partie "Code de sélection".
Si l'utilisateur clique sur l'appellation, il arrive sur la page ci-après :
L'amélioration dans cette version porte sur l'ajout des différentes colonnes : type de code / type de saisie / type d'entité / famille / parent / CRM.
L'utilisateur a la possibilité de filtrer sur ces différentes colonnes grâce aux divers menus déroulants présents via "Sélectionner".
Réabonnement rapide
- Réabonnement sur un contact de type "payé par" possible via la fonctionnalité "Réabonner" - Jira-14527
La fonctionnalité est disponible via le "+" puis "Réabonner". Elle permettait jusqu'alors des réabonnements rapides, seulement sur des contacts de type "client".
L'utilisateur peut effectuer sa recherche par code client/nom client ou bien par référence abonnement. L'utilisateur clique sur le tarif concerné par le réabonnement.
La page ci-dessous s'affiche et l'utilisateur vient sélectionner les informations relatives à un réabonnement. Il peut choisir de facturer celui-ci ou non, tout comme de régler celui-ci ou non.
Notifications
- Historique des notifications conservées pendant 72h au lieu de 24h - Jira-14294
Cette fonctionnalité est disponible depuis l'icône 'cloche'
Elle permet de voir tous les contacts consultés/modifiés depuis les dernières 72h, contre 24h, auparavant.
Correctifs
Dashboard
- Intégrer la notion de heure-min-sec aux noms des fichiers de relevé de prélèvements - Jira-14590
Ces fichiers sont téléchargeables depuis la page d'accueil soit le Dashboard de Mahalo.
Auparavant, les fichiers étaient nommés selon la typologie (CB ou SEPA) et la date du jour d'exécution. Cependant si deux traitements relatifs à la même typologie étaient exécutés le même jour, le 2ème écrasait le 1er fichier, en local.
Pour contribuer à ce fait, TBS a intégré la notion de heure-min-sec dans l'appellation du fichier.
Gestion - Abonnements
- La création de la facture et de la prime n'étaient pas opérationnelles lors d'un parrainage - Jira-14644
Certaines formules contiennent une prime à livrer au parrain lors d'un parrainage. La facture et la livraison de celle-ci n'étaient pas opérationnelles dans Mahalo. La facture n'était pas créée, par conséquent la prime n'était pas présente dans le fichier de livraison des articles libres. Cette anomalie a donc été corrigée dans cette version.
- Sélection "Tous" et action "Suspendre" dans l'écran des abonnements - Jira-12877
La fonctionnalité "Tous/aucun" de la liste des abonnements a été corrigée, dans cette version.
Cette fonctionnalité permet d'effectuer une suspension en masse d'un ensemble d'abonnements prédéfinis par un filtre, ou non.
Un support doit bien avoir été choisi, au préalable.
Exemple de suspension de tous les abonnements :
L'utilisateur doit aller dans la case à cocher, cliquer sur la petite flèche puis faire "Tous"
Ensuite, l'utilisateur utilise la fonctionnalité "..." pour choisir la fonctionnalité "Suspendre"
Tous les abonnements sélectionnés sont bien suspendus et ce n'est plus limité à 10, comme auparavant. L'utilisateur choisit le numéro/la date de début de suspension et le motif, qui sera commun à l'ensemble des abonnements concernés.
Logistique - Import - Contact
- Import du champ "Origine client" - Jira-14388
Le champ "origines" de la fiche contact ne se renseignait pas lors de l'import d'un fichier de contacts. D'où le correctif, réalisé dans cette version.
Pour rappel, le champ s'appelle "origine client" dans le format d'import de contact.
Finance - Factures
- Régularisation impayé - Date et banque de dépôt erronées - Jira-14634
Lorsque l'utilisateur saisissait un règlement standard pour régulariser une facture qui était en règlement par prélèvement, la banque de dépôt et la date étaient par défaut celle du prélèvement. Un correctif a été réalisé pour y mettre la bonne banque et la date du jour.
- Suppression de factures créées via la fonctionnalité de factures en série - Jira-14583
Un correctif a été apporté dans cette version car la suppression de factures qui ont été créées via la fonctionnalité de facturation en série, étaient source d'erreur technique. En effet, la suppression des factures était possible, mais pas celle des abonnements associés.
La suppression est possible depuis l'onglet Finance puis Factures. L'utilisateur sélectionne des factures, utilise la fonctionnalité "..." puis fais supprimer.
Rapports - Diffusion
- Etat de diffusion global - Partie "Abonnements" . Les ADL 1 numéro ne sont plus dans la catégorie "Nouveaux abonnements", "En fin" et "Réabonnements" mais dans la catégorie " En cours" - Cet état est disponible dans Aboweb, mais pour Mahalo, il est disponible via INSIGHTS. Vous pouvez vous rapprocher du support ou de votre chef de projet pour la mise en place. Jira-14130