...und wenn wir einfach schon mal die Möglichkeiten nutzen, die uns Fakturama eh schon bietet?

Ich hab mal eine Brief-Vorlage erstellt...

Brief-Formular für Datenschutzauskunft

Hallo Manfred,

Sehr gut... Damit wäre der Punkt a zu potentiellen Auskunftsersuchen ja schon erledigt. (tu)
Um Punkt d muss sich jeder selbst bemühen, aber dazu gibt es Vorlagen im Netz.
Blieben noch die übrigen gesetzlichen Vorgaben, aber eventuell hat Fakturama da auch schon nutzbare Bordmittel unter der Haube!?

LG
Matthew

Hallo zusammen,
wenn Fakturama revisionssicher werden soll kann ich das für mindestens ein Jahr vom Netz nehmen 🙁 Das ist derartig aufwendig, daß ich das mal nicht eben so nebenbei erledigen kann. Generell würde das aber auch andere OpenSource-Programme (hibiscus, jesEÜR u.a.) betreffen. Mir ist die Problematik durchaus bewußt, aber ich glaube, der User Miracolitag hat hier schon mal einiges zusammengetragen. Vielleicht kann der ja noch einen Beitrag leisten.

Jo, wie fange ich an? Vielleicht damit, dass auch ich mittlerweile Vorträge über das Thema GoBD, digitale Buchführung und papierloses Büro halte, also in gewisser Form da etwas Wissen habe.

Vorab: Fakturama ist hier in keiner Weise betroffen!

Das Problem: Wenn neue Herausforderungen entstehen, entsteht immer auch Panik. Dazu kommen noch (Wissens)Freiräume, die der Gesetzgeber in teilweise guter Absicht lässt und viele viele Interpretationen (im Falle der GoBD) auch bzw. sogar sehr oft von Steuerberatern. Das heißt, so wie auch Ärzte auf ihrem Gebiet keine Götter sein müssen, sind es offensichtlich manche Steuerberater auch nicht.

Bei der EU-Datenschutzgrundverordnung ist Fakturama noch nicht einmal peripher betroffen. Man könnte höchstens eine Erinnerungsfunktion einbauen zu Datensätzen, die 3 Jahre nicht benutzt wurden. Aber das ist kein tragender Pfeiler. Ansonsten zur Auskunft Manfreds Formular (DANKE!) nutzen. Alle Speicherfelder des Kontakteditors haben Platzhalter für den Druck. Alle Platzhalter auf dieses Formular und schon ist der Kunde informiert.

GoBD - Zuerst ein paar Fakten:

Wenn keine Ablage im DMS als eigenes Dokument erfolgt, sondern die Daten in einer anderen Anwendung (z. B.: Fakturierungssystem) bleiben, müssen dort die Anforderungen an die Ordnungsmäßigkeit erfüllt werden. Ist die Anwendung hierzu nicht in der Lage, sollten die erzeugten Dokumente sicherheitshalber im DMS aufbewahrt werden.
Es empfiehlt sich in der Praxis häufig, die entsprechenden Ausgangsbelege zum Zeitpunkt der Erstellung in einem Bildformat (z. B. PDF- oder TIFF-Datei) der Aufbewahrung zuzuführen.

--> Ergo: DMS anbinden, wie es Fakturama V2 mit (zB) ecoDMS vorsieht. Wer möchte, kann auch die originären odt-Dateien mit archivieren. Die Umwandlung in ein PDF erfolgt dann automatisch.
--> Auch ergo: Jeder darf weiterhin seine Rechnungen mit Word schreiben, denn Microsoft wird auch diese Anwendung todsicher in absehbarer Zeit nicht GoBD-konform machen. Und mehr als ein besseres Word ist Fakturama auch nicht (hoffentlich schlägt mich Ralf jetzt nicht ;-)).

Belege in Papierform oder in elektronischer Form sind zeitnah, d. h. möglichst unmittelbar nach Eingang oder Entstehung gegen Verlust zu sichern.

--> Über die Schnittstelle von Fakturama zu ecoDMS werden die Rechnungen unmittelbar (!) archiviert. Somit ist dem Grundsatz der Unverlierbarkeit genüge getan und einer Manipulation hinreichend vorgebeugt. Das ganze dann noch in der Verfahrensdoku beschreiben. Fertig.

