Erstellung von Rückzahlungsplänen

[Paule]

Hallo,

ich habe eine Frage zu Rückzahlungsplänen.

Ich habe eine Tabelle, in der alle Verkäufe und seine Daten angegeben werden.
Über das dazugehörige Formular kann ich dann die Verkäufe und die dazugehörigen Informationen hinzufügen.

Nun gibt es bei uns unterschiedliche Verkaufstypen, wie direkter Verkauf oder auch eine Ratenzahlung. Diese kann ich mir beim Hinzufügen eines neuen Verkaufs dann entsprechend herauspicken aus einem Listenfeld und diese werden dann auch unter der Tabelle SA_Sales gespeichert.

Zurzeit versuche ich für den Verkaufstyp Ratenzahlung eine Übersicht zu erstellen, aus der klar hervorgeht, wann welche Raten anfallen und ich bin mir noch unsicher über den besten Weg dafür.

Von meinem Verständnis aus, muss ich ja eine weitere Tabelle mit den Rückzahlungen haben, wobei ich dann die RückzahlungsID als Primärschlüssel habe und diese dann der SalesID zuordne, die ich wiederrum mit der SalesID (Primärschlüssel) der Tabelle SA_Sales verknüpfen kann.
Für die Tabelle Rückzahlungen könnte ich dann ein Unterformular erstellen und dieses dem Hauptformular (Hinzufügung von Verkäufen) zuordnen.

Ich möchte mir nun aber eigentlich unbedingt die Mühe ersparen, jede Ratenzahlung einzeln eingeben zu müssen, denn die Komplexität hinter den Ratenzahlung ist denkbar gering.

Schon im Formular zur Hinzufügung eines neuen Verkaufs wird das Produkt angegeben. Ich habe eine extra Tabelle mit den Produkten, wo auch die Ratenzahlungssumme sowie die Anzahl der monatlichen Ratenzahlungen gegeben ist. Im Regelfall sollten dies 6 Monate, also 6 monatliche Zahlungen vom Verkaufsdatum aus, sein.

Gibt es irgendeine Möglichkeit, diesen Rückzahlungsplan automatisch mit Hinzufügung eines Verkaufes zu erstellen? Es sind eigentlich alle Daten, die benötigt werden (Verkaufsdatum, Verkaufsprodukt, Rückzahlungssumme, Rückzahlungs-Anzahl) vorhanden, wenn ich einen neuen Verkauf anlege?

Wie gesagt: Meine Vermutung sind die Haupt- und Unterformulare, aber bei dem Unterformular habe ich dann ja immer noch das Problem, dass ich 6x extra Datensätze hinzufügen muss, die eigentlich so einfach zu berechnen sind...

Ich wäre für eure Hilfe sehr dankbar!

Viele Grüße,
Marcus

[DF6GL]

Hallo,

zunächst ist es nötig, eine Stammtabelle/Vorlagentabelle (tblRatenpläne) zu erstellen, die alle möglichen Ratenzahlungstermine/-abstände beinhaltet.

Je nach Datensituation (Historie nötig, d. h. Erfassung der tatsächlich gezahlten Raten mit Datum) ist möglicherweise eine weitere Tabelle (tblVerkaufsRückzahlungen) erforderlich, die diese Historie bzgl. eines Verkaufs eben erfasst. Vorstellbar wäre, in die Historie automatisch bei der Definition eines Ratenverkaufs entspr. der Vorlagentabelle die DS angepasst ( z. B. die Zeitperioden in feste Termine umgerechnet) zu "kopieren".

[Paule]

Hallo,

erstmal ganz vielen Dank für die schnelle Antwort.

Ich übertrage das Ganze jetzt mal auf ein Produkt. Dieses Produkt hat 6 Ratenzahlungen. Die Erste erfolgt im Verkaufsdatum und danach ist jeweils immer ein Monat danach die nächste Zahlung fällig.
Kaufe ich heute ein Produkt auf Ratenzahlung, so zahle ich die erste Rate heute, die nächste am  13.4., 13.5., 13.6., 13.7. und 13.8.
Dieses System bleibt immer gleich. Der einzige Unterschied besteht in den Ratenrückzahlungen und der Rückzahlungsdauer (die meisten werden innerhalb 6 Monate gezahlt, wenige in 4 Monaten). Diese Daten sind wie gesagt alle in der Tabelle mit den Produkten gespeichert.

