Deutsch

Hintergrund

Datenstruktur

Verbindung zur Sage Datenstruktur "strVKBelegPosition"

Oberflächen-Element einbinden

Der entscheidende Punkt: Integration in das Sage Kontextmenü "VKBelegPositionenErfassung" der Position

Beispiel Funktionsaufruf im eigenen Kontextmenü

Datenimplementierung ausschließlich mit .net-Code möglich

Deutsch

Hintergrund

Häufig wird missverstanden , wie die Sage Funktion "DatensatzBearbeiten.Sage.System" anzuwenden ist.

Dieses kurze Beispiel zeigt , wie man sich mit einem Unterelement an die Positionserfassung in einem Verkaufsbeleg hängen kann.

D.h. man öffnet einen eigenen Erfassungsdialog zu einer ausgewählten Belegposition , über das Kontextmenü / Hamburger-Menü der Belegposition.

Dabei handelt es sich um die Umsetzung einer 1:n:m-Datenbeziehung.

Datenstruktur

Die Sage Belegerfassung basiert grundsätzlich auf Datenstrukturen.

Um sich sinnvoll in die Belegerfassung einzuklinken , führt demnach an einer eigenen Datenstruktur kein Weg vorbei.

Verbindung zur Sage Datenstruktur "strVKBelegPosition"

Es muss der Sage Standard Datenstruktur "strVKBelegPosition" zwingend mitgeteilt werden , dass die eigene Datenstruktur mit dieser in Verbindung steht.

Dies geschieht durch das übliche "Anhängen An" ("Append To") an die Sage Standard-Datenstruktur.

Offensichtlich genügt das "Anhängen an" alleine nicht.

Man muss auch im Menü für die "Detail Datenstruktur Referenzen" ("Detail Data Structure References") auf die eigene Datenstruktur verweisen.

⚠️Dieser Punkt ist entscheidend und es muss an dieser Stelle noch einmal darauf hingewiesen werden , dass der "Virtuelle Feldname" ("Virtual Field Name") der untergeordneten Datenstruktur sehr wichtig ist!

Über den "Virtuellen Feldnamen" spricht man das Element an diversen Stellen an. So auch bei der Quellcode-Behandlung. Unnsinnige Dummy-Namen oder nachträgliche Änderungen dieser Feldnamen sollte man daher komplett vermeiden!

Oberflächen-Element einbinden

Für das Einbinden der UX/UI-Ebene empfiehlt sich z.B. ein "Daten Edit Element" (edi)-Element , dem man die o.g. eigene Datenstruktur zuweist.

Zum Einfügen der Felder in das Edi-Element soll an dieser Stelle nicht näher eingegangen werden , da dies Boilerplate Standard ist.

Ein eigenes Kontextmenü ist sicherlich sinnvoll , um Funktionalität auszulösen.

Im vorliegenden Fall verwenden wir einfach ein simples Makro , um Daten aus dem Belegkopf exemplarisch abzugreifen. Dazu später mehr.

⚠️Da das Element im Rahmen der Belegerfassung zum Tragen kommt , ist zu beachten , dass der "Verwendungszweck" ("Usage") exakt so eingestellt wird wie die Belegerfassung (Erfassungsmodus basierend auf Datenstruktur).

Der entscheidende Punkt: Integration in das Sage Kontextmenü "VKBelegPositionenErfassung" der Position

Um nun für die Sage Belegerfassung die Verbindung zwischen der Sage Standard-Belegposition und dem eigenen Edi-Element herzustellen , kommt das Sage Standard Kontextmenü der Belegpositionen zum Tragen.

Hier schließt sich der Kreis.

⚠️Entscheidend ist dabei , dass man den Modus "DatensatzBearbeiten.Sage.System" als Funktion auswählt und - konsequenterweise - im Bereich "Kind Element" ("Child Part") dann das eigene Edi-Element hinterlegt.

Beispiel Funktionsaufruf im eigenen Kontextmenü

Nachfolgend ein simples Makro-Beispiel , um im Kontextmenü des eigenen Edi-Elements auf ein Belegkopf-Datenstrukturfeld zuzugreifen.

Dabei kommt folgende verschachtelte Syntax zum Einsatz:

[$Parent.$Parent.Matchcode]

Datenimplementierung ausschließlich mit .net-Code möglich

Abschließend stellt sich dem Leser sicherlich die Frage , wie die Datenverbindung zur eigentlichen Geschäftsdatenbank (SQL-Server-Datenbank) geschieht.

Da , wie oben erklärt , die Sage Belegerfassung mit einer Datenstruktur mit Geschäftsobjekt arbeitet , führt an .net-Code kein Weg vorbei.

D.h. konkret , dass man sich über die DCMs "BelegToContainer" und "ContainerToBeleg" um den Transport der Daten vom Client zum Sage Applikationsserver und zurück (Roundtrip) durch .net-Code kümmern muss. Es sei denn , die Daten sind überschaubar und hängen direkt an Benutzerfeldern (benutzerdefinierten Feldern bzw. USER-Felder).

Natürlich kann man auch darüber nachdenken , beim Öffnen und Schließen des eigenen edi-Dialogs mit den Sage Serialisierungsfunktionen und der Funktion "DataServiceExecute.Sage.System" zu arbeiten. Entsprechende Beispiele finden sich z.B. im "Rezept 59 Übergabe des Belegobjektes über serialisierte Daten"des "Sage Developer SDK Kochbuchs".

Diese Technik ist Smart Client-ready!

Die Nutzung von neuen Makro-Serialisierungsfunktionen "SerializeData" und "DeserializeData" ("DatenSerialisieren" bzw. "DatenDeserialisieren") stehen in neueren Sage Versionen zur Verfügung und erlauben es , die jeweils kontextbezogene aktuelle Datenstruktur vom Client an den AppServer zu serialisieren und auch wieder zurückzuschicken / zurückzuerhalten.

Der übliche Weg ist jedoch die Implementierung von "BelegToContainer" und "ContainerToBeleg" - siehe "Rezept 20 ContainerToBeleg / BelegToContainer" im "Kochbuch".

Dabei muss man sich auch nicht um die Situation des Belegstatus "Neuer , noch nicht gespeicherter Beleg" kümmern.

Wenn man "BelegToContainer" und "ContainerToBeleg" unbedingt vermeiden und einen der zuvor genannten Wege verwenden möchte , dann muss man sich um das Thema der Persistierung der Daten in der Geschäftsdatenbank natürlich besondere Gedanken machen.

Schließlich steht bei neuen Belegen nicht immer die neue TAN des Beleges im Feld "HandleNew" (für den Primärschlüssel im Feld "BelId") zur Verfügung.

Auf dieses Thema gehen wir gesondert in nachfolgendem Beitrag ein.