Neu Speicherung in SQL DB?

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.525
1.012
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
284
108
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
2.647
1.244
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
284
108
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
2.647
1.244
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
2.525
1.012
@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
2.525
1.012
@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
400
127
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
Titel Forum Antworten Datum
Sql Abfrage VK Preise pro Kundengruppe für Grafana JTL-Wawi 1.8 9
Neu SQL Query zum Bilder löschen Arbeitsabläufe in JTL-Wawi 3
Neu List & Label - Eigene SQL-Abfrage als Grundlage für Tabelle im Berichtscontainer? User helfen Usern - Fragen zu JTL-Wawi 10
Neu SQL Server kein Mandant auswählbar und Dienst lässt sich nicht starten Installation von JTL-Wawi 2
Neu Ameise-Vorlage per SQL abrufen und Daten als Ergebnis erhalten JTL Ameise - Eigene Exporte 1
Neu SQL DB läuft mit Fehler voll und crasht Server JTL-Shop - Fehler und Bugs 1
Neu SQL Vartable für Reservierte Artikel gesucht User helfen Usern - Fragen zu JTL-Wawi 2
Neu Innerhalb einer Variable -SQL Abfrage- das Wort "fett" schreiben Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 2
Neu SQL Eigener Export - Eigene Felder im Auftrag User helfen Usern - Fragen zu JTL-Wawi 7
Neu Wie finde ich per SQL heraus welche Aufträge auf Teillieferbar stehen? JTL Ameise - Eigene Exporte 1
Neu Microsoft SQL unter MS365 Installation von JTL-Wawi 2
Neu SQL Abfrage, 3. Mahnstufe User helfen Usern - Fragen zu JTL-Wawi 1
Neu Variable oder SQL zum Feld "Gewinn netto" (im Auftrag) Eigene Übersichten in der JTL-Wawi 9
Neu SQL Code zur Ausgabe des Verkaufspreis je Kundengruppe User helfen Usern 1
Neu MS SQL Server auf Windows vs Linux Starten mit JTL: Projektabwicklung & Migration 9
Beantwortet Hilfe bei SQL Abfrage erbeten User helfen Usern - Fragen zu JTL-Wawi 3
Neu SQL Abfrage - Sendungsnummern als Liste nach Datum Schnittstellen Import / Export 2
Neu DB: kPlattform eines Auftrages ändern (SQL) - Zwecks Lagerplatzreservierung User helfen Usern - Fragen zu JTL-Wawi 0
Neu SQL prozeduren mit #temp Tabellen Eigene Übersichten in der JTL-Wawi 28
Neu Ameise Export in SQL Abfrage umwandeln User helfen Usern - Fragen zu JTL-Wawi 11
Neu Ware direkt in ein Standardlager einbuchen per SQL StoreProcedure dbo.spWarenlagerEingangSchreiben Schnittstellen Import / Export 9

Ähnliche Themen