Neu Workflow: Provisionsberechnung für Urheber - funktioniert nicht

[more-play]

Hallo.

Da wir eine Provisionsberechnung pro Artikel benötigen habe ich mir den Guide bezüglich Provisionsabrechnungen für Urheber angesehen und versucht fürs erst zu kopieren.

Das Erstellen der Eigenden Felder und die zuweisung funktioniert wie gewohnt einwandfrei.
Auch die einrichten des Workflow ging ohne Probleme.
Beim Test des Workflow´s jedoch wird zwar eine csv datei erstell, diese ist aber bis auf die Kopfzeile mit "Rechnungsnummer;Datum;Provision" leer.
Es wird kein Fehler im Log oder bei der Simulation des workflows angezeigt.


Die Vorlage für die Exportdatei ist wie im Guide:

{% for position in Vorgang.Auftrag.Positionen -%}
{% if position.Artikel.EigeneFelder.Urheberinformationen.Designer == "Garcia" -%}
{{Vorgang.Belegnummer | Trim | Quote }};{{Vorgang.Erstelldatum | Datum: 'yyyy-mm-dd' }};{{position.NettopreisEinzel | Times: position.Menge | Times: 0.03 | Nummer: 'N2','en-US'}}
{% endif -%}
{% endfor -%}

Die Eigenen Felder wurde natürlich dem Guide angepasst.

Verwendet wird Wawi Version 1.4.35.0
Der Server wurde neu gestartet.
Es wird alles als Admin ausgeführt.

Habt ihr eine Idee was da fehlen könnte?

Vielen Dank vorerst und liebe Grüße,
Andreas

 

[css-umsetzung]

Mit der 1.4 haben sich die Variablen zum Teil geändert. Ich gehe davon aus das dies dein Problem ist.

 

[mlpro]

Ich hatte heute genau das gleiche Problem, benötige einen Workflow für Provisionsabrechnung für den Auftrag, nicht für Artikel, wie im Beispiel Workflow: Provisionsberechnung für Urheber.

Das Beispiel Urheber habe ich auch komplett durchgespielt, keine Fehlermeldung, aber wo speichert er den Export hin!?
Kann mir dies jemand mitteilen?


Bzw. hat jemand den Workflow Provisionen des Außendienst als Auftrag Gesamtumsatz netto, nicht auf bestimmte Artikel wie Urheber.
Benutze im Moment die Version 1.5.5.0

Und wie geschrieben, wo speichert die Wawi als Export den Workflow hin?

Für eure Antwort bedanke ich mich im Voraus

mlpro

 

[humorpharm]

Mit der 1.4 haben sich die Variablen zum Teil geändert. Ich gehe davon aus das dies dein Problem ist.

Ich habe das Problem, dass bei JTL scheinbar immer wieder irgendwelche Variablen geändert werden. Allerdings finde ich nirgendwo eine Dokumentation hierzu. Und die Informationen im Guide veralten dann sukzessive.

 

[css-umsetzung]

Man kann sich hier die Änderungen der einzelnen Versionen anschauen.
Aber das betrifft die Datenbank und sagt nur begrenzt etwas über die Variablen in Workflows oder Formularen aus.

Daher ist es immer besser ein Problem direkt anzusprechen und zu sagen was nicht geht oder welche Variablen nicht das liefern was man erwartet.. Wir Servicepartner haben ja ständig mit diesen Änderungen zu kämpfen und da es unser Tagesgeschäft ist können wir daher im Forum recht schnell unterstützend helfen. (Natürlich auch nur bedingt kostenlos weil wir mit diesem erweitertem Wissen auch versuchen müssen Geld zu verdienen)

 

[humorpharm]

Grundsätzlich schließt das eine das andere ja nicht aus. Mein Problem ist, dass wir aus unseren Aufträgen eine Autoren- bzw. Urheberprovision ziehen müssen. Theoretisch soll das ja funktionieren. Aber die entscheidenden Variablen wurden geändert oder sind vielleicht auch weggefallen.

