Neu Speicherung in SQL DB?

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
790
83
Der Prüfer, und das schreibst du richtig, will wissen, wie die Rechnungen entstehen. Da ich Rechnungen auch in Word schreiben kann und darf, teilte ich ihm dies mit und zeigte ihn den Ablauf in JTL. Fertig! Wichtig ist doch nur die Festschreibung in der Buchhaltung, d.h. die Buchung in Datev, bzw. bei uns Lexware und die Überführung der Belege ausgedruckt in den Ordner, bzw. wie bei uns ein DMS.

Wenn sich die Vorlage ändert? Na und, wo ist das Problem? Der Kunde merkt es doch nicht, wenn er seine Rechnung nachfordert und diese sieht anders aus.

Die letzte Prüfung war eine Querprüfung, d.h. tatsächlich kam der Prüfer mit einer von uns ausgestellten Rechnung an und sollte prüfen, ob ich tatsächlich die Ust. abgeführt haben. Er fragte mich nach der Rechnungsnummer, wärend er sich den Ablauf in JTL erklären lies und ich generierte mit einer anderen Vorlage die Rechnung als die er da hatte. Ja, stimmt, sah blöd aus. Aber es war doch nur das Layout. Kein Problem im DMS war die Rechnung im Layout des Kunden.

Es gibt keine unterschiedliche Rechnungen! Es gibt nur andere Layouts! Das ist kein Problem, sondern Luxus! Auch in anderen Anwendungen wie z.B. Lexware faktura kann ich das Layout ändern und alte Rechnungen werden mit den Befehl drucken in dem neuen Layout ausgegeben.
Das kommt im Zweifelsfall aber sehr auf den Prüfer, sein technisches Know-How und seine Laune an. Grundsätzlich gebe ich Dir Recht, nur wenn man's richtig macht, dann gibt es nur ein "Rechnungs-Original", oder hättest Du dem Prüfer notfalls die gleiche Rechnung (inkl. identischer Rechnungsnummer) auch noch einmal in Word geschrieben?
Der Prüfer wird sehr genau hingeschaut haben, nachdem Dein Ausdruck anders aussah, sich dann aber durch die identische Speicherung im DMS überzeugen lassen, dem nicht weiter nachzugehen.

Wie Du schon sagst, sind die Daten in der DB nicht festgeschrieben und die Vorlagen variabel. Es besteht also z.B. auch die Möglichkeit, dass Du ein und dieselbe Rechnung mit unterschiedlichen USt.-IDs, Steuernummern, etc. druckst oder eben mit anderen Rechnungsinhalten, als das Original. Im Zweifelsfall kann das zu einem ziemlichen Problem werden, insbesondere wenn dann die Rechnung aus der Buchhaltung der Querprüfung nicht (inhaltlich) identisch ist mit der im DMS, weil sie z.B. später noch einmal aus der Wawi an den Kunden gemailt wurde. Und da wird der vermeintliche Luxus dann möglicherweise doch wieder zum Problem.

Und eben das ist auch ein Thema, welches im Service-Desk sicherlich des Öfteren vorkommt, also die Frage nach der erneuten Zusendung der Rechnung, sauber gelöst kommt die dann aus dem DMS (egal wie es heißt) und ist dort sicher aufbewahrt und wird durch regelmäßige Backups gesichert, welche aber eben nicht zwangsläufig mit der Wawi-DB gemeinsam erfolgen.

Ehrlich gesagt weiß ich nicht, was JTL genau für eine Nutzerstruktur hat, aber aus meiner Sicht macht es wenig Sinn, sich nur auf E-Commerce-Einsteiger auszurichten. Perspektivisch (und insbesondere wenn er kostenpflichtig sein soll) muss ein Service-Desk und ein ERP-System einfach mehr bieten, als nur die Basis-Funktionen, um die man ganz viel andere Insellösungen drumherum bauen muss.

Grundsätzlich und der ursprünglichen Vorstellung nach sind e-Mails zwar einfach nur "Textnachrichten", die Nutzungs-Realität sieht heutzutage aber definitiv anders aus.
 

