PMS32 Online- Hilfereferenz

Informationen zum PMS32 Serviceupdate - 1.0.03.0014


1.) BDE Bearbeitung - Recht "Neuanlage" auf den Button "Einstellungen" ...
2.) Bestellwesen - Erstellen der Datei EB01 für Bestellung bei SIEMENS ...
3.) Reportbearbeitung: Das Speichern von Reports funktioniert unter bestimmten Umständen nicht korrekt. ...
4.) SYSTEM - Einstellung des temporären Verzeichnisses geändert... ...
5.) Vorgänge: Ermittlung von Listenpreisen bei Mengenänderung von 0 auf >0 bei deaktivierter Onlinekalkulation ...


BDE Bearbeitung - Recht "Neuanlage" auf den Button "Einstellungen" ...

Um Änderungen an den Einstellungen der BDE Daten (J4002) zu verhindern, wurde der Button: "Einstellunegn" in der Maske J4001 auf das Recht "Neuanlage" gelegt.

An den Seitenanfang
Bestellwesen - Erstellen der Datei EB01 für Bestellung bei SIEMENS ...

Bei der Erstellung der Daten für EB01 (SIEMENS) wird eine Zwischentabelle im Startverzeichnis abgelegt. Dies führt bei Multiuserumgebung auf einem Startverzeichnis zu Fehlern.

An den Seitenanfang
Reportbearbeitung: Das Speichern von Reports funktioniert unter bestimmten Umständen nicht korrekt. ...

Durch das Wiederherstellen einiger Variablen beim Verlassen der grafischen Reportbearbeitung konnte es vorkommen, dass der vorherige Speicherstand wiederhergestellt und somit die aktuellen Änderungen überschrieben wurden. Dieser Fehler ist hiermit behoben.
Außerdem wurde das direkte Bearbeiten in der Maske X2101 Reportauswahl unterbunden. Die Datensätze werden nun durch die Bearbeiter nicht mehr gesperrt.

An den Seitenanfang
SYSTEM - Einstellung des temporären Verzeichnisses geändert... ...

Ab dieser Version werden die Verzeichnisse TEMP\ , LOG\ und RES\ sofern PMS32 auf einem Netzlaufwerk gestartet wird, auf die lokalen Maschine verlegt. Die Einstellung kann in der Datei PMS32.PTH im Bereich für jedes Terminal vorbelegt werden.

Wenn PMS32 auf einem gemapten Netzlaufwerk gestartet wird, werden die oben genannten Verzeichnisse in folgenden Verzeichnissen angelegt:
1.) Ist unter dem Terminal ein Eintrag für cTmpDir vorhanden und existiert das Verzeichnis...
2.) Ist das Windows-Benutzer-Tempverzeichnis (SET TEMP...) auf einem FIXED Laufwerk abgelegt dann dort...
3.) Es wird das "erste" beschreibbare FIXED Laufwerk ermittelt...
4.) Kann unter Windows-Benutzer-Tempverzeichnis geschrieben, gelesen, neuangelegt und gelöscht werden...
5.) Es wird der Startpfad genommen

Beispiel bei einem Start auf einem gemapten Laufwerk:
1.) Es ist kein Verzeichnis angegeben
2.) Ablage unter dem Windows-Benutzer-Tempverzeichnis:
C:\Dokumente und Einstellungen\\Lokale Einstellungen\Temp\PMS32\TEMP\_SXC067...
C:\Dokumente und Einstellungen\\Lokale Einstellungen\Temp\PMS32\LOG\
C:\Dokumente und Einstellungen\\Lokale Einstellungen\Temp\PMS32\RES\

Änderung der Datei PMS32.PTH
Möchten Sie ein "schnelles" lokales Laufwerk vorgeben, so kann dies in der Pfaddatei PMS32.PTH für jedes Terminal vorgenommen werden.
Dafür sind die Einträge unter wie folgt zu ändern:

      
            cPrgver="1.0.03.0900.0320"
            cTmpdir="C:\USER\TEMP\"            */ Beispiel eines erweiterten Eintrags
            cWelcome=""            
      <>
      
            …
      <>
<>
In der PMS32.PTH muss dann für jedes Terminal ein Eintrag erzeugt werden, falls gewünscht. Der angegebene Pfad muss EXISTIEREN und ALLE Rechte für den Benutzer haben!

Begründung:
Diese Änderung wurde vorgenommen, da PMS32 verstärkt Daten auf der lokalen Festplatte zwischenspeichert um schnellere Berechnungen durchführen zu können. Wird die Applikation nun auf einem Netzlaufwerk gestartet, so werden alle als "lokal" definierten Zwischentabellen auf dem Netzlaufwerk gespeichert. Damit wird die quasi "lokale" Zwischentabelle wieder im Netzwerk gespeichert, was die Performance eher verschlechert denn verbessert. Auch werden in den Zwischentabellen nicht unbedingt alle benötigten Indizes, für weitere Berechnungen, gesetzt. Damit werden nachfolgende Berechnungen wie LOCATE, SELECT SQL etc. langsamer, wie wenn die Zwischentabelle auf einem lokalen Laufwerk liegen würde.
Datenstrom im ungüstigsten Fall:
Datenbank => Netzwerk => "lokaler Cursor" => Netzwerk => Zwischentabelle => Netzwerk => "lokaler Cursor" => Berechnung
Datenstrom bei lokalen Zwischentabellen:
Datenbank => Netzwerk => "lokaler Cursor" => Zwischentabelle => "lokaler Cursor" => Berechnung

Noch ein paar Infos zur Geschwindigkeit von PMS32…
In zukünftigen Versionen werden Daten, die berechnet werden müssen z.B. "Kalkulation, Disposition, Vertragsberechnung, MAWI-Buchungen, Vertragsberechnungen, CAE-Listenabgleich, etc…" über die Namespace von PMS32 ausgeführt. Damit werden die zu berechnenden Daten per SQL aus der Datenbank geholt und lokal berechnet. Nach der Berechnung werden die lokalen "Cursor" (Zwischentabellen) wieder in die Datenbank zurückgeschrieben. Die lokalen "Cursor" sind dann Zwischentabellen, die im temporären Verzeichnis des Namespace Servers abgelegt werden. Damit sieht der Datenstrom für das "Holen" der Daten in etwa so aus:
Datenbank => Netzwerk => lokaler SQL-Cursor => lokale Zwischentabelle
Nachdem die Daten lokal vorliegen kann die Berechnung erfolgen, was zu ca. 90% auf den bisherigen lokalen Daten erfolgt. Werden weitere Daten aus der Datenbank benötigt, so werden diese sukzessive an die lokalen Zwischentabellen angehängt. Datenstrom in diesem Fall:
Datenbank => Netzwerk => lokaler SQL-Cursor => lokale Zwischentabelle
Nach der Berechnung werden die geänderten Zwischentabellen in die Datenbank im Netzwerk zurückgeschrieben, was nur in diesem Fall zu einer Netzwerklast führt. Der Datenstrom ist in diesem Fall:
Lokale Zwischentabelle => lokaler SQL-Cursor => Netzwerk => Datenbank
Da alle Berechnungen lokal durchgeführt werden, wird auf eine großangelegte Indizierung der lokalen Tabellen zur schnelleren Bearbeitung verzichtet. Die Indizierung der lokalen Tabellen würde meist länger dauern als die komplette Berechnung, auch wenn die Berechnung in sich dann etwas länger dauert. Teilweise werden zur Optimierung der lokalen Tabellen Indizes eingeführt, wenn eine bestimmte Satzzahl der lokalen Tabelle überschritten wird. Dies wirkt sich aber nur bei großen Datenmengen aus, die meist nicht erreicht werden.

