Neu Rechenoperationen mit varchar | Versandkosten aus csv-Spalte

[Dennis030]

Hallo!
Ich importiere Bestellungen von einem Marktplatz per CSV. Da die Versandkosten hier als Spalte hinzugefügt werden, kann ich diese nicht einfach als Position über Ameise importieren. Meine Idee ist, die Versandkosten ins Hinweis/Sonstiges-Feld einzutragen und per Workflow eine Position mit den Versandkosten zu importieren.

Das Problem ist:
Ich kann die in Brutto angegebenen Versandkosten nicht zu Netto umrechnen. Der Versandsteuersatz wird aus der Not heraus aus der ersten Bestellposition übernommen.

{% assign versand = Vorgang.Sonstiges.Hinweis | plus: 0 %}
{% assign steuer = Vorgang.AuftragsPositionen.ArtikelPositionen.ErstesObjekt.MwStSatz | divide: 100 %}
{% assign steuer = 1 | minus: steuer %}
{{ versand }} {{ versand | times: steuer }} {{ Vorgang.AuftragsPositionen.ArtikelPositionen.ErstesObjekt.MwStSatz }} {{ steuer }}

-> Dies führt zur Ausgabe: 3.99 3.99 19 1
Offenbar ist der Wert ein String und kann nicht berechnet werden.

{% assign versand = Vorgang.Sonstiges.Hinweis | plus: 0 %}
{% assign steuer = Vorgang.AuftragsPositionen.ArtikelPositionen.ErstesObjekt.MwStSatz | divide: 100 %}
{% assign steuer = 1 | minus: steuer %}
{{ versand }} {{ versand | times: steuer }} {{ Vorgang.AuftragsPositionen.ArtikelPositionen.ErstesObjekt.MwStSatz }} {{ steuer }}

{% capture query %}\
    SELECT CONVERT(float, LTRIM(RTRIM(cText))) FROM tBestellHinweis\
    INNER JOIN tBestellung ON tBestellHinweis.kBestellHinweis=tBestellung.kBestellHinweis\
    WHERE tBestellung.cBestellNr='{{ Vorgang.Stammdaten.Auftragsnummer }}'\
{% endcapture -%}
{% assign Auftrag_Anmerkung = query | DirectQueryScalar | plus: 0 %}
{% if Auftrag_Anmerkung != null -%}
{{ Auftrag_Anmerkung }} {{ Auftrag_Anmerkung | times: 2 }} {% assign Auftrag_Anmerkung  = Auftrag_Anmerkung | times: 2 %} {{ Auftrag_Anmerkung }}
{% endif -%}

> führt zu: 3,99 3,99 3,99
Der Ansatz in SQL funktioniert auch nicht, obwohl eine Konvertierung zu Float stattgefunden hat.


Hat jemand einen Tipp für mich, wie ich die Berechnung zum laufen kriege? Wahlweise auch gern einen komplett anderen Ansatz?

 

[mh1]

Dein Login mit dem du dich bei der Datenbank einloggst ist ja sicherlich auf deutsch eingestellt. Also liefert dir dein CONVERT(float, LTRIM(RTRIM(cText))) vermutlich 3,99 (Komma als Dezimaltrenner).
Wenn du in Liquid rechnen willst brauchst du aber 3.99 (Punkt als Dezimaltrenner).
Du müsstest dir also mit FORMAT(......, 'N', 'en-us') das entsprechende Format des Wertes aus der Datenbank holen.

 

[Dennis030]

Vielen Dank, wenn ich es richtig umgesetzt habe, hat es leider dennoch nicht funktioniert, obwohl die Variablen nun mit Dezimalpunkt ausgegeben werden. Ich glaube also, dass Liquid hier das Problem ist und den Wert dennoch als string einträgt? Der Trick mit plus: 0 sollte da eigentlich Abhilfe schaffen. Berechnet wird leider dennoch nichts:

{% capture query %}\

    SELECT FORMAT(CONVERT(float, LTRIM(RTRIM(cText))),'N','en-US') FROM tBestellHinweis\

    INNER JOIN tBestellung ON tBestellHinweis.kBestellHinweis=tBestellung.kBestellHinweis\
    WHERE tBestellung.cBestellNr='{{ Vorgang.Stammdaten.Auftragsnummer }}'\
{% endcapture -%}
{% assign Auftrag_Anmerkung = query | DirectQueryScalar | plus: 0 %}
{% if Auftrag_Anmerkung != null -%}
{{ Auftrag_Anmerkung }} {{ Auftrag_Anmerkung | times: 2 }} {% assign Auftrag_Anmerkung  = Auftrag_Anmerkung | times: 2 %} {{ Auftrag_Anmerkung }}
{% endif -%}

->
3.99 3.99 3.99

Ein kleiner Test verwirrt mich noch mehr. Als könnten Workflows auf einmal gar nicht mehr rechnen:

