GoBD/GDPdU

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

xbaseklaus
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 246
Registriert: Mi, 04. Jun 2014 12:01
Wohnort: FRANKEN

GoBD/GDPdU

Beitrag von xbaseklaus »

Guten Morgen ,

ich hab da mal ne Frage zu folgendem Punkt: Neue Anforderungen ab dem 1.1.2017 !

"Es ist der Nachweis zu führen, dass die Daten manipulationssicher, unveränderbar und jederzeit lesbar gespeichert werden"

Die Daten des Kassensystem sind im FOXDBF Format gespeichert ... aber unverschlüsselt ! - in Bezug auf manipulationssicher, unveränderbar ???

Kann mich da jemand kurz aufklären - im Kassenprogramm selbst kann man natürlich nicht manipulieren !!!

Mfg Klaus
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: GoBD/GDPdU

Beitrag von Manfred »

geht es darum sie sicher zu machen, oder reicht es anzuzeigen, wenn sie manipuliert wurden? Im letztern Fall würde ich ein Zusatzfeld anlegen, über die entsprechenden Werte eine Prüfsumme legen und da speichern. (Vereinfacht gesagt)
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
xbaseklaus
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 246
Registriert: Mi, 04. Jun 2014 12:01
Wohnort: FRANKEN

Re: GoBD/GDPdU

Beitrag von xbaseklaus »

Hi Manfred,

mir geht es darum - was das Finanzamt unter:

"Es ist der Nachweis zu führen, dass die Daten manipulationssicher, unveränderbar ..."

versteht !

Die Daten sind im Kassenprogramm nicht manipulierbar ... da die FOXDBF natürlich über ein Externes Programm veränderbar ist ... löschen , editieren , neue Felder kann ich sie damit ja ändern was ja auch manchmal erforderlich ist ... natürlich nicht vom Kunden !

Muss die FOXDBF allgemein verschlüsselt sein ?

Mfg Klaus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Jan »

Hallo Klaus,

ich denke, mit einer einfachen Verschlüsselung kommst Du da nicht weiter. Denn Du verschlüsselst ja so, das man wieder entschlüsseln kann - muß so sein für Deine eigenen Kassenauswertungen (Tagesabschluß, etc.) und für das Finanzamt. Mit einer Verschlüsselung würdest Du nur Fremdprogramme aussperren. Aber wer sagt denn, das nicht Du selber eine Finanzamt-Bescheiß-Funktion gebaut hast, mit der Du das regeln kannst?

Ein guter Ansatz wäre sicherlich, fortlaufende Bonnummern zu haben. damit ist schon mal sicher gestellt, das Du nicht am Ende des Tages die Geheimtaste nutzen kannst: Bitte jeden 2. Bon löschen (sowas gibt es wirklich!). Aber einzelne Positionen und die Bonsumme kannst Du trotzdem noch manipulieren. Könntest Du jedenfalls in den Augen des Finanzamtes.

Ich habe für meinen Kunden auch eine Kasse geschrieben. Und mache mir da auch so meine Gedanken. Mein Kunde meint aber, das wir erstmal gut aufgestellt sind, Und das Finanzamt selber noch nicht so ganz genau weiß, wie das wirklich geregelt sein soll. Und so lange wartet der erstmal ab.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
xbaseklaus
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 246
Registriert: Mi, 04. Jun 2014 12:01
Wohnort: FRANKEN

Re: GoBD/GDPdU

Beitrag von xbaseklaus »

@ Jan

Mir geht es erstmal darum ... müssen die FOXDBF Daten verschlüsselt abgelegt werden ?

Mein Kunde kann mit DBF eh nichts anfangen - im Programm sind die Auswertungen über mehrere DBF verknüpft und verteilt , wenn man das nachträglich manipulieren will muss
man erstmal wissen welche Datenbanken, wie sie verknüpft sind usw ... Aufwand ohne Ende ...

Ich arbeite auch mit fortlaufenden Nummern ... Ich glaube das wäre unbezahlbar wenn da jemand anderes außer mir Manipuliert !!!

Ich mache mir aber auch Sorgen, weil jetzt Kunden kommen und Fragen ... kaufe ich dass von dir ... Gibt's da Probleme ... du verstehst mich .. und ich das ja dann das bestätigen müsste !
Im Programm selber habe ich kein Problem ... es wird alles in DBF abgespeichert ... Stornierung, Gutschrift etc, - Ist auch nachvollziehbar !

Aus dem Programm selber ist nichts manipulierbar ... das kann ich ja beeiden ... aber steht natürlich nur drin was er eingibt :-) REICHT DAS !?!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von brandelh »

