Dokumentation der Buchungslogik von Kreditor Rechnungen.

Ziel der Dokumentation

Die Dokumentation soll eine Übersicht über die verschiedenen Arten von Kreditor-Rechnungen geben, sowie die Verarbeitung der Invoics erklären. Es soll hervorgehen, wie und innerhalb welcher Prozesse die Verbuchung der Invoics sowie der dazu gehörigen Zahlungsverkehr, stattfindet.

Was ist eine INVOIC/ REMADV

Für jede zugrundeliegende Rechnung oder umsatzsteuerrechtliche Gutschrift und Stornierungen dieser wird eine INVOIC-Nachricht (Edifact) erzeugt, die vom Verteilnetzbetreiber an den Lieferanten gesendet wird. Beantwortet wird die INVOIC mit einer REMADV. TODO: Dokumentation zu Edifacts

Allgemeine Hinweise zur Verbuchug von Invoics

In der Vergangenheit wurden INVOICs bei ihrer Erstellung/Akzeptieren der INVOIC auf den Stapel verbucht. Im REMADV-Prozess wurde dann der Stapel ausgeführt und das Buchungsdatum der INVOIC-Buchungen aktualisiert. Die Verbuchung der INVOICs wurde im Rahmen des REX-Projektes geändert. Die INVOICs werden nun erst im REMADV-Prozess verbucht (ohne Stapel) Des weiteren gab es diverse Änderungen bezüglich der bebuchten Konten und des Buchungsdatums. Die einzelnen Änderungen wurden nicht dokumentiert und können nicht vollständig rekonstruiert werden.

Remadv-Lauf

RemadvProzess

  • Der Remadv-Lauf startet automatisch jeden Wochentag um 16:00 Uhr. Durch die Grundeinstellung REMADV_EXECUTION_WEEKDAYS können die Wochentage beeinflusst werden, an denen der Remadv-Lauf Invoics bearbeiten wird.

  • Bis Release 126 wird der Remadv-Lauf immer nur Montags um 16:00 ausgeführt.

  • Ab Release 127 steht REMADV_EXECUTION_WEEKDAYS zur Verfügung. Wird die Grundeinstellung beispielsweise mit Montag, Mittwoch und Freitag gepflegt, werden Invoics jeden Montag, Mittwoch und Freitag um 16:00 geprüft und in Remadvs verarbeitet. An den anderen Wochentagen (inklusive Samstag und Sonntag) läuft der Remadv-Lauf zwar los, wird aber keine Invoics bearbeiten. Diese Ausführungen sind unter der Ansicht Läufe gesondert gekennzeichnet.

  • Der Remadv-Lauf kann ebenfalls manuell gestartet werden (Kreditor/Überweisungsaufträge).

  • Im Remadv-Lauf werden alle akzeptierten Invoics, die innerhalb der nächsten 8 Tage fällig sind pro Iln (des rechnungsstellenden Kreditors) gebündelt. Für jedes Bündel von Invoics wird eine Remadv verbucht. Diese Anzahl an Tagen kann ab Release 127 durch die Grundeinstellung REMADV_COLLECT_INVOICS_DAYS_AHEAD beeinflusst werden.

  • Jede einzelne Invoic kann eine Forderung (positive Invoic, toPay_ > 0) oder ein Guthaben (negative Invoic, toPay_ < 0) sein.

  • Die Summe der Remadv ergibt sich aus der Summe der Beträge aus den Invoics, die in dieser Remadv verarbeitet wurden, und kann damit ebenfalls positiv (sum_ > 0) oder negativ (sum_ < 0) sein.

  • Bei einer positiven Remadv müssen wir Geld an den Kreditor zahlen, es wird ein Überweisungsauftrag erstellt und die Verbuchung der Zahlung findet innerhalb des Remadv-Laufs statt.

  • Bei einer negativen Remadv erhalten wir Geld vom Kreditor. Der Zahlungseingang wird mit dem Kontoauszugsimport verbucht.

Datenbankobjekt Invoic, Tabelle FL_CREDITORINVOIC

Fehlende Beschreibungen müssen durch einen Experten nachgepflegt werden

