> 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.34.0.md). # 2026.34.0 VARIO Cloud 2026.34.0 erweitert OP-Ausgleich und Kassenretouren und verbessert Ausgaberegeln mit Kontaktarten, Adressvorlagen und Auswahlfeldern. {% hint style="info" %} Diese Version steht Dir voraussichtlich **ab dem 03.09.2026** zur Verfügung. {% endhint %} ## Highlight: Standorte – Anschrift, Abgangsland und Unterstandorte VARIO kennt jetzt **Standorte**: eine eigene Stammdatenebene mit **Anschrift**, die Du an **Lager** und **Produktionsaufträge** hängst. Aus dem Standort ergibt sich das **Abgangsland** einer Belegposition – und damit die steuerliche Beurteilung. Sammelrechnungen werden entsprechend **je Abgangsland** getrennt.

Einstellungen/Standorte: Standorte mit Anschrift und Unterstandorten

Unter **Einstellungen → Allgemein → Standorte** verwaltest Du Deine Standorte jetzt als **Hierarchie**: **„Verwalte hier Deine Standorte und weise ihnen Adressen zu. Standorte beeinflussen Belegausgabe und Druckregeln."** * Die Liste zeigt die **obersten Standorte** mit **Bezeichnung**, **Adresse**, **Ort** und **Standard-Standort**. Über den Pfeil klappst Du die **Unterstandorte** auf – beliebig tief. * Die **Adresse** wird nur am obersten Standort gepflegt und gilt für alle darunterliegenden Standorte mit. Ein Unterstandort bekommt deshalb kein Adressfeld: **„Unterstandorte dürfen keinen eigenen Adressbezug haben."** * Die Adressauswahl ist jetzt eine **Suche über die Adressen** mit **Name 1**, **Name 2**, **Straße**, **Hausnummer**, **PLZ** und **Ort**. Bisher standen nur die Adressen des eigenen Mandanten zur Wahl. * Genau ein Standort ist der **Standard-Standort**; er wird am Standort angezeigt, aber nicht dort umgeschaltet. Ein zweiter wird abgewiesen: **„Es darf nur einen Default-Standort geben."** {% hint style="info" %} Existiert noch kein Standard-Standort, wird er bei der Aktualisierung automatisch aus der **Standardadresse des Mandanten** angelegt. Als Bezeichnung wird **Name 1** dieser Adresse verwendet, andernfalls **„Standard-Standort"**. {% endhint %}

Lager: Standort am Lager

Jedes **Lager** hat jetzt ein Feld **„Standort"**. Über den Standort erhält das Lager eine **Anschrift** – die Grundlage für Steuerermittlung, Sammelrechnung und Nachschub über mehrere Standorte. In den Lagerlisten lässt sich der **Standort** als Spalte einblenden. Wird beim Speichern eines Lagers kein Standort gesetzt, trägt VARIO den **Standard-Standort** ein. Die Produktionslager sind dadurch **je Standort** eindeutig statt systemweit: Pro Standort ist je ein **Werkbank-**, **QS-** und **Defekt-Lager** möglich, z. B. mit der Meldung **„Es existiert bereits ein Werkbank-Lager für die Produktion an diesem Standort"**. Das **Ziel-Lager** der Produktion bleibt systemweit eindeutig. {% hint style="warning" %} Bestehende Lager ohne Standort werden bei der Aktualisierung automatisch dem **Standard-Standort** zugeordnet. Wenn Du mit mehreren Anschriften arbeitest, lege zuerst die weiteren Standorte an und ordne die Lager anschließend um. {% endhint %}

Produktion: Standort am Produktionsauftrag

Ein **Produktionsauftrag** gehört jetzt immer zu einem **Standort**. Im Belegkopf siehst Du dazu das Feld **„Standort"**. * Neu angelegte und übernommene Produktionsaufträge erhalten den **Standard-Standort**. * Die **Werkbank-**, **QS-** und **Defekt-Lager** werden passend zum Standort des Auftrags gesucht – nicht mehr systemweit. * Ohne Standort lässt sich ein Produktionsauftrag nicht speichern: **„Ein Produktionsauftrag benötigt einen Standort."** Ist gar kein Standard-Standort vorhanden, meldet VARIO **„Es ist kein Standard-Standort definiert; ein Produktionsauftrag kann nicht angelegt werden."** {% hint style="warning" %} Bestehende Produktionsaufträge ohne Standort werden bei der Aktualisierung automatisch dem **Standard-Standort** zugeordnet. {% endhint %}

Belege: Abgangsland aus dem Standort

Das **Abgangsland** einer Belegposition wird jetzt aus dem **Standort ihres Lagers** ermittelt – über die Anschrift des Standorts. Hat eine Position keinen Lagerbezug oder der Standort keine Anschrift, gilt weiterhin das Land der **eigenen Firma**. Der **Steuersatz** wird damit je Kombination aus **Steuerschema** und **Abgangsland** bestimmt statt immer gegen das Firmenland. Wer aus Lagern in verschiedenen Ländern liefert, erhält damit die richtige Besteuerung je Position. Damit eine Rechnung steuerlich eindeutig bleibt, prüfen **Auftrag**, **Lieferschein** und **Lieferschein-Rechnung** beim Speichern und beim Beenden der Bearbeitung, dass alle Positionen zum gleichen Abgangsort gehören. Andernfalls kommt die Meldung **„Alle Positionen mit Lagerbezug müssen zu Standorten mit derselben Anschrift gehören."**

Belege/Sammelrechnung: Je Abgangsland eine Rechnung

Eine Sammelrechnung darf steuerlich nur Positionen **eines Abgangslands** enthalten. Deshalb werden die Lieferscheine jetzt nach dem **Abgangsland** gruppiert – dem Land der Anschrift des Standorts, aus dem geliefert wurde – und je Abgangsland entsteht eine **eigene Sammelrechnung**. * Im **Sammelrechnungslauf** wird je erzeugter Rechnung ein eigener Eintrag mit der jeweiligen **Anzahl Lieferscheine** geführt. * Beim manuell gestarteten Sammelrechnungs-Job bekommst Du je erzeugter Rechnung eine eigene **Benachrichtigung**. * Lieferscheine ohne Lagerbezug bzw. ohne Standort-Anschrift werden dem Land der **eigenen Firma** zugeordnet.

Lager/Nachschub: Umlagerung über mehrere Standorte

Ware zwischen **Standorten mit unterschiedlicher Anschrift** zu bewegen ist ein Warenverkehr zwischen zwei Adressen – das geht nur über **Belege**. Der Nachschubvorschlag berücksichtigt das jetzt: * Ist in der Picklisten-Vorlage bei **„Durchführung der Umlagerung"** die Option **„Umlagerungs-Auftrag und -Bestellung erstellen"** gewählt, entsteht jetzt **je Standort-Anschrift des Quell-Lagers ein eigener Umlagerungs-Auftrag**. * Bei den übrigen Abschlussarten – **„Picklisten zum Sammeln erstellen"** und **„Nachschubvorschlag drucken und direkt umbuchen"** – werden Quell-Lager mit **anderer** Standort-Anschrift nicht mehr vorgeschlagen. * Bleibt dadurch für ein Ziellager kein passendes Quell-Lager übrig, wird der Vorschlag gar nicht erst erstellt: **„Für Lager {Lager} besteht Nachschubbedarf, aber es gibt kein Quell-Lager mit derselben Anschrift. Eine standortübergreifende Umlagerung ist nur mit der Abschlussart ‚Belege' möglich."** So siehst Du direkt, dass die Vorlage angepasst werden muss.

## Neuerungen

Lager/Kommissionierung: Artikelerfassung und Lagerplatz-Pflicht in der Picklisten-Vorlage

