Aufgabe:

Wir möchten unsere knk-Grundmodule und die knkVerlag-Module in viele kleine Apps (Extensions) zerlegen und diese in den Microsoft Dynamics365 AppSource legen, um sie darüber an ein breites Publikum zu vermarkten. Wenn man sich das Thema näher anschaut, sieht man, dass es nützlich wäre, das Ganze zu strukturieren.

Worum es geht

Wir möchten unsere knk-Grundmodule und die knkVerlag-Module (soweit diese branchenübergreifend nützlich sind) in viele kleine Apps (Extensions) zerlegen und diese in den Microsoft Dynamics365 AppSource legen, um sie darüber an ein breites Publikum zu vermarkten. Wenn man sich das Thema näher anschaut, sieht man, dass es gewisse Interdependenzen gibt und das es nützlich wäre, das Ganze zu strukturieren.

knk-Grundmodule (und branchenübergreifend nützliche knkVerlag-Module) strukturieren – was ist gemeint:

Im Modul „knkBasis“ sind – nur mal als Beispiel – u.a. folgende Funktionalitäten drin, die eigene Apps sein könnten:

a) Unternehmen-Ansprechpartner-Personen-Struktur (der NAV-Standard kann nicht gut mit Privatpersonen und Freiberuflern umgehen: Diese muss man in Standard-NAV sowohl als Firma, als auch als Ansprechpartner anlegen, um mit ihnen Geschäfte machen zu können. Auch kann man in Standard-NAV nicht erkennen, dass ein und dieselbe Person Ansprechpartner bei verschiedenen Firmen ist. Das ist für Unternehmen, die mit solchen Zielgruppen (B2B, B2C) arbeiten, ziemlich schlecht). Wir haben dafür eine elegante Lösung, die den Standard nur geringfügig verändert => könnte man eine Extension draus machen.

b) Kommunikationsdaten: Im NAV-Standard kann man nur eine Büro-Telefonnummer und eine Mobilnummer hinterlegen. Neue Kommunikationsdaten, wie z.B. die SnapChat-ID usw. kann man gar nicht hinterlegen. Unsere Lösung (Kommunikationszeilen) ist einfach und eine elegante Erweiterung des Standards.

c) Social Relations: Ditto, wie Kommunikationsdaten.

d) Anschriften: Der NAV-Standard ist da unrund: Viele Anschriften werden direkt in den Kontakt/Debitor/Kreditor-Daten oder in den Belegen eingegeben. Außerdem gibt es „alternative Lieferanschriften“ – die aber mit einer anderen Feldstruktur als der Rest des Standards. Insgesamt ist das alles großer Murks – den wir heute mit unserem Anschriftenkonzept noch nicht vollbefriedigend gelöst haben – aber wir sind da schon sehr viel besser, als der Standard. Könnte also ein eigenes Addon sein.

Im ersten Schritt benötigen wir mal ein VERZEICHNIS all dieser Funktionsbausteine (die man prinzipiell als App veröffentlichen könnte). => ca. 2-4 Stunden Arbeit

Im zweiten Schritt wäre mal zu untersuchen, ob es Abhängigkeiten zwischen diesen Apps gibt: Benötigt man z.B. das Unternehmen-Ansprechpartner-Personen-Modul als VORAUSSETZUNG, um dann auch das Anschriften-Modul nutzen zu können? Oder könnte man das Modul „Kommunikationsdaten“ immer verwenden? Wenn das Modul „Kommunikationsdaten“ installiert ist – ändert sich dann die Funktionsweise des „Unternehmen-Ansprechpartner-Personen-Moduls“ (müssten da irgendwelche Fallunterscheidungen in den Source-Code eingebaut werden, die abhängig von der vom Nutzer gewählten Konfiguration unterschiedliche Funktionsweisen berücksichtigen)? => ca. 1-5 Tage Arbeit, ggf. lässt sich das auch erst vernünftig beurteilen, wenn man mal ein paar dieser Apps entwickelt und veröffentlicht hat?

Bearbeitet durch

Alexander Mädge