Spaltenname Beschreibung
periodstart Startdatum des Leistungszeitraums zu dem die Invoice erstellt wird
periodend Enddatum des Leistungszeitraums zu dem die Invoice erstellt wird
id Id der Invoic
systemiln ILN des Systembetreibers
partneriln ILN des rechnungsstellenden Kreditors
partnername Name des rechnungsstellenden Kreditors
number Nummer der Invoic
type Typ der Invoic (Kürzel z.B. JVR = Jahresverbrauchsabrechnung, ABS = Abschlagsrechnung, etc.)
reversalinvoic Referenz auf die Storno-Invoic, im Falle das zu dieser Invoic ein Storno eingegangen ist
invoicedate Rechnungsdatum
duedate Fälligkeitsdatum
consumption Verbrauch
gross Bruttobetrag der abzurechnenden Leistungen, die im Rechnungszeitraum erbracht wurden
alreadypayedgross Bruttobetrag der bereits bezahlten Abschläge
topay Offener Rechnungsbetrag (gross – alreadyPayedgross)
taxfree
tax Steuerbetrag der abzurechnenden Leistungen, die im Rechnungszeitraum erbracht wurden
dateedited Statusänderung Akzeptiert/ Abgelehnt
advicesend Veraltet, es wird jetzt status_ verwendet
accepted Veraltet, es wird jetzt status_ verwendet
declined Veraltet, es wird jetzt status_ verwendet
declinedtext Erste Fehlermeldung , bei fehlgeschlagendem Prüfprozess
referencenumber ID der INVOIC - UNB Segment der Edifakt
duplicate
messagetype BGM-Rechnungsnummer
reversal true, wenn Rechnung eine Storno-Invoic ist
customernumber
remadv_remadv id der Remadv, in der Invoic verarbeitet wurde
financaccoun_financaccoun Id des Rechnungskontos, wird gesetzt, sobald eine Invoic verbucht wird
entrystack_entrystack Id des Stapels auf dem die Rechnung liegt ( Ist veraltert, Invoics werden nicht mehr auf Stapel gebucht, allerdings gibt es noch Altfälle)
edimessage_edimessage Id der Edi in FL_Edimessage, wo INVOIC persistiert wird
declinedqualifier Ablehnungsgrund
contract Id des Vertrags zu dem die Marktlokation gehört, welche abgerechnet wird
businepartne_creditor Id des rechnungsstellenden Kreditors
validatedbyuser User, der manuell Neuplausibilisierung durchgeführt hat
status Status
docreference Referenz auf MSCONS der bilanzierte Menge MMM
accountingbeginning MMM Bilamzierungsbeginn
accountingend MMM Bilanzierungsende
inbounddate Rechnungseingangsdatum IN MBS????? In B2B ????
originalreferencenumber Nummer der Original-Invoic bei Stornos
suminvoicamountnet Nettobetrag der abzurechnenden Leistungen, die im Rechnungszeitraum erbracht wurden
sumpaidamountnet Nettobetrag der Bereits bezahlten Abschläge
sumpaidamounttax Steuerbetrag der bereits bezahlten Abschläge
sumdueamountnet
sumdueamounttax
taxnumbercreditor
taxnumberdebitor
alreadypayedtax
reversecharge True im Falle von ReverseCharge bei Mehr und Mindermengen
accountingdocument Id des Buchungsbelegs der Invoic-Verbuchung

Datenbankobjekt REMADV, Tabelle FL_REMADV

Fehlende Beschreibungen müssen durch einen Experten nachgepflegt werden

Spaltenname Beschreibung
id Eindeutige ID
created Datum der Erstellung
systemiln ILN des Systembetreibers
partneriln ILN des rechnungsstellenden Kreditors
type accepted: wenn akzeptierte Invoics in der REMADV verarbeitet wurden/rejected: wenn abgelehnte Invoics in der REMADV verarbeitet wurden
sum Betrag der REMADV, ergibt sich durch aufsummieren der Forderungen/Guthaben der Invoics, die in der REMADV verarbeitet werden
paymentdate Zahldatum
referencenumber RMP-XXX
edimessage_edimessage ID der EDIFACT(FL_EDIMESSAGE), die versendet wird
credittransfermessage ID des Überweisungsauftrags (FL_CREDITCREDITTRANSFMESSAG), der bei positiver Remadv erstellt wird
entry_entry ID des Entries (FL_ENTRY), welches bei positiver REMADV von 203 (Bankkonto) nach 208 (Schnittstelle SEPA-Überweisungsdatei) erstellt wird
state Status der REMADV SEND/PAYED
accoundocume_accoundocume Beleg vom Typ Creditor.Remadv
messagenumber veraltet?

Invoic-Typen und Rechnungskonten

Es gibt verschiedene Typen von Invoics. Bei der Verbuchung einer Invoice wird ein FinancialAccount vom entsprechenden FinancialaccountType (siehe unten) angelegt StornoInvoics bebuchen den gleichen FinancialAccount wie das Original (In der Vergangenheit wurde hierfür ein separater FinancialAccount verwendet)

  • 203 Schnittstelle Kreditorrechnung Abschlagsrechnung (ABS)
  • 204 Schnittstelle Kreditorrechnung Abschlussrechnung (ABR)
  • 205 Schnittstelle Kreditorrechnung Turnusrechnung (JVR)
  • 206 Schnittstelle Kreditorrechnung Zwischenrechnung (ZVR)
  • 207 Schnittstelle Kreditorrechnung Monatsrechnung (MVR)
  • 209 Schnittstelle Kreditorrechnung Integrierte 13. Rechnung (13I)
  • 210 Schnittstelle Kreditorrechnung Mehr-/Mindermengenabrechnung (MMM)
  • 211 Schnittstelle Kreditorrechnung 13. Rechnung (13R)
  • 212 Schnittstelle Kreditorrechnung Messstellenbetrieb (MSB)
  • 213 Schnittstelle Kreditorrechnung Mehrmengenabrechnung (MMM), Ohne Steuer (ReverseCharge)
  • 214 Schnittstelle Kreditorrechnung Mehrmengenabrechnung (MMM), Mit Steuer
  • 215 Schnittstelle Kreditorrechnung Mindermengenabrechnung (MMM), Ohne Steuer (ReverseCharge)
  • 216 Schnittstelle Kreditorrechnung Mindermengenabrechnung (MMM), Mit Steuer

