0

Bug Erstellung Rechnungsnummer

hab eben den fatalen fehler entdeckt, dass rechnungsnummern dopplet vergeben werden ... ist erst einmal passiert, darf aber einfach nicht sein ... oben die formel, sieht da jemand die ursache, wie sopwas passieren kann ... normal sollte ninox fortlaufende nummern erstellen und niemals, NIEMALS eine dopplet vergeben ...

 

danke für die hilfe!!

9 Antworten

null
    • Astavakra
    • vor 1 Jahr
    • Gemeldet - anzeigen

    natürlich entsteht der fehler hier nur, wenn man ältere als den letzten datensatz löscht, was man bei rechnungen ohnehin nicht tun sollte ... aber vielleicht gibt es eine sicherere lösung, die sich zb an der rechnungsnummer mit der höchsten nummer (format ist ja zb KB-2022/123) orientiert - also wenn die letzte so wie das beispiel ist, dass man dann daraus die folgende also 124 generiert ... nur wie gieß ich das in eine formel, dass ich einerseits diese nummer abgreife, andererseits daraus die nächste erstelle?

      • Michi.1
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Astavakra Grüß dich,

      Ein Bug ist es nicht, da ja die Datensätze gezählt werden. Wenn einer fehlt gibt es Probleme. Dann lieber mit max(select arbeiten, dann nimmt ninox die höchste Zahl als Referenz.

      • Astavakra
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Michi danke dir ... werd ich versuchen - muss mich vorher in die funktion einlesen - oder schüttelt das hier jemand aus dem ärmel? :)

    • Ninox-Professional
    • planoxpro
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Hi, für lückenlos fortlaufende Rechnungsnummern sollte man sich an den tatsächlich bereits vergebenen orientieren. Also die aktuell höchste auslesen und dann um Eins erhöhen. Zum Beispiel so: 

    let myJ := format('Erstellt am', "YYYY");
let lastNum := max((select ARs where substr('Rg Nr', 3, 4) = myJ).substr('Rg Nr', 8));
'Rg Nr' := "AR-" + myJ + "/" + format(number(lastNum) + 1, "000")
      • Astavakra
      • vor 1 Jahr
      • Gemeldet - anzeigen

      planox. pro super, danke 

      • Tacho
      • vor 1 Jahr
      • Gemeldet - anzeigen

      planox. pro 

      was passiert im Falle, dass die letzte Rechnung (aktuell höchste) gelöscht wurde?

      • Ninox-Professional
      • planoxpro
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Tacho Das liegt doch auf der Hand: Wenn die Nr. "073" gelöscht wird, ist "072" wieder die höchste. Und die nächste neue Nr. wird wieder "073" sein. Die ist dann aber nicht doppelt, weil die vorherige mit "073" ja gelöscht wurde.

      • Tacho
      • vor 1 Jahr
      • Gemeldet - anzeigen

      planox. pro 
      Das Ergebnis war mir schon klar. Danke, der auf der Hand liegenden Erklärung ;-)

      War eigentlich mehr darauf gemünzt, ob es nicht revisionsproblematisch sein könnte, wenn eine Nummer faktisch mehrfach gleich generiert werden kann. Wäre es nicht besser, auf die höchste gelöschte Nummer dennoch die nächst folgende generieren zu lassen? Um an Deinem Beispiel zu bleiben: "073" wird gelöscht, "072" ist dann zwar höchste, aber die nächste neue Nummer wird dann "074".

      • Ninox-Professional
      • planoxpro
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Tacho 

      Nein, das wäre m. E. nicht besser, weil man dann bei der Nummerierung eine offensichtliche Lücke hätte. Wie erklärt man dem FA ggf. das Fehlen der Nummer "073"? Noch schlimmer wäre es, wenn die Nr. "073" bereits an den Kunden versendet und danach aus Ninox gelöscht wurde. Dann müsste man theoretisch die "074" nehmen, weil die "073" de facto ja schon vergeben ist, auch wenn sie in Ninox(!) nicht mehr existiert. Und man hätte nicht nur das Problem der Lücke, sondern auch das der inhaltlichen Unvollständigkeit. 

      Kurzum: Man sollte einmal erstellte Rechnungs-Datensätze generell niemals löschen, sondern statt dessen immer stornieren und im System behalten. Damit würde man nicht nur oben beschriebene Probleme vermeiden, sondern hätte darüber hinaus mit den lückenlosen, von Ninox vergebenen und nicht manipulierbaren Datensatznummern auch dem FA gegenüber ein gewichtiges Argument hinsichtlich der GoBD-Konformität.

Anmelden, um zu antworten

Content aside

Kategorien

Alle Themen anzeigen
  • vor 1 JahrZuletzt aktiv
  • 9Antworten
  • 70Ansichten
  • 4 Folge bereits