Sales Intelligense

Mit Sales Intelligence by COMPRiS identifizieren Sie Kunden- und Partnerpotenziale, die Sie bislang nicht kannten und machen diese f√ľr Ihre Vertriebsaktivit√§ten zug√§nglich.

Eine Kombination aus Analytics-, Big-Data- und Machine-Learning-Software erm√∂glicht es Ihnen, innerhalb k√ľrzester Zeit neue, unbearbeitete Segmente zu erschlie√üen und gleichzeitig die Datenqualit√§t Ihrer bestehenden Kunden zu verbessern.

intelligente Adressdarstellung in AFS-Manager Formularen

Die Speicherung der zu einem Vorgang (Rechnung, Lieferschein, etc.) hat sich im AFS-Manager im Laufe der Zeit ge√§ndert und weiterentwickelt. Leider hat es AFS vers√§umt, mit einer neuen Version die bestehenden Daten zu konvertieren, sondern √ľberl√§sst dies dem Benutzer. Verst√§ndlicherweise existieren nun in fast jeder Datenbank die unterschiedlichsten Datenformate.

Problematisch wird dies, wenn die Adresse weiter verwertet werden soll, z.B. um eine Rechnung oder Lieferschein zu drucken, oder die Adressdaten an einen Paketdienstleisteister zu √ľbergeben (Postmann). Sollten Sie dar√ľber nachdenken, Ihre Adressdaten zu vereinheitlichen, schauen Sie sich mal unser Programm Lieferadressen an.

Dieses Dokument besch√§ftigt sich mit der Darstellung der richtigen Adresse auf dem Formular. Dabei soll ein Formular f√ľr alle Vorgangsarten (Angebot, Lieferschein, Rechnung, etc.) verwendbar sein. Jede Art, wie der Manager die Adresse speichern k√∂nnte, soll ber√ľcksichtigt werden. Die Anforderungen sind konkret:

  • Auf Belegen au√üer Lieferschein und Kommission wird die Rechnungsadresse gedruckt. Wenn im folgenden von einem Lieferschein die Rede ist, sind immer Lieferschein UND Kommission gemeint.
  • Seit Version X15 verwendet der Manager f√ľr die Lieferadresse eigene Datenbankfelder l_firma, l_firma2, l_name, l_vorname, l_strasse, l_land, l_plz, l_ort. Wenn dort der Ort gef√ľllt ist, wird diese Lieferadresse verwendet.
  • Vor Version X15 verwendete der Manager sogenannte definierte Lieferadressen. Diese sind ein Freitext, welcher mit ##DEF:# beginnt und Zeilenweise die Bestandteile der Adresse enth√§lt. Wenn dies der Fall ist, wird diese Adresse verwendet.
  • Alternativ kann im gleichen Feld eine Freitext-Lieferadresse vorhanden sein. Diese wird, wenn n√∂tig, unformatiert angezeigt.
  • Analog f√ľr die Lieferadresse gibt es seit Version X15 auch f√ľr die Rechnungsadresse eigene Datenbankfelder. Diese Adresse ist, wenn der Ort gef√ľllt ist, der Adresse aus der Adressdatenbank vorzuziehen.

Die Adressen werden wie folgt priorisiert. Die Erkennung ob eine Adresse vorhanden ist oder nicht erfolgt am Ort.

  1. Lieferadresse aus L-Feldern
  2. definierte Lieferadresse
  3. Freitext Lieferadresse
  4. Rechnungsadresse aus R-Feldern
  5. Rechnungsadresse aus Adressdatenbank

Wir verwenden zur Umsetzung den Formulargenerator des AFS Managers. Wenn Sie das Forumlar nicht selbst programmieren wollen, haben wir ein Beispielformuar f√ľr Sie. Sprechen Sie uns an.

Damit das Formular √ľbersichtlich und wartbar bleibt, wird f√ľr jede Adressart ein eigenes Textfeld verwendet. Die Darstellungsbedingung der Textfelder entscheidet, welches angezeigt wird.

intelligente Adressdarstellung in AFS-Manager Formularen
die 4 √ľbereinander liegenden Adress- Objekte im Formular.
intelligente Adressdarstellung in AFS-Manager Formularen
Lieferadresse aus L-Feldern
intelligente Adressdarstellung in AFS-Manager Formularen
Die Darstellungsbedingung f√ľr Lieferadresse aus L-Feldern
intelligente Adressdarstellung in AFS-Manager Formularen
definierte Lieferadresse
intelligente Adressdarstellung in AFS-Manager Formularen
Die Darstellungsbedingung f√ľr definierte Lieferadressen
intelligente Adressdarstellung in AFS-Manager Formularen
freie Lieferadresse im RTF Textfeld
intelligente Adressdarstellung in AFS-Manager Formularen
Die Darstellungsbedingung f√ľr freie Lieferadressen
intelligente Adressdarstellung in AFS-Manager Formularen
Rechnungsadresse aus der Adressdatenbank
intelligente Adressdarstellung in AFS-Manager Formularen
Die Darstellungsbedingung f√ľr Rechnungsadressen aus der Adressdatenbank

Anmerkung: Dieses Beispiel ber√ľcksichtigt noch nicht die R-Felder f√ľr die Rechnungsadresse.

Postmann – Logistikanbindung f√ľr AFS