Mich interessiert auch nur der theoretische Rückzahlungsplan im ersten Schritt - wie tatsächlich gezahlt wird, bleibt erstmal uninteressant.
Mein Ziel ist es, dass ich von allen Ratenverkäufe dann als einzelne Datensätze in einer Abfrage die anstehenden Rückzahlungen als jeweils einzelnen Datensatz ablesen kann.

Ich habe jetzt noch nicht ganz verstanden, wie du das mit der Vorlagentabelle meinst. Ich nehme jetzt quasi mal ein Produkt und erstelle dafür eine Vorlagentabelle mit den Feldern "Rückzahlungssumme" und "Rückzahlungstermin" und nenne diese Tabelle "tbl_Rückzahlung1".
Aber in dieser Tabelle kann ich dann ja nur mit absoluten Werten arbeiten, d.h. das Datum kann ich nicht über DatAdd fortschreiben um die Rückzahlungstermine flexibel und in Abhängigkeit des Verkaufsdatums zu gestalten. Außerdem würde dann ja noch eine Beziehung über die SalesID fehlen, sodass ich in einer Abfrage die anstehenden Rückzahlungen keinem Verkauf und somit Kunden zuordnen kann.

Kurzum: Ich würde mich freuen, wenn du mir das Vorgehen noch etwas genauer erklären könntest, denn ich glaube, ich bin da noch nicht ganz dahinter gestiegen...

Falls ich das Problem oder die Situation noch genauer beschreiben soll, kann ich das gerne auf Wunsch hin tun.

Besten Dank für die Hilfe!

[DF6GL]

Hallo,

Dieses Produkt hat 6 Ratenzahlungen.

Nein, eher so:  Das Produkt unterliegt einem bestimmten Ratenzahlungsplan. Dieser Plan ist einer vom mehreren (auch wenn die anderen nur selten sind),   die in "tblRatenpläne" hinterlegt sind, und zwar nur mit Zahlperioden und nicht mit fixen Terminen, wie auch prozentuale Zahlbetragsangaben und keine festen Beträge.

In Tabelle tblProdukte (in diesem Beispiel) wird der PK-Wert aus "tblRatenpläne" als Fremdschlüssel hinterlegt (durch Auswahl z. B. über ein Kombi beim Anlegen eines Produktes).

Wenn jetzt keine Historie von Nöten ist, kann über eine Abfrage für jedes Produkt dessen Zahlungsplan angezeigt werden, wobei in der Abfrage die in tblRatenpläne hinterlegten Zahlungsperioden und prozentualen Beträge in fixe Termine und Beträge umgerechnet werden.

Ist ein Historie erforderlich, dann braucht es eine weitere Tabelle "tblProduktRatenzahlungen", die mit tblProdukte in 1:n-Beziehung steht und fixe Termine und Beträge enthält.  Das ist sozusagen das Ergebnis aus o. g. Abfrage in eine Tabelle geschrieben...  Die DS in dieser Tabelle werden z. B. mit SQL aus der Vorlagentabelle ausgelesen, berechnet und mit Berücksichtung der ID-Felder abgespeichert.

Diese Tabelle kann ( muss) dann weitere Felder besitzen, z. B. Zahldatum, Zahlbetrag, etc..., wenn wirklich eine Nachverfolgung/Historie-Betrachtung  möglich sein soll.

Aber in dieser Tabelle kann ich dann ja nur mit absoluten Werten arbeiten, d.h. das Datum kann ich nicht über DatAdd fortschreiben um die Rückzahlungstermine flexibel und in Abhängigkeit des Verkaufsdatums zu gestalten. Außerdem würde dann ja noch eine Beziehung über die SalesID fehlen, sodass ich in einer Abfrage die anstehenden Rückzahlungen keinem Verkauf und somit Kunden zuordnen kann.

Das wiederspricht, bzw. deckt sich nicht mit dem o. g. Beispiel bzgl. Produkt.

Es muss geklärt werden, wozu die Zahlungen überhaupt gehören.  Normalerweise ist das eine Rechnung oder ein Verkaufsvorgang oder dergleichen. Vermutlich ist das "tblSales", die mit tblProdukte in n:1-Beziehung steht. Weiterhin steht tblKunden mit 1:n mit tblSales in Beziehung.

