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
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".
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!
Hallo,
ZitatDieses 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.
Zitat
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".
ZitatAber 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.
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?
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)
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.
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...
Hallo,
ZitatFü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.
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
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.
ZitatNaja, 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.. :(
Hallo,
ZitatIch verwende sonst eben auch nur "Zahl" und nie Währung, daher denke ich wäre ersteres besser?
;D
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.
ZitatWenn 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.
Zitat
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 ?
Zitat;D
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.
ZitatWenn 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!
Hallo Marcus,
ZitatWie 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:
For i =1 to AnzahlRaten
CurrentDb.Execute "INSERT INTO Tabelle (Felda, Zahldatum, Rate) SELECT Werta, SalesDatum + x, Gesamtbetrag/AnzahlRaten"
next iDas Datum musst du entsprechend deinen Vorgaben aus der Plantabelle mit Datumsfunktionen berechnen.
hth
gruss ekkehard
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
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
Hallo Ekkehard,
ich habe mich gerade nochmal an den VBA-Code gesetzt, komme aber in der zweiten Hälfte nicht mehr weiter.
Ich habe nun mich mal ausprobiert und bin zu folgendem VBA-Code gekommen:
Private Sub AddNewSale_Click()
DoCmd.GoToRecord , "", acNewRec
If lstRepaymentPlan = 1 Then
For i = 1 To 9
CurrentDb.Execute "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) SELECT SalesID.Value, SalesDate.Value, DatDiff('m', i, 40000), i"
Next i
End If
End Sub
Die Raten sollen in die Tabelle CF_InstallmentsT eingetragen werden. Der Aufbau dieser Tabelle ist:
- InstallmentID (PK)
- ReferingSale (FK)
- InstallmentDate
- InstallmentSum
- Notes (Wert von 1 zu i --> Nummer der Rate).
Die SalesID kann er sich aus dem Textfeld aus dem Formular ("SalesID") holen. Das Ursprungsdatum ebenso ("SalesDate" und dann eben für jedes neu hinzugefügte Installment einen Monat hinzufügen). Die Summe bleibt immer gleich (40.000) und unter Notes landet dann eine Zahl von 1 zu 9 (also gleich mit i).
Der Code oben funktioniert allerdings (aus nachvollziehbaren Gründen?) noch nicht.
Was muss ich noch verändern?
Hallo,
ZitatDie SalesID kann er sich aus dem Textfeld aus dem Formular ("SalesID") holen.
in diesem Fall musst du eine Werteliste übergeben:
Dim strSQL As String
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & _
" Values(" & Me!SalesID & ", " & Format(Me!SalesDate, "\#yyyy\/mm\/dd\#") & ", " & DateDiff("m", i, 40000) & ", '" & i & "')"
CurrentDb.Execute strSQL, dbFailOnError
Aber was bezweckst du eigentlich mit diesem Ausdruck:
DatDiff('m', i, 40000)Könnte es sein, dass die Werteliste so aussehen sollte:
" Values(" & Me!SalesID & ", " & Format(DateDiff("m", i-1, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, '" & i & "')"
Zitat von: MaggieMay am Mai 31, 2016, 10:37:50
Könnte es sein, dass die Werteliste so aussehen sollte:
" Values(" & Me!SalesID & ", " & Format(DateDiff("m", i-1, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, '" & i & "')"
Hallo, vielen Dank schon mal.
Ja, das wird es wohl eher treffen.
Eine Frage noch zum DateDiff: Ich habe in dem Beispiel ja 9 Ratenzahlungen.
Und er soll mir dann also 9 Datensätze erstellen und es ändert sich ja nur das Datum. Bei der ersten Ratenzahlung wäre i=1 und dann soll er also vom Sales Date noch einen Monat drauf rechnen. Bei der zweiten Zahlungen i=2 dann eben zwei. Jetzt ist es minus? Das wird mir nicht ganz klar.
Außerdem fehlt ja jetzt noch die Info, dass wir i von 1 bis 9 läuft, oder?
Ich hatte es jetzt erstmal so versucht wie mit deinem Code. Da kommt bei mir Syntaxfehler bei der INSERT INTO-Methode und die letzte Zeile wird gelb markiert. Also die Execute-Zeile.
Woran kann das liegen?
ZitatBei der ersten Ratenzahlung wäre i=1 und dann soll er also vom Sales Date noch einen Monat drauf rechnen.
Ich dachte, es sollte bei SalesDate beginnen und erst ab dem 2. Datensatz aufaddieren, daher die -1.
ZitatAußerdem fehlt ja jetzt noch die Info, dass wir i von 1 bis 9 läuft, oder?
Die Schleife sollte beibehalten werden. Ich zeigte nur den Code, der zu ändern wäre.
ZitatDa kommt bei mir Syntaxfehler bei der INSERT INTO-Methode
Dann zeige bitte deine Version des Codes. Oder den generierten SQL-String.
Ok, mit der Schleife drinnen ist der Fehler woanders zu finden:
Private Sub AddNewSale_Click()
DoCmd.GoToRecord , "", acNewRec
If lstRepaymentPlan = 1 Then
For i = 1 To 9
Dim strSQL As String
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & _
" Values(" & Me!SalesID & ", " & Format(DateDiff("m", '"i"', Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, '" & i & "')"
CurrentDb.Execute strSQL, dbFailOnError
Next i
End If
Gelb markiert ist nun die Zeile "Private Sub...".
Rot markiert sind die beiden Zeilen ab "strSQL..."
Welche Fehlermeldungen werden dir angezeigt? Lässt sich damit nichts anfangen?
Und was hat dich dazu veranlasst, den Code an dieser Stelle zu ändern?
ZitatFormat(DateDiff("m", '"i"', Me!SalesDate)
Was für einen Datentyp hat das Feld "Notes"? Ist es kein Text, so lass die Hochkommata weg.
Und am Ende fehlt natürlich das "End Sub".
Aaber...
Was hast du mit dem GotoRecord am Anfang im Sinn?
Dadurch verlierst du doch den aktuellen Datensatz und somit die Steuerelementinhalte!
BTW:
Deklarationen gehören an den Anfang der Prozedur.
Die Hochkommata sind weg. "Notes" ist vom Felddatentyp "Zahl".
Ich habe das "-1" weggelassen, weil er ja wie oben beschrieben soll je nach Rückzahlung immer +1 Monat auf das Sales Datum drauf rechnen soll.
Das End Sub ist vorhanden, ich hab es lediglich vergessen zu kopieren.
Angezeigt wird mir ein Fehler beim Kompilieren: - Syntaxfehler. Rot markiert wird die SQL-Zeile.
Mit dem GoToRecord wollte ich ihm sagen, dass er nach dem Klick auf dem Button zu einem neuen Datensatz springen soll.
Der Button befindet sich in dem Formular "AddSales" und wenn ich ein Sales angelegt habe, möchte ich anschließend ja eventuell noch einen weiteren Sale hinzufügen.
Damit speichere ich also die Sales Daten in der Sales Tabelle und gleichzeitig soll er mir eben die Zahlungstermine zu diesem Sale in der Tabelle CF_Installments abspeichern.
Was genau meinst du mit Deklarationen?
ZitatIch habe das "-1" weggelassen, weil [...]
Du hast nicht nur -1 weggelassen, sondern i in Hochkommata
und Gänsefüßchen gesetzt.
ZitatMit dem GoToRecord wollte ich ihm sagen, dass er nach dem Klick auf dem Button zu einem neuen Datensatz springen soll.
Das ist mir schon klar, aber dann verlässt du doch den aktuellen Datensatz und woher sollen dann die Daten für die Anfügeabfrage genommen werden?
ZitatWas genau meinst du mit Deklarationen?
Zum Beispiel die DIM-Anweisung.
Vielleicht wäre dies die bessere Code-Folge:
Private Sub AddNewSale_Click()
Dim strSQL As String
Me.Dirty = False ' speichern
If Me!lstRepaymentPlan = 1 Then
For i = 1 To 9
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & _
"Values(" & Me!SalesID & ", " & Format(DateDiff("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, " & i & ")"
CurrentDb.Execute strSQL, dbFailOnError
Next i
End If
DoCmd.GoToRecord , "", acNewRec
End SubHier fehlt dann nur noch eine Fehlerbehandlung.
Ich habe es in allen Varianten mit Hochkommate+Gänsefüße oder ohne oder nur eines davon ausprobiert.
Ok, ich habe nun das GoToRecord zum Schluss gestellt. Und die DIM-Anweisung am Anfang. Jetzt sieht es so aus:
Private Sub AddNewSale_Click()
Dim strSQL As String
If lstRepaymentPlan = 1 Then
For i = 1 To 9
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values(" & Me!SalesID & ", " & Format(DateDiff("m", "i", Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, '" & i & "')"
CurrentDb.Execute strSQL, dbFailOnError
Next i
End If
DoCmd.GoToRecord , "", acNewRec
End Sub
Jetzt meint er als Fehler "Laufzeitfehler 13 - Typen unverträglich".
Und markiert wieder die sql-Zeile.
In CF_Installments sind
- ReferingSale = Zahl
- InstallmentDate = Datum/Uhrzeit
- InstallmentSum = Zahl
- Notes = Zahl
Im AddSales-Formular sind:
- SalesID und SalesDate Textfelder
- SalesDate hat das Formal Datum, kurz
- SalesID ist PK.
Hallo Paul,
1. In deinem Modul fehlt das "Option Explizit" im Modulkopf.
2. Deshalb fällt es VBA nicht auf, dass da ein Dim i As Integer fehlt.
3. Eben weil i ein Integer ist müssen die "" da weg.
gruss ekkehard
Hi Ekkehard,
ah ok, ich bin jetzt also bei folgendem Code gelandet:
Private Sub AddNewSale_Click()
Dim strSQL As String
Dim i As Integer
If lstRepaymentPlan = 1 Then
For i = 1 To 9
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values(" & Me!SalesID & ", " & Format(DateDiff("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, [b]'" & i & "'[/b])"
CurrentDb.Execute strSQL, dbFailOnError
Next i
End If
DoCmd.GoToRecord , "", acNewRec
End Sub
Das Option Exlicit ist eingefügt.
Jetzt sagt er mir: Fehler beim Kompilieren - Variable nicht definiert.
ZitatJetzt meint er als Fehler "Laufzeitfehler 13 - Typen unverträglich".
Schau dir meinen Code-Vorschlag an. Du hast die Hochkommata bei Notes (um "i") nicht entfernt.
ZitatJetzt sagt er mir: Fehler beim Kompilieren - Variable nicht definiert.
Er nennt (oder zeigt) dir aber auch den Namen der Variablen, warum sagst du das nicht gleich dazu?
Also ich habe alle Hochkommata in meinen Augen entfernt.
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values(" & Me!SalesID & ", " & Format(DateDiff("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, " & i & ")"
Bei dem letzten "i" war ich mir nicht sicher, deswegen wollte ich es fett markieren.
Er zeigt mir lediglich an "Fehler beim Kompilieren - Variable nicht definiert". Mehr nicht.
Im VBA-Editor hinterlegt er dann erst dbFailOnError blau, aber das verschwindet sofort, wenn ich woanders hinklicke. Außerdem ist das ja keine Variable (?).
Nein, dbFailOnError ist eine Konstante, aber das kann Access nicht wissen, wenn es sie nicht kennt. ;-)
Du kannst statt dessen den Direktwert 128 schreiben. Vermutlich fehlt dir der Verweis auf die DAO-Bibliothek, aber wenn du sie bisher nicht gebraucht hast, geht es halt auch so.
Du sagtest Notes wäre vom Typ Zahl, also müssen die markierten Hochkommata weggelassen werden.
Ah ok,
vielen Dank! Jetzt funktioniert das einfügen der Datensätze auf jeden Fall schon mal.
Die Verwirrung war ein wenig bei den Datumsangaben. Ich muss natürlich DateAdd statt DateDiff verwenden. Und nun klappt es wunderbar.
Das ist so cool, das spart so viel Zeit! :)
Ich muss mich doch nochmal melden diesbezüglich.
In meiner Probe-Datenbank mit den exportierten Tabellen aus meiner Original-Datenbank hat das einwandfrei funktioniert.
Nun habe ich in meinem AddSales Formular zum Anlegen von neuen Verkäufen den VBA-Code aus der Probe-Datenbank eingefügt.
Leider bekomme ich dann mit Klick auf die Schaltfläche eine Fehlermeldung, die in der Probe-Datenbank nicht vorhanden war.
Der Fehler ist Laufzeitfehler 3201 - Der Datensatz kann nicht hinzugefügt oder geändert werden, da ein Datensatz in der Tabelle SA_Sales mit diesem Datensatz in Verbindung stehen muss.
Anscheinend fügt er den Verkauf nicht hinzu. Woran kann das liegen, denn in der Probe-Datenbank klappt das wunderbar?
Im Debugger markiert er mir die Zeile CurrentDb.Execute gelb an.
Hier der Code:
Private Sub AddNewSale_Click()
Dim strSQL As String
Dim i As Integer
If Liste80 = "SET_CAMP" Then
For i = 1 To 9
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values(" & Me!SalesID & ", " & Format(DateAdd("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 40000, " & i & ")"
CurrentDb.Execute strSQL, 128
Next i
End If
If Liste80 = "SET_MB2-200" Then
For i = 1 To 6
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values(" & Me!SalesID & ", " & Format(DateAdd("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 20000, " & i & ")"
CurrentDb.Execute strSQL, 128
Next i
End If
If Liste80 = "SET_TREX" Then
For i = 1 To 6
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & " Values( " & Me!SalesID & ", " & Format(DateAdd("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", 10000, " & i & ")"
CurrentDb.Execute strSQL, 128
Next i
End If
DoCmd.GoToRecord , "", acNewRec
End Sub
Hi,
vielleicht zeigst du mal einen Ausschnitt aus dem Beziehungsfenster mit den beiden Tabellen, damit man sieht wie das zusammenhängt?
Hi,
also die Tabelle CF_InstallmentsT steht mit der Tabelle SA_Sales in folgender Verbindung.
Ich habe den PK aus SA_Sales ("SalesID") mit dem Feld "ReferingSale" in CF_InstallmentsT als 1:n Verbindung verknüpft.
Ok, ich habe jetzt mal die Beziehung zwischen den Tabellen gelöscht und dann klappt es wunderbar.
Hat das irgendwelche Nachteile?
Beziehungen zu löschen, die eigentlich Sinn machen, ist ganz gewiss keine Lösung.
Möglicherweise muss der aktuelle Datensatz erst gespeichert werden, ehe die Anfügeabfragen gestartet werden können.
Das heißt ich füge noch vor dem "dim..."-Anweisung noch folgende Code-Zeile ein:
DoCmd.RunCommand acCmdSaveRecord
Und das funktioniert jetzt auch mit Beziehung.
Danke!
Hallo,
so könnte der Code etwas übersichtlicher gestaltet werden:
Private Sub AddNewSale_Click()
Dim strSQL As String
Dim i As Integer, j As Integer, instS As Long
DoCmd.RunCommand acCmdSaveRecord
' altern.
' Me.Dirty = False
Select Case Me!Liste80
Case "SET_CAMP"
j = 9
instS = 40000
Case "SET_MB2-200"
j = 6
instS = 20000
Case "SET_TREX"
j = 6
instS = 10000
End Select
For i = 1 To j
strSQL = "INSERT INTO CF_InstallmentsT (ReferingSale, InstallmentDate, InstallmentSum, Notes) " & _
"Values(" & Me!SalesID & ", " & Format(DateAdd("m", i, Me!SalesDate), "\#yyyy\/mm\/dd\#") & ", " & instS & ", " & i & ")"
CurrentDb.Execute strSQL, 128
Next i
DoCmd.GoToRecord , "", acNewRec
End Sub
Hallo,
vielen Dank. Das sieht in der Tat besser aus!