Remadvs neuerstellen

In einigen Fällen kann es sinnvoll sein, eine Remadv neu zu erzeugen, beispielweise wenn es bei der Invoic-Verarbeitung zu einem Fehler kam und der Marktpartner eine neue Remadv über bereits von MBS verarbeitete Invoics haben möchte. Dies soll der Prozess “Remadvs neuerstellen” ermöglichen. Dabei sind folgende Rahmenbedingungen zu berücksichtigen:

  • In der aktuellen Ausprägung kann der Prozess ausschließlich fallbezogen durch den Support ausgeführt werden
  • Die neue Remadv berechnet die Gesamtsumme über alle Invoics des Originals neu und kann damit fehlerhafte Berechnungen des Originals vermeiden
  • Die Referenznummer entspricht dem Original plus ein “X”. Beispiel: Original war RMP-4711, neue Remadv ist RMP-4711X
  • Es werden keine neuen Buchungen erstellt
  • Es werden keine Überweisungsträger erstellt
  • Es wird eine neue Remadv-EDI erstellt und verschickt
  • Beide Remadvs (Original und Neue) werden auf den Sonderstatus “In Klärung” gesetzt, um sie von weiteren automatischen Prozessen auszuschließen. Sie können über den Knopf “Als bezahlt markieren” in den Status “Bezahlt” gesetzt werden.
  • Eventuelle Differenzen zwischen Original und neuer Remadv müssen fallabhängig behandelt werden. Wir gehen i.A. davon aus, dass biliterale Klärungen zu erfolgen haben

Mehr- und Mindermengen

Der Lastgang einer Marktlokation ohne registrierende Leistungsmessung wird mittels eines Lastprofils prognostiziert und bilanziert (Strom bzw. Gas) Abweichungen der Jahresenergiemenge, die durch eine turnusmäßige Ablesung festgestellt werden, werden zwischen VNB und Lieferanten im Zuge der Mehr- und Mindermengenabrechnung ausgeglichen.

Mindermenge: Es wurde im Zeitraum, zu dem die Abrechnung erstellt wird, mehr Energie in Anspruch genommen als bilanziert wurde. Der Netzbetreiber hat also dem Lieferanten gegenüber eine Forderung und damit ist eine Mindermenge ein Aufwand für den Lieferanten. Der Netzbetreiber stellt die Leistungen dem Lieferanten in Rechnung.
Sender/Leistende = Netzbetreiber
Empfänger = Lieferant

Mehrmenge: Es wurde im Zeitraum, zu dem die Abrechnung erstellt wird, weniger Energie in Anspruch genommen als bilaniziert wurde. Der Lieferant hat also dem Netzbetreiber gegenüber eine Forderung und damit ist eine Mehrmengen Abrechnung ein Ertrag für den Lieferanten. Der Netzbetreiber stellt sich so zu sagen selber eine Rechnung und begleicht diese durch eine Zahlung an den Lieferanten.
Sender/Leistende = Lieferant
Empfänger = Netzbetreiber

MeMiAbb

Reverse Charge Verfahren Wiederverkäufereigenschaft (i.S.d. § 3g UStG)

Um nach dem Reverse-Charge-Verfahren abrechnen zu können, muss

  • bei Strom sowohl der Leistungsempfänger als auch der Leistende

und

  • bei Gas nur der Leistungsempfänger

ein Wiederverkäufer i.S.d. § 3g UStG sein.

Sowohl für Gas- als auch für Stromlieferungen ist der Nachweis der Wiederverkäufereigenschaft durch das Formular des Finanzamtes „Nachweis für Wiederverkäufer von Erdgas und/oder Elektrizität für Zwecke der Steuerschuldnerschaft des Leistungsempfängers“ (USt 1TH) zu erbringen. Der Nachweis hat eine zeitlich eingeschränkte Gültigkeit (vgl. 3.1.1). Ein Unternehmer ist Wiederverkäufer, wenn er zum Zeitpunkt der Ausführung des Umsatzes einen gültigen Nachweis vorlegen kann. (13b3a Abs. 2 Satz 6 UStAE). Die Gültigkeit kann untermonatig beginnen und hat eine Laufzeit von einem bis zu drei Jahren. In der folgenden Abbildung werden verschiedene Szenarien im Hinblick auf die Verwendung des RC Verfahrens betrachtet.

Was ist das Reverse Charge Verfahren?

Begriff:
Das reverse Charge Verfahren ist eine umsatzsteuerliche Regelung, nach der in bestimmten Fällen nicht der leistende Unternehmer, sondern sein Kunde (Leistungsempfänger) die Umsatzsteuer schuldet.