Eine zentrale Anforderung der GoBD betrifft die Unveränderbarkeit. Gewährleisten lässt sich dies
- hardwareseitig z. B. durch unveränderbare und fälschungssichere Datenträger
- softwareseitig z. B. durch Sicherungen, Sperren, Festschreibung, Löschmerker, automatische Protokollierung, Historisierungen, Versionierungen)
- organisatorisch z. B. mittels Zugriffsberechtigungskonzepten
- Kombinationen

--> Ergo: Auch organisatorische Maßnahmen wie Zugriffsberechtigungskonzepte genügen.

Die im Sinne der GoBD aufbewahrungs- und aufzeichnungspflichtigen elektronischen Dokumente und Daten müssen unveränderbar (Rz. 59) und im Originalformat (Rz. 119) aufbewahrt werden. Eine Ablage außerhalb eines revisionssicheren Systems erfüllt ohne Ergreifen weiterer Maßnahmen diese Anforderungen nicht (Rz. 110).

--> Ergo:
Die Finanzverwaltung geht in vielen Fällen davon aus, dass diese Forderung nach Unveränderbarkeit bei dem derzeitigen Stand der Technik den Einsatz eines revisionssicheren DMS zwingend notwendig macht.

DABEI INTERESSANT:
Unter Kostengesichtspunkten könne nur in einzelnen (wenigen) Fällen darauf verzichtet werden, da der Grundsatz der Wirtschaftlichkeit es nicht rechtfertige, die Grundprinzipien der Ordnungsmäßigkeit zu verletzen. Der Steuerpflichtige sei vielmehr verpflichtet, die erforderlichen Kosten genauso in Kauf zunehmen, wie alle anderen Aufwendungen, die die Art seines Betriebes mit sich bringen (Rz. 29).

organisatorische Maßnahmen:
In der Praxis handelt es sich hierbei stets um ein Bündel von Maßnahmen, das einerseits mittels Organisationsanweisungen sowie Schreib- und Zugriffsschutz die Unveränderbarkeit sicherstellt und anderseits mittels technischer Mittel wie regelmäßiger Datensicherungen die Einhaltung des Grundsatzes dokumentiert.

Darüber Hinaus müssen derartige Dokumente auch sicher vor Verlust oder Beschädigung geschützt werden. Dazu sollte es zusätzlich eine Backup-Lösung geben, welche die DB und das Arbeitsverzeichniss z.B. automatisch in eine ZIP- Datei Archiviert.

Die Backup-Lösung gibt es ja. Und die Daten vor Verlust schützen hat etwas mit der technisch verfügbaren Hardware zu tun.

Lebensdauer Beispiele:
CD-R: 5 … 10 Jahre
Festplatten: 2 … 10 Jahre, je nach Betriebsdauer (im Mittel: 5 Jahre)

Da hilft auch kein Backup! Das muss jeder Unternehmer hardwaretechnisch für sich entscheiden. Das Thema Cloud schneide ich hier jetzt bewusst nicht an 😉

Schade das hier Einzel- und Kleinunternehmen vom Gesetzgeber mittlerweile genau so behandelt werden wie Großkonzerne.

Stimmt nicht. Zum einen haben sich nicht die Finanzbehörden die GoBD ausgedacht, sondern es hat ein richtig großer Kreis von Fachleuten daran gearbeitet (Google-Stichwort: AWV e.V.).
Zum anderen wird bei Interpretationen immer betont, dass (im Normalfall) mit Augenmaß geprüft wird.
Wir dürfen aber auch nicht vergessen, dass wir im Jahr 2018 leben und im Wunschfall der Geschäftsverkehr bereits schon jetzt digital läuft. Oder möchte noch jemand seine USt-Voranmeldung händisch in Formbögen eintragen und per Einschreiben oder persönlich dem Finanzamt zukommen lassen? Nee, wir erwarten einiges von den Behörden und die Behörden erwarten etwas von uns.
Und nicht vergessen: Papier zu fälschen ist recht schwierig. Ein PDF zu fälschen ist kinderleicht. Wenn wir also wollen, dass E-Mails und elektronische Rechnungen dem Papier gesetzlich gleichgestellt werden, müssen auch wir etwas gegen deren Fälschbarkeit tun.

Die neuen Grundsätze sollten nach unserer Auffassung nicht als bürokratisch überzogene Vorschriften wahrgenommen werden, sondern als Chance dienen, die eigenen Prozesse und Tätigkeiten zu hinterfragen, um Schwachstellen zu beseitigen und die eigene Leistungsfähigkeit zu steigern. Ich kann trotzdem nur jedem empfehlen, sich mit den GoBD zu beschäftigen, denn Ansprechpartner der Finanzbehörden bleibt der Steuerpflichtige und nicht der Steuerberater! Auch wenn Fakturama GoBD-konform werden würde, wäre kein einziger unserer Nutzer raus aus dem Schneider. Dazu gehört einfach noch mehr.

Wunderbar! Danke für diese umwerfend ausführliche Darstellung. Neu für mich war hier, daß auch der AWV drinhängt. Der hat ja schon das ZUGFeRD verbockt.

Trotzdem hier nochmal ein WICHTIGER HINWEIS: Aktuell sichert Fakturama die Datenbank nicht (HSQL nicht und die MySQL sowieso nicht). Deswegen ist JEDER (!!!) Anwender dazu angehalten, REGELMÄẞIG(!!!) (man beachte das große "ß" 😉 ) seine Daten zu sichern, und zwar sowohl die Datenbank als auch die Dokumente. Bitte diesen Text ausdrucken, 200fach vergrößern und über den Schreibtisch hängen!!!

Unabhängig davon möchte ich mich natürlich nicht aus der Verantwortung stehlen, aber Fakturama ist und bleibt nun mal eine OpenSource-Software. Und ich möchte nochmal kurz den Passus zitieren, den jeder von euch bei der Installation bestätigt hat:

EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement , including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations.

Bitte denkt daran, wenn ihr die Software einsetzt. Ich hoffe, der angelsächsische Dialekt stört nicht so sehr. Wenn euch das zu heiß ist, dann nehmt lieber eine kommerzielle Software, da sind die Haftungsfragen meistens ganz anders geregelt. Fakturama ist tatsächlich ein etwas abgewandeltes Word, da hat Steffen durchaus Recht und ich sehe das auch nicht als Kritik an 🙂 Aber es wird eben derzeit auch nur von einem Menschen programmiert. Und der will auch manchmal Zeit für Familie und Hobby haben...

So. Ich werde jetzt Steffens Text vertonen und leise vor mich hinsingen 😉

Besten Dank für den Ausführlichen Beitrag von Miracolitag, der tatsächlich etwas Klarheit bringt.

Das Fakturama revisionssicher werden solle hab ich ja nicht geschrieben und das wäre wohl auch weit übers Ziel hinaus geschossen. Diesbezüglich stimme ich Ralf voll und ganz zu. Wer so etwas benötigt sollte anstatt open Source eben doch zu einem kommerziellen Produkt greifen.

Die einleitende Aussagen von Steffen:

Fakturama ist hier in keiner Weise betroffen!

bzw.

Bei der EU-Datenschutzgrundverordnung ist Fakturama noch nicht einmal peripher betroffen.

kann ich hingegen nicht nachvollziehen. Damit werden die Nutzer m.E. allein im Regen stehen gelassen. Betroffen sind ja alle Programme in denen Personenbezogene Daten gespeichert werden und damit eben auch Fakturama. Dies trifft nicht nur auf Privatpersonen zu sondern auch auf evtl. erfasste Daten zu Ansprechpartnern von Firmenkunden oder Lieferanten.
Hier mal zwei Artikel dazu: DSGVO GoBD

Das es bez. DMS schon einen Lösungsansatz gibt finde ich schön. Hatte es aber bis dato nirgends entdeckt, würde mir daher eine entsprechende Dokumentation wünschen... oder hab ich die etwa auch übersehen?
Noch viel besser wäre es natürlich wenn dazu auch ein open Source DMS- Projekt nutzbar wäre und nicht nur ecoDMS als kommerzielle Lösung. Gibt es diesbezüglich etwas?

Bezüglich der ganzen Problematik stelle ich mir übrigens folgende Funktionen vor:

1. Möglichkeit zur entsprechenden Generierung eines diesbezüglichen Verfahrensverzeichnis. Dazu müssten mindestens folgende Felder in den Kontaktdaten vorhanden sein: Datum Erstspeicherung, Datum der letzten Änderung, Datenquelle (z.B. Kundenantrag oder Onlineshopregistrierung usw.).
2. Es soll ja auch weiterhin möglich sein, Dokumente zu ändern. Jedoch sollten bei deren Ausgabe nicht einfach bereits vorhandene überschrieben werden. Vielmehr sollte es dann einen entsprechenden Rückfragedialog geben, so das der Anwender auch selbst entscheiden kann:
   [ ] Vorhandenes Dokument überschreiben?
   [X] Neues Dokument mit angehängtem Zähler erstellen?
   Beispielsweise vorhandene Rechnung= RE02158 und statt diese zu überschreiben neues Dokument= RE02158-1 und bei der nächsten Änderung= RE02158-2 usw.