Bisher gab es beim Kommissionieren nur die Wahl zwischen freier Mengeneingabe und „jeder Artikel muss einzeln erfasst werden" – bei **hohen Mengen** war das unpraktisch. In der **Picklisten-Vorlage** steuerst Du das jetzt feiner: im Bereich **„Verarbeitung"** unter **„Weitere Optionen"**. Der bisherige Schalter „Artikel nur durch Scan erfassen" wird durch das Auswahlfeld **„Artikelerfassung"** mit drei Werten ersetzt: * **„Frei"** – keine Einschränkung. Du kannst den Artikel erfassen oder die Menge direkt eingeben. * **„Einmal scannen"** – die Position muss **einmal** über Artikelscan bzw. Eingabe der Artikelnummer erfasst werden; danach ist die **manuelle Mengeneingabe** erlaubt. So bestätigst Du bei hohen Mengen zuerst die Ware und tippst anschließend die Gesamtmenge. * **„Immer scannen"** – die Menge entsteht ausschließlich über die Erfassung der Artikel, eine manuelle Mengeneingabe ist nicht möglich. Greift die Vorgabe, kommt die Meldung **„Manuelle Mengenänderung ist nicht erlaubt"**. Geprüft werden nur Eingaben mit einer Menge **größer null** – die Menge nach unten zu korrigieren bleibt möglich. Bei einem **Verkaufsset**, das nicht als Ganzes kommissioniert wird, zählt die Erfassung der jeweiligen **Komponente**. Neu ist außerdem der Schalter **„Lagerplatz muss immer erfasst werden"**: * Beim Sammeln muss zuerst der **Lagerplatz** erfasst werden, bevor eine Menge gebucht wird – sonst erscheint **„Es muss zuerst ein Lagerplatz erfasst werden"**. Ohne die Option bucht das System weiterhin selbst auf die passenden Lagerplätze. * Zusammen mit **„Lagerplätze vorgeben"** ist der Lagerplatz-Scan damit überhaupt erst möglich; bisher wurde er in diesem Fall mit **„Wenn Lagerplätze vordefiniert wurde, dann ist eine manuelle Lagerplatzauswahl nicht erlaubt"** abgewiesen. * Akzeptiert werden dann ausschließlich die **vorgegebenen** Lagerplätze der aktuellen Position bzw. der Pickliste. Bei jedem anderen Lagerplatz meldet das System **„Es konnte kein zur Pickliste passender Lagerplatz gefunden werden"**. {% hint style="warning" %} Bestehende Picklisten-Vorlagen werden automatisch umgestellt: War „Artikel nur durch Scan erfassen" aktiv, steht **„Artikelerfassung"** anschließend auf **„Immer scannen"**, andernfalls auf **„Frei"**. Auch bereits erzeugte Picklisten werden mitgezogen und behalten damit ihr bisheriges Verhalten. {% endhint %}

Einstellungen/Belege/Parameter: Anzeige der Verfügbarkeit im Beleg

Unter **Einstellungen/Belege/Parameter** legst Du mit dem neuen Parameter **„Anzeige der Verfügbarkeit im Beleg"** fest, auf welcher Grundlage die Lieferbarkeit einer Belegposition angezeigt wird. * **„Für Verkauf (verfügbare Menge, im Standard Bestand - Reserviert)"** – die verfügbare Menge aus Artikel und Verkaufskanal. Das ist die Voreinstellung. * **„Für Lieferung (Bestand - in Kommissionierung)"** – der Bestand abzüglich der Menge, die schon in Kommissionierung ist. Die Einstellung wirkt auf die **farbige Markierung je Position** im Beleg, deren Tooltip **„Vollständig lieferbar"**, **„Teilweise lieferbar"** oder **„Nicht lieferbar"** nennt. Zusätzlich haben jetzt auch Positionen **ohne Bestandsführung** – etwa Dienstleistungen oder Streckengeschäft – eine Lieferbarkeits-Anzeige, und die Verfügbarkeit wird nur noch einmal je Beleg ermittelt statt doppelt. {% hint style="warning" %} Mit der Voreinstellung **„Für Verkauf"** kann die Anzeige im Beleg von der Bewertung bei der **Übernahme in die Kommissionierung** und in **„Lieferbare Aufträge"** abweichen – dort gilt immer die Liefer-Verfügbarkeit. Stelle den Parameter auf **„Für Lieferung"**, wenn beide Angaben übereinstimmen sollen. {% endhint %}

***

Belege/Positionen: Abweichende Artikelnummer als eigenes Feld

Hat ein Lieferant oder Kunde eine **abweichende Artikelnummer**, -bezeichnung oder einen abweichenden **Zusatztext**, wurden diese Werte bisher direkt in die **Positionsfelder** geschrieben – die eigene Artikelnummer aus dem ERP war in der Position damit nicht mehr zu sehen. Jetzt stehen sie in eigenen Feldern daneben. * Die Positionsfelder **Artikelnummer**, **Artikelbezeichnung** und **Artikeltext** behalten die Werte aus dem eigenen Artikelstamm. * Neu dazu kommen **„Abweichende Artikelnummer“**, **„Abweichende Artikelbezeichnung“** und **„Abweichender Artikeltext“**. Gefüllt werden sie aus der **Artikel-Lieferanten-Beziehung** (Einkauf) bzw. der **Artikel-Kunden-Beziehung** (Verkauf) – und nur, wenn die Beziehung **aktiv** ist und die jeweilige Option dort gesetzt ist. * In der Belegmaske erscheinen die abweichenden Werte als **Tooltip** an der Artikelnummer und an der Artikelbezeichnung – nur dann, wenn sie sich vom Positionswert unterscheiden. Der abweichende Artikeltext steht in den **Positionsdetails** als eigenes, nicht änderbares Feld. * Neu ermittelt werden die Werte nur noch, wenn Du den **Kunden bzw. Lieferanten wechselst** oder die Position noch keine Artikelnummer hat. Bereits erfasste Positionen bleiben damit unverändert.

Belegdruck: Abrechnungsübersicht für Anzahlungs-, Abschlags- und Schlussrechnungen

Für Vorgänge mit **Anzahlungs-, Abschlags- und Schlussrechnungen** liefert VARIO jetzt die Daten für eine **Abrechnungsübersicht**. Damit lässt sich auf einem Beleg andrucken, wie der Vorgang abgerechnet ist – welche Belege dazugehören, was schon bezahlt oder verrechnet wurde und was offen ist. Als Datenquelle stehen dafür zwei neue Vorlagen in **Reporten und Abfragen** zur Verfügung. * Die **Übersicht** liefert je Zeile einen Beleg des Vorgangs: **Auftrag**, **Anzahlungsrechnungen**, **Abschlagsrechnungen**, **Teil-, Lieferschein- und reguläre Rechnungen**, **Gutschriften** und **Schlussrechnungen** – jeweils samt Stornos. Sortiert wird in fachlicher Reihenfolge, danach nach **Belegdatum** und **Belegnummer**. * Je Zeile gibt es **Belegnummer**, **Belegdatum**, **Fakturierungsart**, **Netto-** und **Bruttobetrag**, **Währung** und die **Belegartbezeichnung in Mandantensprache**, dazu **„Abrechnungsübersicht: Belegbetrag netto"** / **„… brutto"**, **„… bezahlt"**, **„… verrechnet"**, **„… offen"** und **„Abrechnungsübersicht: Offener Posten"** als Sprung zum OP. * Die **Summen** zum Beleg enthalten **„Abrechnungsübersicht: Auftragswert"**, **„… Anzahlungsrechnungen"**, **„… Abschlagsrechnungen"**, **„… Teil-/Rechnungen"** und **„… Gutschriften"** – jeweils netto und brutto – sowie **„… Betrag dieses Belegs netto/brutto"**, **„… auf diesen Beleg bezahlt"**, **„… an diesem Beleg offen"** und **„… Rückzahlung"** (der nicht verrechnete Anzahlungsüberhang). * Alle Beträge sind in Wirkungsrichtung vorzeichenbehaftet: Rechnungen positiv, **Stornos und Gutschriften negativ**. Aufgenommen werden Belege in den Zuständen **„Gespeichert"**, **„Teilweise übernommen"**, **„Übernommen"**, **„Übernommen (in Bearbeitung)"**, **„Folgebeleg wird bearbeitet"** und **„Storniert"**. Es gilt das Recht **„Verkaufsbelege lesen"**. Ergänzend zählt eine **wieder aufgelöste Verrechnung** nicht länger mit – der auf der Schlussrechnung ausgewiesene **Rückzahlungsbetrag** stimmt damit auch nach dem Auflösen einer Anzahlungsverrechnung.

Retoure: Versender und Rücksendelabel

**Retourenankündigungen** gelten jetzt als sendungsfähige Belege. Damit kannst Du für eine Retoure einen **Versender** nutzen und ein **Rücksendelabel** erzeugen. * Bei der Retourenankündigung werden **Absender und Empfänger vertauscht**: Absender ist die Adresse des Belegs, Empfänger Dein eigenes Unternehmen. * Auch die **Versandkosten-Ermittlung** und der **Hinweis zum Erstellen und Drucken des Versandlabels** greifen jetzt bei der Retourenankündigung. * **Lieferbedingung** und **Versandart** sind dafür **Pflicht**: Fehlt eine der Angaben, kommt an dem Feld die Meldung **„Darf nicht leer sein“**. Bisher war das nur ein Hinweis, der sich übergehen ließ.

