Neu JTL-Wawi 1.10.8.0 - Aufträge "Zusammenfassen [ist] deaktiviert"

[TREND_Jan]

Hat jemand dazu ein Ticket eröffnet oder als Gold-Supportler mal ein bisschen telefoniert?

Ich denke das gehört zu diesem Ticket: https://issues.jtl-software.de/issues/WAWI-81899

 

[Dee]

Auch wir sind stark von diesem Problem betroffen und haben bereits gevoted und kommentiert. Das manuelle Nachbearbeiten von Aufträgen bindet enorm viel Zeit und führt regelmäßig zu Rückfragen von Kunden.

Wir bitten alle, die ebenfalls betroffen sind, hier auch abzustimmen und sich zu Wort zu melden – je mehr "offizielle" Rückmeldung JTL bekommt, desto größer die Chance, dass dieses wichtige Thema bald angegangen wird. Hoffentlich. 🤷‍♀️

 

[mvh]

Moin.
Anbei unser Vorschlag zur Problemlösung,
mit dem UPDATE-SQL-Code und einer kurzen Erklärung.
In dem Verzeichnis C:\Program Files (x86)\JTL-Software\JTLDiag
das Programm JTLDiag.exe finden und ausführen und mit der "+"-Schaltfläche die "SQL-Konsole" starten.
Nach der SQL-Server-Anmeldung den Code einfügen und ausführen:

UPDATE [eazybusiness].[Verkauf].[tPlattformAuftragFeatures]
SET nZusammenfassen=1, nSplitten=1
WHERE nTyp IN (2)

Hier steht der nTyp 2 für alle Shops.
Wer möchte, kann es auch für 6 (Amazon) und 11 (SCX) übernehmen,
z.B. mit IN (2,6,11)

 

[marsblau]

Moin.
Anbei unser Vorschlag zur Problemlösung,
mit dem UPDATE-SQL-Code und einer kurzen Erklärung.
In dem Verzeichnis C:\Program Files (x86)\JTL-Software\JTLDiag
das Programm JTLDiag.exe finden und ausführen und mit der "+"-Schaltfläche die "SQL-Konsole" starten.
Nach der SQL-Server-Anmeldung den Code einfügen und ausführen:

UPDATE [eazybusiness].[Verkauf].[tPlattformAuftragFeatures]
SET nZusammenfassen=1, nSplitten=1
WHERE nTyp IN (2)

Hier steht der nTyp 2 für alle Shops.
Wer möchte, kann es auch für 6 (Amazon) und 11 (SCX) übernehmen,
z.B. mit IN (2,6,11)

Funktioniert! Danke! Hatte es bisher vermieden, da ich nicht "fummeln" wollte, weil nicht vom Fach.

Auf eine Umsetzung seitens JTL sollte man nie warten wenn es auch anders lösbar ist.
E-Rechnung ist seit 2,5 Jahren bekannt und gesetzliche Pflicht ... und trotzdem pfeift man drauf und läßt nicht valide Rechnungen durchweg erzugen (Rundungs"fehler").

 

[Verkäuferlein]

Wieso haben wir uns entschieden das Zusammenfassen zu sperren? Nicht jeder Verkaufskanal/Marktplatz mag es, wenn sich ein Auftrag grundlegend ändert. Und wenn da auf einmal mehr oder weniger Positionen drin sind als vorher, kann es auch gut sein, dass der Verkaufskanal/Marktplatz den Auftrag sperrt oder verwirft. Um diese Probleme zu vermeiden wurde die Sperre eingebaut.

Kann es sein, dass einfach grundlegend das Datenmodell der Wawi das Problem ist?

Meine Vermutung wäre, dass Euch einfach die Zuordnungsparameter zu den Ursprungsaufträgen fehlen.

Das zieht sich ja durch den gesamten "JTL-Kosmos" und fängt damit an, dass die externe Auftragsnummer als Variable für Dotliquid und den Zusammenfassen- Workflow nicht belegt ist, geht dann darüber, dass in der GUI keine Möglichkeit mehr besteht, zu sehen, welche externen Aufträge da in einem Auftrag zusammengeführt worden sind.

Enden tut das Ganze damit, dass auch JTL2Datev von Jera es nicht schafft, 2 Gutschriften/Zahlungen auf einem zusammengefassten ebay-Auftrag automatisch aufzulösen, obwohl beide Gutschritnummern und beide Zahlungen mit den entsprechenden Beträgen im Auftrag hinterlegt sind.