3. Es sollte eine Backupfunktion geben, mit welcher sich je nach Nutzerauswahl folgende Daten zusammen in eine ZIP sichern und bei Bedarf auch wieder Rücksichern lassen:
   [X] Datenbank
   [X] Dokumente
   [X] Vorlagen
   [X] Einstellungen
   Die Sichere Aufbewahrung der Backupdaten (z.B. Netzlaufwerk oder automatische Laufwerkduplizierung) ist dann natürlich Aufgabe der Anwender.

4. Die wohl ohnehin geplante Nutzerverwaltung mit Vergabe entsprechender Berechtigungsprofile (z.B. Nur Anzeigen, Erstellen, Ändern usw.)

Gruß
Matthew

Hallo Matthew,
die von Dir genannten Funktionen sind tatsächlich teilweise schon in Fakturama umgesetzt:

1. Datum der Erstanlage und Datum der Änderung habe ich in allen Objekten drin (Produkte, Kunden, Dokumente usw.). Man sieht das bloß nicht auf der Oberfläche. In der Datenbank heißen die Felder DATEADDED, MODIFIED und MODIFIEDBY. Auswerten kann man das aber noch nicht mit Fakturama-Mitteln. Geht aber bspw. mit OpenOffice Base.
2. darüber habe ich auch schon nachgedacht und das wird es auch in absehbarer Zeit geben
3. die Backupfunktion für die Datenbank wird in der Version 2.0.1 wieder drin sein (bitte nicht mit der aktuellen 2.0.0.1 verwechseln, das ist nur ein Hotfix)
4. das wird noch eine Weile dauern, weil es ziemlich viel Änderungen nach sich zieht

Bezüglich DMS: Da möchte ich wieder mal auf das hervorragende Handbuch verweisen, das offensichtlich nie genügend gewürdigt wird. Dort heißt es nämlich im Kapitel 9:
[quote="Handbuch Fakturama"]
Im Feld Zusätzlicher Pfad der .pdf-Dateien kann man einen weiteren Pfad angeben, in dem PDFDateien
abgelegt werden. Dies wird beispielsweise verwendet, wenn andere Programme (z. B. Archivsysteme)
Dateien aus diesem Pfad direkt lesen und verschieben.

Achso, nochwas: In agorum (Archivsystem) kann man ZUGFeRD-Rechnungen reinschieben, das wird dann gleich ausgewertet. Ist vielleicht auch eine Übelegung wert.

Hallo Matthew,
da Fakturama historisch gewachsen ist, sind die Infos noch etwas verstreut. Das versuchen wir nach und nach zu beheben. Hier mal etwas ausführlicher:

http://vorlagen.fakturama.info/dokumentenmanagementsystem-ecodms/

Der Beitrag bezieht sich noch auf die Version 1.x. Mittlerweile hat Ralf die oben beschriebene Schnittstelle nachgerüstet. Ich werde auch noch ein YouTube-Tutorial dazu machen und wahrscheinlich einen kurzen Podcast zu den GoBD. Mit dem ersten habe ich schon angefangen, bin aber z.Zt. auch anderweitig sehr eingespannt.

Danke für die beiden Artikel. Die DSGVO ist so neu nun auch nicht. Wir als Onlinehändler müssen viele Grundforderungen schon seit Juli 2014 durch die EU-Verbraucherschutzrichtlinie umsetzen. Ich habe eher das Gefühl, dass die DSGVO diese Regelungen lediglich auf alle anderen UN ausweiten soll. Legt allerdings noch eine Schippe obendrauf.

Bei der DSGVO habe ich nur ganz wenige Ideen, wie da Fakturama helfen könnte. In dem Artikel von Dir wird aber auch nicht konkretes genannt. Und dass Haufe und Co. da was machen, ist gewolltes Marketing. Viele andere Softwareanbieter lassen sich die GoBD-Konformität auch testieren. Aber: DAS GoBD-Zertifikat gibt es nicht und genau das ist auch gewollt. Es soll das Prinzip der Technikneutralität im Vordergrund stehen. Alles andere würde für alle Beteiligten ganz schnell zum Fallstrick, da die technische Entwicklung immer eine tolle Eigendynamik hat.

