Office: Anfängerfrage bzgl MWst Berechnung

Hallo!Ich habe gerade angefangen Access und VBA zu lernen!Nun habe ich schon mein erstes Problem!Ich habe mir eine Tabelle erzeugt,mit zwei Feldern,Brutto und MwSt,daraus habe ich ein Formular gemacht!Nun habe ich weiterhin in VBA eine Funktion geschrieben,die folgendermaßen aussieht:
Public Function MWSt(Brutto)
MWSt=Brutto/116 * 16
End Function
Im Formular habe ich jetzt dem Bruttofeld den Namen Brutto zugeordnet,
dem Feld MWSt den Namen MWSt und als Steuerelementinhalt: =MWSt([Brutto])
Wenn ich nun in das Feld Brutto einen Wert eingebe,dann kommt im MWSt.-Feld immer #Fehler,was mache ich denn falsch?Ich habe keine Ahnung...Über eine Antwort würde ich mich freuen!

:)

 

Hallo
Werte die man zu jederzeit berechnen kann sollte man nicht speichern.
Im einem ungebundenen Feld im formular kannst besser die Berechnung direkt eingeben.
=[Brutto]/116*6

 

Du kannst das Formular rechnen lassen besser aber die Abfrage (Spalte in der Abfrage) 'berechnete_spalte: spalte1*spalte2' von links nach rechts. Die Abfrage 'speist' dann Formular UND Bericht. Das ist der saubere Weg.

Grundsatz im DB Design: Berechnete Werte NIE speichern.


Mark B

 

Vielen Dank für die schnellen Antworten!Wollte auch nur vom Prinzip her verstehen,wenn ich eine Funktion schreibe,warum ich die dort nicht aufrufen kann...Das müßte doch auch gehen,obwohl es nciht gut ist...

 

Hallo,

du darfst berechnete Formularfelder nicht so benennen wie eines der Datenfelder im Ausdruck. Am besten, du gewöhnst dir von Anfang an an (nein, ich stottere nicht *wink.gif*), Steuerelemente eindeutig zu benennen, z.B. tabMWST für das Datenfeld in der Tabelle und frmMWST für das Formularfeld, so dass du sie leicht interpretieren und zuordnen kannst.

 

Hallo,

Thema ist ja "Anfängerfrage zur MWSt-Berechnung" - daher mal ein klein wenig Off Topic, wie schnell sich das zur ausgedehnten, steuerrechtlichen UND auch programmiertechnischen Frage hochschaukeln kann.
Zwar wird hier im Thread nur der Einsatz einer Funktion zur Berechnung geübt, aber ich erlaube mir mal an dieser Stelle einen kleinen Ausflug - und wenn's nur als allgemeiner Hinweis an alle Mehrwertsteuerentwickler und Mehrwertsteuerberechner und solche, die es werden wollen/müssen, dient.

Die Mehrwertsteuersätze in Codierungen/Formeln abzulegen, ist schon mal falsch. Die Sätze ändern sich (16% wurde kürzlich zu 19% und die Erhöhung auf 22% läßt sehr wahrscheinlich auch nicht mehr lange auf sich warten . . .). Desweiteren gibt es unterschiedliche Sätze zu unterschiedlichen Warentypen (z. B. Lebensmittel, Bücher, Zeitschriften: 7%). Daher sollten Artikel und ihre Mehrwertsteuersätze in einer separaten Artikeltabelle gepflegt werden und von dort aus verwendet werden.
Beim Anlegen eines Bestellpostens/Rechnungspostens würde dann der Mehrwertsteuersatz, wie er gerade in der Artikeltabelle aktuell eingetragen ist, (automatisch) übernommen werden - das ist keine Redundanz, sondern eine steuerrechtliche Notwendigkeit, da der Mehrwertsteuersatz zum Zeitpunkt der Bestellung/Lieferung festgeschrieben werden muß. Würde man in einer Rechnungspostentabelle lediglich auf das Mehrwertsteuerfeld der Artikeltabelle verweisen und erhöht sich dann eines Tages die Mehrwertsteuer, würde dies rückwirkend für alle alten Rechnungen gelten. Die Nachvollziehbarkeit ist nun nicht mehr gegeben, zu welchem Satz die Mehrwertsteuer ursprünglich errechnet wurde. Nachträgliches Ausdrucken einer Rechnung z. B. würde den Rechnungsbetrag verändern und vermeintlich eingenommene Steuern ausweisen, die man nicht abgeführt hat (sehr problematisch).

Gerade beim elektronischen Speichern/Verwalten von Rechnungen schreiben die Finanzbehörden die jederzeitige Nachvollziehbar vor.