Folgen::
Der leistende Unternehmer darf dem Kunden in diesen Fällen also nur das Nettoentgelt in Rechnung stellen. Der Kunde hat für den Bezug der fraglichen Leistung eine eigene Umsatzsteuerschuld an das Finanzamt zu entrichten (ähnlich wie bei der Erwerbsteuer). Er kann jedoch, soweit er vorsteuerabzugsberechtigt ist, diese Umsatzsteuer auch selbst wieder als Vorsteuer geltend machen. Insoweit besteht hinsichtlich der wirtschaftlichen Belastungswirkungen kein Unterschied zwischen dem Reverse-Charge-Verfahren und der normalen Umsatzsteuer. Das Verfahren führt lediglich zu einer Vereinfachung für den Fiskus und für den leistenden Unternehmer (weil er den Vorgang nicht beim Finanzamt deklarieren muss). V.a. in grenzüberschreitenden Fällen wird dadurch erheblicher Verwaltungsaufwand gespart, weil das Reverse-Charge-Verfahren einem ausländischen Unternehmer erspart, sich an ein dt. Finanzamt wenden zu müssen, und dem dt. Fiskus jede Gefahr nimmt, Steueransprüche im Ausland vollstrecken lassen zu müssen.

Anwendungsbereich:

a) Das Reverse-Charge-Verfahren ist EG-rechtlich u.a. für grenzüberschreitende Fälle vorgesehen:

  1. In den Fällen von grenzüberschreitenden Katalogleistungen ist es unter bestimmten Umständen allen Mitgliedsstaaten zwingend vorgeschrieben.
  2. In allen übrigen Fällen grenzüberschreitender Geschäfte ist seine Einführung den Mitgliedsstaaten gestattet.
  3. Seine Anwendung auf weitere Fallkonstellationen ist EG-rechtlich nur gestattet, wenn es hierfür als Maßnahme zur Verhinderung von Steuerumgehung oder Steuerhinterziehung oder als Maßnahme zur Steuervereinfachung von der EG genehmigt worden ist.

b) In Deutschland ist das Reverse-Charge-Verfahren vorgesehen für:

  1. Werklieferungen und sonstige Leistungen eines in der EU (§ 13b I UStG), bzw. im Ausland ansässigen Unternehmers (§ 13b II Nr. 1 UStG ), naturgemäß allerdings nur dann, wenn diese Vorgänge in Deutschland steuerbar sind.
  2. Lieferungen sicherungsübereigneter Gegenstände durch den Sicherungsgeber an den Sicherungsnehmer außerhalb des Insolvenzverfahrens (§ 13b II Nr. 1 UStG);
  3. Lieferungen von Grundstücken (§ 13b II Nr. 3 UStG),
  4. Werklieferungen und sonstige Leistungen, die der Herstellung, Instandsetzung und -haltung, Änderung oder Beseitigung von Bauwerken dienen, mit Ausnahme von Planungs- und Überwachungsleistungen (§ 13b II Nr. 4 UStG), soweit der Leistungsempfänger wiederum selbst eine solche Leistung an andere erbringt (§ 13b V UStG);
  5. Lieferungen von Gas und Elektrizität eines im Ausland ansässigen Unternehmers nach § 3g UStG (§ 13b II Nr. 5 UStG);
  6. Übertragung von Berechtigungen nach dem Treibhausgas-Emissionshandelsgesetzes u. w. (§ 13b II Nr. 6 UStG); –(7) Lieferungen bestimmter Gegenstände (Metalle), z.T. ab einem Wert eines wirtschaftlichen Vorganges von 5.000 Euro, Anlagen 3 u.4 des UStG (§ 13b II Nr. 7 u. 11 UStG); –(8) Gebäudereinigungsleistungen (§ 13b II Nr. 8 UStG); –(9) Lieferungen von Gold in bestimmter Ausprägung (§ 13b II Nr. 9 UStG); –(10) Lieferungen von Mobilfunkgeräten und ähnl. Gegenständen ab einem Wert eines wirtschaftlichen Vorganges von 5.000 Euro (§ 13b II Nr. 10 UStG).

Das Reverse-Charge-Verfahren gilt in allen diesen Fällen nur dann, wenn der Leistungsempfänger

  1. ein Unternehmer ist (in diesem Fall auch, wenn die Leistung für den nichtunternehmerischen Bereich des Unternehmers bezogen wird) oder
  2. eine juristische Person des öffentlichen Rechts; ist das nicht der Fall, bleibt der leistende Unternehmer Steuerschuldner und muss die Steuer an das dt. Finanzamt abführen.

Ermittlung RC-Verfahren-Theoretische Betrachtung

Energie-Steuer

Fallbetrachtung Stromsteuer – MeMi an Lieferant

Nach § 5 Abs. 3 StromStG entsteht die Stromsteuer mit der Leistung an einen Versorger, der nicht Inhaber eines Stromsteuererlaubnisscheins ist. In diesem Fall muss bei der Mehr-/Mindermengenabrechnung Stromsteuer berechnet und entrichtet werden.

StromsteuerMeMi

Dem Versorger ohne Erlaubnis wird die durch den an ihn leistenden Versorger entrichtete Steuer auf Antrag vergütet, soweit er nachweist, dass die durch die tatsächliche Entnahme des Stroms entstandene Steuer entrichtet worden ist, für den Strom keine Steuer entstanden ist oder der Strom steuerfrei entnommen worden ist.