Kurz gesagt: Man will als Softwarehersteller verkaufen. Also nimmt man sich einen namhaften und teuren (je namhafter, umso besser) und beauftragt den mit Tests an der Software. Der stellt fest, was viele objektiv feststellen können und testiert die GoBD-Konformität. Das heißt aber gar nicht, dass die Finanzbehörden das auch so sehen müssen! Also: Die GoBD-Konformität ist wie bei der CE-Kennzeichnung eine Erklärung des Herstellers, sonst nichts. Und der kann, gerade wenn er Chinese ist, das ganz leicht erklären 😉

Zurück zu Fakturama.
Eine gute Voraussetzung haben wir schon, da wir im Normalfall lokal installiert sind. Das Programm könnte
- nach (ich glaube das war die Frist) 3 Jahren erinnern, wenn ein Datensatz nicht benutzt wurde
- beim Löschen nicht nur einen Löschvermerk setzen, sondern ausixxen
- Briefe auf Wunsch auch löschen (Vorsicht! Die könnten den Charakter eines Handelsbriefes tragen und werden damit aufbewahrungspflichtig)

Ansonsten: Du bist der Ansprechpartner für die DSGVO und nicht die Software. Und wenn wir ein gutes Backup haben, aber die Nutzer es auf einer verlierbaren externen Festplatten mit sich herumtragen, geht die Tendenz eher zum Layer-8-Problem.

Die Software denkt zur Zeit noch nicht mit und weiß nicht, was Du löschen musst und was nicht. An der künstlichen Intelligenz für Fakturama knobeln wir noch 😉

Mit dem Verfahrensverzeichnis ist analog der Verfahrensdoku bei den GoBD der spezielle innerbetriebliche Ablauf / Workaround gemeint. Das kann man nicht generieren. Allerdings gibt es sicher Vorlagen dafür. Ein Kapitel für die Verfahrensdoku bei den GoBD könnte zB der im Vorlagen-Portal beschriebene Ablauf sein. Im Grunde einfach kopieren und eingliedern. Aber abnehmen kann Dir das leider niemand.

Noch kurz zu ecoDMS-Alternativen. Das hatten wir hier schon diskutiert, aber im konkreten Fall stehen (meiner Meinung nach) Nutzen und Aufwand bei vielen Alternativen in keinem Verhältnis. Und letztlich ist eine OpenSource-Überzeugung natürlich prima, aber andererseits will man mit der Software ja auch einen gewissen Zweck erfüllen.

https://www.fakturama.info/community/hilfe-bei-installation-und-bedienung/jahrensanfang-rechnungen-bezahlt-bereinigen/#post-14764

So langsam bekommt man Licht ins dunkel...

@Miracolitag
Du hattest ja erwähnt, dass auch organisatorische Maßnahmen wie Beispielsweise Zugriffsberechtigungskonzepte genügen. Ist es daher zur Erfüllung der GoBD eigentlich zwingend erforderlich ein DMS einzusetzen? oder könnte hier auch eine andere Form der Archivierung, Beispielsweise in OwnCloud mit entsprechendem Schreib- und Zugriffsschutz, genügen?

Wir nutzen beispielsweise schon seit Jahren einen kleinen Microserver (HP ProLiant mit Windows Home Server) als zentralen Datenspeicher mit entsprechender Duplizierungs- und Backupfunktion. Auf diesem Server läuft u.a. übrigens auch MySQL mit der DB von Fakturama. Auch das Arbeitsverzeichnis haben wir dort Zentral abgelegt, so das von jedem Client darauf zugegriffen werden kann.

Bez. Löschfristen. Ist es tatsächlich erforderlich Kundendaten nach etwa 3 Jahren zu Löschen? Bis dato haben wir Kundendaten nie gelöscht, sondern Beispielsweise aufgelösten Firmenkunden nur einen entsprechenden Status verpasst.

Ansonsten: Du bist der Ansprechpartner für die DSGVO und nicht die Software.

Da hast Du natürlich vollkommen recht... Aber gerade die Software soll ja das Werkzeug sein, die Vorgaben zu erfüllen. Bürokraten haben evtl. Ihren Spass daran, aber ich möchte mich viel Lieber mit meiner originären Handwerklichen Tätigkeit beschäftigen. Momentan hat man aber eher das Gefühl Verwaltungsangestellter zu sein.

