New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rechnungsstellung von Mitgliederbeiträgen #18

Open
RolandStuder opened this Issue Jun 4, 2016 · 5 comments

Comments

@RolandStuder
Member

RolandStuder commented Jun 4, 2016

wichtige Links:

Kontext:

Fast alle Organisationen, welche hitobito anspricht benötigen eine Möglichkeit für Rechnungsstellung in der ein oder anderen Form. Hitobito soll dies ermöglichen, wobei die Handhabung möglichst einfach bleiben sollte.

Wir wollen einige mögliche Varianten skizzieren, damit wir uns für eine gute Richtung entscheiden. Wir stellen uns dabei auch die Frage, wie stark das Rechnungssystem mit dem Rest von hitobito sein soll. Oder ob wir das stärker isolieren oder sogar nur über einen Service anbinden.

Anforderungsdokumente der PBS und der Jubla
Hitobito_Erweiterung_Rechnung_v0.1.pdf
Rechnungstool_Version_1.6.pdf

Zentrales Invoicing als Service als Fernvision?

Interessante Erfahrungen von der Pfadi Finnland: Der Dachverband macht für die lokalen Gruppen das Invoicing (sofern gewünscht). Das geht wie folgt:

  • Die Abteilung führt die eigene Mitgliederliste.
  • Die Abteilung legt einen Mitgliederbeitrag fest. (Ebenso definiere Regionen und Dachverband einen Betrag pro Teilnehmer).
  • Der Dachverband fordert den vollen Betrag direkt an (Anteil lokale Gruppe / Anteil Region / Anteil Dachverband) . Mahnt auch.
  • Der Dachverband zahlt anschliessen den Anteil an die Region und die lokale Gruppe aus.

Somit kann eine die unter Umständen mühsame Arbeit der Rechnungsstellung vom Dachverband wahrgenommen werden, dank Massenverarbeitung ist dies insgesamt ein Effizienzgewinn.

Es wäre möglich so eine Version anzudenken.

Varianten:

  1. Einfache Variante auf jeder Ebene, ohne irgendwelche Artikel, nur Emailversand oder PDF ohne ESR Funktionalität.
  2. Einbau von externen Briefversandservice, wie Pingen, wo direkt Rechnungen per Post verschickt werden können, ohne dass ich selbst je Papier anrühren muss.
  3. Einbau von externem Rechnungsservice, in welchem ich aus hitobito heraus direkt Rechnungen generieren kann, der aber nicht selbst von Puzzle betrieben wird.
  4. Etwas ausgebautere Variante in hitobito, die auch ESR Drucken zulässt.
  5. Payment ermöglichen, statt Rechnung schicken (Online Bezahlmöglichkeit, statt Rechnung verschicken z. B. über Einbund von Schnittstellen, so dass z. B. Yellowpay benutzt werden kann).

Die Frage ist wirklich, wollen wir “alte Systeme” unterstützen, oder wollen wir modern direkte Zahlungen ermöglichen?

Mögliche Services / Plattformen die man einbinden könnte

  • Pingen.com für ESR Generierung und Versenden von Post über API -> Ingetrator Account möglich
  • smallinvoice.com für komplette Rechnungslösung inkl. Katalog/Mahnwesen, unterstütz neu auch Online Bezahlung von Rechnungen sehr spannend. Bietet gute API, die zulassen würde, via hitobito Sachen auszulösen / zu übergeben. Frage ist nach Massenmanipulationen. (Limitierung API: 60 Request pro Minute, Kunde erstellen ca. 500-100ms, Erstellen Rechnung 800ms - bis wenige Sekunden).
  • Open Source Lösungen, allerdings vielleicht schwierig die spezifischen Schweizer Bedürfnisse abzudecken. http://invoiceplane.com und Artikel mit einigen Lösungen: https://opensource.com/business/14/9/4-open-source-invoice-tools

Fragen:

  • Wer soll das Rechnungstool vor allem brauchen können? Dient es eher Lokalgruppen ihre Mitgliederbeiträge einzuziehen, oder richtet sich das Tool eher Geschäftsstellenmitarbeiter auf z. B. Kantonsebene? Für Lokalorganisationen braucht es wohl weniger elaborierte Features.
  • Ist die Abrechnung von Lagerbeiträgen ebenfalls im Scope? Und solle die separat betrachtet werden oder eher integriert mit Mitgliederbeiträgen.

