Ich habe gerade bemerkt, dass wenn ich den Verkaufspreis einer Bestellposition, in einem bestehenden Auftrag, im Nachgang ändere, dann ändert sich zwar der Nettopreis in der Listenansicht der Aufträge aber nicht der Bruttopreis. Dort steht dann immer noch der alte Bruttopreis. Auch in einem entsprechenden Bericht wird alte Bruttopreis ausgegeben.
In der Druckansicht des Belegs, wird der Netto- als auch der Bruttopreis aber korrekt ausgegeben.
Ändere mal die erste Zeile Deiner "bridge.php" in:
exec("/usr/bin/php74 cronjobs/starter2.php 2>&1", $out, $result);Du musst im Root Deiner OpenXE-Installation die ".htaccess" mit folgenden Code erweitern:
<Files bridge.php>
Order allow,deny
Allow from all
</Files>Danach funktioniert dann auch der Aufruf der URL per Cron.
Du musst dann aber daran denken, dass Du diese Änderung nach jedem OpenXE-Upgrade wieder einpflegen musst, weil OpenXE die ".htaccass" bei jedem Upgrade überbügelt.
Es ist so wie Alex es geschrieben hat. Man legt erst einen Auftrag an. Dort kann man dann auch eine Lieferanschrift etc. angeben. Anschließend den Auftrag freigeben und aus dem Auftrag dann direkt die Rechnung erstellen ("als Rechnung weiterführen"). Wenn der von Alex aufgeführte Code in der Textvorlage für die Rechnung steht, erscheint dann auch die Lieferanschrift auf dem Rechnungsbeleg.
Wenn direkt eine Rechnung ohne Auftrag geschrieben wird, gibt es die Möglichkeit nicht eine Lieferanschrift einzugeben, da dass eben nur über den Auftrag möglich ist. Dann musst Du Dir so behelfen, wie Du es selbst beschrieben hast.
....das klingt gut, danke 
Moin Moin liebe Community,
ich suche Unterstützung für die Anpassung der Shopware 6 Schnittstelle an das "Produkt Konfigurator 6 Enterprise" Plugin.
Im Wesentlichen geht es bei der Anpassung darum, dass die Konfiguration des jeweils bestellten Produkts beim Import der Aufträge mit importiert wird, sofern es sich um ein Produkt handelt, dass mit dem Konfigurator im Shop konfiguriert werden kann. Wo diese Bestelldaten in der Datenbank liegen, weiß ich: Tabelle "order_line_item", Spalte "payload". JSON rauskopieren und nach dem key="bogxProductConfigurator" suchen. Ab da sind dann die Konfigurationsdaten zu finden.
Vom Hersteller dieses Plugins gibt es eine Anpassung der Shopware 6 Bestellbestätigungs-E-Mail. Da diese ja auf die selben Daten in der Datenbank zugreift, sollte eine Ableitung dieses Codes für die Integration in die Shopware 6 Schnittstelle doch eigentlich kein Hexenwerk sein - zumindest wenn man denn Ahnung vom Programmieren hat....was bei mir leider nicht der Fall ist.
Nachfolgend einmal ein Auszug der Code-Anpassung für die Shopware 6 Bestellbestätigungs-E-Mail:
{# ----------- BLOCK EXTENDED by BOGX ----------- #}
{% block lineItem %}
{# ORIGINAL SHOPWARE #}
{% if nestedItem.payload.bogxProductConfigurator is not defined %}
<tr>
<td>{% if nestedItem.payload.productNumber is defined %}{{ nestedItem.payload.productNumber|u.wordwrap(80) }}{% endif %}</td>
<td>{% if nestedItem.cover is defined and nestedItem.cover is not null %}<img src="{{ nestedItem.cover.url }}" width="75" height="auto" alt="{{ nestedItem.label }}"/>{% endif %}</td>
<td>
{% if nestingLevel > 0 %}
{% for i in 1..nestingLevel %}
<span style="position: relative;">
<span style="display: inline-block;
position: absolute;
width: 6px;
height: 20px;
top: 0;
border-left: 2px solid rgba(0, 0, 0, 0.15);
margin-left: {{ i * 10 }}px;"></span>
</span>
{% endfor %}
{% endif %}
<div{% if nestingLevel > 0 %} style="padding-left: {{ (nestingLevel + 1) * 10 }}px"{% endif %}>
{{ nestedItem.label|u.wordwrap(80) }}
</div>
{% if nestedItem.payload.options is defined and nestedItem.payload.options|length >= 1 %}
<div>
{% for option in nestedItem.payload.options %}
{{ option.group }}: {{ option.option }}
{% if nestedItem.payload.options|last != option %}
{{ " | " }}
{% endif %}
{% endfor %}
</div>
{% endif %}
{% if nestedItem.payload.features is defined and nestedItem.payload.features|length >= 1 %}
{% set referencePriceFeatures = nestedItem.payload.features|filter(feature => feature.type == 'referencePrice') %}
{% if referencePriceFeatures|length >= 1 %}
{% set referencePriceFeature = referencePriceFeatures|first %}
<div>
{{ referencePriceFeature.value.purchaseUnit }} {{ referencePriceFeature.value.unitName }}
({{ referencePriceFeature.value.price|currency(currencyIsoCode) }}* / {{ referencePriceFeature.value.referenceUnit }} {{ referencePriceFeature.value.unitName }})
</div>
{% endif %}
{% endif %}
</td>
<td style="text-align: center">{{ nestedItem.quantity }}</td>
<td>{{ nestedItem.unitPrice|currency(currencyIsoCode) }}</td>
<td>{{ nestedItem.totalPrice|currency(currencyIsoCode) }}</td>
</tr>
{# BOGX KONFIGURATION #}
{% else %}
{% set bogxConfigArray = nestedItem.payload.bogxProductConfigurator %}
{% set bogx_precision = bogxConfigArray.unitySurchargePrecision %}
{% set taxState = order.taxStatus %} {# 'gross'=brutto or 'net'=netto #}
<tr>
{# Produkt-Nr #}
<td style="vertical-align:top;">{% if nestedItem.payload.productNumber is defined %}{{ nestedItem.payload.productNumber|u.wordwrap(80) }}{% endif %}</td>
{# Produktbild #}
{% if bogxConfigArray.productImage is defined and bogxConfigArray.productImage is not null %}
<td style="vertical-align:top;"><img src="{{ bogxConfigArray.productImage }}" width="75" height="auto" alt="{{ bogxConfigArray.productName }}"/></td>
{% else %}
<td style="vertical-align:top;">{% if nestedItem.cover is defined and nestedItem.cover is not null %}<img src="{{ nestedItem.cover.url }}" width="75" height="auto" alt="{{ bogxConfigArray.productName }}"/>{% endif %}</td>
{% endif %}
{# Bezeichnung #}
<td>
<div>{{ bogxConfigArray.productName }}</div>
{% if bogxConfigArray.ordercode is defined and bogxConfigArray.ordercode %}
<div>Order-Code: {{ bogxConfigArray.ordercode }}</div>
{% else %}
<div>Produkt-Nr: {{ bogxConfigArray.articleordernumber }}</div>
{% endif %}
<table style="border-collapse: collapse;border-spacing: 0;border: 0;width: 100%;font-size: 12px;margin: 10px 0 15px 0;">
{% for bogxPosition in bogxConfigArray.optionsGroups %}
{% set dt = bogxPosition.datatype %}
{# MULTISELECT without image #}
{% if dt == 'checkbox_set' or dt == 'checkbox_quantity' %}
{% for valueId in bogxPosition.valueID %}
{% set bogxTitle = bogxPosition.title[valueId] %}
{% set bogxSurcharge = "" %}
{% if bogxPosition.unitySurcharge[valueId] is defined %}
{% if bogxPosition.unitySurcharge[valueId][2] %} {% set bogx_precision = bogxPosition.unitySurcharge[valueId][2] %} {% endif %}
{% if taxState == 'net' %}
{% set unityPrice=bogxPosition.unitySurcharge[valueId][0] | currency(currencyIsoCode, null, bogx_precision) %}
{% else %}
{% set unityPrice=bogxPosition.unitySurcharge[valueId][1] | currency(currencyIsoCode, null, bogx_precision) %}
{% endif %}
{% endif %}
{% if unityPrice is defined and '$price' in title %}
{% set bogxTitle = bogxTitle|replace({'$price': unityPrice}) %}
{% set bogxTitle = bogxTitle|replace({'\n':'<br>\n'}) %}
{% elseif '<b>' in title %}
{% set bogTitle = bogxTitle|split('<b>')[0] %}
{% endif %}
{% if bogxPosition.surcharge[valueId] is defined %}
{% if bogxPosition.surcharge[valueId][2] %} {% set bogx_precision = bogxPosition.surcharge[valueId][2] %} {% endif %}
{% if taxState == 'net' %}
{% set bogxSurcharge=bogxPosition.surcharge[valueId][0] | currency(currencyIsoCode, null, bogx_precision) %}
{% else %}
{% set bogxSurcharge=bogxPosition.surcharge[valueId][1] | currency(currencyIsoCode, null, bogx_precision) %}
{% endif %}
{% endif %}
....usw.Hätte jemand von Euch Zeit, Lust und Ahnung mir bei der Anpassung der Schnittstelle zu helfen!?
Wenn sich vielleicht sogar Jemand finden sollte, der diese Anpassung komplett für mich übernehmen würde, wäre ich auch gern bereit seinen Aufwand angemessen zu entschädigen 
Ja, die Textvorlagen kenne ich und ich nutze sie auch.
Ich würde nur z.B. diese Anrede "Sehr geehrte Damen und Herren" ändern wollen, weil ich meine Kunden so nur in den allerallerseltesten Fällen anrede.
Könnte man für diese Mailvorlage nicht zvielleicht auch eine Geschäftsbriefvorlage nutzen?
Lässt sich eigentlich irgendwo der Inhalt der Ticket-Vorlage anpassen?
Ich habe mir die Konstellation, so wie Alex sie vorgeschlagen hat, jetzt mal eingerichtet:
• Dafür einfach ein zweites Postfach, speziell nur die E-Mail die zu Tickets werden sollen, anlegen.
• Dieses Postfach dann zusätzlich zu Deinem zentralen Postfach in Deinem E-Mail Client anlegen (IMAP).
• Anschließend lassen sich die im zentralen Postfach eingehenden E-Mails manuell oder per Regel in das Postfach für die Tickets verschieben.
• OpenXE holt die E-Mails dann aus diesem "Ticket"-Postfach ab und legt sie als Ticket an.
Das klappt bei mir wunderbar und es ist auch ein Workflow, der mir gut gefällt!
Was mir nur noch nicht ganz klar ist bei Handling der E-Mails ist : was ist genu ist der Vorteil von der Möglichkeit die E-Mails zusätzlich zu archivieren? Ist es nur die Möglichkeit sie automatisch z.B. nach 10 Jahren löschen zu lassen!?
Super....funktioniert nun einwandrei. Danke für die schnelle Behebung
Ich wollte mir gerade einen neuen E-Mail Account in OpenXE anlegen.
Beim Klick auf "+NEU" geht aber keine Eingabemaske auf, sondern nur eine leere Seite:
Ich habe mir dann einfach einen meiner ungenutzten Accounts geschnappt und den mit den Zugangsdaten des neuen E-Mail Kontos aktualisiert. Beim Testen des SMTP mit der Testmail, bekomme ich nun diese Fehlerseite angezeigt:
Die Zugangsdaten habe ich schon x-mal kontrolliert und das Postfach funktioniert grundsätzlich auch.
Hmmmm...ich nutze die Labels bei mir problemslos und im vollen Umfang.
Also - tatsächlich ist der Import der SQL nicht komplett durchgelaufen.
An der Stelle, an der die "Struktur des Views" in der SQL gesetzt werden, ist es zu einem Berechtigungsproblem gekommen, weil dort natürlich der Benutzer meiner Ausgangs-Datenbank eingetragen war. Dementsprechend wurden die in der SQL danach folgenden Indizes und AUTO_INCREMENT`s auch nicht mehr verarbeitet. Nach der Änderung der SQL an den enstprechenden Stellen auf den neuen Dantenbank-Benutzer, lief der Import auch bis zum Ende durch. Damit hat dann auch das anschließende OpenXE-Upgrade problemlos funktioniert.
Ok, dann scheint wohl beim Übertragen der DB auf das Testsystem etwas nicht so wirklich funktioniert zu haben. In der produktiven DB hat die Spalte ID nämlich autoincrement. Ich werde die Test-DB löschen und es noch einmal probieren. Danke Dir erst einmal, ich gebe dann Bescheid!
Hab derzeit noch keinen SSH-Zugang im Web-Tarif inkludiert. Wenn`s keine andere Möglichkeit gibt, müsste ich meinen Tarif erst einmal upgraden und mich dann auch erst einmal ein wenig in die Bedienung von SSH einarbeiten. Ist halt nicht jeder ein echter Webadmin 
Für mich ist das tatsächlich relativ egal, welcher Wert als Datum für "Auslieferung Lager" gesetzt wird. Ich arbeite und verarbeite sowieso nur mit dem Wert aus "Wunsch Liefertermin".
Ich war es nur von Xentral so gewohnt, dass auch nur die Tage als Differenz verarbeitet werden, die ich entsprechend konfiguriert habe. Eine 0 wurde dort auch als 0 verarbeite nicht hardcoded auf 2 gesetzt. Insofern hatte ich das Verhalten von OpenXE in diesem Zusammenhang als Bug gewertet.
Moin,
ich bin nun seit einer Woche produktiv mit OpenXE. Soweit funktioniert alles bestens 
Eine Kleinigkeit ist mir die Tage bei der Bearbeitung von Aufträgen jedoch aufgefallen:
Wenn ich in einen Auftrag einen Wunsch Liefertmin eintrage, dann wird automatisch der Termin für "Auslieferung Lager" gesetzt. Die Anzahl an Tagen, die zwischen diesen beiden Terminen liegen sollen, kann jeweils in den Projekteinstellungen unter "Logistik / Versand" und dann "Anzahl Differenz Tage Auslieferung:" definiert werden.
Ich habe dort "0" eingetragen. Trotzdem wird im Auftrag aber immer eine Differenz von 2 Tagen gesetzt.