Mysteriöse Captionänderung durch Personalisierung

Ich hatte mal folgendes Kuriosum unter NAV 2009 R2 RTC:

Ein User meldete mir einen Tippfehler in einer Spaltenüberschrift einer Listpage – es fehlte ein Buchstabe.

Gut, was macht man üblich in so einer Situation? Man prüft, ob die Caption direkt in der Page (CaptionML) gesetzt ist – dann korrigiert man sie dort. Ist dort keine explizite Caption gesetzt, welchselt  man in die SourceTable der Page und korrigiert die CaptionML im dazu gehörigen Feld.

Nur, es gab nichts zu korrigieren: Die CaptionML in der Page war gesetzt, aber die Caption hatte keinen Tippfehler! Ich schaute mir die Page zur Sicherheit im RTC an, und dort war, wie erwartet, alles in Ordnung.

Offensichtlich muss sich der User vertan haben. Aber Pustekuchen: als ich vor seinem Rechner stand, sah auch in den Tippfehler.

Tatsächlich hatte niemand außer diesem einen User dieses Problem, und auch nur im RTC. In so einer Konstellation ist es sehr wahrscheinlich, dass NAV sich bei der Page-Personalisierung des Users „verschluckt“ hat.  Nach einem Klick auf „Standardeinstellungen wiederherstellen“ in der Page war das Problem auch tatsächlich behoben.

Nur – wie genau verschwand dieser eine Buchstabe? Warum nur bei diesem einen User? Die Page wurde 2 Jahre vorher zuletzt geändert. War es damals die Korrektur des Tippfehlers? (Hier hätte mir ein gut gefüllter Documentation Trigger geholfen, aber nein …)

Meine Vermutung ist, dass der Tippfehler mal (vor über 2 Jahren) wirklich bestanden hat, und nur dieser eine User schon damals die Page personalisiert (etwa: Spalten ein-/ausgeblendet) hat. Diese Annahme zu testen ist kein Hexenwerk – lest davon mehr in einem meiner nächsten Artikel (wird an dieser Stelle verlinkt).

Natalie Karolak
nataliesnav.de
www.msdynamics.de

Welche Nummer hat Optionswert X?

Optionswerte in NAV werden in der C/AL-Programmierung als kommagetrennte Strings in den den Eigenschaften von Tabellen- und Page-Feldern hinterlegt. Der erste Wert entspricht dem nummerischen Wert 0, der nachfolgende 1, und so weiter.

Manchmal ist es bei der Programmierung notwendig zu wissen, welcher Nummer ein ganz bestimmter Optionswert entspricht. Das kann man selbst nachzählen – ist aber bei vielen Optionswerten aber schnell mühselig und fehlerträchtig.

Wie also löst man das Problem produktiver und eleganter? Ansätze gibt es sicherlich viele – und ich nutze diesen hier:

  1. Kopiert den gesamten OptionString bzw. OptionCaption in ein leeres Word-Dokument
  2. Öffnet in Word mit Strg + H die „Suchen und Ersetzen“-Maske.
  3. „Suchen nach“ = „,“
  4. Setzt den Cursor in „Ersetzen durch“.
  5. Drückt Button „Erweitern“, dann Button „Sonderformat“, dann „Manueller Zeilenumbruch“. (Dies wird „^l“ als „Ersetzen durch“ eintragen.)
  6. Drück Button „Alle ersetzen“.

Nun steht jeder Optionswert in einer separaten Zeile. Wir sind noch nicht fertig!

  • Als nächstes blenden wir in Word die Zeilennummern ein: Seitenlayout –> Zeilennummern –> Fortlaufend.

Nun steht vor jedem Optionswert die Zeilennummer. Von diesem Wert zieht ihr 1 ab, und schon habt ihr den Index. Steht also euer gesuchter Optionswert in Zeile 5, hat er den Index 4.

Habt ihr eine andere Lösung? Ich freue mich auf eure Kommentare.

Natalie Karolak
nataliesnav.de
www.msdynamics.de