Letztlich soll zum ersten bei jedem Auftrag geprüft werden, ob ein oder mehrere provisionsrelevante Artikel verkauft wurden (vollständig bezahlt und ohne Retoure). In diesem Fall muss für den betreffenden Urheber in einer CSV vermerkt werden, der Wert der Bestellung und ob irgendwelche Rabatte gewährt wurden. Optimaler Weise funktioniert die Routine so, dass nicht für jeden Urheber eine neue Routine gestartet werden muss.

Haben in der Export-Vorlage folgendes eingetragen:

Dateinamen:

W:\Sicherung\JTL\Provisionen\{{ Report.CreationDate | Datum:'yyyy' }}\{{ Report.CreationDate | Datum: 'MM' }}\Provisionsreport {{ Report.CreationDate | Datum: 'MM' }}-{{ Report.CreationDate | Datum:'yyyy' }}.csv

{% assign Trennzeichen = ';' %}{% comment %}Gibt das Trennzeichen an{% endcomment -%}
{% for position in Report.InvoicePosition -%}
{{ Artikel.position.EigeneFelder.Urheberinformationen.Urheber | Trim | Quote }}{{Trennzeichen}}\
{{ Report.InvoiceNumber | Trim | Quote }}{{Trennzeichen}}\
{{ Report.CreationDate | Datum:'dd.mm.yyyy' }}{{Trennzeichen}}\
{{ Report.InvoiceShipToAddress.CustomerNumber | Trim | Quote }}{{Trennzeichen}}\
{{ Report.InvoiceShipToAddress.PostalCode | Trim | Quote }}{{Trennzeichen}}\
{{ Report.InvoiceShipToAddress.City | Trim | Quote }}{{Trennzeichen}}\
{{ Report.ShippingMethod.Name | Trim | Quote }}{{Trennzeichen}}\
{{ Report.ShippingMethod.Price | Nummer: 'N2','de-DE' }}{{Trennzeichen}}\
{{ position.DiscountRate | Nummer: 'N2','en-US' }}\
{{ Report.CurrencyISO | Trim | Quote }}{{Trennzeichen}}\
{{ Report.TotalNetPrice | Nummer: 'N2','de-DE' }}{{Trennzeichen}}
{% endfor -%}

Das bedeutet, wir hängen an der gleichen Stelle, wie unsere Vorredner...

Nun geht es darum herauszufinden, wie man die eigenen Felder ausliest und in einer CSV ausgibt. Als letztes würden wir gerne das Gleiche noch mit Vertreter-Provisionen auf Kundenbasis machen.

Wer kann uns helfen?

 

[css-umsetzung]

Wenn sich da bis morgen keiner findet poste ich da etwas zu, heute bin ich nicht mehr am Rechner.

 

[css-umsetzung]

Ich glaube ich bin gerade in einem falschem Film
kann es sein das man in einem Auftrag, in der Exportfunktion der neuen Vorlage, gar keine Artikelpositionen mehr hat?
Was macht die Vorlage denn dann noch für einen Sinn? Ich weiß es ist spät aber bin ich echt so blind?

 

[humorpharm]

An welcher Stelle würde denn dann die Provisionsberechnung Sinn machen?

 

[humorpharm]

position.Name und position.SKU gibt es hier aber z.B. noch über eine {% for position in Report.InvoicePosition -%} Abfrage

 

[css-umsetzung]

Dann bist du aber nicht im Auftrag sondern in der Rechnung oder?
Jetzt sehe ich das erst, es ist nicht mehr erkennbar was eine Liste ist und noch viel schlimmer, niemand weiß was in dieser Liste an Variablen vorhanden ist.
Die Positionsliste ist also noch vorhanden aber nicht so wie ich es erwartet hätte.

OK ich schaue mir das morgen an......

 

[humorpharm]

Ich bin froh, dass ich nicht total verblödet bin... und Du das mit der Variablenliste auch so siehst

