Neu Rechnung für weitere Bearbeitung sperren - SQL nIstReadOnly = 1

[xadoX]

Hallo zusammen,

wir würden gerne alle Rechnungen, die wir bereits zu unserer Steuerkanzlei geschickt haben auf nIstReadOnly 1 setzen. Wir haben 1,3 Millionen Bestellungen in der Datenbank.
Folgenden SQL haben wir nach 4 Tagen Laufzeit nun abgebrochen.

Der SQL: update tbestellung set nIstReadOnly = 1

Sieht jemand eine Möglichkeit wie man den Wert bei nIstReadOnly schneller gesetzt bekommt?

 

[Enrico W.]

Wo fange ich an? Ich würd sagen, ich fange damit an, dass Eingriffe in die Datenbank grundsätzlich keine gute Idee sind.
Und ich setze fort mit der bereits in der Wawi eingebauten Funktionalität:

 

[xadoX]

Wo fange ich an? Ich würd sagen, ich fange damit an, dass Eingriffe in die Datenbank grundsätzlich keine gute Idee sind.

Stimme ich dir grundsätzlich zu. Aber eine 0 in eine 1 zu setzen, um eine gewünschte Funktionalität zu bekommen sollten für einen erfahrenen JTL-Nutzer, der mit JTL seit über 10 Jahren arbeitet doch plausibel sein.
Getestet wird es natürlich in einer Testdatenbank und nicht im Livebetrieb.

Die Einstellung in den Globalen Einstellungen ist mir bekannt. Allerdings kann man damit nur global einstellen, dass alle Rechnungen nicht mehr bearbeitet werden können.
Wir würden als Einschränkung natürlich noch den Monat mit reinnehmen. Und diese Funktionalität bekomme ich über JTL leider nicht.

update tbestellung set nIstReadOnly = 1 where kbestellung in (select tbestellung_kbestellung from trechnung where derstellt < '2022-31-03 23:59:59.999') and nIstReadOnly = 0

 

[Enrico W.]

Buchhalterisch richtig ist, dass Rechnungen nicht geändert werden dürfen sondern gutgeschrieben und neu erstellt werden müssen.
Und ich wage es nicht abzuschätzen, ob da noch andere Geschichten dran hängen, wenn man Werte ändert. Es KANN durchaus sein, aber muss nicht.

 

[xadoX]

Vielleicht hat ja jemand eine Idee warum ein Update auf die Tabelle tbestellung mit dem o.g. SQL mehr als 4 Tage läuft und dazu einen Lösungsvorschlag.

 

[Enrico W.]

Wir haben 1,3 Millionen Bestellungen in der Datenbank

Könnte eventuell daran liegen plus den sicherlich ständigen Zugriffen bei der täglichen Arbeit, Abgleichen etc.
Aber mehr als Vermutungen wirst Du nicht bekommen, man müsste das System selbst untersuchen.

 

[xadoX]

Der SQL wurde auf einer Testdatenbank ausgeführt und die ist gekoppelt von allen Zugriffen.

 

[Enrico W.]

Ok, du siehst, ohne zusätzliche Informationen stochert man einfach mal im Trüben herum.

 

[xadoX]

Welche Informationen könnten denn helfen? Ich kann die sicherlich besorgen.

 

[Enrico W.]

man müsste das System selbst untersuchen.

Das fängt bei der Rechnerkonfiguration an, geht weiter über die mitlaufende Software und endet irgendwann bei Microsoft SQL und der Wawi.

 

[xadoX]

Ok, dann versuche ich mein Glück:

SQL Server 2019
PowerEdge R640 Server
2x Intel Xeon Gold 6136 3,0 GHz
192 GB Ram
10x 480 GB SSD
Wawi 1.5.55.0

Auf dem Server läuft nur JTL und er ist nach Anleitung von JTL konfiguriert

 

[SebastianB]

Hi,

Es ist keine gute Idee, den o.g. Haken in der 1.5 nicht zu nutzen. Der sollte immer aktiv sein und nur in absoluten Ausnahmefällen kurz rausgenommen werden, wenn es keine andere Lösung gibt.

Dazu kommt: nIstReadOnly ist nicht das selbe wie "Rechnung kann nicht mehr verändert werden": Wir verwenden nIstReadOnly um bei VCS-Bestellungen bestimmte Dinge zu verhinden - aber manche Änderungen an den Aufträgen sind dennoch möglich. Ein wirkliches "festschreiben" gibt es erst mit der JTL-Wawi 1.6.

Aus dem Grund ist das ganze nicht auf Massenänderungen ausgelegt, deshalb wird beim Update von nIstReadOnly auch die Eckdatenberechnung aufgerufen - und das dauert bei so vielen Aufträgen.

Aus diesen beiden Gründe würde ich von dem Vorhaben abraten.

Wenn Du es dennoch durchziehen möchtest: Du solltest in Batchen arbeiten - also anstelle von 100000 Bestellungen in einem SQL lieber 100 SQLs mit 1000 Bestellungen - dann sind die Transaktionen kürzer und flotter.

LG,
Sebastian

 

[xadoX]

Hallo @SebastianB,

splittet man den SQL geht es wirklich viel besser. Jetzt ist aber aufgefallen, dass man die Auftragspositionen trotzdem noch bearbeiten kann.
In der Tabelle tbestellpos gibt es kein Feld "nIstReadOnly". Ist es von JTL gewollt, dass die Positionen noch bearbeitbar sind?

 

[Shopworker.de]

Jetzt ist aber aufgefallen, dass man die Auftragspositionen trotzdem noch bearbeiten kann.

Ein wirkliches "festschreiben" gibt es erst mit der JTL-Wawi 1.6.

nIstReadOnly ist nicht das selbe wie "Rechnung kann nicht mehr verändert werden": Wir verwenden nIstReadOnly um bei VCS-Bestellungen bestimmte Dinge zu verhinden - aber manche Änderungen an den Aufträgen sind dennoch möglich.