Projet

Général

Profil

Development #31407

Paiement en ligne pour "petites" régies

Ajouté par Brice Mallet il y a 12 jours. Mis à jour il y a 7 jours.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
14 mar. 2019
Echéance:
01 juil. 2019
% réalisé:

0%

Patch proposed:
Non
Demande du club utilisateur:
Non

Description

Les "grosses" régies (typiquement enfance) ont leur logiciel métier émettant des factures, celles-ci étant payables en ligne soit sur le portail famille soit sur Publik si connecteur ad-hoc : OK
Mais il y a des "petites" régies (location de salles, droit d'occupation du domaine public...) qui n'ont pas de logiciel métier, factures établies par le régisseur avec un outil bureautique, par exemple. Dans ce cas, on peut supposer qu'il n'y a pas obligation de rapprochement automatique entre encaissements physiques et encaissement en ligne, le rapprochement pouvant se faire manuellement par l'unique régisseur (mais cela reste une contrainte à expliquer).

L'obligation de paiement en ligne au 1er juillet 2019 pour les collectivités encaissant plus de 1 000 000 euros / an (https://www.legifrance.gouv.fr/eli/decret/2018/8/1/CPAE1815650D/jo/texte), [soit toutes les communes de plus de 1000 habitants > et là c'est pas sûr à la réflexion parce que ce sont des revenus et non des encaissements... / ajout du 19/03], serait l'occasion d'adresser ce cas des petites régies :
  • soit avec un formulaire BO pour générer une dette à payer dans Lingo, dette pouvant être payée sans être connecté (#9039) mais oblige à des saisies unitaires dans Publik
  • soit à base d'un tableau établi par le régisseur, à partir duquel les dettes seraient payables via un TIPI titre "local" (#31217#note-4)

Historique

#1 Mis à jour par Frédéric Péters il y a 12 jours

  • Projet changé de OLAP / Businesse Intelligence pour Publik à Publik
  • Demande du club utilisateur mis à Non

#3 Mis à jour par Thomas Noël il y a 12 jours

soit à base d'un tableau établi par le régisseur

Je note ici, pour spec, que ce tableau devra être mis à jour le plus souvent possible car les gens peuvent payer par d'autre canaux (guichet, virement, etc).

#4 Mis à jour par Benjamin Dauvergne il y a 12 jours

Thomas Noël a écrit :

soit à base d'un tableau établi par le régisseur

Je note ici, pour spec, que ce tableau devra être mis à jour le plus souvent possible car les gens peuvent payer par d'autre canaux (guichet, virement, etc).

Et donc je note ici tout de suite qu'il faut interdire les paiements qui ne passeraient pas par Public (même au guichet, l'agent doit venir directement mettre à jour la facture), et interdire cette solution pour les paiement ou les virements seraient possibles (j'ai rarement vu les virements possibles avec les collectivités de toute façon). Avec ces limitations on s'évite des noeuds au cerveau et on saura où on va et quand leur dire "allez voir SAGA".

Pour moi une cible ce serait :
  • une source de factures alimentable via fichier tableur fournissant les références et les montants, avec une validation des fichiers sur la cohérence et le format (numéro de facture déjà vu, dates dans le futur, email mal formaté, etc..); on définit le format, ex.:
    Champ Format Valuation requis e Description Exemple
    Numéro chaîne alphanum sans espaces oui F20180001
    Identifiant personne/compte/famille/etc.. chaîne alphanum sans espaces non 1234
    Nom UTF-8 libre oui
    Prénom idem oui
    Email non
    Mobile non
    Montant nombre tableau r"\d+([.,]\d+)?" oui 23,45
  • à voir si on permet de gérer des lignes de facture et comment
  • une interface de validation de paiement pour les agents guichet
  • un moyen de payer une facture à partir de la référence
  • option: lister les factures pour un compte (en filtrant par email/mobile)
  • option: générer des factures via un modèle weasyprint bateau

Je note ici que ça pourrait être un connecteur dont les interactions pour le régisseur se ferait via des formulaires/page combos tapant sur une API (pousser un nouveau fichier CSV dans la base, valider une facture comme étant payer, lancer le mailing).

Je note aussi ici que concernant le mailing on aura les mêmes soucis que corbo : ils voudront savoir quand les mails n'arrivent pas, si ils ont été ouverts, etc.. comme la poste quoi.

#5 Mis à jour par Brice Mallet il y a 12 jours

Benjamin Dauvergne a écrit :

Et donc je note ici tout de suite qu'il faut interdire les paiements qui ne passeraient pas par Public (même au guichet, l'agent doit venir directement mettre à jour la facture)

Je sais que dangereux mais j'imaginais pour ma part simple contrôle manuel

à voir si on permet de gérer des lignes de facture et comment

Vu mes cas de figure, je dirais non, mais pê prévoir un champ libre optionnel pour y afficher le libellé de la dette

  • option: lister les factures pour un compte (en filtrant par email/mobile)
  • option: générer des factures via un modèle weasyprint bateau

Oui, vraiment des options, à voir éventuellement par la suite

#6 Mis à jour par Benjamin Dauvergne il y a 12 jours

Brice Mallet a écrit :

Benjamin Dauvergne a écrit :

Et donc je note ici tout de suite qu'il faut interdire les paiements qui ne passeraient pas par Public (même au guichet, l'agent doit venir directement mettre à jour la facture)

Je sais que dangereux mais j'imaginais pour ma part simple contrôle manuel

Contrôle de quoi ? Si en plus notre système produit des factures imprimables et/ou de les envoyer par mail, il aura même envie d'y aller spontanément depuis son guichet plutôt que de le faire à la main.

à voir si on permet de gérer des lignes de facture et comment

Vu mes cas de figure, je dirais non, mais pê prévoir un champ libre optionnel pour y afficher le libellé de la dette

  • option: lister les factures pour un compte (en filtrant par email/mobile)
  • option: générer des factures via un modèle weasyprint bateau

Oui, vraiment des options, à voir éventuellement par la suite

On doit remettre une facture/ticket aux gens de toute façon, ça peut être un simple mail plutôt qu'un truc en PDF, mais faut fournir quelque chose.

#7 Mis à jour par Brice Mallet il y a 7 jours

  • Description mis à jour (diff)

#8 Mis à jour par Pierre Cros il y a 7 jours

Je suis désolé je débarque un peu tard mais est-ce qu'on doit vraiment mettre le doigt là-dedans ? Il me semble que l'info permettant au régisseur de la petite régie de faire le rapprochement suite à un paiement fait dans Publik on l'a déjà dans Lingo/Combo.

Du coup je ne suis pas certain du besoin que l'on cherche à couvrir et j'ai vaguement l'impression qu'on cherche à se substituer à une appli de faturation (dont j'ai bien compris qu'ils n'en avaient pas forcément).

#9 Mis à jour par Benjamin Dauvergne il y a 7 jours

Pierre Cros a écrit :

Du coup je ne suis pas certain du besoin que l'on cherche à couvrir et j'ai vaguement l'impression qu'on cherche à se substituer à une appli de faturation (dont j'ai bien compris qu'ils n'en avaient pas forcément).

En gros c'est presque ça, plutôt un logiciel de caisse tendant vers la facturation, mais disons qu'on a mis le pied dedans dès le système de panier parce que ventiler les paiements sur plusieurs prestations/factures, ça demande d'émettre l'information qui dise exactement ce qu'on a payé des deux cotés.

Formats disponibles : Atom PDF