Im Rahmen des MEMI-Prozesses muss folglich geprüft werden, ob der VNB oder der Lieferant im Sinne des § 5 StromStG einen Erlaubnisschein besitzt. Das Vorliegen des jeweiligen Erlaubnisscheins ist durch bilateralen Informationsaustausch zwischen VNB und Lieferanten zu ermitteln. Der eigene und der des jeweiligen Lieferanten wird mittels Identifikationsart in den Geschäftspartnerstammdaten gepflegt.

Fallbetrachtung Energiesteuer – MeMi an Lieferanten

Nach § 38 Abs. 1 EnergieStG führt die Belieferung eines anderen Erdgaslieferers nicht zur Steuerentstehung. Ein Sonderfall liegt jedoch dann vor, wenn der belieferte Erdgaslieferant nicht als Lieferant beim zuständigen Hauptzollamt (HZA) angemeldet ist. In diesem Fall gilt das Erdgas als vom belieferten im Steuergebiet aus dem Netz entnommen (§38 Abs. 5 EbergieStG) und die Steuer entsteht.

EnergiesteuerMeMi

Die Vergütung der vom Vorlieferanten in Rechnung gestellt Energiesteuer kann beantragt werden, sofern die durch die tatsächliche Entnahme entstandene Steuer nachweislich entrichtet wurde.

Im Rahmen des MEMI-Prozesses muss folglich geprüft werden, ob der VNB oder der Lieferant im Sinne des § 38 EnergieStG als Gaslieferant beim HZA angemeldet ist (Lieferstatus). Der jeweilige Lieferstatus ist durch bilateralen Informationsaustausch zwischen VNB und Lieferanten zu ermitteln. Der eigene und der des jeweiligen Lieferanten wird mittels Identifikationsart in den Geschäftspartnerstammdaten gepflegt.

Gegenüberstellung Mehrmenge ohne und mit ReverseCharge Verfahren

ENTWURF! Diagramm in Arbeit, Historie noch nicht nachvollziehbar um Diagramme fertig zu stellen

MehrmengeRCvsOhneRC

Gegenüberstellung Mindermenge ohne und mit ReverseCharge Verfahren

ENTWURF! Diagramm in Arbeit, Historie noch nicht nachvollziehbar um Diagramme fertig zu stellen

MindermengeRCvsOhneRC

Buchungsdiagramme

Aus den nachfolgenden Buchungsdiagrammen wird die Verbuchung der Invoics und der dazugehörige Zahlungsverkehr abgebildet. Hierbei sind folgende Informationen gegeben:

  • Welche Konten werden im Soll und Haben bebucht
  • In welcher Höhe wird die Buchung erstellt
  • Mit welchem Buchungsbeleg wird die Buchung erstellt
  • In welchem Prozessschritt wird die Buchung erstellt
  • Welche Deckungen werden erstellt
  • Welchen Typ und Beleg haben die Deckungen

Hinweis zum Buchungsdatum

Die Remadv erhält bei ihrer Erstellung ein Paymentdate. Dieses ist das Tagesdatum + 3 Tage Die Verbuchung der Invoic findet zum paymentDate statt, es sei denn:

  • Das Paymentdate liegt in der Vergangenheit
  • Die GlobalProperty CREDIT_TRANSFER_IMMEDIATELY ist auf true gesetzt

dann ist in beiden Fällen das Buchungsdatum gleich dem Tagesdatum Die Verbuchung des Zahlungsausgangs findet zum PaymentDate_ statt. Die Verbuchung des Zahlungseingangs findet zum valutaDatum statt, der im Kontoauszug hinterlegt ist (siehe Dokumentation Kontoauszug noch nicht vorhanden)

Zu jedem Buchungsdiagramm wurde ein TestCase erstellt, der die Buchungslogik abprüft.

BDEW Artikel

Eine Invoic kann einen oder mehrere BDEW Artikel haben. Die BDEW-Artikel bebuchen unterschiedliche Konten Zur Vereinfachung wird in den Buchungsdiagrammen immer nur ein BDEW-Artikel Konto dargestellt. Die Rechnungssumme ergibt sich immer aus der Summe der einzelnen BDEW-Artikel

Die vollständige Artikelliste liegt unter:
https://www.edi-energy.de/archiv/fdf.vdew.net/wysvde/dataforum.nsf/0/1A48533AF02E1434C1257FD500335561/%24file/BDEW-Artikelnummernliste_4_1e_Lesefassung_20160417b.pdf

Verbuchung einer einzelnen positiven Invoic und positiver Remadv

Testfall 1 und Testfall 2:
InvoicAccountingABSTest, testInvoicABS_31001
InvoicAccountingJVRTest, testInvoicJVR_31002_noPayments_oneLinSegment, testInvoicJVR_31002_noPayments_multipleLinSegment

ForderungsInvoicPositiveRemadv