Einkaufsbelege: Einkaufspreise nur mit dem Recht „Einkaufspreis lesen“

Das Recht **„Einkaufspreis lesen“** in der Ressource **Preise** wirkt jetzt auch in **Einkaufsbelegen**. Fehlt es, bleiben dort alle Preisangaben leer – bisher waren sie im Beleg und in Abfragen sichtbar. * Betroffen sind im Beleg **„Gesamtpreis - Netto“**, **„Gesamtpreis - Brutto“**, **„Preisanpassungen - Beleg“**, **„Preisanpassungen - Belegpositionssumme“**, **„Vorkassebetrag“** und **„skontierbarer Rechnungsbetrag“**, in der Position **„Preis pro Einheit“**, **„Gesamtpreis“**, **„Nettopreis“** und die Positions-Preisanpassungen sowie die Steuerwerte **„Besteuerbarer Betrag“**, **„Steuerbetrag“** und **„Bruttobetrag“** – jeweils auch in Basiswährung. * In **Abfragen und Tabellen** bleiben die Spalten erhalten, die Werte sind aber nur bei Zeilen aus Einkaufsbelegen leer. Zeilen aus Verkaufsbelegen sind unverändert sichtbar. * Speicherst Du den Beleg ohne das Recht, werden die vorhandenen Preise **nicht überschrieben** – sie bleiben so, wie sie zuletzt gespeichert wurden. * Alle anderen Belegarten sind von der Prüfung nicht betroffen.

Finanzen/Mahnvorschlag: Mahnstufe auswählen

Im **Mahnvorschlag** musste die Mahnstufe bisher als reine Abfrage-Variable eingetippt werden. Jetzt steht dort das Auswahlfeld **„Mahnstufe“**: * **„Egal“** – ohne Einschränkung, * **„Ohne Mahnstufe – noch nicht gemahnt“** – nur Offene Posten ohne tatsächliche Mahnstufe, * **„Mahnstufe {Nummer}“** für jede eingerichtete Mahnstufe, jeweils mit ihrer Beschreibung als Zusatzinfo. Wechselst Du die Mahnstufe, wird die **Auswahl im Grid zurückgesetzt** – so gerät kein Posten aus einer anderen Stufe in den Mahnlauf.

Provisionen: Provisionsbeträge mit Vorzeichen

Unter **Provisionen → Provisionssätze** gibt es vier neue Spalten: * **Provisionierbarer Betrag Netto (mit Vorzeichen)** * **Provisionierbarer Betrag Brutto (mit Vorzeichen)** * **Provisionsbetrag Netto (mit Vorzeichen)** * **Provisionsbetrag Brutto (mit Vorzeichen)** Die neuen Spalten zeigen denselben Betrag wie die bisherigen, bei **Rücksetzungen** aber mit **negativem** Vorzeichen – also bei der Herkunft **„Verkaufsbeleg (Zurückgesetzt)"** und **„Manuell (Zurückgesetzt)"**. Damit ergibt eine **Summe** über die Liste den tatsächlich abzurechnenden Betrag, statt Buchung und Rücksetzung doppelt zu addieren.

Abfragen: Felder aus Unterabfragen und vergleichbare Lagernummer

Manche Abfragen liefern Spalten aus einer **Unterabfrage** – zum Beispiel **„Lagerbestand zum Datum“** mit dem Bestand und dem durchschnittlichen Einkaufspreis zum Stichtag. Zu diesen Spalten gab es in der Feldauswahl kein passendes Feld: Einmal entfernt, ließen sie sich nicht wieder aufnehmen, und die zugehörigen Filter kamen ohne Feldinformation. * Felder aus Unterabfragen stehen jetzt regulär in der **Feldauswahl** – die Ergebnis-Felder als **Spalten**, die Variablen der Unterabfrage als **Filter**. Berücksichtigt werden bis zu fünf Verschachtelungsebenen. * Die **Filter** dieser Felder tragen jetzt ihre Felddefinition und werden damit korrekt angezeigt. * Das Feld **Lagernummer** lässt sich zusätzlich mit **„Größer als“**, **„Größer gleich“**, **„Kleiner als“**, **„Kleiner gleich“** und **„Liegt im Bereich“** filtern – bisher waren nur Text-Vergleiche möglich.

Belegdruck: Hintergrund-Bild für den Report

Belege lassen sich jetzt mit einem **Hintergrund-Bild** drucken – zum Beispiel mit einem hinterlegten Briefpapier, ohne den Report selbst anpassen zu müssen. * Der neue Report-Parameter **„Pfad zu einem Hintergrund-Bild"** legt fest, welches Bild verwendet wird. Ohne Pfad wird nichts gedruckt. * Im Report-Designer steuert im Bereich **Belegdruck** unter **„Allgemeine Report Parameter"** die neue Option **„Hintergrund-Bild drucken"**, ob das Bild ausgegeben wird. Sie ist standardmäßig **aktiv**. * Das Bild wird hinter den Belegunterhalt über die **gesamte Seite** gelegt – über die Seitenränder hinaus und auf das eingestellte Seitenformat skaliert. Auch größere Seitenformate werden dabei vollständig hinterlegt.

Reportdesigner: Neues Ausgabemodul „Produktion“

Für die **Produktion** gibt es jetzt ein eigenes **Ausgabemodul**. Damit lassen sich Reporte für Produktionsaufträge gestalten und ausgeben, statt auf die Belegreporte auszuweichen. * Im **Reportdesigner** erscheint das Modul **„Produktion“** mit einer mitgelieferten **Standard-Reportgruppe**. * Das Modul ist für **freie Reporte** freigegeben – im Ausgabe-Dialog **„Freier Report“** steht **„Produktion“** damit in der Auswahl **„Ausgabemodul“** zur Verfügung. * Ausgegeben wird per **Druck** und per **E-Mail**.

Skripte und Workflows: Adresse aus einer Adressvorlage anlegen

Im **Adress-Service** kannst Du in Skripten und Workflows jetzt eine neue Adresse aus einer **Adressvorlage** aufbauen, statt alle Felder einzeln zu setzen. Die Vorlage lässt sich über ihren **Namen** oder ihre **ID** angeben. Damit übernimmt die neue Adresse dieselben Vorgaben wie bei der Anlage über die Oberfläche – einschließlich der in der Vorlage hinterlegten Kunden-, Lieferanten- und Ausgabedaten. Existiert die Vorlage nicht, wird kein Datensatz aufgebaut.

Kundenportal: Umsatzübersicht, Statusanzeige und Bildtexte

Die **Startseite** des Kundenportals ist neu aufgebaut und zeigt Deinen Kunden jetzt auch deren Umsatz. * Neue Kachel **„Umsatz“** mit dem **Netto-Umsatz des laufenden Jahres**. Gezählt werden **Rechnungen, Abschlags- und Schlussrechnungen sowie Gutschriften** – Aufträge und Angebote zählen nicht mit. * Neue Kachel **„Umsatz nach Monaten“** als Balkendiagramm. Ohne Umsatz erscheint dort **„In diesem Jahr liegt noch kein Umsatz vor.“** * Die Kacheln **„Offener Gesamtbetrag“** und **„Offene Belege“** sind jetzt **verlinkt** und führen direkt in die passende Liste – bei den Belegen gleich auf die offenen. * Die Belegliste hat den Filter **„Nur offene“**. **Belegstatus**, **Status Offener Posten**, **Sendungsstatus** und die **Verfügbarkeit** im Shop werden einheitlich als farbige Status-Marke dargestellt. * Am **Bild** eines Artikel-Listings hinterlegst Du über **„Metadaten bearbeiten“** je **Sprache** einen **Meta-Titel** und einen **Alternativtext**. Der Hinweis im Dialog lautet **„Hier eingetragene Werte überschreiben die DMS-Standardwerte für dieses Portal.“** Der Alternativtext wird im Portal am Bild ausgegeben – auf der Artikeldetailseite als Zeile unter dem Bild, in Kachel- und Tabellenansicht als Tooltip. * Der Sendungsstatus **„Geliefert“** war als „Gelierfert“ geschrieben; das ist korrigiert. Welche Kacheln ein Kunde sieht, richtet sich weiterhin nach seinen **Portal-Berechtigungen**.

Shopify-App: Produktkategorien und Kategorie-Attribute

Die Shopify-App kann jetzt die **Shopify-Produktkategorien** abrufen und in VARIO übernehmen. * Im **Einrichtungsassistenten** gibt es unter **„Basis-Stammdaten“** den neuen Schritt **„Kategorien“** mit der Aktion **„Kategorien importieren“**. * Der Import läuft im Hintergrund mit Fortschrittsanzeige – erst **„Daten abrufen“**, dann **„Daten importieren“** mit **„{Anzahl}/{Gesamt} Hauptkategorien importiert“** bzw. **„{Anzahl}/{Gesamt} Attribute importiert“**. * Die Kategorien landen in einem **Kategoriebaum**, der dem Verkaufskanal zugeordnet wird. Die Bezeichnungen kommen in der **Sprache des Kanals**, sofern Shopify sie in dieser Sprache anbietet. * Zusammen mit den Kategorien werden die **Kategorie-Attribute** samt ihren Werten übernommen. * Am **Listing** gibt es den neuen Reiter **„Kategorie-Attribute“**. Er erscheint, sobald dem Listing eine Shopify-Kategorie zugeordnet ist; dort weist Du je Attribut einen Wert zu. * Ein **planmäßiger Abruf** hält die Kategorien aktuell. Bringt Shopify eine neue Kategorie-Version heraus, werden bestehende Zuordnungen auf die neuen Kategorien umgeschlüsselt.

Shopify-App: Datenabfragen des Produkt-Exports einsehen und anpassen

Die Abfragen, mit denen die Shopify-App die Artikeldaten für den Produkt-Export zusammenstellt, waren fest in der App hinterlegt. Sie stehen jetzt als **VQL-Queries** der App zur Verfügung und lassen sich dort einsehen und – abhängig von der Berechtigung – anpassen. * Erfasst sind die Abfragen für **Artikel- und Listing-Daten**, **Übersetzungen**, **Varianten** und **Variantenattribute**, **Preise** (Standardpreis, Aktionspreis, Staffelpreis, Grundpreis), **Bestand** sowie **Bilder und Dokumente**. * Die Übersicht zeigt je Abfrage **Schlüssel**, **Bezeichnung**, **Beschreibung**, **Nur Lesbar** und **modifiziert**. * Eine angepasste Abfrage hat Vorrang und bleibt bei einem **App-Update** erhalten. {% hint style="warning" %} Die Namen der Ergebnisfelder werden von der App unverändert weiterverarbeitet. Wird ein Ergebnisname geändert oder entfernt, funktioniert der Produkt-Export nicht mehr. {% endhint %}

Shopify-App: „Import erzwingen“ beim Kategorien-Import

Im Einrichtungsschritt **„Kategorien importieren“** gibt es den neuen Schalter **„Import erzwingen“**. Ohne den Schalter läuft der Import nur, wenn Shopify eine **neue Version der Produkttaxonomie** bereitstellt – ist die Version unverändert, endet er ohne Ergebnis. Mit dem Schalter holst Du die Kategorien erneut, auch wenn sich die Version nicht geändert hat. Während ein Import läuft, ist der Schalter nicht änderbar.

Shopware-6-App: Reiter „Varianten“ im Listing

Am **Listing** eines **Variantenhauptartikels** gibt es in der Shopware-6-App jetzt den Reiter **„Varianten“**. Dort steuerst Du für alle Varianten des Artikels in einer Liste, welche im Shop gelistet werden – ohne jede Variante einzeln zu öffnen. * Die Tabelle zeigt je Variante die Spalten **„Aktiv“** und **„Artikelnummer“** sowie die Sprunglinks **„Artikel“** und **„Listing“**. Über **„Alle auswählen“** und **„Alle abwählen“** setzt Du den Schalter für alle Varianten auf einmal. * Der Schalter **„Aktiv“** ist nur im **Bearbeiten-Modus** änderbar. Beim Speichern werden fehlende Listings angelegt bzw. bestehende aktualisiert; Du siehst dazu die Meldungen **„Varianten werden gespeichert – Übertragung an Shopware wird vorbereitet …“** und **„Varianten gespeichert – Übertragung an Shopware eingereiht“**. * Die Übertragung läuft über **einen Sammel-Eintrag** je Hauptartikel. Betroffene Varianten stehen bis dahin auf **„Wartet auf Synchronisierung“**. * Lässt sich eine einzelne Variante nicht übertragen, wird nur sie auf **„Fehler bei der Synchronisierung“** gesetzt und beim nächsten Lauf erneut versucht – die übrigen Varianten gehen trotzdem raus. Listings mit dem Status **„Deaktiviert“** bleiben unberührt. * Ist der Artikelstammdaten-Upload am Verkaufskanal nicht aktiviert, meldet die App **„Transfer deaktiviert: Artikelstammdaten-Upload ist in den Verkaufskanal-Parametern nicht aktiviert“**. Die Reiter **„Stammdaten“**, **„Medien“** und **„Varianten“** sitzen dazu jetzt gemeinsam in der Reiterleiste der App.

Shopware-6-App: Artikel und Bilder nachträglich in die Warteschlange einreihen

In den **Verkaufskanal-Einstellungen** der Shopware-6-App stehen Dir die neuen Bereiche **„Artikel-Übertragung“** und **„Bild-Übertragung“** zur Verfügung. Damit reihst Du auf Knopfdruck alle auf diesem Verkaufskanal **gelisteten Artikel** beziehungsweise alle bereits **übertragenen Artikel mit Bildern** in die **Warteschlange** ein. Gedacht ist das für den **Erst-Export**: Für Artikel, die schon lange unverändert sind, stößt kein Ereignis mehr eine Übertragung an – bisher blieb nur, jeden Artikel einzeln anzufassen. Bereits eingereihte Artikel bleiben dabei unberührt. Während des Einreihens siehst Du den Fortschritt, am Ende meldet VARIO, wie viele Artikel neu eingereiht wurden. Die **Bild-Übertragung** wird nur angeboten, wenn im Verkaufskanal **„Artikelbilder hochladen“** aktiv ist. {% hint style="warning" %} Bei vielen Artikeln dauert die anschließende Übertragung an Shopware entsprechend lange – die Warteschlange arbeitet die Einträge nach und nach ab. {% endhint %}

eBay-App: Bildverwaltung für Listings

Die eBay-App verwaltet jetzt die **Bilder der Listings** in beide Richtungen. Im **Einrichtungsassistenten** ist der Artikel-Schritt dafür in **„Stammdaten“** und **„Bilder“** geteilt. * **„Artikel-Stammdaten importieren“** übernimmt weiterhin Artikel, kanalspezifische Werte und die eBay-Daten am Listing – die **Bilder bleiben dabei außen vor**. * **„Artikel-Bilder importieren“** legt fehlende Bilder im **DMS** an und verknüpft sie mit **Artikel und Listing**; bereits vorhandene Bilder werden nur verknüpft. Am Ende steht **„{Anzahl} Bilder importiert, {Anzahl} übersprungen, {Anzahl} fehlgeschlagen.“** * Voraussetzung dafür ist der im Schritt **„Artikel-Stammdaten“** vorbereitete Import – solange er im ERP nicht ausgeführt ist, gibt es noch keine Listings. * In die andere Richtung werden die Bilder eines Listings **zu eBay hochgeladen**. Ein Listing braucht bei eBay **mindestens ein Bild** – das Entfernen des letzten Bildes lässt sich deshalb nicht übertragen und wird als Fehler gemeldet, statt den Lauf als erfolgreich auszugeben. * Die eBay-seitige Bild-ID wird jetzt an der Datei-Freigabe mitgeführt. Schon übertragene Bilder werden damit als **„Synchronisiert“** ausgewiesen und bleiben nicht auf **„Warten auf Verknüpfung“** stehen. * Weicht im Einrichtungsassistenten die Anzahl der Stammdaten zwischen VARIO und eBay ab, erscheint statt des grünen Hakens ein Hinweis: **„Die Anzahl der Stammdaten in der VARIO Cloud weicht von der bei eBay ab — bitte erneut importieren.“**

Amazon-App: Sammeladresse für alle Bestellungen

Der Bestellimport hat bisher für **jede Amazon-Bestellung eine neue Adresse** angelegt. Im **Bestellabruf** des Amazon-Verkaufskanals kannst Du jetzt eine **Sammeladresse** hinterlegen. * Das neue Feld **„Sammeladresse“** wählt einen bestehenden **Kunden** aus; über den Eintrag springst Du direkt in die Adresse. * Ist eine Sammeladresse gesetzt, werden **alle importierten Bestellungen auf diesen Kunden** gebucht – neue Adressen entstehen nicht mehr. * Die **Käuferadresse** aus der Amazon-Bestellung wird stattdessen in die **Belegadresse** des Auftrags geschrieben: Namenszeilen, Straße und Hausnummer, PLZ, Ort, Land, E-Mail und Telefon. * Angaben der Sammeladresse, die nicht zum Käufer passen, werden dabei geleert: **Anrede**, **Titel**, **GLN**, **Adresszusätze**, **Postfach** und **Region**. * Ohne Sammeladresse bleibt alles wie bisher.

