Neu Speicherung in SQL DB?

[hula1499]

Aso...das JTL Ticketsystem verwenden bis 10kb Mails, damit man Platz spart.
Alles was darüber geht auf ein anderes Ticketsystem weiterleiten und dort dann bearbeiten.
Sicherheitshalber dann noch ein Post-IT auf die Wand kleben, wo denn jetzt das Ticket beantwortet wurde, oder?

 

[Jens Falk]

Aso...das JTL Ticketsystem verwenden bis 10kb Mails, damit man Platz spart.
Alles was darüber geht auf ein anderes Ticketsystem weiterleiten und dort dann bearbeiten.
Sicherheitshalber dann noch ein Post-IT auf die Wand kleben, wo denn jetzt das Ticket beantwortet wurde, oder?

Wieviele Mails bekommen Sie nochmal von Kunden, die größer sind als 10KB?

 

[hula1499]

Die ehrlichen letzten, genauso reingekommen Mails -> ohne irgendeine Manipulation.

Meine Frage/Nachfrage war auch eigentlich ironisch gemeint. Der Vorschlag ist vollkommen realitätsfremd >10kb Mails weiterzuleiten um ein anderes Ticketsystem zu verwenden und dann in 2 Ticketsystemen nachsehen zu müssen wo denn jetzt der Kunde ist, keine Ahnung wie man auf so eine Idee kommt.

 

[Jens Falk]

Meine 10 Kb waren auch eher ironsich gemeint. Keine Ahnung wie man auf die Idee kommt, Mails größer als 1 MB in einem Servicedesk empfangen zu wollen, indem es um Serviceanfragen geht, die sich auf Vorgänge in der Wawi beziehen.

 

[_simone_]

Meine 10 Kb waren auch eher ironsich gemeint. Keine Ahnung wie man auf die Idee kommt, Mails größer als 1 MB in einem Servicedesk empfangen zu wollen, indem es um Serviceanfragen geht, die sich auf Vorgänge in der Wawi beziehen.

Öhm, wir bekommen PDF und JPG von Lieferanten teils mit 5MB und größer, Kunden schicken uns Bilder mit Auflösungen für ne Fototapete, bei längeren Kontakten ist der Quote auch schon mal etwas länger, und und und...
...und das regelmäßig

 

[ruth]

Hallo zusammen,
wir schauen uns das Servicedesk gerade für ein kleineres Projekt an um zu sehen ob wir damit unsere bisherige Software ablösen könnten.
Allerdings stellt sich mir schon zu Anfang eine Frage. Wird die Mailkommunikation in der normalen SQL DB gesichert oder landet die in einer eigenen Datenbank?
Einerseits gehts mir um gesetzeskonforme Sicherung der Kundenkommunikation, andererseits laufen hier aber auch täglich 100e Mails ein, gerne mit großen Bildern, Anhängen etc.
Wenn das alles in der normalen SQL DB landet wird die schnell verdammt dick. Schaue ich auf unsere Mailsicherungen der letzten Jahre will ich das so eher nicht in einer DB haben die ich (zugegeben ein wenig hyperaktiv) backupe.
Danke für die Info,
SebiW

Das mit den Backup verstehe ich nicht! Ob nun eine DB mit 120 GB gesichert wird oder eine mit 10 GB und die andere mit 110 GB ist doch egal. Die Datenmenge ist gleich. Und gesetzeskonform, also revisionsicher ist nur ein Mailarchiv. JTL hat da ein Webinar u.a. mit dem Händlerbund im Angebot.

 

[Verkäuferlein]

Man darf hier die unterschiedlichen Sachen nicht vermischen.

Grundsätzlich sollte es Zielsetzung eines ERP-Systems sein, möglichst alle Geschäftsprozesse abzubilden oder zumindest Schnittstellen zu bieten.

