[Gelöst] Buchungsnummer in Verkaufskopf - Rechnung scheitert
23. Januar 2008 12:29
Hallo, ich habe bei einem Kunden das Problem:
- der Kunde ruft die Stapelbuchung von VK-Aufträgen auf und liefert zunächst täglich ca. 1000 Belege.
- danach ruft er wiederum die Stapelbuchung auf und fakturiert nun danach diese Aufträge. Dabei kommt es vor, dass nicht alle Aufträge z.B. aufgrund fehlender Zeilendimensionen fakturierbar sind.
Wenn man nun in diese hineingeht und die Zeilendimensionen ergänzt, kommt beim Buchen die Meldung, dass es die Rechnungsnummer schon gibt.
Im Zoom auf den Verkaufskopf erkennt man, dass das Feld "Buchungsnr." einen Eintrag hat.
Soweit konnte ich das auf einer Cronus-DB auch nachstellen. Nur lassen sich hier dann diese hängengebliebenen Aufträge anstandslos fakturieren.
Bei dem Kunden muss hingegen über den Object Designer die Buchungsnummer entfernt werden, damit der Auftrag zu fakturieren ist.
Hatte jemand schon mal so ein Problem, und wie wurde das gelöst?
Grüße thommes.
- der Kunde ruft die Stapelbuchung von VK-Aufträgen auf und liefert zunächst täglich ca. 1000 Belege.
- danach ruft er wiederum die Stapelbuchung auf und fakturiert nun danach diese Aufträge. Dabei kommt es vor, dass nicht alle Aufträge z.B. aufgrund fehlender Zeilendimensionen fakturierbar sind.
Wenn man nun in diese hineingeht und die Zeilendimensionen ergänzt, kommt beim Buchen die Meldung, dass es die Rechnungsnummer schon gibt.
Im Zoom auf den Verkaufskopf erkennt man, dass das Feld "Buchungsnr." einen Eintrag hat.
Soweit konnte ich das auf einer Cronus-DB auch nachstellen. Nur lassen sich hier dann diese hängengebliebenen Aufträge anstandslos fakturieren.
Bei dem Kunden muss hingegen über den Object Designer die Buchungsnummer entfernt werden, damit der Auftrag zu fakturieren ist.
Hatte jemand schon mal so ein Problem, und wie wurde das gelöst?
Grüße thommes.
Zuletzt geändert von thommes am 25. Februar 2008 16:24, insgesamt 1-mal geändert.
23. Januar 2008 13:30
Das ist meiner Meinung nach ein Schönheitsfehler im Standard. Durch einen Commit nach Finden der Buchungsserie kommt es zum Effekt, dass wenn es später zu einem Fehler kommt die Buchungsnr. im Verkaufskopf nicht mehr zurück gesetzt wird. Ich meine das bei einem Kunden so gelöst zu haben, dass ich das Feld am Anfang der CU80 leere - mir wäre jetzt auch nicht bewusst dass es hierdurch zu ungewollten Nebeneffekten kommen könnte. Evtl weiss jemand anderes hierzu mehr?
Viele Grüße
Jan
Viele Grüße
Jan
23. Januar 2008 14:11
Genauso machen wir es auch.
23. Januar 2008 14:21
@Jan, das ist kein Schönheitsfehler, das muss so sein wegen der Kontinuität!
@Thommes,
das sieht so aus, als ob ein Teil der Rechnung bereits gebucht wurde, was eigentlich nur aufgrund von individuellen Anpassungen sein kann. Im Cronus sind die nicht, deswegen kannst du die Rechnung später mit der bereits vergebenen Nummer buchen. In der DB eures Kunden scheint da aber zwischendurch noch ein Commit zu stecken, der irgendwelche Buchungen festschreibt, wenn dann danach in der gleichen Rechnung ein Problem auftritt, wird nur das nach dem Commit zurückgenommen, es gibt dann aber schon die Rechnung mit der Nummer
@Thommes,
das sieht so aus, als ob ein Teil der Rechnung bereits gebucht wurde, was eigentlich nur aufgrund von individuellen Anpassungen sein kann. Im Cronus sind die nicht, deswegen kannst du die Rechnung später mit der bereits vergebenen Nummer buchen. In der DB eures Kunden scheint da aber zwischendurch noch ein Commit zu stecken, der irgendwelche Buchungen festschreibt, wenn dann danach in der gleichen Rechnung ein Problem auftritt, wird nur das nach dem Commit zurückgenommen, es gibt dann aber schon die Rechnung mit der Nummer
23. Januar 2008 14:30
Hi, das wäre eine Option (so mache ich das ja momentan auch schon manuell). Nur: wie erklärt man die entstehenden Lücken in den gebuchten Rechnungsnummern einem Wirtschaftsprüfer?
Ich werde da mal im Code nachsehen an der Stelle, wenn er auf den Fehler läuft. Vielleicht ist da die Prüfung auch etwas sonderbar codiert.
Ich werde da mal im Code nachsehen an der Stelle, wenn er auf den Fehler läuft. Vielleicht ist da die Prüfung auch etwas sonderbar codiert.
23. Januar 2008 14:32
@Michael: da haben sich unsere Einträge zeitlich überschnitten 
Ja, die Lücken in den Nummernserien machen mir insgeheim auch schon Sorgen...
Ja, die Lücken in den Nummernserien machen mir insgeheim auch schon Sorgen...
23. Januar 2008 14:50
Der Fehler tritt in der CU12 auf, nicht in der CU80. Nur so noch als Ergänzung zu meinem Fall...
25. Februar 2008 16:22
Hallo, Problem ist gelöst. War was ganz Dummes: die Belegnummern, die sich nicht buchen liessen, stammten bereits aus der Datenübernahme (Saldovorträge, OPs). Das hat mir auch erst keiner gesagt, dass da ein Nummerchaos geherrscht hat in der Vorgängersoftware. Demnach: shit happens.