|
Buchhaltung - Rundungen
Hallo!
Ich hab folgendes Problem bei meiner Exportfunktion in die Buchhaltung. Es sollen Rechnungen + Auteilungen nach Kostenstellen in die Buchhaltung exportiert werden. Jedoch muss die "Summe der Auteilungen" = Rechnungssumme sein. Problem ist die Rundung auf 2 Kommastellen. Beispiel: Rechnungssumme Ges = 37,13€ (20% Steuer = 7,43€) Aufteilung K1 (50%) = 18,57€ (20% Steuer = 3,71€) Aufteilung K2 (50%) = 18,57€ (20% Steuer = 3,71€) Aufteilungen K1+K2 = 37,14€ (20% Steuer = 7,42€) Ok, hab mir also gedacht ich überprüft die letzte Position und addiere/subtrahiere die Differenzen (0,01€). Jedoch bekomme ich in der Zeilenvalidierung einen Fehler (siehe Beispiel). Korrektur K2 = 18,56€ Steuerkorr. = 3.72€ Fehler Steuer K2 = -> 20% von 18,56€ = 3.71€ (und nicht 3.72€) Habt ihr eine Idee oder Lösungsvorschlag? |
AW: Buchhaltung - Rundungen
Runde nur zur Anzeige
|
AW: Buchhaltung - Rundungen
ja, das liebe ich und wenn man das einem erklärt (z.B. Steuerfuzi, Prüfer, usw) verstehen die das nicht ....
Scheint ja für Österreich zu sein, leider gibt es da keine Lösung, hier kannst nur Probieren was deine Buchhaltung durchlässt. In D ist ja DateV der Standard, die nehmen entweder nur den Brutto oder den Netto Betrag an und rechnen sich das selbst aus. |
AW: Buchhaltung - Rundungen
Wenn man gerundeten Werten arbeitet und diese aufteilt kommt es automatisch zu Rundungsdifferenzen :pale:
|
AW: Buchhaltung - Rundungen
Damit sich die Rundungsfehler nicht summieren intern mit allen Stellen rechnen, zur Ausgabe aber z.B. sowas:
Delphi-Quellcode:
ShowMessage(Format('%.2f', [Value]));
|
AW: Buchhaltung - Rundungen
Zitat:
Leider verlang die Schnittstelle max. 2 Kommastellen... |
AW: Buchhaltung - Rundungen
Es ist immer toll wenn man aus ungenauen Daten/Zahlen genauere generieren/berechnen soll.. :lol:
|
AW: Buchhaltung - Rundungen
dann musst Du mal den Entwickler der Schnittstelle kontakten, wie er sich das vorstellt oder ob er nicht ein Designproblem in seiner Schnittstelle hat. Du wirst ja nicht der erste mit dem Problem sein :roll:
|
AW: Buchhaltung - Rundungen
Zitat:
Sonst müssen sie auf ein anderes neues Rechnungswesensystem umsteigen... :wink: |
AW: Buchhaltung - Rundungen
Er muss sowieso was machen SEPA kommt ja auch in Ö
|
AW: Buchhaltung - Rundungen
Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?
|
AW: Buchhaltung - Rundungen
Das Problem tritt ja grundsätzlich nur bei der Steuer auf (die einzelnen Preise müssen ja immer den korrekten Wert ergeben).
Es gibt da zwei Möglichkeiten: 1.) Die Steuer nicht als Betrag, sondern als Merkmal übergeben (-> 20%, oder 19%, oder 7,5% etc.). Damit ist die Buchhaltung in der Pflicht, die Steuer selber zu berechnen. 2.) Beim Export nimmst Du die Einzelposten, rechnest pro Posten die Steuer aus, und merkst sie Dir im Programm mit *allen* Nachkommastellen. Du rundest und exportierst erst jetzt die Summe der ungerundeten Steuerbeträge (sollte die Buchhalterisch richtige Summe ergeben). Damit hast Du auch eine Kontrollmöglichkeit: Du kannst das nochmal nachprüfen in dem Du die Steuer nochmal auf die Gesamtsumme berechnest - das müsste dem Wert dann entsprechen. Achtung: Das funktioniert nur solange, wie Du einen einheitlichen Steuersatz hast. In DE mit Einzelposten mit dem verminderten Umsatsteuertsatz klappt das z.B. nicht. |
AW: Buchhaltung - Rundungen
Zitat:
|
AW: Buchhaltung - Rundungen
Man müsste die Rundungsdifferenzen auffangen und dann die Teilbeträge korrigieren.
Dann sind die Teilbeträge zwar nicht mehr genau kaufmänisch gerundet aber die Summe der Teilbeträge ergibt wieder den Gesamtbetrag. Das ist nicht so einfach aber ich denke es lohnt sich hier eine Klasse zu bauen denn das Problem gibt es bei allen Rechnungen bei denen Teilbeträge aus Prozentrechnung entstehen. |
AW: Buchhaltung - Rundungen
Zitat:
|
AW: Buchhaltung - Rundungen
Da der Mehrwertsteuerbetrag scheinbar auf den Rechnungsbetrag(je Mwst.) berechnet wird,
sollte auch die Buchung in vergleichbarer Form erfolgen.
Code:
Soll Haben Steuersatz KST Betrag
Debitor Zwischenkonto 20% Rechnungs(teil)betrag 20% Zwischenkonto Erlöskonto1 - Kst1 Nettoteilbetrag1 Zwischenkonto Erlöskonto2 - Kst2 Nettoteilbetrag2 Debitor Zwischenkonto 10% Rechnungs(teil)betrag 10% Zwischenkonto Erlöskonto3 - Kst3 Nettoteilbetrag3 Zwischenkonto Erlöskonto4 - Kst4 Nettoteilbetrag4 usw. |
AW: Buchhaltung - Rundungen
:thumb:
|
AW: Buchhaltung - Rundungen
Was hat die MWSt in den Kostenstellen zu suchen? Die MWst ist ein eigenes KTO, die KST bekommen eh nur Nettowerte. D.h. bei der Buchung werden Nettowert und Vorsteuer eh schon getrennt gebucht und dort müssen, wenn dies mit Abschlagsverfahren gerechnet wird, auf den RN-Betrag angepaßt werden. Dann wird der Netto-Betrag auf die KST verteilt.
Rundungsfehler können eh nur entstehen, wenn statt der Einzelbuchung Netto und Vorsteuer im Abschlagsverfahren gebucht wird, was grundsätzlich falsch ist und seit zig Jehren überholt. Außerdem gibt man keine Gleitkommawerte in der Buchhaltung ein, sondern nur Integerwerte, die nur in der Anzeige und Ausdruck ein Komma (und Dezimalpunkt) spendiert bekommen. Eine Schnittstelle, die Gleitkommawerte erwartet, kannst Du getrost in die Tonne hauen. |
AW: Buchhaltung - Rundungen
Vor ettlichen Jahren hatte ich mal ein ähnliches Problem und habe einfach gegoogelt. Danach gibt es eine -in Deutschland- verbindliche Vorgehensweise bei der Berechnung Netto/Brutto, die auch die bekannten Rundungsdifferenzen erschlägt. Das Finanzamt/Buchhaltung ist ja nicht nur blöd.
Soweit ich mich erinnere, wird stinknormal gerundet, und zwar auf den nächstgelegenen Centbetrag. Die Bruttosumme wird also gerundet und zur Anzeige der MwSt-Steuer Netto von Brutto abgezogen. Peitscht mich, wenn ich mich irre, aber ich bin mir 100% sicher, das das eindeutig geregelt ist. Auch in anderen Ländern. |
AW: Buchhaltung - Rundungen
Zitat:
Hier wird aber das "Problem" buchen von eingehenden (Dritt)Rechnungen behandelt, in denen Netto, MWst und Brutto ja ausgewiesen sind und vom Ersteller der Rechnung bereits gerundet wurden. Diese Werte nocheinmal im Ab- oder Aufschlagsverfahren neu zu berechnen ist schon schlichtwegs falsch! Bei einem meiner Kunden tritt so ein Fall auch immer wieder auf: Einer dessen Kunden überweist ständig einen Cent mehr, als in den Rechnungen ausgewiesen ist, weil die dort wohl auch nicht Netto und MWSt als Beträge buchen sondern neu berechnen. Und da es dabei nicht nur auf den CPU/CoCPU-Typ (FPU) ankommt, sondern auch auf dessen Settings und auf die von deren Programm intern verwendeten Typen oder gar Software-Rundungsalgorithmen wird es nie zu einer Übereinstimmung kommen. Ist auch garnicht nötig, wenn man korrekt bucht. Es wird nicht die selbst errechnete MWSt als Vorsteuer gebucht, sondern die in der Rechnung ausgewiesene und vom Rechnunsgsteller als MWSt abgeführte. Nur bei groben Schnitzern wird neu berechnet und dann "Bitte buchen Sie gleichlautend ..." ein entspr. Schriftverkehr eingeleitet. Dieses bei jedem Rundungs-Cent zu tun, wäre wohl etwas overdressed. Und Buchhaltungs-Soft oder Schnittstellen, die nicht die ausgewiesenen Netto- und MWSt-Beträge buchen/übertragen kann, sondern unbedingt neu berechnen will, gehört einfach in die Tonne! |
AW: Buchhaltung - Rundungen
Zitat:
Zitat:
|
AW: Buchhaltung - Rundungen
Zum Ab/Aufrunden und Vorschriften/Gesetzen/Verordnungen dazu:
Es ist dem FA u.a. ziemlich egal, ob man kaufmännisch oder mathematisch rundet, sich also über 1/10 Cent Rundung un damit über +/- 1 bis 3 Cent pro Rechnung Gedanken macht (theoretisch bis 3 Cent bei bis drei MWSt-Arten in den verschiedenen Ländern). Denn wenn der Kreditor 1 Cent weniger MWSt ausweist, kann der Debitor auch nur 1 Cent weniger Vorsteuer geltend machen - und umgekehrt. Und wenn die Fälle auftreten, daß der Debitor die MWSt neu mit Rundungsdifferenz berechnet und überweist (+/- 1 bis 3 Cent), wird dies eben als Skonto oder Differenz verbucht, damit das RN-Soll augeglichen ist. Die einzige Vorschrift über runden, die es gegeben hat, war in dem Zeitraum, als es den EUR schon als Buchgeld gab aber die nationalen Währungen der am EUR teilnehmenden Länder noch ges. Zahlungsmittel waren - also in diesen drei Jahren des Übergangs, als es zwischen den teilnehmenden Länderwährungen und dem EUR einen festen Umrechnungsfaktor gab (NICHT KURS, darauf wurde extra hingewiesen, daß dies ein FAKTOR war). Damals war vorgeschrieben, daß wenn von einer nationalen, teilnehmenden Währung zu einer anderen nationalen, teilnehmenden Währung umgerechnet wurde nicht direkt mit den zwei Faktoren umgerechnet werden durfte (und einmal gerundet), sondern die eine Währung erst mit deren Faktor in EUR incl. Rundung umgerechnet werden mußte, dann diese gerundeten EUR mit dem zweiten Faktor in die andere Währung, wieder mit Rundung. Das war mehr eine juristische Spitzfindigkeit denn eine sinnvolle Vorgabe, weil es rein juristisch zwischen zwei nationalen Währungen ja keinen Umrechnunsgfaktor gab - immer nur jeweils von nationaler Währung zum EUR. Ansonsten gibt es (zumindest in D) nur noch die KANN-Vorgabe, daß Endsummen von Steuererklärungen pro Erklärungsart auf ganze EUR ABgerundet werden dürfen. Und ein Programmmierer hat sich darüber eh nur Gedanken zu machen, als er den Vorgaben der Fachleute zu folgen und diese umzusetzen hat - eigene Entscheidungen an den Prinzipien der Buchhaltung vorbei sind eh nicht zulässig! |
AW: Buchhaltung - Rundungen
Wir haben in unserem Programm mehrere Finanzbuchhaltungen angebunden...
Da gibt es wirklich riesige Unterschiede! Von "die FiBu rechnet selbst" bis hin zu "ich muss alles aufsplitten und selber richtig rechnen". Im letzteren Fall buchen wir die Rundungsdifferenzen automatisch auf ein steuerfreies Konto in der FiBu. Da die Differenzen mal positiv und mal negativ sein können, hat man am Ende des Abrechnungszeitraumes immer nur wenige Cent auf diesem Konto. Und die dürfen dann gern (auch wenn später mal geprüft wird) vernachlässigt werden. :-D |
AW: Buchhaltung - Rundungen
Zitat:
|
AW: Buchhaltung - Rundungen
Zitat:
Und ein Differenz-KTO ist normal, hatte ich oben (bei RN) als Skonto oder allgemein als Differenz angeführt. Nur ist es ein ganz normales KTO, welches in die Bilanzsumme eingeht! Und eben NICHT vernachlässigt wird, sonst würde die Salden-Prüfung Fehler auswerfen. Denn was einige Leute nicht bedenken, wenn ein klassischer Buchhalter bei einer Salden-Differenz von einem Pfennig auch tagelang nach dem Fehler sucht: ein Pfennig Salden-Differenz kann auch aus mehreren fehlerhaften Buchungen mit großen Beträgen entstanden sein. |
AW: Buchhaltung - Rundungen
Zitat:
Wobei dann bei Grundsätzlichem immer wieder die Erfahrung greift, daß es wohl zu schwierig ist und auch einige Programmierer über die Grundsätze einfach hinweggehen und meinen, sie dürften so programmieren, wie ihre Meinung ist. Bei Erstellen eines Buchhaltungsprogrammes oder auch den Buchungen bzw. Ausgaben einer Warenwirtschaft zur Buchhaltung(sschnittstelle) benötigt man - einen guten Buchhalter (mit Grundsätzen), - einen Steuerberater (mit Grundsätzen), - zwei Juristen - evtl. einen guten Designer für Bildschirm und vorallem Ausdrucke und - einen halben Programmierer - denn mehr als +/- und Prozentrechnung ist eh nicht drin; augenommen evtl. das db-Design. |
AW: Buchhaltung - Rundungen
Danke euch Allen für die hilfreichen Lösungsvorschläge.
Problem ist wirklich nur die Schnittstelle. Jetzt werden die Rundungsfehler MANUELL im Buchhaltungsprogramm korrigiert. Das wollte ich eigentlich mittels "richtigerem" Export verhindern. Mal schauen ob sich an der Schnittstelle was drehen lässt. Nochmals Danke an euch alle!!! :) Grüße, Werner |
AW: Buchhaltung - Rundungen
Zitat:
Und selbstverständlich wird KEIN Konto bei der Bilanz "vernachlässigt". Aber für die Frage spielte das nun wirklich keine Rolle... |
AW: Buchhaltung - Rundungen
Selbst gelöscht, keine Lust auf endlose Diskussionen ,-)
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 19:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz