ich nutze Financial office für die Buchhaltung und die Löhne. Ferner habe ich vor, Schritt für Schritt, dieses auch für die Fakturierung und den Zahlungsverkehr zu nutzen.
Ein ganz wichtiges Element ist für mich in meiner bestehenden (grotten-alten) Lösung die Liquiditätsvorschau welche aus den Daten der Fakturierung und des Zahlungsverkehrs gewonnen wird. Und genau diese Liquiditätsvorschau für einen Zeitraum von einer Woche bis zu drei Monaten möchte ich mit Financial office nutzen. Der Hintergrund ist hauptsächlich der, dass erstens alle Girokonten aus Prinzip als reine Habenkonten existieren und zweitens aufgrund des Geschäftsbetriebes die Einnahmen/Ausgaben stark schwanken.
Anhand dieser Liquiditätsvorschau mache ich dann recht flexibel die Planung der Projekte, schiebe meine Ausgaben dorthin wo diese von der Liquidität getragen werden können. Ändere bei Bedarf die Projektfolge. Habe auch geplante und vermutete Einnahmen bzw. Ausgaben mit in Betracht um immer zahlungsfähig zu sein, möglichst immer zu skontieren ohne zuviel Eigenkapital zu binden.
Ein „Monster“ wie „mache doch einen Excel-Export und stelle diesen dar“ ist indiskutabel. Da benötigt das manuelle durchspielen von sagen wir zehn Szenarien gleich ein paar Stunden. Die Lösung soll eher so sein: betreffende Vorgänge anpassen (Zeitpunkt und Betrag mit Wertung „sicher“, „geplant“ und „unsicher“) und bei Aufruf der Liquiditätsvorschau in Sekundenschnelle das neue Szenario ansehen.
Das mag vielleich „utopisch“ klingen, geht aber mit meiner bisherigen „gotten-alten“ Lösung sehr einfach. Anbei mal ein Screenshot.
Drei Knackpunkte sehe ich für Financial office:
Das Vorhandensein von „virtuellen“ Konten mit geplanten bzw. vermuteten Vorgängen.
Das unkomplizierte Bearbeiten der Vorgänge.
Die einfache grafische Ausgabe.
An Lösungsansätzen wie dies durchgeführt werden kann, bin ich sehr interessiert.
Ob tatsächlich alles ermöglichst werden kann, was Du brauchst/willst, kann ich ad hoc nicht sagen. Bei näherem Interesse kannst Du aber gern mal via Kontakt | lex-blog mit „Angebotsanfrage Lexware Tools“ nachfragen.
Eine kundenspezifische Software übersteigt meine Budgets, wenn es jedoch auf eine Einzellizenz in der Größenordnung 100 € bis 300 € (evtl. etwas mehr) hinausläuft ist es machbar.
Welchen Abwicklungsweg würdest Du einschlagen wollen?
unabhängig von den Kosten fürchte ich, dass das nichts wird. In MS-Money kann man erwartete Zahlungen bzw. Ausgaben erfassen. Das geht mit Quicken auch.
Im Buchhalter stehen aber nur Werte, die von heute in die Vergangenheit reichen. Eine Liquiditätsvorschau ist damit also nicht möglich.
Nicht so wie in Money. Quicken kann in der Liquiditätsvorschau nur eine Summe über alles und auch keine „virtuellen“ Konten, mit welchen erwartete Zahlungen verküpft sind, darstellen. Da ist Quicken praktisch (aus meiner Sicht) komplett unbrauchbar.
Ja, aber ich vermute, dass es für den Buchhalter ein API geben sollte mit welchem man Buchungen erstellen bzw. bearbeiten kann. Dann könnte eine externe Anwendung, so wie vorgeschlagen, die erwarteten Zahlungen verwalten und diese dann bei Bedarf gleich in den Buchhalter „verschieben“. Das sollte schon, natürlich in Zusammenarbeit mit dem Zahlungsverkehr, gehen.
wenn du „nachträgliches bearbeiten“ meinst, muss ich dich auf die die „Grundsätze ordnungsgemäßer Buchführung“ verweisen, die natürlich vom Buchhalter zu beachten sind. MS-Money ist KEIN Buchhaltungsprogramm, daher kann man dort jederzeit Zahlen ändern.
Dann könnte eine externe Anwendung, so wie vorgeschlagen, die erwarteten Zahlungen verwalten und diese dann bei Bedarf gleich in den Buchhalter „verschieben“. Das sollte schon, natürlich in Zusammenarbeit mit dem Zahlungsverkehr, gehen.
na das hast du doch jetzt auch mit MS-Money. Da kann man Buchungen im ASCII-Format exportieren und im Buchhalter importieren. Eine API für eine feste Zusammenarbeit (anklicken und rüberschieben) gibt es aber m.W. nicht.
irgendwann würde ich dieses veraltete Money und das zugehörige Windows XP gerne ersetzen. Zumal Money kein HBCI unterstützt und ich in meiner Lösung die Überweisungsträger auf einen, durch ein Skript simulieren, Drucker drucke in welchem dann aus dem Überweisungformular ein Aufruf für das cli von AqFinance gemacht wird. Alle anderen Zahlungen welche dann per HBCI reinkommen gleiche ich manuell ab. Also auch schon heftig sub-optimal.
Ja, man kann doch Buchungen welche im Stapel liegen nachträglich problemlos bearbeiten. Aber der Buchhalter ist doch nur ein Teilaspekt, inwieweit kann mir da Faktura/Auftrag bzw. der Zahlungsverkehr helfen?
irgendwann würde ich dieses veraltete Money und das zugehörige Windows XP gerne ersetzen. Zumal Money kein HBCI unterstützt
logisch, ist ja auch schon seit über 15 Jahren nicht mehr weiterentwickelt worden.
Ja, man kann doch Buchungen welche im Stapel liegen nachträglich problemlos bearbeiten.
ja schon, aber nach den aktuellen GoBS darf man den Stapel nicht „ewig“ offen lassen. Nach spätestens 8 Tagen müssen Buchungen festgeschrieben (journalisiert) werden.
Aber der Buchhalter ist doch nur ein Teilaspekt, inwieweit kann mir da Faktura/Auftrag bzw. der Zahlungsverkehr helfen?
nur hinsichtlich Ausgangsrechnungen, wobei man dort nur anhakten kann, ob eine Zahlung erfolgt ist. Mit Liquiditätsvorschau hat das nichts zu tun.
vielen Dank für Deine Antworten. Verstanden, da bräuchte es also außerhalb eine Software welche die Liquiditätsvorschau anbietet und sich mit financial office abgleicht.
Ist mir sowieso ein Rästel warum es so eine Software nicht gibt (abgesehen von Quicken mit einer sehr eingeschränkten Vorschau und irgendwelche Software für Großkonzerne).
Ist mir sowieso ein Rästel warum es so eine Software nicht gibt (abgesehen von Quicken mit einer sehr eingeschränkten Vorschau und irgendwelche Software für Großkonzerne).
da stimme ich dir zu. Money war zu seiner Zeit absoluter Spitzenreiter, auch mit der Vorschau. Quicken kann zwar heute - 15 Jahre später - vieles von dem, was Money 99 konnte, aber es kommt da noch lange nicht ran.
Microsoft war damals leider der Meinung, dass „ein so kleines Land wie Deutschland unmöglich zwei Währungen (DM und EUR) haben kann“ und hat die Entwicklung für Deutschland bzw. Europa eingestellt. Und mit unserem HBCI wollten sie sich auch auch nicht anfreunden.
das hbcifm99 kenne ich. Hatte ich mir vor Integration meiner Lösung vor vielen Jahren angesehen. Das große Problem dieser Lösung ist, dass Empfänger und Konten, soweit wie ich mich erinnern kann, „verbogen“ werden und dann die Liquiditätsplanung nicht mehr funktioniert.
ich hatte vor einigen Wochen eine ähnliche Aufgabenstellung. Bei der Prüfung auf Umsetzung zur Erstellung eines Tools waren wir recht schnell im vierstelligen Bereich. Ich denke daher, dass es hier wohl über dem vorgegebenen Budget liegen wird.
Genau diese manuellen Arbeiten möchte ich vermeiden. Der Aufwand für einen manuellen Export/Import und Abgleich ist, denke ich, höher wie das doppelte manuelle Führen der Zahlen.