Postmann ist die L√∂sung zum komfortablen Paketversand mit der Warenwirtschaft AFS Kaufmann und AFS Manager. Unterst√ľtzt werden aktuell die Paketdienstleister UPS Worldship, GLS Gepard Connect, DHL EasyLog und DPD Delisprint. Weitere Logistikunternehmen sind in Planung und einfach umzusetzen.

Postmann Logo

Die Zeiten, in denen die Adresse und ein Barcode auf dem Paket f√ľr den Versand ausreichten, sind vorbei. Mittlerweile bietet jeder Paketdienstleister eine Software an, in der Absender, Empf√§nger, Gewicht, Zustellungsarten und so weiter erfasst werden m√ľssen und welche einen Paketaufkleber ausgibt. Die Erfassung in diesen Programmen ist nicht nur doppelte Arbeit sondern auch fehleranf√§llig.

Postmann basiert auf dem Gedanken, dass alle nötigen Daten schon existieren. Die Daten sollen von dort gelesen werden und mit möglichst wenig Aufwand einen Paketaufkleber erzeugen. Ziel ist, auch größere Mengen an Paketen täglich abwickeln zu können. Zur späteren einfachen Nachvollziehbarkeit ist die erzeugte Sendungsnummer dort, wo sie hin gehört, nämlich im Beleg in der Warenwirtschaft.

  • Komplettbedienung per Barcodescanner
  • Automatische Ermittlung aller Daten aus dem Kaufmann
  • Eingabe von Gewicht und Lieferart per Barcodescanner
  • Anbindung einer digitaler Waage von MyWeight
  • R√ľck√ľbermittlung der Sendungsnummer(n) an AFS-Kaufmann
  • Nachnahmesendungen bei Rechnungen
  • Paketversand im Namen Ihres Kunden
  • Paketversand auf Kosten Dritter (UPS)
  • Multi-Mandanten, Multi-Datenbanken f√§hig
  • Geringe Kosten

Postmann ist f√ľr die Dienstleister UPS, GLS, DHL und DPD verf√ľgbar. Selbstverst√§ndlich realisieren wir auch Ihren Lieblingsdienstleister.

Demoversion

Eine Demoversion von Postmann f√ľr den AFS Manager finden Sie hier: Postmann.zip. Diese Version ist voll funktionsf√§hig, allerdings wird ein Hinweis auf die Testversion auf dem Paketaufkleber ausgegeben. Eine installierte und funktionsf√§hige Testversion k√∂nnen Sie ganz einfach mit einem Freischaltcode von uns in eine Vollversion umwandeln.

Handbuch

Postmann ist die L√∂sung zur Logistikanbindung des AFS Managers. Unterst√ľtzt werden aktuell die Paketdienstleister UPS Worldship, GLS Gepard Connect, DHL EasyLog und DPD Delisprint. Weitere Logistikunternehmen sind in Planung und auf Anforderung einfach umzusetzen.

Postmann ist ein eigenständiges Programm, welches auf die Datenbank des Managers und die Schnittstellen der Paketdienstleister zugreift. Dadurch ist es unabhängig und flexibel. Die Bedienung ist auf Masse ausgelegt und kann vollständig mit einem Barcodescanner erfolgen.

Postmann wird √∂rtlich und zeitlich nah zur Verpackung und Versand ausgef√ľhrt. Fr√ľhzeitig verf√ľgbare Daten wie Absender, Empf√§nger und Versandart werden vorab im Vorgang hinterlegt. Erst sp√§ter verf√ľgbare Daten wie Gewicht werden vom Postmann zugesteuert. Postmann wird vom Lager-Mitarbeiter vollst√§ndig per Barcodescanner bedient.

Postmann wird direkt im Lager auf einem PC installiert. Dieser PC sollte vorzugsweise mit einem Etikettendrucker, einem Barcodescanner und einer digitalen Waage von MyWeight ausgestattet sein. Auf diesem PC sollte außerdem die Software des Paketdienstes installiert werden.

Die Erstinstallation wird beim Kauf per Fernwartung von uns erledigt. Genauere Informationen zur Installation finden Sie hier:

Der Kollege im Lager startet morgens den Postmann und wartet bis die Oberfläche bereit ist. Gleichzeitig startet er die Software des Paketdienstleisters im Hintergrund und aktiviert die Schnittstelle.

  1. Der Mitarbeiter erhält einen Lieferschein oder Packzettel und packt anhand dessen das Paket.
  2. Mit einem Barcodescanner erfasst der Kollege den Barcode auf dem Lieferschein.
  3. Postmann sucht den Lieferschein im AFS Manager und lädt dessen Daten.
  4. Der Absender des Pakets kann je nach Kunde variieren und wird zur Kontrolle angezeigt.
  5. Der Empfänger ist entweder der Kunde oder eine abweichende Lieferanschrift, welche angezeigt wird.
  6. Anhand der Versandart im AFS wird versucht die Lieferart des Versenders zu ermitteln. Ist diese nicht korrekt, korrigiert der Kollege diese per Barcodescan.
  7. Die Anzahl der Pakete kann der Kollege per Barcodescanner eingeben oder ignorieren.
  8. Der Nachnahmebetrag wird aus einer Rechnung gelesen wenn die Zahlungsart „Nachnahme“ enth√§lt. Alternativ kann der Mitarbeiter den Betrag korrigieren oder manuell eingeben.
  9. Ist eine digitale Waage angeschlossen, legt der Kollege das fertige Paket auf die Waage, von welcher Postmann das Gewicht des Päckchens ließt. Alternativ kann er das Gewicht auch per Barcodescanner erfassen oder weglassen.
  10. Der Kollege kontrolliert die auf dem Bildschirm geladenen Daten und bestätigt diese.
  11. Postmann nimmt mit der Schnittstelle der Software des Paketdienstleisters auf und √ľbergibt die Daten.
  12. Die Software des Paketdienstleisters pr√ľft die √ľbergebenen Daten und erzeugt die Sendung. Der Paketaufkleber mit den Sendungsdaten wird gedruckt.
  13. √úber die Schnittstelle erh√§lt Postmann die Sendungsdaten zur√ľck.
  14. Die die soeben erzeugte Sendungsnummer wird zur√ľck in den Beleg im AFS Manager gespeichert.
  15. Wenn vorhanden und gew√ľnscht werden auch weitere Daten in den Beleg gespeichert.
  16. Die Sendungsnummer wird in Postmann dargestellt.