Das heißt, speichert die Wawi die Rechnungen aufgrund von GoBD-Konformität auch als PDF-Datei, sollte dies revisionssicher erfolgen. Sammle ich meine (e-Mail-)Nachrichten in der Wawi, um eine "Kundenakte" zu erhalten, muss ich mir ebenfalls Gedanken darüber machen, ob es nicht Sinn macht, dies gleich "revisionsicher" zu tun.

Es ist doch vollkommen absurd, die Wawi-DB mit PDF-Rechnungen und Mails aufzublähen, um diese parallel noch einmal in einem revisionsicheren Mail-Archiv und/oder DMS zu speichern. In diesem Fall würde es Sinn machen, eine Schnittstelle zu einem DMS bzw. Mail-Archiv zu bauen und sich gleich der Technik der externen Systeme zu bedienen und damit auch die Problematik des Wawi-Backups zu erschlagen.

Unabhängig davon war ja bisher gar nicht die Revisionssicherheit als Problem angesprochen, sondern nur das Backup. Wenn man jetzt alle 1,2,3,4 Stunden eine Datensicherung der Wawi-Daten vornimmt, weil dies einfach die wichtigsten und kostbarsten Daten sind, die am schnellsten wieder herstellbar und vor allem auch rekonstruierbar sein müssen, wird es zum Problem, wenn man jedes Mal den ganzen Ballast mitsichern muss. Darüber hinaus ist natürlich auch die Frage nach Speicherkapazität und Anzahl gespeicherter Backups relevant.

Speichere ich meine Wawi-DB alle 4 Stunden und halte alle Backups der letzten 7 Tage vor, ist das momentan eine relativ kleine Datenmenge. Mache ich das gleiche mit meinen Mails und Rechnungen, ergibt das erstens keinen Sinn und führt zweitens zu einem massiven Anwachsen der Datenmengen (Backup-Dauer und Speicherplatzbedarf).

Momentan arbeiten wir mit DMS und Mail-Archiv und sichern beide 1x am Tag (Rechnungen werden bei uns auch nur 1x am Tag erzeugt und Mails 7 Tage auf dem Mailserver nach Abruf gespeichert), die Wawi-Daten werden in kürzeren Intervallen gesichert.

@Jens Falk
Und die Aussagen, die hier von einem JTL- Servicepartner getroffen werden, lassen mich die Haare raufen... Ich hoffe, dass JTL selber nicht so denkt. Sorry, ich will niemanden in seiner Arbeitsweise angreifen, aber mit Realität und schlanken Prozessabläufen hat das nichts zu tun. In der Regel sucht man sich nicht aus, von wem man wann welche Mails erhält, es gibt aber genug Gründe, in einem Servicedesk auch Fotos, PDF-Anleitungen, etc. zu erhalten und zu versenden. (Und noch ein kleiner Hinweis: In Deiner Sigantur steht "Lexwareware Silber Partner").

 

[Jens Falk]

@ Verkäuferlin Vielen Dank für den Hinweis mit der Signatur.

 

[SebiW]

Das mit den Backup verstehe ich nicht! Ob nun eine DB mit 120 GB gesichert wird oder eine mit 10 GB und die andere mit 110 GB ist doch egal. Die Datenmenge ist gleich. Und gesetzeskonform, also revisionsicher ist nur ein Mailarchiv. JTL hat da ein Webinar u.a. mit dem Händlerbund im Angebot.

Das ist ganz einfach, Eisenhower Matrix: Die 10 GB der Wawi brauche ich tagesaktuell gesichert weil sie die Grundlage aller meiner Geschäftsprozesse sind. Diese Daten sind wichtig und dringend. Tägliche Sicherung, 7x 10GB.
Die 110 GB reichen mir einmal die Woche in der Offzeit gesichert. Da hab ich im Zweifel auch noch Backups auf dem Mailserver. Diese Daten sind wichtig, aber nicht dringend. Wöchentliche Sicherung, 1x 110 GB.
Natürlich will, werde und muss ich beide unterschiedlich behandeln. Wir sprechen hier über Backups von 180GB vs 840 GB wöchentlich.