Manipulationssicher wäre eigentlich nur eine WORM ... aber was nun vorgeschrieben wird weiß ich nicht.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Jan »

Die Österreicher machen das mit Zertifikat und Dongle.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
xbaseklaus
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 246
Registriert: Mi, 04. Jun 2014 12:01
Wohnort: FRANKEN

Re: GoBD/GDPdU

Beitrag von xbaseklaus »

Die allgemeine Vorgabe die ich beachtet habe ist folgende:

Jede Buchung ist detailliert und nachvollziehbar gespeichert
Jede Buchung ist fortlaufend nummeriert (Belegnummer)
Jeder Storno ist detailliert und nachvollziehbar gespeichert
Alle Stammdatenänderungen werden zeitlich und inhaltlich nachvollziehbar protokolliert
Alle Belegänderungen werden zeitlich und inhaltlich nachvollziehbar protokolliert
Jeder Bericht (Tagesabschluss / Z-Bon) ist fortlaufend nummeriert und nachvollziehbar gespeichert.
Alle Kassendaten sind exportierbar und vom Steuerprüfer digital einlesbar
Alle Kassendaten können über einen Zeitraum von 10 Jahren auf der Kasse gespeichert werden.
Der Speicherort/Datenbank und das Betriebssystem sind dem Steuerprüfer darlegbar.
Es liegt ein Programmierhandbuch / Bedienungsanleitung für das Kassensystem vor.

Das wird von dem Kassenprogramm auch alles abgedeckt !

Meine FOXDBF Dateien sind allerdings nicht verschlüsselt !!!
was meiner Ansicht ja folgender Vorraussetzung wiedersprechen würde :

Es ist der Nachweis zu führen, ... jederzeit lesbar gespeichert werden !!!!!!
Benutzeravatar
Rolf Ramacher
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1930
Registriert: Do, 09. Nov 2006 10:33
Wohnort: Bergheim
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Rolf Ramacher »

Hallo Klaus,

nein die Daten müssen nicht verschlüsselt abgelegt werden. haben wir auch nicht gemacht. Nur manipulationssicher - also bestehende Bons nicht veränderbar, laufende Bon nummer usw.

du kannst natürlich deine daten verschlüsselt ablegen., wenn du der meinung bist, dass deine Kunden die Datenbanken bearbeiten könnten.
Gruß Rolf

Mitglied der Gruppe XUG-Cologne
www.xug-cologne.de
xbaseklaus
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 246
Registriert: Mi, 04. Jun 2014 12:01
Wohnort: FRANKEN

Re: GoBD/GDPdU

Beitrag von xbaseklaus »

@ Rolf Ramacher

Wie hast du das mit der Schnittstelle fürs Finanzamt realisiert, wenn ich fragen darf ?

IDEA bzw GDPdU konforme Ausgabe ! bzw. Aufbereitung

Gibt es da "Links" wie das aussehen muss ?

Natürlich ist das bei mir auch über die DBF nachvollziehbar bzw über mein Auswertungs-Modul (mit Ausdruck / DBF Tabellenansicht) !

Mfg Klaus
flanelli
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 151
Registriert: Di, 11. Mai 2010 16:27
Hat sich bedankt: 3 Mal
Danksagung erhalten: 9 Mal

Re: GoBD/GDPdU

Beitrag von flanelli »

Jan hat geschrieben:Die Österreicher machen das mit Zertifikat und Dongle.
Jan
Einspruch :-)
Wenn es um die Sicherung der Daten einer Registrierkasse geht war das zwar einmal das Wunschdenken
des verzeifelt wiehernden Amtsschimmels im FInanzministerium aber es blieb eben beim Wunsch.
Wie schon Hubert erwähnt hat wäre eigentlich nur WORM manipulationssicher wobei sogar über diesen
Weg die Theorie über die Praxis siegt ...

im Alpenland sieht das im Prinzip so aus. ( DEP = Datenerfassungsprotokoll )
Das vollständige DEP ist zumindest vierteljährlich auf einem elektronischen, externen
Medium unveränderbar zu sichern. Als geeignete Medien gelten beispielsweise
schreibgeschützte (abgeschlossene) externe Festplatten, USB-Sticks und Speicher externer
Server, die vor unberechtigten Datenzugriffen geschützt sind.

