Moin.
Gibt es hier schon Neuigkeiten?
Wie lange soll es denn noch "in Diskussion" sein, bis endlich ein seit nunmehr 3 Jahren als "demnächst" angekündigtes essentielles Feature tatsächlich geliefert wird?
Wir haben auch dieses Jahr wieder das Jahresupdate gekauft und geben die Hoffnung nicht auf, aber so langsam müsste wirklich mal etwas passieren.
Als Anregung für die Diskussion:
Wenn es auf RPC oder REST hinausläuft, wäre dafür eine eigenständige Server-Anwendung ratsam.
Ansonsten müsste die Taxpool Anwendung ja die ganze Zeit laufen und ich halte es für einigermaßen "gefährlich", wenn ein Anwender unbedarft oder aus Versehen dann den API Server schließen könnte, weil er es so gewohnt ist.
Tatsächlich würde aber wohl eine c++ dll API bereits alles bieten, was sich ein Entwickler wünscht. Darauf ließe sich ja jedes beliebige Protokoll als Mini-Server selbst implementieren (bzw. implementieren lassen).
Effektiv sind wahrscheinlich gar nicht so viele Methoden notwendig. Sobald Entwickler in der Lage sind, die Methoden des Programms zum verschlüsseln und entschlüsseln der Datensätze zu nutzen, könnte das meiste direkt in der DB erledigt werden.
So eine API erledigt ja üblicherweise regelmäßige Aufgaben in großer Anzahl, sodass sie in erster Linie Anwendung bei Buchungen, Rechnungen, Artikeln, Kunden und Berichten Anwendung finden dürfte.
Alles andere ist imho für ein MVP erstmal entbehrlich. Die Elster Meldungen oder der Jahresabschluss dürfte kaum in den Scope einer (ersten) API fallen.
Ideal wäre es außerdem, wenn vielleicht im nächsten Schritt dann auch über die andere Richtung (Hooks) nachgedacht würde, sodass Taxpool eine externe Software benachrichtigen kann, wenn ein zuvor definiertes Ereignis eintrifft (z.B.: Wenn neuer Kunde angelegt -> Nachricht an CRM / Newslettersystem)
Bei allen diesen Überlegungen sollte die Schnittstelle immer von Taxpool Seite vorgegeben sein und nicht durch einen Drittanbieter, ganz egal, wie "beliebt" dieser ist. Ich halte z.B. die direkte Einbindung von WooCommerce Import immernoch für einen Fehler, der zu erhöhtem Wartungsaufwand führt. Ihr könnt nicht alle möglichen Drittanbieter unterstützen. Wer das möchte, sollte das über eine passende Middleware selbst realisieren können (Taxpool -> Middleware -> Drittanbieter anstatt Taxpool -> Drittanbieter), und ihr solltet stattdessen nur eine einzige aber dafür möglichst vollständige Schnittstelle pflegen.
Ich freue mich, wenn das Thema wieder etwas an Fahrt aufnimmt. Taxpool ist immernoch Spitzensoftware zu einem tollen Preis, aber leider auch immernoch eine Insellösung.
"Keine individuellen Konten" ist bei mir standardmäßig deaktiviert und auch ausgegraut, wenn ich die Lieferantenrechnung erfasse, ebenso wie "Spaltenweise Berechnung".
Dann lag ich ja mit der Differenzbuchung gar nicht so falsch.
Featurevorschlag:
In diesem Zusammenhang wäre es toll, wenn man direkt im Dialog ein Feld zur Korrektur der Vorsteuer hätte, und dadurch dann z.B. der Anteil auf denjenigen Konto mit dem größten Betrag korrigiert würde.
Wenn ich z.B.
98,92 netto Waren (18,7948 => 18.79)
9,13 netto Rohstoffe (1,7347 => 1,73)
macht Taxpool daraus 20,52 VSt., weil Kontenweise berechnet.
Aus Sicht des Lieferanten waren es alles Waren und er hat pauschal 19% von 108,05 (20,5295 => 20,53) ausgewiesen.
Hier wäre es Luxus, wenn man Taxpool einfach sagen könnte, es soll +0,01 Vorsteuer korrigieren, die dann für den posten auf "Waren" mit aufgeschlagen würden, weil es die größte Position ist.
Natürlich kann ich wie oben schon erwähnt auch die nötige Korrektur manuell machen, aber weil Taxpool ja eigentlich alle USt./VSt. Steuerberechnungen selber macht, wäre das schon komfortabel, wenn es das auch hier könnte.
Mit welcher Programmiersprache arbeitet Ihr?
Sorry... hatte die Rückfrage gar nicht gesehen.
Zu unseren "Standardsprachen" gehören
c++
java
php
aber grundsätzlich sind auch andere (C#, Perl, Python, Javascript/Node, Go) möglich, sofern das zum Ziel führt.
Es kommt vor, dass die ermittelte Vorsteuer von der ausgewiesenen Vorsteuer einer Lieferantenrechnung abweicht, wenn man verschiedene Konten verwendet (z.B. bei Waren, Rohstoffe, Bezugsnebenkosten, Dienstleistung auf derselben Lieferantenrechnung)
Ich habe verstanden, dass bei einer Sammelrechnung aufgrund der separaten Berechnung der Vorsteuer je Konto so eine Abweichung im Programm ganz normal ist.
Dennoch ist ja die Abweichung von der ausgewiesenen USt. auf der Lieferantenrechnung nicht richtig und müsste korrigiert werden.
Gibt es dort einen "schlauen Trick", wenn man die Funktion zur Sammelrechnung verwenden möchte, oder hilft hier nur, die Funktion gar nicht zu verwenden (die Rechnung nicht als Rechnung zu erfassen) sondern manuell zu buchen? Das wäre schade, weil dann die im Programm vorhandenen Funktionen zum OP Abgleich ja vermutlich nicht greifen, oder doch?
Ich habe mit dem Gedanken gespielt, einen zusätzlichen "Artikel" mit dem entsprechenden Cent-Betrag an z.B. "Abziehbare Vorsteuer 19%" hinzuzufügen. Dort hin würde ja bei manueller Buchung die Vorsteuer sowieso komplett wandern. Aber ist diese Art der Korrektur legitim oder bringt man damit die Software komplett durcheinander?
Würde mich über einen Hinweis sehr freuen, wie man hier sinnvoll den fehlenden Cent hinzubucht bzw. den zu viel berechneten Cent wieder abzieht.
Viele Grüße
Zahlungsmitteltausch für Prepaid-Kundenkarte (hier suche ich übrigens auch die Verbuchungen, die aber hier ja keine Umsatzerlöse sind und somit 0% USt haben, da erst durch Zahlung mit diesen Kundenkarten ein Umsatz zustandekommt)
Wenn es sich hier um sogenannte "Mehrzweckgutscheine" handelt, schreibst du völlig richtig, dass es sich hier (noch) um gar keine Umsätze handelt.
Auch dafür ist ein eigenes Konto im SKR03 vorgesehen, nämlich 1604 Verbindlichkeiten aus Gutscheinen
Du buchst also beim Verkauf/Aufladen Kasse (1000) an Verbindlichkeiten aus Gutscheinen (1604) und hast dadurch ebenfalls keinerlei Probleme mit der Kontenautomatik.
Beim Einlösen nimmt die Kasse (1000) gar nicht an der Transaktion teil, sondern es wird das entspechende Erlöskonto gegen 1604 gebucht.
Man muss hier wohl unterscheiden zwischen der Kasse im Kontenplan ( = das Konto mit dem Bargeld ) und der Kasse als technische Einrichtung, die auch Dinge tun kann, die buchhalterisch mit einer "Kasse" nichts mehr zu tun haben.
Tatsächlich würde ich von dem Gerät Kasse und der dazugehörigen Software ebenfalls erwarten, dass zu allen technischen Funktionen auch individuelle Einstellungen möglich sind. Diese passend zur Buchhaltung zunächst zu formulieren und dann auch einzustellen ist Aufgabe des Anwenders.
Microsoft schreibt ja auch nicht deine Briefe für dich, obwohl sie unzweifelhaft der Hersteller der Software "Word" sind, mit der man ebenfalls unzweifelhaft Briefe schreiben kann.
Die Korrektur der alten Daten sollte für einen Softwareentwickler oder Excel-Profi leicht von der Hand gehen, wenn - und nur dann, wenn - du das Regelwerk eindeutig und unmissverständlich formulieren kannst.
Stb. und Softwareentwickler in Personalunion sind übrigens eine seltene Spezies 
Stimme zu, dass es so sehr fehleranfällig ist. Allerdings wäre es kein "kopieren" mehr, wenn diese Verweise einfach weggelassen würden.
Sich pauschal für (a) oder (b) zu entscheiden, ist daher nicht zielführend, denn es können ja auch andere Dokumente anhängig sein, die man tatsächlich mit kopieren möchte.
Es sollte daher beim Kopiervorgang gefragt werden, ob die Anhänge (bzw. die Verweise darauf) mit kopiert werden sollen, sodass man im Einzelfall entscheiden kann.
Zu dem Problem, dass man aus Versehen Belege vollständig löscht, hatte ich bereits hier einmal eine Verwendungsprüfung beim Löschen von Anhängen angeregt:
OneDrive (bzw. dessen serverseitiger Unterbau SharePoint) verwendet zur Synchronisation das WebDAV Protokoll, was im Vergleich zu Windows selbst wesentlich restriktiver ist, was Datei- und Ordnernamen angeht. Ein Name, der in "echten" Ordnern unter Windows völlig unproblematisch ist, wird in einem OneDrive Ordner schnell zum Problem.
Leider wird das auf Windows-Seite immernoch nicht ordentlich geprüft und abgefangen, sodass es bei der Synchronisation immer wieder zu Fehlern, Umbenennungen und völlig wirren Umbenennungen.
Auch ein zwischenzeitig anderer Zeichensatz kann zu solchen Problemen führen, wenn zum Beispiel mehrere Rechner mit unterschiedlichen Sprachversionen verwendet werden. Microsoft hat es auch nach Jahren noch nicht geschafft, solche Grundlagen-Probleme in den Griff zu bekommen.
Wie es genau zu einem Ordnernamen, der nur aus Fragezeichen besteht, kommen konnte, wird sich im Nachhinein nicht mehr nachvollziehen lassen.
Ganz allgemein kann man aber so einen Ordner immer umbenennen oder mit dem "richtigen" Namen neu anlegen und den Inhalt kopieren.
Die Infos reichen auch nicht aus, um die Schuld pauschal OneDrive zuzuschreiben. Es kann auch durchaus eine Inkompatibilität in Taxpool vorliegen.
Interessant wäre es daher zu wissen,
- wie der Ordner vorher einmal hieß
- ob der Ordner auch im Explorer als Fragezeichen angezeigt wird. Es ist nämlich auch denkbar, dass der Ordner eigentlich einen gültigen Namen hat, der jedoch in einem für Taxpool unverständlichen Zeichensatz abgelegt ist ( in dem Fall wäre die Klassenbibliothek, die für die Taxpool Entwicklung verwendet wird schuldig, und OneDrive kann nur bedingt etwas dafür )
Leider zeichnet sich auch in anderen Themen zunehmend ab, dass der Hersteller kein Interesse daran hat, eine integrierbare Software anzubieten.
Insofern haben wir den Gedanken jetzt verworfen.
Taxpool wird tatsächlich bei uns jetzt nur noch für die reine Buchhaltung verwendet, und selbst die Vorbereitung dafür erledigen wir extern und ziehen nur noch die Buchungssätze per import. Alles ander machen wir inzwischen extern in Software, die keine Insel ist.
Wir halten an Taxpool einzig wegen der sehr guten Einbindung von ERiC fest.
Ob sich langfristig dafür der Preis immernoch rechtfertigt, oder ob wir Taxpool komplett den Rücken zukehren, wird sich zeigen.
So jedenfalls passt Taxpool einfach gar nicht nicht zu weitestgehend automatisierten Abläufen.
Ich möchte mal einfach darauf hinweisen, dass genau diese hier ständig als "falsch" oder "problematisch" bezeichnete Möglichkeit doch bereits existiert.
Sie ist nur sehr umständlich. Man muss dazu den Beleg jedem Buchungssatz einzeln zuordnen.
Taxpool ist also, wenn ich mal die vorangehenden Kommentare betrachte "ganz furchtbar böse", und man sollte diese Möglichkeit ganz schnell entfernen, weil sonst die Welt untergeht... //ironieoff
Echt jetzt?
Die Betonung beim Feature Wunsch liegt auf "gleichzeitig" (im Gegensatz zu "nacheinander")
Wie bereits gesagt ist ja grundsätzlich jetzt schon möglich, den gleichen Beleg mehreren Buchungen zuzuordnen. Darum ging es bei der Anfrage überhaupt nicht, aber genau das wird hier diskutiert und als Begründung verwendet (ungeachtet der Tatsache, dass genau das bereits möglich ist).
Die Anfrage bezieht sich in keiner Weise auf eine neue Funktion sondern lediglich um die komfortablere Verwendung einer vorhandenen Funktion.
Ich mag aber nicht weiter gegen festgefahrene Meinungen diskutieren. Es führt zu nichts, außer zu hohem Blutdruck.
das Datenvolumen vervielfacht würde
Das ist natürlich völliger Blödsinn, außer Ihr sogenanntes DMS ist laienhaft programmiert. Man muss selbstverständlich nicht mehrere Kopien desselben Dokuments speichern / vorhalten, sondern nur auf das eine Dolument verweisen.
Aber danke, dass Sie hier sehr traffend meine vorangegangene Aussage zielsicher bestätigen. Es werden Ausreden gefunden, anstatt einfach offen und ehrlich zu kommunizieren, dass Sie es enzweder nicht wollen oder nicht können.
Ihr Beispiel hinkt, denn es geht dabei nicht um die Zuordnung des Kontoauszugs, sondern um eine mangelhafte Unterstützung durch ausreichenden Angaben. In der Praxis ist es aber nun einmal so, dass sogar auf demselben Blatt mehrere Transaktion zu finden sind. Die Eindeutigkeit ergibt sich aus der Positionsnummer (siehe ihr eigenes Beispiel), und muss daher keineswegs zu Lasten des Komforts erfolgen.
Es ist ja auch im Programm durchaus möglich, verschiedenen Transaktionen dasselbe Dokument anzuhängen, nur der Vorgang ist aufwändig, da das für jede Buchung einzeln erfolgen muss.
Die Betonung im Titel des Thread liegt eindeutig auf "gleichzeitig".
Wir wäre denn die Schritt für Schritt Anleitung zu diesem Vorgehen, wenn man die "Zahlungen" im Rechnungsmodul verwendet?
Wenn ich die Zahlungen immer erst dann buche, wenn der Kontoauszug komplett ist, dann schlägt das Mahnwesen zu, obwohl der Kunde tatsächlich schon bezahlt hat.
Das Programm schlägt hierbei außerdem einen Nummernkreis ZE für Zahlungseingang vor, anstatt denjenigen des Bankkontos zu verwenden.
Die erläuterte Vorgehensweise ist daher imho mit den Programm-Voreinstellungen nicht vereinbar.
"Den Beleg findet man in der Buchhaltung dann sofort unter einer der Buchungen"
Das ist genau das Problem... ich möchte den Beleg unter egal welcher dieser Buchungen finden, ohne diejenige zu suchen, an der er "dranklebt".
Das ist kein Problem der Buchhaltung sondern ein Problem der Nutzerfreundlichkeit.
Aber lassen wir das Thema...
Sie scheinen ja in einer Welt zu leben, in der die Software den Arbeitsablauf vorschreibt, anstatt den etablierten Arbeitsablauf des Kunden zu unterstützen.
Das zeigt sich leider in verschiedenen Themen hier im Forum immer wieder.
Leider gibt es zurzeit keine wirkliche Alternative zu taxpool, jedenfalls nicht in einem vergleichbaren Preissegment.
Moin,
ja, bei dem Vorschlag ging es überwiegend um Kontoauszüge. Auch wenn es keine Notwendigkeit zur Mehrfachzuordnung gibt, erleichtert das doch das kurzfristige wiederfinden eines zugehörigen Belegs.
Selbstvertändlich kann ich auch ein externes Ablagesystem verwenden, aber da die Funktion einer Dokumentenzuordnung in Taxpool bereits enthalten ist, liegt der Gedanke nahe, sie auch hier zu erweitern.
Es geht also nicht darum, dass der Beleg buchhalterisch korrekt abgelegt wird, sondern darum, dass man schnell herausfindet, auf welchem Beleg eine konkrete Buchung zu finden ist
Ich bin ebenfalls weiterhin stark an Integrationsmöglichkeiten wie einer API interessiert, oder alternativ auch an unverschlüsselten "Hilfstabellen" bei Verwendung der Server-Version mit Postgres.
Ich möchte hier noch einmal das Thema Rechnungsimport aufgreifen, an dem nach wie vor großes Interesse besteht.
Wir streben weiterhin an, Taxpool als "source of truth" zu verwenden, sprich die letzendlich einzige Referenz, in die alles reinläuft.
Wir möchten nicht unsere Daten regelmäßig in verschiedenen Systemen nachhalten.
Kann Taxpool nicht ein Format für einen möglichen Import von Rechnungen vorgeben?
Die Eingabefelder für das manuelle Erstellen von Revhnungen sind schließlich auch so vorgegeben, wie sie sind.
Ich erkenne als Softwareentwickler die Schwierigkeit leider nicht, mit der hier argumentiert wurde. Es ist überhaupt nicht notwendig, konkrete Shops und/oder Drittanbieter exakt passend zu unterstützen, sondern es wird lediglich nach einer grundsätzlichen von Taxpool vorgegeben Importmöglichkeit gesucht, die eben genau den Funktionsumfang abbildet, den Taxpool bei der manuellen Eingabe ebenfalls unterstützt.
Die konkreten Exports bzw. "Übersetzer" aus irgendeiner Drittsoftware zu pflegen oder nachzuhakten, soll überhaupt nicht das Problem von Taxpool sein.
Ich bin insofern verwundert, dass man sich die Mühe macht, einen (zufällig ausgewählten?) Shop "WooCommerce" sehr umfassend zu unterstützen, aber auf einen generischen Import einen großen Bogen macht.
Die konkreten Umsetzungen einer Datenanlieferung kann dann jeder beliebige Softwareentwickler entweder als Standardmodul oder als Individualsoftware leisten, solange nur die Importschnittstelle bekannt ist.
Ich hoffe weiterhin auf gute Neuigkeiten in Sachen Integrationsmöglichkeiten.
Ich bin immernoch ein großer Fan von Taxpool, aber solange es eine Insellösung bleibt, sind einige an sich tolle Funktionen für uns nahezu wertlos (weil ein manuelles Übertragen einfach nicht in Frage kommt)
Beim Löschen von angehängten Dokumenten fragt das Programm, ob der Eintrag gelöscht werden soll, und im zweiten Schritt, ob auch das zugehörige Dokument gelöscht werden soll.
Leider gibt es keine Prüfung und/oderAuskunft darüber, ob das Dokument gleichzeitig auch noch anderen Datensätzen zugeordnet ist, so dass der zweite Schritt potentiell gefährlich ist.
Das Dokument wird gelöscht, was dazu führt, dass andere Datensätze es ebenfalls nicht mehr finden können.
Hier sollte eine Prüfung stattfinden, und das Dokument nur hart gelöscht werden, wenn es keinen weiteren Datensätzen zugeordnet ist.
Gleichzeitig sollte eine Bereinigungsfunktion angeboten werden, die geeignet ist, alle Dokumente im Datenordner zu finden, die keinem Datensatz zugeordnet sind (die gibt es aktuell nur umgekehrt zum finden von "fehlenden" Dokumenten)
Es wäre toll, wenn man dasselbe Dokument mit einer einzigen Aktion gleich mehreren Buchungssätzen zuordnen könnte.
Dies gilt insbesondere für Kontoauszüge als PDF.
Dies könnte man zum Beispiel über eine Mehrfachauswahl im Stapel und Rechtsklick lösen, oder aber über einen separaten Dialog.
Es gibt in Taxpool sowohl bei einer Rechnung als auch in der Buchungsliste die Möglichkeit, Dokumente anzuhängen.
Leider werden diese Informationen unabhängig voneinander geführt und sind nicht verknüpft.
Es wäre toll, wenn ein Dokument, was einer Rechnung angehängt wird (bzw. als PDF Rechnung erzeugt wird) auch gleichzeitig an den dazugehörigen Buchungssatz angehängt werden würde.
Es wäre toll, wenn im Dialog "Zahlungen" der Kunden/Lieferanten Verwaltung in der oberen Rechnungsliste auch der Wert Fremdbeleg der jeweiligen Rechnung zu sehen wäre.
Auf einem Kontoauszug erscheint ja bei Lieferanten-Abbuchungen genau dieser und nicht die selbst vergebene Rechnungsnummer.
So wäre die Rechnung, die zu einer Zahlung auf dem Kontoauszug gehört in der Liste leichter zu finden.
Verwendest du die Datei-Basierte Version oder hast du eine PostgreSQL Datenbank dahinter?
Bei der Dateibasierten Version könnte ich mir durchaus vorstellen, dass hier der Fehler im virtuellen Dateisystem deiner wine Umgebung zu suchen ist.
Taxpool ist da insgesamt doch ziemlich I/O lastig.
Es kann durchaus sein, dass es sich da gerade bei zügigen Tab-Wechseln (jeder mit einer Lese-Operation) etwas verzettelt.
Wenn die Wine Schicht einmal nicht schnell genug schreibt, beim nächsten Klick dadurch einen "alten" Datenbestand liest und diesen dann wiederum als letzten bekannten Datenbestand neu schreibt, dann ist deine Änderung weg. Ohne das einmal nachgebaut zu haben, ist das natürlich nur geraten, aber spontan die einzige Erklärung, die Sinn ergibt.
Schau außerdem einmal nach, ob deinem Dateisystem noch ausreichend freie inodes zur Verfügung stehen.