Stories

  • Als Leitungsperson einer Lokalgruppe will ich auf einfachste Weise Mitgliederbeiträge einsammeln, um meine Gruppe mit minimalen Aufwand zu finanzieren..
  • Als Leitungsperson einer Lokalgruppe will ich die Mitgliederbeiträge anpassen können, um speziellen Situationen wie Geschwister oder finanzielle Erleichterungen gerecht werden zu können.

Erweiterungen

  • Online Bezahlung über eine Schnittstelle statt via Rechnung
  • Kontinuierliche/automatische Rechnungstellung (Zuweisung einer Mitgliedschaft, für die automatisch jährlich Rechnung gestellt wird).

Diese Issue wird kontinuierlich aktualisiert.

ps: Ich probiere hier mal aus mit einem Github Issue zu arbeiten, statt im Redmine.

@RolandStuder RolandStuder self-assigned this Jun 4, 2016

@adriananderegg

This comment has been minimized.

Show comment
Hide comment
@adriananderegg

adriananderegg Jun 6, 2016

Contributor

Hallo Roland

Vielen Dank für das Starten der Diskussion. Meine Gedanken dazu:

  • Invoicing als Service auf Bundesebene ist vielleicht ein langfristiges Szenario, sehe ich aber nicht als Lösung für die aktuellen Handlungswünsche. Zudem m.E. Lager und Kurse auch in scope sein müssten.
  • Ein externer Service klingt zwar sehr verlockend, bei den fortlaufenden Datenschutzdiskussionen in unserem Verband sehe ich das zur Zeit aber nicht als gangbarer Weg an. Zudem verteilen viele Abteilungen um Porto zu sparen die Rechnungen von Hand oder per E-Mail und nicht per Post. Auch dies müsste unterstützt sein.

Zu den Fragen:
ad 1) definitiv Lokalgruppen für das Eintreiben von Mitgliederbeiträgen und... (s.2)
ad 2) Lager- oder Kursbeiträgen. Auch hier mit den Möglichkeiten für anpasspare Beiträge.
In diesem Kontext gibt es noch eine weitere Story: "Als Leitungsperson eines Kurses möchte ich Rechnungen für Teilnehmerbeiträge nicht zwingend an die Person selbst ausstellen. Der Rechnungsempfänger sollte durch eine Gruppe oder andere Person innerhalb der Datenbank überschrieben werden können."
Kontext ist, dass bei Ausbildungskursen teilweise die Abteilung, die Region oder der Kanton die Finanzierung übernimmt und daher die Rechnung nicht an die Person sondern an die Abteilung ausgestellt werden soll.

[Frage 3 ist nicht ausformuliert]

Beste Grüsse
Adrian (PBS Team MiData)

Contributor

adriananderegg commented Jun 6, 2016

Hallo Roland

Vielen Dank für das Starten der Diskussion. Meine Gedanken dazu:

  • Invoicing als Service auf Bundesebene ist vielleicht ein langfristiges Szenario, sehe ich aber nicht als Lösung für die aktuellen Handlungswünsche. Zudem m.E. Lager und Kurse auch in scope sein müssten.
  • Ein externer Service klingt zwar sehr verlockend, bei den fortlaufenden Datenschutzdiskussionen in unserem Verband sehe ich das zur Zeit aber nicht als gangbarer Weg an. Zudem verteilen viele Abteilungen um Porto zu sparen die Rechnungen von Hand oder per E-Mail und nicht per Post. Auch dies müsste unterstützt sein.

Zu den Fragen:
ad 1) definitiv Lokalgruppen für das Eintreiben von Mitgliederbeiträgen und... (s.2)
ad 2) Lager- oder Kursbeiträgen. Auch hier mit den Möglichkeiten für anpasspare Beiträge.
In diesem Kontext gibt es noch eine weitere Story: "Als Leitungsperson eines Kurses möchte ich Rechnungen für Teilnehmerbeiträge nicht zwingend an die Person selbst ausstellen. Der Rechnungsempfänger sollte durch eine Gruppe oder andere Person innerhalb der Datenbank überschrieben werden können."
Kontext ist, dass bei Ausbildungskursen teilweise die Abteilung, die Region oder der Kanton die Finanzierung übernimmt und daher die Rechnung nicht an die Person sondern an die Abteilung ausgestellt werden soll.