Beispiel: Kalkulation eines Vorgangs mit ca. 8200 Positionen und einer Datenbankgröße von E10~70.000 und E11/E12~1.400.000 Datensätzen über ein 100MBit Netzwerk auf einer "langsamen" virtuellen Maschine unter Windows XP. Komplette Kalkulationszeit ca. 50 Sekunden. Das sind ca. 6 ms / Position.

Durch dieses Vorgehen, wird der lokale Rechner weitaus stärker belastet wie in der Vergangenheit. Die CPU- Auslastung kann bei diversen Berechnungen für "längere Zeit" bis zu 100% betragen. Auch das "Lesen" und "Schreiben" der Daten wird das Netzwerk für den entsprechenden Zeitraum stärker belasten wie bisher. Bei der momentanen Kalkulation liegt die Netzwerklast bei ca. 8-10% über die gesamte Zeit der Kalkulation. Danach werden Netzwerklasten bis zu 70% zustande kommen! Mit der "ersten" Auslieferung der Version 1.0.04 werden NICHT ALLE Buchungsfunktionen in die Namespace übertragen sein. Jedoch werden die verbleibenden Buchungsfunktionen in weiteren Versionen in die Namespace übertragen. Das wichtigste ist, dass alle Buchungs- bzw. Berechnungsfunktionen ohne die PMS32 Oberfläche auskommen, sodass diese auch auf einem zentralen Rechner durchgeführt werden könnten.

An den Seitenanfang
Vorgänge: Ermittlung von Listenpreisen bei Mengenänderung von 0 auf >0 bei deaktivierter Onlinekalkulation ...

Bei umfangreichen Baugruppen und Baugruppenpositionen in PMS-Datenbeständen in Zusammenhang mit umfangreichem Positionslistenumfang, kann es bei aktivierter Onlineberechnung zu Wartezeiten bei Mengenänderungen kommen.
Eine bessere Performance wird bereits erreicht, wenn die Mengenänderung in der Maske der Positionskalkulation E1170 erfolgt.
Die Deaktivierung der Onlineberechnung führt auch zu einer kürzeren Wartezeit.
Bei deaktivierter Onlineberechnung in Vorgängen wurde jedoch bei einer Mengenänderung auf 0 der Einzel- und Gesamtpreis auch auf 0 gesetzt.
Wurde die Position nach Listenpreisen berechnet und die Menge wieder auf einen Wert größer 0 geändert, erfolgte keine Aktualisierung des Verkaufspreises auf den Listenpreis.
Nun wird der Listenpreis herangezogen, sodass bei der Mengeneingabe sofort der Positionspreis erkennbar wird.
Dabei wird die Position nicht neu berechnet !!!
Das bedeutet, dass zur Ermittlung aller Kalkulationsdaten und des Deckungsbeitrages zwingend eine Neuberechnung erfolgen muss.
Die Änderung verbessert lediglich den Informationsgehalt, bei Mengenänderungen von 0 auf größer 0.
Diese erfolgt in der praktischen Anwendung oft dann, wenn mit Vorgängen oder Positionen als Vorlage gearbeitet wird, in denen die Positionsmenge der Vorlage 0 sind.
In diesen Vorlagen ist jedoch darauf zu achten, dass die Listenpreise gepflegt werden.

An den Seitenanfang

Dateiversion:1.0.03.0900.0295 - H.U.DD.V1.V2 - 26.05.2010
Senden Sie Ihren Kommentar zu diesem Thema an das Entwicklungsteam von PMS32
Weitere Informationen finden Sie unter der aktuellen PMS32 WEB-Hilfe
Die Informationen dieser Mitteilung sind vertraulich und nur für Sie bestimmt. Unbefugtes Weiterleiten, Veröffentlichen, Kopieren usw. sind untersagt und werden gerichtlich verfolgt.
© PMS Compelec GmbH 2010 el-Projekt®