Nach Beendigung aller Packaktivit√§ten wird Postmann beendet und in der Software des Paketdienstleisters der Tagesabschluss durchgef√ľhrt.

definierte Lieferanschriften im AFS Manager

Eine Lieferanschrift im AFS ist entweder ein Freitext oder ein bestimmt formatierter Text. Wenn die einzelnen Felder der Adresse ben√∂tigt werden, ist es f√ľr eine Software schwierig, einen freien Text zu interpretieren. Daher wird empfohlen, immer definierte Lieferadressen im AFS Manager zu verwenden.

vorgang_definierte_lieferanschrift

Diese sind wie folgt aufgebaut:

##DEF:#
intelligenSE
Jan
Honsberg
Brombacher Strasse 75
DE
69434
Eberbach

Eine definierte Lieferanschrift besteht aus 7 Feldern. Die einzelnen Felder sind durch Zeilenumbr√ľche getrennt. Die erste Zeile enth√§lt immer ein ##DEF:#, alle weiteren enthalten die Feldinhalte wie folgt:

  1. ##DEF:#
  2. Firma
  3. ASP Vorname
  4. ASP Nachname
  5. Strasse
  6. Land
  7. PLZ
  8. Ort

Bleibt ein Feld leer, z.B. der Vorname und Nachname, so muss hier eine leere Zeile verwendet werden.

Wann in einem Vorgang eine freie oder eine definierte Lieferanschrift verwendet wird, kann der Benutzer pro Vorgang entscheiden. Der Kaufmann speichert sich nicht, ob eine Definierte Lieferanschrift oder ein Freitext verwendet wird, sondern erkennt dies an der ersten Zeile.
Eine so formatierte Lieferanschrift kann auch im Kunden als abweichende Lieferanschrift hinterlegt werden. Dort fehlt allerdings die Umschaltm√∂glichkeit auf die definierte Lieferanschrift. Diese kann aber dort von Hand eingegeben werden und wird korrekt in den Vorgang √ľbernommen.

Formular

Im Formular muss eine solche Lieferanschrift gesondert behandelt werden. Eine Freie Lieferanschrift ist normalerweise im Feld

TBL_Auftrag.Lieferanschrift

zu finden. Ist diese leer, so ist entweder keine oder eine Definierte Lieferanschrift hinterlegt. Das Feld

TBL_Auftrag.Lieferanschrift_RTF

enthält die Lieferanschrift in formatierter Form. Wird eine definierte Lieferanschrift verwendet, so enthält diese Feld die ##DEF:# Kodierung.

Um auf die Definierte Lieferanschrift zuzugreifen, sind External-Komandos nötig:

external$("AdresseX.Firma1")
external$("AdresseX.Vorname")
external$("AdresseX.Name")
external$("AdresseX.Strasse")
external$("AdresseX.PLZ")
external$("AdresseX.Ort")
external$("AdresseX.Land")

Wird eine freie Lieferanschrift verwendet, so enthält jede dieser Variablen die volle Lieferanschrift Рist also nicht zu verwenden.

um Herauszufinden, ob eine Lieferanschrift verwendet wird und wenn ja welche können folgende Bedingungen verwendet werden:

if(len(rtrim$(ltrim$(tbl_auftrag.lieferanschrift_rtf)))<=0, 
"keine Lieferanschrift", "mit lieferanschrift")
if(left$(ltrim$(tbl_auftrag.lieferanschrift_rtf), 2)="##", 
"definierte Lieferanschrift", "freie lieferanschrift")

COSMiC Partnerstatus Workflow

Der Workflow Partnerstatus dient dazu, jeden Partner automatisch einen verbindlichen Partnerstatus zuzuordnen.

Die Zuordnung erfolgt in zwei Schritten, welche in den Regeln implementiert sind: Prognose und finaler Status. Durch die Integration ins Regelsystem werden beide Regeln regelm√§ssig, f√ľr jeden Partner innerhalb 24 Stunden ein mal ausgef√ľhrt. Der Partnerstatus wird also t√§glich √ľberpr√ľft.

finaler Status

Die Prognose wird anhand der vorgegebenen Daten t√§glich berechnet. Sie kann sich daher auch t√§glich √Ąndern. Dies ist beim finalen Status nicht gew√ľnscht, da dieser auch an den Partner kommuniziert wird. Der finale Status soll sich nur √Ąndern, wenn ein definierter Zeitraum verstrichen ist.

Der Partnerstatus darf sich nur einmal pro Monat verändern, sofern dieser besser wird.