Und genau so, wie es unterschiedliche Mehrwertsteuersätze gibt, entsteht auch noch eine differenzierte Anwendung der Berechnung in Rechnungen.

Wenn man sich - wie oben ausgeführt - darauf verständigt hat, zu jedem Artikel den jeweils aktuell gültigen Mehrwertsteuersatz zu führen, kann man diesen jetzt beim Anlegen einzelner Rechnungsposten nach Auswahl von Artikeln aus der Artikeltabelle automatisch übernehmen lassen und in der Rechnungspostentabelle festschreiben (als aktuell gültigen Mehrwertsteuersatz zum Zeitpunkt der Rechnungserstellung).

Immer? Eben nicht, denn es kommen noch weitere Aspekte hinzu.

Ein Aspekt aus steuerrechtlicher Sicht ist der Ort und der Zeitpunkt der Lieferung. Beim Anlegen einer Rechnung bzw. beim Anlegen dazugehöriger Rechnungsposten (aus Artikeltabelle) ist weiterhin der Kunde zu berücksichtigen, um die Mehrwertsteuerpflicht überhaupt erst einmal feststellen zu können. Das setzt jetzt wiederum voraus, daß die Anwendung es auch erlaubt, das Land eines Kunden zu erfassen. Von diesem Land muß die Anwendung jetzt auch noch wissen, ob es ein EU-Land ist oder nicht - also muß im Idealfall wiederum eine Ländertabelle her, die diese politischen Informationen bereithält und die dort ebenfalls pflegbar sind.

Noch nicht genug:
Wenn der Kunde im Ausland lebt und die Lieferung dorthin erfolgen soll, muß weiterhin geprüft werden:
Ist das Land der Lieferung ein EU-Land (grundsätzlich erst einmal Mehrwertsteuerpflicht) - oder ist es kein EU-Land (keine Mehrwertsteuerpflicht; hierbei ergibt sich übrigens eine "philosophische" Frage, ob man Bruttopreise in der Artikeltabelle pflegt und "rausrechnet" - dann verkauft man an gewerbliche Kunden in Nicht-EU-Ländern teurer als an gewerbliche Kunden in EU-Ländern, weil letztere den Vorsteuerabzug im Unterschied zu ihren Kollegen z. B. in der Schweiz oder in Timbuktu geltend machen können. Oder ob man eben Nettopreise in der Artikeltabelle pflegt und "draufschlägt").

Immer noch nicht genug:
Hat man bei der anstehenden Mehrwertsteuerberechnung (ob oder ob nicht) nun festgestellt, daß es sich um eine Lieferung ins EU-Ausland handelt, kommt weiterhin eine evtl. vorhandene Umsatzsteuer-ID des Kunden ins Spiel (bei gewerblichen Kunden). Ist dem Rechnungsaussteller/Lieferanten diese ID bekannt (muß halt in den Stammdaten gepflegt werden), wird wiederum keine Mehrwertsteuer berechnet - man kann also noch nicht einmal sagen, daß Lieferungen ins EU-Ausland grundsätzlich mehrwertsteuerpflichtig sind.
Auch besteht eine Pflicht, jährlich separat alle Umsätze zu Lieferungen ins EU-Ausland zu melden/zu listen, welche an Kunden mit ausländischer Umsatzsteuer-ID getätigt wurden.

Desweiteren muß einem Anwendungsentwickler innerhalb dieser Mehrwertsteuerzusammenhänge klar sein, wie die Umsatzsteuervoranmeldungen auszusehen haben.
Erfolgen diese nach "vereinbartem Entgelt", so reichen z. B. monatliche Listen aller erfassten Rechnungen bzw. deren Rechnungsposten (es können ja zeilenweise vereinzelt ganz unterschiedliche Mehrwertsteuersätze vorliegen, die separat zu summieren wären).
Wird hingegen nach "vereinnahmtem Entgelt" abgeführt, sind Zahlungseingangslisten zu erstellen (in der Regel monatlich oder quartalsmäßig), wobei zu jeder eingegangenen Zahlung die ursprünglich festgeschriebenen Mehrwertsteuersätze zur Berechnung der jeweils abzuführenden Vorsteuer (Mehrwertsteuer) herangezogen werden müssen. Das kann z. B. dann "lustig" werden, wenn eine solche Rechnung mehrere Artikel unterschiedlicher Mehrwertsteuersätze enthielt und die Zahlung lediglich einen Teilbetrag der Gesamtrechnungssumme aufweist - aber das lasse ich jetzt mal lieber . . .

Als nicht minder "lustig" (aus entwicklungstechnischer Sicht) können sich auch Stornierungen von Rechnungen herausstellen, wenn eine Rechnung ins EU-Ausland z. B. ursprünglich Mehrwertsteuer enthielt, diese bereits vom Rechnungsaussteller/Lieferanten in seiner Vorsteueranmeldung auch geltend gemacht und abgeführt wurde und nun als negative Mehrwertsteuer vom Finanzamt sozusagen wieder "zurückgeholt" werden soll, der betroffene Kunde aber zwischenzeitlich in ein Nicht-EU-Land umgezogen ist und die Anwendung nun versucht, für die Storno-Rechnung/Gutschrift nach oben geschilderter Vorgehensweise den Mehrwertsteuersatz zu ermitteln - aber das lasse ich jetzt auch mal lieber . . .

Im Grunde wählt man in seinem Bestell-/Rechnungssystem die jeweiligen Artikel per Kombinationsfeld aus. Das Kombinationsfeld (Artikeltabelle) führt in einer Spalte den aktuell gültigen Mehrwertsteuersatz des Artikels (also z. B. 19% oder 7%). Im AfterUpdate-Ereignis schnappt man sich diesen Wert und kommt nach Prüfung aller zuvor geschilderten Umstände entweder exakt auf diesen Prozentsatz oder eben auf 0%, was im Prinzip dann auf eine mehr oder weniger einfache Rechenformel hinausläuft, welche die verschiedenen Zustände/Gegebenheiten wie Inland, EU-Land ja oder nein (wenn EU-Land ja, Umsatzsteuer-ID vorhanden oder nicht) als True oder False errechnet. In der jeweiligen Multiplikation des in der Artikeltabelle aktuell ermittelten Mehrwertsteuersatzes mit True oder False - bzw. abs(-1) oder 0 - ergibt sich nun zeilenweise pro Artikel jeweils der korrekt anzuwendende Mehrwertsteuersatz, welcher deshalb so exakt ist, weil er genau den Mehrwertsteuersatz bezüglich 1. Artikel, 2. Ort und 3. Zeitpunkt der Lieferung/Rechnungsstellung berücksichtigt (Steuergesetzgebung) und zu jedem beliebigen späteren Zeitpunkt nachvollzogen werden kann. Selbst dann, wenn sich die politische EU-Landschaft inzwischen verändert hat und/oder die Rechnung vielleicht zu diesem späteren Zeitpunkt hinsichtlich Mehrwertsteuer ganz anders ausfallen würde.

Wie eingangs erwähnt - eine Off Topic Betrachtung.
Aber vielleicht zeigt sie, daß es nicht damit getan ist, auf einen Betrag global stets einen Prozentsatz anzuwenden - jedenfalls in professionellen Anwendungen kann das auch sehr schnell übel ausgehen, weil Finanzämter nun mal empfindliche Behörden sind.
Und wenn z. B. nach einer allgemeinen Mehrwertsteuererhöhung dann durch falsch durchdachte Bezüge nachträglich alte Rechnungen verändert würden (ohne, daß man das ja eigentlich beabsichtigt hätte), dann ist auch schnell von Umsatzsteuerhinterziehung die Rede - zumindest stößt jeder Betriebsprüfer mindestens schon mal auf eine Ungereimtheit.

Eben weil dieser Thread als eine Anfängerfrage betitelt wurde, wollte ich - in Kenntnis der Tatsache, daß so etwas in vielen eingesetzten Anwendungen falsch gehandhabt wird - mal gerade in erster Linie für Anfänger diese Problematiken aufgreifen, damit ich jetzt nicht abschließend schreiben muß:
So long und möglicherweise auch schon mal viel Spaß beim "Umcoden" und Umstrukturieren aller alten Anwendungen . . .

Gruß
Stephan

 

\@Stephan
Gut gebrüllt Löwe! Und das sollte jeder Wissen, der auch nur für seine Imbissbude oder Kiosk so eine Anwendung programmiert. Buchhaltungs und Rechnungsprogramme bekömmt besser für kleines Geld gekauft.

 

\@kama
Jo, nur machen der Imbissfritze und der Kioskheimer eine Einnahmen-/Ausgabenrechnung (meist im Schulheft auf Karopapier und wenn's hochkommt mit T-Konten) - das ist was ganz anderes, als hier vorgestellt.

Bereits ein kleiner bis mittlerer Zeitschriftenverlag mit gerade mal vielleicht 15.000 Zeitschriftenabonnenten im In- und weltweiten Ausland und annähernd 25.000 Abo- und Anzeigenrechnungen pro Jahr erfordert da schon einiges mehr. Aber das weißt Du ja auch *wink.gif*

Gruß
Stephan