Christian Rott  Wenn ich es richtig verstehe, dann geht es darum, das Interesse von Messebesuchern an bestimmten Produkten bzw. Konfigurationen festzuhalten, um ggf. ein Angebot daraus erstellen zu können. Also im Grunde ein klassisches CRM-Szenario. Und vermutlich soll die Ersterfassung vor Ort möglichst einfach und effizient gehalten werden, deshalb die Auswahlfelder statt Verknüpfungen.

Der Nachteil normaler Auswahlfelder ist halt, dass sie manuell gepflegt und die Bezeichnungen sehr sorgfältig eingetippt werden müssen, wenn man über sie dann später auf bestimmte Datensätze zugreifen will (z. B. Artikel). Grundsätzlich wäre das über entsprechende select-Abfragen aber machbar. So könnte man bspw. mit einem Script nach einem Artikel mit der Bezeichnung "MF30" suchen und den betreffenden Datensatz auslesen und verknüpfen.

Als Alternative kämen ganz oder teilweise auch dynamische Auswahlfelder in Frage, welche direkt auf die Artikel-Tabelle zugreifen. Wie genau das aussehen könnte, hängt aber auch wieder von der Gliederung der Artikel ab. Gibt es Artikelgruppen, Haupt- und Unterartikel, Untertabellen mit Ausstattungsmerkmalen ...?

Da könnte ich jetzt nur spekulieren. Die Überlegung, einmal erfasste Daten als Grundlage für alle weiteren Vorgänge zu nutzen, finde ich aber sehr sinnvoll. Denn es ist ja gerade Sinn einer solchen Datenbank, dass nachgelagerte Prozesse wie das Erstellen eines Angebotes von Anfang an mit berücksichtig werden. Wenn der Innendienst die Daten noch mal erfassen muss, ist das Potenzial von Ninox nicht wirklich ausgeschöpft. ;)

Aber - wie gesagt: Um konkrete, praktische Tipps zu geben, müsste man sich viel tiefer reinknien.
 

Christian Rott 

Wie gesagt, da ich nichts über Datenmodell und -struktur weiß, kann ich leider keine konkrete, befriedigende Antwort bzw. Lösung liefern. Dazu ist das Thema zu komplex, die Fragestellung zu allgemein.

Grundüberlegung sollte immer sein: Welche Informationen benötige ich für welchen Vorgang? Beim ersten Erfassen eines Lead/Interessenten genügen vielleicht noch die Kontaktdaten des Kunden und der Produktbereich, für den er sich interessiert. Für alles weitere vom Angebot über Auftragsbestätigung und Lieferschein bis zur Rechnung braucht man detaillierte Informationen zum Kunden und den Artikeln, die man ihm anbietet, liefert oder berechnet.

Angebote, Aufträge und Rechnungen werden in der Regel mit einer entsprechenden Tabelle erfasst, welche die Kopfdaten beinhaltet (Angebots-/Auftrags-/Rechnungs-Nummer, Kunde, Datum, Gesamtpreis, Konditionen usw.), sowie eine Untertabelle, in der die einzelnen Positionen erfasst werden (Artikel, Spezifikationen, Menge, Preis). Das Prinzip kann man sich bspw. in der Ninox-Vorlage "Rechnungen" ansehen ("Neue Datenbank", Vorlage auswählen).

Der Vorgang lässt sich natürlich auch mit einem Script automatisieren. Mal angenommen, es gibt bereits Tabellen für Kunden, Artikel, Angebote und Angebotspositionen. Weiterhin angenommen, es wurde auch bereits ein Kunde zugeordnet und das im Screenshot abgebildete Auswahlfeld namens 'F-Line Mittel' enthält Artikelbezeichnungen. Dann könnte man mit einer Schaltfläche namens "Angebot erstellen" oder so anhand des ausgewählten Eintrags "F-160" den dazugehörigen Artikel-Datensatz ermitteln und ein neues Angebot mit einer Position erstellen:

let me := this;
let myArtikel := first(select Artikel where Bezeichnung = me.text('F-Line Mittel'));
let newAngebot := (create Angebote);
new.Angebot.(Kunden := me.Kunde);
let newPosition := (create Angebotspositionen);
newPosition.(Angebote := new.Angebot);
newPosition.(Artikel := myArtikel);
newPosition.(Menge := 1);
newPosition.(Preis := myArtikel.Einzelpreis);
openRecord(newAngebot)

Als Ergebnis hätte man einen neuen Datensatz in der Tabelle 'Angebote', der mit dem betreffenden Kunden verknüpft wäre und eine Angebotsposition mit einem Stück Artikel "F-160" enthielte. Zuletzt würde der neu erstellte Angebots-Datensatz geöffnet und könnte um weitere Informationen ergänzt werden.

Das aber nur als simpler theoretischer Ansatz. In der Praxis hätte man wahrscheinlich mehrere Artikel, vielleicht noch Varianten oder bestimmte Ausstattungsmerkmale, die den Preis beeinflussen. Unter den Auswahlfeldern befinden sich möglicherweise Mehrfachauswahlfelder, die anders ausgewertet werden müssen. Und und und ...
 

Das wäre schade, denn der Plan, die einmal mit Ninox erfassten Daten auch gleich für nachgelagerte Prozesse zu nutzen, klingt durchaus schlüssig. Der Aufwand zur Umsetzung wäre mit Ninox auch deutlich geringer als mit anderen Tools, dennoch muss man natürlich immer erst mal etwas Zeit investieren, um später dauerhaft von schlankeren, effizienteren Prozessen zu profitieren. Mit der Unterstützung durch professionelle Ninox-Partner lässt sich die Entwicklung aber deutlich beschleunigen: https://ninox.com/de/partner