Der Partnerstatus darf sich nur einmal in 18 Monaten verändern, sofern dieser schlechter wird.
F√ľr den finalen Status sind also 3 Felder von Bedeutung:

  • finaler Partnerstatus
  • Timestamp Partnerstatus: Zeitpunkt, wann der finale Partnerstatus vom Workflow zuletzt gesetzt wurde.
  • Partnerstatus Prognose: t√§glich berechneter Partnerstatus

Um die Rangfolge der Partnerstati zu bestimmen, ist die Reihenfolge der Auswahlwerte in den Auswahlfeldern ausschlaggebend. Steht der Wert in der Liste weiter oben (1. Zeile) so ist dieser besser. Steht der Wert in der Liste weiter unten (9. Zeile) ist dieser schlechter.

Wird vom Workflow ermittelt, dass der finale Partnerstatus geändert werden muss, so wird der Timestamp Partnerstatus mit dem aktuellen Datum verglichen. Ist der Zeitunterschied größer als 1 Monat und wird der Partnerstatus besser, wird der Partnerstaus geändert, ansonsten bleibt er unverändert. Ist der Zeitunterschied größer als 18 Monate und wird der Partnerstatus schlechter, wird der Partnerstaus geändert, ansonsten bleibt er unverändert.

Prognose

Die Prognose enthält den Partnerstatus, der täglich neu anhand der im Partner gespeicherten Daten berechnet wird.

Der Umsatz ist die Summe des Umsatzes der letzten 12 Monate f√ľr alle Produktgruppen. Die Betreuergruppe wird anhand der Benutzergruppe des MNT-Betreuers festgelegt. Das Kennzeichen VAD ist direkt ein Wert aus dem Partner.

Es gelten folgende Bedingungen. Diese werden sequentiell abgearbeitet, die erste die Erfolgreich ist bestimmt den Status.

  1. Online
    • mehr als 100.000k Umsatz
    • Betreuergruppe Online
  2. Distribution
    • mehr als 100.000k Umsatz
    • Betreuergruppe Distribution
  3. Systemhaus
    • mehr als 100.000k Umsatz
    • Betreuergruppe Systemhaus
  4. Retail
    • mehr als 100.000k Umsatz
    • Betreuergruppe Retail
  5. Volume Reseller
    • mehr als 500k Umsatz
    • Betreuergruppe Volumne
  6. Value Add
    • mehr als 500k Umsatz
    • Kennzeichen VAD
  7. Reseller
    • mehr als 100k Umsatz
    • Betreuergruppe PST
  8. Premium
    • mehr als 100k Umsatz
  9. Advanced
    • zwischen 20k und 100k Umsatz
  10. Business Partner
    • zwischen 1k und 20k Umsatz
  11. Registered
    • weniger als 1k Umsatz
  12. nicht registriert
    • keine Bedingungen

Die Prognose wird ca. jede 24 Stunden neu berechnet und gespeichert.

manuelle √Ąnderung

manchmal kann es nötig werden, einen Finalen Partnerstatus manuell zu setzen und zu fixieren. Um dies korrekt zu tun ist es nötig zu wissen, was der Workflow tut und was man erreichen will.

Generell sollte, sobald der Partnerstatus manuell angepasst wird auch der Timestamp angepasst werden. Wird dies nicht gemacht, wird die Prognose nach den oben definierten Bedingungen als Final √ľbernommen.

Soll ein besserer Partnerstatus gesetzt werden als die Prognose ergibt, so muss der Timestamp auf den heutigen Tag gesetzt werden. Dann gilt dieser f√ľr die n√§chsten 18 Monate, danach wird wieder die Prognose aktiv. Soll der Partnerstatus f√ľr l√§nger als 18 Monate gesetzt werden, z.B. 24 Monate, so muss der Timestamp um 6 Monate in die Zukunft gesetzt werden. Soll der Partnerstatus k√ľrzer als 18 Monate gelten, z.B. nur 1 Jahr, so ist der Timestamp um 6 Monate in die Vergangenheit zu setzen. Soll der Partnerstatus f√ľr immer gelten (nicht empfohlen), so ist der Timestamp m√∂glichst weit in die Zukunft zu setzen. Soll der Partnerstatus bis Ende des Jahres gelten, so muss der Timestamp auf den 1.7. des letzten Jahrs gesetzt werden.

Soll ein schlechterer Partnerstatus gesetzt werden als die Prognose ergibt, so muss mit dem Timestamp identisch verfahren werden, allerdings wird mit 1 Monat anstatt 18 Monaten gerechnet.

COSMiC Internationalisierung

Im Zuge der Internationalisierung ist es n√∂tig, auch COSMiC zu in verschiedene Sprachen zu √ľbersetzen.

Historisch bedingt ist COSMiC vollst√§ndig deutsch ausgelegt. Dies wird ge√§ndert, so dass die Grundsprache des Systems Englisch ist und zur Anzeige in die Sprache des Benutzers √ľbersetzt wird. Dies gestaltet sich allerdings nicht so einfach, da die Trennung zwischen Daten und System nicht eindeutig vorgenommen werden kann.

Textarten

Grundsprache des Systems ist Englisch. Alle Texte die im Quelltext verwendet werden sind in Englisch. F√ľr die Darstellung werden die Texte in die Sprache des Benutzers √ľbersetzt. Daten in der Datenbank werden normalerweise in Englisch vorgehalten und √ľbersetzt. Ausgenommen von der √úbersetzung sind Texte, die der Benutzer selbst eingeben kann. Partnerdaten sind, was standardisierte Felder angeht, in Englisch gespeichert und werden zur Anzeige √ľbersetzt, freie Texte werden in Landessprache gespeichert.