## Verbesserungen

Belege: Positionen in großen Belegen deutlich schneller erfassen

Belege mit vielen Positionen sind beim Erfassen und Speichern **deutlich schneller** geworden. Das Anhängen oder Ändern einer Position kostet jetzt praktisch gleich viel Zeit, ob der Beleg 20 oder 200 Positionen hat. Preise werden dabei nur noch dort neu ermittelt, wo sich an der Position etwas geändert hat. Ändert sich am Beleg etwas, das den Preis beeinflusst – etwa **Kunde**, **Währung**, **Verkaufskanal** oder **Belegdatum** –, werden weiterhin alle Positionen neu bepreist.

Belege: Prüfung auf Einkaufs- und Verkaufsartikel

Positionen, die aus einem **Vorbeleg** übernommen wurden, werden nicht mehr auf das Kennzeichen **Verkaufsartikel** bzw. **Einkaufsartikel** geprüft – sie wurden dort schon geprüft. Wurde das Kennzeichen am Artikel nachträglich entfernt, ließ sich der Folgebeleg bisher nicht mehr speichern und Importe brachen ab. Bei **direkt erfassten** Positionen kommt weiterhin **„Nur Verkaufsartikel sind erlaubt“** bzw. **„Nur Einkaufsartikel sind erlaubt“** – jetzt als Meldung am Feld **Artikel** der betroffenen Position.

Belege: Mengenaufrundung ohne Rückfrage

War die Positionsmenge kein Vielfaches der **Verkaufseinheit**, kam bisher je Position die Rückfrage **„Menge ist kein Vielfaches der Verkaufseinheit“**. Die Rückfrage entfällt. Die Menge wird direkt auf das nächste Vielfache **aufgerundet**, dazu erscheint der Hinweis **„Die Menge wird auf ein Vielfaches der Verkaufseinheit aufgerundet“**. Das gilt in **Angebot**, **Auftrag**, **Lieferschein** und **Lieferschein-Rechnung**.

Belegposition: UVP-Meldung nur noch bei manueller Preisänderung

Bei Artikeln mit **verpflichtendem UVP** erschien die Meldung **„UVP ist verpflichtend. Keine manuelle Änderung erlaubt."** an einer Position auch dann wieder, wenn deren Preis schon früher manuell gesetzt worden war – jeder weitere Speichervorgang lief erneut in die Meldung. Die Meldung kommt jetzt nur noch, wenn der Preis **in diesem Vorgang** tatsächlich manuell gesetzt oder geändert wird.

Belegdruck: Positionsmarkierung bei Alternativ- und Optionalpositionen

Im Angebot wurde die **Kennzeichnung** von Alternativ- und Optionalpositionen nicht gedruckt – die Legende unter den Positionen verwies auf Zeichen, die fehlten. Die Markierung hat jetzt eine **eigene Spalte**. Unter **„Welche Felder sollen gedruckt werden“** heißt sie **„Positionsmarkierung“** und gehört zum Standard-Spaltensatz. Gedruckt wird **„(1)“** für eine Alternativposition, **„(2)“** für eine optionale Position und **„(3)“** für nicht skontier- bzw. rabattierbare Artikel.

Belege: Storno von Rechnungen mit Mahnung

War der Offene Posten einer Rechnung bereits **gemahnt** und der Mahnlauf **festgeschrieben**, ließ sich das **Storno** nicht speichern: Es kam **„Der zugehörige Offene Posten ist bereits bebucht, eine Stornierung ist nicht mehr möglich.“** Reine **Mahnbewegungen** gelten jetzt nicht mehr als Zahlung – sie werden beim Storno automatisch zurückgenommen. Ist tatsächlich Geld eingegangen, auch nur für die Mahngebühr, bleibt das Storno wie bisher gesperrt.

Belege/Streckengeschäft: Rechnungsfreigabe bleibt bei Änderungen erhalten

Im Streckengeschäft verloren Ausgangslieferschein und Auftrag ihre Freigabe **„Streckengeschäfts-Beleg zur Rechnung freigegeben“**, sobald der Eingangslieferschein nur **geändert** wurde – die Rechnung ließ sich dann nicht erstellen. Beim Ändern bleibt das Kennzeichen jetzt erhalten. Zurückgenommen wird die Freigabe nur, wenn nach dem Löschen kein weiterer Eingangslieferschein in der Belegkette übrig ist.

Belege: Rechte während der Belegverarbeitung

Beim Verarbeiten eines Belegs greift VARIO im Hintergrund auf angrenzende Bereiche zu – etwa Offene Posten, Bestand, Lager, Artikel, Preise und Versand. Bisher brauchte der Anwender dafür **eigene Rechte** auf all diese Bereiche, sonst brach die Verarbeitung ab. Diese Zugriffe holt sich die Belegverarbeitung jetzt selbst, nur für die Dauer der Aktion. Die eigentliche Belegberechtigung bleibt unverändert: Wer einen Beleg nicht anlegen, ändern oder übernehmen darf, kann das auch weiterhin nicht. {% hint style="warning" %} Für Benutzer vom Typ **„Limitiert (WMS)“** entfallen dafür die pauschalen Rechte **„Verkaufsbelege erstellen“**, **„Verkaufsbelege kopieren“** und **„Einkaufsbelege erstellen“**. Ansehen, Aktualisieren und Übernehmen bleiben erhalten. Wird eine der entfallenen Aktionen gebraucht, vergib das Recht über eine **Rolle**. {% endhint %}

Belege: Liefersperre beim Kunden wird geprüft

Ist beim Kunden **„Lieferungen blockieren“** gesetzt, ließ sich ein Lieferschein trotzdem ohne Rückmeldung buchen. Beim Buchen eines **Lieferscheins** oder einer **Lieferschein/Rechnung** wird die Liefersperre jetzt geprüft. Liegt eine vor, bricht der Vorgang mit **„Für den Kunden liegt eine Liefersperre vor.“** ab und der Beleg bleibt in Bearbeitung.

Verkaufsmaske/Kalkulation: Werte zwischen Position und Kalkulation

Position und **Kalkulation** haben ihre Werte nicht gegenseitig übernommen: Die Kalkulation startete mit dem Vorgabepreis statt mit dem Positionspreis, und **„Übernehmen“** kam in einer bereits gespeicherten Position nicht an. * Der **„Verkaufspreis“** in der Kalkulation übernimmt jetzt den Preis der Position, solange Du in der Kalkulation nichts geändert hast. * **„Übernehmen“** schreibt Verkaufspreis, Rabatte und Kalkulation jetzt auch in **bereits gespeicherte** Positionen zurück. * Ein Hinweis stellt klar: **„Der hier erfasste Einkaufswert dient ausschließlich der Preisfindung. Er hat keinen Einfluss auf die Marge- bzw. Rohertragsberechnung des Belegs.“**

Belege/Sammelausgabe: Ergebnis wird abgewartet und benannt

Beim Ausgeben mehrerer Belege über **„Belege ausgeben“** wurden Belege als erfolgreich gemeldet, sobald die Ausgabe-App sie angenommen hatte – ob die E-Mail wirklich raus war, stand da noch nicht fest. Der Dialog wartet jetzt das tatsächliche Ergebnis jedes Belegs ab und zeigt es einzeln an. Fehlgeschlagene Belege nennen den Grund. Bleibt ein Ergebnis offen, wird der Beleg entsprechend gekennzeichnet und bewusst **nicht** erneut angestoßen – sonst könnte er ein zweites Mal versendet werden. Beim Versand über **Microsoft 365** gehen die E-Mails eines Postfachs jetzt nacheinander raus und werden bei einer Drosselung automatisch erneut versucht.

E-Mail-Ausgabe: Nur eigene Ausgaben, klare Aussage bei Teilzustellung

Sind mehrere Mail-Apps eingerichtet, hat jede App **jeden** Ausgabe-Auftrag aufgegriffen und den Status am Beleg gesetzt – auch fremde. **Microsoft 365** und **SMTP Mail** verarbeiten jetzt nur noch die Aufträge ihres eigenen Ausgabe-Zugangs. Beim Versand über **SMTP Mail** steht am Beleg außerdem, ob nur **einzelne** oder **alle** Empfänger abgelehnt wurden – mit den betroffenen Adressen. Bricht die Verbindung ab, bevor der Server den Versand bestätigt hat, wird das zur Prüfung gemeldet statt automatisch wiederholt.

Auftrag: Bestandsprüfung mit echter Lieferbarkeit

