Zahlungen: Unterschied zwischen den Versionen
(→Technische/Funktionale Details) |
|||
Zeile 67: | Zeile 67: | ||
= Technische/Funktionale Details = | = Technische/Funktionale Details = | ||
+ | * Hier werden Abschnitte erstellt mit identischem Namen zu Layout/Prozesse | ||
+ | |||
+ | * In der "normalen" Doku ein Link auf die entsprechende Details (im sinne von (Details ...) | ||
+ | |||
+ | * Ein Detail-Abschnitt beginnt mit einem "Backlink": "Details zu ..." | ||
+ | |||
+ | |||
+ | |||
+ | == Zahlung stornieren == | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Es gelten folgende Prämissen: | ||
+ | |||
+ | # Ein Zahlungsstorno ist immer ein Korrektur, nie eine Auszahlung. Die zu stornierende Zahlung hat also so wie erfasst nie stattgefunden (ggf. falsches Datum, falscher Betrag, falsche Zahlungsform etc.). Auszahlungen werden separat als negative Zahlungen erfasst. Daraus folgt dass das Valutadatum eines Zahlungsstornos immer auf das Zahlungsdatum selbst gesetzt. | ||
+ | |||
+ | # Ein Zahlungsstorno darf nicht nachträglich eine OP Liste verändern. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Um obige Prämissen einzuhalten, darf eine Zahlung nicht mehr storniert werden, falls | ||
+ | |||
+ | # es Zahlungsverteilungen gibt, welche schon storniert wurden, wobei das Stornodatum ungleich Zahlungsdatum ist<br/> | ||
+ | |||
+ | Hintergrund: wird eine Zahlung storniert, dann werden auch alle Zahlungsverteilungen per Zahlungsdatum storniert. Gibt es nun schon stornierte Zahlungsverteilungen, würde bei diesen das Stornodatum neu auf das Zahlungsdatum gesetzt. Das verändert die historische OP-Liste und verletzt damit Prämisse 2. | ||
+ | |||
+ | # es eine Zahlungsverteilung auf eine nummerierte Rechnung gibt, wobei: | ||
+ | ## die Zuweisung der Zahlungsverteilung NACH dem Zahlungsdatum erfolgte | ||
+ | ## die Rechnung NACH erfolgter Zahlungsverteilung nummeriert wurde. | ||
− | |||
− | |||
− | + | Ungeachtet obiger Einschränkungen kann eine Zahlung mit ''Zahlungsdatum in der Zukunft'' immer storniert werden, da diese Zahlung keine historische OP-Liste beeinflussen kann. |
Version vom 27. August 2012, 14:56 Uhr
Inhaltsverzeichnis
Übersicht
Zusammenfassung wozu diese UI Page dient. 2-3 Sätze.
Layout
Gibt keine Text-Beschreibung, nur ein Screenshot.
Benutzeroberfläche
Arbeitsabläufe / Prozesse
Hier werden ALLE Prozesse beschrieben die auf dieser Seite möglich sind, dh. über alle Tabs!
Einzelner Prozess
Als eigenes Kapitel!
- Beschreibung Prozess-orientiert, Bspl. Kunden-Übersicht:
- Neuer Kunde erfassen (Duplicate check)
- Family / company Verlinkung
- Familienmitglied neu erfassen
- Kundenmerge
- Address- / Anredefeld Update
- Notizen
Auf Target Release wird im UI hingewiesen (mit Wiki-internem Tag 'targetrelease'
Technische/Funktionale Details
- Hier werden Abschnitte erstellt mit identischem Namen zu Layout/Prozesse
- In der "normalen" Doku ein Link auf die entsprechende Details (im sinne von (Details ...)
- Ein Detail-Abschnitt beginnt mit einem "Backlink": "Details zu ..."
Zahlung stornieren
Es gelten folgende Prämissen:
- Ein Zahlungsstorno ist immer ein Korrektur, nie eine Auszahlung. Die zu stornierende Zahlung hat also so wie erfasst nie stattgefunden (ggf. falsches Datum, falscher Betrag, falsche Zahlungsform etc.). Auszahlungen werden separat als negative Zahlungen erfasst. Daraus folgt dass das Valutadatum eines Zahlungsstornos immer auf das Zahlungsdatum selbst gesetzt.
- Ein Zahlungsstorno darf nicht nachträglich eine OP Liste verändern.
Um obige Prämissen einzuhalten, darf eine Zahlung nicht mehr storniert werden, falls
- es Zahlungsverteilungen gibt, welche schon storniert wurden, wobei das Stornodatum ungleich Zahlungsdatum ist
Hintergrund: wird eine Zahlung storniert, dann werden auch alle Zahlungsverteilungen per Zahlungsdatum storniert. Gibt es nun schon stornierte Zahlungsverteilungen, würde bei diesen das Stornodatum neu auf das Zahlungsdatum gesetzt. Das verändert die historische OP-Liste und verletzt damit Prämisse 2.
- es eine Zahlungsverteilung auf eine nummerierte Rechnung gibt, wobei:
- die Zuweisung der Zahlungsverteilung NACH dem Zahlungsdatum erfolgte
- die Rechnung NACH erfolgter Zahlungsverteilung nummeriert wurde.
Ungeachtet obiger Einschränkungen kann eine Zahlung mit Zahlungsdatum in der Zukunft immer storniert werden, da diese Zahlung keine historische OP-Liste beeinflussen kann.