Ansicht
Dokumentation

SAPDBPNPCE - Log. Datenbank PNPCE : Datenbankprogramm

TXBHW - Original Tax Base Amount in Local Currency   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Verwendung

Die Logische Datenbank PNPCE unterstützt die Auswertung von Personalstammdaten. Sie umfaßt die Funktionalität der Logischen Datenbank PNP und bietet darüber hinaus weitere Auswertungsmöglichkeiten. Für alle Neuentwicklungen sollte daher die logische Datenbank PNPCE und nicht mehr die PNP verwendet werden.

Die im Vergleich zur PNP erweiterte Funktionalität umfaßt im wesentlichen die Auswertung von Mehrfachanstellungen, d.h. die Möglichkeit der gruppierten Auswertung mehrerer Verträge/Personalnummern einer Person. Dazu stehen neue Events 'GET PERSON' und 'GET GROUP', sowie eine erweiterte Syntax für das INFOTYPES-Statement (Zusatz AS PERSON TABLE) zur Beschaffung von Infotypdaten zur Verfügung. Die Nutzung dieser neuen Funktionalität ist optional, d.h. daß ein PNPCE-Report, der die neuen Events und den Zusatz zum INFOTYPES-Statement nicht benutzt, in einem PNP-kompatiblen Modus läuft. Da die PNPCE aber ausserdem über ein verbessertes Selektionsbild verfügt, profitiert davon jeder Report, auch wenn er die Funktionalität zur Auswertung von Mehrfachanstellungen nicht benutzt.

Voraussetzungen

Ein Report, der die PNPCE nutzen möchte, muß diese in seinen Programmattributen unter 'Logische Datenbank' eintragen.

Ferner muß im Report die Struktur PERNR durch die Anweisung 'TABLES PERNR' deklariert werden. Eine weitere Verwendung der Struktur PERNR ist jedoch nur eingeschränkt erlaubt. So ist die Verwendung des Events 'GET PERNR' verboten. Stattdessen ist das Event 'GET PERAS' zu verwenden. Bis auf die Komponente PERNR-PERNR werden alle anderen Komponenten der Struktur PERNR nicht mehr versorgt und haben Initialwerte. Das Programmieren auf diese Werte (mit Ausnahme von PERNR-PERNR) ist daher unzulässig.

