Fortlaufende Änderungen Buchhaltung 2025 Stand 31.12.2025
-----------------------------------------------------------------------------
31.01.25: AGABDA - neue Listenfunktion ("elektron. Provisionsabrechnung")
Das Sondermodul AGABDA dient dazu, um provisionsrelevante Daten zusätz-
lich zu den Programmen wie DB/AGINKA zu exportieren. Es kann damit eine
Datei je Vertriebspartner und Abrechnungsperiode (i.d.R. einmal monatl.)
erzeugt werden, um dessen Midoffice-Anwendung zu unterstützen.
Im AGABDA selbst wurde neu eine Listenfunktion geschaffen. Mithilfe die-
ser Funktion kann nun eine Liste mit Vorgängen erzeugt werden, die vom
AGABDA erkannt und verwaltet wird.
Details entnehmen Sie bitte der AGABDA-Doku. Die Listenfunktion dient
eher der Analyse von AGABDA-Daten. Sollte es Anforderungen an ein an-
deres Format bzw. andere Struktur geben, prüfen wir gerne die Machbar-
keit und den Aufwand.
(Programm: AGABDA / Doku: AGABDA-DOKU / #35710)
----------------------------------------------------------------------------
07.02.25: LZN (LZNEU): Lieferanten-Zahlungen / geändertes Menue
Im LZN, Punkt ZUORDNUNG DER ZAHLUNGSTRAEGER ZUR BANK (3) wurde nun ein
erleichterter Absprung im Feld <LFD> geschaffen ("E" = Ende), wenn man
einzelne Positionen nach Ansicht der Vorschlagsliste bearbeitet hat:
...
ZUORDNUNG DER ZAHLUNGSTRAEGER ZUR BANK 3
ZUORDNUNG DER FORMULARE / BEGLEITLISTEN 4 / 4B
DRUCK: S* S- C C- U* U- A* A- 5
BGL : S S- C C- U U- A A- 6
SAMMELAUFSTELLUNG UEBERWEISUNGEN / SCHECKS 7
UEBERWEISUNGEN IN BANDDATEI UEBERTRAGEN 8
UEBERNAHME IN DIE BUCHHALTUNG 9
+------------------------------------------------------------+
! !
! ZUORDNUNG DER ZAHLUNGSTRAEGER ZU DEN BANKEN: !
! -------------------------------------------- !
! !
! ZAHLUNGSART WAEHRUNG LIEFER/TYP LFD (E) BANK ! <<
! U _1 EUR 991820 ____ ____56 U __ !
! 56 !
+------------------------------------------------------------+
(Programm: LZNEU / Doku: LZN-DOKU / #44362)
----------------------------------------------------------------------------
17.02.25: KODEF - LESE/SCHR-Funktion
Das Sondermodul KODEF dient dazu, beim Versand von Kontoauszügen per
E-Mail bzw. Fax aus den Programmen DTSEPA, BANDCH, DB/DTAIZ individuellere
Dokumente zu erzeugen. Im KODEF kann man dazu entsprechende Bausteine
definieren.
Im KODEF selbst wurde neu eine LESE und SCHReibe-Funktion ermöglicht, mit
denen man diese Definitionen exportieren und importieren kann. Diese
Funktion kann genutzt werden, wenn zwischen verschiedenen logischen Um-
gebungen kopiert wird oder wenn eine Definition gesichert werden soll,
bevor daran Änderungen stattfinden.
Details entnehmen Sie bitte der KODEF-Doku.
(Programm: KODEF / Doku: KODEF-DOKU / #38749)
----------------------------------------------------------------------------
23.04.25: DKDEF - Sortierfunktion
Das Sondermodul DKDEF dient dazu, die Ausdrucke und Ausgaben aus dem
DK (Druck Konten/Salden) definierbar zu machen. Vorteil: damit ist es mög-
lich, diverse Einzelinformationen so zu strukturieren, dass sie dann z.B.
in Excel einfacher weiterzuverarbeiten sind.
Beispiel:
#+ms
BUHALISTE DEFINIEREN: LISTEN-TYP: WBS_ TT.MM.JJ
HH:MM
FELD POS L FELD POS L FELD POS L
Mandant _1 _2 Gegenkontonr. _5 10 Zusatztext2 __ __
Buchungsdatum _2 _8 Gegenktotext __ __ Zusatztext3-Art __ __
Journalnummer _3 _8 Gegenktoliefert __ __ Zusatztext3 __ __
Rechnungsnr. __ __ Gegenktobetrag _7 12 Zusatztext4-Art __ __
Erstelldatum __ __ Gegenktoabstimm. __ __ Zusatztext4 __ __
Kostenstelle __ __ Gegenktosternid 12 10 Fw-Betr-Konto __ __
Kst.-Bezeichnung __ __ Gegenktokonzern __ __ FW-Betr-Gegenkto __ __
Buchungstext 10 30 Vst/Mwst-Kennz. __ __
Währung __ __ Vst/Mwst-Ktonr. _8 12
Umsatzkennz. __ __ VMktotext __ __
Bearbeiter __ __ VMktobetrag _9 12
Kontonummer _4 10 VMktoabstimm. __ __
Kontotext __ __ Fremdwähr-ISO __ __
Kontoliefertyp __ __ FW-Betrag __ __
Kontobetrag _6 12 FW-Butext __ __
Kontoabstimmkz. __ __ Zusatztext1-Art __ __
Kontosternid 11 10 Zusatztext1 __ __
Kontokonzern __ __ Zusatztext2-Art __ __
Enter = speichern, K = Kopftexte, V = Vorschau ___
#+me
In o.g. Beispiel werden einzelne Teile der Informationen zu Journalsätzen
selektiert und spaltenweise angeordnet. Bei Vorhandensein und Nutzung des
Moduls können diverse LISTEN-TYPen definiert werden und im DK genutzt wer-
den.
Neu: "Vorschau"
Gibt man nun "V" (= Vorschau) im Haltefeld einer DKDEF-Definition ein, so
sortiert das Programm die bisher gewählten Journal-Informationen unter-
einander:
#+ms
BUHALISTE DEFINIEREN: LISTEN-TYP: WBS_ TT.MM.JJ
VORSCHAU: HH:MM
FELD POS L FELD POS L FELD POS L
Mandant _1 _2
Buchungsdatum _2 _8
Journalnummer _3 _8
Kontonummer _4 10
Gegenkontonr. _5 10
Kontobetrag _6 12
Gegenktobetrag _7 12
Vst/Mwst-Ktonr. _8 12
VMktobetrag _9 12
Buchungstext 10 30
Kontosternid 11 10
Gegenktosternid 12 10
#+me
Somit überblickt man die getätigten Teile und könnte ggf. ergänzen, korri-
gieren, usw.
(Programm: DKDEF / Doku: DKDEF-DOKU / #44854)
----------------------------------------------------------------------------
06.05.25: DK (KDRUKT) - weitere Option zur Übergabe nach Excel
Im DK, Unterpunkt "S" (SALDEN) gibt es eine weitere Eingabemöglichkeit:
#+ms
*** SALDEN ***
AUSDRUCK ERFOLGT VOM 01.01.JJ BIS 31.12.JJ
--------------------------------------------------
(DE)CKBLATT: N VORSCHUB: N SAMMEL: N
KONTEN VON/BIS ________ ________
AG-KETTE _____ __
ALLE BUCHUNGEN = 1, OFFENE POSTEN = 2 1
BEST.STERNFELD / BEST.STERNFELD NICHT __________ __________
GEGENKONTENKLASSE (EB-KONTEN/ANDERE) __
BESTIMMTE KOSTEN-STELLE? (ALLG. = ^,*) ______ ______ - ______
UMSATZ (TABELLE) / LIEFERTYP / (S,H)/E _ / _ _ _ _ / _ / _
KTO-TYP/AG-BEM (J,N,D) __ __ __ / _
ALTERS-STRUKTUR _ ____
AUSDRUCK SALDO = 0.00 / SALDO-SALDO OP _ _ _
MONATS-SALDEN ? (J,N) / VERKEHRSZAHLEN? _ _ E <<<<
#+me
Im unteren Teil in der Zeile MONATS-SALDEN/VERKEHRSZAHLEN gibt es am Ende
der Zeile ein weiteres einstelliges Feld (letztes Eingabefeld der Zeile).
Die Eingabe "E" in diesem Feld bewirkt, dass Kontonummer/Gegenkontonummer/
VSt/MwSt-Kontonummer bei Nutzung des Journal-Exports (DRUCKEN = D, Modul
BLKSAP) nicht wie üblich exportiert wird, stattdessen im Excel-TEXT-For-
mat.
Beispiel Konto 1200:
... ;1200; ... (übliche Ausgabe)
... ;="1200"; ... (Excel-TEXT-Format)
Im genannten Feld wird nur der Eintrag "E" wie beschrieben abgearbeitet.
Im regulären Ausdruck (also kein BLKSAP-Export) hat das Feld keine Aus-
wirkung.
Ziel der Erweiterung soll sein, dass eine alphanum. Kontenspalte so in
Excel besser verarbeitet werden kann (Sortierung).
(Programm: KDRUKT / Doku: DK-DOKU / #38111)
----------------------------------------------------------------------------
21.05.25: C-Programm - neues Feld <RECHNUNGSDATUM>
Anforderung: "Da unsere Einkaufskonditionen mehrheitlich lauten, dass die
Rechnungen der tourist. Leistungsträger 4 Wochen nach Rechnungsstellung
fällig sind (unabhängig vom Reisedatum), soll das Rechnungsdatum des Lei-
stungsträgers als Ausgangslage zur Berechnung der Fälligkeit genutzt wer-
den."
Entsprechend der o.g. Anforderung wurde ein neues Feld im C-Programm ge-
schaffen:
RECHNUNGS-DATUM (Zeile 7)
Fehlwert (leer): Berechnung auf Basis Reisedatum
Will man stattdessen eine Zahlung an den Kreditor in Relation zu seiner
Rechnungsstellung leisten und das Reisedatum ist nicht relevant, so kann
man in diesem Feld das Rechnungsdatum des Lieferanten eintragen. Die
Fälligkeitstage aus dem LS finden hier auch ihre Anwendung.
Das vorgeschlagene Fälligkeitsdatum kann bestätigt oder überschrieben,
nicht aber gelöscht werden.
Details entnehmen Sie bitte der J-Doku.
(Programm: JOURC / Doku: J-DOKU / #43343)
----------------------------------------------------------------------------
21.05.25: HOLIBU - neues Feld <Rech-Datum>
Anforderung wie oben: kreditorische Abrechnung nach Rechnungsdatum des
Lieferanten - statt Reisedatum
HOLIBU - Feld <Rech-Datum> (unten links)
Fehlwert (leer): Buchung erfolgt auf Reisedatum
"J": es wird nicht auf Reisedatum sondern auf Rechnungsdatum gebucht.
Die Fälligkeit aus LS wird berücksichtigt.
Details entnehmen Sie bitte der HOLIBU-Doku.
(Programm: HOLIBU / Doku: HOLIBU-DOKU / #43343)
----------------------------------------------------------------------------
26.05.25: DTAUSZ: CAMT-Format mit neuer Variante
Aufgrund einer Kundenanfrage gibt es im DTAUSZ (Einlesen der Kontoauszug-
Daten) in der Parameter-Sektion eine weitere Variante:
3: "Account Servicer Reference" wird nicht in den WBS-internen Verwen-
dungszweck in der Sektion "Manuelle Bearbeitung" übertragen (die Bank-
interne, bankeneigene Referenz wird im Verwendungszweck ignoriert und
der VWZ somit im DTAUSZ-4 "lesbar").
Hintergrund: Banken ersetzen zunehmen das MT 94x-Format und liefern statt-
dessen XML camt.05x. Zum Teil liefern die Banken Inhalte, die nicht ein-
deutig sind und die Anzeige im Verwendungszweck im DTAUSZ-4 ("Manuelle Be-
arbeitung") relevante Teile nicht sichtbar machen. Mit dieser Variante "3"
wird die "Account Servicer Reference" ignoriert und der für den Anwender
relevantere Teil des Verwendungszwecks darstellbar.
Da Bankenformate nur bedingt einem fixen Standard in jedem Feld entspre-
chen, sind weitere Varianten u.U. nötig und realisierbar. Sollte Bedarf
bestehen, kontaktieren Sie bitte den WBS Blank Support.
(Programm: DTACAM / Doku: DTAUSZ-DOKU / #47816)
----------------------------------------------------------------------------
02.06.25: DTAUSZ: Kostenstellenbildung bei speziellen GVC
In der DTAUSZ-Sektion "Zuordnung Buchungsarten" (Menuepunkt 8) gibt es
ein neues Feld "Kost".
Mit diesem Feld ist es möglich, einem "Geschäftsvorfall-Code" (GVC) im
Datensatz der Bank eine speziellen Kostenstelle zuzuordnen. Drei Vari-
anten sind vorgesehen:
- leer: Default-Kostenstellenbildung (Bank-Kennz./LFD Auszug/Zahlart)
- Eintrag einer festen, definierten Kostenstellen für diese Buchungs-
art (GVC)
- Eingabe "*": sofern im Kontenplan des "G-Kto." eine Kostenstelle ein-
getragen ist, wird dieser Wert als Kostenstelle verwendet (sonst wie
leer/Default). D.h. findet das DTAUSZ bei diesem GVC trotz "*" keine
KST im Kontenplan, gilt Default: KST: Bank-Kennz./LFD Auszug/Zahlart
(Programm: DTAUSZ / Doku: DTAUSZ-DOKU / #48529)
----------------------------------------------------------------------------
11.07.25: Kreditkarten-Clearing mit Computop: Merchant-ID
WBS-Kunden werden u.U. bei der Umstellung des PSP "nexi" (vormals:
Concardis) zum Anbieter Computop (CT) neue Merchant-IDs mitgeteilt.
Die neue Merchant-ID weist u.U. einen Präfix auf, der die Feldlänge
der Merchant-ID deutlich verlängert.
Wurde bislang im FB-K das Feld PSPID (Zeile 19) dafür genutzt, hat WBS
nun ein Möglichkeit geschaffen, eine überlange Merchant-ID auf zwei
Felder im FB-K aufzuteilen. Dazu erfolgt die Eingabe in beiden Felder,
d.h. für die Merchant-ID werden PSPID und PSWD hintereinandergehängt.
Bsp. MOTO:
19 PSPID : WBSTest________
20 PSWD : Moto___________
Die Merchant-ID "WBSTestMoto" wird auf Zeile 19+20 aufgeteilt und auto-
matisch in der Übergabe an Computop zusammengefügt.
Variante eCommerce:
Nach Eingabe "W" im Haltefeld des Provider CT (Computops) erfolgt auch
hier die Aufteilung auf zwei Felder:
Währung : !I_
Vertragsnr. : ______________________________
Buchungs-Kto. : ________ Prov.-Kto: ________
2. Buchungs-Kto: ________ Term.-Nr : _
PSPID : WBS____________
PSWD : Test___________ _
In der Übergabe wird dann daraus "WBSTest" als Merchant-ID.
(Programme: FIRMA2/KKTRAN / Doku: TPKK-DOKU / #49389)
----------------------------------------------------------------------------
20.08.25: STERN-ID/Stern-Historie: ID bei Generalumkehr
Das KTOSNOK-Modul für die Stern-Historie im Journal wurde erweitert.
Anforderung: "Wenn eine Buchung im Journal storniert wird, greift die
im BUPARA festgelegte Abarbeitung (GENRALUMKEHR J/N), die Buchung wird
im Hintergrund storniert und beide Buchungen erhalten ein Abstimmkenn-
zeichen "G". Wäre es möglich, für das "G" eine (STERN-)ID zu vergeben,
damit das "G" nicht einseitig entfernt werden kann? Eine Löschung wäre
dann nur für eine ganze ID und beide Posten möglich. Die eigentliche
Funktion soll unverändert erhalten bleiben."
Diese Anforderung wurde nun umgesetzt. Die neue Funktion greift ab dem
Zeitpunkt des Einspielens.
Einfaches Beispiel:
01 Konto 4711 Stern-id 20451 TT.MM.JJ XYZ KJOURS TT.MM.JJ Seite 1
Datum Lfd * SB Beleg Text Rech-nr . EUR
--------------------------------------------------------------------------------
TT.MM.JJ 10 K G WFA KS4711 RM#50550 1234567 -222,00 H
TT.MM.JJ 9 K G WFA KS4711 RM#50550 1234567 222,00 S
01 Konto 1000 Stern-id 20452 TT.MM.JJ WFA KJOURS TT.MM.JJ Seite 1
Datum Lfd * SB Beleg Text Rech-nr . EUR
--------------------------------------------------------------------------------
TT.MM.JJ 10 G G WFA KS4711 RM#50550 1234567 222,00 S
TT.MM.JJ 9 G G WFA KS4711 RM#50550 1234567 -222,00 H
(Programme: KJOURS/KDRUKT / Doku: KTOSNOK-Doku / #50550)
-----------------------------------------------------------------------------
29.10.25: BUIMP: automatischer Filetransfer auch in den Varianten 1 + 2
Das Modul BUIMP (Import von Datensätzen in das Journal) wurde dahingehend
erweitert, dass nun auch bei den Importvarianten 1 + 2 ein automatischer
Filetransfer nutzbar ist.
Wird also die Parameter-Abfrage "FTF" mit "J" beantwortet, so gilt:
- im Feld "Pfad Import-Datei" wird nur der eigentl. Dateiname erfasst
(nicht Pfad/Verzeichnis)
- das WBS-Script (gtbuimp) sucht die eingegebene Datei im Download-
Ordner, der im WBSTN des Users eingestellt ist
- die Datei wird dazu im ftf-Verzeichnis eingelesen (automatisch)
- durch "Übernahme" wird die Datei eingelesen
- die Datei wird im ftf-Verzeichnis nicht gelöscht (ggf. bei zukünfti-
gen Download überschrieben)
Wird die Parameter-Abfrage "FTF" mit "N" beantwortet, so ist im Feld
"Pfad Import-Datei" der Pfad plus Name der Importdatei einzutragen und
es findet eben kein Filetransfer statt.
(Programm: BUIMP / Doku: BUIMP-DOKU / #42093)
----------------------------------------------------------------------------
15.11.25: Kreditkarten-Clearing mit Computop:
referenzierte Gutschrift
Im Zuge der Umstellung vom PSP "Nexi/Concardis" zu Computop für das
Clearing der Kreditkartenzahlungen, hat Computop auf das Thema "refe-
renzierte Gutschrift" hingewiesen.
Diese Variante soll dafür sorgen,
- dass Refunds reibungslos abgewickelt werden können,
- dass es zu weniger Rückfragen in Verbindung mit den Endkunden kommt und
in Summe die Reservierungs-Abteilung beim Veranstalter entlastet wird.
Hinzu kommt, dass (soweit WBS Blank es einschätzen kann), Computop den
Merchant/Veranstalter mit geringeren Kosten belastet.
Grund: "Gutschriften werden als teure CREDIT-Transaktion eingereicht,
die gesondert abgerechnet werden."
Um diese Funktion nutzen zu können, gelten folgende neue Einträge im
FB-K, Abkürzung "CT" (Computop), Feld "TCP/IP-Var.":
bereits bekannte Verfahren:
1 = Computop mit PSD2
2 = Computop (Test) mit PSD2
nun neu:
! 3 = Computop mit PSD2 und referenzierte Gutschrift !
! 4 = Computop (Test) mit PSD2 und referenzierte Gutschrift !
Bevor man den Eintrag im FB-K macht, muss man sicherstellen, dass im
Script "computop.sh" Folgendes in die Abfrage des Types eingebaut wird:
elif Ä "[buaend25.html]" = "R" Ü
then
URL="https://www.computop-paygate.com/credit.aspx"
(Programm: KKTRAN / Doku: TPKK-DOKU / #50575)
----------------------------------------------------------------------------
03.12.25: Zahlungsverkehr Schweiz (ISO20022)
Der Zahlungsverkehr mit Schweizer Banken unterliegt speziellen Bedingungen
und Routinen. Im Zuge der ISO20022-Umstellung (globaler Standard für die
Finanznachrichtenübermittlung) wurden nun auch Anpassungen im debito-
rischen Zahlungsverkehr in den WBS-Programmen vorgenommen.
Vorab: selbst wenn es im Zahlungsbereich ISO-Normen gibt, kann es rele-
vante Unterschiede zwischen einzelnen Banken geben. Maßstab für die hier
beschriebenen Erweiterungen ist die Commerzbank. Sollte Ihre Hausbank
die Exportdaten aus dem WBS-Programm nicht akzeptieren, prüfen wir gerne
bankenspezifische Anpassungen (in Angebotsform).
Realisiert wurden (COBA-Spezifikation, Schweizer ISO20022-Version):
- pain.008.001.02 (Lastschrift) und
- pain.001.001.03.ch.02 (Überweisung)
Für die Umsetzung hat sich WBS entschieden, ein neues Programm (SEPCC)
zu entwickeln, dass das SEPAC ersetzt.
Es handelt sich um eine Adaptionen der Schweizer LSV+/DTA-Verfahren. Es
gibt keine Mandate/Mandatsverwaltung im SEPA-Standard. Stattdessen werden
LSV+-ID, BDD-ID, ESR-Teilnehmernummer etc. verwendet.
Die Schnittstelle ist wie bisher von allen Zahlprogrammen ansteuerbar,
sofern
- im FB-D (PARAMETER DATENTRÄGERAUSTAUSCH), INLAND die Spalte PROG. mit
"SEPCC" gefüllt ist und
- im benutzten Bankkürzel im FB-1,B die Felder LSV+-Abarbeitung gefüllt
sind.
Es werden jeweils getrennte Dateien erstellt für Zahlart und Währung:
LSV-CHF, LSV-EUR, GUT-CHF, GUT-EUR. Weitere Infos bzgl. stammdatenseiti-
ger Voraussetzungen und Name/Struktur der XML-/Bankdatei entnehmen Sie
bitte dem SEPCC-Kapitel der DTSEPA-Doku.
Programme: SEPCC/KBUZAH/PDRUZ/SEPAC/TBANK/ZAHLU /
Doku: SEPA-Doku / #2578
----------------------------------------------------------------------------
Diese Dokumentation wurde erstellt von der WBS Blank Software GmbH