eRechnungspflicht ab dem 1. Januar 2025

Rechnungen müssen künftig in einem strukturierten elektronischen Format ausgestellt werden, das dem europäischen Rechnungsstandard  EN16931 entspricht und die elektronische Verarbeitung ermöglicht.

Klar ist, dass eine reine PDF Datei oder Word nicht hierunter fallen. Ein Bildbeleg als visuelles Prüfmittel rückt damit in den Hintergrund. Die Prüfung von Rechnungen wird zu einem rein digitalen Prozess am Bildschirm.
Zukunftsweisend sollte jetzt der Prozessablauf einer digitalen Eingangsrechnungsprüfung im Unternehmen organisiert werden.

„eRechnungspflicht ab dem 1. Januar 2025“ weiterlesen

UST Regelung §12 Abs 3 USTG mit Fibu Übergabe

Wenn nach der Datev Abschlagsvariante gearbeitet wird (Generalumkehr Schlußrechnung abbzgl. der erhaltenen Anzahlungen) BnFibu.ini Eintrag SR=0 muss folgender Lösungsweg praktiziert werden.

Sachverhaltstexte:
Hinweis gemäß § 13b Umsatzsteuergesetz (Steuerschuldnerschaft des Leistungsempfängers). Diese Rechnung ist ohne MwSt., der Auftraggeber ist zur Anmeldung und Abführung der Umsatzsteuer verpflichtet.

Hinweis gemäß § 12 Absatz 3 Umsatzsteuergesetz: Diese Rechnung ist mit 0% UStG. ausgewiesen.

Regelsteuersatz 19% UST und 0% 13b UST anhaken

„UST Regelung §12 Abs 3 USTG mit Fibu Übergabe“ weiterlesen

Eingangsrechnungsbuch Zahlungskonditionen aus Lieferantenstamm überschreiben

Mit diesem Job werden die Zahlungsbedingungen im Eingangsrechnungsbuch mit den aktuell hinterlegten Zahlungskonditonen des Lieferanten (Kreditor) aus den KWP Zahlungskonditionen überschrieben solange diese noch nicht an die Finanzbuchhaltung (z.B. Datev) übergeben worden sind.

update rebEinRechnung
set Nettofaelligkeit = r.Eingangsdatum+k.NettoTage,SkontoPrz=k.skonto,skontodatum=r.Eingangsdatum+k.SkontoTage,AbbuchungErstellt=k.Abbuchung,skonto=Skontobasis*(k.Skonto/100)
from rebeinrechnung r left join adradressen a on r.fkAdresse=a.AdrNrGes left join adrkonditionen k on a.ZahlungsKondition=k.KonditionsNr
where r.FibuUebgDatum is Null

Eingangsrechnungsbuch Kost1 und Kost2 füllen neues WW2

Vorgang in rebbuchung – Diese Felder werden mit dem Wert gefüllt
0 = Projekt füllt fkprojnr
2 = Regie füllt Vorgangsnr
4 = Bestell füllt füllt fkBestellnr
5 = Wartungsauftrag füllt Vorgangsnr
9 = Sonstiges NULL

Auf Basis der Checkliste sollten die Informationen zurückkommen, wie im Eingangsrechnungsbuch bei der Datev Schnittstelle die Felder Kost1 und Kost2 gefüllt werden sollen.

select re.id,re.Bezeichnung, rb.fkKonto, rb.fkBestellNr, rb.fkProjNr, rb.vorgang, rb.VorgangsNr, rb.KstKtr,Projekt.ProjNr as pnr,Regie.ProjNr as rnr,
projekt.AbtNr, regie.AbtNr, regie.AnlagenNummer, bestellung.VorgangsNr, bestellung.VorgangsNr2,
case
when rb.vorgang = 0 and rb.fkBestellNr is null then rb.fkProjNr
when rb.Vorgang = 2 and rb.fkBestellNr is null and rb.fkProjNr is null then rb.VorgangsNr
when rB.vorgang = 4 and rb.fkBestellNr is not null then Bestellung.VorgangsNr
when rb.Vorgang = 5 and rB.fkBestellNr is null and rb.fkProjNr is null then rb.VorgangsNr
end as Kostentraeger,
case
when cast(rB.vorgang as nvarchar) = 0 and cast(rb.fkBestellNr as nvarchar) is null then cast(projekt.AbtNr as nvarchar)
when cast(rB.vorgang as nvarchar) = 2 and cast(rb.fkBestellNr as nvarchar) is null and cast(rb.fkProjNr as nvarchar) is null then cast(regie.AbtNr as nvarchar)
when cast(rB.vorgang as nvarchar) = 4 and cast(rb.fkBestellNr as nvarchar) is not null then cast(Bestellung.AbteilungsNr as nvarchar)
–when rb.Vorgang = 5 then regie.AnlagenNummer
when rb.Vorgang = 5 then regie.AbtNr

end as Kost

FROM Bestellung RIGHT OUTER JOIN rebEinRechnung as re RIGHT OUTER JOIN rebBuchung as rb
on re.pkER = rb.fkER LEFT OUTER JOIN Projekt ON rb.fkProjNr = Projekt.ProjNr LEFT OUTER JOIN Regie ON rB.VorgangsNr =
Regie.ProjNr ON Bestellung.BestellNr = rb.fkBestellNr where REDatum > ‚01.04.2024‘



ZuGFerd Zahlungskonditionen – warum werden die Skontodaten häufig falsch interpretiert

Bei Skonto handelt es sich um einen Nachlass aufgrund einer verkürzten Zahlungsfrist. In Deutschland ist die Übermittlung von Skonto-Informationen in vielen Branchen üblich. Das Datenmodell der EN 16931 sieht derzeit keinen entsprechenden Prozess vor und stellt daher keine strukturierten Informationselemente zur Verfügung, um Skonto-Informationen in entsprechender Form abzubilden.

Prinzipiell ist im europäischen Datenmodell das Informationselement „Payment terms“ vorhanden, das geeignet ist, unstrukturierte Zahlungsinformationen in Textform aufzunehmen. Dies ermöglicht jedoch keine automatisierte Verarbeitung.