Hey,
kannst du vielleicht kurz beschreiben, was das generische Diagramm anzeigen soll und aus welcher Tabelle die Daten dazu kommen?
]]>Wenn ich aber nun versuche eine Aggregation per “Anzahl” zu erstellen, bekomme ich die Fehlermeldung “Sie können keine Anzahl für dieses Diagramm auswählen, weil die Quellenanfrage diese Aggregationsmethode nicht unterstützt.”
Hast du vielleicht eine Idee was das sein könnte? Hab schon diverse Propertys an der Query ausprobiert, aber bekomme es nicht hin.
]]>Hallo Matthias,
der Blogeintrag ist von 2020 🙂
Die Universal Code Initiative ist soweit ich weiß erst später veröffentlicht worden. Zu mindestens war es mir damals noch nicht bekannt.
]]>interessanter Blogpost – wie immer.
Nur das Ende ist mMn. sachlich nicht korrekt, da die .NET Integration auch in AL nicht nutzbar ist (wenn Du Deine Lizenz noch nicht auf BC umgestellt hast). Zukünftige BC Lizenzen müssen nämlich entweder “Universal Code” entsprechen oder zusätzliche Module schalten, die ziemlich teuer sind für keinen realen Benefit.
Quelle z.B.: https://www.anaptis.com/universal-code-initiative-cloud-ready-oder-abstrafung/ oder https://www.1clickfactory.com/blog/business-central-universal-code-initiative/
Der einzige wirklich zukunftssichere Weg ist der Datenaustausch per API oder Webservice.
Viele Grüße und frohe Weihnachten,
Matthias
Das kann man so als Regel nicht festlegen. Bei einer Liste mit 20 Flowfields und 10-15 Sekunden Ladezeit würde ich mir die Execution Plans auf dem SQL Server ansehen. Da kann man dann auch sehen welche Probleme genau auftreten. Es kann auch sein, dass die Indexauswahl besser funktioniert, wenn die Flowfields einzeln geladen werden.
Es kann auch mit der NAV/BC Version zusammenhängen, da die SQL Queries nicht zwischen allen Versionen gleich sein müssen.
]]>Wir haben den selben Effekt wie Gerald beschrieben. Nachdem wir “DisableSmartSQL” aktiviert haben wird die Liste mit ca. 20 Flowfields in 1-2 Sekunden geladen. Woher brauchte die Liste 10-15 Sekunden.
Gibt es da bereits neue Kenntnisse?
]]>Das ist sicherlich auch ein Workaround, aber dabei sollte man im Hinterkopf haben, dass der Modify trigger dann oft mehrmals durchlaufen wird (im Validate und später nochmal durch die Modifikation). Das kann negative Auswirkungen auf die Performance haben.
]]>Cust.RESET;
Cust.FILTERGROUP(-1);
FilterT := ‘@*Meier*’;
Cust.setfilter(Name,FilterT);
Cust.setfilter(“Name 2”,FilterT);
Cust.FILTERGROUP(0);
PAGE.RUN(0,Cust);
muss am ServiceTier hierzu noch evtl. was eingestellt werden?
]]>Hi Zeljko,
ich glaube nicht das generische Diagramme in Listen überhaupt in einer Liste anzeigen lassen.
Aus meiner Sicht würde ich bei der Anforderung ein Diagramm in einer Liste einzublenden folgende Optionen in Betracht ziehen:
– Power BI Factbox – das kann Daten in Bezug auf den gewählten Datensatz anzeigen, aber setzt auch voraus, dass man Power BI nutzt,
– eigenes Javascript/.NET Addin in einer Factbox zur Umsetzung der grafischen Anforderung. Es müsste möglich sein Diagramme zu zeichnen (System.Web.DataVisualization / System.Drawing) – habe ich persönlich aber noch nicht gemacht.
– Je nachdem welches business intelligence man nutzt, kann man auch dort die geforderte Auswertung vornehmen und per WebAdding (Darstellung einer Webseite as Addin einfach den Link zu dem gefilterten Diagramm aufrufen).
Sofern die Daten nicht in real time zur Verfügung stehen müssen, könnte man auch einfach mit Bildern arbeiten.
Beispiel:
– Eine Aufgabenwarteschlage erstellt pro Fertigungsauftrag ein RDLC Bericht. Dieser Bericht kann beispielsweise ein Diagramm enthalten, welches als PDF oder Word gespeichert wird. Solche Daten kann man auch in ein Bild umwandeln und dieses dann in ein Blob oder in neueren Versionen in ein Mediaset einlesen. Bilder lassen sich leicht als Factbox zu einer Liste hinzufügen.
Es kann aber auch gut sein, dass keine der genannten Wege eine gute Lösung für dein Problem darstellt. Das hängt sicher davon ab, was genau erreicht werden soll.
VG
Robert
LG Zeljko
]]>This happens with both OnBeforeModify and OnAfterModify events.
]]>Das klingt für mich nach einem Bug, kann aber auch sein das dies aus einem bestimmten Grund entfernt wurde. Das kann ich aus dem Stand nicht beantworten.
Man kann bei github schauen, ob man dort etwas zu dem Thema findet oder dort auch Microsoft direkt fragen: https://github.com/microsoft/AL
Es gibt einige Unterschiede zwischen C/AL und AL, daher kann ich mir auch vorstellen, dass dies als Feature fehlt.
]]>Schau mal im Report Designer in C/SIDE unter View bzw. Ansicht -> Labels
– Lables werden nur einmal übertragen (performanter und sinnvoll bei internen Berichten, die in der Sprache des Clients gedruckt werden sollen)
– Textkonstanten müssen im Dataset übergeben werden und werden dann für jeden Record erneut übertragen. Das benötigt man nur, wenn man die Sprache innerhalb des Berichtsdruck ändern möchte (Beispiel: Rechnungsdruck über drei Rechnungen – eine davon ist für einen Deutschen, eine ist für einen Engländer und eine für einen Franzosen. In diesem Fall kann man die Sprache mit CurrReport.Language im Bericht ändern und damit werden die Textkonstanten dann auch in der jeweiligen Sprache des Kunden übertragen.)
zunächst vielen Dank für diesen ausführlichen Beitrag. Eine Sache ist mir noch unklar. Nachdem die Tabelle hinzugefügt worden ist, woher kommen die Caption Felder PostingDateCaption, DocumentTypeCaption etc…..Diese wurde ja nicht im DataSet definiert ?
Viele Grüße,
Hussein
]]>Das ist korrekt. 2009 Classic Client ist leider viel zu alt. Dort wurde dieses Feature noch nicht unterstützt. NAV 2009 ist aber schon etwas in die Jahre gekommen 🙂
]]>Freut mich sehr.
]]>Danke dafür.
Grüße
Waldemar
I know that there are some blogs about it, but i didn’t find one in german. Therefore I created one in german. 🙂
]]>Das muss man Microsoft fragen 🙂
]]>Wieso besitzt das Tablix selbst solche Flags (Repeat Header/Column Rows on each page), die aber einfach ins leere laufen und man stattdessen an den Zeilen selbst was einstellen muss – das kann einen ja dann nur verwirren
]]>Schau mal in der Codeunit 412 Common Dialog Management nach. Dort gibt es die Funktionen “OpenFile” / “OpenFileWithName”, die ähnlich funktionieren.
VG
RObert
Ich benutze die Version 2009.
Leider gibt es dort noch nicht die Möglichkeit des OpenFileDialog (CU419).
Was kann ich stattdessen verwenden?
Mfg
Mike
Mit den statischen Headern ist das meiner Meinung nach nicht möglich. Das von beschriebene Konzept geht immer davon aus, dass der Header auf Seite 1 einmal größer ist, als auf Seite 2. Daher wird der Kopf grundsätzlich so groß gezogen, wie auf Seite 2.
Ich kenne zwar deine Anforderung nicht im Detail, aber vermutlich würde ich in diesem Fall die Berichte aufteilen. Demnach habe ich einen Bericht mit einem statischen Header und einen zweiten Bericht mit deinem reduzierten Header. Wenn du einen Ausblick gibst, warum du die von dir angesprochene Anforderung brauchst, kann man ggf. nochmal nach Alternativen suchen.
Experimentell könnte man auch den Kopf komplett in den Textkörper schieben und diesen als Überschrift einer Tabelle verwenden. Dort könnte man die statischen Zeilen mit den Eigenschaften “KeepWithGroup = After” und “RepeatOnNewPage = true” so einstellen, dass die Überschriften auf jeder Seite gedruckt werden. In einem solchen Fall kann man alle Zellen einer Zeile zusammenführen und dann per Rechtsklick ein Rechteck einfügen. Dort kann man sich dann austoben. Wenn man zwei Überschriftszeilen (Rechtecke als Tabellenkopf) macht, kann man die statischen Zeilen auch generisch per Bedingung (Hidden Property) einblenden und ausblenden. Die Tabelle muss dann aber so aufgebaut werden, dass auf die statischen Zeilen eine Gruppe folgt (mehrere angrenzende Gruppen gehen nicht). Die Gruppe kann dann beliebig viele Untergruppen haben. Das bedeutet dann, dass die komplette Tabelle den gesamten Berichtsdruck abdecken muss (wäre aber ggf. ein Versuch wert). Eine Einschränkung gibt es auf jeden Fall: Auf die PageNo kann man im Textkörper nicht zugreifen. Dafür muss man sich dann überlegen, ob die nicht irgendwo im Kopf oder Fuß platziert werden muss.
]]>Du kannst versuchen, den Kopf auf der ersten Seite genauso groß zu machen, wie du ihn für die zweite Seite benötigst. Damit dann keine leere Stelle auf der ersten Seite entsteht, verschiebst du so viele Elemente aus dem Textkörper in den Kopf der ersten Seite. Das geht allerdings nur, wenn das keine Gruppenelemente sind (z.B.: Tabellen). Das geht nur mit statischen Elementen, wie Textboxen. Die Elemente können per Set/GetData in den Kopf übertragen werden (falls notwendig)
Ansonsten sollte man andere Lösungsansätze suchen (2 Berichte, ohne den Kopfbereich arbeiten und stattdessen Kopfzeilen aus Listen und Tabellen verwendet, …).
Falls du da mehr Hilfe benötigst, kannst du deine Frage im deutschen NAV Forum msdynamics.de stellen. Da gibt es viel Know-How und dann kann man auch spezifischer auf dein Problem eingehen.
]]>Hi Hermann,
a) Query können Werte nicht negieren oder positiv darstellen. Soweit ich weiß geht das auch nicht über die generischen Diagramme.
b) Filterungen sind auf alle Felder der Tabelle oder der jeweiligen Query möglich (http://robert-dynamicsnav.de/wp-content/uploads/2016/10/Queries2_11_QueryEinrichtungGenerrischesDiagramm.jpg). In diesem Fall habe ich somit einen direkten Filter auf das Feld SUM_Amount_LCY gesetzt. Den Namen habe ich in der Query für dieses Feld hinterlegt, bzw. der Standard hat dies vorgegeben.
c) Das ist mit Queries nicht machbar.
Zwischentabellen wären eine Lösung, aber nach meiner Meinung nach nicht die Beste. Wenn du dich in SQL auskennst, bzw. SQL Skripte schreiben kannst, dann kannst du auch deine Query zu einer SQL View machen. Diese SQL View kannst du in Dynamics NAV anzeigen, wnen du eine neue Tabelle anlegst und diese mit dem gleichen Namen + der Eigenschaft “LinkedObject” = “Yes” hinterlegst.
Dann hast du eine Tabelle, die dann all deine Anforderungen erfüllen kann:
a) in einer SQL View kannst du Werte negieren oder nur positiv darstellen
b) Du kannst dynamische Filter setzen
c) Zeiträumen kannst du ebenso variabel deklarieren
Mehr dazu findet man hier:
– LinkedObject: http://www.msdynamics.de/viewtopic.php?t=2008 / https://msdn.microsoft.com/en-us/library/dd339076.aspx / https://msdn.microsoft.com/en-us/library/dd338595.aspx
– SQL Views: http://techblog.byllemos.com/2008/05/using-sql-views-in-navision/ / https://dynamicsuser.net/nav/b/waldo/posts/how-to-display-an-sql-server-view-in-microsoft-dynamics-nav
VG
Robert
vielen Dank erst mal für die Arbeit, die Du dir für uns alle machst.
Ich habe mal einen Query für ein Diagramm erstellt und bin an Grenzen gestossen:
Fragestellung / Anzeige: 10-20 Kreditoren mit dem größten Einkaufswert in Zeitraum
Poblem: a) ich hätte die Werte gern positiv dargestellt
b) Ich weiss nicht, wie ich Query so einen Filter setzen soll. Der Diagramm-Filter passt auch nicht
c) wie kann ich einen variablen Zeitraum verwenden ?
Oder muss ich hier doch mit einer Zwischentabelle arbeiten ?
Grüße
ATLAN / Hermann Schubert
Hi,
eigentlich wird das über die Sichtbarkeiten der beiden Köpfe gesteuert. Du musst die Hidden Eigenschaft des Kopfes (erste Seite) auch auf PageNo > 1 setzen. Also den ersten Kopf immer ausblenden, wenn es nicht die erste Seite ist. Umgekehrt dann für den Kopf der zweiten Seite.
Nun muss man dafür sorgen, dass die Dokumentgruppe (bei mir Document) nach Belegnr. und Kopienr. gruppiert und die Eigenschaft ResetPageNumber bei der Gruppe aktiviert ist. Die Seitennummer muss bei einer Kopie auch wieder bei 1 anfangen. Das ist oben beschrieben, aber ich gruppiere nicht nach der Kopiennr. Da sollte der Unterschied zu deinem Beleg liegen.
]]>Hi Daniel,
danke für deine Meinung. Du sprichst da einige wichtige Punkte an auf die ich hier gar nicht eingegangen bin. Ich kann natürlich auch in NAV die SOAP XML Anfrage ausprogrammieren und auch die Antwort lesen. Das hat auch seinen Charme.
Visual Studio hat neben der Web Reference Funktion auch ein paar nennenswerte Nachteile. Dazu gehört auch, dass man bei Fehlern schwer prüfen kann, welche genaue XML Anfrage gestellt wurde und wo der Fehler genau liegt. In NAV ließe sich die Anfrage beispielsweise in eine Datei schreiben um diese dann zwecks SOAPUI oder ähnlichen Programm zu prüfen. Auch ist die Umwandlung zu Proxyklassen in Visual Studio nicht perfekt! Zusätzlich benötigt man die DLL auch im Server oder Clientverzeichnis von Dynamics NAV (je nach Anforderung).
Man darf aber nicht vergessen, dass die integrierte Funktion der Web Reference schon ziemlich komfortabel ist. Das bietet mir NAV nicht. Da benötige ich schon einiges an Code um das entsprechend abzubilden.
Für welchen Weg man sich auch entscheidet, bleibt letzten endlich jedem selbst überlassen. Ich persönlich finde die Lösung als Klassenbibliothek aber definitiv nicht schlecht. Dabei berücksichtige ich auch, dass so wenig Business Logik in Visual Studio stattfindet und nur die Aufrufe der Webservicefunktionen von Visual Studio durchgeführt wird. Auch die Übertragen von Tabellen ist kein Problem, man kann schließlich auch eigene Klassen mit den notwendigen Werten in seine Klassenbibliothek integrieren und diese als Listparameter mit NAV austauschen. Das ist dann stark vergleichbar mit der Parameterübergabe eines XMLPort. Deine Argumente kann ich aber dennoch nachvollziehen!
Mein Fazit: Es gibt hier kein Schwarz oder weiß! Beide Varianten haben Vor- und Nachteile.
VG
Robert
Wenn man weiß wie, dann ist C/AL nicht die falsche Wahl. Visual Studio bietet zwar durch die Web Referenz eine komfortable Möglichkeit, aber benötigt wird sowas nicht. Zudem wird die Codepflege deutlich erschwert und selbst für kleine Anpassungen muss man ständig die DLL neu generieren.
Im Standard gibt es bereits in der Codeunit 1297 einen Webservice Aufruf, den man für seine zwecke auch umfunktionieren kann.
Ich habe bspw. den Response in ein XMLPort übergeben und dies zu validieren und direkt eine Tabelle zu füllen. Sowas wäre mit einer externen DLL nur schwer oder gar nicht möglich.
Ich denke auf den ersten Blick ist es im VS schon leichter weil vieles automatisiert ist und wenn man von C/AL nicht so die Ahnung hat dann sowieso. Aber wenn es möglich ist, dann sollte man schon in NAV bleiben.
Danke für die ausführliche Herleitung und grundsätzliche Erläuterung des Verhaltens.
]]>Dann wäre ich geneigt von einem konzeptionellen Fehler zu sprechen. NAV ist derzeit noch alles andere als auf “dumme” GUI und Batchbetrieb ausgerichtet.
]]>Das ist leider nicht möglich. Deswegen ist das ja auch so ein großes Problem, wenn in dieser Form programmiert wird. Das führt im schlimmsten Fall zu komplett falschen Daten.
]]>Das Problem besteht meines Wissens hier genauso.
]]>Mir ging es hier nur um das Aufzeigen dieses Problems. Lösungsmöglichkeiten gibt es hier sicherlich einige und mein Tipp ist ein Weg um das Problem zu lösen. Wie man vorgehen sollte, hängt sicherlich vom direkten Fall ab!
]]>zu “Füge den Code stattdessen in den OnInsert, OnModify, OnRename oder OnDelete ein. Hier funktioniert auch der Rollback auf anderen Record Variablen.”
Dies steht dann in Widerspruch, dass Businesslogik und GUI getrennt werden sollten. Klar ist das schon auch weiterhin irgendwie machbar, aber schön ist anders.
Guter Beitrag
]]>Hallo Marcel,
ich kann nicht für alle Webservices sprechen. Meine Erfahrungen sind allerdings folgende:
a) Zugangsdaten müssen im Konstruktor als Parameter angegeben werden.
b) Zugangsdaten müssen bei spezifischen Aufruf einer Funktion des Webservices übergeben werden.
Bei beiden Varianten ist es möglich, dass die Zugangsdaten per String übertragen werden oder das man eine Klasse erstellen und mit den Zugangsdaten füttern muss. Die Webservice Definition sollte eigentlich immer öffentlich sein, ohne das Zugangsdaten angegeben werden. Damit kann man auch immer die Webservice Referenz in Visual Studio hinzufügen.
Falls du das nicht so einfach heraus bekommst, wie das bei deinem Webservices funktioniert, dann musst du die Dokumentation vom Webservices Veröffentlicher anfragen.
]]>Das hast du falsch verstanden 🙂 Die Reportlogik wird nicht über den Haufen geworfen, daher ist es meiner Meinung nach ein guter Plan, den Standard auch zu nutzen und dort Kompetenzen aufzubauen.
In dem Satz ist etwas Sarkasmus versteckt, da die Classic Berichte abgelöst worden sind!
VG
Robert
Grüße
]]>Der Hauptgrund ist meiner Meinung nach der Folgende:
NAV lässt keine Web Referenz zu, sowie es in Visual Studio der Fall ist. Dadurch ist die Integration m.E. viel schwieriger als es in Visual Studio ist.
Des Weiteren gibt es ebenfalls zu viele .NET Restriktionen – Vjeko hat das schon gut beschrieben (http://vjeko.com/top-10-things-i-miss-in-net-interoperability-in-nav-2013) – vieles gilt auch für NAV 2016 noch!
Zu guter letzt habe ich mich auch mit dem Beitrag von Vjeko befasst, indem er einen NAV Page Web Service konsumiert. Da wird es sehr schnell kompliziert. Man muss sich einfach mal das Objekt herunterladen (http://www.mibuso.com/dlinfo.asp?FileID=1472). Ich halte eine kleine Klassenbibliothek für wesentlich einfacher, aber das ist nur meine subjektive Meinung.
]]>Danke 🙂 Ich geb mein Bestes!
]]>