Auftrag: Eigene Felder in DotLiquid Vorlage verwenden [Wawi 1.9.4.5] [SQL]

[Powalowski]

WAWI 1.9: Anders als im Workflow, kann man in der Auftragsvorlage nicht direkt auf die Eigenen Felder zugreifen.
Eine kleine SQL Abfrage wird benötigt:

{% comment  -%}Eigenes Feld Holen{% endcomment -%}
{% assign Feldname = "Auftragsart" -%}
{% capture query -%}\
SELECT TOP(1) [cValue] FROM [eazybusiness].[DbeS].[vAuftragUpdateAttribute]
WHERE [kAuftrag] = '{{ Report.InternalId }}' AND [cKey] = '{{ Feldname }}';
{% endcapture -%}
{% assign Auftragsart = query | DirectQueryScalar -%}
\
Ergebnis:
{{Auftragsart}}

Ich hoffe ich kann euch damit helfen. Es wäre cool, wenn es irgendwo eine Sammlung solcher Codeschnippsel geben könnte. Oder bin ich mal wieder nicht tief genug in der Community drin?

 

[ergowebshop]

Oh da bist du nicht der Einzige, da sitzen wir alle im selben Boot, wo Datenbankabfragen benötigt werden um verschiedene Unzulänglichkeiten zu umgehen.

Ich wäre auch nicht auf die Idee gekommen die Eigenen Felder ausgerechnet in DbeS.vAuftragUpdateAttribute zu suchen, na gut mit einer Volltextsuche vielleicht.

Jedenfalls hat uns das gerade mega geholfen um in der Auftragsvorlage bei Speichern bearbeiten, Template für Dateinamen diesen aus einem Eigenen Feld zu ziehen, da sind ja sonst nur englische Variablen und keine Eigenen Felder. Besten Dank.

 

[Powalowski]

Nachtrag: es gibt noch eine weitere View dbo.tBestellungAttribute.kBestellung In der oben genannten Tabelle View sind nicht immer alle Eigenen Felder drin. tBestelllungAttribute ist besser - ich habe aus dem Code der View aber nicht auf den ersten Blick verstanden, wo da der Unterschied ist. Sollte mal ein Eigenes Feld leer sein, diese Tabelle View konsultieren

Bei eigenen Feldern, die ein Datumsfeld sind, war widerrum nur vAuftragUpdateAttribute befüllt. Da ich keine Zeit hatte das genauer zu verstehen, hab ich es von Fall zu Fall mit Stichproben geprüft.

 

[kelvin.]

Du verwechselst Tables mit Views. Tables sind Tabellen, in denen Daten gespeichert werden.
Ein View ist eine Select Abfrage, die in der Datenbank gespeichert ist.
vAuftragUpdateAttribute ist ein View.
tBestellungAttribute ist ein Table.

Für Wawi 1.9 würde ich tBestellungAttribute nicht benutzen. Das ist ein Überbleibsel aus 1.5.
Um die Werte der eigenen Felder zu bekommen müssen mehrere Tabellen verbunden werden.
Es gibt Tabellen mit den Namen Attribut und AttributSprache oder so ähnlich.
In AttributSprache gibt es eine Spalte für Text, ganze Zahlen, dezimal Zahlen und Datumswerte.

Eine komplette Sammlung an Codeschnippsel gibt es nicht. Im Forum müsste die Abfrage für eigene Felder zu finden sein.

 

[ergowebshop]

Im Forum müsste die Abfrage für eigene Felder zu finden sein.

Ja gut wenn man erstmal weiß, dass es in AttributSprache steht, ja dann findet man es über die Suche, z.B.:
https://forum.jtl-software.de/threa...-datumsfelder-checkboxen.187918/#post-1004338

Aber wenn ich z.B. in einer Workflow Aktion den ersten Ansprechpartner inkl. Vorname und Anrede haben will, da sucht man sich dumm und dämlich.

 

[Powalowski]

Du verwechselst Tables mit Views. Tables sind Tabellen, in denen Daten gespeichert werden.
Ein View ist eine Select Abfrage, die in der Datenbank gespeichert ist.
vAuftragUpdateAttribute ist ein View.
tBestellungAttribute ist ein Table.

Hab's nur im Text verwechselt (und jetzt korrigiert, danke) - beides sind Views:



@kelvin. deine Benennungsvermutung wäre intuitiv richtig, nur nicht in der JTL-Welt 😂 Ich denke, die haben tBestellungAttribute als View für Kompatibilität "erhalten".

@ergowebshop, @kelvin. Das scheint der richtige Weg hängt irgendwie mit den Sprachen zusammen - sieht man auch im SELECT der View. Je nachdem ob man ein eigenes Feld per Oberfläche oder per Workflow befüllt, füllen sich diese Views jedoch unterschiedlich! Ich denke der Join aus dem Verlinkten Thread könnte am besten sein. Bei uns hatten mir je nachdem immer Werte einer der beiden Views gefehlt. @ergowebshop - ein finales Schnippselchen würd der Nachwelt (und uns ) helfen👍🏻

 

[mh1]

... deine Benennungsvermutung wäre intuitiv richtig, nur nicht in der JTL-Welt 😂 Ich denke, die haben tBestellungAttribute als View für Kompatibilität "erhalten".

Die Entwickler von JTL haben ursprünglich mal angefangen, alle Relationen und teilweise auch deren Attribute mit einem Prefix im Namen zu versehen.
Im Zuge von Updates, Erweiterungen des Datenbankschemas, Änderung der Datentypen u.s.w. ist dieses Prinzip der Namensgebung aber nicht mehr in allen Bereichen konsistent.
Auch aus Kompatibilitätsgründen werden in neueren Versionen z.b. Tabellen, die es in älteren Versionen noch gab als View abgebildet.
Und so hat man jetzt eben Views, die im Namen ein kleines T vorangestellt haben, obwohl sie ja keine Tabelle sind, sondern eben ein View.