{% assign floatde = 10,9 %}
{% assign floaten = 10.9 %}
{{ floatde }} {{ floaten }}  //> 10,9 10,9
{% assign floatdex = floatde | plus: 2 %}
{% assign floatenx = floaten | plus: 2 %}
{{ floatdex }} {{ floatenx }} //> 10,9 10,9
{% assign test = 10 | plus: 1 %}
{{ test }} //> 10
{% assign test = test | plus: test %}
{{ test }} //> 10

 

[MirkoWK]

Guten Morgen,

schreib das Plus mal mit großem P, dann sollte es klappen. Im Liquid-Editor ist es dann auch farblich hervorgehoben.
Das Betrifft dann auch alle Modifizierer.

Viele Grüße
Mirko

 

[mh1]

Vielen Dank, wenn ich es richtig umgesetzt habe, hat es leider dennoch nicht funktioniert, obwohl die Variablen nun mit Dezimalpunkt ausgegeben werden(...)

Also meine persönliche Empfehlung ist (da werden jetzt die Shopify/Liquid Verfechter aufschreien) - sowenig Logik wie möglich in Liquid zu packen.
Liquid ist eine Template Sprache. Dafür da, um dir in dynamischen Berichten Werte aus der Datenbank anzuzeigen. Es gibt zwar ein paar einfache Filter und auch bestimmte Kontrollstrukturen, aber auch viele Stolpersteine.

Ich weiß nicht genau, was du vorhast, aber lass doch die Berechnungen von der DB-Engine machen und hol dir per SQL den entsprechend errechneten Wert.
Diesen kannst du dir dann von Liquid anzeigen lassen (ob Liquid dann String oder Numerisch oder sonstwas draus macht ist dann nicht mehr so wichtig) 😉

Ein kleiner Test verwirrt mich noch mehr. Als könnten Workflows auf einmal gar nicht mehr rechnen(....)

Die geschweifte Klammer mit Prozentzeichen kennzeichnen den Kontrollfluss. Da kannst du sowas wie Kontrollstrukturen aufbauen und Werte z.B. nur anzeigen, wenn bestimmte Bedingungen erfüllt sind. z.B. {% if name == 'Michael' %} Hallo Michael!{% endif %}

Wenn du aber ein Objekt referenzieren willst brauchst du doppelt geschweifte Klammern: {{ }} -> In Liquid Sprech ist das ein Output Tag
z.B. Hallo {{ name }}

Wenn du einen Filter anwenden willst (mit dem Pipe Zeichen), dann mußt du das ganze in einen Output Tag packen. z.B. Hallo {{ 'michael' | upcase }}

Wie gesagt: Ich würde sowenig wie möglich mit Liquid berechnen. Viele Stolpersteine bzw. Fehlerquellen.

 

[Dennis030]

schreib das Plus mal mit großem P, dann sollte es klappen. Im Liquid-Editor ist es dann auch farblich hervorgehoben.
Das Betrifft dann auch alle Modifizierer.

Verrückte Welt, das wars. Danke dir!

Also meine persönliche Empfehlung ist (da werden jetzt die Shopify/Liquid Verfechter aufschreien) - sowenig Logik wie möglich in Liquid zu packen.
Liquid ist eine Template Sprache. Dafür da, um dir in dynamischen Berichten Werte aus der Datenbank anzuzeigen. Es gibt zwar ein paar einfache Filter und auch bestimmte Kontrollstrukturen, aber auch viele Stolpersteine.

Wie du vorhergesagt hast, schreie ich hiermit auf. Liquid ist für mich als Shopify-User zu einfach und zu ansehnlich um es nicht statt SQL zu verwenden. Und bis auf solche Spitzfindigkeiten hat es mir noch nie (unverschuldetete) Probleme bereitet. Was ich versucht habe: Netto zu Brutto umrechnen, anhand eines variablen Steuersatzes.


Danke euch beiden für die freundliche Hilfe!

Edit: Das ist es letztendlich geworden: Das Hinweisfeld wird per CSV-Import mit den Brutto-Versandkosten gefüllt. Ich berechne die Nettoversandkosten und füge sie als Freiposition ein.

Nettopreis:

{% assign versand = Vorgang.Sonstiges.Hinweis | Times: 0.01 %}
{% assign steuer = 100.00 | Plus: Vorgang.AuftragsPositionen.ArtikelPositionen.ErstesObjekt.MwStSatz | DividedBy: 100 %}
{{ versand | DividedBy: steuer}}

 

[mh1]

Verrückte Welt, das wars. Danke dir!


Wie du vorhergesagt hast, schreie ich hiermit auf. Liquid ist für mich als Shopify-User zu einfach und zu ansehnlich um es nicht statt SQL zu verwenden. Und bis auf solche Spitzfindigkeiten hat es mir noch nie (unverschuldetete) Probleme bereitet. Was ich versucht habe: Netto zu Brutto umrechnen, anhand eines variablen Steuersatzes.

😁 👍
Nehme deinen Aufschrei hiermit zur Kenntnis 😂

Aber das ist ja das schöne wenn verschiedene Tools zur Verfügung stehen: Jeder kann es mit den Werkzeugen machen, die ihm am sinnvollsten erscheinen