Wir haben das ganze seit über 11 Jahren als individuell programmierte Lösung im Einsatz, inkl. Rechnungserstellung, Rechnungsversand, Mahnwesen, Vertragsverwaltung, Schnittstelle zum Inkasso, Kundenlogin + DNS-Verwaltung, Bestellmöglichkeit, Domainverwaltung, Partnerprogramm und künftig soll das ganze auch mit LiveConfig verbunden werden, um noch mehr automatisierung zu ermöglichen, wenn denn endlich mal die neue Version 3 erscheinen wird. Ich kann es jedem nur empfehlen eigene Lösungen zu nutzen, man ist nicht auf Fremdanbieter angewiesen die an der Preisschraube drehen können wie sie wollen oder von heute auf morgen vom Markt verschwunden sind und vor allem bleiben die Daten sicher "im Haus". Auch ein Pluspunkt ist, man muss sich nicht in verschiedene Systeme einloggen, sondern nur eines. Eine Exportfunktion aller Rechnungsdaten für den Steuerberater gibt es ebenso. Weiterhin hat der Kunde einen eigenen Loginbereich, indem er Domains bestellt, Verträge verwaltet, DNS-Einstellungen vornimmt, Rechnungen im Archiv herunterladen kann, das Partnerprogramm nutzt usw. usf.
Kunden/Rechnungs-Verwaltungsprogramm für Hosting
-
-
wir driften hier ziemlich ab...
https://www.golem.de/news/wors…f-pleite-2404-184481.html
Korrekt, kann passieren.
Aber:
- mit einem sauberen Business Continuity Plan ist das zwar ärgerlich, aber kein Totalschaden.
- wir sind hier allesamt Hosting-Anbieter. Der zitierte Fall kann also unsere eigene Infrastruktur mit unseren eigenen Systemen und der dort installierten Software auch treffen.
- Backups erfolgen extern auf eigenen Systemen - idealerweise sogar mit Append-Only, so dass keine Daten in-place als Ransomware verschlüsselt werden können.
Ja, eine auf dem eigenen Rechner installierte Software mit rein lokaler Datenhaltung löst das Problem natürlich. Aber selbst da braucht es Backups - oder hat noch nie jemand Kaffee auf den Laptop gekippt, oder sich drauf gesetzt?
Zu g*Sales/LexOffice: bei LexOffice fehlt die Warteschlange, die IMHO unersetzlich ist. Auch kann LexOffice standardmäßig keine Rechnungen mit unterschiedlichen Steuersätzen (16%/19% - wir erinnern uns). Buchhaltung/Rechnungen aber ohne GoBD-konforme Archivierung zu speichern halte ich für ... riskant. Daher die eigene Anwendung extern - wie weltmeister auch. Muss letztendlich aber jeder selbst wissen.
Zurück zum Thema: bis auf das große Lexware (und Webfakt, aber das fällt ja weg...) sind mir keinerlei Programme für die lokale Rechnungsschreibung mehr bekannt.
-
- wir sind hier allesamt Hosting-Anbieter. Der zitierte Fall kann also unsere eigene Infrastruktur mit unseren eigenen Systemen und der dort installierten Software auch treffen.
Alles was Du selbst verwaltetes (Software und Daten) kannst Du selbstverständlich problemlos wieder auf anderen Servern einrichten, so lange Du entsprechende Backups hast. Darüber besteht hier Einigkeit und ich denke das bezweifelt auch keiner. Natürlich je nach Umfang ggf. sehe aufwendig sein.
Wenn es aber um SAAS-Dienste geht, und es sich um Software handelt, die man eben nicht selbst verwaltet, sondern nur Schnittstelle dahin bedinet, dann kann man diese nicht wieder Herstellen im worst-case Fall (Hersteller geht pleite etc.).
Klar, auch da sind ggf. Backups und Exporte möglich, die den Aufbau einer Kundenverwaltung in einer ganz andere Software ermöglichen. Dies ist aber eben nicht so einfach wie dargstellt und mal eben schnell erledigt - natürlich je nach Umfang der Inhalte. Wir haben tausende Kunden, hunderte Artikel, massenweise Vorlagen für Emails und andere Aktionen, Abrechnungsdaten, hunderte offene Posten mit unterschiedlichen Mahnungszuständen, tausende gebuchte Artikel alle mit unterschiedlichen Laufzeiten, Preisen etc.pp.
Das würde ich gerne mal sehen, wenn von heute auf morgen der Anbieter weg ist und man sofort unter Zeitdruck sich eine Sofware suchen muss die das allen genauso kann und die auch noch ale Daten importieren kann - das gehe ich jede Wette ein., das ist auch in 4 Wochen nicht realistisch.
Bei mir ist es ja so, das Webfakt nicht mehr weiterentwickelt wird und offenbar vom Markt verschwindet. Ich haben aber nicht dem Zeitdruck, weil die Software ja bei uns läuft ud auch weiterläuft. Spätestens wenn irgendwelche rechtlichen Änderungen eintreten, die nicht mehr umsetzbar sind, erst dann müsste man sich umsehen nach Ersatz. Das ist eine GANz ANDERE Situation und deshlab empfehle ich solche Daten auf keinen Fall bei SAAS-Diensten zu nutzen.
"Weltmeister" hat es offenbar verstanden:
ZitatIch kann es jedem nur empfehlen eigene Lösungen zu nutzen, man ist nicht auf Fremdanbieter angewiesen die an der Preisschraube drehen können wie sie wollen oder von heute auf morgen vom Markt verschwunden sind und vor allem bleiben die Daten sicher "im Haus".
-
Wir haben tausende Kunden, hunderte Artikel, massenweise Vorlagen für Emails und andere Aktionen, Abrechnungsdaten, hunderte offene Posten mit unterschiedlichen Mahnungszuständen, tausende gebuchte Artikel alle mit unterschiedlichen Laufzeiten, Preisen etc.pp.
Das würde ich gerne mal sehen, wenn von heute auf morgen der Anbieter weg ist und man sofort unter Zeitdruck sich eine Sofware suchen muss die das allen genauso kann und die auch noch ale Daten importieren kann - das gehe ich jede Wette ein., das ist auch in 4 Wochen nicht realistisch.
Das wird auch jetzt bei einem Wechsel von Webfakt nicht realistisch sein. Im besten Fall findet man zeitnah eine geeignete Software und muss noch etwas selbst entwickeln, um die Daten per API selbst zu migrieren. Und in 10 Jahren steht man vielleicht wieder am gleichen Punkt.
Ich haben aber nicht dem Zeitdruck, weil die Software ja bei uns läuft ud auch weiterläuft. Spätestens wenn irgendwelche rechtlichen Änderungen eintreten, die nicht mehr umsetzbar sind, erst dann müsste man sich umsehen nach Ersatz.
Im besten Fall schaut man sich bereits vorher um. Oder noch besser, man nutzt diese Übergangszeit, um eine eigene Lösung zu entwickeln. Für uns stellt sich lediglich noch die Frage, ob für die Rechnungsstellung / Mahnwesen / Buchhaltung ein externes Produkt per API angesteuert werden soll oder ob man dieses integriert. Die Verwaltung der Kundendaten, Webspace-Pakete, Server und die Schnittstellen zu LiveConfig oder Domainanbietern würde dann in jedem Fall in der eigenen Software erfolgen.
Um zur eigenen Fragestellung zurück zu kommen: Aus meiner Sicht gibt es aktuell kein alternatives Produkt zu Webfakt als Gesamtpaket. Insbesondere nicht, wenn alles lokal laufen soll.
-
Das wird auch jetzt bei einem Wechsel von Webfakt nicht realistisch sein. Im besten Fall findet man zeitnah eine geeignete Software und muss noch etwas selbst entwickeln, um die Daten per API selbst zu migrieren. Und in 10 Jahren steht man vielleicht wieder am gleichen Punkt.
Um mal ne Binsenweisheit rauszukramen: Nichts ist für ewig.
Ich schaue alle halbe Jahre mal quer über den Markt ob es irgendwelche Neuentwicklungen gibt die passend für uns wären. Vieles von dem mit dem wir in den letzten ~25 Jahren gearbeitet haben ist schon lange wieder verschwunden genauso wie Registrare und Hoster über Nacht plötzlich weg waren.
Eine Überzeugung zu der ich in den letzten Jahren gekommen bin ist das es vollkommen Sinn gemacht hätte einfach alles selber zu entwickeln statt unzählige Stunden damit zu verschwenden Programme auszuprobieren von denen man letztendlich eh nie weiß in welche Richtung sie sich Entwickeln und wielange sie durchhalten bzw ob sie auf Dauer den eigenen Business Case bedienen können.
Wenn man was selber entwickelt muss man alle paar Jahre mal was anpassen oder updaten und das wars dann auch.
Ist wie bei Liveconfig, man hat seit zig Jahren auf nötige Funktionen und Weiterentwicklungen gewartet und es ist einfach nix passiert. Wäre das schon am Anfang klar gewesen hätte ich gleich was eigenes geschrieben.
-
Ist wie bei Liveconfig, man hat seit zig Jahren auf nötige Funktionen und Weiterentwicklungen gewartet und es ist einfach nix passiert. Wäre das schon am Anfang klar gewesen hätte ich gleich was eigenes geschrieben.
Das möchte ich so nicht stehen lassen. LiveConfig wurde und wird durchgehend weiterentwickelt. Zum Entwickeln gehört mehr, als einzelne bestimmte Funktionen einzubauen (die möglicherweise Sie speziell benötigen/erwarten), sondern auch eine Produktpflege.
Eine Individual-Entwicklung ist selbstverständlich immer die optimale Lösung (weil die ja alle Anforderungen erfüllt), aber nunmal auch die aufwendigste und teuerste Lösung. Zudem setzt das die entsprechenden Kompetenzen und Ressourcen voraus.
Und jetzt bitte wieder zurück zum Ursprungsthema, allgemeine Diskussionen gehören nicht in diesen Thread.
-
Nachdem Cika-Software zwischenzeitlich Insolvenz angemeldet, der Insolvenzverwalter die Firma bereits aufgelöst hat und der Quellcode vom bisherigen Programmierer-Ehepaar nicht verkauft werden kann, besteht bei den Webfakt-Nutzern Handlungsbedarf.
Hat hier jemand schon das "ideale" Nachfolge-Fakturierungsprogramm gefunden?
-
Wie in anderen Beiträgen hier auch:
Individuelle Lösung auf Laravel-Basis (u.a. mit Laravel Backpack) und selbstgebauter Anbindung an LexOffice und InternetX (AutoDNS).
Haben auch eine automatisierte Webfakt-Migration über Verarbeitung der Daten aus den Webfakt-Tabellen entwickelt.
Bei Fragen gerne melden. -
Hallo zusammen,
welche alternativen gibt es denn aktuell?
Wir haben bisher SESFakt verwendet, und waren super zufrieden damit.
- LexOffice kann keine SEPA Dateien erstellen, scheidet somit aus
- SevDesk unterstützt nur wiederkehrende Rechnungen, dabei müssen aber alle Artikel die gleiche Laufzeit aufweisen, Artikel mit unterschiedlichen Leistungszeitraum wird nicht unterstützt
bisher alles nicht das gelbe vom Ei.
-
Ich habe Einblick in SevDesk bekommen. Es kann UStE und Buchungen erfassen ist viel Geklicke. Für kleine Buchhaltung und Übergaben an StB brauchbar - imho aber nichts für Profis.
-
Alles anzeigen
Hallo zusammen,
welche alternativen gibt es denn aktuell?
Wir haben bisher SESFakt verwendet, und waren super zufrieden damit.
- LexOffice kann keine SEPA Dateien erstellen, scheidet somit aus
- SevDesk unterstützt nur wiederkehrende Rechnungen, dabei müssen aber alle Artikel die gleiche Laufzeit aufweisen, Artikel mit unterschiedlichen Leistungszeitraum wird nicht unterstützt
bisher alles nicht das gelbe vom Ei.
SEPA-Dateien sollten sich mit einem fähigen Entwickler über die REST-API problemlos erzeugen lassen. Alternativ gibt es auch SepaHeld, was diverse unserer Kunden mit Lexoffice erfolgreich im Einsatz haben.
-
Lexoffice habe ich mir inzwischen auch angeschaut, ähnlich wie Sevdesk, ist mehr eine Buchhaltung als eine Faktura wie Webfakt/SESFakt.
Und nur um eine Sepa XML zu generieren noch zwei weitere Anbieter (Sepaheld + Gocardless) ins Boot zu holen und zu bezahlen, halte ich für übertrieben.
-
Möglicherweise schwenken wir dann auch irgendwann um, aber aktuell sind wir dabei die ZUGFeRD-Rechnung auch in Webfakt mit einer eigenen vollständig im Webfakt-Workflow integrierten Lösung zu realisieren. Damit kann Webfakt dann auch problemlos weiter benutzt werden.
Das wäre als Übergangslösung interessant. Allerdings sehe ich dafür nur zwei Wege: Entweder man erstellt die ZUGFeRD-PDF-Dateien (Rechnungen) selbst indem man in Webfakt die Datenbank entsprechend ausliest. Oder man übernimmt die bereits generierten PDF-Dateien und ergänzt diese um die eingebetteten XML-Daten, bevor diese per E-Mail versandt werden. Darf man mehr über euren Lösungsweg erfahren?
Wir hatten Kontakt mit https://www.agenturbo.de/ und dem Produkt KBMpro.
KBMPro haben wir uns ebenfalls angesehen. Sehr schöne Software, allerdings mit Schwerpunkt auf Agenturen statt Provider. Leider kein API-First Prinzip, sonst hätte man fehlende Module leicht ergänzen können. So dürfte es derzeit sehr schwierig werden, alle fehlenden Funktionen von Webfakt nach zu implementieren.
Hostware (https://hostware.io/) sah ebenfalls interessant aus, allerdings benötigt dies ebenfalls eine externe Fakturierung/Buchhaltung für die Rechnungsgenerierung und -Versand.
Individuelle Lösung auf Laravel-Basis (u.a. mit Laravel Backpack) und selbstgebauter Anbindung an LexOffice und InternetX (AutoDNS).
Haben auch eine automatisierte Webfakt-Migration über Verarbeitung der Daten aus den Webfakt-Tabellen entwickelt.
Bei Fragen gerne melden.Ich hatte dir im April eine PN hier im Forum geschickt, kam diese an? Auf lange Sicht finde ich eine solche Individuallösung am geeignetsten, mit Anbindung an eine externe Fakturierung und Schnittstellen zu den übrigen Systemen (Domainverwaltung / LiveConfig / ...). So könnte bei Bedarf auch eine Schnittstelle jederzeit gewechselt werden.
-
Das wäre als Übergangslösung interessant. Allerdings sehe ich dafür nur zwei Wege: Entweder man erstellt die ZUGFeRD-PDF-Dateien (Rechnungen) selbst indem man in Webfakt die Datenbank entsprechend ausliest. Oder man übernimmt die bereits generierten PDF-Dateien und ergänzt diese um die eingebetteten XML-Daten, bevor diese per E-Mail versandt werden. Darf man mehr über euren Lösungsweg erfahren?
Unser Weg ist folgender:
- Wir haben einen auf Perl basierten Server ("ZUGFeRD-Server") programmiert, der auf einem bestimmten Port SMTP annimmt.
- In Webfakt wurde ein weiteres SMTP-Profil eingerichtet. Darüber werden dann im Rechnungslauf die Emails versendet. Das zu nutzende Profil wird ja beim Rechnungslauf jeweils individuell ausgewählt.
- Der ZUGFeRD-Server nimmt eine Email aus dem Rechnungslauf entgegen und erkennt mit einer RegEx am Betreff der Mail ob es eine Rechnung ist.
- Als Rechnung erkannte Mails werden weiter verarbeitet, alle anderen gehen über einen offiziellen SMTP-Relay ins Internet
- Der ZUGFeRD-Server läuft auf demselben PC/Server, auf dem Webfakt installiert ist und hat Zugriff auf die Webfakt-Datenbank.
- Anhand der PDF-Daten in der Rechnungsemail wird die Kundennummer und die Rechnungsnummer erkannt. Mit diesen beiden Daten kann man aus zwei Tabellen der Webfaktdatenbank alle in der Rechnung befindlichen Daten auslesen (so lange die Rechnungen noch in der offenen Posten-Liste sind). Statische Informationen wie Angaben zum Hoster sind in einer config-Datei abgelegt.
- Der ZUGFeRD-Server konvertiert nun die PDF-Datei via Ghostscript in das notwendige PDF/A3 Format und und integriert alle notwendigen Rechnungsdaten als XML-Anhang in das PDF. Dann wird die Rechnungs-Email mit dem ausgetauschten PDF an ein SMPT-Relay gesendet, welches die Email dann zustellt.
- In der Prüf- und Entwicklungsphase arbeiten wir natürlich mit einer Webfaktkopie auf einem Testserver. In der Konfiguration des ZUGFeRD-Servers kann ein Debug-Modus aktiviert werden, welcher alle Emails umleitet auf ein Testpostfach - damit keine echten Kunden solche Email bekommen.
Das System ist so gut wie fertig. Wir bauen das System für uns selbst und für einen befreundeten Hoster. Bislang sind nach vielen kleinen Anpassungen die Ergebnisse valide! Geprüft mit einem ziemlich scharfen Validator (portinvoice.com), der mit Mustang und Valitool prüft.
Ein Vertrieb ist nicht angedacht. Anhand des hier vorgestellten Lösungswegs sollte jeder halbwegs fähige Programmierer das nachbauen können. Das Schöne ist, das der Webfakt-Workflow identisch weiterläuft. Man muss nur dafür sorgen, das Rechnungsemails über das ZUGFeRD-SMTP-Profil in Webfakt gesendet werden.
So lange es keine neuen rechtlichen Vorgaben gibt, kann man damit Webfakt problemlos weiter nutzen.
PS: In der Auftragserfassung hat CiKa ja bereits ZUGFeRD bereits integriert. Unsere Prüfungen zeigen allerdings Probleme bei der Validierung in einigen Fällen. Faktisch damit nur ganz bedingt nutzbar.
Das oben erwähnte KBMpro ist mittlerweile schon deutlich weiter für Webfaktkunden umgebaut worden. Ziel ist eine immer bessere Integration. Aktuell für us aber noch viel zu umständlich nutzbar. Da warten wir mal noch ein/zwei Jahre ab,
Ich erwarte sowieso viele Probleme bei vielen Anbietern diverser Buchhaltungssoftware. Teilweise ist es so das nach unseren Tests, das die von einer Software selbst erzeugten ZUGFeRD-Rechnung von der eigenen Software als nicht valide eingestuft werden. Da fragt man sich manchmal, liegt das am Fachkräftemangel :?!!?
Ich kann nur dazu raten den oben genannten Validator zu nutzen. Das integrierte Valitool ist offenbar die aktuelle Referenz. Auf der genannten Website kann man täglich ein paar Rechnungen auch kostenfrei validieren. Valitool gibt vor allen Dingen ganz exakte Fehlermeldungen aus, die bei der Programmierung ungemein helfen.
-
Webfakt rechnet in der Rechnung falsch oder besser gesagt "ungenau" oder noch besser "zu genau".
Rechnungspositonen werden dort mit allen Nachkommastellen aus der Artikeldatenbank als Gesamt-Netto aufsummiert, dann die Märchensteuer daraus berechnet und damit der Brutto-Endbetrag.
Das fällt vor allem bei den Domain-Rechnungen in größerer Anzahl auf. Es sind zwar nur Cent-Beträge, aber am Ende ist die Summe nun mal falsch.
Wir haben einen auf Perl basierten Server ("ZUGFeRD-Server") programmiert, der auf einem bestimmten Port SMTP annimmt.
Ein guter Lösungsweg, daran hatte ich jetzt nicht gedacht! Das verschafft etwas Zeit für eine Eigenlösung. Am Ende sollte eine API zu einer etablierten Fakturierungssoftware stehen, welche ihrerseits regelmäßig an die gesetzlichen Erfordernisse angepasst wird. Im Bedarfsfall kann man diese auch zu einer anderen Software ändern oder eine Eigenlösung bauen, ohne die grundlegende Software (Datenbank mit Kundendaten, Speicherplätzen, Domains usw.) umbauen zu müssen.
-
Guten Abend zusammen,
hallo Michael mjk,
sorry, Deine PN ist mir tatsächlich durchgegangen. Entschuldige bitte die fehlende Rückmeldung. Mir lässt das Thema Webfakt und dessen Zukunft sowie eine eigene webbasierte Alternative für Agenturen und Hoster keine Ruhe lässt. Es ist ja nun offiziell, dass Webfakt nicht mehr weiterentwickelt wird, die CiKa Software ist lt. diverser Informationen liquidiert. Weitere Infos gibt es keine.
Ich konnte jedenfalls die webfakt.de ergattern. Das spricht nicht dafür, dass da bei CiKa noch jemand was mit vor hatte
Unsere Lösung kommt Webfakt schon ziemlich nahe, zumal ich immer einen API-First-Ansatz verfolgt habe. Im tägliche Einsatz für uns selbst klappt das wunderbar, aber von einem Produkt für die breite Masse sind wir weit entfernt. Mich überrascht grade die Menge der Anfragen zu dem Thema, mir war nicht bewusst, wieviele User von Webfakt es noch gibt.
Meiner Meinung nach ist es vergebene Liebesmüh eine komplette Wawi wie Webfakt webbasiert umzusetzen. Es ist zielführender hier externe Tools mit Spezialisierung anzubinden. Ich habe nie verstanden, weshalb die Steinbrechers bei Webfakt nicht klare Grenzen im Funktionsumfang gesetzt haben und sich auf bestimmte Core-Features konzentriert haben.
Es gibt für viele Funktionen gute Lösungen am Markt und im Bereich Buchhaltung ist das für uns aktuell Lexoffice / Lexware office, deren API-Ansatz unseren Vorstellungen entspricht und zuverlässig weiterentwickelt wird. Der Steuerberater ist zufrieden, die Buchhaltungsabteilung auch.
Ich habe aktuell nicht die personellen Kapazitäten, dass wir von jetzt auf gleich unsere Lösung "veröffentlichen", da will ich niemandem falsche Hoffnungen machen. Da sind eine Menge Bugs drin, die ich dafür erstmal ausbügeln müsste, und auch an vielen Stellen Dinge individuell konfigurierbar machen müsste. Ich will da nicht zuviel versprechen, die Idee ist aber da.
Mal gucken, was die nächsten Wochen so bringen ...
Viele Grüße
Sebastian
-
@flo4545 Ja, die genannten Fehler sind und waren ja schon lange in Webfakt bekannt. War für mich allerdings dann am Ende auch einer der vielen Gründe, Webfakt nach über 20 Jahren ad acta zu legen. Mir wäre es langfristig zu riskant, weiterhin damit zu arbeiten. Ganz unabhängig davon, dass in meinen Augen eine desktopbasierte Windows-Software in 2024 nichts mehr zu suchen hat.
-
@mjk Hostware beobachte ich seit einiger Zeit.
Deren Ansatz ist schon vom Gedankengang her nicht schlecht, aber zu sehr auf auf eine starre SaaS-Lösung fixiert, bei der diktiert wird, welche Features wichtig sind und welche nicht.
Als "Hoster" und "Agentur" weiß ich, wie wichtig die Möglichkeit ist, selber "eingreifen" und weiterzuentwickeln zu können. Ich bin großer Verfechter von Open Source und Self Hosting (jedenfalls wenn es Sinn macht) und würde mich nie an eine Cloud-Lösung bzw. Insel hängen, die keine vernünftige API von Anfang an bietet. Hostware hat zwar ganz viele Schnittstellen zu externen Services, bietet aber m.W. aktuell immer noch selber keine vernünftige API. Damit hätte ich schonmal ein Problem.
Das war tatsächlich schon vor 3 Jahren ein Kriterium auf Laravel zu setzen, da im Grunde eine vernünftige REST-API "out of the box" mit drin ist.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!