Das mit den Prefixen hat man früher gerne so gemacht damit man "den jeweiligen Typ gleich erkennt".
Auch heute ist diese Praxis z.B. im Bereich der Vhs Kurse oder von Berufsschullehrern vermittelte 'Best Practice' (auch gerne im Bereich der C Programmierung )
Man zwängt sich dadurch aber in ein unangenehmes Korsett, das jede Änderung an der Struktur unnötig erschwert.

 

[ergowebshop]

ein finales Schnippselchen würd der Nachwelt (und uns ) helfen👍🏻

Oh wir haben es so gemacht wie im ersten Beitrag von dir, funktioniert für uns, das Verlinkte kannten wir ja erst später.
Also haben wir jetzt:
- hole den Wert aus dem eigenen Feld
- wenn da was drin steht, nimm das als Dateiname bei Auftrag speichern
- wenn nicht bastle es aus Auftragsnummer und Name, wenn es den nicht gibt dann alternativ Firma
- filtere " und / und : raus weil die in Dateinamen nicht zulässig sind, sonst kann er nicht Speichern und tut auch nicht Mailen (ja, gibt noch weitere unzulässige Zeichen)

{% capture query -%}\
SELECT TOP(1) [cValue] FROM [eazybusiness].[DbeS].[vAuftragUpdateAttribute] WHERE [kAuftrag] = '{{ Report.InternalId }}' AND [cKey] = 'AB_Dateiname';
{% endcapture -%}\
{% assign Dateiname = query | DirectQueryScalar -%}
\
\\server\Auftragsbestätigungen\
\{% if Dateiname != null %}{{Dateiname}}{% else %}\
{{ Report.SalesOrderNumber }} -{% if Report.Address.LastName != empty %} {{Report.Address.LastName | Replace: ':', '' | Replace: '/', ' ' | Replace: '\"', ''}}{% else %} {{ Report.Address.Company | Replace: ':', '' | Replace: '/', ' ' | Replace: '\"', '' }}{% endif %}\
{% endif %}\
.pdf

Den Anhang 112594 betrachten

Btw.: was nutzt du da für ein Datenbankprogramm?

 

[ergowebshop]

Ich denke der Join aus dem Verlinkten Thread könnte am besten sein. Bei uns hatten mir je nachdem immer Werte einer der beiden Views gefehlt. @ergowebshop - ein finales Schnippselchen würd der Nachwelt (und uns ) helfen👍🏻

Also zusammengefasste Schnipselchen für die Nachwelt.

Namen und Werte per Join:

SELECT cName,cWertVarchar
FROM Verkauf.tAuftragAttribut AS Attribut
JOIN Verkauf.tAuftragAttributSprache AS Sprache ON Sprache.kAuftragAttribut = Attribut.kAuftragAttribut
JOIN tAttributSprache AS AttributSprache ON AttributSprache.kAttribut = Attribut.kAttribut
WHERE Attribut.kAuftrag = '1234'

Oder mit View wie oben schon beschrieben:

SELECT cKey,cValue FROM [eazybusiness].[DbeS].[vAuftragUpdateAttribute] WHERE [kAuftrag] = '1234'

Wenn man aber die Namen der Felder nicht extra braucht sondern nur die Werte, aber ohne View, dann tut es auch ein Subselect:

select cWertVarchar from Verkauf.tAuftragAttributSprache where kAuftragAttribut in (SELECT kAuftragAttribut FROM Verkauf.tAuftragAttribut where kAuftrag='1234')

Das liefert jedoch in jedem Fall alle Eigenen Felder, oft will man an einer bestimmten Stelle im Workflow oder in einer Dokumentvorlage nur ein bestimmtes Feld auswerten/ausgeben.

Bestimmtes Feld per Feldname geht dann z.B. mit:

SELECT cKey,cValue FROM [eazybusiness].[DbeS].[vAuftragUpdateAttribute] WHERE [kAuftrag] = '1234' AND [cKey] = 'MeinFeld'

Aber das birgt die Gefahr: irgendwann benennt jemand bei euch das Feld um in Mein_Feld und dann geht die Vorlage bzw. der Workflow nicht mehr.

Geht auch vorzubeugen:
1. in einem Auftrag (in dem Fall des mit interner ID 1234) das Feld befüllen, denn sonst steht in der Datenbank nichts, auch kein Leerwert.
2. alle Werte im SMSS ausgeben mittels Subselect inkl. kAuftragAttribut:

select kAuftragAttribut,cWertVarchar from Verkauf.tAuftragAttributSprache where kAuftragAttribut in (SELECT kAuftragAttribut FROM Verkauf.tAuftragAttribut where kAuftrag='1234')

Das liefert z.B.:
567, mail@example.com,
890, Berlin
999, Meine Bemerkung
man merke sich die Zahl vor dem Wert den man gerade befüllt hat, das ist das gewünschte Feld, z.B. 567
3. wir wissen das Feld hat intern die ID 567, auch wenn es mal umbenannt wird, dann wäre unser SQL:

select cWertVarchar from Verkauf.tAuftragAttributSprache where kAuftragAttribut in (SELECT kAuftragAttribut FROM Verkauf.tAuftragAttribut where kAuftrag='1234' and kAttribut='567')

4. In Vorlage/Workflow ist dann nur noch die 1234 durch die interne Auftrags ID zu ersetzen, 567 bleibt so.