CX_CHARGE - Zu-/Abschläge

Klassenhierarchie

Beschreibung:

Es stehen folgende Klassen zur Verfügung:

Diese Klasse kann nicht selbst benutzt werden und besitzt weder Funktionen noch Datenfelder.

Klassen CX_CHARGE und abgeleitete für Erstellung von Zahlungsbedingungen:
Skonti, Teilzahlungen, etc. und allgemein Ab/und Zuschläge

Basis-Klasse CX_CHARGE hält CX_AMOUNT *charge, das in Verbindung mit
chargeEnum arbeitet:
0, T("Betrag wie eingegeben", "Amount as entered"), 0xff
1, T("Vorzeichenwechsel", "Change sign"), 0xff
2, T("Abschlag (Subtrahiere)", "charge (subtract)"), 0xff
4, T("Aufteilung (Multipliziere)", "partition (multiply)"), 0xff
64, T("Zwingend", "Must"), 0xff // 'UND' Bedingung !
128, T("Erledigt", "Fullfilled"), 0xff

Man geht davon aus, dass i.Allgemeinen ein Basis-Betrag, der von
aussen kommt, durch eine CHARGE manipuliert wird. Trotzdem auch fix Betrag
möglich (chargeEnum = 2 und Amount vom Typ CX_VALUE)

Also Modellierung von: (1) 3 % (aber in Wirklichkeit -3% oder umgekehrt)
(2) basisWert - charge
(4) basisWert * charge



Funktionen:
===========
Value(_basisWert): ermittelt den tatsächlichen - ausgerechneten -
Wert der Charge


DueDate(basisDatum): ermittelt die tatsächliche Fälligkeit des Betrages


DueValue(_basisWert, _basisDatum, _bisDatum)
ermittelt den Betragswert bis zu einem bestimmten
Datum



CX_DELAYED_CHARGE: Betrag zu einem verzögertem (unbekannten) Zeitpunkt (z.B. Skonto)
Hält zusätzlich: CX_AMOUNT* delay
delayEnum (Addiere zu Basisdatum, Berechne Basisdatum)

CX_STATE_CHARGE: Betrag zu einem Status (von CX_DELAYED_CHARGE abgeleitet)
Hält zusätzlich: CX_STATE_MONITOR* state

CX_TERMED_CHARGE: Betrag zu einem best. Termin: z.B. Teilzahlungen
Hält zusätzlich: CX_TERM* fixedTerm


CX_PAY_OFF_CHARGE: (auch für COMISSION ?)
CX_BUSINESS_OBJECT* debt: an wen/von wem wird Gebühr abgeführt/erhoben

CX_TAX: abgeleitet von CX_PAY_OFF_CHARGE, hat zusätzlich Typ der Steuer
und Liste von Sachlkonten. Funktionen TaxAccount() und CashDiscountAccount()
holen direkt das Konto, unetr dem die Steuer gebucht wird und das 
Skonto-Korrekturkonto. Eventuell Skonto-Korrektur auch als CondBag-Objekt
in CX_ACCOUNT_DOMAIN, falls Zusammenhang komplizierter.


OFFEN:
======

Modellierung von Zinsen (CX_DEPOSIT_INTERESTS)
Kreditlinie (CX_CREDIT_LINE)
Ratenabzahlung (CX_INSTALMENT)
(früher abgeleitet von CX_DEPOSIT_CONDITION)

depositInterestsEnum
{
0, T(Zinsen, "Interests"), 0xff
1, T(Sollzinsen, "interests payed"), 0xff
2, T(Habenzinsen, "interests earned"), 0xff
3, T(Überziehungszinsen, "overdraft interests"), 0xff
4, T(Strafzinsen, "penal interests"), 0xff
}

basePeriodEnum
{
13, T(Jahr, year), 0xff
12, T(Tertial, tertian), 0xff
11, T(Quartal, quarter), 0xff
10, T(Monat, month), 0xff
9, T("14-tägig", fortnight), 0xff
8, T(Woche, week), 0xff
7, T(Tag, day), 0xff
}

delayEnum könnte eigentlich entfallen, System sollte selbst merken,
was als delay gespeichert wurde

Partial_Payment: DueCharge muss additiv sein
CX_CHARGE::IsActive() ??

Verbindung zu subCharge herstellen: generell

chargeEnum: offen/verdeckt (wie verarbeiten ?)

Preise/Rabatte/Tax/Commission ??

Prozent im Hundert/vom Hundert ??

Code-Beispiel: