AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Buchhaltung - Rundungen

Ein Thema von weisswe · begonnen am 19. Aug 2013 · letzter Beitrag vom 22. Aug 2013
Antwort Antwort
Seite 2 von 3     12 3      
Benutzerbild von Olli73
Olli73

Registriert seit: 25. Apr 2008
Ort: Neunkirchen
741 Beiträge
 
#11

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 13:25
Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.640 Beiträge
 
#12

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 13:28
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.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
arnof

Registriert seit: 25. Apr 2013
1.254 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#13

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 13:45
Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?
Wenn er (von was auch immer ) was in die Buchhaltung automatisch bringen will und es aufteilen will z.B. für die Kostenrechnung, so muss er die Buchung splitten, sonst kriegt man das da nicht rein. Deshalb muss er das von einer Buchung in zwei aufteilen und dann schlägt das Rundungsproblem zu, da 2 mal gerundet nicht einmal gerundet sind und ein cent dann die Rundungsdifferenz ist!
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#14

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 13:55
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.
fork me on Github
  Mit Zitat antworten Zitat
Benutzerbild von Olli73
Olli73

Registriert seit: 25. Apr 2008
Ort: Neunkirchen
741 Beiträge
 
#15

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 13:55
Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?
Wenn er (von was auch immer ) was in die Buchhaltung automatisch bringen will und es aufteilen will z.B. für die Kostenrechnung, so muss er die Buchung splitten, sonst kriegt man das da nicht rein. Deshalb muss er das von einer Buchung in zwei aufteilen und dann schlägt das Rundungsproblem zu, da 2 mal gerundet nicht einmal gerundet sind und ein cent dann die Rundungsdifferenz ist!
Das ist mir schon klar. Meine Frage bezog ich darauf, dass hier wohl die Schnittstelle nicht optimal ausgelegt ist: Eine Aufteilung auf Kostenstellen macht nur Sinn, wenn es sich um Kosten handelt; da gehören weder Umsatzsteuer noch Anschaffung von Anlagevermögen u.Ä. rein. Natürlich geht das nur, wenn es die Schnittstelle erlaubt, lediglich Aufwand/Kosten (Nettobetrag) zu verteilen.
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.464 Beiträge
 
Delphi 12 Athens
 
#16

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 14:02
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.
  Mit Zitat antworten Zitat
arnof

Registriert seit: 25. Apr 2013
1.254 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#17

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 14:04
  Mit Zitat antworten Zitat
Alt 19. Aug 2013, 16:57     Erstellt von Smut
Dieser Beitrag wurde von TBx gelöscht. - Grund: Verdacht auf SPAM und den damit verbundenen verschwenderischen Umgang von wertvollen Bits und Bytes
MeierZwoo

Registriert seit: 3. Dez 2012
106 Beiträge
 
#18

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 17:24
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.
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#19

AW: Buchhaltung - Rundungen

  Alt 19. Aug 2013, 21:46
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.
  Mit Zitat antworten Zitat
MeierZwoo

Registriert seit: 3. Dez 2012
106 Beiträge
 
#20

AW: Buchhaltung - Rundungen

  Alt 20. Aug 2013, 01:19
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.
Das gilr für das Erstellen von Rechnungen.

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!
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 3     12 3      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:27 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