In AlfBanco 5 gibt es jetzt die Möglichkeit steuerrelevante Umsätze in den Umsatzdetails mit einem Häckchen zu markieren. Das war es dann leider auch wohl schon
Irgendwelche Auswertungsmöglichkeiten für dieses Häkchen habe ich bis jetzt noch nicht herausgefunden.
Dieses Thema wurde auch schon als Wunsch im Thread http://forum.alf-banco.de/umsatzsteuers ... t3853.html angesprochen, aber anscheinend ist der Wunsch bei Alf noch nicht angekommen, zumindest wurde darauf noch nicht reagiert. Zugegeben, der Wunsch wurde für die neue Version 5 wohl etwas zu spät geäußert, aber vielleicht noch nicht zu spät, um im nächsten Update berücksichtigt zu werden. Daher äußere ich den Wunsch im AlfBanco5 Forum erneut, in der Hoffnung, dass er hier Gehör findet.
In einer Business Version wäre es wirklich wünschenwert, in den einzelnen Umsätzen steuerrelevante Details unterbringen zu können, die etwas mehr aussagen als eine einfache "Ja/Nein"-Markierung durch ein einfaches Häkchen.
Mir ist auch klar, das AlfBanco "nur" ein Onlinebanking- und kein vollwertiges Buchhaltungsprogramm ist, doch wären einfachste steuerrelevante Auswertungen schon wünschenswert. Dazu würde es im ersten Schritt schon ausreichen, wenn die steuerrelevanten Umsätze möglichst bequem und einfach identifiziert und in entsprechenden Auswertungen zusammengefasst und als Exceltabelle exportiert werden könnten, wo dann die eigentliche Auswertung stattfinden kann.
Wenn ich z.B. mehrere Ausgaben-Kategorien habe, die immer 19% Umsatzsteuer enthalten, die ich als Vorsteuer geltend machen kann, und dann eine dieser Kategorien einem Umsatz zuweise, kann ich mit dieser Info in einer Auswertung die bereits gezahlte Vorsteuer in diesen Umsatzkategorien ermitteln. Andere Ausgabenkategorien wären z.B. "Übernachtung", für die 7% Vorsteuer anfallen.
Bei den Einnahmenkategorien könnte ich die abzuführende Umsatzsteuer in einer Auswertung ermitteln. Die Differenz wäre dann entweder sie Umsatzsteuerzahllast oder -erstattung, je nach Vorzeichen.
Der einfachste Weg möglichst schnell dorthin zu kommen wäre, wenn statt eines Häkchens ein frei wählbarer Code angegeben werden könnte, wie z.B. eine Zahl als Steuerschlüssel, die dann gezielt in einer Auswertung abgefragt werden kann. Dieser Schlüssel repräsentiert dann die unterschiedlichsten Steuerarten und -sätze, die dann anderswo, z.B. in Excel ausgewertet werden können. Der Schlüsselwert sollte auch weiterhin direkt in den Umsatzdetails gespeichert werden, da sich die Mehrwertsteuer ja immer mal ändern kann und für spätere Umsätze andere Schlüssel enthalten können muss. Allerdings sollte es bei der Kategoriezuweisung (auch bei den automatischen Zuweisungsregeln) automatisch mit dem aktuellen Schlüssel gefüllt werden, damit man die Umsätze nicht noch mal extra einzeln "anfassen" muss, um den Steuerschlüssel zu hinterlegen. Dazu müssten die Kategorien neben dem Ein- und Ausgaben-Attribut ein zusätzliches Attribut erhalten, in dem man die Steuerschlüssel als Wert eingeben kann. Bei Änderungen der Steuersätze braucht dann lediglich hier der Schlüssel angepasst werden, um sicherzustellen, dass alle neuen Umsätze den neuen Steuerschlüssel erhalten.
Sicher kann man auch mit den jetzigen Kategorien solche Auswertungen konstruieren, indem man die Kategorienamen auswertet, doch ist dies äußerst umständlich und fehlerträchtig. Erstens gibt es viele Kategorien, welche einen identischen Steuersatz haben und zweitens können sich Kategorienamen auch mal ändern, bzw. in eine andere Ebene verschoben werden, oder sogar mehrfach vorkommen. Dies müsste dann in z.B. in der auswertenden Exceltabelle alles berücksichtigt werden.
Und wenn man denn schon dabei ist, könnte man den Umsatzdetails noch ein bis zwei zusätzliche Attribute spendieren, die der Anwender frei nutzen kann, z.B. zur Unterscheidung von privaten und gewerblichen Ein- und Ausgaben. Diese zusätzlichen Atrribute müssten in den Kategorien ebenfalls abgebildet werden, damit die darin enthaltenen Werte den Umsatzdetails per Regel zugewiesen werden können. So könnte mit einer Zuweisungsregel der Buchungsposten "Tanken" auf einem Privatkonto als Privatausgabe und auf dem Geschäftskonto als Gewerbliche Ausgabe mit Vorsteuer gekennzeichnet werden. Bisher habe ich 2 Hauptkategorien "Privat" und "Geschäftlich" zur Unterscheidung angelegt, mit dem Nachteil, dass jede dieser Hauptkategorien eine Unterkategorie "Tanken" enthalten muss. Zur optischen Unterscheidung nenne ich die private Kategorie "Tanken priv." und die geschäftliche "Tanken gesch.". Noch aufwändiger wird es bei den verschiedenen Versicherungsarten, die es sowohl für den privaten als auch für den geschäftlichen Bereich gibt. Und das Ganze dupliziert sich nochmals, wenn aus den Bereichen nicht nur Ausgaben, sondern auch Einnahmen zu erwarten sind, z.B. Prämienerstattungen oder Versicherungsleistungen. Dies zeigt, dass das obligatorische Einnahme-Ausgabe-Attribut in der Kategorie eigentlich überflüssig ist und einzig durch das Vorzeichen des Betrages definiert werden kann. Wenn in einer Kategorie Ausgaben und Einnahmen (z.B. Gutschriften) vorkommen können, muss wegen dieses Ein-Ausgabenattributes diese Kategorie zweimal angelegt werden.
Wie man sieht, gibt es noch viel zu tun in Sachen Steuern und Kategorien
Gruß
Siggi3001
Steuerrelevante Umsatzdetails
Hallo,
Sie können über die Lupe bei den Umsätzen die Umsätze nach "nur steuer-relevante Buchungen" filtern und das Filter-Ergebnis z.B. drucken oder exportieren.
Gruß,
ALF
das ist möglich.Dazu würde es im ersten Schritt schon ausreichen, wenn die steuerrelevanten Umsätze möglichst bequem und einfach identifiziert [...] und als Exceltabelle exportiert werden könnten
Sie können über die Lupe bei den Umsätzen die Umsätze nach "nur steuer-relevante Buchungen" filtern und das Filter-Ergebnis z.B. drucken oder exportieren.
Gruß,
ALF
Steuerrelevante Umsatzdetails
Hallo und danke für die schnelle Antwort,
dass man die Lupe anklicken kann, wusste ich noch nicht. Das wird mir bei weiteren Filteraufgaben bestimmt weiterhelfen. Nur das aktuell beschriebene Problem löst es immer noch nicht.
Bei einem Geschäftskonto sind quasi alle Buchungen steuerrelevant. Daher nützt mir eine einfache "Ja/Nein"-Markierung in Bezug auf Steuerrelevanz sehr wenig. Wichtig ist es, die Steuerarten identifizieren zu können, in der Form "Betrag enthält 19% (oder 7%) Mehrwertsteuer", oder "Steuerfreie Lieferung und Leistung" etc. Dazu wäre es viel hilfreicher, wenn statt eines Häckchens, ein selbst definierter Code bei jedem Umsatz hinterlegt werden könnte. Optimal wäre die Möglichkeit, wenn nicht nur eine Zahl, sondern ein alphanumerischer Code hinterlegt werden könnte, was die Filtermöglichkeiten noch flexibler macht. Über die Bedeutung der Codes muss das Programm nichts wissen. Die Definition obliegt nur dem Anwender. Das Programm muss nur eine Auswertemöglichkeit ähnlich wie bei den automatischen Kategorieregeln bieten, wie "Feld Code enthält...", oder "Feld Code beginnt mit...".
Beispiel für unterschiedliche Steuercodes:
UST#19%, UST#7%, UST#0%, EUST#19% usw. für die verschiedenen Umsatzsteuerarten.
Wenn im entsprechenden Feld für die Filteregel festgelegt wird:
Code enthält "UST", werden alle Umsatzsteuerbehafteten Datensätze ausgefiltert.
Beim Suchtext "EUST" nur die mit Einfuhrumsatzsteuer behafteten und
beim Suchtext "UST#19%" nur die mit 19% Umsatzsteuer und Einfuhrumsatzsteuer behafteten Umsätze. Um die in diesem Fall bei der Regel "enthält" auftretende Gleichbehandlung von UST und EUST zu vermeiden, sollte eine Filterregel "Beginnt mit:" anwählbar sein, oder der Code muss vom Anwender so umdefiniert werden, dass solche unbeabsichtigten Mehrfachfilterungen nicht auftreten können, z.B. statt "EUST" den Code "USTE" definieren.
Beim Export der so gefilterten Umsätze muss das Codefeld natürlich mit exportiert werden, damit es z.B. in einer geeigneten Excelanwendung ausgewertet werden kann. So kann mit den Suchstringfunktionen von Excel der Steuersatz hinter dem Zeichen "#" extrahiert und der Steueranteil aus dem Betrag herausgerechnet werden.
Als positiver Nebeneffekt kann dieses Codefeld außer für steuerrelevante auch für ganz andere ausgeklügelte Filteraufgaben verwendet werden. Dies bleibt ganz dem Anwender überlassen.
Das Optimum wäre, wenn statt nur eines, vielleicht zwei bis drei frei definierbare Felder zur Verfügung ständen. So könnte das erste für die Steuerarten und das zweite für Kostenstellen o.ä. und das dritte für Buchungskonten verwendet werden.
Aber ich würde auch mit nur einem Feld schon recht weit kommen. Dazu wäre es schon ausreichend, wenn das Codefeld ausreichend lange Codes aufnehmen kann, mit denen ich alle Filterkriterien unterbringen kann, wie z.B. "UST#19% Kost12345 kto8000" mit dem Leerzeichen als Trennzeichen zwischen diesen drei Unterschiedlichen Kriterien. Wie gesagt, das Programm muss der Inhalt des Codefeldes überhaupt nicht interessieren.
Damit nun nicht jeder Umsatz einzeln angefasst werden muss, um die UST-Codes zu hinterlegen, könnte dies auch schon bei der Kategoriezuweisung erledigt werden. Denn innerhalb einer Kategorie gilt meistens immer derselbe Steuersatz. Deshalb müsste die Kategorie neben dem eigentlich überflüssigen Attribut Einnahme/Ausgabe ein zusätzliches Code-Attributfeld haben, in dem der Steuercode hinterlegt werden kann und der dann bei der Kategoriezuweisung in das Codefeld des Umsatzes kopiert wird. Das Kopieren ist notwendig, weil sich die Steuersätze mit Sicherheit mal ändern werden. In dem Fall müsste dann der Code in der Kategorie angepasst werden, damit neue Umsätze den neuen Code erhalten, die alten Umsätze den alten Code aber behalten müssen.
Ich weiss, dass ist schon ein recht komplexer Wunsch, aber er ist in Teilbereichen schon sehr leicht realisierbar, wenn nur das Ja/Nein Feld für die Steuerrelevanz durch ein einfaches Textfeld ersetzt und die Filterfunktionen entsprechend angepasst werden würde. Die komfortable automatische Zuweisung durch die Kategorien ist eine Funktion, die schon etwas umfangreichere Programmierarbeit erfordert und könnte zumindest als Meilenstein für die nächste Version 6 angepeilt werden. Dabei könnten auch noch einige andere Verbesserungen für die Kategorien einfliessen, wie sie auch im AlfBanco4 Forum angesprochen wurden. Das ist aber eine andere Baustelle.
Ansonsten bin ich sehr zufrieden mit dem Programm
Gruß
Siggi3001
dass man die Lupe anklicken kann, wusste ich noch nicht. Das wird mir bei weiteren Filteraufgaben bestimmt weiterhelfen. Nur das aktuell beschriebene Problem löst es immer noch nicht.
Bei einem Geschäftskonto sind quasi alle Buchungen steuerrelevant. Daher nützt mir eine einfache "Ja/Nein"-Markierung in Bezug auf Steuerrelevanz sehr wenig. Wichtig ist es, die Steuerarten identifizieren zu können, in der Form "Betrag enthält 19% (oder 7%) Mehrwertsteuer", oder "Steuerfreie Lieferung und Leistung" etc. Dazu wäre es viel hilfreicher, wenn statt eines Häckchens, ein selbst definierter Code bei jedem Umsatz hinterlegt werden könnte. Optimal wäre die Möglichkeit, wenn nicht nur eine Zahl, sondern ein alphanumerischer Code hinterlegt werden könnte, was die Filtermöglichkeiten noch flexibler macht. Über die Bedeutung der Codes muss das Programm nichts wissen. Die Definition obliegt nur dem Anwender. Das Programm muss nur eine Auswertemöglichkeit ähnlich wie bei den automatischen Kategorieregeln bieten, wie "Feld Code enthält...", oder "Feld Code beginnt mit...".
Beispiel für unterschiedliche Steuercodes:
UST#19%, UST#7%, UST#0%, EUST#19% usw. für die verschiedenen Umsatzsteuerarten.
Wenn im entsprechenden Feld für die Filteregel festgelegt wird:
Code enthält "UST", werden alle Umsatzsteuerbehafteten Datensätze ausgefiltert.
Beim Suchtext "EUST" nur die mit Einfuhrumsatzsteuer behafteten und
beim Suchtext "UST#19%" nur die mit 19% Umsatzsteuer und Einfuhrumsatzsteuer behafteten Umsätze. Um die in diesem Fall bei der Regel "enthält" auftretende Gleichbehandlung von UST und EUST zu vermeiden, sollte eine Filterregel "Beginnt mit:" anwählbar sein, oder der Code muss vom Anwender so umdefiniert werden, dass solche unbeabsichtigten Mehrfachfilterungen nicht auftreten können, z.B. statt "EUST" den Code "USTE" definieren.
Beim Export der so gefilterten Umsätze muss das Codefeld natürlich mit exportiert werden, damit es z.B. in einer geeigneten Excelanwendung ausgewertet werden kann. So kann mit den Suchstringfunktionen von Excel der Steuersatz hinter dem Zeichen "#" extrahiert und der Steueranteil aus dem Betrag herausgerechnet werden.
Als positiver Nebeneffekt kann dieses Codefeld außer für steuerrelevante auch für ganz andere ausgeklügelte Filteraufgaben verwendet werden. Dies bleibt ganz dem Anwender überlassen.
Das Optimum wäre, wenn statt nur eines, vielleicht zwei bis drei frei definierbare Felder zur Verfügung ständen. So könnte das erste für die Steuerarten und das zweite für Kostenstellen o.ä. und das dritte für Buchungskonten verwendet werden.
Aber ich würde auch mit nur einem Feld schon recht weit kommen. Dazu wäre es schon ausreichend, wenn das Codefeld ausreichend lange Codes aufnehmen kann, mit denen ich alle Filterkriterien unterbringen kann, wie z.B. "UST#19% Kost12345 kto8000" mit dem Leerzeichen als Trennzeichen zwischen diesen drei Unterschiedlichen Kriterien. Wie gesagt, das Programm muss der Inhalt des Codefeldes überhaupt nicht interessieren.
Damit nun nicht jeder Umsatz einzeln angefasst werden muss, um die UST-Codes zu hinterlegen, könnte dies auch schon bei der Kategoriezuweisung erledigt werden. Denn innerhalb einer Kategorie gilt meistens immer derselbe Steuersatz. Deshalb müsste die Kategorie neben dem eigentlich überflüssigen Attribut Einnahme/Ausgabe ein zusätzliches Code-Attributfeld haben, in dem der Steuercode hinterlegt werden kann und der dann bei der Kategoriezuweisung in das Codefeld des Umsatzes kopiert wird. Das Kopieren ist notwendig, weil sich die Steuersätze mit Sicherheit mal ändern werden. In dem Fall müsste dann der Code in der Kategorie angepasst werden, damit neue Umsätze den neuen Code erhalten, die alten Umsätze den alten Code aber behalten müssen.
Ich weiss, dass ist schon ein recht komplexer Wunsch, aber er ist in Teilbereichen schon sehr leicht realisierbar, wenn nur das Ja/Nein Feld für die Steuerrelevanz durch ein einfaches Textfeld ersetzt und die Filterfunktionen entsprechend angepasst werden würde. Die komfortable automatische Zuweisung durch die Kategorien ist eine Funktion, die schon etwas umfangreichere Programmierarbeit erfordert und könnte zumindest als Meilenstein für die nächste Version 6 angepeilt werden. Dabei könnten auch noch einige andere Verbesserungen für die Kategorien einfliessen, wie sie auch im AlfBanco4 Forum angesprochen wurden. Das ist aber eine andere Baustelle.
Ansonsten bin ich sehr zufrieden mit dem Programm
Gruß
Siggi3001
Hallo,
danke für Ihre ausführliche Beschreibung.
Wir haben dies zu Wünsche verschoben und auch entsprechend notiert.
Leider sind Erweiterungen der Datenbank nach Veröffentlichung aufwändig, da dann bei allen Kunden die Datenbank (nochmal) konvertiert werden muss.
Wir werden aber prüfen, ob und wie wir Ihre Vorschläge umsetzen können.
Gruß,
ALF
danke für Ihre ausführliche Beschreibung.
Wir haben dies zu Wünsche verschoben und auch entsprechend notiert.
Leider sind Erweiterungen der Datenbank nach Veröffentlichung aufwändig, da dann bei allen Kunden die Datenbank (nochmal) konvertiert werden muss.
Wir werden aber prüfen, ob und wie wir Ihre Vorschläge umsetzen können.
Gruß,
ALF
Hallo,
was wäre an der Neukonvertierung der Datenbank während eines kleineren Updates denn so schlimm? Bei mir hat die Neukonvertierung beim Umstieg auf Version 5 ohne Probleme geklappt und nur wenige Sekunden gedauert. Zumindest habe ich bis jetzt noch keine Probleme feststellen können.
Gruß
Siggi3001
was wäre an der Neukonvertierung der Datenbank während eines kleineren Updates denn so schlimm? Bei mir hat die Neukonvertierung beim Umstieg auf Version 5 ohne Probleme geklappt und nur wenige Sekunden gedauert. Zumindest habe ich bis jetzt noch keine Probleme feststellen können.
Gruß
Siggi3001