Es wird in einem Remadv-Lauf eine einzelne Forderungs-Invoic verarbeitet, woraus zwangsläufig eine positive Remadv (Forderung) entsteht. Der Zahlungsausgang wird innerhalb des Remadv-Laufs verbucht (Belegtypen Creditor.Remadv.Invoice und Creditor.Remadv). Die REMADV erhält den Status PAYED. Desweiteren wird ein Überweisungsauftrag erstellt, der bei der Bank eingereicht werden muss. Hierzu wird eine Aufgabe ‘Überweisung an Kreditoren durchführen’ erstellt. Führt die Bank die Überweisung aus, wird der Zahlungsausgang im folgenden Kontoauszug aufgeführt. Beim Import des Kontoauszugs findet der Ausglaeich auf dem Konto 208 statt.

Verbuchung von zwei positiven Invoics und positiver Remadv

noch kein Testfall vorhanden :

ZweiForderungsInvoicsPositiveRemadv

Es werden in einem Remadv-Lauf zwei Forderungs-Invoic verarbeitet, woraus zwangsläufig eine positive Remadv (Forderung) entsteht. Der Zahlungsausgang wird innerhalb des Remadv-Laufs verbucht (Belegtypen Creditor.Remadv.Invoice und Creditor.Remadv). Bei der Verbuchung von mehreren Invoics in einem Remadv-Lauf werden die Buchungen mit den Belegtypen Creditor.Invoice und Creditor.Remadv.Invoice immer pro Invoic statt. Die Buchung von Bankkonto (302) nach Schnittstelle Sepa Überweisungsdatei (208) mit dem Belegtyp Creditor.Remadv wird immer pro Remadv verbucht. Der Betrag der Buchung 302 an 208 entspricht dabei dem Betrag der Remadv (FL_REMADV.sum_), welcher sich wiederum aus der Summe der zu zahlenden Beträge der Invoics (FL_CREDITORINVOICE.toPay_) ergibt. Die REMADV erhält den Status PAYED. Desweiteren wird ein Überweisungsauftrag erstellt, der bei der Bank eingereicht werden muss. Hierzu wird eine Aufgabe ‘Überweisung an Kreditoren durchführen’ erstellt. Führt die Bank die Überweisung aus, wird der Zahlungsausgang im folgenden Kontoauszug aufgeführt. Beim Import des Kontoauszugs findet der Ausglaeich auf dem Konto 208 statt.

Verbuchung einer positiven Invoic und positiver Remadv sowie der Storno-Invoic in zwei unterschiedlichen Remadv-Läufen

Testfall 3 und Testfall 4 InvoicAccountingABSTest, testInvoicABS_31001_Reversal
InvoicAccountingJVRTest,testInvoicJVR_31002_noPayments_Reversal
ForderungsInvoicUndStorno

Es wird in einem Remadv-Lauf eine einzelne Forderungs-Invoic verarbeitet, woraus zwangsläufig eine positive Remadv (Forderung) entsteht. Der Zahlungsausgang wird innerhalb des Remadv-Laufs verbucht (Belegtypen Creditor.Remadv.Invoice und Creditor.Remadv) Die REMADV erhält den Status PAYED. Desweiteren wird ein Überweisungsauftrag erstellt, der bei der Bank eingereicht werden muss. Hierzu wird eine Aufgabe ‘Überweisung an Kreditoren durchführen’ erstellt. Führt die Bank die Überweisung aus, wird der Zahlungsausgang im folgenden Kontoauszug aufgeführt. Beim Import des Kontoauszugs findet der Ausglaeich auf dem Konto 208 statt. Anschließend wird in einem zweiten Remadv-Lauf die Storno-Invoic zu der bisher verbuchten Invoic verarbeitet. Da die Oiginal-Invoic eine Forderung war, stellt das Storno ein Guthaben dar, woraus eine negative Remadv resultiert. Der Kreditor muss damit Geld an uns überweisen. Es findet also kein Zahlungsausgang statt und es wird auch kein Überweisungsauftrag erstellt (Verbuchung entfällt). Die REMADV erhält den Status SEND. Sobald die Zahlung des Kreditors auf unserem Konto eingegangen ist, wird diese Position im folgendem Kontoauszug aufgeführt. Mit dem Import dieses Kontoauszugs, wird der Zahlungseingang verbucht. Die Zuweisung an den korrekten Kreditor erfolgt durch die Remadv-Nummer, (RMP-XYZ), die im Verwendungszweck angegeben wird. Die REMADV erhält den Status PAYED und der offene Posten auf dem Kreditorkonto wird ausgeglichen.

Verbuchung einer positiven Invoic mit bezahlten Abschlägen und positiver Remadv

Testfall 5

ForderungsInvoicMitBezahltemAbschlagPositiveRemadv

Es wird in einem Remadv-Lauf eine einzelne Forderungs-Invoic mit bereits bezahlten Abschlägen verarbeitet, woraus eine positive Remadv (Forderung) entsteht. Eine Forderung entsteht nicht zwangsläufig, sondern nur dann, wenn der Rechnungsbetrag höher ist, als die bereits bezahlten Abschläge, so wie in diesem Beispiel. Der Zahlungsausgang wird innerhalb des Remadv-Laufs verbucht (Belegtypen Creditor.Remadv.Invoice und Creditor.Remadv). Die REMADV erhält den Status PAYED. Desweiteren wird ein Überweisungsauftrag erstellt, der bei der Bank eingereicht werden muss. Hierzu wird eine Aufgabe ‘Überweisung an Kreditoren durchführen’ erstellt. Führt die Bank die Überweisung aus, wird der Zahlungsausgang im folgenden Kontoauszug aufgeführt. Beim Import des Kontoauszugs findet der Ausglaeich auf dem Konto 208 statt.

