Selbst erstellte Belegart wird beim Druck als E-Rechnung behandelt

TSP

Neues Mitglied
Hallo zusammen,
wir haben bei uns die Sage Version 9.0.8.2 im Einsatz.
Eine eigene Belegart "Lageranfrage" mit dem Kennzeichen "VFL" konnte bisher immer problemlos mit dem im AppDesigner erstellten Bericht ausgedruckt werden.
Seit dem Update mit Einführung der E-Rechnung, können wir diesen Beleg nur mit Workaround als Infodruck ausdrucken.
Ansonsten das gleiche Bild wie bei einer E-Rechnung (Drucken mit Druckerauswahl ausgegraut, Ausgabe E-Rechnung per Mail greift).

Hat jemand eventuel das gleiche Problem oder eine Idee wie wir das bei uns lösen können?

Vielen Dank schonmal !
 
Leider ja.
SAGE hat die Funktion von Druckprozess- Varianten mit der 9.0.8 "zerstört".
Angeblich wir es erst mit der 9.0.9 wieder funktionieren.

Bei den Belegen ist primär der 2. Buchstabe des Belegkennzeichen entscheidend

wenn 'P' dann Angebotsbelege
wenn 'R' dann RahmenvertragVK
wenn 'V' dann Auftragsbelege
wenn 'L' dann Lieferbelege
wenn 'F' dann Rechnungsbelege
wenn BKZ='COL' dann Warenbewegungsbelege (intern)


Wenn der 2. Buchstabe nicht in der Tabelle aufgeführt ist,
entscheidet die höchste Gleichgewichtswirkung, die in KHKVKBelegarten gesetzt ist, also GGBestellt, GGGeliefert, GGBerechnet.

wenn GGBerechnet<>0 dann Rechnungsbelege
wenn GGGeliefert<>0 dann Warenbewegungsbelege
wenn GGBestellt=0 dann Angebotsbelege

SAGE meinte, wenn man im AppDesigner den Bericht rptVKRechnung.. kopieren und unter einem anderen Namen speichern würde, der das Wort "Rechnung" nicht enthält,
- also etwa rptVKInvoice...
dann würden wieder die Einstellungen bei den Druckprozessen greifen.

Getestet habe ich das noch nicht.

Ansonsten erkennt Sage alles nach der obigen Logik als "Rechnung" - und übersteuert die meisten Einstellungen der Druckprozesse - und sendet diese Belege per E-Rechnung raus.
Im Druckprozess kann man lediglich den Bericht "Kopie" einfügen - und zusätzlich zur E-Rechnung einen Ausdruck auf einem Drucker machen lassen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: TSP
Ich würde in diesem Fall das Belegkennzeichen der individuellen Belegart ändern und dabei die von cmayer beschriebene Notation beachten.
Als drittes Zeichen würde ich immer eine Ziffer verwenden, damit es keine Überschneidungen zu Belegkennzeichen aus dem Standard geben kann, falls von Sage neue Belegarten dazukommen. Also z.B. aus "VFL" dann "VV1" machen (je nach Wirkung der individuellen Belegart).
Für die vorhandenen Daten zur individuellen Belegart (Belege, Belegworkflow, Druckprozesse) kann das Belegkennzeichen problemlos per Skript geändert werden. Also erst die Definition der Belegart mit dem neuen Belegkennzeichen erstellen, die Belegkennzeichen in den vorhandenen Daten ändern und dann die Definition der Belegart mit dem alten Belegkennzeichen löschen.

Also z.B. so (ohne Gewähr):
SQL:
INSERT INTO KHKVKBelegarten (Kennzeichen, Erfassungsart, Bezeichnung, BezeichnungReport, Nummernkreis, NummernkreisArt, Gleichgewichtsstatistik, IstInitialbeleg, IstDialoganlage, IstSammelbeleg, RoherloesModus, StatistikWirkungUmsatz,
       StatistikWirkungMenge, MitFibuUebergabe, FibuUebergabeMode, Disposition, DispositionWirkung, Lagerbuchung, LagerbuchungWirkung, GGBestellt, GGBestelltWirkung, GGGeliefert, GGGeliefertWirkung, GGRetour,
       GGRetourWirkung, GGBerechnet, GGBerechnetWirkung, LBWPositiv, LBWNegativ, MEKBerechnung, MitNachweisPflicht, MitGueltigkeit, Archiv, Projekt, Editierbar, [Option], OptionXRM, AnzeigeIndex)
SELECT 'VV1' AS Kennzeichen, Erfassungsart, Bezeichnung, BezeichnungReport, Nummernkreis, NummernkreisArt, Gleichgewichtsstatistik, IstInitialbeleg, IstDialoganlage, IstSammelbeleg, RoherloesModus, StatistikWirkungUmsatz,
       StatistikWirkungMenge, MitFibuUebergabe, FibuUebergabeMode, Disposition, DispositionWirkung, Lagerbuchung, LagerbuchungWirkung, GGBestellt, GGBestelltWirkung, GGGeliefert, GGGeliefertWirkung, GGRetour,
       GGRetourWirkung, GGBerechnet, GGBerechnetWirkung, LBWPositiv, LBWNegativ, MEKBerechnung, MitNachweisPflicht, MitGueltigkeit, Archiv, Projekt, Editierbar, [Option], OptionXRM, AnzeigeIndex
