Neu Speicherung in SQL DB?

  • Temporäre Senkung der Mehrwertsteuer Hier findet ihr gesammelt alle Informationen, Videos und Fragen inkl. Antworten: https://forum.jtl-software.de/threads/mehrwertsteuer-senkung-vom-01-07-31-12-2020-offizieller-diskussionthread-video.129542/

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
945
192
Eine Kundenhistorie mit Inhalt wird man in der Regel nur ein Jahr benötigen. Danach schaut man eher weniger in die Vorgänge. Hier reicht, daß man ein Betreff bzw. Rechnungsnummer usw. hat um in den entsprechenden Archiven nachzuschauen.

JTL sollte ein Anwendung sein und bleiben, in der es um Einkauf und Verkauf geht.

Es würde auch bei den derzeitigen Datenschutzauflagen schwer erklärbar sein, warum E-Mails, Rechnungen usw. von vor Jahren im System mit vollständigen Inhalt sind. Aufbewahrungsfristen einzuhalten bedeutet nicht gleichzeitig, daß jeder JTL-wawi-Benutzer die Vorfälle/ vollständigen Inhalte sieht, die vor etlichen Jahren geschehen sind.

Da ist das Leben mit externen Lösungen DMS/Mailarchiv wesentlich einfacher und schafft keine Probleme!
Hm. für mich klingt das ein bisschen nach 1-dimensionalem Denken in einer 3-dimensionalen Welt.

Ja, es geht um Einkauf und Verkauf, noch genauer um (Online-)Handel, dazu gehört aber eben auch die Kommunikation mit Kunden und Lieferanten und das beinhaltet nunmal auch die Kommunikationshistorie. Außerdem müssen wir ja davon ausgehen, welche Systeme ein Händler standardmäßig benötigt und wenn es dann um ein ERP geht, sollten auch alle Prozesse, die ein Händler benötigt in diesem integriert sein.

Ehrlich gesagt drehen wir uns auch ein wenig im Kreis, wir haben hier ja von vorneherein für eine "physische" Trennung der Daten ausgesprochen aber eine "technische" Zusammenführung (das schließt natürlich Berechtigungen und Datenschutz mit ein), da war Deine Position, dass alles in eine Datenbank mit einer Sicherung müsste, wenn ich das richtig sehe.

Was genau ist daran einfacher, wenn ich 3 nicht miteinander verbundene Systeme nutze um eine miteinander korellierende Aufgabe zu erledigen?

Man muss das Ganze doch einmal aus der Lösungssicht und nicht aus der Problemsicht betrachten. Die zentrale Frage ist doch: "Was macht einem Online-Händler die tägliche Arbeit leichter?"

Daher meine Frage: Ist die oben genannte Lösung für euch ein Weg mit dem ihr in der Wawi mit Kunden kommunizieren könnt ohne die Datenbanken aufzublähen?
Das kann ich für uns leider nur mit einem klaren "Jein" beantworten. Mit der Perspektive, dass sich der Funktionsumfang erweitert, wäre es zumindest die Möglichkeit den Service-Desk als eine Art temporären "Mail-Client" bzw. "Mail-Server" einzusetzen, der die Mails mehr oder weniger mit Kunden und Aufträgen verknüpft und quasi nur als "Zwischenspeicher" für die temporäre Bearbeitung (bis zur Erledigung) dient und die eigentliche Speicheraufgabe weiterhin beim Mailserver bzw. Mailarchiv zu belassen

Für eine Telefonnotiz oder eine kleine Reklamation, oder eine (Mail-)Aufgabe ist das sicherlich auch mit längerfristiger Speicherung nutzbar, löst aber eben noch kein wirkliches infrastrukturelles Problem.

Cool wäre, wenn man über den Service-Desk z.B. die ebay-Kommunikation mit Nachrichtenverlauf und per API-Anbindung an ebay sauber abwickeln könnte, das würde sehr viel erleichtern und sich dann auch wieder lohnen dafür ggf. die DB ein wenig zu strapazieren.

Das Grundproblem ist aber die Menge an Anfragen und Kommunikation, die einfach speicherhungrig ist und der Verknüpfung verschiedener Systeme bedarf. Eine Teil-Erleichterung wäre aber zumindest in der Erledigung von "kleinen Anfragen" gegeben ohne dass es einen Konflikt mit einem anderen System oder übermäßige Duplizität gibt. :)
 
  • Gefällt mir
Reaktionen: SebiW

Jens Falk

Offizieller Servicepartner
SPBanner
14. Mai 2020
188
66
Was genau ist daran einfacher, wenn ich 3 nicht miteinander verbundene Systeme nutze um eine miteinander korellierende Aufgabe zu erledigen?
Gern beantworte ich dies.

1. Man wird nicht eine Kundenhistorie mit vollem Inhalt 10 Jahren in einem Servicedesk benötigen.
2. In einen DMS und Mailarchiv werden gesetzeskonform die Dokumente gelagert - die eher nicht im täglichen Geschäftsalltag abgerufen werden, sondern nur bei Prüfung usw.
3. Wie der Name es eigentlich schon ausdrückt: Servicedesk! D.h. Anfragen beantworten auf allen möglichen Kanälen, also eher Funktionen von otrs, zendesk, freescout usw. als ecoDMS, bifarm-Archiv, ELO usw.

Das für eine Aufgabe die ein Geschäftsvorfall von vor x Jahren betrifft, drei Systeme benötigt werden, ist eher unwahrscheinlich. Es reicht ein Blick ins DMS.
 

SebiW

Sehr aktives Mitglied
2. September 2015
1.439
430
Gern beantworte ich dies.

1. Man wird nicht eine Kundenhistorie mit vollem Inhalt 10 Jahren in einem Servicedesk benötigen.
2. In einen DMS und Mailarchiv werden gesetzeskonform die Dokumente gelagert - die eher nicht im täglichen Geschäftsalltag abgerufen werden, sondern nur bei Prüfung usw.
3. Wie der Name es eigentlich schon ausdrückt: Servicedesk! D.h. Anfragen beantworten auf allen möglichen Kanälen, also eher Funktionen von otrs, zendesk, freescout usw. als ecoDMS, bifarm-Archiv, ELO usw.

Das für eine Aufgabe die ein Geschäftsvorfall von vor x Jahren betrifft, drei Systeme benötigt werden, ist eher unwahrscheinlich. Es reicht ein Blick ins DMS.
1. Richtig. Sagt auch keiner. Die darf gern bspw im Filesystem archiviert werden (Button->archivieren, Workflow->archivieren) und sollte einfach nur bei Bedarf aus dem Servicedesk durchsuchbar sein. Das darf gerne langsamer sein. Es sollte den User aber nicht aus dem Wawi Kontext herauszwingen. Und man sollte sie separat sichern können.
2. Auch richtig. Was spricht dagegen das funktionell sauber in die Wawi zu integrieren? Wieso macht es in Deinen Augen mehr Sinn, ein externes System wie ecoDMS anzubinden, als dies als native Wawi Funktion bereitzustellen?
Für den Wawi User bedeutet das an dieser Stelle: Zusatzaufwand, Zusatzkosten. Wieso sollte das von Vorteil sein?
3. Auch richtig. OTRS zb kann Mails einfach im Dateisystem speichern und so dauerhaft bei Bedarf verfügbar halten. Ist langsamer als ne DB, macht aber keine Probleme. Siehe Punkt 1.

Zusammengefasst: Wieso sollte es für einen JTL Nutzer vorteilhaft sein, sich diverse zusätzliche Tools anzuflanschen, die Zusatzkosten, Zusatzaufwand und Zusatzfehlerwahrscheinlichkeit bedeuten?
Es tut mir leid, aber nein, "JTL ist kein DMS" ist kein Argument. Bis vor 3 Monaten war JTL auch kein Servicedesk. Bis vor zwei Jahren kein Fulfillment Network.
Derzeit ist JTL keine Produktionsumgebung. Kein Preiskalkulationstool. Kein Controlling Tool. Keine Schnittstelle zu Marktplätzen außer eBay und Amazon.
All das kommt aber.

Ich sehe kein sinnvolles Argument, warum ein DMS nicht in JTL integriert werden sollte. Vario hat eins, Sage auch. Warum sollte das für JTL nicht sinnvoll sein?
Gleiches gilt für das Mailarchiv für die Mails, die über den Servicedesk laufen.
 

Jens Falk

Offizieller Servicepartner
SPBanner
14. Mai 2020
188
66
Ich sehe kein sinnvolles Argument, warum ein DMS ...
ich sehe dann aber auch kein sinnvolles Argument, warum nicht JTL ein Betriebssystem, Textverabeitung, Buchhaltung usw. baut.