jensfalk

Aktives Mitglied
8. Januar 2013
73
10
Es besteht also z.B. auch die Möglichkeit, dass Du ein und dieselbe Rechnung mit unterschiedlichen USt.-IDs, Steuernummern, etc. druckst oder eben mit anderen Rechnungsinhalten, als das Original. Im Zweifelsfall kann das zu einem ziemlichen Problem werden, insbesondere wenn dann die Rechnung aus der Buchhaltung der Querprüfung nicht (inhaltlich) identisch ist mit der im DMS, weil sie z.B. später noch einmal aus der Wawi an den Kunden gemailt wurde. Und da wird der vermeintliche Luxus dann möglicherweise doch wieder zum Problem.
- Unterschiedliche Ust.-ID, Stuernummern eher nicht, außer bei Umwandlung des Unternehmens, bzw. Umzug zu einen anderm FA. / Aber da muß dann sowieso eine ToDoliste usw. erstellt werden.
- Das Problem ist eher die Ust., wenn diese sich ändert. Hier müßte JTL etwas bei den Steuersätzen umbauen. Nämlich (Beispiel) normaler Steuersatz 16% 01.04.1998, normaler Steuersatz 19% 01.01.2007, so daß wenn am 01.01.2021 der Satz steigt bei der Variabale beim Ausdruck ab 01.01.2021 der Satz 25 erscheint und bei den Dokumenten davor 19 %.
- Tatsächlich sollte bei einer Prüfung die Rechnung in der Wawi eher nicht generiert werden, sondern man holt jene aus dem DMS. In der Regel bekommt der Prüfer die Dokumente für die zu prüfenden Jahre per DMS-Export auf einen Datenträger, da sucht er sie sich, wenn er/sie mag selbst. Bei den Ausgangrechnungen wird er/sie aber auch eher sich das Steuerkonto ansehen und dort nach der Rechnung suchen. Das geht mit der verwendeten Prüfsoftware IDEA wesentlich schneller.

Ehrlich gesagt weiß ich nicht, was JTL genau für eine Nutzerstruktur hat, aber aus meiner Sicht macht es wenig Sinn, sich nur auf E-Commerce-Einsteiger auszurichten. Perspektivisch (und insbesondere wenn er kostenpflichtig sein soll) muss ein Service-Desk und ein ERP-System einfach mehr bieten, als nur die Basis-Funktionen, um die man ganz viel andere Insellösungen drumherum bauen muss.
Ich würde, wenn ich die Referenzen auf der JTL-Seite sehe nicht davon sprechen, daß es eine Lösung ist, die nur den Einstieg in den E-Commerce abdeckt.

Grundsätzlich und der ursprünglichen Vorstellung nach sind e-Mails zwar einfach nur "Textnachrichten", die Nutzungs-Realität sieht heutzutage aber definitiv anders aus.
Ja, und deshalb geht der Weg bei vielen dahin, die Mailserver arbeiten zu lassen und keine Insellösung in Anwendungen zu basteln. Das Problem der Nutzerrealität betrifft doch nicht nur JTL.

Will/ muß man., weil JTL kein Spaß mehr macht, weil man zu groß ist, usw. sich von JTLtrennen, dann habe ich wenigere Migrationsprobleme nehme ich nur eine Datenbank.

Nochmals! alles in eine Datenbank. So macht es auch SAP, mit allen Modulen und Lösungen. Auch in eine Oracel-DB würde ich eher nicht Mails mit riesigen anhängen lassen. Ein guter Freund SAP-Admin bei einer großen Versicherung bestätigt mir, daß auch beie Ihnen der Mailserver die Anhänge abtrennt.

Schöne WE und bleibt gesund.
 

forumjtlolshopag

