Produits Entr'ouvert » Publik

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).

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".

• 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.

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

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.

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).

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.