Zu der Idee mit zwei Mailumgebungen ... enthalte ich mich. Das ist sowas von weit weg von jeder sinnvollen Business Umsetzung, mir ist echt die Kinnlade runtergeklappt.
Mail 1 Kunde sagt Problem, Mail 2 schickt er Bilder vom Problem, Mail 3 beschreibt er näher, Mail 4 schickt er noch ein Foto der Verpackung. Dann schön abwechselnd in zwei Umgebungen die Mails. Ja, klar. Alle diese Mails beziehen sich auf einen Prozess in der Wawi und gehören auch dort hinein ... oder eben in ein anderes CRM. Deshalb liegen die bei jedem anderen CRM auch in ner eigenen DB.

Edith sagt: Und nur als Anmerkung: bei Greyhound kommen DMS und CRM auch gleich in einem Aufwasch. Weil es naheliegend und sinnvoll ist das so zu machen. Für jeden Scheiss noch immer ein Extratool anzuflanschen erhöht nur die Fehlerwahrscheinlichkeit.

 

[hula1499]

Zu der Idee mit zwei Mailumgebungen ... enthalte ich mich. Das ist sowas von weit weg von jeder sinnvollen Business Umsetzung, mir ist echt die Kinnlade runtergeklappt.

Vollkommen wertlos auch nur ein Wort darüber zu verlieren.
Hoffentlich lasst sich so ein Schwachsinn kein Kunde einreden...

 

[ruth]

Das ist ganz einfach, Eisenhower Matrix: Die 10 GB der Wawi brauche ich tagesaktuell gesichert weil sie die Grundlage aller meiner Geschäftsprozesse sind. Diese Daten sind wichtig und dringend. Tägliche Sicherung, 7x 10GB.
Die 110 GB reichen mir einmal die Woche in der Offzeit gesichert. Da hab ich im Zweifel auch noch Backups auf dem Mailserver. Diese Daten sind wichtig, aber nicht dringend. Wöchentliche Sicherung, 1x 110 GB.
Natürlich will, werde und muss ich beide unterschiedlich behandeln. Wir sprechen hier über Backups von 180GB vs 840 GB wöchentlich.

Den Ansatz finde ich völlig falsch.

Schnelles effektives Backup, schnelle Wiederherstellung, zügige Wiederaufnahme des Geschäftsbetriebes. Große Datenmenge? Dann halt gute Hardware und Medien.

Wenn ich keine Massen an große Mails in der Datenbank haben will, also wirklich massenhaft Mails mit riesigen Anhängen, dann gibt es drei Ansätze:

1. Wie Jens Falk schrieb Weiterleitungen großer Mails / Wieviele wäres es tatsächlich?
2. Anhänge vom Mailserver abtrennen und ins Dateisystem legen lassen, dabei bekommt die Mail einen Link zur Datei.
3. Etwas anderes nehmen als Service-Desk

In unserer Branche ist es üblich, dass Mails mit riesigen Anhängen (+ 1MB) kommen. Die kommen aber nur von Lieferanten. Hier setzen wir tatsächlich noch ein anderes System ein.
Wir werden aber mit hoher Wahrscheinlichkeit auch diese in den SD holen. Dann werden die Anhänge abgetrennt und die Mail bekommt einen Anhang mit Link zum Anhang. Erste Test laufen sehr gut.

Die Rechnungen sind auch bei uns zweimal da. Einmal in der Wawi für den täglichen Betrieb (Kunde will nochmal die Rechnung) und einmal im DMS für Buchhaltung und Aufbewahrungspflicht. Hat auch den Vorteil, dass nicht lang überlegt werden muss wenn der Kunde eine Löschung verlangt. Wird der Wunsch geäußert, wird halt gelöscht in der Wawi. Kein Mitarbeiter hat mehr Zugriff (weil nicht vorhanden), fertig. Es sind nur noch seine Rechnungen im DMS, wo sie nach der Aufbewahrungspflichtzeit automatisch gelöscht werden.

