Auswahl von Lieferanten in Verkaufslieferscheinmaske ermöglichen

[demofreak@…]

Es sollte möglich sein, in Verkaufslieferscheinen zusätzlich zu den Kunden auch die Lieferanten auswählen zu können. Dadurch wäre man in der Lage, Retouren von Fehllieferungen bzw. Testgeräten einfach abbilden zu können. Momentan ist man gezwungen, die Teile über die Lagerverwaltung auszulagern und den Lieferschein manuell zu erstellen.

Ich werde in den nächsten Tagen versuchen, soweit durchzusteigen, dass ich das in der aktuellen unstable bei mir mal reinbastele, um Seiteneffekte austesten zu können.

So, ein erster Teil eines Retourenlieferscheins ist als Branch "return_delivery_order" unter ​http://www.chdstudt.de/files/lx-office-erp/.git zu finden.

Bisher gibt es zwei neue Menüpunkte, "Retourenlieferschein erfassen" und unter Reports "Retourenlieferscheine". Das Hinzufügen, Bearbeiten und Auslagern/Schliessen? der Lieferscheine funktioniert, ebenso die korrekte Anzeige der Dokumente im Lagerbuchungsjournal. Die Datenbankstruktur wird nicht verändert, d.h. die Änderungen sind zur Not sogar rückwärtskompatibel (mit ein paar Abstrichen bei der Anzeige der Reports).

Was bisher noch nicht abschliessend stimmt, sind z.B. die Buttons im Workflow (es hat sicher keinen Sinn, aus einem solchen Lieferschein eine Rechnung zu generieren). Ich hätte gern Hinweise dazu, was außerdem alles noch unstimmig ist, wenn sich also jemand zum Test bereitfinden würde, wäre ich dankbar.

Zwischenstand: es gibt inzwischen auch das Gegenstück im Verkauf (Warenrücknahme) und ein paar kleinere Unstimmigkeiten sind erledigt.
Ich suche immer noch jemanden, der sich erbarmt und mal ein wenig testet. ;-)

(In reply to comment #3)

Zwischenstand: es gibt inzwischen auch das Gegenstück im Verkauf
(Warenrücknahme) und ein paar kleinere Unstimmigkeiten sind erledigt.
Ich suche immer noch jemanden, der sich erbarmt und mal ein wenig testet. ;-)

Vergessen: das Repo ist unter ​http://www.chdstudt.de/git/?p=lx-office-erp.git bzw. ​git://chdstudt.de/lx-office-erp zu finden, der Branch heißt inzwischen return_redemption

Ich habe es mir noch nicht angesehen, möchte aber Folgendes zu bedenken geben:

Der Typ eines Lieferscheines (Einkauf oder Verkauf) ist in der Datenbank nicht separat gespeichert. Bisher wird er daraus abgeleitet, ob vendor_id oder customer_id NULL ist (bei vendor_id ISNULL ist es natürlich ein Verkaufslieferschein und umgekehrt).

Wenn man Lieferscheine aus dem Menü heraus aufruft, gibt es den Parameter "type". Daher weiß die Oberfläche auch anders, welchen Typ sie bearbeiten soll. Dieser ist aber, wie gesagt, nicht in der DB gespeichert.

Das führt mit deinen Änderungen dazu, dass sämtliche Abfragen (z.B. auch in Kundenprojekten), die sich darauf verlassen, dass der Typ über customer/vendor_id ISNULL getestet werden kann, plötzlich ungültig werden.

(In reply to comment #5)

Der Typ eines Lieferscheines (Einkauf oder Verkauf) ist in der Datenbank nicht
separat gespeichert. Bisher wird er daraus abgeleitet, ob vendor_id oder
customer_id NULL ist (bei vendor_id ISNULL ist es natürlich ein
Verkaufslieferschein und umgekehrt).

Genau.

Das führt mit deinen Änderungen dazu, dass sämtliche Abfragen (z.B. auch in
Kundenprojekten), die sich darauf verlassen, dass der Typ über
customer/vendor_id ISNULL getestet werden kann, plötzlich ungültig werden.

Ok, an die Kundenprojekte habe ich nicht gedacht, darüber habe ich auch keinen Überblick. Ich hatte eigentlich gerade wegen der Kompatibilität versucht, ohne ein weiteres DB-Feld auszukommen.
Wenn man partout direkt aus der DB ableiten können muss, ob es ein Verkaufs- oder ein Lieferantenretourenlieferschein ist, kann man das aber auch mit einer simplen Erweiterung der Abfrage tun:

Bisher:

WHEN customer_id IS NULL THEN 'purchase_delivery_order'
ELSE 'sales_delivery_order'

Neu:

WHEN vendor_id IS NULL AND is_sales = TRUE THEN 'sales_delivery_order'
WHEN vendor_id IS NULL AND is_sales = FALSE THEN 'redemption_receipt'
WHEN is_sales = FALSE THEN 'purchase_delivery_order'
ELSE 'return_delivery_order'

Das muss nur entsprechend kommuniziert werden.

Und zur Not muss ich das Ganze dann eben abschaltbar machen, das sollte auch kein zu großes Problem sein. Dann kann man sich aussuchen, ob man diese Funktionalität haben will und zur Not seine eigenen Erweiterungen überprüfen muss, oder ob einfach alles weiter so funktioniert wie bisher.

(In reply to comment #6)

Und zur Not muss ich das Ganze dann eben abschaltbar machen, das sollte auch
kein zu großes Problem sein. Dann kann man sich aussuchen, ob man diese
Funktionalität haben will und zur Not seine eigenen Erweiterungen überprüfen
muss, oder ob einfach alles weiter so funktioniert wie bisher.

Genau genommen ist es bereits abschaltbar, weil man für beide Funktionen ein neues Recht benötigt. Wenn selbiges nicht vergeben ist, ist die Funktion außer Dienst und alles sollte vollkommen kompatibel zu bestehenden Erweiterungen sein.

Reicht nicht aus. Dann schaltet man es mal kurz zum Ausprobieren ein und lässt es so; bastelt dann Lieferscheine, die teilweise falsch behandelt werden.

Ja, man muss für alle Belegtypen (nicht nur Lieferscheine) direkt aus dem Datenbankinhalt ableiten können, was sie für welche sind.

(In reply to comment #8)

Reicht nicht aus. Dann schaltet man es mal kurz zum Ausprobieren ein und lässt
es so; bastelt dann Lieferscheine, die teilweise falsch behandelt werden.

Dieser menschliche Faktor ist zwar vorhanden, aber eigentlich kein Argument. Wer in einer produktiven Installation "rumprobiert", obwohl der Umstand dokumentiert ist, ist selber schuld.
Was freilich nix daran ändert, dass man versuchen sollte, das zu verhindern.

Ja, man muss für alle Belegtypen (nicht nur Lieferscheine) direkt aus dem
Datenbankinhalt ableiten können, was sie für welche sind.

Ok, kann man. "is_sales" und "vendor/customer_id" ergeben eine eindeutige Identifizierung des Belegtyps.