An tblSales wäre dann "tblSalesZahlungen"  (oben als "tblProduktRatenZahlungen" genannt) mit 1:n Beziehung angebunden. Die "tblRatenpläne" benötigt keine feste Beziehung zu einer anderen Tabelle, sie ist ja lediglich eine "Vorlage" für das Kopieren der DS in "tblSalesZahlungen".

Aber in dieser Tabelle kann ich dann ja nur mit absoluten Werten arbeiten, d.h. das Datum kann ich nicht über DatAdd fortschreiben um die Rückzahlungstermine flexibel und in Abhängigkeit des Verkaufsdatums zu gestalten.

In der Tabelle stehen am Ende tatsächlich absolute Werte, die aber beim Kopiervorgang entspr. den Werten aus tblSales berechnet und abgespeichert wurden. Das erlaubt zudem die individuelle Anpassung der Termine und Beträge , sollte aus irgendeinem Grund dies gewünscht werden.

[Paule]

Das heißt, ich mache jetzt tbl_Ratenpläne in einer Tabelle:

RückzahlungsplanID          Zahlperiode (Zahl)          Rückz.-Summe (welcher Typ?? Kurzer Text?)
1                                       6                                   1/6
2                                       4                                   1/4
3                                       3                                   1/3

Und in der tblProdukte füge ich ein weiteres Feld RepaymentPlan(ID) hinzu, welches ich mit der tblRatenplan in Beziehung setze?

So als erster Schritt?

[DF6GL]

Hallo,

Im Prinzip ja..

Die "Zahlperiode" (Long) muss eine definierte interpretative Einheit haben (z. B. 6 MONATE)
Die "Rückz.-Summe"  ("Rückzahlrate" , Datentyp Währung und als "Prozentzahl" interpretiert:  0,16)

Code [Auswählen] Erweitern

Und in der tblProdukte füge ich ein weiteres Feld RepaymentPlan(ID) hinzu, welches ich mit der tblRatenplan in Beziehung setze?


Welches Konzept verwendest Du hier (wie vorher schon angemerkt):

Produkt mit Zahlungplan oder Verkauf von Produkten mit Zahlplan?

Für Ersteres: Ja.
Für Zweites:  Wie vorher beschrieben.

[Paule]

Ich würde alle Rückzahlungsperioden in Monaten angeben (die sind zwischen 3-6 Monaten).

Zu der anderen Frage: In glaube, ich verstehe sie nicht ganz.

Ich lege über ein Formular in die Tabelle SA_Sales einen neuen Verkauf an. In diesem Datensatz ist der Customer als FK mit enthalten, genauso wie das gekaufte Produkt (FK auf tblProdukte).
Diese Zahlungspläne sind für jeden gleich, da gibt es keine Abstufungen. Die Zahlungen gehören also zum Verkaufsvorgang.
Beantwortet das die Frage?


Für mich ist wie gesagt wichtig, dass ich am Ende eine Übersicht erhalte, wo ich klar ersichtlich habe, welche Zahlungen (egal von welchem Produkt, Verkauf oder Kunde) in der nächsten Zeit anstehen. Damit man dann überprüfen kann, ob diese bezahlt wurden oder nicht.
Da fehlt mir jetzt noch ein bisschen die Vorstellung, wie ich diese Brücke/Umrechnung erfolgt...

[DF6GL]

Hallo,

Für mich ist wie gesagt wichtig, dass ich am Ende eine Übersicht erhalte, wo ich klar ersichtlich habe, welche Zahlungen (egal von welchem Produkt, Verkauf oder Kunde) in der nächsten Zeit anstehen. Damit man dann überprüfen kann, ob diese bezahlt wurden oder nicht.

Irgendwie ist diese Aussage nicht logisch:  Du willst künftige Zahlungen erkennen und dadurch feststellen, ob Zahlungen getätigt wurden.

Ein Zahlungsplan ist doch eine Vorgabe für zeitlich abhängige  Zahlungsvorgänge...  Insofern solltest Du den Vorschlag mit der Historie umsetzen.  Pro Zahlungstermin wird ein DS erstellt. Wie der DS terminlich und betragsmäßig aussieht, ergibt sich aus der Vorlagetabelle und daraus den Berechnungen der Termine und der Rate, bzw. Restbeträgen.