Die GoBD-Konformität ist wie bei der CE-Kennzeichnung eine Erklärung des Herstellers, sonst nichts. Und der kann, gerade wenn er Chinese ist, das ganz leicht erklären.

Hier im Holzhandwerk wurde ja Beispielsweise schon die CE- Kennzeichnungspflicht für Haustüren eingeführt. Unseren Endkunden bringt dies keinerlei Vorteil, schließlich fertigen wir unsere individuellen Haustüren nach wie vor auf dem gleichen hohen Qualitätsstandard. Nur eben mit dem Unterschied, dass nun noch eine Menge Bürokratie dazu gekommen ist. Vorteile bringt dies nur den Handelskonzernen die nun mit CE gekennzeichnete Billigstprodukte leichter auf den Markt bringen können. Das ist ja nicht die einzige Baustelle, da gilt es ja noch diverse Zertifizierungen und Präqualifizierung zu Meistern, dann aktuell das völlig neue Bauvertragsrecht für Privatpersonen (BGB anstatt VOB ) usw. Und nun muss man all diese Dokumente nicht nur erzeugen, sondern sich auch im deren revisionssicher Archivierung kümmern, was wiederum einen Rattenschwanz neuer zusätzlichen Aufgaben nach sich zieht. Bürokratievereinfachung hatte ich mir persönlich anders vorgestellt... einfacher scheint es m.E. jedoch nur für die Verwaltungen zu werden. Sorry, wenn ich hier etwas vom Thema abgeschweift bin... hoffe ich komme damit nicht als Wutbürger rüber, deren vermeintlicher "Alternative" ist nämlich so gar nicht mein Ding.

Zurück zum Thema: Hast du bez. Verfahrensdoku bei den GoBD mal ein Beispiel bzw. einen entsprechenden Link?

@rheydenr
Für den zusätzlichen PDF- Pfad würde ich mir (analog zu den übrigen Pfaden) die optionale Verwendung von Platzhalten ({yyyy},{doctype} usw.) wünschen, um so die unterschiedlichen Dokumentenarten alternativ auch strukturiert ablegen zu können.

Zu Punkt I. Hier wäre es mittelfristig schön, wenn man diese Daten mit einer Dokumentenvorlage in eine Tabelle überführen, oder als CSV Exportieren könnte. Beispielsweise: Kunden- oder Lieferantennummer; Name; Anlagedatum; Änderungsdatum; Datenquelle

Zu Punkt III. Hier sollte nicht nur die Datenbank gesichert und auch rückgesichert werden können. Sondern je nach Nutzerauswahl eben auch noch der Dokumentenordner, Vorlagenordner und die Einstellungen (.fakturama2) gemeinsam. Am besten zusammen in eine ZIP, welche man möglichst auch mit einem Passwort sichern kann. Dann noch in den Programmeinstellungen die Pfadangabe für das Backupverzeichnis und ein Optionsfeld: Backupnachfrage bei Programmende?

P.S. Zu guter Letzt erlaube ich mir noch einen kurzen Hinweis auf die Anregungen aus meinem ersten Beitrag vom Anfang vergangenen Jahres... auch wenn einiges bereits umgesetzt ist.

Gruß
Matthew

Hallo Matthew,
ich antworte später noch einmal ausführlicher. Ich habe das Tutorial zu Fakturama und dem DMS ecoDMS fast fertig. Damit entfallen vllt. schon mal paar Fragen und Antworten.

Hier nochmal kurz mein Senf dazu. Ich werde voraussichtlich Ende Februar eine solide Ganztagsbetankung in Sachen DSGVO erhalten. Dort werde ich die Leute so löchern, daß ich hinterher weiß, ob ich irgendwas an Fakturama ändern muß und wenn ja, was).

Ganztagsbetankung

:)o Hört sich trotz des trockenen Thema irgendwie nach ner ziemlich spaßigen Veranstaltung an :)-D
Ich empfehle Martinis - selbstverständlich geschüttelt, nicht gerührt! B)

So, das Tutorial ist auf YouTube:

FAKTURAMA und Dokumentenmanagement

Hallo Ralf,

hat die Verstaltung zu DSGVO stattgefunden? Wenn ja, bist du jetzt schlauer was in Fakturama vielleicht angepasst werden müsste? 😉

Wie löst Ihr die GoBD Geschichte für euch?