Gut bekanntes Mitglied
6. Juni 2018
272
49
@Michael Spaltmann
Wäre es nicht ggf. möglich aus technischer Sicht das Servicedesk an einem IMAP Konto zu binden? Die ganzen Funktionen mit Ordnern und Zugriffen für interne Nutzer wäre über JTL Wawi weiterhin möglich, aber das reine ablegen etc. kann doch auf dem IMAP Konto verbleiben. So könnte man das Servicedesk mit einem Exchange Server verbinden.
 

Michael Spaltmann

Moderator
Mitarbeiter
2. November 2010
395
44
Hi,

man kann aktuell zwar den SD via IMAP einbinden, aber wir schauen aktuell nicht auf die einzelnen Ordner. Wir werden uns zu dem ganzen Thema was wir wo mit der Wawi wie speichern wollen nochmal intern zusammensetzen und Euer Feedback aus diesem Thread werden wir dort berücksichtigen.

Viele Grüße Michael
 

t.oster

Gut bekanntes Mitglied
4. Dezember 2013
159
8
Meiner Meinung nach müsste für Binärdaten (Mailanhänge, Artikel/Kategoriebilder und PDFs) eine allgemeine Speicherlösung neben der Datenbank her. Am besten so ähnlich wie das bei OsTicket gelöst ist. Es gibt also gegebenenfalls verschiedene Backends/Plugins zB D=Sicherung in der DB (Standard), F=Sicherung in einem Dateipfad, A= Amazon S3 oder was einem sonst noch so einfällt.
Dann wird in einer Tabelle halt Gepeichert Datei mit der ID x liegt auf Backend Y. Dazu kann man dann beliebig die Daten migrieren zwischen den Backends. Somit kann die Wawi mit einer reinen DB starten wie es jetzt ist, aber sobald es zu viel wird, kann man zB per Plugin alle Mailanhänge in einen Order auslagern.

Damit das Netzwerkfähig funktioniert müsste natürlich die Datei noch irgendwie verteilt werden, aber da gäbe es ja Möglichkeiten (HTTP-Server, Netzlaufwerk), was dann ebenfalls in die Verantwortung des "Speicherplugins" fallen würde.
 
  • Gefällt mir
Reaktionen: Shopworker.de

ruth

Gut bekanntes Mitglied
10. März 2007
224
5
Meiner Meinung nach alles in die Datenbank, oder per Filelink für jene die 10 GB nur haben.
Man will nicht wirklich aus x-Quellen wiederherstellen, bzw. sichern. Die Datenmenge die zu sichern ist, ändert sich doch nicht.

Wer Probleme hat mit der Backup-Größe, bzw. der zu sicherten Menge muß sich mit entsprechenden Backuplösungen beschäftigen. Klar ist doch, daß man ab einer bestimmtem größe, Backups mit Tape-Storage fahren miuß. Entsprechende Artikels gabs jüngst in ct und ix.

Sorry, aber was t.oster heute um 12:33 schrieb ist eher gefrickel. Nennt mir doch mal ein seriösen Anbieter der sowas macht. Außerdem wie will da die JTL-Wawi GoBD-konform sein? Viel Spaß beim schreiben und anpassen der Verfahrsdokumentation.

Ganz ehrlich, die Diskussion verstehe ich nicht. Ich dachte die Jahrtausendwende ist rum und BigData Realität. Oder wollt Ihr die Jahreszahl nun zweistellig programmieren, Millennium-Bug?

In Datev und Lexware, das sind beliebte und profesionelle Buchhaltungs-Anwendungen, hängen die Buchungskräfte das PDF an den Buchungsatz an. Der Vorteil, klick auf Beleg, ist so enorm, daß keiner auf die Idee käme das wegen "Backupprobleme" zu hinterfragen. Der ITler der damit ankäme, wird zu recht vom Hof gejagt werden.

SAP und Co. mache das seit 15 Jahren. Und wo sind die PDFs und Tiffs, richtig! in der Datenbank.

Bitte veröffentlicht die 1.6 und beschäftigt Euch nicht mit Problemen, die eigentlich keine sind. Danke
 
  • Gefällt mir
Reaktionen: jensfalk