Das ist effektives Arbeiten mit schlanken Prozessen! Was kostet den Speicherplatz?

Wir wollen, dass JTL weiterhin JTL-WAWI als ERP-System mit allen wichtigen Prozeßen des Einkaufs, Verkaufs und Versandes bestmöglich abbildet. Wir wollen weder JTL-WAWI als DMS, noch als CRM, noch als Buchhaltung sehen. Das machen andere besser.

 

[SebiW]

Schnelles effektives Backup, schnelle Wiederherstellung, zügige Wiederaufnahme des Geschäftsbetriebes. Große Datenmenge? Dann halt gute Hardware und Medien.

Intern wie extern, wir Backupen täglich auf einen zweiten physischen Standort. Und jetzt erzähl mir mal wie Du das mit Datenmengen von 150 Gig bei einem lokalen Totalschaden wie Brand oder Wasser mit guter Hardware und guten Medien erschlägst. Und nein "ich zieh mir die Daten abends auf eine Festplatte und wander damit durch die Gegend" ist kein guter Backup Plan.

Wenn ich keine Massen an große Mails in der Datenbank haben will, also wirklich massenhaft Mails mit riesigen Anhängen, dann gibt es drei Ansätze:

1. Wie Jens Falk schrieb Weiterleitungen großer Mails / Wieviele wäres es tatsächlich?
2. Anhänge vom Mailserver abtrennen und ins Dateisystem legen lassen, dabei bekommt die Mail einen Link zur Datei.
3. Etwas anderes nehmen als Service-Desk

1. Zu viele um einen Effizienzgewinn durch die Arbeit mit Service Desk zu erzielen. Und nur dann macht der Service Desk Sinn.
2. GENAU DARÜBER REDEN WIR HIER DIE GANZE ZEIT, DASS DIE DICKEN DATEN NICHT IN DIE DB SONDERN SAUBER GETRENNT ABER VERKNÜPFT EXTERN ABGELEGT GEHÖREN.
3. Nutzen wir seit Jahrzehnten. Für mittlerweile fünf Mandanten. Die Frage ist ja gerade ob der Service Desk hier im Vergleich zu anderen CRMs (Amtangee, Greyhound usw)eine Alternative wäre.

In unserer Branche ist es üblich, dass Mails mit riesigen Anhängen (+ 1MB) kommen. Die kommen aber nur von Lieferanten. Hier setzen wir tatsächlich noch ein anderes System ein.
Wir werden aber mit hoher Wahrscheinlichkeit auch diese in den SD holen. Dann werden die Anhänge abgetrennt und die Mail bekommt einen Anhang mit Link zum Anhang. Erste Test laufen sehr gut.

In unseren Branchen ist es üblich, das Mails mit großen Anhängen von Kunden kommen. Ja, ich kann mir auch eine Lösung basteln die funktioniert.
Je weniger solcher Lösungen benötigt werden desto geringer ist aber die Fehleranfälligkeit des Gesamtsystems.

Die Rechnungen sind auch bei uns zweimal da. Einmal in der Wawi für den täglichen Betrieb (Kunde will nochmal die Rechnung) und einmal im DMS für Buchhaltung und Aufbewahrungspflicht. Hat auch den Vorteil, dass nicht lang überlegt werden muss wenn der Kunde eine Löschung verlangt. Wird der Wunsch geäußert, wird halt gelöscht in der Wawi. Kein Mitarbeiter hat mehr Zugriff (weil nicht vorhanden), fertig. Es sind nur noch seine Rechnungen im DMS, wo sie nach der Aufbewahrungspflichtzeit automatisch gelöscht werden.

Das ist effektives Arbeiten mit schlanken Prozessen! Was kostet den Speicherplatz?