Der tatsächlich relevante Faktor für eine Manipualtionssicherheit ist die Signierung aller Belege
über, vom Gesetzgeber exakt definierte Routinen und Zertifikate.
Die Unveränderbarkeit des Inhaltes der Daten ist durch die Signatur bzw. das Siegel und insbesondere durch die
signierten Monatsbelege gegeben. Jede Sicherung ist gemäß § 132 BAO aufzubewahren.
Sollten die Daten des DEP zur Sicherung verschlüsselt werden, müssen die Daten
inhaltsgetreu wiederhergestellt werden können.


@xbaseklaus
Falls es sich bei dem von Dir zitierten Text
"Es ist der Nachweis zu führen, dass die Daten manipulationssicher, unveränderbar und jederzeit lesbar gespeichert werden"
um einen Gesetzesauszug handelt und dieser Passus NICHT die manipulationsicher ERSTELLUNG der Daten
( durch die Erstellung sind diese ja zumindest auch gespeichert )
SONDERN deren EXTERNE SPEICHERUNG auf einem anderem Medium als dem ausführenden Rechner beschreibt
wäre es sehr ratsam eine absolut präzise, rechtsverbindliche Detailspezifikation vom Gesetzgeber zu erfahren.

Ich kenne die deutsche Judikatur nicht im Detail aber wenn es um die reine Datensicherung geht dann ist es nahezu
unvorstellbar dass eine absolut manipulationsichere Speicherung von Datenbeständen abverlangt werden kann denn
alleine den Kostenfaktor hierfür würde ein kleiner Handelsbetrieb niemals stemmen können.
Die oftmals angebotene billige Variante eines sogenannten "Datensafes" durch mehr windige als findige Unternehmen ist
genausoviel wert wie die Nachrichten von gestern in der Zeitung.

Es ist halt wohl auch bei Euch so Sitte dass der Gesetzgeber immer wieder mehr oder weniger nebulösen Schrott aus dem
Ärmelschoner beutelt und es dem Volk überläßt wie es zu interpretieren wäre. Tritt allerdings der Fall ein dass man dem
bösen, bösen Täter den Pelz abziehen möchte scheint alles glasklar zu sein und plötzlich wird aus einem fadenscheinigen
Geschwafel ein 100% in Stein gemeiselter eindeutiger Gesetzestext der nur eine Interpretation zuläßt: SCHULDIG :blob8:

Gruß aus den tief verschneiten Alpen, Marcel
Ahoile aus dem Süden
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

hi,

wenn eine Verordnung kommt hat das nichts mit deiner Datenbank*** zu tun. [-X
bei einer Betriebsprüfung interessieren die sich nicht für "deine" Daten, die holen sie sich eher vom Steuerberater (DATEV)

solange es keine genaue Angaben von Finanzamt gibt kocht jeder Programmierer sein eigenes Süppchen ...
das Problem liegt nun an den Beamten des Finanzamt ob die dein "Verfahren" akzeptieren.

---

der Papier Bon muss doch sowieso gedruckt werden
wenn das Programm die Bon-Nummer / Summe "SOFORT" auf einen 2nd Drucker in eine Liste geht wäre das bei einer Betriebsprüfung wohl standhalten ;-)

---

was ich mal überlegt habe ... man kann du eine CD / DVD im UDF Format beschreiben.
bei einem normalen, nicht löschbaren, Medium kann man dann eine Datei nicht mehr löschen/überschreiben, oder ?

---

***ein DBF hat keine "Sicherheitsmerkmale" welches "sicherstellen" das Manipulation nicht möglich sind.
BitCoin arbeitet ja mit "Block Chain" Verfahren das als sicher gilt aber ob es der Beamte akzeptieren würde ?
gruss by OHR
Jimmy
henxl
UDF-Programmierer
UDF-Programmierer
Beiträge: 91
Registriert: Fr, 10. Feb 2006 19:46
Wohnort: Mannheim

Re: GoBD/GDPdU

Beitrag von henxl »

Hallo,

als Steuerberater befasse ich mich seit einiger Zeit mit diesen gesetzlichen Neuerungen.

Als unveränderbar war bisher zu verstehen, dass ein einzelner Geschäftsvorfall nachträglich nicht verändert werden kann, also ein Buchungssatz nicht durch einen geänderten ersetzt werden kann. Vielmehr sind bei Änderungen die Stornierung des bisherigen und die Neuerfassung des neuen Buchungssatzes nachvollziehbar aufzuzeichnen. Das Verhindern der nachträglichen Manipulieren einer Datei war damit nicht gemeint. Ist auch mit den bisherigen Mitteln nicht möglich, wie bereits aufgezeigt wurde.
Deshalb wurde am 21.12.2016 das sog. Kassengesetz beschlossen. Siehe hiezu die Ausführungen von DATEV:
https://www.datev.de/web/de/aktuelles/n ... eberblick/
Bis spätestens 31.12.2019 wird es ein Sicherheitsmodul geben, im Einzeln § 146a der Abgabenordnung.

