Skip to main content

Dateiname exportieren

Timo Skottki

Hallo zusammen,

wir haben derzeit ein Problem, vielleicht hat ja jemand ein paar Gedanken oder im besten Fall sogar eine Lösung dafür. 
Wir bauen über ein SELECT Statement einen Dateinamen zusammen, damit dieser von einem Folgesystem verarbeitet werden kann (SELECT CONCAT(CONCAT(CONCAT("ObjType", '_'),CAST("DocEntry" AS VARCHAR)),'_P_Beleg') FROM "O@@RDR" WHERE "DocEntry" = [%DocEntry])

Es handelt sich um ein Bestellanforderung, dürfte aber für dieses Problem keine Relevanz haben.
Die Datei wird auch sauber erzeugt und an die richtige Stelle im Dateisystem gelegt, solange es sich um einen normal hinzugefügten Beleg handelt. Das Ganze funktioniert NICHT bei geparkten Belegen. Es wird zwar eine Datei erzeugt, diese hat aber eine ganze andere Bezeichnung (vermutlich der Systemstandard, denn wenn wir die Query entfernen, heißt die Datei auch beim normalen Hinzufügen so). Die Frage ist, warum verhalten sich an der Stelle normale und geparkte Belege unterschiedlich? 

Gruß
Timo

0

Comments

3 comments

Date Votes
  • Lothar Hasenkämper

    Hallo Timo,

    einzelne Belege werden in ihren eigenen Tabellen gespeichert (AU→ORDR). Hier haben sie einen PrimaryKey die DocEntry.

    Geparkte Belege werden ALLE in der ODRF Tabelle gespeichert. Hier werden die Belegarten über den ObjType unterschieden. 

    Wenn Du eine Query darauf feuerst rate ich dir SELECT TOP 100 * FROM ODRF.
    Je nachdem wieviel Ihr in der Tabelle habt könnte es sonst unschöne Begleiterscheinungen geben ;-).

    Gruß Lothar

    0
  • Timo Skottki

    Hallo Lothar,
     

    danke für die Antwort, mir ist klar, dass die einzelnen Belege in verschiedenen Tabellen stehen. Allerdings ersetzt CoreSuite nach meinen Informationen das durch das @@. Die Art des Belegs wird ja über den Form Type oder Objekt Type (bin nicht sicher) entschieden. Sprich, auch wenn wir O@@RDR, was ja die Tabelle Kundeaufträge ist, nutzen, wird eine korrekte Datei der Bestellanforderung erzeugt. Aber eben nur, wenn man hinzufügt, nicht bei geparkten Belegen. Wir haben es in der Tat bereits mit der ODRF probiert (ohne @@), hat aber nicht funktioniert.

    Gruß Timo

    0
  • Lothar Hasenkämper

    Hi Timo,

    hier kommen einige Dinge zusammen. Ich versuche das mal schriftlich hinzubekommen.

    Aufgrund deiner Query, gehe ich davon aus das ihr HANA habt. Dieses Konstrukt mit dem mehrfachen CONCAT muss ggf. in HANA so sein in SQL würde 1 reichen.

    Der Standard-Dateiname wird nur verwendet wenn das Feld leer ist oder ein Fehler in der Query. Was mich aber wundert ist, dass es bei einem "richtigen" Beleg funktioniert. Es wundert mich aber auch das du die DocNum castest und die DocEntry nicht. Beides sollten im Ursprung INT sein.

    Damit das ganze mit dem O@@RDR überhaupt funktioniert muss das ganze in den Formtypes von CS hinterlegt sein.

    Bei einem Draft hat das Fenster aber den FormType des Belegs zu dem er gehört und auch der ObjectType verhält sich so. Wenn du einen geparkten Kundenauftrag aufmachst also 139/17.

    Man kann aus meiner Sicht also nicht die Drafts in den Formtypes hinterlegen um O@@RDR zu nutzen. Du kommst über deine Abfrage also nicht in die ODRF.

    Jetzt hast du aber eine Query aufgebaut um über den Parameter [%DocEntry] die Daten ObjType und DocEntry im Namen zu verwenden. Es gibt aber auch den Parameter '[%ObjectId]', den kannst du verwenden um deinen Name zu "stricken" dann musst du nicht in eine Tabelle. In SQL würde/könnte es so aussehen. 

    SELECT '[%ObjectId]' + '/' + '[%DocEntry]' + '/' + '[%DocNum]'

    Wie das in HANA ist weiß ich nicht.

    Kommen wir aber zu den Kernen des Probleme.

    Die DocEntry/DocNum die du über die Parameter bekommst ist sind die Nummern des Draft's. Sie haben GAR NIX mit den Werten zu tun die der Beleg hat wenn er hinzugefügt wurde, weil diese dann aktuell vergeben werden. Es ist also niemals möglich eine Beziehung herzustellen zwischen dem Draft und dem hinzugefügten Beleg und somit hat der Draft, aus meiner Sicht, auch nichts in deinem Archiv verloren zwischen den Belegen die tatsächlich im System sind´. Denn nach deinem Dateinamen-Aufbau kann man echte Belege nicht von Draft's unterscheiden. Hinzu kommt, das Draft's gelöscht werden können also ggf. auch nicht mehr in der ODRF vorhanden sind. 

    Wenn du den Parameter ObjectId verwendest, bekommst du in der CS-Welt die ID von dem Beleg wo du auf den Knopf gedrückt hast. Die ObjectId für den Draft ist aber 112. Verrückter Weise ist aber im Layout die ObjectId ( GetData("LD.Par.ObjectId") ) die 112, das passt CS irgendwie an. Ich habe mal geschaut ob es irgendwie einen anderen Parameter dafür gibt, der anzeigt, das es sich um einen Draft handelt. Habe aber nichts gefunden.

    Um jetzt festzustellen ob es sich um einen Draft handelt könntest du nun in der Kombination mit den Parametern oben ('[%ObjectId]'  '[%DocEntry]'  '[%DocNum]') in einer Query prüfen ob es diese Kombination in der ODRF existiert. Wie du das dann in deinem Archiv nutzt bzw. wie dann der Dateiname sein soll musst du dann entscheiden.

    Ich hoffe ich hab es verständlich erläutert.

    Grüße Lothar


     

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post