[Frage 3 ist nicht ausformuliert]

Beste Grüsse
Adrian (PBS Team MiData)

@RolandStuder

This comment has been minimized.

Show comment
Hide comment
@RolandStuder

RolandStuder Jun 13, 2016

Member

Eine grosse Herausforderung für das Feature ist die richtigen Leute auswählen zu können, wir haben bisher die Möglichkeit wie es bei den Abos funktioniert und auf der Personenliste. Beide scheinen mir nicht ideal. Insgesamt wäre eine allgemein gute gelöster Personenfilter wünschenswert. Aber das ist ein relativ grosses Unterfangen. Deshalb priorisiere ich vorläufig eine einfach Auswahl von Gruppenmitgliedern oder Anlassbesuchern.

Ideen hierzu sind sehr willkommen, siehe #19.

Zur Anpassung von Rechnungsempfänger: Ich sehe folgendes Modell vor. Man wählt Lagerteilnehmer aus und erstellt zu allen eine Rechnung, bevor man diese versendet kann man die Rechnungen beliebig anpassen und Vermerke anbringen. Aber ein Mapping von Lagerteilnahme und Rechnung wäre keine gegeben.

Member

RolandStuder commented Jun 13, 2016

Eine grosse Herausforderung für das Feature ist die richtigen Leute auswählen zu können, wir haben bisher die Möglichkeit wie es bei den Abos funktioniert und auf der Personenliste. Beide scheinen mir nicht ideal. Insgesamt wäre eine allgemein gute gelöster Personenfilter wünschenswert. Aber das ist ein relativ grosses Unterfangen. Deshalb priorisiere ich vorläufig eine einfach Auswahl von Gruppenmitgliedern oder Anlassbesuchern.

Ideen hierzu sind sehr willkommen, siehe #19.

Zur Anpassung von Rechnungsempfänger: Ich sehe folgendes Modell vor. Man wählt Lagerteilnehmer aus und erstellt zu allen eine Rechnung, bevor man diese versendet kann man die Rechnungen beliebig anpassen und Vermerke anbringen. Aber ein Mapping von Lagerteilnahme und Rechnung wäre keine gegeben.

@RolandStuder

This comment has been minimized.

Show comment
Hide comment
@RolandStuder

RolandStuder Jun 13, 2016

Member

Also hier der erste Prototyp mit dem meiner Meinung nach minimalen Set was es braucht. Spielt damit herum. Es können auch Kommentare direkt dort erfasst werden.

https://invis.io/S47MIDEDH#/165849462_Rechnungsstellung_Einstieg_Copy

Und der Prototyp als Download Prototyp Rechnungsstelle v1.zip

Member

RolandStuder commented Jun 13, 2016

Also hier der erste Prototyp mit dem meiner Meinung nach minimalen Set was es braucht. Spielt damit herum. Es können auch Kommentare direkt dort erfasst werden.

https://invis.io/S47MIDEDH#/165849462_Rechnungsstellung_Einstieg_Copy

Und der Prototyp als Download Prototyp Rechnungsstelle v1.zip

@RolandStuder

This comment has been minimized.

Show comment
Hide comment
@RolandStuder

RolandStuder Jul 13, 2016

Member

Das Interesse von der Jubla und Insieme bezieht sich eher auf die Rechnungsstellung mit einer Integration eines Buchhaltungstools. Die PBS sucht eher eine Lösung, die sich vor allem an die Lokalgruppen (Scharen / Abteilungen richtet).

Member

RolandStuder commented Jul 13, 2016

Das Interesse von der Jubla und Insieme bezieht sich eher auf die Rechnungsstellung mit einer Integration eines Buchhaltungstools. Die PBS sucht eher eine Lösung, die sich vor allem an die Lokalgruppen (Scharen / Abteilungen richtet).

@RolandStuder

This comment has been minimized.

Show comment
Hide comment
@RolandStuder

RolandStuder Oct 7, 2016

Member

DSJ verwendet abacus, hat ein spezifisches .xls

Member

RolandStuder commented Oct 7, 2016

DSJ verwendet abacus, hat ein spezifisches .xls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment