Problem im Report mit OP und ANZ

[Grayworks]

Hallo,

in einem typischen Workflow, wo mit VK-Aufträgen OP angelegt werden, die durch Zahlung zu 100% ausgeglichen werden, woraufhin dann geliefert wird.

Das BAND ANZ der LS/RE wird angezeigt, wenn es eine Zahlung gibt:      ANZ.visible := (<OPV."BISHERGEZAHLT"> <> 0); Diese Zahlung fußt aber nicht auf der LS/RE sondern dem früheren VK-Auftrag, der eine andere Nummer hat.

Jetzt gibt es ein riesen Problem mit den OPV. Die SQL Anfrage, die wir nutzen funktioniert zwar, aber manchmal unerklärlicherweise nicht.

  Select *                                                                                                                                  
  from OPV
  where OPV.KUNDENNR =: KUNDENNR

mit Master auf Kopf_Fuss

gibt es eine bessere SQL, die auf keinen Fall hier Probleme machen würde? Das Problem tritt nur manchmal auf.

Bearbeitet 29. August 2022 von Grayworks

[A.Zweimüller]

Hallo Grayworks,

so wie die Abfrage jetzt ist, wird der Offene Posten über die Kundennummer abgefragt, hat der Kunde mehrerer Offene Posten, wird (bin mir jetzt nicht sicher) der erste oder der letzte Eintrag genommen der in der Tabelle OPV, für diesen Kunden, gefunden wird. 

Das erklärt es auch das es nur ab und an auftritt, nämlich nur dann wenn der Kunde mehrerer OP´s hat. 

Besser ist es über die Belegnummer / Beleg ID zu gehen. 

  Select * from OPV
  where OPV.BEK_ID =:ID

 

 

Master wie gehabt Kopf_Fuss

 

Gruß 

Andreas Zweimüller 

[Grayworks]

Hallo Andreas,

vielen Dank für den Vorschlag, das hätte ich noch erwähnen sollen. Wir hatten deinen Vorschlag davor schon im Einsatz, aber dann kam es bei einigen Rechnungen dazu, dass gar keine Daten in der IBDAC "OPV" vorhanden waren. Das war dann immer der Fall, wenn aus irgendeinem Grund der OPV nicht mit der LS/RE in Zusammenhang gebracht wurde, also VARIO das nicht verknüpft hat. Dann war die Zahlung anhand des VK-Auftrages praktisch alleinstehend. Kann man in so einer Situation auch per SQL Abhilfe schaffen zum Beispiel aus dem Auftrag/Bestellnummer die Daten ziehen, um das ganze robuster zu gestalten?

[A.Zweimüller]

Hallo 

Ein Offene Posten wird erst angelegt sobald der Beleg gebucht ist, bei einer Rechnung, oder Auftrag mit VK / ANZ ... erst ab Buchen entsteht ein Offener Posten.

Wenn ich es richtig verstanden habe kauft der Kunde etwas auf Vorkasse, zahlt diese aber nicht auf den Auftrag o. Rechnung sondern gesondert? 

Das einzige was mir da spontan einfällt, wenn man über die Kundennummer geht, ist den Betrag zu vergleichen... da ist jedoch auch erst ein vergleich möglich bei Buchung des Zahlungseingang auf die Kundennummer, UND! was wenn der Kunde X mal den selben Artikel mit dem identischen Preis kauft.  

[Grayworks]

Hallo Andreas,

danke für deine Hilfe dabei, dieser Sache auf den Grund zu gehen.

Du hast Recht, es sollte so laufen, dass die VARIO den VK-Auftrag bei Buchung als OPV speichert. dann eine Zahlung eingeht, womit der OPV abgeschlossen wird, dann wird geliefert und übernommen entweder in LS dann RE oder gleich in eine LS/RE. Dadurch das VARIO diese Kette verknüpft weiß VARIO das der OPV letztendlich zur Schlussrechnung gehört. Normalerweise läuft das bei uns auch so und dann ist alles gut.

Jetzt kam es bei einer bestimmten Rechnung aber vor, dass dann in der IBDAC"OPV" keine Daten verfügbar waren. Der VK-Auftrag steht in der 7.2 als offener Posten drin, aber nicht die später ausgestellte Rechnung, die bei der 7.2 gar nicht aufgeführt wird.
Das haben wir dann durch die obige Sache mit der Kundennr lösen können für den Report, was aber ja neue Probleme verursacht. Vielleicht ist das also ein Problem mit dem Workflow bei uns, oder bei VARIO ist intern irgendwo die Kette abgerissen.

Das vielleicht auch für andere, denen Ähnliches widerfahren ist.

Also was mir hier als potenzielle Lösung vorschwebte, um das idioten- und ausfallsicher zu gestalten wäre eine SQL, die erst wie oben beschrieben auf die die OPV BEK mit der vorliegenden Schlussrechnung verknüpft, aber dann, wenn keine Daten dadurch gefunden werden können, also konditional, wird als Plan B die BEK_ID mit der ID des zugehörigen Auftrages verknüpft, wodurch dann doch noch der OPV gefunden werden kann.

Sind meine Überlegungen verständlich formuliert?

Nebenbei, wie immer ein großes Dankeschön für deine professionelle Hilfe bei unseren Fragen. Das ist der Grund, warum uns die VARIO mehr und mehr gefällt!

 

Bearbeitet 30. August 2022 von Grayworks

[A.Zweimüller]

Hallo 

Vielleicht vertippt ? 

Sie möchten auf die OPV BEK abfragen? Und wenn da nichts gefunden wird auf die BEK ID abfragen ?

Das müssen Sie bitte genauer beschreiben. 

Es gibt die Tabelle OPV 

und 

die Tabelle BEK 

in der Tabelle OPV steht eine Belegnummer die in der BEK vorhanden ist 

es kann jedoch sein das eine Belegnummer aus der BEK NICHT in der OPV steht. 

 

[Grayworks]

Hallo Herr Zweimüller,

wir sind der Sache jetzt durch ein paar Tests auf den Grund gegangen. Der Fehler lag hier bei uns. Es war so, dass wir VK-Aufträge hatten, die bezahlt wurden, dann haben wir bei den Rechnungen in der Vorschau aber nicht das Band ANZ gefunden und dachten, da sei etwas passiert. Wenn wir aber dann die Rechnung gebucht hatten tauchte das Band ANZ auch auf, wie es sollte. Von daher waren wir einfach verwirrt, weil wir die Rechnung immer noch einmal per Vorschau auf Korrektheit überprüfen wollten, aber erst nach Buchung das Band ANZ so funktioniert, wie es soll.

Vielen Dank an Sie für Ihre Mithilfe hier dennoch!