Verbuchung einer negativen Invoic mit bezahlten Abschlägen und negativen Remadv

Testfall 9

GuthabenInvoicMitBezahltemAbschlagNegativeRemadv

Es wird in einem Remadv-Lauf eine einzelne Guthaben-Invoic mit bereits bezahlten Abschlägen verarbeitet, woraus eine negative Remadv (Guthaben) entsteht. Ein Guthaben entsteht nicht zwangsläufig, sondern nur dann, wenn der Rechnungsbetrag gerringer ist, als die bereits bezahlten Abschläge, so wie in diesem Beispiel. Der Kreditor muss damit Geld an uns überweisen. Es findet also kein Zahlungsausgang statt und es wird auch kein Überweisungsauftrag erstellt (Verbuchung entfällt). Die REMADV erhält den Status SEND. Sobald die Zahlung des Kreditors auf unserem Konto eingegangen ist, wird diese Position im folgendem Kontoauszug aufgeführt. Mit dem Import dieses Kontoauszugs, wird der Zahlungseingang verbucht. Die Zuweisung an den korrekten Kreditor erfolgt durch die Remadv-Nummer, (RMP-XYZ), die im Verwendungszweck angegeben wird. Die REMADV erhält den Status PAYED und der offene Posten auf dem Kreditorkonto wird ausgeglichen.

Verbuchung einer negativen Invoic mit bezahlten Abschlägen und negativer Remadv sowie der Storno-Invoic in zwei unterschiedlichen Remadv-Läufen

Testfall 6:
TODO Klasse und Methode hinterlegen GuthabenInvoicMitBezahltemAbschlagUndStorno

Es wird in einem Remadv-Lauf eine einzelne Guthaben-Invoic mit bereits bezahlten Abschlägen verarbeitet, woraus eine negative Remadv (Guthaben) entsteht. Ein Guthaben entsteht nicht zwangsläufig, sondern nur dann, wenn der Rechnungsbetrag gerringer ist, als die bereits bezahlten Abschläge, so wie in diesem Beispiel. Der Kreditor muss damit Geld an uns überweisen. Es findet also kein Zahlungsausgang statt und es wird auch kein Überweisungsauftrag erstellt (Verbuchung entfällt). Die REMADV erhält den Status SEND. Sobald die Zahlung des Kreditors auf unserem Konto eingegangen ist, wird diese Position im folgendem Kontoauszug aufgeführt. Mit dem Import dieses Kontoauszugs, wird der Zahlungseingang verbucht. Die Zuweisung an den korrekten Kreditor erfolgt durch die Remadv-Nummer, (RMP-XYZ), die im Verwendungszweck angegeben wird. Die REMADV erhält den Status PAYED und der offene Posten auf dem Kreditorkonto wird ausgeglichen. Anschließend wird in einem zweiten Remadv-Lauf die Storno-Invoic zu der bisher verbuchten Invoic verarbeitet. Da die Oiginal-Invoic ein Guthaben war, stellt das Storno eine Forderung dar, woraus eine positive Remadv resultiert. Der Zahlungsausgang wird innerhalb des Remadv-Laufs verbucht (Belegtypen Creditor.Remadv.Invoice und Creditor.Remadv). Die REMADV erhält den Status PAYED. Desweiteren wird ein Überweisungsauftrag erstellt, der bei der Bank eingereicht werden muss. Hierzu wird eine Aufgabe ‘Überweisung an Kreditoren durchführen’ erstellt. Führt die Bank die Überweisung aus, wird der Zahlungsausgang im folgenden Kontoauszug aufgeführt. Beim Import des Kontoauszugs findet der Ausglaeich auf dem Konto 208 statt.

Verbuchung einer 0-Euro Invoic mit bezahlten Abschlägen und einer 0 Euro Remadv

Testfall 7:
0EuroInvoicMit0EuroRemadv.png

Es wird in einem Remadv-Lauf eine einzelne Guthaben-Invoic mit bereits bezahlten Abschlägen verarbeitet. Die Besonderheit in diesem Fall ist, dass die Rechnungssumme genau der Summe der bereits bezahlten Abschlägen entspricht. Daraus ergibt sich eine offene Forderung/ ein offenes Guthaben von 0 Euro. Die Invoic wird verbucht und es wird ebenfalls eine Remadv angelegt und versendet. Allerdings gibt es keine Verbuchung der Remadv.

Verbuchung einer positiven Invoic und einer negativen Invoic und positiver Remadv

