In der nächsten Version ändert sich im Bereich "Feld-Attribute anhängen?" für die Eigenschaft "Sichtbarkeit" folgendes Verhalten: Felder mit "Sichtbarkeit = Versteckt" können durch die Eigenschaft "Feld-Attribute anhängen?" nicht mehr geändert werden. Da einige Felder in den Belegerfassungen im Standard auf "Sichtbarkeit = Versteckt" eingestellt sind, aber durchaus auch in den Erfassungen angezeigt werden könnten, werden diese Felder des Standards geändert.
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Vorlage Standard mit
Anlage in Feldgruppe „Positionseinheiten“ mit
Anlage in Vorlage Standard mit
Anlage in Feldgruppe „Positionseinheiten“ mit
Anlage in Vorlage Standard mit
Anlage in Feldgruppe „Positionseinheiten“ mit
Der Schreibschutz wird durch serverseitige Codierung sichergestellt (Feld ist in der ReadOnlyFieldList). Durch die Deaktivierung der Eigenschaft „Schreibschutz?“ wird bei programmatische Änderung des Feldes der Beleg Dirty.
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Feldgruppe „PositionSonstiges“ mit
Anlage in Feldgruppe „PositionSonstiges“ mit
Da alle Felder von Versteckt auf Eingeblendet umgestellt werden, werden für alle Felder Feldberechtigungen eingetragen.
Die Felder „kalkulatorischer EK“ und „Roherlös“ können kritische Informationen sein. Die Feldberechtigungen dieser Felder werden daher anhand der bereits vergebenen Berechtigungen von „Kalkulation/ Preisfindung“ und „Kalkulation/ Roherlös“ im Datenbankupdate behandelt.
Die 1:N:M-Beziehungen ließen sich bereits vorher im AppDesigner definieren. Nun wurde auch die Darstellung auf dem Client, sowie die Behandlung der CRUD-Methoden vom System implementiert.
Die Definition der M-Beziehung erfolgt analog der Definition der N-Beziehung. Die Verknüpfung erfolgt ebenfalls in der Eigenschaft "Detail-Datensätze", nur das die Hinterlegung des Detail-Datensatzes jetzt in der entsprechenden N-Beziehung zu erfolgen hat. Gleiches gilt für die Zuordnung für die UI-Darstellung. Das Multi-Data-Edit-Element der M-Beziehung muss einem Data-Edit-Element der N-Beziehung zugeordnet werden.
Als Ausgangspunkt nehmen wir das Beispiel "Projektsteuerung" aus Beispiel für die Zusammenhänge der Metadatenobjekte und ergänzen die N-Beziehung "BPKProjektsteuerungMitarbeiter" um einige Felder und legen die M-Beziehung "BPKProjektsteuerungMitarbeiterFehlzeiten" an.
Führen Sie die SQL-Statements aus Vorbereitung der Datenbank auf einer Demodatenbank aus. Zusätzlich führen Sie bitte diese SQL-Statements aus:
CREATE TABLE "BPKProjektsteuerungMitarbeiterFehlzeiten"
(
"FehlzeitId" INTEGER NOT NULL DEFAULT 0,
"Mandant" SMALLINT NOT NULL DEFAULT 0,
"SteuerungId" INTEGER NOT NULL DEFAULT 0,
"Mitarbeiter" VARCHAR(20) NOT NULL,
"DatumVon" DATETIME NOT NULL,
"DatumBis" DATETIME NOT NULL,
"Fehlzeit" SMALLINT NOT NULL DEFAULT 0,
"Timestamp" ROWVERSION,
CONSTRAINT PK_BPKProjektsteuerungMitarbeiterFehlzeiten PRIMARY KEY CLUSTERED ("FehlzeitId", "Mandant")
)
GO
INSERT INTO USysCatalog ([Table], Revision) VALUES ('BPKProjektsteuerungMitarbeiterFehlzeiten', 1)
GO
ALTER TABLE "BPKProjektsteuerungMitarbeiter"
ADD "Firmenwagen" KHKBoolean NOT NULL DEFAULT 0,
"Navigation" KHKBoolean NOT NULL DEFAULT 0,
"Mitnahme" KHKBoolean NOT NULL DEFAULT 0,
"Notebook" KHKBoolean NOT NULL DEFAULT 0,
"StellvertreterProjektleitung" KHKBoolean NOT NULL DEFAULT 0,
"ZugriffProjekt" KHKBoolean NOT NULL DEFAULT 0
GO |
Die Datenstruktur wurde angelegt, um eine 1:N:M-Beziehung darstellen zu können. Ferner geht es hier um die Anlage von Metadaten, nicht um Datenbankdesign oder Performance Optimierungen. Daher verzichten wir auf zusätzliche Indizes oder Löschweitergaben. |
Das Beispiel beschreibt die Anlage einer 1:N-Beziehung. Der aktuelle Stand des Beispiels sieht so aus:
Zu einer Projektsteuerung können N-Mitarbeiter hinterlegt werden. Die Anlage der Metadaten werden in dem Beispiel beschrieben, hier kurz die Zusammenfassung:
"recProjektsteuerung" und "recProjektsteuerungMitarbeiter" auf Basis der zugehörigen SQL-Tabellen.
Die 1:N-Beziehung wird in der Eigenschaft "Detail-Datensätze" des Datensatzes "recProjektsteuerung" hinterlegt. Die Datensatz-Beziehung geht über die SteuerungId.
"ediProjektsteuerung" und "mdeProjektsteuerungMitarbeiter" auf Basis der Datensätze.
Die 1:N-Beziehung wird in "ediProjektsteuerung" durch die Hinterlegung eines Feldes mit Feldname = virtueller Name der Datensatz-Beziehung, sowie "Typ" des Feldes = "Unterelement" mit Zuweisung von "mdeProjektsteuerungMitarbeiter" definiert.
Legen Sie folgende Strings an:
| Name | ID | Wert |
|---|---|---|
| Fehlzeit | 0 | Frei |
| Fehlzeit | 1 | bezahlter Urlaub |
| Fehlzeit | 2 | Resturlaub |
| Fehlzeit | 3 | Weiterbildung |
| Fehlzeit | 4 | Krankheit |
Legen Sie den Datensatz "recProjektsteuerungMitarbeiterFehlzeiten" mit Hilfe des Assistenten "Tabelle importieren" (BPKProjektsteuerungMitarbeiterFehlzeiten) an.
Hinterlegen Sie in der Eigenschaft "Detail-Datensätze" des Datensatzes "recProjektsteuerungMitarbeiter" folgende Daten:
Damit ist die 1:N:M-Beziehung auf Seiten der Datensätze definiert.
Die M-Beziehung muss einem Data-Edit-Element der N-Beziehung zugeordnet werden. In diesem Beispiel existiert kein "Bearbeiten-Dialog" für die Mitarbeiter, da die 1:N-Zuordnung nur aus der Hinterlegung von Mitarbeiternummern besteht. Für die Beschreibung der 1:N:M-Beziehung sind die nachfolgenden Änderungen an der Tabelle "recProjektsteuerungMitarbeiter" ohne Belang. Da aber dieses Beispiel auch für Beispiel für die Zusammenhänge der Metadatenobjekte verwendet werden soll, wollen wir zuerst die 1:N-Beziehung komplementieren.
Fügen Sie die neuen Felder in "recProjektsteuerungMitarbeiter" hinzu.
"Datentyp" für alle neuen Felder auf "Indizierter String" mit Index -1 und 0 und Ja/Nein-Strings aus Sage.System.Common
Anpassen der Titel entsprechend nachfolgender Tabelle:
| Feldname | Titel |
|---|---|
| Firmenwagen | Hat Firmenwagen |
| Navigation | Navi-Gerät vorhanden |
| Mitnahme | Kollegen mitnehmen |
| Notebook | Hat Notebook |
| StellvertreterProjektleitung | stellv. Projektleitung |
| ZugriffProjekt | Zugriff auf Projektdaten |
Um diese Daten besser bearbeiten zu können, legen wir für die N-Beziehung einen "Bearbeiten-Dialog" (Data-Edit-Element) an.
Legen Sie das Data-Edit-Element "ediProjektsteuerungMitarbeiter" an.
Der Aufruf des Dialoges erfolgt über einen Kontextmenüeintrag. Dem Multi-Data-Edit-Element "mdeProjektsteuerungMitarbeiter" ist bereit das Kontextmenü "ProjektsteuerungMitarbeiter" zugeordnet. Wir erweitern dieses Kontextmenü um den Eintrag "Bearbeiten" und verschieben dabei den bestehenden Eintrag "Löschen" auf Position 2 mit Aktivierung einer neuen Gruppe ("Gruppe beginnen?" = True).
Legen Sie den Kontextmenüeintrag "Bearbeiten" im Kontextmenü "ProjektsteuerungMitarbeiter" an.
Damit haben wir den Bearbeiten-Dialog für die 1:N-Beziehung implementiert.
Legen Sie das Kontextmenü "ProjektsteuerungMitarbeiterFehlzeiten" an.
Legen Sie das Multi-Data-Edit-Element "mdeProjektsteuerungMitarbeiterFehlzeiten" an.
Legen Sie im Data-Edit-Element "ediProjektsteuerungMitarbeiter" im Register "Mitarbeiter" die Element-Feldgruppe "Fehlzeiten" an.
Legen Sie das Feld "MitarbeiterFehlzeiten" (virtueller Feldname der N:M-Beziehung der Datensätze) in der Feldgruppe "Fehlzeiten" an.
Damit ist die M-Beziehung auch auf UI-Ebene definiert worden. Datensätze der M-Beziehung können angelegt und gelöscht werden.
Auch für die M-Beziehung kann ein "Bearbeiten-Dialog" angelegt werden. Das Verfahren ist identisch zur N-Beziehung.
Legen Sie das Data-Edit-Element "ediProjektsteuerungMitarbeiterFehlzeiten" an.
Wir erweitern das Kontextmenü "ProjektsteuerungMitarbeiterFehlzeiten" um den Eintrag "Bearbeiten" und verschieben dabei den bestehenden Eintrag "Löschen" auf Position 2 mit Aktivierung einer neuen Gruppe ("Gruppe beginnen?" = True).
Legen Sie den Kontextmenüeintrag "Bearbeiten" im Kontextmenü "ProjektsteuerungMitarbeiterFehlzeiten" an.
Zu einer Verkaufsposition können beliebig viele Zusatztexte und/oder Zusatzwerte erfasst werden. Eine weitere Tiefe soll dieses Beispiel aber nicht haben. Es werden noch das Laden, Speichern und eine Aktion auf einen Eintrag codiert.
Führen Sie dazu in einer Demodatenbank der Sage 100 diese SQL-Statements aus:
CREATE TABLE "BPKVKBelegePositionenZusatz"
(
"BelPosID" INTEGER NOT NULL DEFAULT 0,
"ZusatzID" INTEGER NOT NULL DEFAULT 0,
"Mandant" SMALLINT NOT NULL DEFAULT 0,
"BelID" INTEGER NOT NULL DEFAULT 0,
"Sortierung" INTEGER NOT NULL DEFAULT 0,
"Zusatztext" VARCHAR(50) NULL,
"Zusatzwert" MONEY NULL DEFAULT 0,
"Timestamp" ROWVERSION,
CONSTRAINT PK_BPKVKBelegePositionenZusatz PRIMARY KEY CLUSTERED ("BelPosID", "ZusatzID", "Mandant")
)
GO
INSERT INTO USysCatalog ([Table],Revision) VALUES ('BPKVKBelegePositionenZusatz','1')
GO |
Damit die Zusatzdaten pro Position erfasst werden können, sind folgende Metadaten anzulegen.
Legen Sie die Datenstruktur "strBPKVKBelegPositionZusatz" an.
Legen Sie die Datenstruktur "strVKBelegPosition" an.
Legen Sie das Multi-Data-Edit-Element "mdeBPKVKBelegPositionenZusatz" an.
Legen Sie das Data-Edit-Element "ediBPKVKBelegPositionenZusatz" an.
Legen Sie das Kontextmenü "VKBelegPositionenErfassung" an.
In der Belegerfassung können nun Zusatzdaten pro Position erfasst werden.
Wenn Sie nun mehrere Positionen in der Erfassung haben und zu jeder Position andere Zusatztexte/Zusatzwerte, so werden diese Daten alle korrekt angezeigt, auch wenn die Selektion der Position sich ändert. Die Zuordnung zu einer Position ist also vorhanden. Wenn Sie allerdings bei einer Position z.B. die Menge ändern, dann sind die Zusatzdaten nach dem Ausführen des Daten-Service nicht mehr vorhanden. Für den Transfer der Daten muss durch Codierung selber gesorgt werden.
Die M-Beziehung kann nicht als Objekt in die DCMProperties-Property gesichert werden, da durch ein Sprung nach COM dieses Objekt nicht erhalten bleibt. Die Objekt-Items müssen also flach gesichert und gelesen werden. Dafür benutzen wir ein Hilfsfeld. Legen Sie zusätzlich in den Metadaten folgendes an:
Legen Sie in der Datenstruktur "strVKBelegPosition" das Feld "BPKZusatzdatenCount" an.
Legen Sie das Multi-Data-Edit-Element "mdeVKBelegPositionen" an (oder benutzen Sie den Anhängen an-Assistenten).
Legen Sie das Daten-Edit-Element "ediVKBelegerfassung" an (oder benutzen Sie den Anhängen an-Assistenten).
Ferner wollen wir noch einen Daten-Service implementieren.
Legen Sie das Kontextmenü "VKBelegPositionenErfassungZusatzdaten" an.
Zusätzlich werden die verwendeten DCMs (siehe Codierung) unter "Erweiterungen/ Ereignisse" eingetragen.
WDB-Eintrag 203334: Anhang Beispiel_1NM_Belegposition_81.rar |
Die Eigenschaft "Navigations-Element" ist ab der Version 8.1 eine 1:N-Beziehung und wird daher in einem Zusatzdialog hinterlegt (Beispiel ediAdressenstamm.Sage.System):
Werden mehr als ein Navigations-Element in einem Daten-Edit-Element hinterlegt, wird vom System in der Applikation die Schaltfläche "Bearbeiten" hinzugefügt. Über diese Schaltfläche kann ein Navigations-Element gewählt werden:
Für eine programmatische Umstellung steht der Makro-Befehl "NavigationUmschalten" zur Verfügung. (Makrobefehle)
Navigations-Elemente können an Standard-Daten-Edit-Elemente angehängt werden. Dabei wird aber ein Listen-Element nur angehängt, wenn dem Standard-Daten-Edit-Element bereits mindestens 1 Navigations-Element zugeordnet ist.
Die Definition des Primary-Keys in den Schlüsselfeldern der Datenquelle muss bei allen Datenquellen identisch sein.
Kontextmenüeinträge von Listen-Elementen werden nach dem folgenden Verfahren zusammengeführt:
Da das Menü als ganzes im Data-Edit-Element angezeigt wird (das Menü vom Data-Edit-Element selbst, das Menü von der Liste und das Menü von der Liste-Selektion), wird es nach wie vor bereits Serverseitig komplett zusammengebaut und zum Client geschickt.
Der Client filtert dann über eine Herkunftsangabe die nicht von der aktuell eingestellten Liste stammenden Einträge aus.
Verwendet das Daten-Edit-Element mehrere Navigationselemente, so können deren Menüs verschiedene Menüeinträge enthalten.
Das Mischen funktioniert dann wie folgt:
Beim Bearbeiten von Feldern gibt es die neue Option (Menüband im Register Metadaten, oder im PopUp-Menü) "Werte übernehmen". Um geänderte Werte in andere Felder zu übernehmen, geht man wie folgt vor:
Mit dem neuen Makrobefehl "AuskunftÖffnen" kann eine Auskunft direkt ohne Umweg nach Access geöffnet werden. Damit vereinfacht sich auch die Übergabe von Parametern.
Die Funktionsaufrufe "gbOpenAuskunft" und "gbOpenAuskunftParameter" entfallen NICHT. |
Folgende Metadaten sind anzulegen:
Makrobefehle (Partner- und Lösung-ID entsprechend Ihren Daten, komplette Beschreibung unter Makrobefehle)
| Zeile | Befehl | Parameter 1 | Parameter 2 |
|---|---|---|---|
| 1 | AuskunftÖffnen | mdtStatVK.100065830.Auskunft | Artikelnummer:=[Artikelnummer];AuspraegungsHandle:=[AuspraegungsHandle];Kunde:=[$Parent.A0Konto] |
In diesem Beispiel wird eine Auskunft aufgerufen. Es ist kein "Zusatzdialog" zur Erfassung. Der Platzhalter "$Me($IndexSelected)" bezieht sich auf den Kontext "Belegposition" und nicht auf selektierte Datensätze der Auskunft. Eine Verbindung zwischen dem Kontextmenü der Auskunft und dem Kontextmenü der Belegposition gibt es nicht. |
Bisher konnte eine Datenreferenz in den folgenden Varianten angelegt, bzw. durch zusätzliche Eigenschaften eines Feldes kontextbezogen gefiltert werden:
Ab der Version 8.1 kann nun an den Geschäftsprozess einer Datenreferenz kontextbezogen eine Parameterliste übergeben werden. Die Parameter stehen in der zu implementierenden Klasse "BusinessProcessBase" in der Property "ServiceParameters" zur Verfügung. Die Parameter werden in der Eigenschaft "Datenreferenz-Parameter" in der üblichen Syntax (Art:=1;Typ:=[Typ];Kahn:="Kahn ""Der Titan""") hinterlegt.