X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/6d831130c4f2ca900470592ed7dc760a4eb82241..HEAD:/doc/html/ch02s19.html diff --git a/doc/html/ch02s19.html b/doc/html/ch02s19.html index c39d32f5f..a40ec5a21 100644 --- a/doc/html/ch02s19.html +++ b/doc/html/ch02s19.html @@ -1,27 +1,21 @@
-In der Schweiz hat die kleinste aktuell benutzte Münze den Wert - von 5 Rappen (0.05 CHF).
Auch wenn im elektronischen Zahlungsverkehr Beträge mit einer - Genauigkeit von 0.01 CHF verwendet werden können, ist es trotzdem nach - wie vor üblich, Rechnungen mit auf 0.05 CHF gerundeten Beträgen - auszustellen.
In kivitendo kann seit der Version 3.4.1 die Einstellung für eine - solche Rundung pro Mandant / Datenbank festgelegt werden.
Die Einstellung wird beim Erstellen der Datenbank bei
- Genauigkeit festgelegt. Sie kann anschliessend über
- das Webinterface von kivitendo nicht mehr verändert werden.
Abhängig vom Wert für default_manager in
- config/kivitendo.conf werden dabei folgende Werte
- voreingestellt:
0.05 (default_manager = swiss)
0.01 (default_manager = german)
Der Wert wird in der Datenbank in der Tabelle defaults
- in der Spalte precision gespeichert.
In allen Verkaufsangeboten, Verkaufsaufträgen, Verkaufsrechnungen - und Verkaufsgutschriften wird der Endbetrag inkl. MWST gerundet, wenn - dieser nicht der eingestellten Genauigkeit entspricht.
Beim Buchen einer Verkaufsrechnung wird der Rundungsbetrag - automatisch auf die in der Mandantenkonfiguration festgelegten - Standardkonten für Rundungserträge bzw. Rundungsaufwendungen - gebucht.
(Die berechnete MWST wird durch den Rundungsbetrag nicht mehr - verändert.)
Die in den Druckvorlagen zur Verfügung stehenden Variablen
- quototal, ordtotal bzw.
- invtotal enthalten den gerundeten Betrag.
- Achtung: Werden Verkaufsbelege in - anderen Währungen als der Standardwährung erstellt, so muss in kivitendo - ab Version 3.4.1 die Genauigkeit 0.01 verwendet werden.
Das heisst, Firmen in der Schweiz, die teilweise - Verkaufsrechnungen in Euro oder anderen Währungen erstellen wollen, - müssen beim Erstellen der Datenbank als Genauigkeit 0.01 wählen und - können zur Zeit die 5er Rundung noch nicht nutzen.
Bis Version 3.0 wurde "closedto" ("Bücher schlieÃen zum") als + Grundlage für das Startdatum benutzt. SchlieÃt man die Bücher allerdings + monatsweise führt dies zu falschen Werten.
In der Mandantenkonfiguration kann man dieses Verhalten genau + einstellen indem man:
weiterhin closed_to benutzt (Default, es ändert sich nichts zu + vorher)
immer den Jahresanfang nimmt (1.1. relativ zum + Stichtag)
immer die letzte Eröffnungsbuchung als Startdatum nimmt
- mit Jahresanfang als Alternative wenn es keine EB-Buchungen + gibt
- oder mit "alle Buchungen" als Alternative"
mit Jahresanfang als Alternative wenn es keine EB-Buchungen + gibt
immer alle Buchungen seit Beginn der Datenbank nimmt
Folgende Hinweise zu den Optionen: Das "Bücher schlieÃen Datum" + ist sinnvoll, wenn man nur komplette Jahre schlieÃt. Bei Wirtschaftsjahr + = Kalendarjahr entspricht dies aber auch dem Jahresanfang. "Alle + Buchungen" kann z.B. sinnvoll sein wenn man ohne Jahresabschluà + durchbucht. Eröffnungsbuchung mit "alle Buchungen" als Fallback ist z.B. + sinnvoll, wenn man am sich Anfang des zweiten Buchungsjahres befindet, + und noch keinen Jahreswechsel und auch noch keine EB-Buchungen hat. Bei + den Optionen mit EB-Buchungen wird vorausgesetzt, daà diese immer am 1. + Tag des Wirtschaftsjahres gebucht werden. Zur Sicherheit wird das + Startdatum im Bilanzbericht jetzt zusätzlich zum Stichtag mit angezeigt. + Das hilft auch bei der Kontrolle für den Abgleich mit der GuV bzw. + Erfolgsrechnung.