Neu Wie bedenklich wäre es, den Vorgangsstatus von Aufträgen über einen direkten Datenbankbefehl zu aktualisieren?

[Ahok]

Es müsste theoretisch nur die ID geändert werden, aber ich bin mir nicht sicher ob in JTL noch irgendwelche andere Dinge passieren müssen, wenn ein Vorgangsstatus geändert wird. Eigentlich sollte das kein Problem sein, mal abgesehen vom typischen "JTL rät nicht in die Datenbank zu schreiben", oder?

 

[Peeters]

Warum sollte man so etwas überhaupt tun wollen?

 

[ergowebshop]

Na sicherlich um massenweise Aufträge zu ändern und eine Statusänderung die über die Wawi selbst nicht geht, z.B. was rückgängig machen.

Würde theoretisch gehen, käme aber drauf an welche Art von Statusänderung!?

Ändert aber nicht die Farbe, Priorität. Dann gibt es den Vorgangsstatus (verlinkt mit tVorgangsstatus)
Zusätzlich zum Hauptstatus nAuftragStatus gibt es aber drüben in der tAuftragEckdaten Tabelle noch den nZahlungStatus, nLieferstatus, nRechnungStatus, Bezahlstatus/datum in dBezahlt und ggf. noch mehr zu bedenken.

Auch würden Änderungen nicht in der Historie auftauchen oder du müsstest tAuftragHistorie anpassen.
Dann kommt noch dazu dass eine Statusänderungen keine Lagerbuchungen durchführt oder rückbucht...
Und schon sobald es Stornos betrifft oder diese rückgängig zu machen, nein, da hängen dann noch weitere Tabellen dran.

Und falls auch nur ein Auftrag noch andere Dokumente dranhängen hat, Lieferschein oder gar Rechnung: Finger weg.

Um welche Art der Änderung geht's denn genau?

 

[Ahok]

Na sicherlich um massenweise Aufträge zu ändern und eine Statusänderung die über die Wawi selbst nicht geht, z.B. was rückgängig machen.

Würde theoretisch gehen, käme aber drauf an welche Art von Statusänderung!?

Ändert aber nicht die Farbe, Priorität. Dann gibt es den Vorgangsstatus (verlinkt mit tVorgangsstatus)
Zusätzlich zum Hauptstatus nAuftragStatus gibt es aber drüben in der tAuftragEckdaten Tabelle noch den nZahlungStatus, nLieferstatus, nRechnungStatus, Bezahlstatus/datum in dBezahlt und ggf. noch mehr zu bedenken.

Auch würden Änderungen nicht in der Historie auftauchen oder du müsstest tAuftragHistorie anpassen.
Dann kommt noch dazu dass eine Statusänderungen keine Lagerbuchungen durchführt oder rückbucht...
Und schon sobald es Stornos betrifft oder diese rückgängig zu machen, nein, da hängen dann noch weitere Tabellen dran.

Und falls auch nur ein Auftrag noch andere Dokumente dranhängen hat, Lieferschein oder gar Rechnung: Finger weg.

Um welche Art der Änderung geht's denn genau?

Es geht nur darum, dass Fahrer den Status "Rechnungserstellung gesperrt" per App setzen können wenn sie unterwegs sind. Ein Workflow hat das dann als Bedingung keine Rechnung zu erstellen, wenn das gesetzt ist.

 

[ergowebshop]

Ist mir neu, könnte das in Features sein

UPDATE Verkauf.tAuftragFeatures
SET
    nRechnungErstellen     = 0,
    nTeilrechnungErstellen = 0
WHERE kAuftrag = 123;

Wie wäre es einfach mit einem Eigenen Feld, wenn es eh nur für die Workflow Bedingung ist?

 

[Ahok]

Ist mir neu, könnte das in Features sein

UPDATE Verkauf.tAuftragFeatures
SET
    nRechnungErstellen     = 0,
    nTeilrechnungErstellen = 0
WHERE kAuftrag = 123;

Wie wäre es einfach mit einem Eigenen Feld, wenn es eh nur für die Workflow Bedingung ist?

Der Status ist nicht von JTL. Vorgangstatus kann man frei erfinden, so wie eigene Felder. Wir haben den nur so genannt. Wenn dieser Status gewählt wurde, blockt das den Workflow.