Das Problem sind da vermutlich weniger die Plattformen/Marktplätze, als vielmehr der Umgang der Wawi mit den Aufträgen und Auftragspositionen aus den externen Aufträgen und deren Zuordnung(sparameter) im Nachgang. Alle benannten Probleme lassen sich natürlich durch Optimierung des Datenmodells und der Verarbeitung der Daten lösen oder eben einfach durch Vermeidung der Ursache, dass diese Probleme zu Tage treten.

Die Änderung der Daten in den hier erwähnten Tabellen führt dazu, dass Ihr den Mechanismus aushebelt und ggfs. in genau die Probleme rennt, die wir erstmal versucht haben zu verhindern. Ich möchte Euch darauf hinweisen, dass daraus entstandene Probleme evtl. nicht durch unseren Support abgedeckt sind bzw. behoben werden können.

Kernproblem ist vermutlich die GoBD-Konformität (die eben ein konsistentes Datenmodell voraussetzt, um eine entsprechende Nachvollziehbarkeit zu gewährleisten)!? Und als Basis dann vermutlich mögliche Inkonsistenzen in Datenmodell der Wawi.

Aus meiner Sicht müsste ja in einem konsistenten Datenmodell jede Auftrags-/Rechnungs-/Gutschrifts-Position auch im Nachgang noch Ihrem Ursprungsauftrag (sowohl externen Auftrag, als auch internen Auftrag) einwandfrei zugeordnet werden können. Damit müsste sowohl ein Zusammenfassen, als auch ein (Rück-)Splitten, als auch das Thema Sammelrechnung unproblematisch möglich sein und auch jederzeit dem Marktplatz mitgeteilt werden können, welche externen Aufträge in welchem Status sind.

Es mag da sicherlich auch gewisse Schwierigkeiten geben, z.B. wenn eine Sendungsnummer von einem Marktplatz nur für einen Marktplatz-Auftrag akzeptiert wird und nicht bei mehreren Marktplatz-Aufträgen hinterlegt werden kann, aber dann müsste man diese Entscheidungsgrundlage ja auch einfach und nachprüfbar kommunizieren können.

Mir vermittelt sich der Eindruck, dass hier nicht nach bisheriger Funktionalität und sinnvoller Nutzbarkeit für die Anwender entschieden wird, sondern Kennzahlen-Optimierung betrieben wird (möglichst einfache Entwicklung möglichst wenig Support-Aufwand).

Auf jeden Fall ist das wieder ein Prozess mehr, der in der 1.10 beschnitten wird und ein Grund mehr, nicht auf die 1.10 zu wechseln.

 

[mvh]

Kann es sein, dass einfach grundlegend das Datenmodell der Wawi das Problem ist?

Meine Vermutung wäre, dass Euch einfach die Zuordnungsparameter zu den Ursprungsaufträgen fehlen.

Das zieht sich ja durch den gesamten "JTL-Kosmos" und fängt damit an, dass die externe Auftragsnummer als Variable für Dotliquid und den Zusammenfassen- Workflow nicht belegt ist, geht dann darüber, dass in der GUI keine Möglichkeit mehr besteht, zu sehen, welche externen Aufträge da in einem Auftrag zusammengeführt worden sind.

Enden tut das Ganze damit, dass auch JTL2Datev von Jera es nicht schafft, 2 Gutschriften/Zahlungen auf einem zusammengefassten ebay-Auftrag automatisch aufzulösen, obwohl beide Gutschritnummern und beide Zahlungen mit den entsprechenden Beträgen im Auftrag hinterlegt sind.

Das Problem sind da vermutlich weniger die Plattformen/Marktplätze, als vielmehr der Umgang der Wawi mit den Aufträgen und Auftragspositionen aus den externen Aufträgen und deren Zuordnung(sparameter) im Nachgang. Alle benannten Probleme lassen sich natürlich durch Optimierung des Datenmodells und der Verarbeitung der Daten lösen oder eben einfach durch Vermeidung der Ursache, dass diese Probleme zu Tage treten.