Viele Grüße
Heinz
Das einzige, was ich weiß ist, dass ich nichts weiß, Sokrates
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

henxl hat geschrieben:Deshalb wurde am 21.12.2016 das sog. Kassengesetz beschlossen. Siehe hiezu die Ausführungen von DATEV:
https://www.datev.de/web/de/aktuelles/n ... eberblick/
Bis spätestens 31.12.2019 wird es ein Sicherheitsmodul geben, im Einzeln § 146a der Abgabenordnung.
der Satz
Es wird angenommen, dass der Preis einer zertifizierten technischen Sicherheitseinrichtung etwa 10 Euro pro Einheit betragen wird (vgl. BT-Drs. 18/9535, S. 16).
der Preis ist IMHO ein Wunschdenken ...

im Grunde ist es ein Dongle ...
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

Hallo Klaus,
wir nutzen unsere FileMonitor-Klasse, um Dbfs und Ntxs transparent zu verschlüsseln. Der hängt sich zwischen die Xbase-Runtime und das Betriebsystem und man kann bei jedem File-Zugriff eingreifen. Dies kann man nutzen, um beim Schreibvorgang zu verschlüsseln und beim Lesevorgang zu entschlüsseln. Mit ganz wenig Aufwand und fast ohne Performanceverluste kriegt man es damit hin, dbfs "usersicher" zu machen. Will man wirklich verschlüsseln, so geht das natürlich auch, indem man sich einen berechenbaren Schlüssel fast unendlicher Länge bastelt, der durchaus von Datei zu Datei anders sein kann, und diesen auf die gelesenen und geschriebenen Daten per Byte-Xor anwendet. Wir nutzen die FileMonitor-Technik auch, um die durch Virenschutzprogramme verursachten Schreib- und Leseprobleme zu umschiffen. Alle ominösen Xbase-Abstürzer beim Dateizugriff mit Zerstörung von Indizes gehören seitdem der Vergangenheit an.
Mehr Details auf Wunsch.
Viele Grüße
Michael
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

hi,

wie schon bemerkt wurde geht es nicht um irgendwelche Datenbanken sondern um ein transparentes Verfahren des Nachweises.

der von der DATEV angedachte "Dongle" könnte folgendes machen :

1.) vergibt ein laufende Nummer
2.) nimmt einige "muss" Felder als Parameter und gibt einen HASH zurück welchen man in den Record eintragen muss.

zu 1.) es darf kein Datensatz gelöscht werden. vielmehr ist eine Storno Buchung mit laufender Nummer notwendig.
zu 2.) der eingetragene HASH Code stellt sicher das die Informationen der "muss" Felder sich nicht ändert.

---

die DATEV ist im Grund ja ein Rechenzentrum und arbeitet schon immer mit "Datenübertragung"
es wäre technisch kaum ein Aufwand eine "Kasse" auf Online Betrieb aufzurüsten.

die Daten werden bei 2.) an die DATEV übertragen und die lokale DBF wäre nur für eigene Zwecke
klar muss die "Kasse" auch einen geschützten "Not-Speicher" haben wenn das Internet nicht funktioniert ...
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

.. weil ich eine konkrete Anfrage für die einfache Verschlüsselung mittels FileMonitor bekommen habe, habe ich ein Beispiel auf der XCockpit-Website hierfür verfügbar gemacht. Vielleicht gibt es ja noch andere Interessenten.

Hier der Link:

http://www.xcockpit.com/download.html

Da geht man auf Temporary Downloads (Doppelklick für Öffnen) und wählt das File Encryption Sample aus. Download Button drücken, fertig.

Das gute Stück kommt mit allem, dass man selber experimentieren kann. Die erforderliche cpxfimon.lib für’s Linken ist dabei. Alle Files, die die Extension „.enc“ haben, werden vom Programm verschlüsselt geschrieben und beim Lesen entschlüsselt. Bitte nicht produktiv verwenden.

Viele Grüße
Michael
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Rudolf »

Hallo Michael,
ich denke das Tool wäre für viele interessant, wird es auch mal produktiv einsetzbar sein ? Habe mal mit der Xbase++ eigenen Verschlüsselungs DBE getestet, hat ganz gut funktioniert. Aber keine Ahnung ob die weiterentwickelt wird. Bei Alaska weiß man ja nie.
Grüße
Rudolf
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