Die **Bestandsprüfung bei der Auftragserfassung** sah bisher nur den verfügbaren Bestand des Artikels im Lager der Position an. Jetzt zieht sie die **tatsächliche Lieferbarkeit** heran – einschließlich der Mengen vorheriger Positionen desselben Belegs, der Komponenten bei **Baugruppen** und der Mengen, die für andere Aufträge reserviert sind. Auch die Rückfrage ist ruhiger geworden: * Ist **gar kein** Bestand verfügbar, kommt keine Rückfrage mehr, sondern der Hinweis **„Es gibt keinen verfügbaren Bestand. Menge bleibt unverändert.“** Die eingegebene Menge bleibt stehen. * Reicht der Bestand nur teilweise, lautet die Rückfrage **„Der verfügbare Bestand ist nicht ausreichend, es sind nur {Menge} verfügbar. Soll die Menge auf {Menge} angepasst werden?“** * Eine Antwort, die Du im selben Speichervorgang gegeben hast, wird übernommen und nicht erneut abgefragt. Für die Anzeige im Beleg steuerst Du die Grundlage über den neuen Parameter **„Anzeige der Verfügbarkeit im Beleg“**.

Lager/Kommissionierung: Aufträge gehen wieder in die Lieferung

Bei der **Übernahme eines Auftrags in die Kommissionierung** wurden Auftrag und Positionen getrennt bewertet – mit unterschiedlichen Grundlagen und ohne feste Reihenfolge. Dadurch konnte die Übernahme abgelehnt werden, obwohl der Bestand ausgereicht hätte. Jetzt wird die Verfügbarkeit für Auftrag und Positionen **in einem Durchgang** ermittelt, und der Bestand wird **in Positionsreihenfolge** verteilt: Bei mehreren Positionen mit demselben Artikel bedient die vordere Position den Bestand zuerst.

***

Lieferbare Aufträge: Sortierung und schnellerer Aufbau

Die Liste **„Lieferbare Aufträge“** war nach **Belegdatum** absteigend sortiert – die neuesten Aufträge standen oben. Jetzt ist sie aufsteigend nach **Belegdatum** und dann nach **Erstellungsdatum** sortiert, sodass Du die **ältesten** offenen Aufträge zuerst abarbeitest. Außerdem bauen sich die Liste und die aufgeklappten Positionen **deutlich schneller** auf.

***

Lager/Kommissionierung: Meldung bei frei kommissionierbarem Artikel ohne Bezeichnung

Scannst Du beim Packen einen als **„Frei kommissionierbar“** gekennzeichneten Artikel ohne **Bezeichnung**, bricht das ab – die Meldung nannte den betroffenen Artikel aber nicht. Jetzt steht die **Artikelnummer** in der Meldung, beim Scannen wie beim Abschließen der Pickliste.

Datenübernahme aus VARIO 8: Baugruppen und Strecken-Vorgabe

Bei der Übernahme von Artikeln aus VARIO 8 wird die **Streckenlieferung** jetzt nur noch für Artikelarten übernommen, bei denen sie zulässig ist – bestandsgeführte, bestandslose und Dienstleistungsartikel. Bei allen anderen, etwa Baugruppen, steht sie danach auf **„nur Lager“**. Eine V8-Baugruppe, die bei der Verwendung **aufgelöst** wird, wird jetzt als **Jumboartikel** angelegt statt als Verkaufsset. {% hint style="warning" %} Das gilt für neu ausgeführte Datenübernahmen. Bereits übernommene Artikel behalten ihre bisherigen Werte. {% endhint %}

Finanzen/Bankumsätze: Skonto beim Ausgleich Offener Posten

Beim Verbuchen eines Bankumsatzes auf Offene Posten wurde der **Skonto** nicht berücksichtigt. Zahlte ein Kunde unter Abzug von Skonto, blieb je Posten ein Restbetrag offen. Jetzt wird je Zahlungszeile der zum **Valutadatum** gültige Skonto ermittelt, in **„Skonto/Gebühren“** eingetragen und der **„Zu verbuchende Betrag“** entsprechend verringert – der Posten ist damit ausgeglichen. Einen von Dir selbst eingetragenen Skonto und eine bewusste **Überzahlung** lässt VARIO unangetastet.

Offene Posten: Rückerstattung geht an den Zahler

Die **Manuelle Rückerstattung** einer Überzahlung oder eines Guthabens hat die Zahlung mit **der eigenen Bankverbindung** als Empfänger angelegt – das Geld wäre auf das eigene Konto zurückgegangen. Jetzt wird die Rückzahlung an die **Gegenseite der eingegangenen Zahlung** adressiert: IBAN, BIC und Name kommen aus dem Bankumsatz, überwiesen wird von dem Konto, auf dem die Zahlung eingegangen ist. Liegt keine Zahlung vor, greifen **Standard-Bankkonto** und die **Bankstammdaten** des Kunden bzw. Lieferanten.

Auftrag: Anzahlungsforderung beim Auflösen gegengebucht

Beim **Auflösen** eines Auftrags mit **Anzahlung** wurde der zugehörige Offene Posten gelöscht, solange sein Saldo offen war – die Anzahlungsforderung verschwand spurlos. Jetzt wird sie **gegengebucht**: Es besteht keine Forderung mehr, und der **Saldo** trägt den zurückzuzahlenden Betrag. Der Auftrag findet seinen Offenen Posten also auch nach dem Auflösen. Entfernt wird der Posten nur noch, wenn er keine Zahlung trägt. Ist der Offene Posten **manuell abgeschlossen**, wird das Auflösen jetzt abgewiesen: **„Der Offene Posten zum Auftrag ist manuell abgeschlossen. Der Abschluss muss zuerst storniert werden.“**

Finanzen/Lastschrift: Gutschriften vor Lastschrift verrechnen

Die Option **„Gutschriften vor Lastschrift verrechnen“** an der Zahlungsträgervorlage blieb wirkungslos: Verrechnet wurden nur Gutschriften mit der Rückzahlungsart **„Zahlungsverschiebung“** – ein gewöhnlicher Gutschrift-Beleg hat dort gar keinen Wert. Jetzt werden **alle offenen Gutschriften** des Kunden verrechnet, ausgenommen die mit der Rückzahlungsart **„Auszahlung“**. Bleibt danach nichts einzuziehen, meldet der Lauf **„Alle Rechnungen wurden mit Gutschriften verrechnet — kein Einzug notwendig.“**

Finanzen/Banken: Kontoverbindungen bleiben erhalten

Die Verbindung zwischen einem Bankkonto in VARIO und dem Konto beim Bankanbieter ging verloren – schon ein Speichern oder eine Statusprüfung des Bankzugangs löschte die Zuordnung. Das ist behoben: Entfernt wird sie nur noch, wenn Du die Bankverbindung oder den Bankzugang selbst löschst. Beim Abgleich dient jetzt die **Kontonummer** und, wenn keine vorhanden ist, die **IBAN** als Zuordnung – eine IBAN mit Leerzeichen führt nicht mehr zu einem doppelten Konto.

Finanzen/Banken: Klare Meldung bei fehlender Bankverbindung

War eine Bank nicht mit Dir als Benutzer verknüpft, brachen **Umsätze abrufen** und das **Senden einer Überweisung** mit einem technischen Fehler ab. Woran es lag, war der Meldung nicht zu entnehmen. Jetzt prüft VARIO die Verknüpfung vorab und meldet **„Diese Bank ist nicht mit ihnen als Benutzer verknüpft“** – beim Senden einer Zahlung entsprechend, dass zum Bankkonto keine Verbindung besteht. Banken ohne Online-Anbindung sind davon nicht betroffen.

Finanzen/Mahnungen: Entwurfsmahnung ausgeben

Eine Mahnung im Status **„Entwurf“** ließ sich nicht herunterladen und nicht per **E-Mail** versenden – es kam **„Nur eine verbuchte Mahnung kann gedruckt werden.“** Der reine Druck funktionierte, ließ die Mahnung aber unverbucht zurück. **Drucken**, **Herunterladen** und **E-Mail** schreiben eine einzelne Entwurfsmahnung jetzt vorher **fest** und geben sie anschließend aus; Status und Druckdatum werden gesetzt. Die **Vorschau** schreibt nie fest, eine **stornierte** Mahnung kann weiterhin nicht ausgegeben werden.

Belegdruck/Mahnung: Bankgebühren im Druck

In der **Mahnung** und in der **Saldenbestätigung** heißt die Gebührenspalte jetzt **„davon Bankgebühren"** – der Betrag ist im ausgewiesenen Gesamtbetrag also schon enthalten. Zusätzlich wird der Betrag immer **ohne Vorzeichen** gedruckt; bisher konnte dort ein negativer Wert stehen.