Kernproblem ist vermutlich die GoBD-Konformität (die eben ein konsistentes Datenmodell voraussetzt, um eine entsprechende Nachvollziehbarkeit zu gewährleisten)!? Und als Basis dann vermutlich mögliche Inkonsistenzen in Datenmodell der Wawi.

Aus meiner Sicht müsste ja in einem konsistenten Datenmodell jede Auftrags-/Rechnungs-/Gutschrifts-Position auch im Nachgang noch Ihrem Ursprungsauftrag (sowohl externen Auftrag, als auch internen Auftrag) einwandfrei zugeordnet werden können. Damit müsste sowohl ein Zusammenfassen, als auch ein (Rück-)Splitten, als auch das Thema Sammelrechnung unproblematisch möglich sein und auch jederzeit dem Marktplatz mitgeteilt werden können, welche externen Aufträge in welchem Status sind.

Es mag da sicherlich auch gewisse Schwierigkeiten geben, z.B. wenn eine Sendungsnummer von einem Marktplatz nur für einen Marktplatz-Auftrag akzeptiert wird und nicht bei mehreren Marktplatz-Aufträgen hinterlegt werden kann, aber dann müsste man diese Entscheidungsgrundlage ja auch einfach und nachprüfbar kommunizieren können.

Mir vermittelt sich der Eindruck, dass hier nicht nach bisheriger Funktionalität und sinnvoller Nutzbarkeit für die Anwender entschieden wird, sondern Kennzahlen-Optimierung betrieben wird (möglichst einfache Entwicklung möglichst wenig Support-Aufwand).

Auf jeden Fall ist das wieder ein Prozess mehr, der in der 1.10 beschnitten wird und ein Grund mehr, nicht auf die 1.10 zu wechseln.

Moin. Die Antwort ist definitiv - Nein. Es gibt Tabellen, Abfragen und SPs, die das Gegenteil aufweisen. Auch dein "Bug" ist über eine Abfrage zu lösen. In einem Punkt stimme ich Dir zu - die 1.10 ist eine "zwischen Version" für die "Bastler", die breite Masse soll lieber etwas abwarten.

 

[Verkäuferlein]

Moin. Die Antwort ist definitiv - Nein. Es gibt Tabellen, Abfragen und SPs, die das Gegenteil aufweisen. Auch dein "Bug" ist über eine Abfrage zu lösen. In einem Punkt stimme ich Dir zu - die 1.10 ist eine "zwischen Version" für die "Bastler", die breite Masse soll lieber etwas abwarten.

Grundsätzlich lasse ich mich da ja gerne eines Besseren belehren und ich würde es auch gutheißen, wenn es so wäre. Aber dann lass es uns gerne konkret machen.

Ich habe es mir jetzt nur in der 1.9.7.x in der Datenbank angesehen und auch nicht alle Tabellen durchsucht. Es gibt dort für jede Auftrags-Position eine individuelle ID, es gibt auch interne Auftrags-IDs und einen Merge- Log für die Auftrags-IDs. Allerdings sind die Auftragspositionen nach dem Zusammenfassen dann der neuen Auftrags-ID zugewiesen. Den Weg, diese Auftragspositionen wieder Ihrem ursprünglichen (internen wie externen) Auftrag zuzuordnen, habe ich jedoch nicht gefunden.

Progressiv scheint das also alles weitestgehend in der Datenbank dokumentiert zu sein und es lässt sich somit auch einiges auf Datenbankebene (z.B. durch Ergänzung zusätzlicher Tabellen/Abfragen) umsetzen. Für den retrograden Weg habe ich allerdings nicht die richtigen Ansatzpunkte gefunden (das mag an mir liegen). Diesen Weg benötigen wir ja aber, wenn wir zusammengefasste Aufträge wieder auflösen wollen (sei es für einen Marktplatz, zur retrograden Prüfung oder zum wieder Aufsplitten des Auftrages).

Wenn es beide Wege gibt und die Sperre des Zusammenfassens nicht der Datenkonsistenz dient, stelle ich mir aber umsomehr die Frage:
Warum greift man so in eingespielte Prozesse ein?
und
Woher weiß der Marktplatz, dass der Auftrag in der Wawi geändert wurde und mehr/weniger/andere Positionen hat?

 

[mvh]

Grundsätzlich lasse ich mich da ja gerne eines Besseren belehren und ich würde es auch gutheißen, wenn es so wäre. Aber dann lass es uns gerne konkret machen.

