Hierzu wurde angenommen dass die meisten Einträge a) für den aktiven Vorgang und b) automatisch bzw. manuell aus einem vorgegeben Katalog erfolgt, mit der Anzahl 1 berechnet werden soll und der Katalogpreis unverändert bleibt. Die Angaben lassen sich für die anderen Fälle dann nachträglich bearbeiten. Achtung: Wenn der dazugehörige Vorgang nachträglich gewechselt wird, muss das Datum manuell nachgezogen werden falls gewünscht. Umgekehrt wenn das Datum nachträglich geändert wird, wird nicht automatisch der dazugehörige Vorgang ausgewählt.
Vermutlich ist die Auflistung und Bearbeitung der erbrachten Leistungen der kleinste gemeinsame Nenner auf dem Weg zur Rechnungsstellung. Ob es realistisch und angebracht ist dass Gnumed eine möglichst treffsichere Vorschlagsliste zur Leistungsabrechnung beisteuert, weiss ich nicht. Meiner Meinung nach sollte zumindest noch die Möglichkeit zur Rechnungsstellung für Private Leistungen vorhanden sein (Button "Rechnung" mit Pdf ), die Buchhaltung und Verwaltung der Zahlungen extern.
Die Erstellung geschieht momentan manuell auf Anforderung und erzeugt ein PDF das erstmal nicht in der Dokumenten-Ansicht verfügbar ist. Dieser Ansatz wurde gewählt weil eine Rechnung episodenunabhängig ist und auch nicht reviewed werden soll. Die Rechnung ist nachträglich im Kontext-Menü der Rechnungsposten aufrufbar, das mit reportlab erzeugte Pdf liegt in einem Ordner auf der Platte. Musterrechnung
Als Schnittstelle zur Buchhaltung wird eine CSV-Datei mit den einzelen Zeilen für die geschlossene Rechnung befüllt. Die Datei enthält aktuell Wertstellungsdatum, Buchungskonto, Betrag und einen beschreibenden Text.
Leider ist das Rechnungsformular noch nicht als Vorlage definiert, und das Layout noch etwas dürftig. Customizing geschieht indem Variablen in der Datei gmBillFactory.py bearbeiten (Praxisanschrift, Kontaktangaben, UST-Id etc.). Internationalisiert ist hier auch noch nix, wenn das überhaupt sinnvoll ist.
Mit dem Rechnungsabschluss verbunden ist die Ermittlung des Empfängers, dessen Rechnungsanschrift und des Gesamtbetrags. Der Gesamtbetrag um nachfolgende Zahlungsabstimmprozesse zu erleichtern. Der Rechnungsempfänger ist derzeit implementiert "schaue bei den externen Ids" nach dem jüngsten Eintrag "Rechungsempfänger". Die Rechnungsanschrift als "Nehme aus einer Adressliste vom Typ Invoice oder Home sortiert nach Adresstyp=Invoice" den ersten, wenn keiner da "Name Rechnungsempfänger - in Praxis". Die tatsächliche Adressformatierung geschieht mit einer Funktion fmt_inv_address aus Ihrem momentan eingestellten Landesschema .
Nach Zuordnung der Rechnungsposten und Erstellung der Rechnung hierfür, sind die Posten in der GUI nicht mehr bearbeitbar. Auf Datebankebene gibt es zusätzlich eine Rule die das Verändern verhindern soll.
Damit das Plugin aktiviert werden kann, müssen Datenbank-Objekte angelegt werden und ein Paar neue Python-Dateien im Gnumed-Ordner gelegt werden. Da "leere" Encounter aufgeräumt werden und wir eine neue Abhängigkeit Encounter : Billing Record (1:0..n) einführen, sind kleinere Änderungen gegenüber der Datenbank (Version v16.9) notwendig.
Um Pdfs erzeugen zu können, muss reportlab installiert werden, sowie in der Datei gmBillFactory einige Angaben zu Ihrer Praxis gemacht werden. Ausserdem brauchts einen Ordner in dem die Pdfs dann abgelegt werden können.
Schema vor Übernahme in v17 Tabelle Posten:bill_item, Leistungen:ref.billable und ci_category, View v_bill_items, v_enc und ci_category (ref.data_source), acc_export_lines sowie Hilfsfunktionen
Annahme: Der Katalog der Leistungen wird je Instanz in Gnumed vorgehalten.
Noch zu klären: Migration bill_rec nach bill_item (Wer benutzt die?) und charge_item nach billable verschiedene Tabellen basierend auf coding_system_root (Wer befüllt die einmalig und regelmäßig?)
Business-Objekte und Plugin Posten: gmBillItem, Leistungen: gmBillable, Rechnung: gmBill, gmBillFactory
Das Plugin muss aktiviert werden. Der Benutzer muss dazu zumindest Leserechte auf die Tabellen im Schema haben.