die Verschlüsselung, ob überhaupt vorgeschrieben, ist NICHT das Problem [-X
es geht um den "lückenlosen" Nachweis das wirklich alles gebucht wurde.

das was das Finanzamt im Prinzip will ist das "Blockchain" Verfahren wie beim BitCoin.
wie bekannt ist der "Blockchain" selbst nicht verschlüsselt
man kann jede Transaktion "sehen" und nicht nachträglich manipulieren.

---

ich vergleiche den "Blockchain" gerne mit der Fibonacci Reihenfolge :
die vorherigen Zahlen bilden die neue Zahl ( 1+2=3, 2+3=5, 3+5=8 ... )
bei so eine Reihenfolge würde es sofort auffallen wenn eine Zahl manipuliert wird.

leider hat auch diese Methode ein Harken : die Zahlen werden immer grösser -> mehr Rechenaufwand
deshalb wird IMHO nie die Grenze der möglichen BitCoins erreicht ... es würde sich nicht lohnen.

da die Reihenfolge exponentiell ansteigt ist der Aufwand am Anfang noch locker mit einem Laptop möglich.
bei mehr als 1.000.000 Buchungen pro Jahr könnte das langsam kritisch werden ... aber solche Kunden habe ich nicht.
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

Hallo Rudolf,

diesen FileMonitor kann man bedenkenlos einsetzen. Wir machen das, ohne je ein Problem gehabt zu haben. Wir nutzen es z.B. um Außendienstmitarbeitern eine Portion DBFs mit Kundenkonditionen zu schicken, die dann aus Excel abgerufen werden. Da geht es z.B. um Deckensysteme, für die die nötigen Mengen im Excel berechnet werden und die Preise kommen dann aus unseren Daten. Dazu haben wir auch ein Tool, mit dem wir direkt Daten aus den Dbf-Tabellen über Index in die Excel-Tabellen holen können, nennt sich AServer. Dieses Tool hat diese Verschlüsselung optional eingebaut (über ein ladbares Modul). Über die selbe Technik (FileMonitor) bremsen wir auch die Zugriffsfehler aus, die von Zeit zu Zeit durch Virenschutzprogramme auftreten. Und da kann man noch ein paar andere nette Sachen mit machen, z.B. Dateizugriffsprotokolle schreiben.

Ich schreibe die Warnung hin, damit die Leute nicht auf die Idee kommen, die Demo produktiv zu verwenden. Der letzte Segen für 2.0 fehlt von mir allerdings auch noch.

Hast Du die Demo schon ausprobiert?

Viele Grüße
Michael
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Rudolf »

Hallo Michael,
danke für die Info, muss die Demo erst mal anschauen. Deine Lösung hört sich sehr professionell und vielseitig an. Ich mache auch Krankenpflege Aberchnungssysteme, da kann man immer punkten wenn man was mit Verschlüsselung anbieten kann Auch für meine DMS Systeme ist es wichtig wenn ich alle Dokumente verschlüsselt verwalten kann.
Grrüße
Rudolf
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

Rudolf hat geschrieben: Di, 16. Jan 2018 10:36 Ich mache auch Krankenpflege Aberchnungssysteme, da kann man immer punkten wenn man was mit Verschlüsselung anbieten kann
was nützt dir eine Verschlüsselung wenn der Abrechnungssystem nicht mehr abgenommen wird weil der Nachweis (Zertifikat) fehlt :?:
Ihr redet doch wieder am Thema vorbei ...
gruss by OHR
Jimmy
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Rudolf »

Hallo Jimmy,
woher nimmst Du die Info dass meine Kunden ein Zertifikat verlangen ?
Grüße
Rudolf
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

Rudolf hat geschrieben: Di, 16. Jan 2018 20:21 woher nimmst Du die Info dass meine Kunden ein Zertifikat verlangen ?
vom Buch Prüfer der letztens im Hause war.
Er meint das es "das einfachste" wäre wenn man den zuständigen Code "Zertifizieren" lassen würde.

Das Problem wäre nur jemanden zu finden der dies mit Xbase++ Code machen dürfte ;-)
gruss by OHR
Jimmy
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: GoBD/GDPdU

Beitrag von Rudolf »

Hallo Jimmy,
ok, verstehe. Aber meinen Kunden genügt momentan dass "erhebliche kriminelle Energie" notwendig ist um sich die Daten anzueignen. Mein Programm läuft nur in einer bestimmten Umgebung, man kann sich also das System mit Daten nicht einfach kopieren um damit die Daten zu entschlüsseln. Sollte dann also ausreichend sicher sein.
Grüße
Rudolf
Antworten