Ich habe es mir jetzt nur in der 1.9.7.x in der Datenbank angesehen und auch nicht alle Tabellen durchsucht. Es gibt dort für jede Auftrags-Position eine individuelle ID, es gibt auch interne Auftrags-IDs und einen Merge- Log für die Auftrags-IDs. Allerdings sind die Auftragspositionen nach dem Zusammenfassen dann der neuen Auftrags-ID zugewiesen. Den Weg, diese Auftragspositionen wieder Ihrem ursprünglichen (internen wie externen) Auftrag zuzuordnen, habe ich jedoch nicht gefunden.

Progressiv scheint das also alles weitestgehend in der Datenbank dokumentiert zu sein und es lässt sich somit auch einiges auf Datenbankebene (z.B. durch Ergänzung zusätzlicher Tabellen/Abfragen) umsetzen. Für den retrograden Weg habe ich allerdings nicht die richtigen Ansatzpunkte gefunden (das mag an mir liegen). Diesen Weg benötigen wir ja aber, wenn wir zusammengefasste Aufträge wieder auflösen wollen (sei es für einen Marktplatz, zur retrograden Prüfung oder zum wieder Aufsplitten des Auftrages).

Wenn es beide Wege gibt und die Sperre des Zusammenfassens nicht der Datenkonsistenz dient, stelle ich mir aber umsomehr die Frage:
Warum greift man so in eingespielte Prozesse ein?
und
Woher weiß der Marktplatz, dass der Auftrag in der Wawi geändert wurde und mehr/weniger/andere Positionen hat?

Moin.
OK, lass uns gemeinsam die Tabellen ansehen, nur 1-2 Beispiele.
Die Tabelle Verkauf.tAuftragPosition beinhaltet kAmazonBestellungPos, ist ein FKey von pf_amazon_bestellungpos
und kEbayTransaction, ist ein FKey von ebay_transaction.
Die Auftragspositionen beziehen sich also immer auf die richtigen Markplatzvorgänge, auch bei den zusammengefügten
Aufträgen, denn kAuftrag/kBestellung ist eine interne Nummer, die E-Bay/Amazon/etc. nicht wissen müssen.
So kommst die WaWi sehr schnell zu pf_amazon_bestellung mit der richtigen cOrderId und zu ebay_checkout mit der richtigen cOrderId.
Der Markplatz muss also NICHT wissen, was der Benutzer zusammenfügt und die WaWi hat den richtigen Bezug über die Auftragspositionen.
Zusätzlich gibt es auch "gegen" Verknüpfungen, z.B. in ebay_transaction das FKey kBestellung.

Die WaWi "dokumentiert" die Vorgänge ziemlich rudimentär: nur in den Tabellen Verkauf.tAuftragMerge_Log und Kunde.tHistorie.
Warum - weiß ich nicht, ist aber unwichtig, denn der Code in der SP spAuftraegeZusammenfassen und TV Verkauf.ifZusammenfassbareAuftraege ist offen.
und wir haben den Code früher vor 1.8 für uns entsprechend angepasst.

Wenn Du eine fertige Abfrage für cOrderId haben willst - schreib mich privat an, können wir die Anforderungen dafür klären.
Viele Grüße, ihr MVH-Team.

 

[Verkäuferlein]

Moin,

OK, lass uns gemeinsam die Tabellen ansehen, nur 1-2 Beispiele.
Die Tabelle Verkauf.tAuftragPosition beinhaltet kAmazonBestellungPos, ist ein FKey von pf_amazon_bestellungpos
und kEbayTransaction, ist ein FKey von ebay_transaction.
Die Auftragspositionen beziehen sich also immer auf die richtigen Markplatzvorgänge, auch bei den zusammengefügten
Aufträgen, denn kAuftrag/kBestellung ist eine interne Nummer, die E-Bay/Amazon/etc. nicht wissen müssen.
So kommst die WaWi sehr schnell zu pf_amazon_bestellung mit der richtigen cOrderId und zu ebay_checkout mit der richtigen cOrderId.
Der Markplatz muss also NICHT wissen, was der Benutzer zusammenfügt und die WaWi hat den richtigen Bezug über die Auftragspositionen.
Zusätzlich gibt es auch "gegen" Verknüpfungen, z.B. in ebay_transaction das FKey kBestellung.

