Liebes Team von campai,
Gibt es schon einen näheren Zeitplan für das roll out der neuen Module von Campai? Wir stehen gerade vor der Frage, wann wir unsere Jahresbuchhaltung am Besten machen. Am Liebsten würde wir dies schon mit dem neuen Modul machen. Zudem haben wir Ende November eine größere Veranstaltung. Daher müssen wir überlegen, wie wir diese organisieren.
Herzliche Grüße
Sebastian
Hallo Sebastian,
geplant ist aktuell Anfang 2025.
Lg
Oliver
Hallo Oliver,,
wann Anfang 2025?
Januar? Februar? März? usw.
Lg
Michaeö
Hallo Michael,
das FiBu Modul kommt am 6.1. Newsletter geht, soweit ich weiß, am Sonntag raus.
Lg
Oliver
Hallo Oliver,
wie sieht es aus mit:
Vereinskalender
Verknüpfung Formulare und Mitglieder/Kontakte
Self Service Portal
LG Michael
Hallo Michael,
Kalender kommt mit dem Kursmodul. Wie Umfangreich da die Funktionen bei Release sind, kann ich aber noch nicht sagen. Zumindest die Veranstaltungen und Kurse die im Kursmodul erstellt werden sind dann natürlich eingetragen.
Self Service kommt auch gleich mit Apo-Release.
Danach machen wir uns gleich daran das Mitglieder- und Kontaktemodul neu zu bauen und gleich eine direkte Formularimportfunktion einzubauen, die dann auch gleich Alternative Kontakte usw. automatisch anlegen und zuweisen können wird. Wir rechnen mit Q1 damit.
Liebe Grüße
Oliver
Hallo,
auf dem Community-Event im April hieß es, dass das FiBu-Modul schon fast fertig ist, noch Ende Q2/2024 ins Beta-Testing gehen und das Release noch vor Q4/2024 erfolgen wird. Auf mehrere Nachfragen im Spät-Sommer hieß es dann, dass das Beta-Testing für das FiBu-Modul im September losgehen würde. Ein angedachtes weiteres Online-Community-Event, auf dem auch Live-Einblicke in den Stand der Entwicklungen gegeben werden, hat nicht stattgefunden.
Mittlerweile haben wir Ende November 2024. Oliver hat oben geschrieben, dass ein Release vom FiBu-Modul am 06.01. erfolgen soll. Einen für das letzte Wochenende angekündigten Newsletter haben wir bisher nicht erhalten. Wir gehen dennoch weiterhin davon aus, dass das Jahr 2025 für den Release am 06.01. gemeint ist.
Mehrfach haben wir uns sowohl bei Buchhaltungs- als auch Eventmodul als Beta-Tester angeboten und angemeldet. Bisher haben wir keine Nachricht/Einladung dazu erhalten. Sollte ein Beta-Testing bereits stattfinden, würden wir uns über eine sofortige Freischaltung freuen.
Sofern noch kein Beta-Testing stattfindet, muss man wohl große Zweifel am genannten Release-Termin oder aber in der Vorgehensweise bei der Entwicklung und Einbindung der Community haben. Es verbleiben nun noch ca. 3 Arbeitswochen bis zur Weihnachts-/Jahreswechsel-Pause. Dass in dieser Zeit eine vernünftige Beta-Testing-Phase mit sinnvoller Berücksichtigung von Hinweisen aus der Community stattfindet, ist zu bezweifeln. Da sind nach unseren Erfahrungen Probleme mit Bugs und Enttäuschungen mit den Funktionalitäten vorprogrammiert.
In jedem Fall scheint sowohl Kommunikationsstrategie, Community-Einbindung, als auch Vorgehen bei der Umsetzung von neuen Funktionalitäten verbesserungswürdig und steht leider im Gegensatz zu dem, was im Community-Event im April gesagt wurde. Die Benutzerfreundlichkeit der Software lässt in der Folge zu wünschen übrig. Wir würden uns freuen, wenn die Veränderung von diesen "Grundwerten" eines Software-Unternehmens auf Eure Liste mit den guten Vorsätzen für das neue Jahr kommen würde. Dann kann aus der Software mit guten Ansätzen vielleicht endlich eine Software werden, die das Arbeiten für die Benutzer vereinfacht.
Viele Grüße
Alex
Hallo Alex,
du hast korrekt erkannt, dass wir bei so Ablauf-Geschichten noch nicht die Besten sind. Wir haben uns dazu aber vor kurzem Unterstützung geholt und sind dabei diesbezüglich Strukturen einzuführen, damit das alles geregelter und verlässlicher abläuft. Die ersten Früchte dieser Arbeit werdet ihr am 2-3 Dezember mitbekommen, wo wir den Beta-Test des neuen Finanzmoduls für alle campai-Kunden starten. Dieses Mal begleitet von einer umfassenden Kommunikationskampagne. Das neue Finanzmodul wird alle Tickets lösen, die aktuell auf "in Bearbeitung" sind. Mehr dazu nächste Woche. Dieses Mal so fix, wie bei uns noch nie etwas fix war.
Liebe Grüße und danke für die Geduld
Oliver
Hallo Oliver,
danke für Deine Antwort und die Einblicke, die Du gewährst. Schade, dass vorher kein Austausch mit der Community erfolgt ist und dass scheinbar doch wieder im "stillen Kämmerlein" vor sich hin programmiert wurde. Das ist leider keine sehr professionelle Vorgehensweise und lässt leider schon jetzt Zweifel am Ergebnis aufkommen. Zudem macht es deutlich, dass die immer wieder "beschworene" Community von Euch leider nicht wirklich ernst genommen zu werden scheint.
Wir hoffen insofern, dass es nun zumindest kurzfristig ein Online-Community-Event gibt, in dem die Beta-Version und neue Funktionalitäten der FiBu vorgestellt werden und ein Austausch erfolgt. Zudem wird hoffentlich ein realistischer Release-Termin gesetzt und benannt. Der 06.01.2025 ist damit ja nicht mehr realistisch.
Viele Grüße
Alex
Hallo Alex,
das FiBu Modul ist im Prinzip komplett fertig und kommt in der Nacht von Montag auf Dienstag in den öffentlichen Beta-Test. Anbindung an das Admin-Modul und Release am 6.1. ist fix. Intern und mit ausgewählten Großkunden wurde schon getestet. Bzgl. Community: Über 100 Tickets von euch aus dem Feedback hier und das Ganze Feedback aus dem Support der letzten Jahre sind in das Modul geflossen und entweder eingebaut oder überflüssig, weil die Abläufe besser sind. Wir haben da wirklich keinen Stein auf dem anderen gelassen um sämtliche Bereiche von campai nahtlos zu integrieren, so dass sich die Buchhaltung fast von selbst macht. Funktionieren tut das ganze und Funktionen hat es auch alle gewünschten. Es geht jetzt bis 6.1. nur mehr darum Bugs zu finden. Danach widmen wir uns dann euren Verbesserungsvorschlägen dazu. Also noch ein paar Tage Geduld und dann kanst du dich selbst überzeugen.
Liebe Grüße
Oliver
Hallo Oliver,
der Beta-Test ist ja nun gestartet. Leider ist dieser Start gestern schon sehr holprig verlaufen, da Campai in Gänze gestern für uns überwiegend nicht nutzbar war. Man konnte sich nicht einloggen. Erst am Abend nach 20 Uhr war es dann wieder möglich.
Zum Beta-Test:
Wie wir jetzt erkennen, scheint es sich ja aber eigentlich gar nicht um einen Beta-Test, sondern vielmehr um eine Einführungsphase zu handeln, da schon jetzt viele Angaben/Einstellungen zur Umstellung erforderlich sind und keine "Dummy-Daten" im Mandanten vorhanden sind. Wenn es sich aber eigentlich um eine Einführungsphase handelt, ist für uns dann aber wiederum das Einführungsdatum des 06.01.2025 für ein Buchhaltungsmodul überhaupt nicht nachvollziehbar. Das Geschäftsjahr beginnt bei fast allen Vereinen am 01.01. des Jahres. Der Abschluss der Einführungsphase müsste daher unbedingt noch in diesem Jahr liegen, um die Vorbereitungen für den gleich zu Jahresbeginn anstehenden Rechnungslauf abschließen zu können.
Erstes Feedback zum Modul:
Wir müssen leider feststellen, dass unsere vielen Anmerkungen zur Buchhaltungs- und Programmlogik aus den vergangenen beiden Jahren nicht berücksichtigt wurden. Obwohl nun Debitoren und Kreditoren hinterlegbar sind, wird weiterhin alles belegbasiert anstatt debitor- oder kreditorbasiert "gedacht". Die verschiedenen Prozesse bleiben damit unnötig kompliziert. Es scheint, als wurde leider kein Buchhaltungs-Know-How eingeholt und mit keinen anderen bedienerfreundlichen anderen Buchhaltungssoftware-Programmen verglichen. Wir hoffen, dass hier im Zuge der Einführungsphase nochmal drüber nachgedacht und nachgebessert wird. Nochmals bieten wir unseren Erfahrungsschatz aus vielen Jahren Buchhaltung und Warenwirtschaft zum Austausch an.
Zum anderen:
Oben hattest Du von einer "umfassenden Kommunikationskampagne" geschrieben. Bisher können wir neben einer einzigen Newsletter-Email, wenigen Dokumenten im Doku-Bereich und ein paar Hinweisen in der Software selbst weder hier im Forum noch auf der Website noch auf Eurem YouTube-Kanal noch an anderer Stelle Infos/Dokumentationen zum neuen Modul und zum Einführungsablauf finden.
Daher ergeben sich viele Fragen:
- Wann wird es eine Vorstellung der Software in einem gemeinsamen Online-Meeting geben?
- Wie wird die genaue Umstellung der Software konkret erfolgen?
- Mit welchem Modul (neu oder alt) sollen die Beitragsrechnungen am 02.01.2025 erstellt und versendet werden?
- Wie kann man die Mitglieder/Kontakte als Debitoren in einen Mandanten übernehmen oder wann werden diese im neuen Modul als Debitoren angezeigt?
- Werden alle Rechnungen aus 2023 und Vorjahren danach im neuen Modul verfügbar sein?
Ganz generell: An welcher Stelle sollen wir hier im Forum Feedback geben bzw. Fragen stellen? Erstellt ihr der Übersichtlichkeit halber einen eigenen Bereich?
Oder soll jede Anmerkung in einem Support-Ticket gestellt werden?
Fragen, Fragen, Fragen, ....
Viele Grüße
Alex
Hallo Alexander,
Alex hier -- Ich bin für das neue FiBu und Faktura Modul verantwortlich. Wir Oliver bereits erwähnte, haben wir selbstverständlich auf die Community gehört und den größten Teil der offenen Tickets eingearbeitet.
Gerne kannst du mir hier in diesem Ticket mehr Feedback zukommen lassen mit Beispielen damit wir uns das ansehen. Konkret:
wird weiterhin alles belegbasiert anstatt debitor- oder kreditorbasiert "gedacht".
Was genau meinst du damit kannst du das konkretisieren?
Die verschiedenen Prozesse bleiben damit unnötig kompliziert.
Hast du 1-2 Beispiele von Prozessen wo diese konkret unnötig kompliziert sind damit wir uns das im Detail ansehen?
Nochmals bieten wir unseren Erfahrungsschatz aus vielen Jahren Buchhaltung und Warenwirtschaft zum Austausch an.
Gerne, nutzen wir die Chance dieses Tickets dann können sich auch andere mit Feedback beteiligen. Es wäre schon super wenn du ggf. auf obige Fragen konkrete Beispiele hättest damit wir das nachvollziehen können.
- Wann wird es eine Vorstellung der Software in einem gemeinsamen Online-Meeting geben?
Ja, wird per Newsletter angekündigt
- Wie wird die genaue Umstellung der Software konkret erfolgen?
Das jetzige campai wird ab 6.1 komplett mit der neuen FiBu integriert sein ergo Rechnungen, etc. werden dann über das neue erstellt werden
- Mit welchem Modul (neu oder alt) sollen die Beitragsrechnungen am 02.01.2025 erstellt und versendet werden?
Wenn möglich würde ich empfehlen bis 6.1 zu warten damit das Ganze bereits ins neue Modul fließt. Wir arbeiten natürlich hart daran dass wir ggf ein paar Tage früher fertig werden.
- Wie kann man die Mitglieder/Kontakte als Debitoren in einen Mandanten übernehmen oder wann werden diese im neuen Modul als Debitoren angezeigt?
Das passiert mit dem Update am spätestens 6.1 automatisch
- Werden alle Rechnungen aus 2023 und Vorjahren danach im neuen Modul verfügbar sein?
Nein, alle Daten bleiben im jetzigen Modul erhalten und das neue startet mit dem neuen Jahr. Es ändert sich ja z.B. auch der Kontenrahmen komplett.
Hallo Alex,
danke für Deine Antworten und für den Austausch in der Sache. Gern kannst Du mich auch anrufen. Das scheint mir einfacher. Meine Daten sollten hinterlegt sein.
Es kostet viel Zeit, hier alle Dinge zusammenzutragen. Hier dennoch ein paar Erläuterungen:
"Euer Ansatz ist belegbasiert anstatt debitor- oder kreditorbasiert / Hast du 1-2 Beispiele von Prozessen, wo diese konkret unnötig kompliziert sind, damit wir uns das im Detail ansehen?"
Es ist in der Buchhaltung üblich, dass ein Kunden-/Mitgliedskonto als Debitorenkonto geführt wird. Wenn ich Deine Antwort richtig verstanden haben, wird dies nun auch scheinbar im neuen Modul so abgebildet. Beim Anlegen eines Mitglieds wird also dieses Mitglied gleichzeitig als Debitor angelegt. Jetzt bei der Umstellung sollen Deiner Aussage nach auch alle vorhandenen Mitglieder als Debitoren übernommen/geführt werden. Das ist soweit erstmal prima!
Üblicherweise werden dann Geschäftsvorfälle mit Kunden/Lieferanten wie Rechnungsein- und ausgänge bzw. Soll-Stellungen sowie Zahlungsmittelflüsse dann in erster Linie aber einem Debitoren oder Kreditor zugeordnet. Im Falle eines Mitgliedsbeitragseingang also einem Debitorenkonto. Erst im zweiten Schritt erfolgt die Zuordnung zu einer Rechnung/Soll-Stellung dieses Debitors.
Warum muss das so sein?
Bsp: Ein Mitglied überweist Geld für einen Mitgliedsbeitrag von 60,00 Euro, obwohl noch gar keine Soll-, d.h. Rechnungsstellung im System erfolgt ist. Gerade im Vereinsbereich ist dies bei wiederkehrend gleichen Beiträgen (Bringeschuld) nicht selten. Beim (automatischen) Zuweisen des Zahlungseingangs sollte daher als erstes versucht werden, den Betrag einem Debitorenkonto zuzuweisen. Üblicherweise über den Zahlernamen, einen Namen im Verwendungszweck oder die Kunden-, d.h. Mitgliedsnummer im Verwendungszweck. Mit dieser Zuweisung ist der wesentliche Prozess auch abgeschlossen, da das Debitorenkonto dann im genannten Fall ein Guthaben ausweist. Fertig!
Innerhalb des Debitorenkontos kann dann das "Matching" zu einer Soll-Stellung/nach exakt passendem Betrag und bei mehr als einer Soll-Stellung mit gleichem ggf. nach FIFO-Prinzip erfolgen. Auch hier sollte der User aber Möglichkeiten haben, ggf. gleich manuell zuordnen zu können.)
Wenn - wie im genannten Beispiel - noch gar keine Soll-Stellung erfolgt ist, "sucht" Campai momentan immer (in diesem Fall vergeblich) nach Belegen. An vielen Stellen (auch im neuen Modul) muss dann erst ein Beleg erstellt werden, von Euch bspw. hier bspw. als Anzahlungsbeleg bezeichnet. Dies ist aber im Grunde überflüssig und schafft nur Probleme! Insbesondere wenn bestimmte Teile eines Prozesses (Rechnungstellung/Zahlung/Bearbeitung der Verbuchung) zeitlich nicht zusammenfallen.
Auch aus buchhalterischer Sicht ist es vor allem erst mal wichtig, dass zunächst der Geschäftsvorfall des Zahlungseingangs vollständig abgebildet wird. Der korrekte Buchungssatz wäre: Bank 1800 an Debitor 10001 60,00 Euro.
Die Situation haben wir im neuen Modul nachgestellt. Es wird nicht nach Debitor zugeordnet, sondern es muss erst ein Anzahlungsbeleg erstellt werden und dann der Zahlungseingang diesem neu-erstellten Anzahlungsbeleg zugeordnet werden. Damit erscheint aber erst nach dem Zuordnen zum neu erstellten Anzahlungsbeleg eine Buchung in der Buchhaltung.
Gerade bei Teil- oder Überzahlungen macht es dies aber besonders kompliziert bzw. sogar inkorrekt:
Bsp.: Ein Mitglied ist Halbjahreszahler (30,00 Euro pro Halbjahr). Die Soll-Stellung im Debitorenkonto beträgt damit am Jahresanfang 30,00 Euro. Das Mitglied zahlt aber gleich für das gesamte Jahr 60,00 Euro.
Auch im neuen Campai-Modul wird erst zur Rechnung zugeordnet. Es erscheint eine Buchung des Teilbetrags von 30 Euro im Soll der Bank und erst nach Erstellung und Zuordnung zu einem zu erstellenden Anzahlungsbeleg wieder 30 Euro im Soll der Bank. Richtig wäre aber, dass zunächst der vollständige Zahlungseingang von 60,00 im Soll der Bank gegen das Debitorenkonto gebucht wird!
Wenn hier jetzt Dinge noch zeitlich zeitlich auseinander fallen, wird es richtig kompliziert bzw. falsch! Wenn die Bearbeitung und damit die Erstellung des Anzahlungsbelegs ja immer im Nachgang erfolgt, muss dieser trotzdem eigentlich das Datum der Erstellung zum Bearbeitungszeitpunkt ausweisen. Die Zahlung ist ja aber bereits vorher und muss zwingend das Datum des Umsatzes auf dem Bankkonto tragen, damit das Bankkonto in der Buchhaltung stimmt.
Fazit: Der Anzahlungsbeleg und andere "Krücken", die ihr dafür einführt, sind in solchen Fällen überflüssig und schaffen nur komplizierte bzw. falsche Buchungen! Das (nicht sinnvolle) Prinzip, nicht direkt gegen einen Debitor oder Kreditor zu buchen, zieht sich leider durch fast alle Prozesse in Campai und macht es nur unnötig kompliziert bzw. führt teilweise sogar zu nicht korrekter Buchhaltung.
"Wann wird es eine Vorstellung der Software in einem gemeinsamen Online-Meeting geben?
Ja, wird per Newsletter angekündigt"
Es verbleibt ja nicht viel Zeit bis zur Einführung. Unsere Erwartungshaltung wäre, dass das erste Vorstellungsmeeting in der nächsten Woche erfolgt und in der übernächsten Woche ein Schulungsmeeting, in dem die wesentlichen Prozesse an Beispielen gezeigt werden. Parallel dazu sollte Eure Doku auf der Website für das neue Modul vollständig verfügbar sein. Diese Schritte sind notwendig, damit die User ab Anfang des Jahres mit der Buchhaltung arbeiten können! Dass dies schon meilenweit von einer üblichen Vorgehensweise bei einem Release einer Buchhaltungssoftware ist, will ich hier nicht weiter ansprechen.
Bitte habt auf dem Schirm: Unsere bisher hier gestellten Fragen sind ja nur ein Bruchteil dessen, was an Fragen von Usern kommen wird. Von der Benennung von Bugs mal ganz abgesehen. Das ihr hier Beta-Test und Einführungsphase mit einem Release-Candidat "zusammenwerft" ist wirklich schwierig.
Bitte gebt baldmöglichst alle Informationen zu Euren Planungen bzgl. Online-Meeting/Schulung und Doku-Release! Vielen Dank!
"Mit welchem Modul (neu oder alt) sollen die Beitragsrechnungen am 02.01.2025 erstellt und versendet werden?
Wenn möglich würde ich empfehlen bis 6.1 zu warten damit das Ganze bereits ins neue Modul fließt. Wir arbeiten natürlich hart daran dass wir ggf ein paar Tage früher fertig werden."
Das ist ein riesiges Problem!!! Ihr zwingt Euren Kunden damit auf, vom 01.01.-05.01.2025 keine Rechnungen stellen und versenden zu können. Dies ist aber bei ganz vielen Vereinen der Normalfall. Bitte stellt spätestens am 01.01.2025 um 0:00 Uhr die lauffähige neue Version bereit!
"Werden alle Rechnungen aus 2023 und Vorjahren danach im neuen Modul verfügbar sein?
Nein, alle Daten bleiben im jetzigen Modul erhalten und das neue startet mit dem neuen Jahr. Es ändert sich ja z.B. auch der Kontenrahmen komplett."
Das ist für uns leider überhaupt nicht nachvollziehbar. Zumal mit der Begründung des veränderten Kontenrahmens. Wir hoffen, dass bei zukünftigen Änderungen am Kontenrahmen nicht auch wieder bisherige Daten in einem extra Modul geführt werden.
Prüft bitte, ob die alten Buchungen/Belege ggf. etwas später als abgeschlossene Geschäftsjahre übernommen werden können, damit Mitglieds-/Debitorenkonten fortgeschrieben werden können und alles in einer Anwendung verfügbar ist.
Grundsätzliches zur Umstellung/zum Testen:
- An welcher Stelle sollen wir hier im Forum Feedback geben bzw. Fragen stellen? Erstellt ihr der Übersichtlichkeit halber einen eigenen Bereich?
Oder soll jede Anmerkung in einem Support-Ticket gestellt werden?
- Um wirklich testen zu können, müssten wir Daten importieren können. Es gibt ja im neuen Modul auch einen einen Import für Debitoren. Wie kann ich unsere aktuellen Mitglieder im entsprechenden Format aus der Campai-Mitgliederverwaltung exportieren, um sie in das neue Modul importieren zu können?
Oder stellt ihr zumindest Dummy-Daten für Debitoren und Kontoumsätze bereit, die man importieren kann?
- Bisher brachte der große Probleme brachte
Sonstige grundsätzliche Anmerkungen:
- Geht bitte davon aus, dass der Bediener der Software weiß, was er tut. Schränkt es nicht immer unnötig ein. Dies war bisher sehr häufig der Fall und macht unseren Buchhaltungsmitarbeitern das Leben nur unnötig kompliziert. Teilweise verhindert es sogar nötige Buchungen. Leider scheint dies auch im neuen Modul der Fall an verschiedenen Stellen zu sein.
- Hinweise, die den (unerfahrenen) Nutzer unterstützen, sind gut. So etwas sollte es geben. Der Nutzer muss dann aber selbst entscheiden können, ob er bspw. auch auf der Gegenseite eines bestimmten Kontos bucht. Macht ggf. ein Benutzerrecht "Experten-Modus" für den Buchhaltungsbereich verfügbar, so dass ein solcher Nutzer alle Konten bebuchen kann.
Was uns fehlt:
- Eine Unterscheidung zwischen Buchungsstapel und Buchungsjournal.
- Eine "Logik"/"Mechanismus" wie Buchungen überhaupt in den Buchungsstapel/Journal kommen. Zur Zeit wird nach der Erstellung eines Belegs (egal ob "abgeschlossen" oder "nicht abgeschlossen") sofort eine nicht festgeschriebene Buchung unter "Buchungen" angezeigt. Das wirkt zwar erstmal smart und besser als das bisherige "Synchronisieren" via Datumsbereich, das auch große Probleme mit sich brachte, ist aber für den täglichen Betrieb insbesondere in einem Mehrbenutzer-System problematisch. Wenn die Buchhaltungsmitarbeiter versuchen, die Buchhaltung abzustimmen, und parallel werden Rechnungen erstellt oder alte storniert und dies sofort im Journal sichtbar wird, kann sich die Buchhaltung die "Karten legen". Das wird nicht funktionieren! Der Buchhalter muss entscheiden können, wann Buchungen aus den neuen Geschäftsvorfällen erzeugt/übertragen werden!
- Buchungen, obwohl nicht festgeschrieben, sind nicht änderbar. (Vielleicht finden wir auch einfach die Option nicht!)
- Bei Auswertungen wie EÜR und SuSa sollte zwischen Ansichten "nur festgeschriebene" und "mit noch nicht festgeschriebenen" Buchungen unterschieden werden können.
- Bei Listenansichten/Journalen sollte es immer die Möglichkeit geben auf Konten (und nicht nur auf Kostenstellen) einzugrenzen und eine Summen- und Saldenanzeige direkt in dieser Ansicht zu zeigen. Dies ist doch zwingend erforderlich, um nach Buchungen einen Abgleich gegenüber dem Kontostand machen zu können.
- Leider hält der Download von Rechnungen/Belegen noch immer keinen anpassbaren Dateinamen bereit. Bitte ermöglicht es umgehend! Es bedeutet immer einen unverhältnismäßigen Aufwand, bspw. Rechnungen beim Kuvertieren zu sortieren, um diese mit anderen Dokumenten wie bspw. Aufnahmebrief und Mitgliedsausweis zusammenzufügen. Die Rechnungsnummer ist , da ich diese ja bei den anderen Dokumenten. Lasst den Nutzer über den Dateinamen beim Download mit Platzhaltern entscheiden, wie dieser aufgebaut ist.
- diverse weitere Punkte...
Kleine Bugs, die nebenbei aufgefallen sind:
- In der Summen- und Saldenliste ist der Monat "März" zweimal aufgeführt. Es fehlt aber der "Oktober".
- Name eines angebundenen Bankkontos ist nachträglich nicht änderbar.
Weitere Fragen:
- Wie verhält es sich nach der Umstellung dann mit den Saldenvorträgen aus den bisherigen Mitgliedskonten? Wird dies automatisch übernommen?
- Werden die angelegten Beiträge und Aufnahmegebühren auch als "Produkte" im neuen Modul erscheinen?
Viele Grüße
Alex
P.S.: Alle obengenannten grundsätzlichen Infos und Anmerkungen sind in diversen Meetings mit Euren Mitarbeitern und Tickets im Support in den letzten Monaten und Jahren beschrieben worden. Das erst jetzt - trotz vieler Nachfragen in den letzten Monaten, einen Beta-Test endlich zu starten - ein Einblick möglich wird und diese Anmerkungen erst jetzt erneut angebracht werden können, schmerzt uns sehr.
Hi,
Debitoren / Kreditoren
Die Anzahlungsrechnungen müssen wir verwenden um später korrekt dagegen aufzulösen mit dem tatsächlichen Guthaben. Die Belege für Mitgliedsrechnungen sollten ja vorhanden sein da diese ja automatisch erstellt werden.
Bei einer Überzahlung von z.B. 30 eur wird dann 30 euro automatisch auf den fälligen Beitragsbeleg gebucht und 30 Eur werden als Anzahlungsrechnung erstellt. Buchhalterisch ist das schon korrekt so (Haben wir verifizieren lassen) da die Anzahlung auf einem anderen Konto erstmal zwischen geparkt werden muss bis diese aufgelöst werden kann.
Wenn jetzt die nächste Mitgliedsrechnung über 30 Eur erstellt werden würde, würde er noch die 30 Eur der Anzahlung finden, diese verwenden und beide Belege als bereits abgeschlossen markieren bei der Erstellung.
Das Problem liegt vielleicht eher an der UI? Ich kenne eure Prozesse dafür zu wenig. Aber vielleicht wenn man einen einfacheren Dialog hätte in dem gleich alles drin ist und die Anzahlungsrechnung dann z.B. korrekt im Hintergrund erstellt wird ohne extra Dialog wäre schon eine Lösung.
Wie es buchhalterisch falsch sein sollte verstehe ich nicht ganz. Entscheidend ist das Buchungsdatum auf dem Bankkonto. Wird die Anzahlungsrechnung erstellt erhält diese dasselbe Datum kann also nicht falsch sein.
Wenn es euch hilft könnten wir auch im "Neue Buchung erstellen" Dialog auch das direkte Verbuchungen auf Debitoren/Kreditoren Konten erlauben, würde euch das weiterhelfen? Dann allerdings ohne Anzahlungsrechnungen kann das System keine Guthaben automatisch beim erstellen neuer Rechnungen gegenrechnen.
Wir arbeiten nach dem buchhalterischen Grundprinzip "Keine Buchung ohne Beleg".
Vorstellung der Software
Ja, es ging gestern Abend noch eine Mail raus mit drei Terminen für nächste Woche dass alle teilnehmen können 😃
Umstellung / Testen
Die Testphase ist bereits abgeschlossen. Die Preview (nicht Beta) dient dazu, dass man sich einige Wochen vor eigentlichem Release schon mit dem System vertraut machen kann und nicht erst im neuen Jahr überrascht ist.
Feedback gerne im Forum und oder besser als Feedback Tickets damit wir das Finanzmodule entsprechend den Wünschen weiterentwickeln können.
Debitoren werden beim eigentlichen Release dann automatisch mit den Mitgliedern/Kontakten/Zahlern verknüpft.
Sonstige grundsätzliche Anmerkungen
Leider weiß der Bediener oft nicht was er tut und wir haben die meisten Support-Anfragen wegen falschen Buchungen die Kunden durchführen. Natürlich aber sollte es Experten nicht einschränken da bin ich absolut bei dir und da müssen wir schauen wo wir ggf. Restriktionen aufheben müssen.
Bis auf obiges Beispiel mit den Debitoren welche Stellen gibt es im neuen Modul noch von denen du schreibst, dass diese unnötig kompliziert sind oder Buchungen verhindern? Schaue ich mir dann gerne separat jedes einzelne an und gucke was man da dann ggf noch verbessern könnte.
Was uns fehlt
Eine Unterscheidung zwischen Buchungsstapel und Buchungsjournal
Wir verwenden standardmäßig die Stapelbuchung und implementieren die Dialogbuchung durch die Festschreibung
- Eine "Logik"/"Mechanismus" wie Buchungen überhaupt in den Buchungsstapel/Journal kommen. Zur Zeit wird nach der Erstellung eines Belegs (egal ob "abgeschlossen" oder "nicht abgeschlossen") sofort eine nicht festgeschriebene Buchung unter "Buchungen" angezeigt. Das wirkt zwar erstmal smart und besser als das bisherige "Synchronisieren" via Datumsbereich, das auch große Probleme mit sich brachte, ist aber für den täglichen Betrieb insbesondere in einem Mehrbenutzer-System problematisch. Wenn die Buchhaltungsmitarbeiter versuchen, die Buchhaltung abzustimmen, und parallel werden Rechnungen erstellt oder alte storniert und dies sofort im Journal sichtbar wird, kann sich die Buchhaltung die "Karten legen". Das wird nicht funktionieren! Der Buchhalter muss entscheiden können, wann Buchungen aus den neuen Geschäftsvorfällen erzeugt/übertragen werden!-
Zum Thema unnötig kompliziert haben wir ja absichtlich jetzt dass System dass Buchungen automatisch im Hintergrund erfolgen und man nicht noch manuell Rechnungen wieder extra einbuchen muss. Wie sollte sonst auch eine OPOS Liste etc. auf Debitoren erfolgen wenn diese nicht mit den Rechnungen direkt verknüpft sind. Wir haben uns hier 1:1 an gängige Software wie Datev ReWe etc gehalten die das genauso machen.
Buchungen, obwohl nicht festgeschrieben, sind nicht änderbar. (Vielleicht finden wir auch einfach die Option nicht!)
Korrekt, Buchungen werden immer gelöscht und neu erzeugt. Buchungen die vom System durch Belege erzeugt werden, müssen auch von dort geändert werden.
- Bei Auswertungen wie EÜR und SuSa sollte zwischen Ansichten "nur festgeschriebene" und "mit noch nicht festgeschriebenen" Buchungen unterschieden werden können.
Ja, das ist ein absolut valider Punkt den ich gerne mit aufnehme
- Bei Listenansichten/Journalen sollte es immer die Möglichkeit geben auf Konten (und nicht nur auf Kostenstellen) einzugrenzen und eine Summen- und Saldenanzeige direkt in dieser Ansicht zu zeigen. Dies ist doch zwingend erforderlich, um nach Buchungen einen Abgleich gegenüber dem Kontostand machen zu können.
Den Punkt verstehe ich leider nicht ganz. Auf Konten kannst du im Journal ja über die Suchfunktion oder respektive bei Kontenklassen über die Sidebar eingrenzen. Wenn du auf Kontenübersicht gehst und dann dort wieder ein Konto klickst kannst du ja alle Buchungen nur für dieses Konto mit Saldo etc. auch einsehen.
- Leider hält der Download von Rechnungen/Belegen noch immer keinen anpassbaren Dateinamen bereit. Bitte ermöglicht es umgehend! Es bedeutet immer einen unverhältnismäßigen Aufwand, bspw. Rechnungen beim Kuvertieren zu sortieren, um diese mit anderen Dokumenten wie bspw. Aufnahmebrief und Mitgliedsausweis zusammenzufügen. Die Rechnungsnummer ist , da ich diese ja bei den anderen Dokumenten. Lasst den Nutzer über den Dateinamen beim Download mit Platzhaltern entscheiden, wie dieser aufgebaut ist.
Muss ich mir ansehen, sollte eigentlich immer die Belegnummer nehmen. Was genau würdest du denn anpassen wollen da wir nur begrenz Informationen wie zB. Belegnummer beim erstellen der Dokumente haben? Da können wir wenn ich das genauer verstanden habe sicher nacharbeiten um das Leben zu vereinfachen.
Kleine Bugs, die nebenbei aufgefallen sind
- In der Summen- und Saldenliste ist der Monat "März" zweimal aufgeführt. Es fehlt aber der "Oktober"
Danke, schaue ich mir gleich an
Name eines angebundenen Bankkontos ist nachträglich nicht änderbar.
Meinst du, eines Online-Kontos? Das können wir sicher ändern.
Weitere Fragen😶
Wie verhält es sich nach der Umstellung dann mit den Saldenvorträgen aus den bisherigen Mitgliedskonten? Wird dies automatisch übernommen?
Da überlegen wir noch. Da im jetzigen System das eigentlich keine echten Saldenvorträge sind sondern ein völlig falsches System (deswegen wirds auch abgeschafft) und offenen Rechnungen, Gutschriften etc. können wir da nicht einfach was übernehmen da die offenen Rechnungen ja noch im alten System abgeschlossen werden müssen um den Ausgleich zu erreichen.
Werden die angelegten Beiträge und Aufnahmegebühren auch als "Produkte" im neuen Modul erscheinen?
Die Beiträge etc. bleiben erstmal da wo diese sind, da ändert sich nichts. Es ändert sich nur dass ab 25 die Rechnungen davon nicht mehr im alten sondern im neuen System erfasst werden.
P.S.: Alle obengenannten grundsätzlichen Infos und Anmerkungen sind in diversen Meetings mit Euren Mitarbeitern und Tickets im Support in den letzten Monaten und Jahren beschrieben worden. Das erst jetzt - trotz vieler Nachfragen in den letzten Monaten, einen Beta-Test endlich zu starten - ein Einblick möglich wird und diese Anmerkungen erst jetzt erneut angebracht werden können, schmerzt uns sehr.
Die Entwicklung hat entsprechend lange leider gedauert. Ich würde allerdings stark empfehlen, für Änderungswünsche etc. immer und auschließlich unsere Feedback-Tickets zu benutzen. Daran orientieren wir uns bei der Entwicklung (haben mit dem neuen System ja jetzt auch knapp 80% der Tickets erledigen können). Direktes Feedback im Support geht oft unter da der Support dafür da ist, direkte Hilfestellung zu leisten. Aber jegliches Feedback bitte unbedingt in die Feedback tickets rein dafür sind die da 😃
Was wir jetzt da haben ist auch eine komplett neue Technologie auf die wir setzen. Ergo nichts ist ja in Stein gemeißelt und wir werden die Fibu weiter über nächstes Jahr anpassen anhand der Feedback Tickets und deren Gewichtung.
Kleiner Nachtrag:
- In der Summen- und Saldenliste ist der Monat "März" zweimal aufgeführt. Es fehlt aber der "Oktober"
Wollte ich gerade nachstellen passiert bei mir aber nicht. Hast du dazu mehr infos? Ggf. ein anderes Datum eingestellt oder abweichendes Geschäftsjahr oder.. ?
danke
Alex
Hallo Alex,
danke für Deine Nachricht. Ich empfehle dringend ein Telefonat, da wir nicht leisten können, hier alles schriftlich zu erläutern.
Hier dennoch nochmal zu den Denklogiken rund um Zahlungsflüsse und Debitoren / Kreditoren:
"Die Anzahlungsrechnungen müssen wir verwenden, um später korrekt dagegen aufzulösen mit dem tatsächlichen Guthaben."
Genau das ist schon der Fehler in der Denklogik. Das Guthaben entsteht durch den Saldo auf dem Debitorenkonto, nicht durch irgendeinen weiteren Beleg!
Bitte unterscheidet korrekt, was der jeweilige Geschäftsvorfall ist!!!
"Buchhalterisch ist das schon korrekt so (Haben wir verifizieren lassen) da die Anzahlung auf einem anderen Konto erstmal zwischen geparkt werden muss bis diese aufgelöst werden kann."
Nein, es muss nicht auf einem anderen Konto zwischengeparkt werden. Das "Zwischenparken" kann genau auf dem Debitorenkonto passieren!
"Wenn jetzt die nächste Mitgliedsrechnung über 30 Eur erstellt werden würde, würde er noch die 30 Euro der Anzahlung finden, diese verwenden und beide Belege als bereits abgeschlossen markieren bei der Erstellung."
Das würde bei der Verrechnung mit dem Saldo vom Debitorenkonto genauso laufen. Und so wird es eben auch üblicherweise gemacht!
"Das Problem liegt vielleicht eher an der UI?"
Nein, vor allem liegt es an der Denklogik. Debitoren- und Belegzuweisung kann ja meist in einem Schritt und hoffentlich meist automatisiert erfolgen. Das Problem ist, Eure nicht korrekte, buchhalterische Denklogik, die es kompliziert macht!
Der zugrundeliegende Geschäftsvorfall ist erstmal nur der Zahlungseingang auf dem Bankkonto! Das muss sauber zugeordnet und dann auch verbucht werden. Darum geht es. Wie schon oft empfohlen: Schaut Euch bitte mal an, wie das bei anderen Software-Produkten gemacht wird!
"Aber vielleicht wenn man einen einfacheren Dialog hätte in dem gleich alles drin ist und die Anzahlungsrechnung dann z.B. korrekt im Hintergrund erstellt wird ohne extra Dialog wäre schon eine Lösung."
Schon das automatisierte Erstellen einer "Anzahlungsrechnung" ist überflüssig und stellt einen Geschäftsvorfall dar, der nicht existiert, da es in dem Fall keine Anzahlung, sondern eine Überzahlung gegeben hat! Das ist zum einen nicht das gleiche und zum anderen verkompliziert Euer Ansatz später nur alles, unter anderem die Darstellung und Nachvollziehbarkeit!
Randnotiz: Beim alten Modul ist das bei der Rücklastschriftbearbeitung ähnlich "schief" aus buchhalterischer und am Ende aus Nutzer-Sicht. Es werden Gutschriften erzeugt, obwohl diese gar nicht nötig oder sogar falsch sind. Nur weil eine Lastschrift gescheitert oder zurückgebucht wurde, ist die ursprüngliche Rechnung nicht falsch. Ganz im Gegenteil: Sie muss bestehen bleiben. Man erzeugt ggf. eine weitere Rechnung über dem Kunden in Rechnung gestellte RL-Gebühren und fordert ihn zur Zahlung der ursprünglichen und der neuen Gebühren-Rechnung auf. Im neuen Modul konnten wir Rücklastschriften noch nicht testen, hoffen aber, dass ihr hier endlich einen anderen Weg gegangen seid!
"Wie es buchhalterisch falsch sein sollte, verstehe ich nicht ganz. Entscheidend ist das Buchungsdatum auf dem Bankkonto. Wird die Anzahlungsrechnung erstellt, erhält diese dasselbe Datum. Kann also nicht falsch sein."
Auch hierbei erstmal zu den Grundthemen: Es ist eigentlich zwischen Buchungs-, Beleg- und ZE/Wertstellungsdatum zu unterscheiden. Allein das läuft hier auch schon durcheinander!
Du schreibst: "Entscheidend ist das Buchungsdatum auf dem Bankkonto." Das ist richtig, aber eben nur für die Verbuchung des Zahlungseingangs! Nicht korrekt ist aber, zum Bearbeitungszeitpunkt des Zahlungseingang (Datum Y) rückwirkend mit in der Vergangenheit liegendem Datum X des Zahlungseingangs eine "Anzahlungsrechnung" auszustellen. Es ist bitte dringend zu verstehen: Was ist abzubildende Geschäftsvorfall! Hier ist es eine Überzahlung, keine Anzahlung!
Und beim Verbuchen/Zuordnen der Zahlungseingänge ist der zunächst abzubildende Geschäftsvorfall eben der Zahlungseingang auf dem Bankkonto. Wie im Beispiel oben beschrieben mit Buchungssatz zum Datum des Zahlungseingangs: Bank 1800 an Debitor 10001 60,00 Euro.
Die Vereinbarung zu einer Anzahlung gibt es zu diesem Zeitpunkt ja gar nicht! Genau das versucht ihr aber zu fingieren und dann buchhalterisch abzubilden. Das ist nicht korrekt!
Das Zahlungseingangsdatum liegt ja vor dem Belegdatum des Anzahlungsbelegs, der ja erst beim Bearbeiten und damit nach dem Zahlungseingangs entsteht. Das sind also 2 Geschäftsvorfälle zu unterschiedlichen Zeitpunkten mit einem jeweils unterschiedlichen Datum.
Beim Bearbeiten des Zahlungseingangs versucht ihr zu "fingieren", als hätte es eine Anzahlungsvereinbarung gegeben, um krampfhaft einen Beleg zu erzeugen! Das ist aber beides überflüssig und macht es komplizierter, als es ist.
Um es nochmal klar zu sagen: Es geht hier nicht nur um "Wortklauberei" zu Begrifflichkeiten wie Anzahlung und Überzahlung, sondern um die daraus resultierenden Dinge für die Buchhaltung!
"Wenn es euch hilft könnten wir auch im "Neue Buchung erstellen" Dialog auch das direkte Verbuchungen auf Debitoren/Kreditoren Konten erlauben, würde euch das weiterhelfen?"
Wir benötigen nicht unbedingt einen weiteren "Button". Das sollte grundsätzlich automatisiert ablaufen!!! Wenn ich hier von "Schritten" spreche, dann geht es um die Programm- und Buchhaltungslogik. Nicht um Bedienerschritte.
"Dann allerdings ohne Anzahlungsrechnungen kann das System keine Guthaben automatisch beim erstellen neuer Rechnungen gegenrechnen."
Das Verrechnen würde mit dem Saldo auf einem Debitorenkonto genauso laufen. Und so macht man es üblicherweise auch automatisiert. Das sollte daher der Standard sein, nicht anders. Das ist einer der Punkte, bei der Eure Programmlogik es viel komplizierter macht und mehr Handlungsbedarf beim Benutzer erzeugt.
Vorgehen beim Zahlungseingang;
Wenn Debitor und Beleg exakt zugeordnet werden konnte: Prima!
Wenn nur Debitor zugeordnet werden konnte: Auch gut und der wesentliche Teil des Geschäftsvorfalls "Zahlungseingang" wäre abgeschlossen und korrekt verbucht!
Das Guthaben entsteht als Saldo auf dem Deb-Konto.
In den Einstellungen hinterlegt man bspw. dafür schon Grundsätze für die Programmlogik, wie bspw.
Zuordnen von Zahlungseingängen zu Positionen/Rechnungen im Debitorenkonto
a) strikt nach FIFO-Prinzip
b) Matching zu exaktem Betrag und Rechnungsnummer aus Verwendungszweck, dann bei mehreren betragsgleichen, exakt passenden Positionen FIFO-Prinzip
Umgang mit Guthaben auf Debitoren-Konto
a) Grundsätzlich Guthaben mit nächster Rechnung verrechnen.
b) Grundsätzlich Guthaben auf das Senderkonto zurückzahlen.
"Wir arbeiten nach dem buchhalterischen Grundprinzip "Keine Buchung ohne Beleg".
Ja, das macht ihr, aber eben in falsch verstandener Weise! Der hier im Beispiel beschriebene Geschäftsvorfall ist der Zahlungseingang!!! Der passende Beleg dazu ist der Kontoauszug!!! Es benötigt keinen weiteren Beleg!
Das, was ihr als Krücke "fingiert", ist, als hätte es eine Absprache mit dem Mitglied gegeben, dass eine Anzahlung zu leisten sei. Das würde üblicherweise vor Zahlungseingang passieren. Das ist hier doch aber gar nicht der Fall und muss auch nicht sein!!!
"Wir haben uns hier 1:1 an gängige Software wie Datev ReWe etc gehalten, die das genauso machen."
Das stimmt leider nicht!!! Wir nutzen Datev-ReWe! Belege/Umsätze werden dort erst bereitgestellt. Der Buchhalter entscheidet dann, welche Belege er wann in welchen Buchungsstapel holt und dann verbucht!!! Bei allem anderen könnte kein Buchhalter seinem Job nachkommen!
Auch das ist genau einer der Fehler in der Denklogik. Sprecht doch mal mit einem Buchhalter und lasst ihn die Software testen. Wir geben Euch seit zwei Jahren kostenlos dieses wohlgemeinte Feedback, machen Angebote, aber es wird leider nicht genutzt.
An der Stelle muss ich erstmal unterbrechen. Wir können nicht unendlich viel Zeit investieren, wenn es am Ende leider doch alles nicht berücksichtigt zu werden scheint. Wenn Interesse besteht, stehe ich gern für ein Telefonat zur Verfügung. Auch am Wochenende.
Bedauerlicherweise müssen wir feststellen: Ihr versucht eine Buchhaltungssoftware zu entwickeln, holt Euch aber viel zu wenig Buchhaltungs-Know-How in Euer Team! Die Community bindet ihr auch nicht ein. Auf dem Community-Event wird von Beta-Tests gesprochen, zu denen alle mit eingeladen werden. Erst im Sommer, dann im Herbst, dann im Winter. Auch Oliver schreibt in der letzten Woche noch von "Beta-Test" hier im Forum. Du schreibst jetzt: "Die Testphase ist bereits abgeschlossen". Es sei jetzt eine "Preview"!
Deine Aussage zum Vorgehen und zu Eurer neuen Arbeitsweise war auf dem Community-Event eine ganz andere. Schade!
Hi,
Lass uns die zwei Themen dann doch etwas kürzer beleuchten damit nicht zuviel Zeit draufgeht.
Die Anzahlungsrechnungen machen wir u.a. aus steuerlichen Gründen da z.B. Überzahlungen unter Umständen Steuerpflichtig werden. Die Anzahlungsrechnung ist korrekt und nochmal verifiziert worden dass die Buchungen darunter der gängigen Praxis entstammen um ebend jenes Steuerproblem sauber zu lösen.
Ich verstehe aber, dass es bei Vereinen ggf. etwas anders ist dadurch dass wir ja steuerbefreite Bereiche haben.
Um das Ganze etwas voranzubringen kannst Du mir ggf sagen:
- Welche Buchungssoftware genau das Verhalten aufweist mit Debitoren von dem Du sprichst und automatisch den Debitoren-Saldo mit Rechnungen verrechnet damit ich mir das mal ansehen kann
- Wie würden wir das Problem buchhalterisch lösen? Nehmen wir an wir verbuchen den Eingang der Zahlung von 60 EUR, 30 EUR gehen gegen eine Rechnung/Beleg, soweit so gut. Die restlichen 30 EUR würden wir von der Bank an den Debitor buchen damit dieser einen Saldo aufweist
- Eine neue Rechnung über 30 EUR würde erstellt werden. Wir verrechnen die 30 EUR Saldo vom Debitoren mit der Rechnung, die Forderungssumme beläuft sich also auf 0 EUR. Wie genau sollten wir dann den Saldo von 30 EUR auf dem Debitorenkonto ausbuchen da die Rechnung selbst ja 0 EUR aufweist vielleicht hast du mir da konkrete Buchungsvorschläge mit Konten wie das aussehen würde respektive gewünscht wäre?
Zweites Thema Buchungsstapel. Angenommen die Rechnungen und Zahlungen beeinflussen die Buchhaltung nicht. Wie wäre der Prozess für den Buchhalter, diese dann manuell in die Buchhaltung zu übernehmen so dass Du sagst das wäre gut gelöst? Alle Belege einzeln durchgehen und sagen "In Buchhaltung überführen" oder ähnliches?
Wenn das manuell geschieht haben wir dann aber eine weitere Gefahr z.B. angenommen wie oben genannt verrechnen wir Debitoren Saldos gegen neue Rechnungen. Da dies aber erst manuell übertragen wird, also zu spät erfolgt, könnte es so z.B. auch sehr leicht passieren dass der Debitoren Saldo mehrfach verrechnet wird da er erst später vom Buchhalter manuell ausgeglichen wird. Wie würde man dies lösen wollen?
Telefonieren ist schwer da ich ein Fan davon bin, Dinge schriftlich festzuhalten da sonst bei mir danach nichts hängen bleibt. Deswegen die zwei konkreten Themen oben mit konkreten Fragen. Bin ich gerne bereit das noch zusätzlich anders zu lösen sobald die zwei Thematiken korrekt verstanden und nachvollziehen zu können.
lg
Alex