FROM   KHKVKBelegarten WHERE Kennzeichen = 'VFL'

UPDATE KHKVKBelege SET Belegkennzeichen = 'VV1' WHERE Belegkennzeichen = 'VFL'
GO

UPDATE KHKArchivVKBelege SET Belegkennzeichen = 'VV1' WHERE Belegkennzeichen = 'VFL'
GO

UPDATE KHKBelegartenWorkflow SET Belegart = 'VV1' WHERE Belegart = 'VFL'
GO

UPDATE KHKBelegartenWorkflow SET Folgebelegart = 'VV1' WHERE Folgebelegart = 'VFL'
GO

UPDATE KHKDruckprozesseBelegarten SET Belegkennzeichen = 'VV1' WHERE Belegkennzeichen = 'VFL'
GO

UPDATE KHKDruckprozesseBelegarten2 SET Belegkennzeichen = 'VV1' WHERE Belegkennzeichen = 'VFL'
GO

UPDATE KHKTextbausteineBelegarten SET Belegart = 'VV1' WHERE Belegart = 'VFL'
GO

DELETE FROM KHKVKBelegarten WHERE Kennzeichen = 'VFL'
GO
 
  • Like
Reaktionen: TSP
Es liegt an dem F im Belegkennzeichen, sprich die E-Rechnungssteuerung greift hier immer für Belege die Ein "F" (Faktura) also für sage Rechnungsrelevant sind. Siehe auch die Standardbelegkennzeichen VFG(Gutschrift), VFR(Rechnung), VFS(Stornorechnung) etc.
Folglich ist die ein Ändern in Belegarten hier zielführend. Ob da eine Änderung der bestehenden / historischen Belege notwendig ist sein mal dahingestellt. Ansonsten sieht das script von diakh schon mal net schlecht aus.
 
Moin,
die Änderung der historischen Belege ist sinnvoll, weil sonst alle Abfragen und Views die einen "Inner Join" über das Belegkennzeichen in die KHKVKBelegarten ausführen, keine Daten mehr zurückliefern.

Hier mein Vorschlag auf Basis von @diakh und etwas allgemeingültiger:

SQL:
-- Script zur Umstellung eines Belegkennzeichens in den KHKVKBelegen

-- Hier Belegkennzeichen anpassen

DECLARE @BelegkennzeichenAlt varchar(3) = 'VFL'
DECLARE @BelegkennzeichenNeu varchar(3) = 'VV1'

SET XACT_ABORT ON

BEGIN Transaction Belegarten

--KHKVKBelegarten
UPDATE KHKVKBelegarten SET Kennzeichen=@BelegkennzeichenNeu WHERE Kennzeichen=@BelegkennzeichenAlt

--abhängige Tabellen
UPDATE KHKVKBelege SET Belegkennzeichen = @BelegkennzeichenNeu WHERE Belegkennzeichen = @BelegkennzeichenAlt
UPDATE KHKArchivVKBelege SET Belegkennzeichen = @BelegkennzeichenNeu WHERE Belegkennzeichen = @BelegkennzeichenAlt
UPDATE KHKBelegartenWorkflow SET Belegart = @BelegkennzeichenNeu WHERE Belegart = @BelegkennzeichenAlt
UPDATE KHKBelegartenWorkflow SET Folgebelegart = @BelegkennzeichenNeu WHERE Folgebelegart = @BelegkennzeichenAlt
UPDATE KHKDruckprozesseBelegarten SET Belegkennzeichen = @BelegkennzeichenNeu WHERE Belegkennzeichen = @BelegkennzeichenAlt
UPDATE KHKDruckprozesseBelegarten2 SET Belegkennzeichen = @BelegkennzeichenNeu WHERE Belegkennzeichen = @BelegkennzeichenAlt
UPDATE KHKTextbausteineBelegarten SET Belegart = @BelegkennzeichenNeu WHERE Belegart = @BelegkennzeichenAlt

COMMIT Transaction Belegarten

GO

Das sollte bei Problemen sauber zurückrollen.

Im Übrigen gilt das Script aber nur für Installationen ohne Anpassungen von Partnern, denn deren Tabellen werden ja nicht berücksichtigt. Da muss man schauen, ob Anpassungen installiert sind und ob wir die mit updaten können.

liebe Grüße
Marcus
 
Hallo an alle Beteiligten,

vielen vielen Dank für die ausführliche Klärung dieses Problems!
Damit läuft der Druck unserer eigenen Belegarten wieder wie gewünscht.
Allen noch einen schönen Tag!
 
Zurück
Oben