Da bin ich komplett bei Dir, das habe ich auch nicht in Frage gestellt, war ja aber die Begründung, weshalb das Zusammenfassen seitens JTL eingeschränkt wurde.

Die WaWi "dokumentiert" die Vorgänge ziemlich rudimentär: nur in den Tabellen Verkauf.tAuftragMerge_Log und Kunde.tHistorie.
Warum - weiß ich nicht, ist aber unwichtig, denn der Code in der SP spAuftraegeZusammenfassen und TV Verkauf.ifZusammenfassbareAuftraege ist offen.

Und da liegt mein Problem.

In Verkauf.tAuftraege habe ich in kAuftrag und cAuftragsNr Lücken nach dem Zusammenfassen, die sich meiner Ansicht nach nur über Verkauf.tAuftragMerge_Log halbwegs nachvollziehen/erklären, aber eben nicht vollständig rekonstruieren lassen.

Das Problem lässt sich umgehen, indem man Zusammenfassen unterbindet und damit immer eine 1zu1-Zuordnung von kAuftrag, cAuftragsNr und cExterneAuftragsnummer hat.

Siehst Du da irgendeine Möglichkeit, nachträglich von cExterneAuftragsnummer (respektive cOrderId aus dbo.ebay_checkout) eine Verbindung zu ehemals kAuftrag (=kAuftrag_Alt in Verkauf.tAuftragMerge_Log) und darüber zu der ehemligen cAuftragsNr herzustellen?

Ich aktuell nicht.

Wenn Du eine fertige Abfrage für cOrderId haben willst - schreib mich privat an, können wir die Anforderungen dafür klären.

Da komme ich bei Bedarf gerne drauf zurück, danke.

Gruß
Verkäuferlein

 

[wawi-dl]

...
Siehst Du da irgendeine Möglichkeit, nachträglich von cExterneAuftragsnummer (respektive cOrderId aus dbo.ebay_checkout) eine Verbindung zu ehemals kAuftrag (=kAuftrag_Alt in Verkauf.tAuftragMerge_Log) und darüber zu der ehemligen cAuftragsNr herzustellen?
...

Wir fassen ebenfalls sehr viel zusammen, was uns eigentlich egal sein sollte, oftmals gibt es ohnehin nur ärger mit den Kunden dann

Würde mich daher interessieren, wofür ihr den Bezug zwingend braucht?
Kann mir nur vorstellen für die Buchhaltung, der Rest wäre "mir" völlig egal, Auftrag versendet, bezahlt, erldigt.

Man könnte über Workflow das Zusammenfassen überwachen und die Werte in ein eigenes Feld schreiben, überlege daher ob ich das für uns umsetze, wüsste aber nicht warum.

 

[Verkäuferlein]

Würde mich daher interessieren, wofür ihr den Bezug zwingend braucht?
Kann mir nur vorstellen für die Buchhaltung, der Rest wäre "mir" völlig egal, Auftrag versendet, bezahlt, erldigt.

Man könnte über Workflow das Zusammenfassen überwachen und die Werte in ein eigenes Feld schreiben, überlege daher ob ich das für uns umsetze, wüsste aber nicht warum.

Das war mehr eine kritische Analyse, als der akute Bedarf. Wir schreiben beim Zusammenfassen beide alten Auftragsnummern (und wenn die Variable belegt wäre auch beide externen Auftragsnummern) ins Kommentarfeld. Das hilft zum einen für die Nachvollziehbarkeit in der Buchhaltung, zum anderen aber auch, wenn man mal den externen Auftrag direkt identifizieren will. Auf Positionsebene wäre dies aber natürlich noch besser.

Aus meiner Sicht, würde das ganz einfach ganz viele neue Möglichkeiten bieten. Zum einen könnte ich mir Vorstellen, dass in Unternehmen, wo ein Wirtschaftsprüfer testiert (oder auch bei eine Steuerprüfung) durchaus mal die Frage aufkommt, wo die Lücken in den Auftragsnummern herstammen, zum anderen könnte ich mir auch vorstellen, dass das für eine GoBD-Zertifizierung einer Software hilfreich sein könnte.

