Zahlungen: Unterschied zwischen den Versionen
Aus Umbrella.net Documentation
(→Technische/Funktionale Details) |
(→Zahlung stornieren) |
||
| Zeile 76: | Zeile 76: | ||
== Zahlung stornieren == | == Zahlung stornieren == | ||
| − | |||
| − | |||
| − | |||
| − | |||
Es gelten folgende Prämissen: | 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 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. | # Ein Zahlungsstorno darf nicht nachträglich eine OP Liste verändern. | ||
| − | |||
| − | |||
| − | |||
Um obige Prämissen einzuhalten, darf eine Zahlung nicht mehr storniert werden, falls | 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/> | + | # 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. |
| − | |||
| − | 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: | # es eine Zahlungsverteilung auf eine nummerierte Rechnung gibt, wobei: | ||
| − | |||
## die Zuweisung der Zahlungsverteilung NACH dem Zahlungsdatum erfolgte | ## die Zuweisung der Zahlungsverteilung NACH dem Zahlungsdatum erfolgte | ||
| − | |||
## die Rechnung NACH erfolgter Zahlungsverteilung nummeriert wurde. | ## 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. | 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, 15:57 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.