Konkret heißt das, dann mit der Zahlperiode und dem prozentualen Betrag aus einer bestimmten  Vorlage die realen Zahlungstermine und Rückzahlungsbeträge als jeweilige Datensätze in die Historien-Tabellen (tblSalesZahlungen) geschrieben werden.


Da fehlt mir jetzt noch ein bisschen die Vorstellung, wie ich diese Brücke/Umrechnung erfolgt...


Naja, die Daten aus der Vorlagentabelle auslesen und in  einer VBA-Schleife die notwendigen Termine berechnen und mit SQL in die Tabelle einfügen.

[Beaker s.a.]

Hallo Marcus,
Betrifft ein Sale immer nur ein Produkt?
Falls auch mehrere Produkte zu einem Sale gehören können,
gehört der Rückzahlungsplan zum Sale, nicht zum Produkt.
gruss ekkehard

[Paule]

Hallo Ekkehard,

ja, wir verkaufen pro Sale ein Produkt. Schon allein, weil es unterschiedliche Verträge gibt für jedes Produkt.

@DF6GL
Ok, vielleicht blöd ausgedrückt: Ich meinte, dass wir dann handschriftlch kontrollieren, wer gezahlt hat. Heißt: Wenn ich eine Liste habe mit den anstehenden Ratenzahlungen, kann ich die ja auch handschriftlich abhaken. 
Heißt: Ich will eine Übersicht folgenden Layouts:
CustomerID, CustomerName, SalesID, Produkt, Ratenrückzahlungstermin, Ratenrückzahlung, (Ratenperiode(1.,2.,3. ... Rückzahlung?)). Diese Übersicht wil lich mir dann jeden Monat ziehen um die voraussichtlichen Einnahmen zu kontrollieren. Ich möchte NICHT extra eingeben, wieviel und wann dann wirklich bezahlt wurden - diese Info spielt erstmal keine Rolle. Es geht rein um die Erstellung einer Übersicht der theoretisch anstehenden Ratenzahlungen (meintest du das mit "Historie"?).

Eine Kontrolle habe ich eh über die Buchung im Buchhaltungssystem. Das heißt, dort speichere ich ja die Einnahme (mit Marken, die ihn zum Kunden zuordnen lassen), sodass ich das gegenüberstellen könnte und ein zusätzlicher Buchungssatz gar nicht unbedingt nötig wäre.



Macht es denn einen großen Unterschied, wenn ich die Ratenzahlung (z.B. 0,16) als Zahl (Double) angebe? Ich verwende sonst eben auch nur "Zahl" und nie Währung, daher denke ich wäre ersteres besser? Dazu noch die Frage mit der Rundung. 1/3 ist eben ja nicht 0,33...das müsste ich ja auch noch berücksichtigen, dass die Summe der Ratenzahlungen dann auch genau den Gesamtpreis ausmachen.

Naja, die Daten aus der Vorlagentabelle auslesen und in  einer VBA-Schleife die notwendigen Termine berechnen und mit SQL in die Tabelle einfügen.

Könnten wir das Schritt für Schritt durchgehen? Meine VBA-Kenntnisse sind ebenso limitiert wie meine Access-Künste..und in SQL arbeite ich wie du weißt ja fast ausschließlich mit TempVar...(noch) .

Ich habe jetzt die tblRatenpläne angelegt. Ich habe in der tblProdukte ein weiteres Feld "Ratenplan" hinzugefügt und das mit tblRatenpläne.RatenplanID verknüpft. Ich habe den Verkäufen einen Ratenplan zugewiesen (obwohl das nicht wirklich nötig ist, wie du unten geschrieben hast). In meiner Vorstellung brauche ich jetzt ZWINGEND die Tabelle tblSalesZahlungen, wo ich basierend auf der dem Rückzahlungsplan für jeden Sale dann die einzelnen Datensätze erstellen kann, die für jeweils eine der Rückzahlung stehen.

Allein nun die VBA Anweisung, die dann sechs/drei Datensätze beim Hinzufügen eines Verkaufs, in eine andere Tabelle als tblSales anlegt, ist mir völlig fremd.. 