Parallel dazu würde ich persönlich das auch technisch für sinnvoll erachten, die Aufträge eher "virtuell" zusammenzufassen oder die vorherigen Aufträge zur Dokumentation in einer anderen Tabelle zu speichern, als z.B. einen Auftrag komplett verschwinden zu lassen und den anderen weiter zu nutzen. Das würde dann wie gesagt aus meiner Sicht sowohl für ein Rücksplitten der Aufträge, als auch für so Themen wie Sammelrechnung vermutlich von Vorteil sein und eine saubere Dokumentation ermöglichen.

Wir erleben das ja auch in der Praxis, dass Kunden dann 2x mit unterschiedlichen Farben bestellen, dann nur eine haben wollen und wir dann 1x im zusammengefassten Auftrag nullen. Komplizierter wird es, wenn der Kunde dann (versehentlich) 2x exakt das gleiche bestellt, das dann zusammengefasst ist und man nicht mehr weiß, welche Position man nullen soll, damit auch z.B. der abgebrochene Kauf bei ebay der korrekten Position zugeordnet ist.

Wenn ich das richtig gesehen habe, wird ja beim Zusammenfassen von Shop-Aufträgen auch rückgreifend im Shop der eine Auftrag gelöscht und der andere umgeschrieben. Und das ist wahrscheinlich das, was von Seiten JTL auch als problematisch betrachtet wird.

Der 1zu1-Bezug ist natürlich immer am einfachsten zu programmieren, zu warten und eben dann auch nachzuvollziehen, bringt halt aber viele Einschränkungen für den Anwender mit sich.

 

[mvh]

Moin,



Da bin ich komplett bei Dir, das habe ich auch nicht in Frage gestellt, war ja aber die Begründung, weshalb das Zusammenfassen seitens JTL eingeschränkt wurde.



Und da liegt mein Problem.

In Verkauf.tAuftraege habe ich in kAuftrag und cAuftragsNr Lücken nach dem Zusammenfassen, die sich meiner Ansicht nach nur über Verkauf.tAuftragMerge_Log halbwegs nachvollziehen/erklären, aber eben nicht vollständig rekonstruieren lassen.

Das Problem lässt sich umgehen, indem man Zusammenfassen unterbindet und damit immer eine 1zu1-Zuordnung von kAuftrag, cAuftragsNr und cExterneAuftragsnummer hat.

Siehst Du da irgendeine Möglichkeit, nachträglich von cExterneAuftragsnummer (respektive cOrderId aus dbo.ebay_checkout) eine Verbindung zu ehemals kAuftrag (=kAuftrag_Alt in Verkauf.tAuftragMerge_Log) und darüber zu der ehemligen cAuftragsNr herzustellen?

Ich aktuell nicht.



Da komme ich bei Bedarf gerne drauf zurück, danke.

Gruß
Verkäuferlein

Moin. Konnte früher nicht schreiben, hatte wenig Zeit. Anbei die Abfrage zum Ausprobieren.

SELECT TOP (1000) tal.*, ta.cAuftragsNr, th.cValue1 AS cAuftragNeu, th.cValue2 AS cAuftragAlt, ta.kPlattform, ISNULL(alt.cOrderId,'') as OrderIdAlt
  FROM eazybusiness.Verkauf.tAuftragMerge_Log tal
  INNER JOIN eazybusiness.Verkauf.tAuftrag ta ON ta.kAuftrag=tal.kAuftrag
  LEFT JOIN eazybusiness.Kunde.tHistorie th ON th.kAuftrag=ta.kAuftrag AND th.kVorgang=42
  LEFT JOIN (
  SELECT kBestellung, et.TransactionID, ct.cOrderId
  FROM eazybusiness.dbo.ebay_transaction et
  INNER JOIN eazybusiness.dbo.ebay_checkoutpos cp ON et.TransactionID=cp.TransactionID
  INNER JOIN eazybusiness.dbo.ebay_checkout ct ON cp.kEbayCheckout=ct.kEbayCheckout
  ) alt ON alt.kBestellung=kAuftragAlt
  ORDER BY dMerge desc

 

[wawi-dl]

... Zum einen könnte ich mir Vorstellen, dass in Unternehmen, wo ein Wirtschaftsprüfer testiert (oder auch bei eine Steuerprüfung) durchaus mal die Frage aufkommt, wo die Lücken in den Auftragsnummern herstammen, zum anderen könnte ich mir auch vorstellen, dass das für eine GoBD-Zertifizierung einer Software hilfreich sein könnte....