Produkt- und Funktionsüberblick für Microsoft Dynamics NAV 2015

Kennt ihr schon den Produkt- und Funktionsüberblick für Microsoft Dynamics NAV 2015?

NAV2015

Mir ist dieses Dokument deshalb einen Eintrag wert, weil

  • Microsoft ein deutschsprachiges Dokument zur Verfügung gestellt hat (wir erinnern uns: das passiert leider immer seltener)
  • es einen schönen Überblick über die Unterschiede zwischen Starter Pack und Extended Pack bietet.

Ihr könnt es hier downloaden – und natürlich bei Microsoft.

Natalie Karolak
nataliesnav.de
www.msdynamics.de

Leere Seite(n) im NAV-Report

Eben noch habt ihr nur eine Kleinigkeit an einem Berichtslayout in Microsoft Dynamcis NAV geändert, da druckt der RDLC-Bericht plötzlich leere Seiten. Woran liegt das?

1. Jede zweite Seite ist ganz oder nahezu leer

In der Praxis (und ganz besonders unter NAV 2009 (RDLC 2005), siehe unten!) dürfte der häufigste Grund plötzlich leere Seiten die versehentliche Verbreiterung des Textkörpers sein (im nachfolgenden Bild ist neu geschaffene Bereich rot gekennzeichnet):

Zu breit gezogener Textkörper

Zu breit gezogener Textkörper

Um keine leeren Seiten zu erzeugen, müsst ihr den Textkörper an dessen rechten Rand greifen und so weit wie möglich nach links ziehen:

Textkörper nach Reduzierung der Breite

Textkörper nach Reduzierung der Breite

Aber was veranlasst den Renderer überhaupt zur zweiten Seite?
Antwort: Textkörper + Seitenränder >  Breite des Papierformats.

Beispiel: Eine DIN A4-Seite im Hochformat ist 21 cm breit.  In Visual Studio können wir die Breite des tatsächlichen Druckbereichs in Form des RDLC-Textkörpers frei wählen. Legen wir ihn nun größer als 21 cm fest (selbst, wenn es nur ein µm mehr ist, und selbst wenn wir nichts darin andrucken!), stellt der Renderer fest, dass der Inhalt nicht auf eine Seite passt – und hängt rechts die fehlenden Zeichen auf einer weiteren Seite an. Das heißt aber auch: Überragt nur ein Leerraum die erste Seite, erscheint die nächste Seite leer, oder vielmehr erscheint  jede zweite Seite leer.

Meist muss der Druckbereich in Visual Studio noch kleiner gewählt werden, da in den Berichtseigenschaften Seitenränder definiert worden sind. Haben wir z. B. einen linken Rand von 2 cm und einen rechten Rand von 1 cm, bleiben uns 21 minus 2 minus 1 = 18 cm. Das hießt: breiter als 18 cm darf der Textkörper in diesem Fall nicht definiert sein.

Zum Glück ist es seit NAV 2013 (RDLC 2008) schon etwas weniger einfach, leere Seiten durch einen versehentlich breiter gezogenen, aber rechts leeren Textkörper zu erzeugen: Dies wird seitdem durch die neue (und standardmäßig aktivierte) RDLC-Berichtseigenschaft ConsumeContainerWhiteSpace verhindert.

ConsumeContainerWhitespace

ConsumeContainerWhitespace

Ich finde die deutsche Erklärung darunter nicht ganz so glücklich. Sie bedeutet für uns eigentlich nur: Der leere Bereich rechts, welchen ich im ersten Screenshot noch rot markiert habe, wird quasi ignoriert. Aber: wäre der rote Bereich gefüllt gewesen, hätten wir trotzdem eine zusätzliche Seite erzeugt. Schön an der gesetzten Eigenschaft ist, dass sie uns in jeden Fall überflüssige Leerräume ganz am Ende der Seite abschneidet: siehe auch nächster Punkt.

2. Und wenn ein ggf. mehrseitiger Bericht nur eine einzige, leere Seite ganz zum Schluss produziert?