[DF6GL]

Hallo,

Ich verwende sonst eben auch nur "Zahl" und nie Währung, daher denke ich wäre ersteres besser?

Was Du sonst immer verwendest ist doch kein Argument gegen "Währung".

"Währung" ist eine Festkomma-Zahl mit 4 Dezimalstellen. "Double" ist eine Gleitkommazahl mit 15 signifikanten Stellen.

Bei "Währung" fallen Rundungsfehler nicht so stark ins Gewicht wie bei einer Double-Zahl.

Wenn ich eine Liste habe mit den anstehenden Ratenzahlungen, kann ich die ja auch handschriftlich abhaken. 

Naja, wenn Du schon eine Db für den ganzen "Vorgang" aufstellst, dann kannst Du damit auch die Verwaltung treiben..


Wie Du diese "Liste" erstellst, hab ich vorher beschrieben.

wir verkaufen pro Sale ein Produkt. Schon allein, weil es unterschiedliche Verträge gibt für jedes Produkt.

Wenn man genau sein will, muss diese Situation eindeutig klar gelegt werden:

Betrifft der Ratenzahlungsplan ein Produkt oder den Verkauf eines Produktes ?

[Paule]

Was Du sonst immer verwendest ist doch kein Argument gegen "Währung".

"Währung" ist eine Festkomma-Zahl mit 4 Dezimalstellen. "Double" ist eine Gleitkommazahl mit 15 signifikanten Stellen.

Bei "Währung" fallen Rundungsfehler nicht so stark ins Gewicht wie bei einer Double-Zahl.

Nun, sonst wurde mir immer gesagt, dass unterschiedliche Felddatentypen schwierig sind, gerade, wenn man Berechnungen anstellt, wie ich das ja hier tue. Daher kam der Gedankengang.

Wenn man genau sein will, muss diese Situation eindeutig klar gelegt werden:

Betrifft der Ratenzahlungsplan ein Produkt oder den Verkauf eines Produktes ?

Dann Ersteres. Jedes Produkt hat einen klaren Ratenzahlungsplan, den man auswählen kann. Entweder man nimmt ihn, oder nicht. Wir verhandeln da nicht mit dem Kunden. Entweder er zahlt alles direkt, oder eben entsprechend dem Ratenplan, der zu diesem Produkt existiert.

_________

Wie dem auch sei, ich werde nun das Ganze so aufsetzen, dass man die Rückzahlungen einzeln hinzufügen muss zu der tblSalesZahlungen.

Danke vielmals für die Hilfe!

[Beaker s.a.]

Hallo Marcus,

Wie dem auch sei, ich werde nun das Ganze so aufsetzen, dass man die Rückzahlungen einzeln hinzufügen muss zu der tblSalesZahlungen.

Musst Du doch nicht. Per VBA kannst Du doch auf einen Rutsch soviele DS anhängen wie du willst. In diesem Fall eben so viele wie es Raten gibt.
fragmentarischer Luftcode:

Code [Auswählen] Erweitern

For i =1 to AnzahlRaten
    CurrentDb.Execute "INSERT INTO Tabelle (Felda, Zahldatum, Rate) SELECT Werta, SalesDatum + x, Gesamtbetrag/AnzahlRaten"
next i
Das Datum musst du entsprechend deinen Vorgaben aus der Plantabelle mit Datumsfunktionen berechnen.
hth
gruss ekkehard

[Beaker s.a.]

Gerade fällt mir auf, dass man das im Zusammenspiel (JOIN) mit der Plantabelle, wahrscheinlich auch ohne Schleife mit einem einzigen SQL-Statement erledigen kann.
Leider kann ich das jetzt nicht so aus dem Ärmel schütteln, - vielleicht helfen die Profis?
gruss ekkehard

[Paule]

Hallo Ekkehard,

ganz lieben Dank für deine Hilfe!
Ich habe es jetzt erstmal auf die umwegsame Tour gemacht. Soweit funktioniert das nun.
Ich werde mich in den nächsten Tagen da nochmal dran setzen und das so machen wie von dir beschrieben. Das wäre nämlich eine enorme Zeit- und Arbeitsersparnis.

Also danke dafür!

Grüße,
Marcus