Man kann das sicherlich hinterfragen, aber es gibt keine gesetzlichen Vorgaben für fortlaufende Auftragsnummern, nur Rechnungsnummern.
Den Prüfer interessiert am Ende nur, ob das Geld in der Kasse ist, das auch geflossen ist.

Wenn du also keinen Zweck dazu hast, so what ... ansonsten CustomWorkflow bauen, in eine Tabelle/Feld schreibt, ruhig schlafen und fertig

 

[mvh]

Moin. Alle Daten sind da und auch die Zuordnungen. Was fehlt - ist ein Entwicklerhandbuch. Viele Grüße, Ihr MVH-Team.

 

[wawi-dl]

Moin. Konnte früher nicht schreiben, hatte wenig Zeit. Anbei die Abfrage zum Ausprobieren.

SELECT TOP (1000) tal.*, ta.cAuftragsNr, th.cValue1 AS cAuftragNeu, th.cValue2 AS cAuftragAlt, ta.kPlattform, ISNULL(alt.cOrderId,'') as OrderIdAlt
  FROM eazybusiness.Verkauf.tAuftragMerge_Log tal
  INNER JOIN eazybusiness.Verkauf.tAuftrag ta ON ta.kAuftrag=tal.kAuftrag
  LEFT JOIN eazybusiness.Kunde.tHistorie th ON th.kAuftrag=ta.kAuftrag AND th.kVorgang=42
  LEFT JOIN (
  SELECT kBestellung, et.TransactionID, ct.cOrderId
  FROM eazybusiness.dbo.ebay_transaction et
  INNER JOIN eazybusiness.dbo.ebay_checkoutpos cp ON et.TransactionID=cp.TransactionID
  INNER JOIN eazybusiness.dbo.ebay_checkout ct ON cp.kEbayCheckout=ct.kEbayCheckout
  ) alt ON alt.kBestellung=kAuftragAlt
  ORDER BY dMerge desc

Danke für die Abfrage, habe da die externe Nummer mal noch ergänzt und Dubletten entfernt.
Alles steht nicht drin, hängt also von der JTL Version ab, vermute ab 1.9.

SELECT        DISTINCT
            tal.*,
            ta.kPlattform,
            th.cValue1 AS cAuftragNEU,
            th.cValue2 AS cAuftragALT,
            ta.cExterneAuftragsnummer AS cAuftragNEU,
            ISNULL(alt.cOrderId,'') AS cOrderIdALT
FROM        eazybusiness.Verkauf.tAuftragMerge_Log tal
INNER JOIN    eazybusiness.Verkauf.tAuftrag ta ON ta.kAuftrag=tal.kAuftrag
LEFT JOIN    eazybusiness.Kunde.tHistorie th ON th.kAuftrag=ta.kAuftrag AND th.kVorgang=42
LEFT JOIN    (
            SELECT        kBestellung,
                        et.TransactionID,
                        ct.cOrderId
            FROM        eazybusiness.dbo.ebay_transaction et
            INNER JOIN    eazybusiness.dbo.ebay_checkoutpos cp ON et.TransactionID=cp.TransactionID
            INNER JOIN    eazybusiness.dbo.ebay_checkout ct ON cp.kEbayCheckout=ct.kEbayCheckout
            ) alt ON alt.kBestellung=kAuftragAlt
ORDER BY dMerge DESC

 

[mvh]

Moin. Nicht vergessen, das Thema bezieht sich auf 1.10.X, Verkäuferlein nutzt 1.9.X So war die Aufgabenstellung. Aber auch mit 1.8 würde es funktionieren.

 

[Angelfachmarkt]

Wir haben nun gestern von 1.9.7 auf 1.10.12 geupdatet nun können wir keine amazon Bestellungen mehr zusammenfügen es kommt die Meldung: Zusammenfassen deaktiviert.
Vorher war dieses möglich. Wir fügen jeden Tag Amazon Aufträge und auch ebay Aufträge zusammen wenn jemand doppelt bestellt hat.
Ich habe auch die SQL Haken wie vorher Beschrieben in der Datenbank gesetzt was aber keinen Erfolg gebracht hat.
Hat jemand eine Lösung dafür?
Grüße

 

[wawi-dl]

gelesen?
https://forum.jtl-software.de/threa...menfassen-ist-deaktiviert.232504/post-1282031