Kasse: Negativer Kassenbestand wird verhindert

Barzahlungen und Kassenbuch-Buchungen konnten den Bestand einer bestandsgeführten Kassenzahlungsart ins Minus laufen lassen – es wurde mehr ausgezahlt, als in der Kasse war. Vor dem Abschließen wird das jetzt geprüft und mit **„Der Bestand der Kassenzahlungsart „…“ würde mit … negativ werden.“** abgewiesen. Geprüft werden Kassenquittung, Kassenretoure sowie Einlage, Ausgabe und Entnahme im Kassenbuch. Je Kassenzahlungsart lässt sich festlegen, ob ein negativer Bestand **nie** (Vorgabe), **immer** oder **nach Rückfrage** erlaubt ist.

Kasse: Beträge bei vertikaler Umsatzsteuerberechnung

Stand die **Umsatzsteuerberechnung** auf **„Vertikal“**, kam es an der Kasse bei **Einlage** und **Ausgabe** zu einer Fehlermeldung und zu einem falschen Betrag. Die Beträge stimmen jetzt auch mit vertikaler Umsatzsteuerberechnung – bei Kassenbuch-Einlage, -Ausgabe und -Entnahme, beim **OP-Ausgleich** samt Rücknahme und bei der **Kundeneinzahlung**.

Kasse/Kartenterminal: Zahlungspositionen nach einer Terminal-Zahlung

Wie mit der Zahlungsposition einer **Kartenzahlung** umgegangen wird, richtet sich jetzt eindeutig nach dem Status der Zahlung am Terminal. * Eine **abgebrochene oder abgelehnte** Kartenzahlung wird automatisch **vom Bon entfernt**. Bisher blieb die Zeile liegen und blockierte den Abschluss, selbst wenn Du eine Ersatzzahlung erfasst hast. * Eine **erfolgreich ausgeführte** Kartenzahlung lässt sich **nicht mehr löschen** – sie kann nur über eine **Storno-Zahlungsposition** aufgelöst werden. * Eine **noch laufende** Zahlung bleibt wie bisher gesperrt. Zahlungspositionen ohne Terminal-Zahlung, etwa Bargeld, lassen sich unverändert entfernen.

Kasse/Fiskalisierung: Kassenbuch-Belege werden erst beim Abschluss signiert

Bei **Kassenbuch-Eröffnung**, **-Abschluss**, **-Einlage**, **-Ausgabe** und **-Entnahme** wurde die **TSE-Transaktion** schon beim Anlegen des Belegs eröffnet. Brach der Vorgang ab, blieben im **Transaktionsjournal** stornierte Transaktionen zu Vorgängen zurück, die es nie gegeben hat. Diese Belege werden jetzt erst **beim Abschluss der Erfassung** an die TSE übergeben – abgebrochene Vorgänge erzeugen damit keine TSE-Transaktion mehr. Für **Kassenquittung** und **Kassenretoure** bleibt es beim bisherigen Ablauf.

Kasse: Kassenauswahl lässt sich schließen

Beim Öffnen der Kasse fragt VARIO, welche **Kasse** Du verwenden möchtest. Dieser Dialog trug keinen Titel und ließ sich nicht verlassen: Ein Abbrechen ohne Auswahl öffnete ihn sofort wieder, sodass Du in der Kassenansicht festhingst. Der Dialog heißt jetzt **„Kasse auswählen“** und lässt sich über das **X** schließen. Brichst Du ohne Auswahl ab, verlässt VARIO die Kassenansicht und bringt Dich auf die vorherige Seite zurück – oder auf die Startseite, wenn es keine gibt.

Artikel/Zubehör: Dienstleistungen als Zubehörartikel

Im Artikel-Reiter **Zubehör** ließ sich über **Neues Zubehör** eine **Dienstleistung** auswählen, beim Speichern wurde sie aber abgewiesen. Jetzt ist die Dienstleistung als Zubehörartikel erlaubt – neben bestandsgeführten und bestandslosen Artikeln und Verkaufssets. Damit kannst Du etwa eine Montage- oder Serviceleistung direkt am Hauptartikel führen und über die **Einfügeart** in den Beleg ziehen lassen. Als **Hauptartikel** ist eine Dienstleistung weiterhin nicht zulässig.

Einstellungen/Zählerkreise: Keine verketteten alternativen Konfigurationen

An einem **freien Zählerkreis** lässt sich eine **alternative Konfiguration** hinterlegen. Bisher konnte diese Alternative selbst wieder eine Alternative haben – es entstanden Ketten, deren Ergebnis nicht mehr nachvollziehbar war. VARIO prüft jetzt, dass die als Alternative gewählte Konfiguration **nicht selbst** eine alternative Konfiguration hinterlegt hat. Andernfalls kommt die Meldung **„Die Zählerkreis-Konfiguration darf keine alternative Zählerkreis-Konfiguration haben, wenn sie selbst bereits eine alternative Konfiguration ist.“**

Einstellungen/Reporte: Kopieren eines Reports

Beim **Kopieren eines Reports** übernimmt die Kopie die Dateien des Originals. Wurde die Kopie gespeichert, baute VARIO ihr Template neu auf und überschrieb damit die **Report-Designer-Datei des Originals**. Für kopierte Reporte wird das Template jetzt nicht mehr neu erzeugt. Für Beleg-Reporte galt das bereits, jetzt gilt es für alle Report-Bereiche.

Skripte und Workflows: Aktivieren und Deaktivieren trotz Workflow

War für **Artikel**, **Adressen** oder **Assets** ein Workflow hinterlegt, der vor dem Speichern läuft, ließen sich die Datensätze nicht mehr **deaktivieren** oder **aktivieren** – das Kennzeichen ging beim Zurückschreiben des Workflow-Ergebnisses verloren. Das Kennzeichen wird jetzt mit übernommen. **Deaktivieren** und **Aktivieren** funktionieren damit auch bei hinterlegtem Workflow.

Skripte und Workflows: Entscheidungen öffnen sich wieder automatisch

Bei Workflows mit einer **Benutzer-Entscheidung** öffnete sich der Entscheidungsdialog nicht mehr von selbst – die Kennung des Arbeitsschritts wurde in der gespeicherten Meldung in einem anderen Format abgelegt als in der Schnittstelle, sodass die Oberfläche die Entscheidung nicht mehr zuordnen konnte. Gespeicherte und übertragene Daten verwenden jetzt durchgängig dasselbe Format. Die Entscheidung wird damit wieder automatisch aufgerufen.

Platzhalter: Allgemeine Platzhalter in CRM-Texten auswählbar

In Texten zu **CRM-Aufgaben**, **CRM-Deals** und **CRM-Projekten** fehlten die **allgemeinen Platzhalter** in der Auswahl bzw. Autovervollständigung – eingesetzt haben sie schon immer funktioniert, sie waren nur nicht auffindbar. Jetzt werden **`attr_user`**, **`attr_date`**, **`attr_date_time`**, **`attr_hostname`** und **`attr_hostname_with_schema`** auch dort mit angeboten.

CRM/Projekte: Tatsächlicher Projektzeitraum aktualisiert sich

Der **tatsächliche Projektzeitraum** blieb stehen, wenn eine Aktivität nicht direkt am Projekt, sondern an einem **untergeordneten Vorgang oder Teilprojekt** erfasst wurde. Jetzt wird das oberste Projekt bei jeder Änderung einer Aktivität neu berechnet. **„Tatsächlicher Projektzeitraum (von)“** und **„(bis)“** ergeben sich weiterhin aus dem frühesten und spätesten Startdatum aller Aktivitäten des Projekts und seiner Unterobjekte.

CRM/Projekte: Aufgaben zwischen Swimlanes verschieben

Im **Kanban-Board** mit **Swimlanes** landete eine verschobene Aufgabe nach dem Neuaufbau des Boards häufig an der falschen Stelle. VARIO zählte die Reihenfolge lokal weiter, während sie im Hintergrund bereits neu vergeben wurde – ein zweites Verschieben rechnete dann mit veralteten Werten. Nach jedem Verschieben wird das Board jetzt neu geladen, und solange ein Verschieben läuft, nimmt das Board keinen weiteren an. Die Reihenfolge bleibt damit auch bei mehreren Verschiebungen hintereinander korrekt – sowohl im Kanban-Board unter **Projekte** als auch im **Kanban**-Reiter innerhalb eines Projekts.

Statistiken: Aufbau läuft deutlich schneller