Die Grundidee ist ja, nach einer erfolgreich erstellten und bezahlten Rechnung, einen Provisionsanspruch festzustellen. Der Auftrag alleine reicht aus meiner Sicht hierfür noch nicht aus. Idealer Weise schließt man dann noch mit einem Versatz von 14 bzw. 30 Tagen (wenn nämlich das Widerrufsrecht abgelaufen ist) über den Ausführungsplan aus, dass es zu einem Storno oder einer Erstattung gekommen ist, um eine Überzahlung zu vermeiden...

Im Anhang noch einmal die Workflow-Einstellung, mit der man grundsätzlich feststellen kann, ob jmd. provisionsberechtigt ist. Das heißt, hier ist die Variable vorhanden.

Also erstmal eine ruhige Nacht und viel Spaß morgen mit den Völkermassen zur 30. Einheitsfeier in Berlin

 

[301Moved]

Ich würde gar nicht den "Umweg" über ne Exportvorlage gehen, sondern direkt aus dem Workflow die Datei zur Provisionsberechnung schreiben lassen. Optimalerweise so, dass man die Liste auch wieder einlesen lassen kann über die Aufgabenplanung auf den jeweiligen Vertreter (als Kunden).

 

[humorpharm]

@vekoop Das würde ich gerne machen. Die Herausforderung besteht nur darin, dass ich einfach nicht herausfinde, wie ich den Wert der eigenen Felder in diese Datei bekomme...

 

[301Moved]

Ist das nicht: {{ Vorgang.Auftrag.Positionen.Artikel.EigeneFelder }} - ich verwende die nicht, deswegen kann ich das nicht sagen. Das per "contains" abfragen und dann den Wert der Auftragsposition x Provision schreiben per "Datei schreiben" als Ereignis

 

[css-umsetzung]

Ist das nicht: {{ Vorgang.Auftrag.Positionen.Artikel.EigeneFelder }} - ich verwende die nicht, deswegen kann ich das nicht sagen. Das per "contains" abfragen und dann den Wert der Auftragsposition x Provision schreiben per "Datei schreiben" als Ereignis

Das kannst du nur in den alten Formularen verwenden.

Ich bin froh, dass ich nicht total verblödet bin... und Du das mit der Variablenliste auch so siehst

Die Grundidee ist ja, nach einer erfolgreich erstellten und bezahlten Rechnung, einen Provisionsanspruch festzustellen. Der Auftrag alleine reicht aus meiner Sicht hierfür noch nicht aus. Idealer Weise schließt man dann noch mit einem Versatz von 14 bzw. 30 Tagen (wenn nämlich das Widerrufsrecht abgelaufen ist) über den Ausführungsplan aus, dass es zu einem Storno oder einer Erstattung gekommen ist, um eine Überzahlung zu vermeiden...

Im Anhang noch einmal die Workflow-Einstellung, mit der man grundsätzlich feststellen kann, ob jmd. provisionsberechtigt ist. Das heißt, hier ist die Variable vorhanden.

Also erstmal eine ruhige Nacht und viel Spaß morgen mit den Völkermassen zur 30. Einheitsfeier in Berlin

Ich gehe nicht vor die Tür

so also ich hab hier mal einen Versuchsaufbau durchgeführt

{% for position in Report.InvoicePosition -%}
{% if position.PositionType == 'Item' -%}
{% capture query %}\
SELECT TOP 1 taas.cWErtVarchar
FROM dbo.vArtikelAttributSprachePlattform AS vaa 
    RIGHT JOIN dbo.tAttribut AS ta ON ta.kAttribut = vaa.kAttribut AND ta.cGruppeName='Urheberinformationen' 
    LEFT JOIN dbo.tAttributSprache AS tas ON  tas.kAttribut = vaa.kAttribut AND tas.cName='Urheber'
     LEFT JOIN dbo.tArtikelAttributSprache AS taas on taas.kArtikelAttribut = vaa.kArtikelAttribut