Bei Sage habe ich keine Möglichkeit direkt die DB anzusprechen. Solange die DB offen wie bei JTL ist, wird es nicht möglich sein ein rechtlich unbedenkliche DMS-Funktionalität zu integrieren.

Es gibt schlicht keine Notwendigkeit bei Lösungen, wie zum Bsp. bitfarmDMS (kostenlos) oder ecoDMS eine Zugrifflizenz 89,- (einmalig), auch noch ein DMS in JTL einarbeiten zu wollen, wenn ich in JTL nur bei der Erstellung der Rechnung ein gleichzeitiges speichern anstoßen muß, damit das Dokument ins DMS geht und dort automatisch verarbeitet wird.

Wir warten auf 1.6 und Shop 5 bereits wie lang? Ein verzetteln sollte vermieden werden.

Zahlreiche Anwender von Lexware financel office, Sage usw. kommen zu JTL, weil sie eben nicht eine nur zum Teil funktionierente und überteuerte Eierlegendewollmilchsau wollen. Sie wissen, daß:

- JTL Multi-Channel-Vertrieb besser kann
- Datev. Agenda und Lexware Buchhaltung besser kann
- bitfarm Archiv, ecoDMS, elo usw. Dokumentenmanagment besser kann
- MS Office, LibreOffice Textverarbeitung, Tabellenkalkulation ... besser kann

Und am Ende des Tages auch feststellen, daß sie mit diesen Lösungen wesentlich effektiver und kostengünstiger arbeiten.
 

SebiW

Sehr aktives Mitglied
2. September 2015
1.439
430
ich sehe dann aber auch kein sinnvolles Argument, warum nicht JTL ein Betriebssystem, Textverabeitung, Buchhaltung usw. baut.
Buchhaltung? Würde Sinn machen. JTL will ein ERP sein, da gehört Finanz- und Rechnungswesen eigentlich rein. Siehe:
https://de.wikipedia.org/wiki/Enterprise-Resource-Planning#Funktionsbereiche_einer_ERP-Software

Und ja, ich und viele andere Kunden wollen sowas lieber aus einer Hand. Mag sein, dass es für Dich als Servicepartner schwer nachvollziehbar ist.
Ich möchte mich nicht mit halbgaren Lösungen wie Unicorn rumschlagen, ich will keine zusätzlichen Systeme für Unterbereiche anflanschen.
Bei Sage habe ich keine Möglichkeit direkt die DB anzusprechen. Solange die DB offen wie bei JTL ist, wird es nicht möglich sein ein rechtlich unbedenkliche DMS-Funktionalität zu integrieren.
Deshalb macht man für sowas ne separate DB. Wo ist das Problem?
Es gibt schlicht keine Notwendigkeit bei Lösungen, wie zum Bsp. bitfarmDMS (kostenlos) oder ecoDMS eine Zugrifflizenz 89,- (einmalig), auch noch ein DMS in JTL einarbeiten zu wollen, wenn ich in JTL nur bei der Erstellung der Rechnung ein gleichzeitiges speichern anstoßen muß, damit das Dokument ins DMS geht und dort automatisch verarbeitet wird.
Doch die gibt es. Weil all diese Systeme die Komplexität erhöhen, zusätzliche Resourcen für Einrichtung und Wartung verschlingen und vor allem nicht für JTL optimiert sind.
Ja, ich kann Rechungen in ecoDMS drucken. Ich will auf die aber auch aus der Wawi zugreifen können. Jedes Einwegsystem erhöht den Aufwand und damit die Arbeitszeit. Mannstunden sind Geld.
Wir warten auf 1.6 und Shop 5 bereits wie lang? Ein verzetteln sollte vermieden werden.
Und deshalb sollen Funktionen nur halbfertig umgesetzt werden?
Zahlreiche Anwender von Lexware financel office, Sage usw. kommen zu JTL, weil sie eben nicht eine nur zum Teil funktionierente und überteuerte Eierlegendewollmilchsau wollen. Sie wissen, daß:

- JTL Multi-Channel-Vertrieb besser kann
Bis man jenseits von Amazon und eBay arbeiten möchte...
- Datev. Agenda und Lexware Buchhaltung besser kann
Was Zusatzkosten und Aufwand verursacht.
- bitfarm Archiv, ecoDMS, elo usw. Dokumentenmanagment besser kann
Meist mit viel zu vielen Funktionen und hohem Aufwand in der Konfiguration und nicht bidirektional.
- MS Office, LibreOffice Textverarbeitung, Tabellenkalkulation ... besser kann
Das will auch keiner.
Und am Ende des Tages auch feststellen, daß sie mit diesen Lösungen wesentlich effektiver und kostengünstiger arbeiten.
Besser als schlecht ist nicht gut. Bei der Weiterentwicklung der Wawi kann das Ziel ja wohl kaum "wir möchten das irgendwie okay können" sein.
Wenn neue Funktionen eingeführt werden machen die nur Sinn, wenn sie so angelegt sind, dass sie skalieren können, bestehende Alternativen übertreffen und insbesondere auch für Neueinsteiger den Um- und Einstieg erleichtern.

Und deshalb gehören ERP Komponenten in die Wawi.

Edith sagt, weils Wikipedia da so schön auf den Punkt bringt:
ERP-Systeme sollten weitgehend alle Geschäftsprozesse abbilden. Eine durchgehende Integration und eine Abkehr von Insellösungen führen zu einem ganzheitlichen ERP-System, in dem Ressourcen unternehmensweit verwaltet werden können. ERP-Systeme verbessern zudem den Kommunikationsfluss im Unternehmen und können im Sinne von E-Collaboration die Zusammenarbeit im Unternehmen effizienter gestalten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Verkäuferlein

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
945
192
@Manuel Pietzsch

Wäre es nicht eventuell auch sinnvoll (wie auf einer der vorderen Seiten schon einmal angesprochen), dem Service-Desk zu ermöglichen als regulärer IMAP-Client zu agieren?

Dann könnte man dem (meist schon vorhandenen) Mailserver und dem Mailarchiv die Speicherung überlassen, müsste nur Metadaten in der Wawi speichern und hätte gleichzeitig noch die Möglichkeit im Bearbeitungsweg zu variieren und trotzdem die Anknüpfung im Service-Desk an die Wawi zu nutzen, also gleich Kundendaten zu der Mail zu sehen.

Zumindest wäre dies ein vorübergehender Workaround, der keine tiefen Eingriffe in Prozesse benötigt und würde mehr Vor- als Nachteile bringen, wenn man dann mit der Arbeit mit dem Service-Desk startet.

Die benannten Probleme zu lösen, die Verlagerung der Speicherung bzw. weitere Verzahnung mit anderen Systemen wäre dann ja später trotzdem unbenommen, wenn ihr soweit seid.
 
  • Gefällt mir
Reaktionen: SebiW

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
945
192
@Michael Spaltmann Irgendwie habe ich Deinen Beitrag erst jetzt gerade gesehen.

Grundsätzlich würde ich sagen, dass der Ansatz einen guten Eindruck macht. So hat man dann verschiedene Ansatzpunkte, entweder den kompletten Posteingang im SD zu bearbeiten oder auch nur Mails für den SD umzusortieren und trotzdem sind dann alle Infos noch im Mail-Programm bzw. auf dem Mailserver und im Mail-Archiv und man hat gleichzeitig die Anbindung an die Kunden- und Auftragsdaten.

Momentan fällt mir dazu auch nichts ein, was es noch zu ergänzen gibt.
 

BeniF

Sehr aktives Mitglied
27. September 2018
189
49
Hi,

@Verkäuferlein wir wollten das hier wenn möglich noch dieses Quartal umsetzen: https://issues.jtl-software.de/issues/WAWI-47181

Würde das ausreichen? Falls nicht, welche Punkte würden dir exakt noch fehlen?

Viele Grüße Michael
GANZ WICHTIG

Es fehlt dass man keine 3. Partei ins Ticket holen kann.
Ich erhalte ein Ticket in dem mir der Kunde erklärt, keine Ware erhalten zu haben. Zur Klärung müssen wir Rücksprache mit DHL halten. Hier wäre es sinnvoll dass alle Antworten, vom Kunden und von DHL, in dieses eine Ticket laufen.
Das Servicedesk ohne dieses Feature zu betreiben ist sehr mühselig.

Kleinere Punkte wären:
- Ticket anlegen und direkt per eMail versenden (aktuell muss erst ein Ticket angelegt werden, dann über "Senden" die eMail erstellt werden - Absender und Empfänger wird über diesem Weg auch nicht vorab gefüllt)
- Beim antworten auf ein Ticket muss immer der Empfänger ausgewählt werden.
 