Konkret bedeutet dies:

  • Feldnamen sind Englisch und werden bei der Anzeige √ľbersetzt (en+)
  • Auswahlwerte f√ľr Auswahlfelder sind en+
  • Namen von Benutzern und Gruppen sind in Englisch, werden aber nicht √ľbersetzt (en-)
  • Berichte, Berichtsnamen und Beschreibung sind in Landessprache und werden nicht √ľbersetzt (de-)
  • Bei Berichtsbedingungen und -Eingaben werden Feldnamen und Operatoren in Englisch gespeichert und √ľbersetzt, die Vergleichswerte m√ľssen aber entsprechend des Feldtyps zu den Inhalten passen (siehe #Suchen)
  • Partnerdaten, die auf Auswahlfeldern beruhen, werden in Englisch in der Datenbank gespeichert und bei Anzeige √ľbersetzt. (en+)
  • Partnerdaten, die auf Auswahlfeldern mit Sonstigem beruhen, werden dann in Englisch gespeichert, wenn ein Auswahlwert verwendet wird. Wird ein freier Text in Sonstiges eingetragen, wird dieser nicht √ľbersetzt.
  • Partnerdaten, die in Textfeldern gespeichert werden sind in Landessprache (de-)
  • Partnerdaten, die auf Datums oder Zahlfeldern beruhen werden im internationalen Format gespeichert und bei der Darstellung konvertiert.
  • Box Namen sind historisch bedingt in einer Mischung aus Deutsch und Englisch. Diese werden normalerweise nicht angezeigt.
  • Box Titel sind en+
  • Box Inhalte k√∂nnen √ľber eine Option der Box √ľbersetzt werden. In diesem Fall sind die Inhalte in Englisch zu verfassen. Die √úbersetzung erfolgt Zeilenweise. Inhalte die √ľbersetzt werden, sollten recht statisch sein und sich selten √Ąndern um den √úbersetzungsaufwand gering zu halten.
  • Regeln sind in Englisch oder Landessprache und werden nicht √ľbersetzt. Die Beschreibung der Regeln in Flie√ütext existiert in deutsch und englisch.

angezeigte Sprache

Die Sprache, in der COSMiC dargestellt wird ist abhängig vom angemeldeten Benutzer. Diese wird in den Erweiterten Benutzerrechten vom Administrator festgelegt.

Solange noch kein Benutzer angemeldet ist, wird die Sprache in der Konfiguration der Installation festgelegt.

Technisches

Die √úbersetzung erfolgt anhand einer MySQL Tabelle, die in allen Installationen verwendet wird. Diese Tabelle enth√§lt zu jedem Text die passenden √úbersetzungen. Diese Tabelle wird vom √úbersetzungs-Team gepflegt. Ben√∂tigte Texte werden dort automatisch angelegt, sobald diese im System verwendet werden. Neu angelegte und damit noch nicht √ľbersetzte Texte werden als „automatisch“ gekennzeichnet bis diese √ľbersetzt wurden.

Probleme

Suchen

Da die Partnerdaten nicht in einer einheitlichen Sprache vorliegen ist beim Suchen Hintergrundwissen gefragt. Basiert die Suche auf Text-Feldern, so muss in der Landessprache gesucht werden. Basiert die Suche auf Auswahlfeldern, so muss in Englisch gesucht werden. Die Volltextsuche sollte daher nur Text-Felder beinhalten.

Beim Erstellen von Berichten ist bei den Filtern und Eingaben die selbe Problematik zu beachten.

√Ąnderungen am Feldtyp

Eine √Ąnderung des Feldtyps ist in Problemlos m√∂glich, allerdings muss zus√§tzlich zum Datentyp auch die Sprache beachtet werden.

Wird ein Textfeld in ein Auswahlfeld konvertiert, sind die Daten bereits in Landessprache enthalten, die Auswahlwerte allerdings in Englisch. In den Partnerdetails werden die englischen Auswahlwerte allerdings √ľbersetzt, aber die landessprachlichen Daten nicht zugeordnet. In der Auswahlliste stehen diese dann also entweder unter Sonstiges oder als eigener Auswahlpunkt.

Wird ein Auswahlfeld in ein Textfeld konvertiert, so verschwindet die √úbersetzung und die Daten werden in Englisch angezeigt.

Wir deinem Auswahlfeld ein Auswahlpunkt hinzugef√ľgt oder entfernt, so werden genauso die entsprechenden Daten nicht zugeordnet bzw. nicht mehr √ľbersetzt.

Intelligente Eingabewerte in COSMiC

Nicht immer ist beim Suchen, Filtern oder in Berichten ein fester Wert sinnvoll. Cosmic bietet intelligente Eingabewerte, die vom System bei Bedarf umgesezt werden.

im Zuge der Internationalisierung werden auch englische K√ľrzel eingef√ľhrt.

Datum

Bei Datumsfeldern kann automatisch das aktuelle Datum und/oder Zeit eingesetzt werden und basierend darauf gerechnet werden.

  • heute / today

Setzt das aktuelle Datum ohne Zeitanteil ein, z.B. 30.07.2014

  • heute -2 Monate / today -2 month

Rechnet von heute die angegebene Anzahl von Monaten vor oder zur√ľck. Es sind positive und negative Werte erlaubt, allerdings immer mit Vorzeichen + oder -. Auch bei einem Monat muss 1 Monate geschrieben werden. Es wird jeweils das reine Datum ohne Zeitanteil verwendet.

  • heute -14 Tage / today -14 days

Rechnet von heute die angegebene Anzahl von Tagen vor oder zur√ľck. Es sind positive und negative Werte erlaubt, allerdings immer mit Vorzeichen + oder -. Auch bei einem Tag muss 1 Tage geschrieben werden. Es wird jeweils das reine Datum ohne Zeitanteil verwendet.

  • jetzt / now

Setzt das aktuelle Datum und Zeit ein, z.B. 30.07.2014 14:25

  • jetzt -6 Stunden / now -6 hours

Rechnet von heute die angegebene Anzahl von Stunden vor oder zur√ľck. Es sind positive und negative Werte erlaubt, allerdings immer mit Vorzeichen + oder -. Auch bei einer Stunde muss 1 Stunden geschrieben werden. Es wird immer sekundengenau gerechnet. Neben Stunden sind wie oben auch Tage und Monate m√∂glich.

  • wochenbeginn

Rechnet von heute aus zur√ľck auf den letzten vergangenen Montag, 0:00 Uhr.

  • wochenende

Rechnet von heute aus auf den nächsten Montag, 0:00 Uhr.

Benutzer

  • ich / me

mit dem Schl√ľssewort wird der Vor- und Nachname des aktuell angmeldeten Benutzers eingef√ľgt. Das Feld darf nur die drei Buchstaben enthalten, sonst nichts.

Auswahlwerte

  • ersterwert

verwendet in einem Auswahlfeld den ersten Wert der Auswahlliste.

  • letzterwert

verwendet in einem Auswahlfeld den letzten Wert der Auswahlliste.

Verwendung

Die Schl√ľsselw√∂rter k√∂nnen an verschieden Stellen, wo Daten an die Datenbank √ľbergeben werden verwendet werden.

  • in Bedingungen von Berichten
  • in Eingabewerten von Berichten
  • in Textfeldern in den Partnerdetails (auch als Sonstiges)
  • in den Vorgabewerten eines Felds
  • in den Suchfeldern der Detailsuche oder Volltextsuche

COSMiC Felder

Die Felder bilden das Grundger√ľst der Partnerdatenbank. Felder sind in jeder Installation flexibel definierbar.

Die Definition der Felder ist von den #Inhalten getrennt, sodass jederzeit Felder hinzugef√ľgt oder ge√§ndert werden k√∂nnen ohne das Daten verloren gehen.

Über die normalen Datentypen hinaus gibt es zusätzliche #Feldtypen mit besonderen Funktionen oder Eigenschaften.

Name

Der Name des Feldes muss innerhalb der Datenbank eindeutig sein und ist frei definierbar. Es sind 100 Zeichen f√ľr den Feldnamen erlaubt, allerdings sollten zwecks Darstellung nur 20-30 Zeichen verwendet werden.

Neben dem eindeutigen Namen erhält jedes Feld vom System eine eindeutige ID. Diese wird automatisch vergeben und ist nicht änderbar. Der Name kann jederzeit geändert werden. Cosmic verweist generell immer auf die ID des Feldes, sodass eine Namensänderung keine Auswirkung auf z.B. Inhalte, Berichte, Rechte, Regeln, Konfigurationen hat.

Feldtypen

Es gibt verschiedene Datentypen f√ľr Felder, welche sowohl den Inhalt als auch die Darstellung und Eingabem√∂glichkeiten steuern. Die zur Verf√ľgung stehenden Feldtypen k√∂nnen je nach Anforderungen erweitert werden.

Text

normales Text Eingabefeld f√ľr einen kurzen Text bis ca. 200 Zeichen. Es k√∂nnen zwar beliebig lange Texte gespeichert werden, allerdings ist die Darstellung in einem einzeiligen kurzen Textfeld ungeeignet. Mit einer Zahl bei Auswahlm√∂glichkeiten kann die L√§nge der eingebbaren Zeichen eingeschr√§nkt werden, allerdings wirkt sich das nur auf die Darstellung und nicht auf die tats√§chliche Speicherkapazit√§t des Felds aus.

Memo

Memo ist wie Text, nur dass mehrere Zeilen und Zeilenumbr√ľche erlaubt sind.

Zahl

Zahl speichert eine numerische Zahl beliebiger Genauigkeit. Erlaubt sind Ziffern, ein Vorzeichen sowie das Komma als Dezimaltrennzeichen.

Euro

Euro ist weitgehendst Identisch mit Zahl, allerdings kann in der Spalte Auswahl eine Einheit f√ľr die Zahl stehen, welche in der Anwendung dargestellt wird.

Datum

Datum enth√§lt ein Datum mit Zeitwert. Die Formatierung ist immer yyyy-mm-dd hh:nn:ss, also das vierstellige Jahr, zweistelliger Monat, zweistelliger Tag, zweistellige Stunde, zweistellige Minute und zweistellige Sekunde. Ist ein ung√ľltiges Datum enthalten, wird dies zur Anzeige in der Anwendung versucht zu korrigieren und beim Speichern korrekt eingetragen.

Ja/Nein (Boolean)

Boolean speichert einen Ja-Nein-Wert. Content enthält eine 1 oder 0, wobei ein leerer Wert oder fehlender Datensatz als Nein angesehen wird und jeder andere Wert als Ja. Gespeichert wird aber immer eine 1, 0 oder der Datensatz wird gelöscht.

Auswahlfeld Mehrfachnennung

Check speichert eine Liste von Werten, die aus einer Liste von Werten ausgewählt wurden. Die möglichen Werte sind in Auswahl zeilenweise gespeichert. Content enthält die ausgewählten Werte zeilenweise.

Auswahlfeld Einfachnennung

Radio speichert einen Wert, der aus einer Liste von Werten ausgewählt wurde. Die möglichen Werte sind in Auswahl zeilenweise gespeichert. Content enthält den ausgewählten Wert aus der Liste.

Auswahlfeld … und Sonstiges

CheckSonst und RadioSonst sind identisch mit Check und Radio, können allerdings zusätzlich auch einen freien Eintrag enthalten. Dies kann allerdings auch bei Check und Radio der Fall sein, die Darstellung und Behandlung der zusätzlichen Zeilen in der Anwendung unterscheidet sich aber.

Verweis auf Partner

Partner speichert einen Verweis auf einen Partner. Gespeichert wird die ID aus Kunde.

Telefonnummer / E-Mail / URL

URL, eMail, Tel enthalten Texte, die in Anwendung formatiert dargestellt werden. Es k√∂nnen zwar beliebige Daten enthalten sein, die Anwendung stellt diese auch dar, aber speichert nur g√ľltige URL, eMail und Telefonnummern.

Kategorie und Position

Mit der Kategorie und Position wird die Darstellung in den Partnerdetails festgelegt. Die Kategorie gibt an, welcher Karteireiter/Tab verwendet wird, X und Y die Pixelgenaue Position von der oberen linken Ecke ausgesehen.

Die Feldverwaltung stellt ein möglichst genaues Abbild der Partnerdetails dar. Hier kann jedes Feld per Drag&Drop in den Kategorien verschoben und innerhalb der Kategorie positioniert werden. Bei der Positionierung per Drag&Drop wird ein Raster von 10 Pixeln eingehalten, die manuelle Eingabe von X und Y ermöglicht jeden Wert.

Bei der Anlage einer Kategorie, wird angegeben, ob es sich um eine Kategorie oder Untertabelle handelt. Untertabellen werden in den Partnerdetails als Tabelle dargestellt. Die Spaltenreihenfolge wird aus der X, danach aus der Y-Position bestimmt, also von oben nach unten und links nach rechts. Außerdem kann in der Tabellenansicht sich jeder Benutzer die Spalten je nach Wunsch ein- und ausblenden.

Vorgabewerte

Jedes Feld kann einen Vorgabewert enthalten, welcher eingesetzt wird, wenn ein neuer Datensatz in der Untertabelle oder ein neuer Partner angelegt wird.

Bei einer Untertabelle wird der Vorgabewert in das Feld eingesetzt anstatt es leer zu lassen. Der Benutzer kann das Felder während der Bearbeitung noch ändern und leeren. Beim Speichern wird der dann im Feld eingetragene Wert unabhängig vom Vorgabewert gespeichert. Hat der Benutzer kein Schreibrecht auf das Feld, so wird auch der Vorgabewert nicht gespeichert.

Als Vorgabewert kann jede beliebige Zeichenfolge verwendet werden. Abhängig vom Feldtyp kann dieser allerdings noch umgewandelt oder nicht korrekt dargestellt werden. Wird z.B versucht, ein Text in ein Zahl oder Datumsfeld vorzugeben, wird dieser, soweit möglich in eine Zahl/Datum konvertiert. Es können auch intelligente Eingabewerte verwendet werden, solange diese zum entsprechenden Feldtyp passen.

Beschreibung

Der Beschreibungstext kann Anweisungen zum Ausf√ľllen des Felds enthalten. Der enthaltene Text wird, sofern vorhanden im Tooltip eines Felds in den Partnerdetails angezeigt.

Inhalte

Die Inhalte jedes Felds werden getrennt von der Definition des Felds gespeichert. Das bedeutet, dass wenn sich die Definition des Felds ändert die (noch) keine Auswirkungen auf die Inhalte hat.

Ist ein bestimmter Eingabewert, wie auch immer, in die Datenbank gelangt, bleibt dieser dort unver√§ndert bis zur n√§chsten √Ąnderung gespeichert unabh√§ngig davon, was die Definition des Felds aussagt. Die Definition des Felds stellt lediglich sicher, dass der Feldinhalt (in den Partnerdetails) entsprechend dargestellt wird. Dazu kann es n√∂tig sein, den Wert zu ver√§ndern, konvertieren, abzuschneiden, zu erweitern oder gar zu l√∂schen. Dies geschieht in dem Moment nur f√ľr die Anzeige. In der Datenbank wird der Inhalt erst ge√§ndert, wenn ein Speichervorgang ausgel√∂st wird, der einen anderen Inhalt vorsieht.

Manche Feldtypen behandeln ung√ľltige Daten die verloren gehen k√∂nnten:

  • bei Auswahlfeldern mit Sonstiges werden Daten, die nicht nicht einem Auswahlwert zuzuordnen sind, im Sonstiges-Abschnitt untergebracht.
  • bei Auswahlfeldern ohne Sonstiges werden Daten, die nicht einem Auswahlwert zugeordnet werden k√∂nnen, als ein eigener Auswahlwert hinzugef√ľgt und dargestellt
  • Textfelder und Memofelder k√∂nnen beliebige Daten enthalten, daher ist ein Datenverlust auszuschlie√üen.

Manche Feldtypen erzeugen mit hoher Wahrscheinlichkeit einen Datenverlust:

  • Ein Zahlfeld kann nur ein Zahl enthalten. Texte und Buchstaben werden verloren gehen. Allerdings wird ein Wert sehr Tolerant in eine Zahl umgewandelt.
  • Ein Euro Feld darf genauso wie ein Zahlfeld nur eine Zahl enthalten, sogar mit der Beschr√§nkung auf zwei Nachkommastellen. W√§hrungssymbole werden allerdings toleriert.
  • bei Ja/Nein Feldern wird jeder Wert abweichend von „0“, „nein“, „false“, „no“ und leer als „ja“ erkannt.
  • Eine Telefonnummer kann nur aus Ziffern und Leerzeichen bestehen. Alles andere wird ignoriert. Eine Telefonnummer wird aber um eine Landesvorwahl erg√§nzt, anhand einer Vorwahl-liste validiert und formatiert.

COSMiC Datenstruktur

Die Partnerdaten in COSMiC sind auf verschiedene Datentabellen verteilt. Dies ist nötig, damit die Partnerdatenbank einfach und unkompliziert vom Benutzer erweitert werden kann.

Zentral ist die Tabelle Kunde, welche die eindeutige Partner ID und die Stammdaten enth√§lt. Die zus√§tzlichen Datenfelder enth√§lt die Tabelle DataFeld. Dort wird Name, Darstellung und Dateninhalt konfiguriert. Die eigentlichen Daten befinden sich in DataDetail, ein Datensatz f√ľr jeden Partner und jedes Feld. F√ľr die Untertabellen sind die beiden Tabellen SubFeld und SubDetail zust√§ndig, welche weitgehenst identisch mit den Data-Tabellen sind.

Partner

Die Tabelle Kunde enth√§lt f√ľr jeden Partner einen Datensatz.

Die ID wird automatisch von der Datenbank vergeben und primäre Identifikation des Partners.

Die KDNR ist eine sekundäre Identifikation. Sie wird vom Benutzer vergeben, die Datenbank stellt allerdings deren Eindeutigkeit sicher.

Die Felder Firma, Str, Land, PLZ, Ort, Tel enthalten die grundlegenden Stammdaten. Die genaue Formatierung √ľbernimmt die Anwendung und entspricht denen der Felder.

Felder

Die Tabelle DataFeld enthält die Definition der zusätzlichen Felder.

Jedes Feld ist √ľber seine ID eindeutig identifiziert. Die ID wird automatisch von der Datenbank vergeben. Name und Beschreibung sind Name und Beschreibung des Felds; sie werden prim√§r f√ľr die Darstellung in der Anwendung verwendet. Die Spalte Typ gibt zusammen mit Auswahl an, welche Daten im Feld gespeichert werden und wie. Kategorie, PosX, PosY sind f√ľr die Darstellung in den Partnerdetails (Karteireiter und Position) verantwortlich.

Die Tabelle DataDetail enthält die eigentlichen Daten zu jedem Feld und jedem Partner. Über die Spalte Referenz wird der Bezug zum Partner hergestellt, sie enthält die eindeutige ID des Partners aus der Tabelle Kunde. Die Spalte Feld stellt die Verbindung zum Feld her, sie enthält die ID aus DataFeld. Die Spalte Content enthält die eigentlichen Daten, die Formatierung ist abhängig vom Feldtyp.

Es muss nicht immer f√ľr jedes Feld/Partner ein Datensatz in DataFeld existieren. Wenn kein Datensatz vorliegt, liegen auch keine Daten vor. Es sind aber Datens√§tze mit leerem content erlaubt.

Untertabellen

Untertabellen sind weitgehendst identisch mit den Feldertabellen aufgebaut.

Die Spalte Kategorie in SubFeld enthält hier den Namen der Untertabelle und stellt damit die Zusammengehörigkeit von Feldern zu einer gedachten Untertabelle her.

Die Spalte Nummer in SubDetail enth√§lt die ID eines Untertabellendatensatzes und f√ľgt somit die Daten zu einer Zeile in der Untertabelle zusammen. Die Nummer ist nur innerhalb einer Untertabelle (Kategorie aus SubFeld) und eines Partners (Referenz in SubDetail) eindeutig.

Feldtypen

Jedes Feld hat einen Typ, welcher durch die Anwendung verwaltet wird. Die Art des Typs bestimmt die Spalte Typ, zusammen mit Auswahl aus den Tabellen DataFeld und SubFeld. Der Typ hat Einfluss darauf, wie die Inhalte in content in den Tabellen DataDetail und SubDetail gespeichert sind.

Anmerkungen

Alle Tabellen enthalten eine ID, welche von der Datenbank vergeben wird und eindeutig ist.

Alle Tabellen enthalten eine Spalte Timestamp, welche die Datenbank aktualisiert. Sie enthält immer das Datum, wann dieser Datensatz das letzte mal geändert wurde.

Alle Tabellen und Feldnamen sind grundsätzlich kleingeschrieben, unabhängig von der Schreibung in dieser Dokumentation.

Tabellennamen können zwischen den Installationen abweichen.

Nicht beschriebene Felder sind obsolet oder nur zur Abwärtskompatibilität vorhanden.

Dieses Dokument stellt den Entwicklungsstand vom 25.07.2016 dar.