Wir wollen, dass JTL weiterhin JTL-WAWI als ERP-System mit allen wichtigen Prozeßen des Einkaufs, Verkaufs und Versandes bestmöglich abbildet. Wir wollen weder JTL-WAWI als DMS, noch als CRM, noch als Buchhaltung sehen. Das machen andere besser.

Was hat das mit dem Thema Servicedesk zu tun? Wir archivieren unsere Daten auch anderweitig, muss ja.
Und trotzdem würde ich es vorziehen hier eine integrierte Lösung zu haben.
Jede Anbindung erhöht die Ausfall- und Fehlerwahrscheinlichkeit. Für jede Unterfunktion eigene Software einrichten, pflegen, warten und auf Fehler überwachen zu müssen ist das exakte Gegenteil von schlanken Prozessen.

Nochmal: Hier geht es um den Servicedesk der ein CRM sein will, es für Kunden mit großen Datenvolumen unter den gegebenen Umständen aber nicht sein kann. Auf dieses Problem weisen ich und andere in diesem Thread hin.


Zusammengefasst: Natürlich lassen wir das mit dem Servicedesk jetzt erstmal. Das ist aber ja weder produktiv für uns noch für JTL. Hier geht es um Feedback für ein Betatool dass mit ein paar Anpassungen auch für große Kunden sher attratkiv sein kann.

 

[ruth]

Intern wie extern, wir Backupen täglich auf einen zweiten physischen Standort. Und jetzt erzähl mir mal wie Du das mit Datenmengen von 150 Gig bei einem lokalen Totalschaden wie Brand oder Wasser mit guter Hardware und guten Medien erschlägst. Und nein "ich zieh mir die Daten abends auf eine Festplatte und wander damit durch die Gegend" ist kein guter Backup Plan.