In NAV 2009 (RDLC 2005) solltet ihr das untere Ende des Textkörpers immer so weit es geht nach oben ziehen, um zum Schluss keinen Leerraum zu drucken, der ggf. nicht mehr auf die letzte gefüllte Seite passt.

Ab NAV 2013 steht es euch frei, dies ebenfalls zu tun, sofern die o.g. RDLC-Berichtseigenschaft ConsumeContainerWhitespace nicht gesetzt ist.

Natalie Karolak
nataliesnav.de
www.msdynamics.de

Anlagenbuchhaltung – Posten stornieren

Neben dem Transaktionsstorno, das eine komplette Buchung als storniert setzt, können in Microsoft Dynamics NAV 2009 Classic, einzelne Anlagenposten einer Transaktion mit „Posten stornieren“ gegengebucht werden.

Der Unterschied besteht hier in einer Gegenbuchung, die den stornierten Anlagenposten mit „Storno“ kennzeichnet. In den Sach- und übrigen Posten werden Gegenbuchungen erzeugt, die kein Storno-Kennzeichen erhalten.

Der Kniff bei der Sache ist, die Buchung so zurückzudrehen, wie sie ursprünglich gebucht wurde. Dafür schaut man ggf. bei Navigate vorbei und schaut sich an, welche Posten mit welchen Werten und Dimensionen vormals gebucht worden sind.

Hier die als Beispiel die ursprüngliche Buchung eines Anschaffungswertes im „Anlagen Fibu Buch.-Blatt“:

Buchen der Anschaffungskosten für die Anlage

Buchen der Anschaffungskosten für die Anlage

Die Buchungsroutine erzeugt die entsprechenden Sach-, MwSt.- und Anlagenposten. Wird auf diesen gebuchten AnIagenposten die Funktion „Posten stornieren“ ausgeführt, so werden in dem entsprechenden Anlagenbuchblatt, nur die Informationen des Anlagenpostens mit dem negativen Betrag ins Buchblatt übertragen, sowie das Feld „Anlagenstornoposten Lfd. Nr.“ ausgefüllt.

Da in diesem Beispiel, die Fibu-Integration eingeschaltet ist, bedeutet dies, dass sich die vorbereitete Gegenbuchung im „Anlagen Fibu Buch.-Blatt“ wiederfindet. Im anderen Fall wäre dies das „Anlagen Buch.-Blatt“.

Der User ist nun gefordert, die Buchblattzeile richtig zu ergänzen.

Buchungszeile nach der Ausführung "Posten stornieren"

Buchungszeile nach der Ausführung „Posten stornieren“

Im „Anlagen Fibu Buch.-Batt“ müssen noch das Gegenkonto und die Geschäfts-, Produkt-, MwSt.-Geschäfts- und MwSt.-Produktbuchungsgruppe eingetragen werden. Auch der Betrag muss auf den Bruttobetrag angepasst werden.

Buchen des Stornos nach Überarbeitung der vorgeschlagenen Buchungszeile

Buchen des Stornos nach Überarbeitung der vorgeschlagenen Buchungszeile

Nach dem Buchen des „Anlagen Fibu Buch.-Blattes“, werden die stornierten Anlagenposten in die Anlagenstornoposten verschoben. Sie sind in den normalen Anlagenposten nicht mehr sichtbar.

Auswahl der Stornoposten

Auswahl der Stornoposten

Stornoposten nach "Posten stornieren"

Stornoposten nach „Posten stornieren“

Sonja Neumann
www.datenkultur.de

Anlagenbuchhaltung – Transaktion stornieren

Beim Stornieren von Anlagenposten in Microsoft Dynamics NAV 20009 Classic, über die Funktion „Transaktion stornieren“, kann es zu Fehlberechnungen der AfA-Tage kommen oder die AfA wird ggf nicht neu berechnet.

Wer über eine Entwicklerlizenz verfügt, kann ohne Gewähr folgende Änderungen durchführen:

In der Codeunit 5616 „Depreciation Calculation“ in der Funktion „SetFAFilter“ am Ende noch einen Filter auf das Feld „Reversed“ = FALSE setzen. Und in der Tabelle „FA Ledger Entry“ den entsprechenden Schlüssel um das Feld „Reserved“ erweitern.

Die Änderungen haben den Effekt, dass die durch das „Transaktionstorno“ stornierten Posten bei der Berechnung der AfA-Tage und AfA-Beträge unberücksichtigt bleiben und dementsprechend „neu“ kalkuliert werden.

Sonja Neumann
www.datenkultur.de

Transaktion stornieren – NAV 2009

Das Transaktionsstorno in Navision Dynamics NAV 2009 Classic dient dazu, Buchungsblattposten zu stornieren oder zu korrigieren.

Das Stornieren ganzer Transaktionen kann aus verschiedenen Bereichen wie Debitoren, Kredtioren, Journale, Banken, Anlagen und Journale aufgerufen werden. Demzufolge können mit der Funktionalität die entsprechenden Posten storniert werden wie, Sachposten, Kreditoren-/Debitorenposten sowie die dazugehörigen Detailposten, MwSt-Posten, Bankposten und Anlagenposten.

Voraussetzung für die Verwendung der Funktionalität ist das Buchen über Fibu-Buchblätter. Bei Buchungen über Belege ist die Ausführung der Funktion nicht möglich.

Weitere Voraussetzungen sind, dass das Feld „Buch.-Blattname“ im Fibu-Journal ausgefüllt ist. Die zu stornierenden Debitoren-, Kreditoren-, Bankposten, etc. dürfen nicht ausgeglichen sein. Insbesondere Bankposten dürfen nicht durch eine Abstimmung geschlossen oder mit Scheckposten verknüpft sein.

Des Weiteren muss der Gesamtbetrag der Sachposten gleich null sein, die Buchung darf keine Artikelposten enthalten und es dürfen keine bereits stornierten Posten nochmals storniert werden.

Ein Transaktionsstorno für Anlagenposten ist nicht möglich, wenn die Anlagen verkauft wurden oder der Storno einen negativen Buchwert ergibt.

Ebenfalls sind Posten mit Datumskomprimierung vom Transaktionsstorno ausgeschlossen.

Sind bei dem Stornierungsvorgang ausgeglichene Debitoren- oder Kreditorenposten betroffen, so müssen zuvor die Ausgleiche aufgehoben werden.

Auf den entsprechenden Debitorenposten-,  Kreditorenposten-, etc. Karten findet man unter dem Button „Funktion“ die „Transaktion stornieren“. Hier beispielhaft an den Debitorenposten gezeigt.

Transaktionsstornoaufruf bei den Debitorenposten

Transaktionsstornoaufruf bei den Debitorenposten

Die Funktion sucht sich sämtliche Posten zusammen, die die gleiche Transaktionsnummer haben, wie der zur Stornierung ausgewählte Posten.

Aus diesem Grunde ist es egal, ob das Storno in den ggf. betroffenen Sachposten oder der Bank auswählt wird, letztlich sind alle zu dieser Buchung gehörenden Posten storniert.

Stornierte Posten erkennt man zunächst an dem gesetzten Flag im Feld „Storniert“ des Postens.

Storno auf Debitorenposten

Storno auf Debitorenposten

Wie hier beispielhaft an den Debitorenposten dargestellt, verweisen auch die Felder „Storniert durch Lfd. Nr.“ und „Stornierter Posten Lfd. Nr.“, die durch Ihre Einträge aufeinander.

Beim Stornieren eines kompletten Journals, wird ebenfalls die Funktion „Transaktion stornieren“ ausgeführt.

Transaktionsstorno für Journale

Transaktionsstorno für Journale

Nach der Stornierung kann für die korrekte Buchung ins Fibu-Buchblatt eingetragen und gebucht werden.

Sonja Neumann
www.datenkultur.de