https://dev.entrouvert.org/https://dev.entrouvert.org/favicon.ico?15861920342019-03-14T08:43:23ZRedmine Entr’ouvertPublik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1617862019-03-14T08:43:23ZFrédéric Pétersfpeters@entrouvert.com
<ul><li><strong>Projet</strong> changé de <i>OLAP / Business Intelligence pour Publik</i> à <i>Publik</i></li><li><strong>Club</strong> mis à <i>Non</i></li></ul> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1617992019-03-14T09:04:49ZThomas Noël
<ul></ul><blockquote>
<p>soit à base d'un tableau établi par le régisseur</p>
</blockquote>
<p>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).</p> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1618732019-03-14T11:33:10ZBenjamin Dauvergne
<ul></ul><p>Thomas Noël a écrit :</p>
<blockquote><blockquote>
<p>soit à base d'un tableau établi par le régisseur</p>
</blockquote>
<p>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).</p>
</blockquote>
<p>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".</p>
Pour moi une cible ce serait :
<ul>
<li>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.:
<table>
<tr>
<td> Champ </td>
<td> Format </td>
<td> Valuation requis e</td>
<td> Description </td>
<td> Exemple </td>
</tr>
<tr>
<td> Numéro </td>
<td> chaîne alphanum sans espaces </td>
<td> oui </td>
<td> </td>
<td> F20180001 </td>
</tr>
<tr>
<td> Identifiant personne/compte/famille/etc.. </td>
<td> chaîne alphanum sans espaces </td>
<td> non </td>
<td> </td>
<td> 1234 </td>
</tr>
<tr>
<td> Nom </td>
<td> UTF-8 libre </td>
<td> oui </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> Prénom </td>
<td> idem </td>
<td> oui </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> Email </td>
<td> </td>
<td> non </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> Mobile </td>
<td> </td>
<td> non </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> Montant </td>
<td> nombre tableau <code>r"\d+([.,]\d+)?"</code> </td>
<td> oui </td>
<td> </td>
<td> 23,45 </td>
</tr>
</table></li>
</ul>
<ul>
<li>à voir si on permet de gérer des lignes de facture et comment</li>
</ul>
<ul>
<li>une interface de validation de paiement pour les agents guichet</li>
<li>un moyen de payer une facture à partir de la référence</li>
<li>option: lister les factures pour un compte (en filtrant par email/mobile)</li>
<li>option: générer des factures via un modèle weasyprint bateau</li>
</ul>
<p>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).</p>
<p>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.</p> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1618882019-03-14T12:39:57ZBrice Mallet
<ul></ul><p>Benjamin Dauvergne a écrit :</p>
<blockquote>
<p>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)</p>
</blockquote>
<p>Je sais que dangereux mais j'imaginais pour ma part simple contrôle manuel</p>
<blockquote>
<p>à voir si on permet de gérer des lignes de facture et comment</p>
</blockquote>
<p>Vu mes cas de figure, je dirais non, mais pê prévoir un champ libre optionnel pour y afficher le libellé de la dette</p>
<blockquote>
<ul>
<li>option: lister les factures pour un compte (en filtrant par email/mobile)</li>
<li>option: générer des factures via un modèle weasyprint bateau</li>
</ul>
</blockquote>
<p>Oui, vraiment des options, à voir éventuellement par la suite</p> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1619502019-03-14T15:16:43ZBenjamin Dauvergne
<ul></ul><p>Brice Mallet a écrit :</p>
<blockquote>
<p>Benjamin Dauvergne a écrit :</p>
<blockquote>
<p>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)</p>
</blockquote>
<p>Je sais que dangereux mais j'imaginais pour ma part simple contrôle manuel</p>
</blockquote>
<p>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.</p>
<blockquote><blockquote>
<p>à voir si on permet de gérer des lignes de facture et comment</p>
</blockquote>
<p>Vu mes cas de figure, je dirais non, mais pê prévoir un champ libre optionnel pour y afficher le libellé de la dette</p>
<blockquote>
<ul>
<li>option: lister les factures pour un compte (en filtrant par email/mobile)</li>
<li>option: générer des factures via un modèle weasyprint bateau</li>
</ul>
</blockquote>
<p>Oui, vraiment des options, à voir éventuellement par la suite</p>
</blockquote>
<p>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.</p> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1627412019-03-19T11:24:22ZBrice Mallet
<ul><li><strong>Description</strong> mis à jour (<a title="Voir les différences" href="/journals/162741/diff?detail_id=142092">diff</a>)</li></ul> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1627512019-03-19T12:13:41ZPierre Crospcros@entrouvert.com
<ul></ul><p>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.</p>
<p>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).</p> Publik - Development #31407: Paiement en ligne pour "petites" régieshttps://dev.entrouvert.org/issues/31407?journal_id=1627562019-03-19T12:58:53ZBenjamin Dauvergne
<ul></ul><p>Pierre Cros a écrit :</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>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.</p>