Neben dem Event 'GET PERAS' stehen ausserdem die Events 'GET PERSON' und 'GET GROUP' zur Verfügung. Um diese nutzen zu können, müssen sie über die NODES-Anweisung deklariert werden ('NODES PERSON', 'NODES GROUP' bzw. NODES PERAS').

Begriffserläuterung

Werden die Events 'GET PERSON' und 'GET GROUP', sowie der Zusatz 'AS PERSON TABLE' zum INFOTYPES-Statement nicht verwendet, so signalisiert der Report dadurch, daß er die Funktionalität zur Auswertung von Mehrfachanstellungen nicht benötigt. In diesem Fall läuft der Report in einem PNP-kompatiblen Modus. Dieser wird in den nachfolgenden Erläuterungen PNP-Modus genannt. Im Gegensatz dazu spechen wir vom CE-Modus, wenn die Funktionalität zur Auswertung von Mehrfachanstellungen angefordert wird.

Funktionsumfang

Ablauf einer Auswertung

Das Selektionsbild der PNPCE stellt standardmäßig eine Reihe von Funktionen zur Verfügung, über die sich die Selektion der Personalnummern und Personen einschränken läßt. Diese werden in den folgenden Abschnitten näher erläutert. Unabhängig davon, ob der Report im CE- oder PNP-Modus läuft, ist der Ablauf zunächst wie folgt: Alle zur Verfügung stehenden Funktionen und Selektionsbedingungen führen zu der Selektion von Personalnummern. Wird die Sortierfunktion verwendet, so wird diese Personalnummernmenge anschließend gemäß der ausgewählten Sortierkriterien sortiert. Im PNP-Modus wird daraufhin zu jeder Personalnummer das Event GET PERAS ausgelöst.

Im CE-Modus werden zuvor zu allen selektierten Personalnummern die zugehörigen Personen ermittelt. Anschließend wird zu jeder Person das Event GET PERSON ausgelöst. In der Komponente OBJID der Struktur PERSON wird die Personen-Id angegeben. PERNR_NUM enthält die Gesamtanzahl der Anstellungen (= Personalnummern), die diese Person hat und die inkludierte Tabelle ALL_PERNRS enthält eine Liste dieser Personalnummern, unabhängig davon, ob sie tatsächlich selektiert wurden oder nicht. Für die selektierten Personalnummern wird das Flag SELECTED auf 'X' gesetzt. Für alle nicht selektierten Personalnummern ist das Flag initial. Das Flag PROCESS gibt an, ob die Personalnummer im weiteren Verlauf verarbeitet werden soll. Für alle selektierten Personalnummern ist dieses Flag standardmäßig auf 'X' gesetzt. Der Report darf dieses Flag zum Zeitpunkt GET PERSON jedoch für alle Personalnummern beliebig setzen oder löschen. Auf diesen Weg findet eine Kommunikation zwischen Report und logischer Datenbank statt, über die der Report den weiteren Ablauf steuern kann.

Im nächsten Schritt wird von der logischen Datenbank eine Gruppierung aller Personalnummern einer Person durchgeführt, die verarbeitet werden sollen (d.h. für die das Flag PROCESS gesetzt wurde). Die Art der Gruppierung kann vom Report über das Flag PNPCE_GROUPING_FROM_PAYROLL ('normale' oder Payroll-Gruppierung) und über die Parameter PNPGPRSN (Gruppierungsgrund) und PNPGPVAL (Gruppierungswert) des Selektionsbildes gesteuert werden. Zu jeder ermittelten Gruppe von Personalnummern wird das Event GET GROUP ausgelöst. Die Komponenten GROUPING_REASON und GROUPING_VALUE enthalten Gruppierungsgrund und -wert dieser Gruppe, und in PERNR_NUM steht die Anzahl der Personalnummern, die zu dieser Gruppe gehören und nachfolgend verarbeitet werden. Die inkludierte Tabelle ALL_PERNRS enthält eine Liste dieser Personalnummern mit weiteren Informationen. Das Flag SELECTED gibt an, ob die jeweilige Personalnummer ursprünglich selektiert wurde (Flag gesetzt), oder vom Report als zu verarbeiten gekennzeichnet wurde. GROUPING_BEGDA und GROUPING_ENDDA enthalten den Gültigkeitszeitraum, den die Personalnummer für diese Gruppierung hat. Das Flag NO_AUTHORITY ist dann gesetzt, wenn für eine Personalnummer keine ausreichende Berechtigung vorliegt. Die entsprechende Personalnummer wird dann nicht weiter verarbeitet. Die Komponente SORT legt eine Standardsortierung der Personalnummern der Gruppe fest. Diese kann durch den Report durch Überschreiben der Werte geändert werden. Auf diese Weise findet eine Kommunikation mit der logischen Datenbank statt, die die weitere Verarbeitungsreihenfolge der Personalnummern steuert.

Für alle Personalnummern der Gruppe (mit Ausnahme der Personalnummern, für die keine Berechtigung vorliegt) wird anschließend in der durch die Komponente SORT (siehe oben) vorgegebenen Reihenfolge das Event GET PERAS ausgelöst. Die Komponenten SELECTED und GROUPING_BEGDA und GROUPING_ENDDA haben dabei die selbe Bedeutung wie beim Event GET GROUP. Das Flag PROCESSED_BEFORE gibt an, ob die Personalnummer bereits vorher einmal verarbeitet wurde (es ist möglich, daß die selbe Personalnummer zu mehreren Gruppierungen gehört und deshalb mehrfach verarbeitet wird).

Sortierung

Über die Funktion 'Sortierung' in der Buttonleiste kann die Liste der selektierten Personalnummern sortiert werden. Dazu können bis zu sieben Felder aus Infotyp 0001 ausgewählt werden, die in die Sortierung einfließen sollen. Da bei Zeitraumauswertungen (anders als bei Stichtagsauswertungen) zu einer Personalnummer mehrere Datensätze zu Infotyp 0001 existieren können, ist ferner anzugeben, ob die Sortierung gemäß den Werten des letzten oder des ersten Datensatzes im Personenauswahlzeitraum erfolgen soll.

Im PNP-Modus bestimmt die sortierte Reihenfolge exakt die Reihenfolge, in der das Event GET PERAS aufgerufen wird. Im CE-Modus bestimmt die Sortierung die Reihenfolge, in der das Event GET PERSON aufgerufen wird. Basierend auf der (sortierten) Reihenfolge der Personalnummern wird die Liste der Personen aufgebaut. Existiert zu jeder selektierten Personalnummer nur genau eine Person, so entspricht die Reihenfolge der Personen exakt der Reihenfolge der Personalnummern. Führen jedoch mehrere selektierte Personalnummern zu der selben Person, so bestimmt ausschließlich die erste Personalnummer die Sortierreihenfolge der Personen. Alle weiteren Personalnummern bestimmen lediglich die Reihenfolge, in der nachfolgend das Event GET PERAS aufgerufen wird. Vorausgesetzt, der Report verlangt keine Umsortierung der Personalnummern durch Manipulation der Komponente SORT beim Event GET GROUP (siehe oben), so wird das Event GET PERAS für die Personalnummern einer Person in der Reihenfolge aufgerufen, in der die Personalnummern (ursprünglich) sortiert wurden.

Bereitstellen von Infotyp-Datensätzen

Neben dem Auslösen der Events GET PERSON, GET GROUP und GET PERAS stellt die logische Datenbank auch die Datensätze der Infotypen bereit, die mittels der INFOTYPES-Statements angefordert werden. Im Report müssen die INFOTYPES-Statements dort angegeben werden, wo auch die Variablendeklarationen gemacht werden, also in jedem Fall vor dem ersten erfassten Coding.

Prinzipiell unterscheidet man drei Varianten des INFOTYPES-Statements:

INFOTYPES nnnn

Der Infotyp nnnn wird zum Zeitpunkt GET PERAS mit den Datensätzen der aktuellen Personalnummer versorgt. Es werden nur die Datensätze bereitgestellt die in den auf dem Selektionsbild angegebenen Auswertungszeitraum fallen (dies ist ein Unterschied zur PNP, die standardmäßig alle Datensätze bereitstellt). Alternativ kann der Report durch Verwenden der Makros RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL spezifizieren, welche Datensätze bereitgestellt werden sollen.

INFOTYPES nnnn AS PERSON TABLE

Der Infotyp nnnn wird zum Zeitpunkt GET GROUP mit den Datensätzen aller Personalnummern versorgt, die in der inkludierten Tabelle ALL_PERNRS (der Struktur GROUP) stehen und für die Berechtigung vorliegt (Flag NO_AUTHORITY nicht gesetzt). Es werden nur die Datensätze bereitgestellt die in den auf dem Selektionsbild angegebenen Auswertungszeitraum fallen. Alternativ kann der Report durch Verwenden der Makros RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL spezifizieren, welche Datensätze bereitgestellt werden sollen.

INFOTYPES nnnn AS PERSON TABLE MODE P

Der Infotyp nnnn wird zum Zeitpunkt GET PERSON mit den Datensätzen aller Personalnummern versorgt, die in der inkludierten Tabelle ALL_PERNRS (der Struktur PERSON) stehen. Es wird keine Berechtigungsprüfung durchgeführt und es werden in jedem Fall alle existierenden Datensätze bereitgestellt, unabhängig davon, wie der Auswertungszeitraum auf dem Selektionsbild eingestellt wurde. Auch die Verwendung der Makros RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL hat hierauf keinen Einfluß.

Selektionsmöglichkeiten

Egal, ob der Report im PNP- oder CE-Modus läuft: Alle auf dem Selektionsbild der PNPCE zur Verfügung stehenden Funktionen und Selektionsoptionen dienen (zunächst) der Selektion von Personalnummern. Nur im CE-Modus werden anschließend zu diesen Personalnummern die zugehörigen Personen ermittelt. Im folgenden werden die Funktionen beschrieben, die von der PNPCE prinzipiell zur Einschränkung der Selektion zur Verfügung gestellt werden. In welchem Umfang diese Funktionen tatsächlich genutzt werden, hängt vom Report und der ihm zugeordneten Reportklasse ab. Die Zuordnung einer Reportklasse zu einem Report erfolgt bei der Pflege der Reporteigenschaften (SE38, 'Eigenschaften'; Button 'Ändern' -> Button 'HR-Reportklasse'). Der Kunde hat die Möglichkeit, diese Zuordnung zu übersteuern. Dazu existiert die Customizing-Aktivität Reportklasse zuordnen unter dem Pfad 'Personalmanagement' -> 'Personalinformationssystem' -> 'Reporting' -> 'Anpassung des Standardselektionsbildes'. Unter dem selben Pfad befindet sich auch die Customizing-Aktivität Reportklasse anlegen, über die sich Reportklassen definieren und ändern lassen. Da auch die PNP das Konzept der Reportklassen verwendet, ist darauf zu achten, daß einem PNPCE-Report nur eine Reportklasse zugeordnet wird, die spezielle für die PNPCE erstellt wurde.

Selektionsfelder der Infotypen 0000 und 0001

Alle Standardfelder der Infotypen 0000 und 0001 stehen zur Selektion zur Verfügung. Zusätzlich stehen weitere Selektionsfelder zur Verfügung, die sich als Konkatenation zweier oder mehrerer dieser Infotypfelder ergeben. Nach Möglichkeit sollten diese konkatenierten Felder jedoch nicht benutzt werden, da sie nicht performant in die Selektion einfließen und unter Umständen zu langen Laufzeiten führen können. Über die Funktion 'Selektionsfelder' in der Buttonleiste lassen sich die gewünschten Selektionsfelder ein- und ausblenden. Die Reportklasse definiert eine Vorauswahl der Felder, die zur Verfügung stehen sollen.

Freie Abgrenzungen

Die Freien Abgrenzungen ermöglichen die Selektion nach beliebigen und insbesondere auch kundeneigenen Infotypfeldern. Über die Funktion 'Freie Abgrenzungen' in der Buttonleiste lassen sich die Freien Abgrenzungen ein- und ausblenden. Die Reportklasse steuert, ob dies als Popup oder Inplace geschieht, bzw. ob die freien Abgrenzungen überhaupt unterstützt werden. Basis für die Freien Abgrenzungen ist ein Selektionsview, der festlegt, welche Infotypen und welche Felder zur Selektion angeboten werden. Die Definition eines Selektionsviews erfolgt in der ABAP Workbench. Als Typ des Selektionsviews muß 'für beliebige Tabellen' gewählt werden (der Typ 'zur logischen Datenbank' ist nicht zulässig, auch wenn man zunächst anderes vermuten würde). Über die Reportklasse wird gesteuert, welcher Selektionsview für die Freien Abgrenzungen verwendet wird. Wenn die Freien Abgrenzungen genutzt werden, so stehen die Funktionen 'Einschränken über Orgstruktur', 'Suchhilfe' und 'Selektions-ID' nicht zur Verfügung.

Einschränken über Orgstruktur

Eine Selektion von Personalnummern kann auch über ihre Position in der Organisationsstruktur vorgenommen werden. Dazu steht in der Buttonleiste die Funktion 'Orgstruktur' zur Verfügung, die die Organisationsstruktur darstellt. Hier können die Organisationseinheiten ausgewählt werden, zu denen die zu selektierenden Personalnummern gehören sollen. Dabei ist es unerheblich, ob die Personalnummern der markierten Organissationseinheit direkt, oder einer ihr untergeordneten Organisationseinheit zugeordnet sind. Wenn eine Einschränkung über die Orgstruktur erfolgt, so stehen die Funktionen 'Freie Abgrenzungen', Suchhilfe' und 'Selektions-ID' nicht zur Verfügung.

Suchhilfe

Die inkludierten Suchhilfen der Sammelsuchhilfe PREM stehen über die Funktion 'Suchhilfe' der Buttonleiste zur Verfügung. Hier können auch kundeneigene Suchhilfen eingebunden werden. Eine Beschreibung dazu findet sich im Customizing unter dem Pfad 'Personalmanagement' -> 'Personaladministration' -> 'Grundeinstellungen' -> 'Suchhilfen pflegen'. Wenn eine Suchhilfe verwendet wird, so stehen die Funktionen 'Freie Abgrenzungen', 'Einschränken über Orgstruktur' und 'Selektions-ID' nicht zur Verfügung.

Selektions-ID

Die Menge der zu selektierenden Personalnummern läßt sich auch über eine vordefinierte Selektionsmethode, eine sogenannte 'Selektions-ID' einschränken. Eine Beschreibung der Funktionsweise sowie eine Anleitung zum Anlegen von Selektions-ID's befindet sich in der Customizing-Aktivität 'Selektions-IDs definieren' unter dem Pfad 'Personalmanagement' -> 'Personalinformationssystem' -> 'Selektions-IDs'. Hier wird auch beschrieben, wie sich Selektions-ID's gruppieren lassen. Auf dem Selektionsbild der PNPCE werden genau die Selektions-ID's zur Auswahl angeboten, deren Gruppierung in der Reportklasse hinterlegt ist. Wenn eine Selektions-ID ausgewählt wurde, wird sie in jedem Fall auch ausgeführt. Dies kann entweder explizit durch Drücken des Buttons (hinter der ausgewählten Selektions-ID) erfolgen, oder es geschieht implizit beim Starten der Ausgabe (F8). Wenn eine Selektions-ID verwendet wird, so stehen die Funktionen 'Freie Abgrenzungen', 'Einschränken über Orgstruktur' und 'Suchhilfe' nicht zur Verfügung.

Auswertungszeitraum

Die PNPCE unterscheidet (wie die PNP auch) zwischen dem Datenauswahlzeitraum und dem Personenauswahlzeitraum. Beides wird unter dem Begriff Auswertungszeitraum zusammengefaßt. Während sich der Personenauswahlzeitraum auf die Selektion der Personalnummern auswirkt, steuert der Datenauswahlzeitraum die durch das INFOTYPES-Statement angeforderte Datenbeschaffung. Beide lassen sich auf dem Selektionsbild getrennt durch Auswahl eines geeigneten Eintrags der jeweiligen Listbox einstellen. Alternativ kann auch eine simultane Einstellung über eine gemeinsame Listbox erfolgen. Welche Einträge die Listboxen haben (d.h. welche Auswertungsintervalle unterstützt werden) läßt sich über die Reportklasse steuern. Der eingestellte Personenauswahlzeitraum wird bei der Selektion der Personalnummern berücksichtigt. Es werden nur die Personalnummern selektiert, die die angegebenen Selektionsbedingungen an mindestens einem (Stich-)tag im eingestellten Personenauswahlzeitraum erfüllen. Zu diesen Personalnummern werden standardmäßig alle Datensätze der angeforderten Infotypen beschafft, die an mindestens einem (Stich-)tag im eingestellen Datenauswahlzeitraum gültig sind. Ein abweichendes Verhalten läßt sich durch die Makros RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL erzielen. Eine Ausnahme bildet auch die Beschaffung der Datensätze zu Infotypen, die mit dem Zusatz AS PERSON TABLE MODE P definiert wurden. Hier werden unabhängig vom Datenauswahlzeitraum alle Datensätze beschafft.

Als Besonderheit für den Auswertungszeitraum ist die Abrechnungsperiode anzusehen. Es kann entweder die aktuelle Abrechnungsperiode, oder eine beliebige Abrechnungsperiode ausgewählt werden. In beiden Fällen ist der Abrechnungskreis einzugeben. Aus diesen Angaben erreichnet sich der Abrechnungszeitraum. Dieses Intervall wird für die weitere Verarbeitung (intern) als Auswertungszeitraum (also sowohl als Personen- als auch Datenauswahlzeitraum) verwendet.

Den verwendeten Auswertungszeitraum kann der Report über die Struktur PN abfragen. Die Komponenten BEGDA und ENDDA enthalten den Datenauswahlzeitraum während BEGPS und ENDPS den Personenauswahlzeitraum enthalten. Umgekehrt kann der Report Daten- und Personenauswahlzeitraum auch explizit setzen. Er muß dazu zum Zeitpunkt START-OF-SELECTION die entsprechenden Komponenten der Struktur PN füllen. Dies macht allerdings nur dann Sinn, wenn über die Reportklasse eine manuelle Pflege des Auswertungszeitraums ausgeblendet wurde.

Kommunikation zwischen Report und PNPCE

Ein Bestandteil der logischen Datenbank PNPCE ist das Include DBPNPCECOM. Dieses wird automatisch auch von jedem Report, der auf der PNPCE basiert, includiert. Der darin definierte Common Part bewirkt, daß Report und PNPCE einen gemeinsamen Datenbereich haben. Über diesen Datenbereich wird der Datenaustausch zur Kommunikation zwischen Report und PNPCE realisiert. Hier sind alle Schalter definiert, durch deren Manipulation der Report den Ablauf der PNPCE steuern kann. Ausserdem enthält das Include DBPNPCECOM eine Reihe von Makros, über die die PNPCE dem Report weitere Funktionen zur Verfügung stellt. Ein Großteil dieser Makros wurde von der PNP übernommen und war dort im Include DBPNPMAC definiert. Darüberhinaus existieren nach wie vor weitere Makros in der mittlerweile veralteten Tabelle TRMAC. Diese Makros sollten in keinem Fall mehr verwendet werden. Alle dort definierten Makros, die Funktionalität der logischen Datenbank betreffen, existieren auch im Include DBPNPCECOM mit geringfügig geänderter Schreibweise ('Unterstrich '_' statt Bindestrich '-'; z.B. RP_PROVIDE_FROM_LAST statt RP-PROVIDE-FROM-LAST). Einige der TRMAC-Makros wurden im Include DBPNPCECOM mit gleicher Schreibweise, aber ohne Funktionalität überdefiniert, so daß eine irrtümliche Verwendung (der TRMAC-Makros) zu einem Syntaxfehler führt und somit ausgeschlossen ist.

Im folgenden wird die Funktionalität erläutert, die über die im Include DBPNPCECOM definierten Schalter und Makros bereitgestellt wird. Um die genaue Syntax zum Aufrauf eines Makros hinsichtlich seiner Parameter und Typisierung zu erfahren, sollte man sich die Definition des Makros im Include DBPNPCECOM anschauen.

Auswertungszeitraum in der Struktur PN

Die Struktur PN enthält Informationen über den Auswertungszeitraum, für den die Auswertung gestartet wird, unabhängig davon, auf welche Art und Weise dieser auf dem Selektionsbild spezifiziert wurde. Jeder Report sollte daher ausschließlich auf die Felder der Sturktur PN zugreifen, wenn er diese Informationen benötigt, und nicht etwa auf die Selektionsfelder PNPBEGDA, PNPENDDA ,etc. des Selektionsbildes.

Die Felder PN-BEGPS und PN-ENDPS enthalten den Personenauswahlzeitraum, für den die Selektion der Personalnummern durchgeführt wird. Die Felder PN-BEGDA und PN-ENDDA enthalten den Datenauswahlzeitraum. Falls der Auswertungszeitraum über eine Abrechnungsperiode eingestellt wurde, so enthält PN-PABRP die Abrechnungsperiode, PN-PABRJ das Abrechnungsjahr und PN-PERMO den Periodenparameter. Abrechungsperiode und Abrechnungsjahr stehen ausserdem (zusätzlich) in PN-PAPER.

Der Report kann die Felder PN-BEGDA, PN-ENDDA, PN-BEGPS und PN-ENDPS auch selber zum Zeitpunkt START-OF-SELECTION mit Werten belegen und damit den Auswertungszeitraum vorgeben. In einem sochen Fall macht jedoch die Einstellmöglichkeit dieses Zeitraums auf dem Selektionsbild keinen Sinn und sollte über die Reportklasse ausgeblendet werden. Ferner muß der Report sicherstellen, daß die angegebenen Werte gültig sind, da keine Verpobung dieser Werte mehr stattfindet.

Datenauswahlzeitraum setzen: RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, RP_SET_DATA_INTERVAL_ALL

Durch das INFOTYPES-Statement fordert der Report Infotyp-Datensätze an, die von der PNPCE gelesen und bereitgestellt werden. Über den Zusatz 'VALID FROM .. TO ..' kann der Report spezifizieren, daß er nur Datensätze benötigt, die im angegebenen Zeitraum gültig sind. Leider ist der Zusatz 'VALID FROM .. TO ..' in den meisten Fällen unbrauchbar, da er keine dynamische Angabe des Datums ermöglicht, sondern nur Konstanten akzeptiert. Wird der Zusatz VALID FROM .. TO ..' nicht verwendet, liefert die PNPCE standardmäßig alle Datensätze, die in dem auf dem Selektionsbild angegebenen Datenauswahlzeitraum fallen. Ist dies nicht gewünscht, so kann der Report die Makros RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL aufrufen, um die Infotyp-Datensätze auf einen abweichenden Gültigkeitszeitraum einzuschränken. Das Makro RP_SET_DATA_INTERVAL setzt den Gültigkeitszeitraum für einen einzelnen Infotypen, dessen Name (z.B. 'P0001' , oder 'PP0001' nicht zu verwechseln mit seiner Nummer '0001') im ersten Parameter anzugeben ist. Im zweiten und dritten Parameter wird der Gültigkeitszeitraum spezifiert. Analog ist das Makro RP_SET_DATA_INTERVAL_INFTY zu verwenden, bei dem aber davon abweichend im ersten Parameter nicht der Name, sondern die Nummer des Infotyps anzugeben ist. Da der selbe Infotyp unter Verwendung der INFOTYPES-Zusätze 'AS PERSON TABLE' oder 'NAME ...' mehrfach (unter verschiedenen Namen) verwendet werden kann, setzt dieses Macro den Gültigkeitszeitraum für alle Infotypen der selben Nummer. Das Makro RP_SET_DATA_INTERVAL_ALL dagegen hat nur den Gültigkeitszeitraum als Parameter und setzt diesen für alle verwendeten Infotypen.

Mode eines Infotyps setzen: PNP_SET_INFTY_MODE_BY_NAME, PNP_SET_INFTY_MODE_BY_NUMBER

Das INFOTYPES-Statement verfügt über den Zusatz MODE, mit dem sich steuern läßt, ob und wie der Infotyp verarbeitet werden soll. Wird der Zusatz nicht verwendet, so entspricht dies einem 'MODE Y', und der Infotyp wird von der PNPCE gelesen und in der internen Infotyptabelle bereitgestellt. Durch 'MODE N' läßt sich steuern, daß die interne Infotyptabelle zwar deklariert wird, jedoch keine Infotypdatensätze von der PNPCE gelesen werden. Ferner gibt es noch den 'MODE P', der nur zusammen mit dem Zusatz 'AS PERSON TABLE' verwendet werden darf, und bewirkt, daß zum Zeitpunkt GET PERSON alle Infotypdatensätze aller Personalnummern einer Person ohne Berechtigungsprüfung und ohne Zeitraumeinschränkung gelesen werden. Durch die Verwendung der Makros PNP_SET_INFTY_MODE_BY_NAME und PNP_SET_INFTY_MODE_BY_NUMBER kann der Report den beim INFOTYPES-Statement angegebenen MODE zur Laufzeit (dynamisch) ändern. Der Aufruf der Makros muß zum Zeitpunkt INITIALIZATION oder START-OF-SELECTION erfolgen. Das Makro PNP_SET_INFTY_MODE_BY_NAME setzt den MODE für einen einzelnen Infotypen, dessen Name (z.B. 'P0001' , oder 'PP0001' nicht zu verwechseln mit seiner Nummer '0001') im ersten Parameter anzugeben ist. Analog ist das Makro RP_SET_INFTY_MODE_BY_NUMBER zu verwenden, bei dem aber davon abweichend im ersten Parameter nicht der Name, sondern die Nummer des Infotyps anzugeben ist. Da der selbe Infotyp unter Verwendung der INFOTYPES-Zusätze 'AS PERSON TABLE' oder 'NAME ...' mehrfach (unter verschiedenen Namen) verwendet werden kann, setzt dieses Makro den MODE für alle Infotypen der selben Nummer.

Nachlesen von Zeitwirtschaftsinfotypen: RP_READ_ALL_TIME_ITY, RP_READ_ALL_PERSON_TIME_ITY

Zeitwirtschaftsinfotypen (2000-2999) enthalten häufig eine Vielzahl von Datensätzen, insbesondere dann, wenn die Positiverfassung im Einsatz ist. Wird eine zu große Datenmenge über die INFOTYPES-Statements angefordert, so kann dies zu Performanceproblemen oder im Extremfall sogar zu einem Speicherüberlauf führen. Aus diesem Grund gibt es die Makros RP_READ_ALL_TIME_ITY und RP_READ_ALL_PERSON_TIME_ITY, mit denen sich Zeitwirtschaftsdaten gezielt nachlesen lassen. Die Zeitwirtschaftsinfotypen werden dazu durch das INFOTYPES-Statement mit dem Zusatz MODE N definiert. Dies bewirkt, daß die interne Infotyptabelle zwar deklariert wird, die Daten von der PNPCE aber (noch) nicht gelesen werden. Zu den Zeitpunkten GET GROUP und GET PERAS kann der Report dann entscheiden, ob und für welchen Zeitraum er die Zeitwirtschaftsdaten nachlesen möchte. Zum Zeitpunkt GET GROUP kann er das Makro RP_READ_ALL_PERSON_TIME_ITY aufrufen, um alle Zeitwirtschaftsdaten zu den Personalnummern einer Person zu lesen, die verarbeitet werden sollen, d.h. die in der inkludierten Tabelle ALL_PERNRS der Struktur GROUP stehen. Die Daten werden dann in die Infotypen geschrieben, die mit dem INFOTYPES-Statement unter Verwendung des Zusatzes AS PERSON TABLE deklariert wurden.

Zum Zeitpunkt GET PERAS dagegen kann der Report das Makro RP_READ_ALL_TIME_ITY aufrufen, um die Zeitwirtschaftsdaten zur aktuellen Personalnummer zu lesen. In beiden Fällen ist beim Aufruf des Makros der Zeitraum anzugeben, in dem die Datensätze gültig sein sollen. Ausserdem wird in beiden Fällen der Schalter PNP-SW-IGNORELOCKEDRECORDS berücksichtigt, der steuert, ob gesperrte Datensätze gelesen werden, oder nicht. Für alle Datensätze wird ferner eine Berechtigungsprüfung durchgeführt. Ist für einen Datensatz keine Berechtigung vorhanden, so wird dieser verworfen (d.h. nicht in die Infotyptabelle gestellt). Falls Datensätze mangels Berechtigung verworfen wurden, so wird der globale Schalter PNP-SW-AUTH-SKIPPED-RECORD auf den Wert '1' gesetzt, andernfalls hat er den Wert '0'.

Gesperrte Datensätze: PNP-SW-IGNORELOCKEDRECORDS

In der Personalstammdatenpflege ist es möglich, einzelne Infotypdatensätze zu sperren. Diese Datensätze bleiben bei Auswertungen mit der PNPCE normalerweise unberücksichtigt. Durch Setzen des Schalters PNP-SW-IGNORELOCKEDRECORDS auf 'N' (zum Zeitpunkt INITIALIZATION oder START-OF-SELECTION) kann der Report jedoch die PNPCE anweisen, auch gesperrte Datensätze zu lesen.

Berechtigungsprüfung: PNP_SW_SKIP_PERNR, PNP_GET_AUTH_SKIPPED_PERNRS

Die PNPCE führt für alle Infotyp-Datensätze, die vom Report über das INFOTYPES-Statement angefordert werden, eine Berechtigungsprüfung durch. Liegt auch nur für einen einzigen Datensatz eines der verwendeten Infotypen keine Berechtigung vor, so wird standardmäßig die Verarbeitung der Personalnummer abgebrochen. Im PNP-Modus bedeutet dies, daß das Event GET PERAS (für die Personalnummer) übersprungen wird. Der Report bekommt dies nur mit, wenn er im Anschluß (möglichst zum Zeitpunkt END-OF-SELECTION) das Makro PNP_GET_AUTH_SKIPPED_PERNRS aufruft, welches ihm eine Liste der übersprungenen Personalnummern liefert.

Im CE-Modus wird zum Zeitpunkt GET GROUP in der inkludierten Tabelle ALL_PERNRS das Flag NO_AUTHORITY gesetzt, so daß der Report daran erkennt, daß keine Berechtigung vorliegt. Das nachfolgende Event GET PERAS wird für diese Personalnummer ebenfalls nicht ausgeführt. Wie im PNP-Modus kann der Report über das Makro PNP_GET_AUTH_SKIPPED_PERNRS die Liste der Personalnummern abholen, für die keine Berechtigung vorhanden ist.

Durch den Schalter PNP_SW_SKIP_PERNR läßt sich jedoch auch ein anderes Verhalten erzielen. Setzt man diesen Schalter (zum Zeitpunkt INITIALIZATION oder START-OF-SELECTION) auf 'N', so werden keine Personalnummern mehr (mangels Berechtigung) übersprungen. Es werden lediglich die Datensätze verworfen (d.h. nicht bereitgestellt), für die keine Berechtigung vorliegt. Der Report hat keine Möglichkeit zu erkennen, daß ihm Datensätze 'unterschlagen' wurden.

Mengenzugriff durch Array-Fetch: PNPCE_ARRAY_FETCH_SIZE

Das Lesen der Infotyp-Datensätze erfolgt nicht für jede Personalnummer einzeln, sondern als Mengenzugriff für mehrere Personalnummern gleichzeitig. Dadurch wird die Zahl der Datenbankzugriffe reduziert und die Performance zum Teil erheblich verbessert. Allerdings ist es nicht möglich, auf einen Schlag die Infotyp-Datensätze aller Personalnummern zu lesen, da dies je nach Anzahl der selektierten Personalnummern und vorhandenen Datensätzen zu Speicherplatzproblemen führen kann. Aus diesem Grund wird eine Segmentierung der Personalnummern in Blöcke fester Größe vorgenommen und immer die Personalnummern eines Blockes zusammen verarbeitet. Diese Blockgröße ist standardmäßig auf 100 eingestellt (was bedeutet, daß die Personalnummern von 100 Personen gleichzeitig verarbeitet werden), kann vom Report aber über den Schalter PNPCE_ARRAY_FETCH_SIZE zum Zeitpunkt INITIALIZATION oder START-OF-SELECTION verändert werden. Eine Änderung dieses Wertes sollte nur mit äußerster Vorsicht vorgenommen werden. Wird der Wert zu groß eingestellt, kann es zu einem Speicherüberlauf kommen, ist er zu klein eingestellt, so geht dies zu Lasten der Performance. Die Wahl eines geeigneten Wertes muß sich also an der Anzahl der angeforderten Infotypen sowie der darin erwarteten Datenmenge orientieren. Beachten Sie hierbei auch den Schalter V_T77S0 LDB AFMEM.

Sperren von Personen / Personalnummern

Standardmäßig werden von der Logischen Datenbank keine Personalnummern oder Personen gesperrt. Der Report kann dies aber anfordern. Im CE-Modus muß der Report dazu den Schalter PNPCE_ENQUEUE_PERSONS auf 'X' setzen. Dies bewirkt, daß die LDB für alle Personalnummern einer Person Sperren setzt. Nur wenn alle Personalnummern erfolgreich gesperrt werden konnten, gilt die Person als gesperrt und wird verarbeitet. Andernfalls wird sie übersprungen. Es ist die Aufgabe des Reports, diese Sperre wieder zurückzunehmen. Dazu sollte er das Makro PNPCE_DEQUEUE_PERSON unter Angabe der Personen-Id aufrufen. Personen, die nicht gesperrt werden können und übersprungen werden, werden von der Logischen Datenbank geloggt. Am Ende der Verarbeitung kann diese Liste vom Report über das Makro PNPCE_GET_ENQ_FAILED_PERSONS abgefragt werden. Allerdings werden nicht alle Personen geloggt, sondern nur die ersten N Personen. Wieviele dies genau sind, kann der Report über den Schalter PNPCE_LOG_ENQ_FAILED_PERSONS einstellen. Ein Wert von -1 bedeutet, daß alle Personen geloggt werden sollen. Beim Aufruf des Makros PNPCE_GET_ENQ_FAILED_PERSONS wird neben den ersten N geloggten Personen in jedem Fall auch die Gesamtzahl der übersprungenen Personen zurückgegeben.

Im PNP-Modus können einzelne Personalnummern gesperrt werden. Dazu muß der Report (wie in der PNP auch) den Schalter PNP-SW-ENQUEUPERNR auf 'Y' setzen. Auch hier ist der Report für das Entsperren der Personalnummern selbst verantwortlich und kann dazu das Makro PNP_DEQUEUE_PERNR unter Angabe der Personalnummer aufrufen. Eine Liste der Personalnummern, die nicht gesperrt werden konnten, kann über das Makro PNP_GET_ENQ_FAILED_PERNRS abgeholt werden. Auch hier werden nur die ersten N Personalnummern geliefert sowie die Gesamtanzahl der übersprungenen Personalnummern. Die Anzahl der Personalnummern, die geloggt werden soll, läßt sich über den Schalter PNP_LOG_ENQ_FAILED_PERNRS einstellen. Der Wert -1 bedeutet dabei, daß alle Personalnummern geloggt werden sollen.

Ermitteln des ersten Datensatzes im Zeitraum: RP_PROVIDE_FROM_FRST

Das Makro RP_PROVIDE_FROM_FRST analysiert die ihm in einer internen Tabelle übergebenen Infotyp-Datensätze bezüglich des angegebenen Zeitraums und stellt den ersten im angegebenen Zeitraum gültigen Datensatz (denjenigen mit dem kleinsten ENDDA ) in die Kopfzeile der internen Tabelle. Falls kein Datensatz im angegebenen Zeitraum existiert, wird der globale Schalter PNP-SW-FOUND auf den Wert '0' gesetzt, andernfalls hat er den Wert '1'. Falls der Infotyp Subtypen enthält, ist zusätzlich der Subtyp zu spezifizieren, zu dem der letzte gültige Datensatz ermittelt werden soll. Andernfalls ist das Ergebnis undefiniert. Ferner müssen die Datensätze der internen Tabelle nach Primärschlüssel sortiert sein. Dies ist gewährleistet, wenn die Datensätze von der Logischen Datenbank PNPCE über das INFOTYPES-Statement ermittelt wurden. Bei Unklarheit über die exakte Funktionalität des Makros ist die Implementierung des Makros zu analysieren. Im Zweifelsfall sollte das Makro nicht verwendet werden, sondern eine für den jeweiligen Report passende Lösung selbst implementiert werden.

Ermitteln des letzten Datensatzes im Zeitraum: RP_PROVIDE_FROM_LAST

Das Makro RP_PROVIDE_FROM_LAST analysiert die ihm in einer internen Tabelle übergebenen Infotyp-Datensätze bezüglich des angegebenen Zeitraums und stellt den letzen im angegebenen Zeitraum gültigen Datensatz (denjenigen mit dem größten ENDDA) in die Kopfzeile der internen Tabelle. Falls kein Datensatz im angegebenen Zeitraum existiert, wird der globale Schalter PNP-SW-FOUND auf den Wert '0' gesetzt, andernfalls hat er den Wert '1'. Falls der Infotyp Subtypen enthält, ist zusätzlich der Subtyp zu spezifizieren, zu dem der letzte gültige Datensatz ermittelt werden soll. Andernfalls ist das Ergebnis undefiniert. Ferner müssen die Datensätze der internen Tabelle nach Primärschlüssel sortiert sein. Dies ist gewährleistet, wenn die Datensätze von der Logischen Datenbank PNPCE über das INFOTYPES-Statement ermittelt wurden. Eine Besonderheit ergibt sich auch für Infotypen mit Zeitbindung 3: Hier wird nicht unbedingt der Datensatz mit dem größten ENDDA zurückgeliefert, sondern (falls vorhanden) der erste Datensatz, der am Ende-Datum des angegebenen Zeitraums gültig ist. Bei Unklarheit über die exakte Funktionalität des Makros ist die Implementierung des Makros zu analysieren. Im Zweifelsfall sollte das Makro nicht verwendet werden, sondern eine für den jeweiligen Report passende Lösung selbst implementiert werden.

Infotyp lesen: RP_READ_INFOTYPE

Das Makro RP_READ_INFOTYPE liest die Datensätze eines Infotypes zur angegebenen Personalnummern, die im angegebenen Zeitraum gültig sind, und schreibt sie in die angegebene interne Tabelle. Diese Tabelle muß richtig typisiert sein. Falls keine Datensätze im angegebenen Zeitraum existieren, wird der globale Schalter PNP-SW-FOUND auf den Wert '0' gesetzt, andernfalls hat er den Wert '1'. Für alle Datensätze wird ferner eine Berechtigungsprüfung durchgeführt. Ist für einen Datensatz keine Berechtigung vorhanden, so wird dieser verworfen (d.h. nicht in die interne Tabelle gestellt). Falls Datensätze mangels Berechtigung verworfen wurden, so wird der globale Schalter PNP-SW-AUTH-SKIPPED-RECORD auf den Wert '1' gesetzt, andernfalls hat er den Wert '0'. Beim Lesen der Datensätze wird ausserdem der Schalter PNP-SW-IGNORELOCKEDRECORDS berücksichtigt, der steuert, ob gesperrte Datensätze gelesen werden, oder nicht.

Normalerweise werden Infotypen über den Funktionsbaustein HR_READ_INFOTYPE gelesen. Das Makro RP_READ_INFOTYPE bietet dann Performancevorteile, wenn die Datensätze bereits von der PNPCE gelesen wurden und daher in einem internen Puffer stehen. Die PNPCE liest aber nur Datensätze, die vom Report über ein INFOTYPES-Statement angefordert wurden. Ferner wird der Puffer nach spätestens 100 verarbeiteten Personalnummern wieder gelöscht. Wenn der Report aber die Datensätze über ein INFOTYPES-Statement anfordert, macht ein erneutes Anfordern der Datensätze über das Makro RP_READ_INFOTYPE für die selbe Personalnummer im allgemeinen wenig Sinn. Der Aufruf für eine andere Personalnummer profitiert nur dann vom Puffer, wenn diese (zufällig) zu dem Block der 100 aktuell gepufferten Personalnummern gehört. Unter Performancegesichtspunkten ist die Bedeutung des Makros daher zu vernachlässigen.

Ausgetretene Mitarbeiter ausschließen: RP_SEL_EIN_AUS_INIT

Der Aufruf dieses Makros zum Zeitpunkt INITIALIZATION bewirkt, daß nur Personalnummern selektiert werden, die im eingestellten Personenauswahlzeitraum nicht ausgetreten sind. Technisch gesehen wird dazu die Select-Option PNPSTAT2 (STAT2 aus Infotyp 0000) mit '<> 0' belegt. Dabei handelt es sich lediglich um einen Vorschlagswert für die auf dem Selektionsbild angezeigte Selektionsbedingung, die durch den Anwender nachträglich geändert oder gelöscht werden kann.

Fortschrittsanzeige: PNPCE_NO_PROGRESS_INDICATOR, PNPCE_PROGRESS_BLOCK_SIZE

Die PNPCE nutzt die Standardtechnik zur Anzeige des Verarbeitungsfortschritts (progress indicator). Falls der Report eine eigene Fortschrittsanzeige realisieren möchte, oder eine solche Fortschrittsanzeige nicht gewünscht ist, kann der Report diese durch Setzen des Schalters PNPCE_NO_PROGRESS_INDICATOR auf 'X' ausschalten. Ausserdem läßt sich über den Schalter PNPCE_PROGRESS_BLOCK_SIZE steuern, wie häufig, (d.h. nach jeweils wievielen verarbeiteten Personen) die Fortschrittsanzeige aktualisiert wird (eine zu häufige Aktualisierung kann zu Performanceverlust führen).

Payroll-Grouping: PNPCE_GROUPING_FROM_PAYROLL

Durch Setzen dieses Schalters auf 'X' läßt sich einstellen, daß die Gruppierung von Personalnummern (wie sie zum Event GET GROUP geliefert werden) auf Basis von Abrechnungsdaten erfolgen soll.

Aufgrund eines Fehlers geskippte Personalnummern: PNP_GET_ERR_SKIPPED_PERNRS

Für einige Infotypen ist in der PNPCE eine spezielle Logik zum Ermitteln der Datensätze implementiert. Für die Infotypen 0027 und 0266 erfolgt dies über den Aufruf eines Funktionsbausteins (HR_COST_DISTRIBUTION_GET). Im Fehlerfall kann der Funktionsbaustein eine Exception auslösen. Die PNPCE reagiert auf eine solche Exception, indem sie die Personalnummern, für die der Fehler aufgetreten ist, nicht weiter verarbeitet, d.h. das Event PUT PERAS nicht auslöst. Wenn der Report wissen möchte, welche Personalnummern aufgrund dieses Fehlers übersprungen wurden, kann er dazu das Makro PNP_GET_ERR_SKIPPED_PERNRS aufrufen.

Bemerkungen

Kopfzeilen von Infotyptabellen

Die PNPCE füllt nur den Tabellenrumpf der mit INFOTYPES definierten Infotypen, nicht aber die Kopfzeilen. Diese werden initialisiert. Ein Programmieren auf die Kopfzeilen ist daher unzulässig. Bei der PNP ist dies teilweise anders. In bestimmten Fällen wird auch die Kopfzeile gefüllt, in vielen Fällen aber nicht. Da dies von unterschiedlichen Faktoren abhängt, die insbesondere vom Report nicht nachvollziehbar/steuerbar sind, ist auch in der PNP de Facto das Programmieren auf eine vermeindlich gefüllt Kopfzeile unzulässig.

Infotypverwaltungstabelle $RINFO$

In der Tabelle $RINFO$ werden die Infotypen verwaltet, die der Report über das INFOTYPES-Statement definiert. Sie ist im Include DBPNPCECOM definiert, so daß der Report ebenfalls Zugriff auf diese Tabelle hat. Die manuelle Modifikation dieser Tabelle zur Änderung von Infotypeigenschaften durch den Report ist jedoch verboten. Stattdessen sollten die Makros verwendet werden, über die sich die Infotypeigenschaften setzen lassen (Setzen des MODE durch PNP_SET_INFTY_MODE_BY_NAME und PNP_SET_INFTY_MODE_BY_NUMBER; Setzen des Gültigkeitszeitraums durch RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY und RP_SET_DATA_INTERVAL_ALL).

Start eines PNPCE-Reports mit vorselektierter Personalnummernmenge/Personenmenge.

Ein PNPCE-Report läßt sich auch mit einer von außen vorgegebenen Personalnummernmenge starten. Dazu ist beim Aufruf des Reports mittels SUBMIT der Parameter PNPINDEX mit den entsprechenden Personalnummern zu versorgen. Da es sich technisch gesehen bei PNPINDEX um eine (dunkle) Select-Option handelt, sind die Personalnummern in einer RANGE-Struktur bestehend aus SIGN, OPTION und LOW zu spezifizieren. Für jede Personalnummer muß SIGN den Wert 'I', OPTION den Wert 'EQ' und LOW die Personalnummer enthalten. Beim SUBMIT ist die Range-Tabelle an PNPINDEX über den Operator 'IN' zu übergeben.

Beispiel:

RANGES: pernr_index FOR pernr-pernr.

CLEAR pernr_index.

pernr_index-sign = 'I'.

pernr_index-option = 'EQ'.

pernr_index-low = '00000815'.

APPEND pernr_index.

SUBMIT pnpce_report WITH pnpindex IN pernr_index.

Wenn auf diese Weise eine Personalnummernmenge vorgegeben wird, dürfen die Funktionen 'Freie Abgrenzungen', 'Einschränken über Orgstruktur', 'Suchhilfe' und 'Selektions-ID' nicht zum (weiteren) Einschränken der Personalnummernmenge verwendet werden. Die für die Selektionsfelder der Infotypen 0000 und 0001 eingegebenen Bedingungen werden jedoch berücksichtigt.

In ähnlicher Weise ist es möglich, einen PNPCE-Report mit einer vorgegebenen Personenmenge zu starten. Dazu ist beim Aufruf des Reports mittels SUBMIT der Parameter PNPPERID mit den entsprechenden Personen-ID's zu versorgen. Anders als PNPINDEX ist PNPPERID aber kein Range, sondern eine interne Tabelle, deren Zeilentyp das Datenelement PERSONID ist.

Beispiel:

DATA: personid_index TYPE STANDARD TABLE OF personid.

APPEND '00000815' TO personid_index.

SUBMIT pnpce_rerpot WITH pnpperid = personid_index.

Wenn auf diese Weise eine Personenmenge vorgegeben wird, darf nicht gleichzeitig eine Personalnummernmenge (über PNPINDEX) vorgegeben werden. Auch dürfen die Funktionen 'Freie Abgrenzungen', 'Einschränken über Orgstruktur', 'Suchhilfe' und 'Selektions-ID' nicht zum (weiteren) Einschränken der Personalnummernmenge verwendet werden.

Gleichzeitige Verwendung mehrerer Selektionsmöglichkeiten

Die PNPCE kennt neben der Selektion nach Feldern der Infotypen 0000 und 0001 wie oben beschrieben prinzipiell sechs weitere Möglichkeiten zur Personalnummernselektion. Im einzelnen sind dies die Selektion über Freie Abgrenzungen, über die Orgstruktur, über Suchhilfe, über Selektions-ID und durch die explizite Angabe einer Personalnummernmenge in PNPINDEX oder einer Personenmenge in PNPPERID beim Aufruf des Reports. Diese sechs Möglichkeiten schließen sich jedoch gegenseitig aus, d.h. es darf tatsächlich nur eine davon genutzt werden. Auf dem Selektionbild wird versucht, dies durch geeignete Abfragen sicherzustellen. In einigen Fällen kann es jedoch dazu kommen, daß mehr als nur eine dieser Funktionen verwendet wird (z.B. bei Aufruf des PNPCE-Reports mit expliziter Angabe einer Personalnummernmenge in PNPINDEX sowie einer zu verwendenden Variante, in der ausserdem Freie Abgrenzungen gespeichert wurden). In diesem Fall wird dennoch nur eine, und zwar die erste verwendete Funktion bezüglich der folgenden Reihenfolge berücksichtigt.

1. Freie Abgrenzungen
2. Einschränken über Orgstruktur
3. Suchhilfe
4. Selektions-ID
5. Explizite Angabe der Personalnummern in PNPINDEX
6. Explizite Angabe der Personen in PNPPERID

Die so gefundene Personalnummernmenge wird in jedem Fall durch die angegebenen Selektionsbedingungen der Infotypen 0000 und 0001 weiter eingeschränkt.

Beispiel

PNP-Modus (ohne Funktionalität zur Auswertung von Mehrfachanstellungen)

TABLES: PERNR.

NODES: PERAS.

INFOTYPES: 0006 NAME P0006.

GET PERAS.

* table P0006 is filled with infotype 0006 data of PERNR

* stored in PERAS-PERNR

  WRITE :/ PERAS-PERNR.

  ...

CE-Modus (mit Funktionalität zur Auswertung von Mehrfachanstellungen)

TABLES: PERNR.

NODES: PERSON, GROUP, PERAS.

INFOTYPES: 0001 NAME ALL_0001 AS PERSON TABLE MODE P.

INFOTYPES: 0001 NAME PP0001 AS PERSON TABLE.

INFOTYPES: 0006 NAME P0006.

GET PERSON.

* table ALL_0001 is filled with infotype 0001 data of all PERNRs

* stored in PERSON-ALL_PERNRS without authority check !!!

  WRITE :/ PERSON-OBJID.

  ...

GET GROUP.

* table P0001 is filled with infotype 0001 data of all PERNRs

* stored in GROUP-ALL_PERNRS

  WRITE :/ GROUP-GROUPING_REASON, GROUP-GROUPING_VALUE.

  ...

GET PERAS.

* table P0006 is filled with infotype 0006 data of PERNR

* stored in PERAS-PERNR

  WRITE :/ PERAS-PERNR.

  ...

PERFORM Short Reference   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 53238 Date: 20240531 Time: 041138     sap01-206 ( 628 ms )