WHERE vaa.kArtikel={{ position.ProductInternalId }}
{% endcapture %}\
{{ position.SKU }} - {{ position.ProductInternalId }} - {{ query | DirectQueryScalar }}
{% endif -%}\
{% endfor -%}

Wichtig ist dabei das du auch den Positionstypen prüfst so wie ich das gemacht habe, sonst könnte es einen Fehler geben da die SQL Abfrage dann ja keine interne ID hat.


Also das man da jetzt keine Informationen hat welche Variablen möglich sind und sich diese mühsam aus den views in der Datenbank selbst raussuchen muss ist nicht so Klasse, das bedeutet das Shopbesitzer noch mehr von externen abhängig sind, weil das klickibunti komplett weg fällt.

 

[301Moved]

Das kannst du nur in den alten Formularen verwenden.

Ich würde ja gar kein Formular verwenden

 

[humorpharm]

Moin, das sieht schon genial aus!!! und es funktioniert auch! Dafür schon mal Danke, Danke, Danke!

Ein letzter Punkt noch. Da wir für jeden Artikel eine unterschiedliche Tantieme zahlen, steht dieser Wert in einem zweiten Feld die prozentuale Beteiligung [tas.cName='Tantiemen in %']. In einem dritten Feld steht ein Fixbetrag [tas.cName='Tantiemen in EUR']. Es gibt aber immer nur eins von beidem, wäre aber auch ok, wenn beide Werte exportiert werden.

Meine SQL-Kenntnisse reichen hierfür nicht aus, wie ich die Abfrage erweitern müsste, um alle drei Wert abzufragen und entsprechend als Ergebnis in query auszugeben. Könntest Du da nochmal rüberschauen?

 

[css-umsetzung]

Das musst du dann ja mit zwei Abfragen machen, dann solltest du den ersten Query aber auch etwas ändern

Liste:
{% for position in Report.InvoicePosition -%}
{% if position.PositionType == 'Item' -%}
{% capture query %}\
SELECT TOP 1 taas.cWErtVarchar
FROM dbo.vArtikelAttributSprachePlattform AS vaa
    RIGHT JOIN dbo.tAttribut AS ta ON ta.kAttribut = vaa.kAttribut AND ta.cGruppeName='Urheberinformationen'
    LEFT JOIN dbo.tAttributSprache AS tas ON  tas.kAttribut = vaa.kAttribut
     LEFT JOIN dbo.tArtikelAttributSprache AS taas on taas.kArtikelAttribut = vaa.kArtikelAttribut
WHERE vaa.kArtikel={{ position.ProductInternalId }} AND tas.cName='Urheber'
{% endcapture %}\
{% capture proviQuery %}\
SELECT TOP 1 taas.cWErtVarchar
FROM dbo.vArtikelAttributSprachePlattform AS vaa
    RIGHT JOIN dbo.tAttribut AS ta ON ta.kAttribut = vaa.kAttribut AND ta.cGruppeName='Urheberinformationen'
    LEFT JOIN dbo.tAttributSprache AS tas ON  tas.kAttribut = vaa.kAttribut
     LEFT JOIN dbo.tArtikelAttributSprache AS taas on taas.kArtikelAttribut = vaa.kArtikelAttribut
WHERE vaa.kArtikel={{ position.ProductInternalId }} AND (tas.cName='Tantiemen in %' OR tas.cName='Tantiemen in EUR') AND NULLIF(taas.cWErtVarchar,'')!='' and NULLIF(taas.cWErtVarchar,'')!=''
{% endcapture %}\
----------------------------
SKU: {{ position.SKU }}
kArtikel:  {{ position.ProductInternalId }}
Urheber: {{ query | DirectQueryScalar }}
Provision: {{ proviQuery | DirectQueryScalar }}
{% endif -%}\
{% endfor -%}

 

[humorpharm]

WOW, danke vielmals.

Es gibt noch ein kleines Thema. Die Provision in EUR wird nicht exportiert. Im Gegensatz zur %-Provision wurde diese nicht als Datentyp Wertliste sondern als Datentyp Preis angelegt.

Könnte das das Problem sein?