In Bearbeitung Variable für Zahlungsart

Happy

Sehr aktives Mitglied
29. Juli 2011
498
124
Potsdam
@wawi-dl
Eine Variablen Liste vor meiner Zeit betrifft also keine Variablen welche durch Ausgabe 2.0 entfernt wurden.
Es geht mir jedoch um genau solche Variablen.

Alles andere wäre kein Fehler, sondern ein Feature.
Die fehlende WEEE Nummer wird im übrigen noch kommen und kann aktuell hervorragend mit Hilfe von Eigenen Artikelfeldern behoben werden.
 

snPerranporth

Aktives Mitglied
6. März 2017
25
33
Hallo @Happy ,

erstmal vielen Dank, dass du dich diesem Thema annimmst. Ich bin zwar nicht @wawi-dl , aber absolut elementare Angaben für Unternehmen sind z.B. folgende

Kundendaten [weitgehend existent]
Kundennummer [siehe unten]
Bestellnummer [nicht existent > SQL nötig]
Bestelldatum [nicht existent > SQL nötig]
Vertriebskanal [mir nicht in Ausgabe 2.0 nicht geläufig > Report.ShopName ohne Inhalt und (...).Platform nicht mehr verfügbar!]
Auftragsnummer [nicht existent > SQL nötig]
Auftragsdatum [nicht existent > SQL nötig]
(ACHTUNG zu Auftrag vs. Bestellung: Das ist NICHT dasselbe! Eine Bestellung kann am 10.10. aufgegeben sein. Der Auftrag am 11.11. manuell oder auch per Workflow angelegt werden.)
Zahlart [Report.PaymentMethodName > funktioniert aber leider nicht]
Zahldatum [date$(Report.ValutaDate,'%x')]
Versandart [Report.ShippingMethod.Name]
Versanddatum [date$(Report.ServiceDate,'%x')]
Lieferscheinnummer [nicht existent > SQL nötig]
Lieferdatum [nicht existent > SQL nötig]

Die Liste ist jetzt nicht vollständig. Aber sie ist ein Anfang.

Diese Angaben sollten ohne SQL Abfrage nutzbar sein. Das ist auch deshalb so wichtig, weil ihr durch Änderungen ständig die Abfragen ungültig macht. Und das darf nicht sein. Auch im Softwarebereich hat man eine Produkthaftung. Also nicht falsch verstehen. Natürlich sind die SQL Abfragen hier von umtriebigen Nutzern, auch freundlicherweise (und größtenteils von euch JTL Mitarbeitern) erstellt. Danke dafür. Aber ihr seid schon in der Verantwortung euren Kunden mindestens die absoluten Basics anzubieten. Das sollte euer Anspruch sein. Findest du nicht? Und wenn wir da nicht einer Meinung sind, dann überleg mal was mehr Arbeit macht: Ständig selbe Anfragen im Forum beantworten zu müssen oder einmal alles an (selbsterklärenden) Variablen bereitstellen, was so oder so (und fast überall) gebraucht wird.

Deswegen ist mein Vorschlag weitgehender: macht alle Variablen für alle Dokumente verfügbar. Die o.a. Variablen sind durchaus in allen Dokumenten brauchbar. Überlasst den Kunden die Entscheidung, welche Variablen für sie wichtig sind. Das ist doch nicht zu viel verlangt oder? Ich hab das 2015/16 schon mal vorgeschlagen. Technisch nicht möglich, hieß es. Das ist doch aber ein schlechter Scherz. Es wäre nicht mal Performance-lastig, ein Dubletten Tabelle aller Variablen zu erstellen. Aus diesem Pool fischt man dann alle Daten. Noch besser wäre aber, ihr räumt auf und killt euren ohnehin vorhandenem Dubletten Pool. Variablen wie Auftragsnummer, Rechnungsnummer, Rechnungsdatum und so weiter sind schließlich immer gleich! Die braucht man nicht mehrmals im System führen. Ich sehe darin ein großes Problem. Nicht anders herum. Spart Speicherplatz. Aber vor allem spart es euch insbesondere Pflegeaufwand. Oder? Ja, das tut es!

Ein Beispiel noch zum Thema Dubletten:
Kundennummer > ein und dieselbe Angabe, wird 4 Mal allein im Umfeld Rechnung aufgeführt, mit
Report.Address.CustomerNumber
Report.Customer.Customer.Number
Report.InvoiceBillToAddress.CustomerNumber
Report.InvoiceShipToAddress.CustomerNumber


Warum tut ihr euch so schwer damit gute Kundenanregungen (möglichst schnell) umzusetzen? Das bedeutet Mehrwert für das System. Für euer Unternehmen. Ich persönlich begreife das nicht.

Aber vielleicht bist du ja derjenige, dem jetzt das Licht aufgeht. Die Notwendigkeit liegt auf der Hand: Die Wawi programmiert ihr nicht für euch. Sondern für den Kunden.

(Und Entschuldigung, wenn irgendwas hart klingt. Es schwingen halt Emotionen mit, weil man als Anwender einfach nicht das Einfache anwenden kann. Du verstehst?)
 
  • Gefällt mir
Reaktionen: fibergirl

snPerranporth

Aktives Mitglied
6. März 2017
25
33
Was ich noch vergessen habe: Den Mehrwert für alle, wenn alle Variablen überall nutzbar sind. Dann machen die L&L Bausteine auch erst Sinn. Weil sie dann auch so funktionieren, wofür sie gedacht sind.
Bislang braucht die Bausteine nämlich niemand, weil man auch einfach mit copy paste sehr viel schneller Ausgabe-übegreifende Geschäftspapiere erstellen kann. Das ist noch so etwas, was ich persönlich nicht verstehe.
 
  • Gefällt mir
Reaktionen: fibergirl

snPerranporth

Aktives Mitglied
6. März 2017
25
33
Danke @wawi-dl .

Das macht es aber doch nicht einfacher. Wieder mal bekomme ich einen dezenten Ausraster, wenn ich #8 lese.

Das ist Teil des gesamten Problemes. Alles viel zu kompliziert. Man braucht Auftragsnummer nicht nur in Ausgabe Auftrag. Ja, da ist diese vorhanden. Aber nicht in Rechnung und Co KG.

Wir brauchen doch nicht aufführen, welche Variable wo verfügbar sein muss. Alle wichtigen Variablen einfach überall gleichermaßen verfügbar machen.
Wir Kunden können so frei verfügen, in welcher Ausgabe wir auf welche Variablen zugreifen wollen und in welchen nicht. Aber das aller, aller, allerbeste ist der Vorteil bei JTL selbst.
Damit hilft sich JTL selbst bei der Verwaltung. Denn statt vieler gleicher Variablen in unterschiedlichen Ausgabewege zu pflegen, pflegt man fortan nur eine.
 
  • Gefällt mir
Reaktionen: fibergirl

wawi-dl

Sehr aktives Mitglied
29. April 2008
6.797
835
Hilft nicht, das neue Thema wurde darum extra erstellt, damit man JETZT endlich mal gebündelt alles sammeln kann.
Ich fordere seit Jahren fehlende Variablen!

Eine Umstellung auf Ausgabe 2.0 ist keine Pflicht, die alten Vorlagen laufen ohne Probleme stabil.

Daher nochmals den Wink, schreibt alles ins Thema rein, Happy / Dennis wird sich dann um die Variablen endlich kümmen!
 

Ähnliche Themen