Es gibt für wenig Geld Tresore die einen gewissen Feuerwiderstand haben. Wer dort keine Festplatte reinlegen möchte, wird wohl auch nicht seine Bachups regelmäßig prüfen, d.h. wiederherstellen. Und ja, unser GF wandert auch jeden Tag mit einer Festplatte nach Hause und legt sie dort in einen Safe (sagt er

Uns wäre es egal ob mit dem Servicedesk die DB etwas größer wird. Wir filtern die Mails, bzw. die Anhänge nur raus weil sie nicht die relevanz haben, in die DB geschrieben zu werden. Wir haben andere Daten mit denen die DB größer wird, als bei anderen Händlern. Wir haben kein Problem ca. 120 GB täglich voll und halbstündlich ergänzend wegzusichern.

Festplatten kosten kaum was im Verhältnis zu 120 GB Cloud. Ich käme gar nicht auf die Idee 120 GB durchs Netz zehn Häuser weiter zu schieben, außer es wäre ein Außenstelle mit der ich ein Gigabit-Netz habe.

Aber wir reden aneinader vorbei, bzw. siehst Du Probleme wo es keine gibt.

 

[Verkäuferlein]

Den Ansatz finde ich völlig falsch.

Schnelles effektives Backup, schnelle Wiederherstellung, zügige Wiederaufnahme des Geschäftsbetriebes. Große Datenmenge? Dann halt gute Hardware und Medien.

......

Die Rechnungen sind auch bei uns zweimal da. Einmal in der Wawi für den täglichen Betrieb (Kunde will nochmal die Rechnung) und einmal im DMS für Buchhaltung und Aufbewahrungspflicht. Hat auch den Vorteil, dass nicht lang überlegt werden muss wenn der Kunde eine Löschung verlangt. Wird der Wunsch geäußert, wird halt gelöscht in der Wawi. Kein Mitarbeiter hat mehr Zugriff (weil nicht vorhanden), fertig. Es sind nur noch seine Rechnungen im DMS, wo sie nach der Aufbewahrungspflichtzeit automatisch gelöscht werden.

Jeder hat hier vermutlich andere Strukturen und unterschiedliche Backup-Ansätze. Wir hatten nur schonmal den Ernstfall und ich weiß wie gut es 1. ist schnell wieder die Wawi am laufen zu haben (sowohl vom Gefühl, als auch um zumindest mit der Auslieferung weiter arbeiten zu können und die Bestände weiter laufen zu lassen) und sich dann 2. um die weniger kritischen Daten kümmern zu können, die im Zweifelsfall auch archiviert sind und nicht zwangsläufig wieder produktiv hergestellt werden müssen.

Ob das doppelte Vorhalten der Rechnungen und ggf. Löschen aus der Wawi wirklich sinnvoll ist, sei mal dahingestellt. Was macht Ihr wenn der Steuerprüfer wissen möchte, wie die Rechnung zustande kommt, also den Weg von der Rechnung zum Auftrag oder umgekehrt nachvollziehen möchte? Was macht Ihr, wenn Eure Rechnungsvorlage sich verändert und Ihr die Rechnung neu aus der Wawi ausgebt oder durch z.B. ein Update die Vorlage fehlerhaft wird und es plötzlich 2 unterschiedliche gleiche Rechnungen gibt? Und warum soll ich die Rechnung produktiv doppelt speichern, wenn sie mir auch einmal gespeichert reicht?

Grundsätzlich macht es doch Sinn, möglichst viele zusammenhängende Prozesse in einem System abzubilden oder zumindest entsprechende bildirektionale Schnittstellen zwischen den Systemen zu haben und trotzdem die Daten entsprechend zu trennen.

Je größer die Datenmengen, desto komplexer wird das Ganze halt. Ich hoffe nur, Euer Geschäftsführer schleppt keine HDD mit sich rum, die dann im Wiederherstellungsfall einen "Transportschaden" hat.

 

[Jens Falk]

Die Filterung auf den Mailserver, u.a. mit Procmail, war früher üblich und es wurden Anhänge von der Mail abgetrennt. Zu dieser Vorgehensweise kommen immer mehr Verwaltungen. Universitäten, Kliniken und Firmen zurück. Die Vorteile liegen klar auf der Hand.

Im Bereich des Privaten erkennt man auch diese Tendenz, u.a. bei Thunderbird mit der File-Link-Funktion.

Wer ein Outlook-Postfach, oder eben die DB von JTL-Wawi klein halten möchte, sollte sich überlegen auf seinem Mailserver Filter und Regeln anzulegen.

Um den normalen Benutzer von JTL nicht zu überfordern, sollte einfach alles in die Datenbank. Der Lösungsansatz mit Filestreaming ist wegen der 10 GB Grenze sehr gut.

Ein Backup, eine Wiederherstellung. Das kennen die Kunden u.a. von Datev und von Lexware. Das möchten sie auch so. Warum auch nicht?

Auch meinen Kunden empfehle ich die Festplattenlösung mit Generationprinzip und Safe. Jüngst war ein Artikel in der ct. (https://www.heise.de/ratgeber/Emotet-sicheres-Familien-Backup-erstellen-4705783.html), in diesem, wie auch in allen zuvor mit dem Thema Backup: am Ende der Backupkette war's der Datenträger (Platte oder Band) und der feuerfeste Safe.

Das hat man schon immer so gemacht, weil sich das eben auch bewährt hat.

Sinnvoll wäre, wenn es im SD eine Filelinkfunktion gäbe wie in Thunderbird. Idealer: Statt der Rechnung im Anhang, der Link zum Shop, wo die Rechnung im Kundenbereich abrufbar ist, senden. Den im Shop will der Händler den Kunden doch haben, oder nicht?

 

[Jens Falk]

Ob das doppelte Vorhalten der Rechnungen und ggf. Löschen aus der Wawi wirklich sinnvoll ist, sei mal dahingestellt. Was macht Ihr wenn der Steuerprüfer wissen möchte, wie die Rechnung zustande kommt, also den Weg von der Rechnung zum Auftrag oder umgekehrt nachvollziehen möchte? Was macht Ihr, wenn Eure Rechnungsvorlage sich verändert und Ihr die Rechnung neu aus der Wawi ausgebt oder durch z.B. ein Update die Vorlage fehlerhaft wird und es plötzlich 2 unterschiedliche gleiche Rechnungen gibt? Und warum soll ich die Rechnung produktiv doppelt speichern, wenn sie mir auch einmal gespeichert reicht?

Ich habe zwei Firmen, zum einem bin ich Unternehmsberater (seit 2005) zum anderen Händler (auch seit 2005). JTL habe ich als Händler seit 2007 im Einsatz, in der Beratung seit 2010, ofizieller SP erst seit 2020.

Wir wurden bisher zweimal geprüft, zuletzt die Jahre 2016 und 2017. Da gab es überhaupt keine Probleme.

JTL habe ich nie als sogenanntes Vorsystem betrachtet, weil anderes als z.B. bei Lexware das Paßwort der DB bekannt ist, also Daten nicht festgeschreiben werden im Sinne des Gesetzgebers. Was ich persönlich auch für sehr gut halte, da ich sehr viel an der DB machen möchte. Es ist auch eins der Hauptgründe warum bei uns JTL im Einsatz ist!

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.

 

[McAvity]

GENAU DARÜBER REDEN WIR HIER DIE GANZE ZEIT, DASS DIE DICKEN DATEN NICHT IN DIE DB SONDERN SAUBER GETRENNT ABER VERKNÜPFT EXTERN ABGELEGT GEHÖREN.

Genau, dafür gibt es definitiv bessere Systeme als ein relationales Datenbank-System. Ein Beispiel wäre (wenn man es nicht im Dateisystem ablegen möchte) das GridFS von MongoDB.

MfG

McAvity

 

[SebiW]

Genau, dafür gibt es definitiv bessere Systeme als ein relationales Datenbank-System. Ein Beispiel wäre (wenn man es nicht im Dateisystem ablegen möchte) das GridFS von MongoDB.

MfG

McAvity

Ja. Und ein solches besseres System sollte JTL in ihr CRM integrieren. Ich kann hier auch auch problemlos mit einer Ablage im Dateisystem leben. Machen wir bei unserem derzeitigen Tool auch.

Nochmal, nichts anderes versuche ich hier die ganze Zeit zu kommunizieren: der Mailverkehr gehört nicht in die Warenwirtschafts DB, auch nicht in Form von Filestream weil Filestream hier das Problem nur verlagert aber nicht behebt.

 

[McAvity]

der Mailverkehr gehört nicht in die Warenwirtschafts DB, auch nicht in Form von Filestream weil Filestream hier das Problem nur verlagert aber nicht behebt.

Full Ack.

MfG

McAvity

 

[Jens Falk]

Lexware ist auch so erfolgreich, weil die Anwendung ein normaler Benutzer selbst installieren und einrichten kann. Dort gibt es eine DB, fertig! Auch bei Lexware financial office und Lexware business.

Es gibt vergleichbare Lösungen, die bekommt nur noch ein Servicepartner installiert, weil jedes Modul/ Bereich seine eigene DB hat. Sehr ärgerlich für Firmen, wenn der SB nur diesen Hersteller möchte.

JTL ist auch so erfolgreich, weil fast jeder installieren und loslegen kann. Hoffentlich bleibt es so.

Wer ein Service-Desk mit einem Mailclient oder einem Ticketsystem wie OTRS verwechselt, wer sich riesige Anhänge in das Service-Desk holt, sollte auch in der Lage sein, seine Datenbank, inkl. Backups, zu beherrschen.

Die meisten JTL-Nutzer werden das Service-Desk so nutzen, wie es ursprünglich gedacht war: Beantwortung von normalen Service-Anfragen, wie: wo ist mein Paket?, kann ich das nachbestellen usw.

Deshalb werden die meisten Nutzer auch kein Problem haben, daß das Service-Desk in die DB schreibt.