> For the complete documentation index, see [llms.txt](https://help.vario-software.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.vario-software.de/vario-cloud-changelog/2026/2026.33.0.md).

# 2026.33.0

## <i class="fa-star" style="color:$primary;">:star:</i> Highlight: Offene Posten an der Kasse – Teilzahlungen und Rücknahmen

Der **OP-Ausgleich an der Kasse** ist deutlich flexibler geworden: Kunden können **Teilbeträge** auf einen offenen Posten zahlen, und in der **Kassenretoure** lassen sich an der Kasse geleistete **Zahlungen** sowie **Kundeneinzahlungen (Guthaben)** wieder **zurücknehmen**.

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Offene Posten:</strong></mark> Teilzahlungen beim OP-Ausgleich</summary>

Beim **OP-Ausgleich an der Kasse** musste bisher immer der **komplette offene Betrag** kassiert werden. Jetzt kannst Du einen **beliebigen Teilbetrag** erfassen.

* Im Dialog **„OP-Ausgleich bearbeiten“** zeigt der Hinweis **„Höchstens {Betrag} — ein Teilbetrag ist möglich.“** die Obergrenze an.
* Die Obergrenze ist der **zum Belegdatum zahlbare Betrag** des offenen Postens, also der offene Saldo **abzüglich des anwendbaren Skontos**.
* Wird mehr erfasst, meldet das System **„Der Betrag darf den zum Belegdatum zahlbaren Betrag des Offenen Postens nicht übersteigen.“**

Die bisherige Meldung „Der Betrag muss dem offenen Betrag des Offenen Postens entsprechen (keine Teilzahlung)“ entfällt damit.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Retoure:</strong></mark> Zahlungen und Guthaben zurücknehmen</summary>

**OP-Ausgleich und Kundeneinzahlung** sind jetzt nicht mehr nur in der Quittung, sondern auch in der **Kassenretoure** möglich – dort als **Rücknahme**.

* Über die Kassen-Aktion für Offene Posten wählst Du aus **„An der Kasse bezahlte Offene Posten“** bzw. **„Guthaben des Kunden“** aus. Gibt es nichts zurückzunehmen, erscheint der Hinweis **„Für {Kunde} gibt es keine an der Kasse bezahlten Offenen Posten.“** bzw. **„Für {Kunde} gibt es kein offenes Guthaben.“**
* Die Positionen heißen in der Bonliste **„OP-Rücknahme“** bzw. **„Guthaben-Rücknahme“**. Im Betragsdialog (**„Zahlung zurücknehmen“** / **„Guthaben zurücknehmen“**) siehst Du **„Zurücknehmbar: {Betrag}“** bzw. **„Guthaben: {Betrag}“**.
* **Teilrücknahmen** sind zulässig. Zurückgenommen werden darf höchstens der **an der Kasse ausgeglichene Betrag** bzw. das **noch offene Guthaben** – andernfalls kommt die Meldung **„Der Betrag übersteigt den an der Kasse ausgeglichenen Betrag bzw. das offene Guthaben des Offenen Postens.“**
* Je Retoure ist **eine Guthaben-Rücknahme** und **je offenem Posten eine Rücknahmeposition** möglich.

Zusätzlich ist die bisherige Sperre aufgehoben: Der **Sofortstorno** ist für Bons mit OP-Ausgleichs- oder Einzahlungspositionen nicht mehr blockiert.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Offene Posten:</strong></mark> Neues Feld „An der Kasse ausgeglichen“</summary>

Offene Posten haben ein neues Feld **„An der Kasse ausgeglichen“**. Es enthält den über **OP-Ausgleichspositionen an Kassen** ausgeglichenen Betrag **abzüglich der über Kassenretouren zurückgenommenen Beträge**.

Das Feld lässt sich in den Tabellen der Offenen Posten als **Spalte einblenden**, **filtern** und **sortieren**. Die Kasse nutzt es, um die Auswahl der zurücknehmbaren Posten vorzufiltern.

</details>

## <i class="fa-star" style="color:$primary;">:star:</i> Highlight: Ausgaberegeln – Kontaktarten, Adressvorlagen und neue Auswahlfelder

Die **Ausgabe** von Belegen und Mahnungen wurde deutlich erweitert. Neu sind eine **Kontaktarten-Priorisierung**, mit der Du steuerst, an welche Kontaktart eine E-Mail bevorzugt geht, **Ausgaberegeln direkt in der Adressvorlage** und eine Reihe neuer **durchsuchbarer Auswahlfelder** in Vorlagen und Suchdialogen.

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Ausgaberegeln:</strong></mark> Kontaktarten-Priorisierung für den E-Mail-Empfänger</summary>

Ausgaberegeln mit der Ausgabeart **E-Mail** haben den neuen Bereich **„Kontaktarten-Priorisierung“** mit dem Feld **„Kontaktarten (E-Mail)“**. Er steht für die Ausgabe von **Belegen** und **Mahnungen** zur Verfügung und erscheint nur, wenn die Regel tatsächlich auf E-Mail ausgibt.

* Über die Auswahl **„Kontaktart hinzufügen“** nimmst Du Kontaktarten in die Liste auf.
* Die Liste ist **per Drag & Drop sortierbar**; die Spalte **„Prio“** zeigt die laufende Reihenfolge, über das Kreuz entfernst Du einen Eintrag wieder.

Bei der Ausgabe wird der E-Mail-Empfänger damit so ermittelt:

* Grundlage ist beim Beleg der **Rechnungsempfänger** – ist keiner gesetzt, der Beleg-Kunde. Bei der Mahnung ist es die Adresse des **offenen Postens** der ersten Mahnposition.
* Berücksichtigt werden nur Kontakte der Kontaktart-Gruppe **E-Mail** und nur Kontaktarten, die **in der Liste stehen**.
* Ausgewählt wird der Kontakt mit der **höchsten Priorität** in der Liste; bei gleicher Kontaktart entscheidet die **Sortierung des Kontakts** an der Adresse bzw. am Ansprechpartner.
* Bei **B2B**-Adressen werden zuerst die Kontakte der **Ansprechpartner** durchsucht, dann die der **Hauptadresse** – bei den übrigen Geschäftsbeziehungen umgekehrt.
* Ist die Liste **leer** oder findet sich **kein passender Kontakt**, wird kein Empfänger ermittelt und die Ausgabe per E-Mail entfällt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Adressvorlagen:</strong></mark> Ausgaberegeln in der Vorlage</summary>

In einer **Adressvorlage** kannst Du jetzt auch **Ausgaberegeln** hinterlegen. Der neue Bereich **„Ausgaberegeln“** legt über **„Ausgaberegel“** beliebig viele Regeln an – je Regel mit

* **Ausgabemodul**,
* **Quell-Ausgabetyp** oder **Ziel-Ausgabetyp** (es ist immer nur eines von beiden setzbar – die Auswahl des einen sperrt das andere),
* **Ziel-Reportgruppe** (die Auswahl richtet sich nach dem gewählten Modul; **Standard-Reportgruppe** ist möglich),
* **Anzahl Ausgaben** sowie
* den **modulspezifischen Regel-Feldern**, die das gewählte Ausgabemodul mitbringt.

Wird eine Adresse über diese Vorlage angelegt, werden die Regeln als **Ausgaberegeln der Adresse** mit angelegt. Damit sind bei einer neuen Adresse nicht nur die Stammdaten, sondern auch die gewünschten Ausgabewege sofort gesetzt.

Die Adressvorlage selbst wird dafür jetzt **vom Server beschrieben** statt in der Oberfläche festgelegt – mit den Bereichen **Adresse**, **Kundendaten**, **Lieferantendaten** und **Vertreter**, die abhängig von den gewählten **Adress-Typen** ein- und ausgeblendet werden.

{% hint style="warning" %}
Bestehende Adressvorlagen werden bei der Aktualisierung automatisch umgestellt: Ihr Inhalt wird unter den Bereich **„Adresse“** verschoben, damit die Ausgaberegeln daneben Platz haben. Es gehen dabei keine Werte verloren.
{% endhint %}

</details>

<details>

<summary><mark style="color:$primary;"><strong>Vorlagen und Suchdialoge:</strong></mark> Neue durchsuchbare Auswahlfelder</summary>

In Vorlagen, Parameter-Formularen und Suchdialogen stehen weitere Stammdaten jetzt als **durchsuchbare Auswahl** statt als einfache Liste zur Verfügung:

**Anrede**, **Zahlart**, **Lieferart**, **Lieferbedingung**, **Preisgruppe**, **Steuersatz**, **Erstkontaktart**, **Ausgabetyp** und **Report-Gruppe**.

Zusätzlich zeigen die Auswahlfelder für **Anrede**, **Kundengruppe**, **Lieferantengruppe**, **Zahlart**, **Lieferart**, **Lieferbedingung**, **Preisgruppe** und **Steuersatz** einen bereits gespeicherten Wert jetzt korrekt mit seiner Bezeichnung an – bisher blieb das Feld beim Öffnen einer gespeicherten Vorlage leer.

</details>

## <i class="fa-lightbulb-on" style="color:$primary;">:lightbulb-on:</i> Neuerungen

<details>

<summary><mark style="color:$primary;"><strong>Amazon-App:</strong></mark> Umlagerungen zu Amazon (FBA) (Beta)</summary>

Für **FBA-Verkaufskanäle** gibt es in der Amazon-App den neuen Bereich **„Umlagerungen“**. Damit planst Du eine Anlieferung an Amazon vollständig in VARIO und übergibst sie anschließend an das Lager.

Eine Umlagerung durchläuft dabei die Schritte:

* **Positionen** – Artikel und Mengen für die Anlieferung
* **Versandgruppen** – Amazon schlägt die Aufteilung vor (**„Aufteilung in {Anzahl} Versandgruppen“**)
* **Kartons** – Kartons je Versandgruppe melden; daraus werden die Placement-Gebühren berechnet
* **Fulfillment Center** – **„Verteilung auf {Anzahl} Fulfillment Center“** mit Gebühren, Rabatten und Gültigkeit auswählen
* **Transport** – Transportoption bestätigen, bei Stückgut inklusive **Anlieferfenster**
* **Übergabe ans Lager** – es entsteht ein **Umlagerungs-Auftrag**

Der Status der Umlagerung wird durchgängig ausgewiesen – von **„Noch nicht an Amazon übertragen“** über **„Versandgruppen bestätigt“**, **„Kartons gemeldet“**, **„Fulfillment Center bestätigt“** und **„Transport bestätigt“** bis **„An das Lager übergeben“**.

{% hint style="info" %}
Voraussetzung ist ein Verkaufskanal mit **Listing-Typ FBA** und ein hinterlegtes **„Lager für FBA-Aufträge“** in den Kanal-Einstellungen. Fehlt eines von beiden, weist die App im Bereich „Umlagerungen“ ausdrücklich darauf hin. Für den Transport stehen **„Amazon Partnered Carrier“** und **„Eigener Versanddienstleister“** zur Verfügung; zusätzlich lassen sich in den App-Einstellungen ein **Standard-Karton für die Planung** sowie ein **Transitlager für FBA-Umlagerungen** hinterlegen.
{% endhint %}

</details>

<details>

<summary><mark style="color:$primary;"><strong>Amazon-App:</strong></mark> Listing-Typ und Versender für FBA und Prime</summary>

Der **Listing-Typ** eines Amazon-Verkaufskanals wird jetzt ausdrücklich unterschieden: **FBM**, **FBA** und **Seller Fulfilled Prime**. Der Typ steuert, welche Funktionen für den Kanal zur Verfügung stehen – Umlagerungen zu Amazon gibt es beispielsweise nur für **FBA**.

Passend dazu gibt es in den Versender-Einstellungen der App eigene Konfigurationen für **FBA** und **Prime**, und im Paket eines Verkaufsbelegs eigene Ansichten für **FBA-** und **Prime-Sendungen**.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Lager/Kommissionierung:</strong></mark> Abweichung von der Lagerplatzvorgabe</summary>

Steht die vorgegebene Ware nicht am vorgegebenen Lagerplatz, musste die Pickliste bisher abgebrochen werden. Jetzt kann der Kommissionierer die Position **selbst auflösen**.

In der Picklisten-Vorlage aktivierst Du dafür die Option **„Abweichung von der Lagerplatzvorgabe erlauben“**. Anschließend stehen beim Sammeln zwei Aktionen zur Verfügung:

* **„Anderen Lagerplatz suchen“** – die Lagerplatzvorgabe wird verworfen und ein anderer Lagerplatz mit Bestand vorgegeben. Wurde auf der Position noch nichts gesammelt, wird vorher nachgefragt.
* **„Mit gesammelter Menge abschließen“** – die Position wird mit der bereits gesammelten Menge abgeschlossen, die restliche Lagerplatzvorgabe verworfen.

Ist auf **keinem** anderen Lagerplatz ausreichend Bestand vorhanden, erscheint der Dialog **„Zu wenig Bestand“**. Er prüft zusätzlich die **Nachschublager** und zeigt gefundene Bestände an. Von dort aus kannst Du

* die Pickliste über **„Pausieren bis umgelagert wurde“** anhalten, bis die Ware umgelagert ist, oder
* die Position über **„Ohne neue Ware abschließen“** mit einer Mindermenge abschließen.

Lässt die Picklisten-Vorlage eine Mindermenge nicht zu, wird das ausdrücklich gemeldet. Das Überspringen ist nur **während des Sammelns** möglich.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Lager/Kommissionierung:</strong></mark> Chargenvorgabe in der Schnellkommissionierung</summary>

Die **automatische Chargenermittlung** greift jetzt auch in der **Schnellkommissionierung**. Bisher war sie auf Einzel-, Rollende und Konsolidierungs-Kommissionierung beschränkt.

Damit werden bei Artikeln mit **Charge** oder **MHD** die Chargen auch in der Schnellkommissionierung automatisch ermittelt und bestätigt – vorausgesetzt, in der Picklisten-Vorlage sind **„Für S/N u. Charge mit Verfallsdatum/MHD: älteste S/N o. Charge in Pickliste vorgeben“** und **„Chargen automatisch ermitteln und bestätigen“** aktiv.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Shopware-6-App:</strong></mark> Kategorien synchronisieren</summary>

Die Shopware-6-App überträgt jetzt auch **Kategorien**. In den App-Einstellungen gibt es dafür die neue Aktion **„Kategoriebaum-Übertragung“**, die den Kategoriebaum des Verkaufskanals im Hintergrund nach Shopware überträgt und den Fortschritt anzeigt (**„{x} Kategorien gefunden …“**, **„Kategorie {x} von {y} wird übertragen …“**). Am Ende wird gemeldet, wie viele Kategorien in Shopware **neu angelegt** wurden.

Am ERP-Kategorieformular eines Shopware-Verkaufskanals stehen dafür neue Felder zur Verfügung:

* Zusatzfeldgruppe **„Shopware 6 Kategorie“** mit **In der Navigation ausblenden**, **Shopware-Tag-IDs** und **CMS-Layout-Seiten-ID**
* Zusatzfeldgruppe **„Shopware 6 Kategorie SEO“** – **je Sprache** pflegbar – mit **SEO-Titel**, **Meta-Beschreibung**, **Keywords** und **SEO-URL-Pfad**

{% hint style="info" %}
Die **übergeordnete Kategorie** lässt sich jetzt nur noch **beim Anlegen** wählen. Ein nachträgliches Umhängen war im Backend ohne Wirkung und wird deshalb nicht mehr angeboten.
{% endhint %}

</details>

<details>

<summary><mark style="color:$primary;"><strong>DHL-App:</strong></mark> Sendungsverfolgung über die Push-API</summary>

Die DHL-App meldet Pakete jetzt bei der **Push-Sendungsverfolgung** von DHL an. Die Sendungsereignisse werden dadurch **automatisch** am Paket hinterlegt, statt sie bei jedem Öffnen abzurufen – der Verlauf ist damit auch ohne Abruf sofort sichtbar und je Status mit einem eigenen Symbol dargestellt.

Im **Verkaufsbeleg** zeigt der Reiter **„Detail“** zusätzlich den Zustellstatus aller Pakete als Kennzeichen an:

* **Nicht zugestellt**
* **Teilweise zugestellt**
* **Komplett zugestellt**
* **Probleme bei mind. 1 Sendung** – mit dem Hinweis **„{x} von {y} Paketen mit Problem“**
* **Keine automatischen Meldungen** – mit dem Hinweis **„{x} von {y} Paketen ohne automatische Meldungen“**

</details>

<details>

<summary><mark style="color:$primary;"><strong>MCP-Server-App:</strong></mark> KI-Assistent verbinden</summary>

Die MCP-Server-App hat einen neuen Ablauf **„KI-Assistent verbinden“**. Er liegt jetzt in den **Benutzereinstellungen** (Reiter **„MCP-Server“**) und ersetzt die bisherige Info-Seite in den App-Stammdaten.

* Im Schritt **„KI-Tool wählen“** stehen unter anderem **Claude Desktop**, **Claude Code**, **ChatGPT**, **Cursor**, **VS Code** (auch Insiders), **Windsurf**, **Gemini CLI**, **LM Studio** und **n8n** zur Auswahl – dazu **Generisch (HTTP)** und **Anderes**.
* Im Schritt **„Zugriffsrechte“** legst Du die Zugriffsstufe fest: **„Nur lesen“** (Suchen und Abfragen), **„Schreiben mit Bestätigung“** (destruktive Aktionen erfordern eine Bestätigung) oder **„Autonom schreiben“** (auch destruktive Aktionen ohne Bestätigung). Rechte, die Du selbst nicht vergeben darfst, sind gesperrt.
* Nach **„Verbinden“** erhältst Du die fertige **Konfiguration** für das gewählte Tool sowie den **API-Key**. Der Token ist **nur einmal sichtbar**. Für Cursor, VS Code und LM Studio gibt es zusätzlich einen Installations-Link.
* Unter **„Meine MCP-Zugriffs-Token“** siehst Du Deine eigenen Zugänge und kannst sie über **„Alle meine Tokens invalidieren“** widerrufen.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Verkaufskanäle:</strong></mark> Preise und Rabatte von einem anderen Verkaufskanal</summary>

Am Verkaufskanal gibt es die neuen Felder **„Preise von Verkaufskanal“** und **„Rabatte von Verkaufskanal“**. Damit legst Du **je Kanal** fest, aus welchem anderen Verkaufskanal Preise bzw. Rabatte übernommen werden, wenn der Kanal selbst keinen eigenen Preis bzw. Rabatt hat.

* Bleibt ein Feld **leer**, gibt es **keine Übernahme** – es greifen nur die Preise bzw. Rabatte des Kanals selbst.
* Ein Kanal darf nicht auf sich selbst oder **zyklisch** verweisen; das wird geprüft und gemeldet.
* Der eigene Kanal hat weiterhin **Vorrang** vor dem Herkunftskanal.

{% hint style="info" %}
Bisher war der **Standard-Verkaufskanal** fest als Rückfallebene hinterlegt. Damit sich am bestehenden Verhalten nichts ändert, wird bei der Aktualisierung für bestehende Verkaufskanäle automatisch der **Standard-Verkaufskanal** als Herkunftskanal für Preise und Rabatte eingetragen.
{% endhint %}

</details>

<details>

<summary><mark style="color:$primary;"><strong>Zusatzfelder:</strong></mark> Neuer Feldtyp „URL“</summary>

Für Zusatzfelder gibt es den neuen Typ **„URL“**. Ein URL-Zusatzfeld besteht aus zwei Eingaben:

* **Link-Text** – der Text, der angezeigt wird
* **URL** – die Adresse, standardmäßig mit `https://` vorbelegt und auf Gültigkeit geprüft

In der Anzeige wird das Feld als **klickbarer Link** dargestellt, der in einem **neuen Tab** öffnet; ist kein Link-Text hinterlegt, wird die URL selbst angezeigt. Auch in **Tabellen** und **Karten-Ansichten** werden URL-Werte als Link ausgegeben.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Bestellvorschlag:</strong></mark> Nur für bestimmte Lieferanten ausführen</summary>

Beim Erzeugen von **Bestellvorschlagslisten** – und in der zugehörigen **Vorlage** – gibt es den neuen Schalter **„Nur für bestimmte Lieferanten ausführen“**. Ist er aktiv, schränkst Du den Lauf ein über

* **Lieferanten** – eine Mehrfachauswahl konkreter Lieferanten und/oder
* **Lieferanten-Selektion (zur Filterung)** – eine gespeicherte Adress-Selektion

Die Einschränkung ist nicht möglich, wenn die **Lieferanten-Präferenz** bereits einen Lieferanten festlegt (**„Bestimmter Lieferant“** oder **„Hauptlieferant“**) – in diesem Fall wird der Schalter gesperrt und eine bestehende Einschränkung entfernt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Adresse:</strong></mark> Zusatzadresse zur Hauptadresse machen</summary>

Über die neue Aktion **„Zusatzadresse zur Hauptadresse machen“** tauschst Du Haupt- und Zusatzadresse einer Adresse. Der Dialog zeigt dazu den Hinweis **„Die gewählte Zusatzadresse wird zur Hauptadresse. Die bisherige Hauptadresse "{Name}" wird zur Zusatzadresse.“** und fragt

* die **Neue Hauptadresse** sowie
* den **Adresstyp der bisherigen Hauptadresse** ab.

Gibt es keine Zusatzadresse, wird das gemeldet. Aus einer geöffneten Zusatzadresse heraus steht die Aktion direkt als **„Zur Hauptadresse machen“** zur Verfügung.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Dashboard:</strong></mark> Neues Widget „Notizen“</summary>

Für die Dashboards von **Adresse**, **Artikel**, **Deal**, **Projekt** und **Aufgabe** gibt es das neue Widget **„Notizen“**. Es zeigt **Notiz** und **Bemerkung** des jeweiligen Datensatzes direkt im Dashboard und erlaubt das Bearbeiten und Speichern an dieser Stelle.

Im Bearbeitungsmodus des Widgets stellst Du über Schalter ein, **welche** der beiden Felder angezeigt werden – mindestens eines bleibt immer aktiv. Die Größe des Widgets ist frei anpassbar; die Editoren richten sich danach.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Projekte:</strong></mark> Timeline und Kanban erweitert</summary>

Die **Timeline** eines Projekts hat zwei neue Schaltflächen bekommen:

* **„Heute“** springt direkt zum heutigen Tag.
* **„Abgeschlossene Aufgaben ein-/ausblenden“** blendet erledigte Aufgaben aus der Timeline aus.

Aufgaben der obersten Ebene ohne Unteraufgaben werden zusätzlich in der zusammenklappbaren Gruppe **„Aufgaben ohne übergeordnete Aufgabe“** zusammengefasst. In der Kopfzeile stehen jetzt außerdem eine **Quartals-** und eine **Tageszeile** zur Verfügung.

Im **Kanban** eines Projekts gibt es im Kontextmenü einer Karte den neuen Eintrag **„Link kopieren“**. Er legt den Link zur Aufgabe – inklusive Nummer und Bezeichnung – in die Zwischenablage und meldet **„Link in Zwischenablage kopiert“**.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Artikel/Parameter:</strong></mark> Bester Prozentsatz für Kundenrabatte</summary>

Unter **Einstellungen/Artikel/Parameter** gibt es den neuen Parameter **„Bester Prozentsatz für Kundenrabatte“**.

Ist er aktiv, wird bei der Rabattfindung für Verkaufsrabatte der **höchste prozentuale Rabatt** verwendet – die **beste Kondition wird also gegenüber der kundenindividuellen Kondition bevorzugt**. Ist er inaktiv, bleibt die bisherige Rabattfindung unverändert.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Kasse/Zahlungsarten:</strong></mark> Zahlungsarten deaktivieren</summary>

**Kassen-Zahlungsarten** und **Zahlungsarten-Backends** lassen sich jetzt direkt in der Übersicht **deaktivieren** und wieder **aktivieren**. Bisher konnten sie dort nur gelöscht werden – nicht mehr benötigte Einträge können damit erhalten bleiben, ohne weiter zur Auswahl zu stehen.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Fiskalisierung:</strong></mark> Neues Recht „TSE-Einstellungen vornehmen“</summary>

Die Aktionen an der **TSE** (z. B. TSE anlegen, ändern oder außer Betrieb nehmen) waren bisher nur für **Superuser** möglich. Sie sind jetzt über das neue Recht **„TSE-Einstellungen vornehmen“** in der Ressource **Kasse** steuerbar und lassen sich damit gezielt an Rollen vergeben.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Fiskalisierung:</strong></mark> Transaktionen nachträglich stornieren</summary>

Im **Transaktionsjournal** der Fiskalisierung konnten bisher nur **verwaiste** TSE-Transaktionen storniert werden – Transaktionen mit zugehörigem Beleg wurden mit dem Hinweis abgewiesen, dass sie an der Kasse storniert werden müssen.

Diese Einschränkung entfällt. Damit lassen sich auch Transaktionen nachträglich stornieren, bei denen das **Signieren nicht geklappt** hat. Schlägt die Stornierung bei der TSE fehl, wird die Fehlermeldung des Anbieters jetzt ausdrücklich zurückgemeldet.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Dateien und Belege:</strong></mark> PDF-Vorschau mit Zoom</summary>

Die **PDF-Vorschau** und die **Bild-Vorschau** haben eine eigene Zoom-Bedienung erhalten: **Verkleinern**, **Vergrößern** und eine **Prozentanzeige**, über die Du mit einem Klick auf die Ausgangsgröße zurücksetzt. Zusätzlich kannst Du mit **Strg + Mausrad** zoomen und den vergrößerten Inhalt **verschieben**.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Tabellen:</strong></mark> Datensätze mit gleicher ID ausblenden</summary>

In den Einstellungen einer Abfrage gibt es im Reiter **„Allgemein“** die neue Option **„Datensätze mit gleicher ID ausblenden“**.

Ist sie aktiv, wird je ID nur **eine** Zeile angezeigt – das ist für die klassischen Tabellen weiterhin die Voreinstellung. Für **freie VQL-Abfragen** ist die Option standardmäßig **aus**, sodass dort alle Ergebniszeilen sichtbar bleiben, auch wenn sie dieselbe ID liefern.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Datenimport:</strong></mark> Herstellerartikelnummer im Artikelimport</summary>

Der **Artikelimport** kennt jetzt zusätzlich das Feld **Herstellerartikelnummer**. Es kann damit wie die übrigen Artikelfelder in der Zuordnung gemappt und importiert werden.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Datenimport:</strong></mark> Keine Duplikatprüfung bei Adressimporten</summary>

Beim **Import von Adressen** wird die **Erkennung von Adressduplikaten** nicht mehr ausgeführt. Sie war für große Importe der wesentliche Bremsklotz und hat dabei laufend Duplikat-Vorschläge erzeugt.

Außerhalb von Importen – also beim Anlegen und Ändern von Adressen in der Oberfläche – arbeitet die Duplikaterkennung unverändert weiter.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Datenübernahme aus VARIO 8:</strong></mark> Retouren</summary>

Die Migration aus VARIO 8 umfasst jetzt auch das Retourenwesen. Übernommen werden können

* die Belegarten **0700 („Retoureankündigung“)** und **0800 („Warenrücknahme“)**,
* die **Retourengründe** und **Retourengruppen** sowie
* die **Retouren-Details der Belegpositionen** inklusive Retourenkategorie.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Platzhalter:</strong></mark> ObjectIDs und Mandanten-Adresse</summary>

**ObjectIDs** werden in Platzhaltern jetzt korrekt als reine Zahl ausgegeben – bisher wurden sie wie eine formatierte Zahl (mit Tausendertrennzeichen) dargestellt. Allgemein richtet sich die Formatierung eines Platzhalterwerts jetzt nach dem **Datentyp** des Feldes, zum Beispiel bei Währungs- und Dezimalwerten.

Zusätzlich stehen zwei neue allgemeine Platzhalter zur Verfügung: **`attr_hostname`** (die öffentliche Adresse Deines Mandanten) und **`attr_hostname_with_schema`** (dieselbe Adresse inklusive `https://`).

</details>

<details>

<summary><mark style="color:$primary;"><strong>Bestellung:</strong></mark> Einkaufseinheit als Vorgabemenge</summary>

Beim Erfassen einer neuen Position in einem **Einkaufsbeleg** wird jetzt die **Einkaufseinheit** aus der Artikel-Lieferanten-Beziehung als **Vorgabemenge** gesetzt – analog zur Verkaufseinheit im Verkaufsbeleg.

Voraussetzung ist ein **aktiver** Artikel-Lieferant zum Lieferanten des Belegs mit hinterlegter **Einkaufseinheit**. Eine bereits erfasste Menge wird nicht überschrieben.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Bestellung:</strong></mark> Eigene Standard-Lieferadresse bei der Übernahme</summary>

Bei der Übernahme eines Auftrags in eine **Bestellung** wird jetzt automatisch die **eigene Standard-Lieferadresse** als Lieferanschrift gesetzt. Damit liefert der Lieferant an die dafür vorgesehene eigene Adresse, statt an die Hauptadresse des Unternehmens.

</details>

## <i class="fa-arrow-trend-up" style="color:$primary;">:arrow-trend-up:</i> Verbesserungen

<details>

<summary><mark style="color:$primary;"><strong>Auftrag:</strong></mark> „Nicht genügend Bestand“ – Antwort wirkt richtig</summary>

Die Rückfrage bei nicht ausreichendem Bestand hat **vertauscht** reagiert: **„Ja“** hat die eingegebene Menge beibehalten, **„Nein“** sie auf den verfügbaren Bestand reduziert.

Jetzt reduziert **„Ja“** die Menge auf den verfügbaren Bestand, **„Nein“** behält die eingegebene Menge. Der Text ist zusätzlich eindeutiger: **„Der verfügbare Bestand ist nicht ausreichend, es ist nur {Menge} verfügbar. Soll die Menge auf {Menge} angepasst werden?“**

Ist überhaupt kein Bestand verfügbar, bleibt die eingegebene Menge erhalten, statt eine Position mit Menge 0 zu erzeugen. Außerdem wird die Antwort nicht mehr für weitere Positionen wiederverwendet – die Rückfrage kommt je Position neu.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Belegdruck:</strong></mark> Übertrag bei Zwischensummen</summary>

Enthielt ein Beleg eine **Zwischensumme**, war der **Übertrag auf die Folgeseiten zu hoch** – die Zwischensummen-Position wurde mitgezählt. Zwischensummen werden im Übertrag jetzt nicht mehr berücksichtigt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>E-Rechnung:</strong></mark> Beleg-Rabatte und -Zuschläge in ZUGFeRD</summary>

**Beleg-Rabatte und -Zuschläge** wurden beim ZUGFeRD-Export nicht mitgegeben, wodurch exportierte Rechnungen nicht fehlerfrei validierbar waren. Sie werden jetzt als **Abzug** bzw. **Zuschlag** auf Belegebene exportiert – mit dem Steuersatz des höchsten im Beleg enthaltenen Steuersatzes.

</details>

<details>

<summary><mark style="color:$primary;"><strong>E-Commerce-Apps:</strong></mark> Bestellnummer in der Externen ID</summary>

Bei **Shopware 6**, **Shopify**, **eBay** und **ChannelPilot** wird die **Bestellnummer des Shops** jetzt einheitlich beim Anlegen des Belegs in die **Externe ID** geschrieben. Das nachträgliche Setzen der **Externen Nummer** entfällt.

Bei **Amazon** bleibt es unverändert: Die Externe ID enthält die Amazon-Bestellnummer (bei Geschäftskunden ergänzt um die Bestellreferenz), die **Externe Nummer** wird weiterhin für die auf dem Versandlabel anzudruckende **PO-Nummer** genutzt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Finanzen/Lastschrift:</strong></mark> Gläubiger-ID erst beim Senden</summary>

Beim **Starten eines Lastschriftlaufs** wurde die **Gläubiger-ID** der eigenen Bank bereits verlangt und der Lauf ist andernfalls mit einem Serverfehler abgebrochen.

Die Gläubiger-ID wird jetzt erst beim **Senden** der Lastschrift benötigt – dort wird sie an den Zahlungen festgeschrieben und mit ihnen an die Bank übergeben. Fehlt sie, wird nicht versendet und es erscheint eine verständliche Meldung statt eines Serverfehlers.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Finanzen/Zahlläufe:</strong></mark> Sortierung im Grid</summary>

Die Übersichten der **Lastschriften** und **Überweisungen** waren nach dem Anforderungsdatum sortiert. Sie sind jetzt nach **Ausführungsdatum absteigend** sortiert – die aktuellsten Läufe stehen damit oben.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Finanzen/Bankumsätze:</strong></mark> „Nicht relevant“ nur für offene Umsätze</summary>

Ein Bankumsatz konnte ohne Prüfung auf **„nicht relevant“** gesetzt werden – auch dann, wenn er bereits zugeordnet war. Der Status wird jetzt nur noch für Umsätze im Status **„nicht zugeordnet“** gesetzt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Finanzen/Zahlungen:</strong></mark> Kontosaldo in der Übersicht</summary>

In der Zahlungsübersicht wurde der **Kontosaldo** fehlerhaft angezeigt. Der Saldo wird jetzt direkt am Bankkonto mitgeliefert und dadurch korrekt ausgewiesen.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse:</strong></mark> Gesperrte Kassen</summary>

Eine **deaktivierte Kasse** konnte weiterhin ausgewählt werden. Jetzt wird die Auswahl abgewiesen mit dem Hinweis **„Diese Kasse ist gesperrt. Bitte eine andere Kasse auswählen.“**

Zusätzlich ist das Feld **„Aktiv“** im Kassen-Formular nur noch lesend – **Aktivieren und Deaktivieren** erfolgt über die Aktion in der Kassenübersicht.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Kartenterminal:</strong></mark> Laufende Kartenzahlungen</summary>

Solange eine **Kartenzahlung noch am Terminal verarbeitet** wird, kann der Beleg jetzt weder verworfen noch die Zahlungsposition entfernt werden – beides wird mit einem klaren Hinweis auf das betroffene Terminal abgewiesen.

Umgekehrt blockieren **nicht erfolgreiche** Kartenzahlungen (abgebrochen oder fehlgeschlagen) das Kassieren nicht mehr: Als Zahlung zählt eine Terminal-Zahlung nur im Status **erfolgreich**.

Konnte der Beleg nach einer erfolgreichen Terminal-Zahlung nicht gespeichert werden, weist die Kasse ausdrücklich darauf hin: **„Die Zahlung am Terminal ist erfolgt, der Beleg konnte aber nicht gespeichert werden. Bitte den Bon über „Abschließen“ abschließen – die Zahlung nicht wiederholen.“**

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kasse/Kassenabschluss:</strong></mark> Klarer Hinweis bei fehlgeschlagener Berechnung</summary>

Konnten **Abschöpfung und neuer Anfangsbestand** nicht berechnet werden, war nur ein weicher Hinweis zu sehen, dass die Werte möglicherweise nicht aktuell sind.

Jetzt erscheint ein deutlicher Banner mit **„Abschöpfung und neuer Anfangsbestand konnten nicht berechnet werden. Der Kassenabschluss kann im Moment nicht abgeschlossen werden.“** und dem Zusatz **„Die angezeigten Beträge stammen noch vom letzten erfolgreichen Stand. Die gezählten Werte bleiben gespeichert.“** – inklusive Schaltfläche zum **Wiederholen**.

Außerdem wird beim **Abbrechen einer Kasseneröffnung** die bereits begonnene **Fiskalisierungs-Transaktion** storniert, sodass anschließend wieder ein Abschluss möglich ist.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Lager/Kommissionierung:</strong></mark> Sammelkommissionierung mit mehr als 100 Aufträgen</summary>

Bei der **Sammelkommissionierung** wurden nur die ersten 100 Aufträge berücksichtigt. Die Begrenzung ist entfallen – es lassen sich jetzt auch **mehr als 100 Aufträge** in einem Lauf kommissionieren.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Artikel:</strong></mark> Artikel mit Gebinden löschen</summary>

Beim Löschen eines Artikels mit **Gebinden** kam die Meldung **„Es gibt noch keinen Basis-Artikel“**, sodass der Artikel nicht gelöscht werden konnte. Die zugehörigen Artikel werden jetzt in der richtigen Reihenfolge – Basis-Artikel zuletzt – entfernt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Zählerkreise:</strong></mark> Alternative Konfigurationen</summary>

Für **freie Zählerkreise** konnten in der Oberfläche keine **alternativen Konfigurationen** hinterlegt werden, weil die Zuordnung zur Konfiguration nicht mitgeliefert wurde. Das ist behoben.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Lieferbare Aufträge:</strong></mark> Fehlende Aufträge</summary>

Im Menüpunkt **„Lieferbare Aufträge“** fehlten Aufträge. Die Auswertung prüft jetzt gezielt das Leserecht für Verkaufsbelege, statt die Rechte des Aufrufs zu übernehmen – dadurch werden alle lieferbaren Aufträge angezeigt.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Skripte und Workflows:</strong></mark> Dezimal-Zusatzfelder</summary>

In Skripten und Workflows führten **Zusatzfelder vom Typ Dezimal** zu Problemen, weil sie – anders als Währungsfelder – nicht in einen Zahlenwert umgesetzt wurden. Dezimalfelder werden jetzt genauso behandelt wie Währungsfelder.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Einstellungen/Ausgabe:</strong></mark> System-Mail-Vorlage bleibt erhalten</summary>

Angepasste **System-Mail-Vorlagen** wurden bei jedem Neustart mit den Standardtexten überschrieben. Die Texte bleiben jetzt erhalten.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Kommissionierung:</strong></mark> Reports bei fehlenden und zu viel gepickten Artikeln</summary>

Bei **„fehlende Artikel“** wurde ein falscher Report gezogen und bei **„zu viel gepickt“** erfolgte kein automatischer Druck. Ursache war eine falsch gebildete Zuordnung zur Report-Gruppe; sie ist korrigiert.

</details>

<details>

<summary><mark style="color:$primary;"><strong>System/Versionen:</strong></mark> Apps mit Namen und ohne Versionsinfo</summary>

In der **Versionsübersicht** wurden Apps mit ihrem technischen Bezeichner geführt. Sie erscheinen jetzt mit ihrem **Namen** – und werden auch dann aufgelistet, wenn zu einer App keine Versionsinformation abgerufen werden kann.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Lager/Lagerbewegung:</strong></mark> Scan-Protokoll mit Charge und MHD</summary>

Beim Buchen von Lagerbewegungen über den Scanner zeigt das Protokoll jetzt die gebuchte Zeile vollständig an – als **„{Menge} × {Artikel} · Charge/SN {Nummer} → {Ziel}“** bzw. **„{Menge} × {Artikel} · MHD {Datum} → {Ziel}“**.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Datenimport:</strong></mark> Bereich „Dateiinterpretation“</summary>

Die Einstellungen zum Einlesen der Importdatei sind im Regelwerk jetzt im eigenen Bereich **„Dateiinterpretation“** zusammengefasst. Beim Hochladen weist der Dialog zusätzlich deutlicher auf die beiden Wege hin: **„Datei (.txt, .csv) auswählen, per Drag & Drop hinzufügen oder…“** / **„…Zeilen einfügen / bearbeiten.“**

</details>

<details>

<summary><mark style="color:$primary;"><strong>Shopware-6- und Shopify-App:</strong></mark> Sortierung der Attributwerte wird übertragen</summary>

Die im ERP gepflegte **Sortierreihenfolge der Attribute und Attributwerte** kam im Shop nicht an.

* **Shopware 6**: Eigenschaftengruppen werden jetzt mit dem Sortiertyp **„position“** angelegt und übertragen – vorher sortierte Shopware im Storefront alphanumerisch und hat die übergebenen Positionen ignoriert. Zusätzlich wird die Position der Gruppe selbst mitgegeben.
* **Shopify**: Nach dem Produkt-Upload werden die **Optionen und Optionswerte** ausdrücklich in die ERP-Reihenfolge gebracht. Der reine Produkt-Upload ordnet bestehende Optionen nur über den Namen zu und lässt deren Position unverändert.

</details>

<details>

<summary><mark style="color:$primary;"><strong>Shopify-App:</strong></mark> Rabatte im Bestellimport</summary>

Das **Rabatthandling** beim Import von Shopify-Bestellungen wurde überarbeitet.

* Rabatte werden jetzt **immer je Position mit dem von Shopify zugeordneten Betrag** gebucht – nicht mehr als Prozentsatz. Damit stimmen Steueraufteilung und Summen ohne eigene Rundungslogik mit Shopify überein.
* Ein **Bestellrabatt** (Rabatt auf die gesamte Bestellung) wird ebenfalls anteilig auf den Positionen gebucht und zusätzlich als **Kopftext** im Beleg dokumentiert, z. B. **„Shopify-Bestellrabatt "Sommer10" (10 %): 12,34 EUR - anteilig auf die Positionen verteilt“**.
* Als Rabattbezeichnung wird der **Rabattcode** verwendet, sonst der **Titel** des Rabatts.
* **Versandrabatte** sind weiterhin über den vergünstigten Versandpreis abgebildet.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.vario-software.de/vario-cloud-changelog/2026/2026.33.0.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