Testcase :In Arbeit
ForderungsUndGuthabenInvoicPositiveRemadv
Es wird in einem Remadv-Lauf eine Forderungs-Invoic und eine Guthaben-Invoic verarbeitet. Da der Betrag der Forderungs-invoic größer ist, als der Betrag der Guthaben-Invoic, resultiert eine positive Remadv (Forderung). Die Ausgangszahlung wird innerhalb des Remadv-Laufs verbucht (Creditor.Remadv.Invoice, Creditor.Remadv)

Verbuchung einer einzelnen negativen Invoic und negativen Remadv

Testcase :In Arbeit
GuthabenInvoicNegativeRemadv

Es wird in einem Remadv-Lauf eine einzelne Guthaben-Invoic verarbeitet, woraus zwangsläufig eine negative Remadv (Guthaben) entsteht. Es wird keine Ausgangszahlung durchgeführt wird(Creditor.Remadv.Invoice, Creditor.Remadv), da der rechnungsstellende Kreditor uns den Betrag der REMADV schuldet. Die Eingangszahlung wird mit dem Kontoauszugsimport verbucht.

Verbuchung einer positiven Invoic und einer negativen Invoic und negativer Remadv

Testcase :In Arbeit
GuthabenUndForderungsInvoicNegativeRemadv

Es wird in einem Remadv-Lauf eine Forderungs-Invoic und eine Guthaben-Invoic verarbeitet. Da der Betrag der Guthaben-Invoic größer ist, als der Betrag der Forderungs-Invoic, resultiert daraus eine negative Remadv (Guthaben). Es wird keine Ausgangszahlung durchgeführt wird(Creditor.Remadv.Invoice, Creditor.Remadv), da der rechnungsstellende Kreditor uns den Betrag der REMADV schuldet. Die Eingangszahlung wird mit dem Kontoauszugsimport verbucht.

Verbuchung einer negativen Invoic und negativer Remadv sowie der Storno-Invoic in zwei unterschiedlichen Remadv-Läufen

Testcase :In Arbeit
GuthabenInvoicUndStornoKontoauszug

In Arbeit

Verbuchung einer positiven Invoic und einer negativen Invoic und negativer Remadv, Zahlungseingang wird manuell zugewiesen

Testcase :TODO Klasse und Methode hinterlegen GuthabenInvoicManuelleZuweisung

Es wird in einem Remadv-Lauf eine Forderungs-Invoic und eine Guthaben-Invoic verarbeitet. Da der Betrag der Guthaben-Invoic größer ist, als der Betrag der Forderungs-Invoic, resultiert daraus eine negative Remadv (Guthaben). Es wird keine Ausgangszahlung durchgeführt wird(Creditor.Remadv.Invoice, Creditor.Remadv), da der rechnungsstellende Kreditor uns den Betrag der REMADV schuldet. Die Eingangszahlung wird mit dem Kontoauszugsimport verbucht. Die Zuweisung an den korrekten Kreditor, innerhalb des Kontoauszugsimport, wird dadurch vorgenommen, dass im Verwendungszwck, die Remadv-Nummer angegeben ist. Ist diese nicht vorhanden, kann die Eingangszahlung nicht automatisch dem Kreditor zugewiesen werden, und wird auf Transit verbucht. Auf dem Transitkonto kann durch die Ribbon-Funktion “an Kreditor zuweisen” die Buchung manuell zugewiesen werden (Interface.StaFile.Entry.AssignToCreditorAccount)

Mehrmenge im Reverse Charge Verfahren

Testfall 16:
MehrmengeImRC

Die Mehrmenge stellt für den Lieferanten einen Ertrag dar. Im ReverseCharge findet keine Verbuchung der Steuer statt, da wir lediglich die Sicht des Lieferanten abbilden. Die Steuer muss durch den Verteilnetzbetreiber an das Finanzamt abgeführt werden. Verbucht wird der reine Netto-Betrag.

Mehrmenge ohne Reverse Charge Verfahren

Testfall 11:
MehrmengeOhneRC

Die Mehrmenge stellt für den Lieferanten einen Ertrag dar. Bei einer Mehrmenge ohne ReverseCharge findet eine Reduzierung der Vorsteuer statt.

Mindermenge im Reverse Charge Verfahren

Testfall 17:
MindermengeImRC

Eine Mindermenge stellt für den Lieferanten einen Aufwand dar. Im ReverseCharge-Verfahren wird die Zahlung an den Kreditor Netto gebucht, da die Steuer direkt an das Finanzamt abgeführt wird. Für die Steuerregulierung wird die Steuerbuchung auf den speziellen UStG § 13 - Steuerkonton gebucht (Vorsteuer § 13 - 311 an MWST § 13 - 312) (Der Unternehmer, der eine Leistung erbringt, ist Schuldner der Umsatzsteuer. Von diesem Grundsatz gibt es Ausnahmen, und zwar dann, wenn der Leistungsempfänger gemäß § 13b UStG Schuldner der Umsatzsteuer wird. Er ist dann verpflichtet, die Umsatzsteuer an das Finanzamt abzuführen)

Mindermenge ohne Reverse Charge Verfahren

Testfall 15:
MindermengeOhneRC

Eine Mindermenge stellt für den Lieferanten einen Aufwand dar. Ohne ReverseCharge, wird wie üblich das Vorsteuerkonto im Soll bebucht