Der Job **„Komplette Statistik neu erstellen“** brauchte bei großen Datenbeständen sehr lange und lief in die Zeitüberschreitung. Er ist jetzt **deutlich schneller** und bricht auch bei großen Datenbeständen nicht mehr ab. Zusätzlich steht der **Fortschritt** im Protokoll – mit Anzahl und Laufzeit je Block und der Dauer je Statistik-Baustein. Damit lässt sich ein langer Lauf mitverfolgen.

Dateien und Belege: Datei-Zuordnungen gelöschter Datensätze

Wurde ein Datensatz gelöscht, an dem **Dateien** hingen, blieb die **Zuordnung** der Dateien bestehen und zeigte auf einen Datensatz, den es nicht mehr gibt. Das Löschen räumt die Zuordnungen jetzt zuverlässig mit ab – über alle Bereiche, an denen Dateien hängen können. {% hint style="warning" %} Mit dem Update werden **bereits vorhandene** Zuordnungen einmalig entfernt, deren Datensatz nicht mehr existiert. Die Dateien selbst bleiben erhalten – nur die verwaiste Zuordnung entfällt. {% endhint %}

Dateien und Belege: Darstellung in der PDF-Vorschau

Die **PDF-Vorschau** stellte manche Belege falsch dar – besonders **eingescannte DMS-Belege**. Ursache waren fehlende Hilfsdateien der Vorschau: **Standard-Schriften**, **Zeichensatz-Tabellen**, **Farbprofile** und die **Bild-Decoder**. Diese Dateien werden jetzt mit ausgeliefert und von der Vorschau genutzt. Betroffen sind die Vorschau in VARIO und im Admin-Center.

Benutzereinstellungen/Sicherheit: Anmeldung nach Passwortänderung und Zwei-Faktor-Einrichtung

Nach den Aktionen **„Passwort ändern“** und **„Zweiter Faktor“** blieben Rückgabewerte in der Adresszeile stehen – die Anmeldung wies das beim nächsten Aufruf zurück, sodass VARIO nicht mehr geladen wurde. Das ist behoben: Nach der Aktion landest Du wieder dort, wo Du warst. Das gilt für die **Benutzereinstellungen** in VARIO ebenso wie im **Admin-Center**.

Apps und Webhooks: Beleg-Webhooks nur für vorhandene Vorgänge

Der Katalog der **Beleg-Webhooks** enthielt jede denkbare Kombination aus **Belegkategorie** und **Belegvorgang** – auch solche, die es fachlich nicht gibt und die nie ausgelöst wurden. Angeboten werden jetzt nur noch die Kombinationen, die im Beleg-Ablauf tatsächlich einen Webhook auslösen; die Liste ist zusätzlich **alphabetisch sortiert**. Eine Registrierung auf eine nicht mehr angebotene Warteschlange lässt sich weiterhin entfernen.

E-Commerce-Apps: Einrichtung registriert keine ungültigen Beleg-Webhooks mehr

Bei der **Einrichtung** der Apps für **Shopware 6**, **eBay** und **Channelpilot** wurden Beleg-Webhooks auf Kombinationen aus Belegkategorie und Belegvorgang registriert, die es fachlich nicht gibt. Die Registrierung lief auf einen Fehler und ließ die Einrichtung scheitern; ausgelöst wurden diese Webhooks ohnehin nie. Diese Registrierungen entfallen. Die tatsächlich genutzten Webhooks – etwa für den **Versandstatus** und für **Verkaufskanäle** – werden unverändert eingerichtet.

Shopware-6- und Channelpilot-App: Bestellstatus beim manuellen Bestellimport

War beim Bestellabruf **„Automatisch importieren“** inaktiv, wurde der **„Bestellübergang nach Abruf“** nicht ausgeführt – der Bestellstatus im Shop blieb unverändert. Zusätzlich wurde nur die erste Abrufseite vorbereitet, und ein zweiter Abruf konnte dieselben Bestellungen doppelt einpacken. Jetzt gilt in beiden Modi dasselbe: Die abgerufenen Bestellungen werden im Shop sofort in den eingestellten Folgestatus versetzt, es werden **alle** offenen Bestellungen abgerufen, und ein erneuter Abruf greift nur die wirklich neuen.

Shopware-6-App: Fehlende Verkaufskanal-Daten werden nachgeladen

Bei länger bestehenden Verkaufskanälen konnten in den zwischengespeicherten Shopware-Daten **Währung** oder **Sprache** fehlen. Folge: Die **Preisübertragung** brach ab, und **Kunden** wurden ohne Sprache übertragen. Abhilfe war nur ein erneuter Durchlauf des Einrichtungsassistenten. Fehlt eine dieser Angaben, lädt die App die Shopware-Verkaufskanäle jetzt selbst nachträglich und arbeitet dann weiter.

Shopware-6-App: Preise und Bestände von noch nicht übertragenen Artikeln

Stand in der **Warteschlange** eine Preis- oder Bestandsübertragung für einen Artikel, der noch gar nicht nach Shopware übertragen war, wies Shopware die **komplette Übertragung** ab – auch die übrigen Einträge des Durchlaufs. Solche Einträge werden jetzt einzeln übersprungen und als **„Ignoriert“** geführt; Bestand und Preis kommen mit der Stammdaten-Übertragung des Artikels mit. Innerhalb eines Durchlaufs werden die **Stammdaten zuerst** abgearbeitet.

Shopware-6-App: Sichtbarkeit beim Artikelimport

Beim **Artikelimport** aus Shopware wurde die **Sichtbarkeit** als Text statt als Stufe gespeichert. Im Listing stand dann der Rohwert „30“ anstelle der Bezeichnung, und beim Rückschreiben ging der Wert in einem Format raus, das der Shop nicht erwartet. Der Import legt die Sichtbarkeit jetzt als Stufe ab – **„Sichtbar“**, **„In Produktlisten ausblenden“** oder **„Nicht sichtbar“**. Bereits importierte Textwerte werden beim Übertragen umgewandelt.

Shopware-6-App: Artikelbilder ohne hinterlegte Dateiendung

Ein Artikelbild wurde bei der Übertragung übersprungen, wenn zur **DMS-Datei** keine **Dateiendung** hinterlegt war. Das trifft Dateien, die ohne Endung im Namen ins DMS gelangt sind – etwa über einen Upload-Link oder einen PIM-Export. War es das einzige Bild des Artikels, endete der Warteschlangen-Eintrag mit der Aussage, es gebe nichts zu übertragen. Jetzt ermittelt VARIO die Endung zusätzlich aus dem **Dateityp** der DMS-Datei und, falls auch der fehlt, aus dem **Dateinamen**. Lässt sie sich auf keinem Weg bestimmen, bleibt nur dieses eine Bild liegen und die Warteschlange nennt den Grund: **„Bild nicht übertragbar: Zu der DMS-Datei lässt sich keine Dateiendung ermitteln …“**.

Shopify-App: Alternativtext überschreibt keine anderen Felder mehr

Beim Speichern des **Alternativtexts** eines Bildes – im Reiter **„Medien“** und beim Medien-Import – wurde die zugehörige Datei-Freigabe komplett ersetzt. Felder, die die App nicht selbst verwaltet, gingen dabei verloren, zum Beispiel ein in VARIO gepflegter **Meta-Titel**. Die Änderung wird jetzt auf den bestehenden Stand aufgesetzt statt ihn zu ersetzen. Was Du selbst setzt, gilt – ein geleerter Text wird also weiterhin geleert.

Shopify-App: Gelöschte Preise und entfallene Aktionspreise

Die Shopify-App bekam bisher nur mit, wenn ein **Artikelpreis** angelegt oder geändert wurde – nicht, wenn er **gelöscht** wurde. Das ist behoben; die Anmeldung erfolgt beim Update der App für alle Verkaufskanäle. Zusätzlich wird der **Vergleichspreis** in Shopify jetzt geleert, wenn der **Aktionspreis** in VARIO entfällt. Bisher blieb dort der durchgestrichene alte Preis stehen.

E-Commerce-Apps: Fehlerdetails in der Warteschlange aufklappen

In der **Warteschlange** der Apps war die Schaltfläche zum Aufklappen der Fehlerdetails vertauscht: Gab es einen Fehler, war sie gesperrt – gab es keinen, ließ sie sich anklicken und zeigte nichts. Jetzt lässt sich die Zeile genau dann aufklappen, wenn eine Meldung hinterlegt ist. Das gilt für **Shopify**, **Shopware 6**, **Amazon**, **eBay** und **ChannelPilot**.

--- # 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.34.0.md?ask=&goal= ``` `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.