Ähnliche Themen Forum Antworten Erstelldatum des Themas
Neu Installation von JTL -WAWI - Hänge beim SQL Installation von JTL-Wawi 6
Neu SQL-Fehlermeldung beim Update einer DB auf Version 1.5.30.0 bei FOREIGN KEY-Einschränkung 'FK_dbo_tMerchantVersandRef_kVersand' JTL-Wawi - Fehler und Bugs 2
Neu Nach Upgrade auf SQL 2017 Express User helfen Usern - Fragen zu JTL-Wawi 0
Neu Anmeldung an MS SQL Server 2019 schlägt fehl.... Installation von JTL-Wawi 4
Neu SQL Abfrage einschränken User helfen Usern - Fragen zu JTL-Wawi 1
Neu Fehlermeldung SQL (0x80131904): Die INSERT-Anweisung steht in Konflikt mit der FOREIGN KEY-Einschränkung 'FK_ebay_data_membermessage_out_kEbayuser' .. JTL-Wawi - Fehler und Bugs 0
Neu Firma aus SQL DB extrahieren bzw. Firma mit allen Daten löschen User helfen Usern - Fragen zu JTL-Wawi 0
Neu SQL Server Größe der .mdf .log Temp-DB User helfen Usern - Fragen zu JTL-Wawi 7
Neu JTL Version aus SQL Table auslesen Individuelle Listenansichten in der JTL-Wawi 1
Neu Datenbankanbindung bei externem SQL Server Installation von JTL-Wawi 2
Neu SQL Stücklistenartikel User helfen Usern - Fragen zu JTL-Wawi 0
Neu SQL Server Optimierung - Wawi/WMS SEHR langsam User helfen Usern - Fragen zu JTL-Wawi 13
Neu SQL Abfrage Artikelnummer als Barcode Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 3
Neu Anmeldung SQL Server Installation von JTL-Wawi 10
Neu Versand>Lieferscheine offen: SQL Abfrage Artikelgewicht aller Positionen User helfen Usern - Fragen zu JTL-Wawi 0
Neu Update 4 auf 5- Datenbankupdate - SQL Fehler Installation / Updates von JTL-Shop 0
Neu Problem bei instalation SQL "does not support the language of the OS" Installation von JTL-Wawi 8
Neu SQL Server mit FileZilla verbinden Allgemeine Fragen zu JTL-Shop 3
Neu Neuinstallation SQL Server 2019 User helfen Usern - Fragen zu JTL-Wawi 2
In Diskussion SQL Abfrag in Artikeln gibt falschen Wert aus. JTL-Workflows - Fehler und Bugs 6
Neu Neuinstallation SQL Server 2019 Installation von JTL-Wawi 5
Neu SQL Abfrage - Microsoft Excel Arbeitsabläufe in JTL-Wawi 1
Neu SQL für komplett lieferbare Aufträge User helfen Usern - Fragen zu JTL-Wawi 0
Neu Wawi Sql-Abfrage des globalen Artikelnamens Deutsch in eigene Übersicht Individuelle Listenansichten in der JTL-Wawi 2
Neu SQL Abfrage Lagerbestand Verbrauch User helfen Usern - Fragen zu JTL-Wawi 1
Neu Probleme nach Upgrade 4.06 auf 5.0 - SQL Query blockiert Datenbank Installation / Updates von JTL-Shop 13
Neu JTL-WaWi (SQL Server Express 2017) - Extreme Performance-Einbrüche User helfen Usern - Fragen zu JTL-Wawi 5
Gelöst Ausgabe von SQL abfragen in Tabelle als Datenquelle Gelöste Themen in diesem Bereich 5
Neu Per SQL Umsatz netto aktuelles Jahr, Vorjahr und Datum letzter Auftrag abfragen User helfen Usern - Fragen zu JTL-Wawi 3
Neu JTL Shop 4 auf 5 SQL Update Fehler - 1267 Illegal mix of collations Installation / Updates von JTL-Shop 10
Neu SQL Datenbank, TempDB und Logfiles verschieben Installation von JTL-Wawi 5
In Diskussion Varkombis zu Stückliste zuordnen - SQL Befehl oder Workflow JTL-Workflows - Fehler und Bugs 4
Neu Welchen SQL Server würdet ihr empfehlen ? User helfen Usern - Fragen zu JTL-Wawi 2
Neu Anmeldung SQL Datenbank nicht möglich Starten mit JTL: Projektabwicklung & Migration 1
Neu SQL Datenbank keine Verbindung Installation von JTL-Wawi 0
Neu SQL Fehler durch ENGINE=InnoDB Technische Fragen zu Plugins und Templates 4
Ähnliche Themen