[gelöst] Afa berechnen: Bebuchung des Sachkontos

Unsere Anlagenbuchhaltung benötigt Hilfe.

Es ist gewünscht, dass die aus einer Afa resultierenden Sachposten eine gefüllte Herkunftsart (=Anlage) und Herkunftsnummer (=Anlagennr.) haben.
Aktuell wird dies erreicht, indem der Bericht "Afa berechnen..." OHNE Option "Gegenkonto einfügen" (bzw. ohne nachträgliches Aufrufen der Anlagen-Fibu-Buch.-Blatt-Funktion "Anlagengengenkonto einfügen") aufgerufen wird.
In die so erzeugten Anlagen Fibu Buch.-Blattzeilen (Kontoart = Anlage) wird dann manuell das Gegenkonto eintragen.

Die Option "Gegenkonto einfügen" bzw. "Anlagengegenkonto einfügen" dagegen erzeugt pro Anlage eine zweite Anlagen Fibu Buch.-Blattzeile mit positivem Betrag, Kontoart = Sachkonto, allerdings ohne Herkunftsart und Herkunftsnummer.

Daher stellt sich für mich die Frage: Ist das, was unsere Anlagenbuchhaltung bisher manuell gebucht hat, sachlich "falsch"?
Warum füllt der Standard für die Sachkontenzeile nicht die Herkunftsfelder? Spricht was dagegen, dies zu ergänzen?

Das ist und war m.E. schon immer so in NAV wenn man mehrzeilig im Buchblatt bucht, dass auf der einzelnen Zeile die Herkunftsnr. nicht gefüllt wird. Wie auch?
Es können ja unzählige Zeilen innerhalb dieser Belegnummer im Buchblatt vorhanden sein.
Ich würde da nix am NAV Standard ändern!
Hier kommt ja nicht immer nur 1 Kreditor oder 1 Debitor wie aus einem Systembeleg als Herkunftsnummer in Frage.

LG Anke

Hier kommt ja nicht immer nur 1 Kreditor oder 1 Debitor wie aus einem Systembeleg als Herkunftsnummer in Frage.

Hier geht es lediglich um die Herkunft Anlage (nicht Debitor/Kreditor), und die ist eindeutig.

Leider hast du nicht geschrieben, ob die bisherige Vorgehensweise meiner Kollegen richtig war?

Es ist gewünscht, dass die aus einer Afa resultierenden Sachposten eine gefüllte Herkunftsart (=Anlage) und Herkunftsnummer (=Anlagennr.) haben. Aktuell wird dies erreicht, indem der Bericht "Afa berechnen..." OHNE Option "Gegenkonto einfügen" (bzw. ohne nachträgliches Aufrufen der Anlagen-Fibu-Buch.-Blatt-Funktion "Anlagengengenkonto einfügen") aufgerufen wird. In die so erzeugten Anlagen Fibu Buch.-Blattzeilen (Kontoart = Anlage) wird dann manuell das Gegenkonto eintragen.

Leider hast du nicht geschrieben, ob die bisherige Vorgehensweise meiner Kollegen richtig war?

Es ist gewünscht, dass die aus einer Afa resultierenden Sachposten eine gefüllte Herkunftsart (=Anlage) und Herkunftsnummer (=Anlagennr.) haben. Aktuell wird dies erreicht, indem der Bericht "Afa berechnen..." OHNE Option "Gegenkonto einfügen" (bzw. ohne nachträgliches Aufrufen der Anlagen-Fibu-Buch.-Blatt-Funktion "Anlagengengenkonto einfügen") aufgerufen wird. In die so erzeugten Anlagen Fibu Buch.-Blattzeilen (Kontoart = Anlage) wird dann manuell das Gegenkonto eintragen.

Hallo Natalie,

so funktioniert das ja, anders (also zweizeilig) eben nicht. Und ich würde da auch nix programmieren

LG Anke

Danke Anke,
aber ich befürchte, wir reden noch immer aneinander vorbei ... Also noch einmal ganz langsam:

Der Stapellauf "Afa berechnen" erzeugt (bitte korrigiere mich ...!) im Standard im "Anlagen Fibu Buch.-Blatt" pro Anlage einen Datensatz mit

• Kontoart = Anlage
• Kontonr. = Anlagennr.
• Herkunftsart = Anlage
• Herkunftsnr. = Anlagennr.
• Gegenkontonr. = LEER

Wähle ich zusätzlich die Option "Gegenkonto einfügen", wird pro Anlage eine weitere Zeile hinzugefügt. Die erste Zeile ist die oben genannte, die zweite jedoch:

• Kontoart = Sachkonto
• Kontonr. = Sachkontonr.
• Herkunftsart = LEER
• Herkunftsnr. = LEER

Vielleicht liegt es nur an unserer Einrichtung, aber hier bei uns erzeugt jede Anlage nur einen Anlagen-Datensatz, und auch die Sachkontenbebuchung erfolgt auf ein EIN Sachkonto. Also keine Notwendigkeit, die Sachkontozeilen zu splitten.

Zurück zum Grundproblem:
Unsere Fibu möchte, dass bei der Verbuchung des Sachpostens (auf das Gegenkonto) die Anlage als Herkunftsart/-nr. mitgeführt wird.
Aktuell gibt es zwei Möglichkeiten:

1. Entweder, der Bericht wird OHNE "Gegenkonto einfügen" aufgerufen (= 1 Zeile pro Anlage), und die Gegenkontonr. wird manuell in jede Buch.-Blattzeile nachgetragen. --> Nicht praktikabel bei vielen Anlagen.
2. Oder, es wird Option "Gegenkonto einfügen" gewählt (= 2 Zeilen pro Anlage). Dann ist die zweite Zeile zwar mit dem Gegenkonto (im Feld Kontonr.) befüllt, aber in dieser zweiten Zeile fehlen die Herkunftsart/-nr. = Anlage. Man müsste also auch hier alle Zeilen durchgehen und diese manuell nachtragen --> Ebenfalls nicht praktikabel.

Fragen:

1. Macht es buchhalterisch/postentechnisch einen Unterschied, ob ich Methode 1 oder 2 inkl. der manuellen Ergänzung praktiziere, um einen Sachposten mit Herkunft = Anlage zu erzeugen?
2. Was spricht (für uns) dagegen, den Bericht anzupassen, dass die zweite Gegenkontozeile mit der Anlage als Herkunft vorbelegt wird?

1. Macht es buchhalterisch/postentechnisch einen Unterschied, ob ich Methode 1 oder 2 inkl. der manuellen Ergänzung praktiziere, um einen Sachposten mit Herkunft = Anlage zu erzeugen?
2. Was spricht (für uns) dagegen, den Bericht anzupassen, dass die zweite Gegenkontozeile mit der Anlage als Herkunft vorbelegt wird?

1. Nein, prinzipiell kann man im Fibubuchblatt immer Soll und Haben in getrennte Zeilen schreiben. Das gehört seit Anbeginn zu den Grundfesten von NAV. Manche Erweiterungen haben damit allerdings manchmal Probleme, wenn bei Eingaben nur die aktuelle Zeile mit dem Cursor berücksichtigt wird ( z.B. Skontoberechungen o.ä.). Das ist dann aber ein Fehler im Add-On bzw. auch im Standard gab es schon Hotfixes, weil dieses Szenario nicht bedacht wurde.
2. Wenn das nicht versorgt wird, ist es ein Bug. Entweder selber korrigieren oder MS melden oder beides .

1. Nein, prinzipiell kann man im Fibubuchblatt immer Soll und Haben in getrennte Zeilen schreiben. Das gehört seit Anbeginn zu den Grundfesten von NAV.

War auch meine Annahme, aber ich wollte sicher gehen ...

2. Wenn das nicht versorgt wird, ist es ein Bug.

Das ist jetzt eine ganz andere Richtung, als Anke eingeschlagen hat
@Anke, stimmt du Kai jetzt zu oder fällt dir ein Argument ein, warum das ein Feature anstatt eines Bugs sein sollte ...?
Mich würde es wundern, dass es bis heute keinem aufgefallen ist.

Ich habe aktuell keinen Zugriff neuere Datenbanken als 2009 R2 - kann das jemand vielleicht kurz in einer 2013 R2 verifizieren? Wird auch dort bei Bericht "Afa berechnen" (in Suche) + "Gegenkonto einfügen" in der Sachkontozeile keine Herkunft vergeben?

Ich stimme dem nicht zu, das ist KEIN BUG. Das ist und war schon immer so und zwar auf jedem Buchblatt !

Ich würde wenn dann empfehlen, den Report "AfA berechnen" bei der dortigen Option "Gegenkonto einfügen" zu ergänzen, dass dabei die Herkunftsart und -Herkunftsnr. aus der vorherigen Zeile in die Zeile mit dem Sachkonto geschrieben wird.

Die Funktion im Anlagen-Fibu-Buchblatt würde ich nur für die Anlagenbuchungsart "Normal-AfA" entsprechend ergänzen, welches der gesetzten Option im Report "Afa berechnen" entspricht.

VG
Anke

Ich würde wenn dann empfehlen, den Report "AfA berechnen" bei der dortigen Option "Gegenkonto einfügen" zu ergänzen, dass dabei die Herkunftsart und -Herkunftsnr. aus der vorherigen Zeile in die Zeile mit dem Sachkonto geschrieben wird.

Genau das meinte ich doch auch, aber dass es bei diesem Szenario standardmäßig nicht mitversorgt wird, stufe ich als Bug ein.

Ich würde wenn dann empfehlen, den Report "AfA berechnen" bei der dortigen Option "Gegenkonto einfügen" zu ergänzen, dass dabei die Herkunftsart und -Herkunftsnr. aus der vorherigen Zeile in die Zeile mit dem Sachkonto geschrieben wird.

Und auch ich habe in meinem Eingangsbeitrag genau das gemeint

Warum füllt der Standard für die Sachkontenzeile nicht die Herkunftsfelder? Spricht was dagegen, dies zu ergänzen?

Habe nun eine Anpassung vorgenommen, sodass auch die zusätzliche Kontenzeile über die Herkunftsinfos verfügt.
Folgendes habe ich hierzu geändert (alle Angabe ohne Gewähr!):

Codeunit 5601 FA Insert G/L Account, Funktion GetBalAcc
Neue lokale Variable: GenJnlLine2 vom Typ Record (Gen. Journal Line)

Code:

GetBalAcc.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.