IT2011 auslesen und Tagesarbeitszeiten addieren (ohne FuBa)
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
Hallo,
ich möchte die Arbeitszeiten eines Mitarbeiters aus dem Infotyp 2011 direkt auslesen ohne FuBa.
Das hat gut geklappt. Nur, wenn der MA an einem Tag 2x stempelt, möchte ich diese Zeiten addieren.
Ich hatte die Idee, die erste Summe in einer Variable zwischenzuspeichern. Aber ich habs bisher nicht hinbekommen.
Rechts die beiden Zeitsummen eines gleichen Tages sollen addiert ausgegeben werden. Ist hier der SUM Befehl ein Ansatz? Wenn ja, wie könnte ich den hier verpacken?
ich möchte die Arbeitszeiten eines Mitarbeiters aus dem Infotyp 2011 direkt auslesen ohne FuBa.
Das hat gut geklappt. Nur, wenn der MA an einem Tag 2x stempelt, möchte ich diese Zeiten addieren.
Ich hatte die Idee, die erste Summe in einer Variable zwischenzuspeichern. Aber ich habs bisher nicht hinbekommen.
Code: Alles auswählen.
MOVE-CORRESPONDING p0001 TO ausgabe.
SORT p2011 BY ldate ltime.
LOOP AT p2011 WHERE ldate > '20181231'.
CLEAR: ausgabe-backupgehzeit, ausgabe-rechenergebnis, ausgabe-zwischensumme, ausgabe-tagesarbeitszeit.
MOVE p2011-ldate TO ausgabe-datum.
CASE p2011-satza.
WHEN 'P10'. MOVE p2011-ltime TO ausgabe-kommzeit. MOVE ausgabe-kommzeit TO ausgabe-backupkommzeit.
WHEN 'P20'. MOVE p2011-ltime TO ausgabe-gehzeit. MOVE ausgabe-gehzeit TO ausgabe-backupgehzeit. CLEAR: ausgabe-kommzeit, ausgabe-gehzeit, ausgabe-kurzbeschreibung.
WHEN '02'. MOVE p2011-ltime TO ausgabe-gehzeit. MOVE ausgabe-gehzeit TO ausgabe-backupgehzeit. CLEAR: ausgabe-kommzeit, ausgabe-gehzeit, ausgabe-kurzbeschreibung. MOVE 'ohne Pause' TO ausgabe-kurzbeschreibung.
ENDCASE.
CHECK ausgabe-backupgehzeit NE '000000'.
ausgabe-rechenergebnis = ausgabe-backupgehzeit - ausgabe-backupkommzeit.
MOVE ausgabe-backupkommzeit TO ausgabe-kommzeit.
MOVE ausgabe-backupgehzeit TO ausgabe-gehzeit.
MOVE ausgabe-rechenergebnis TO ausgabe-zwischensumme.
" ausgabe-tagesarbeitszeit = ausgabe-zwischensumme + ausgabe-rechenergebnis.
APPEND ausgabe.Rechts die beiden Zeitsummen eines gleichen Tages sollen addiert ausgegeben werden. Ist hier der SUM Befehl ein Ansatz? Wenn ja, wie könnte ich den hier verpacken?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
Hallo Wolfgang,
ja, das ändert an der Ausgabe nichts.
Gruß
Florian
ja, das ändert an der Ausgabe nichts.
Gruß
Florian
Hallo Florian,
leider ist nicht erkennbar wie die TB: Ausgabe definiert ist.
Wenn dort die Personalnummer neben den anderen numerischen Felder definiert ist sollte ein Collect klappen.
Es werden ja alle numerischen Felder mittels Collect addiert.
Wichtig ist ein Alpha-Feld wie die Personalnummer.
Gruß Wolfgang
leider ist nicht erkennbar wie die TB: Ausgabe definiert ist.
Wenn dort die Personalnummer neben den anderen numerischen Felder definiert ist sollte ein Collect klappen.
Es werden ja alle numerischen Felder mittels Collect addiert.
Wichtig ist ein Alpha-Feld wie die Personalnummer.
Gruß Wolfgang
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
Hallo Wolfgang,
also die TB Ausgabe sieht so aus:
Mir ist nicht ganz klar, wie ich den COLLECT jetzt definieren muss, damit er die Stunden eines selben Tages addiert.
Zu addieren wäre
also die TB Ausgabe sieht so aus:
Mir ist nicht ganz klar, wie ich den COLLECT jetzt definieren muss, damit er die Stunden eines selben Tages addiert.
Zu addieren wäre
Code: Alles auswählen.
rechenergebnis [T(6)]Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo Florian,
TB:Ausgabe
personalnr(8) type c,
alle Felder mit den Stunden etc.
Kein Name oder das Feld Zeile.
Den Namen kannst du später dazu holen.
Gruß Wolfgang
TB:Ausgabe
personalnr(8) type c,
alle Felder mit den Stunden etc.
Kein Name oder das Feld Zeile.
Den Namen kannst du später dazu holen.
Gruß Wolfgang
Folgende Benutzer bedankten sich beim Autor wreichelt für den Beitrag:
Florian9999
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
Ich habe der ausgabe folgende Zeile hinzugefügt (die anderen Variablen sind noch da, nur aus Platzgründen hier raus genommen)
"personalnr ist keine interne Tabelle", lautet die Fehlermeldung. Aber es ist ja als interne Tabelle definiert...
Wie muss hier die Syntax aufgebaut werden?
Code: Alles auswählen.
DATA: BEGIN OF ausgabe OCCURS 0,
personalnr(8) TYPE c,
END OF ausgabe.Code: Alles auswählen.
COLLECT ausgabe-rechenergebnis INTO ausgabe-personalnr."personalnr ist keine interne Tabelle", lautet die Fehlermeldung. Aber es ist ja als interne Tabelle definiert...
Wie muss hier die Syntax aufgebaut werden?
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Er könnte die Spalten auch drinlassen, das wäre überhaupt kein Problem, wenn er nicht einen Codingstil von Release 3.1 (oder noch früher) schreiben würde! Der COLLECT orientiert sich am Primärschlüssel der Tabelle. Wenn er seine Tabelle ausgabe mit einem unique key pernr definieren würde, dann würde der COLLECT darüber aufsummieren, egal was da noch an anderen Feldern da ist. Optimalerweise als sortierte oder Hashtabelle, dann wird der COLLECT gleich noch performanter (und der spätere Zugriff auf die Ergebnistabelle auch). Dazu müsste er sich freilich von der vorsintflutlichen Tabellendefinition über OCCURS 0 verabschieden. Auch von den ganzen MOVEs kriegt man Augenkrebs; nach meiner Erinnerung waren die zu 3.1i-Zeiten bereits deprecated. Vor allem der verwirrende Ketten-MOVE
Code: Alles auswählen.
MOVE p2011-ltime TO ausgabe-kommzeit. MOVE ausgabe-kommzeit TO ausgabe-backupkommzeit.Code: Alles auswählen.
ausgabe-kommzeit = ausgabe-backupkommzeit = p2011-ltime.Von more advanced stuff wie Feldsymbolen oder gar 7.40-Syntaxelementen will ich gar nicht erst anfangen.
Welches Release hast Du eigentlich, Florian?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Florian9999
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
ERP608 mit NW750 auf SP13
Da ich ganz am Anfang mit ABAP stehe... wie sieht denn so eine Abfrage in meinem o.g. Sinne mit moderner Syntax aus?
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Na, wenn Du schon auf Release 7.50 sitzt, dann kannst Du doch syntaktisch aus dem Vollen schöpfen. Wenn Du gerade erst anfängst, wer hat Dir denn dann diese antike Syntax beigebracht? Hast Du ein altes ABAP-Buch auf dem Speicher gefunden? So habe ich programmiert, als ich 2001 angefangen habe! ;-) Was ich allerdings gut finde, ist, dass Du dadurch auch nicht die komische ungarische Notation nutzt. Das solltest Du möglichst beibehalten (jedenfalls soweit Deine Auftraggeber das akzeptieren, denn leider nutzen fast alle Entwickler die ungarische Notation).
Bei der Analyse Deines Codes bin ich auch noch auf einen inhaltlichen Programmierfehler gestoßen:
Was bringt Dir der MOVE TO ausgabe-gehzeit, wenn Du gleich hinterher wieder CLEAR ausgabe-gehzeit machst? Aber das nur am Rande.
Bei näherer Betrachtung halte ich COLLECT in Deinem Fall doch nicht für so geeignet, weil COLLECT verlangt, dass die interne Tabelle nur numerische Felder als Nichtschlüsselfelder enthalten darf. Du willst ja aber offenbar z.B. auch Felder der P0001 drinhaben (ich bin mal exemplarisch von P0001-ENAME ausgegangen). Nun könntest Du natürlich eine separate Rechentabelle aufmachen, die dieser Bedingung genügt, darin die Werte zusammenCOLLECTen und anschließend diese Tabelle verwenden, um Deine eigentliche Tabelle ausgabe mit allen ihre Feldern aufzubauen. Das finde ich dann aber nicht mehr effizient.
Mir ist aber auch nicht klar, was Du da mit dem P2011-SATZA machst. Wir nutzen hier den Infotyp 2011 nicht, deswegen habe ich keine Beispielzeilen dieser Tabelle vorzuliegen, sondern nur ihre Definition laut SE11, aber ich sehe da als wesentliche Felder P2011-BEGUZ und P2011-ENDUZ (Beginn- und Endeuhrzeit) und würde in meiner Naivität vermuten, dass jede Zeile ein Stechuhreintrag ist und sich die Arbeitszeit eines solchen Stechuhreintrags nicht wie in Deinem Code angegeben, sondern aus P2011-ENDUZ minus P2011-BEGUZ errechnet?
Wenn die Ermittlung über die P2011-SATZA in Deinem Code richtig wäre, dann würde das ja bedeuten, dass Beginn- und Endezeit derselben Arbeitszeit in unterschiedlichen P2011-Zeilen liegen. Wenn jemand mehrfach am Tag ein- und ausstempelt, wäre dann die Frage, wie Du die richtige Paarung der Zeilen hinbekommst, welches Einstempeln also zu welchem Ausstempeln gehört. Oder geht das einfach chronologisch (erstes Ausstempeln gehört zum ersten Einstempeln usw.)? Aber wozu braucht man dann P2011-BEGUZ und P2011-ENDUZ?
Ich bin mal von meiner Theorie ausgegangen und habe Dein Coding basierend darauf ohne COLLECT umgestaltet und dabei die moderne, ab Release 7.40 erlaubte Syntax genutzt. Das sieht dann so aus:
Bei der Analyse Deines Codes bin ich auch noch auf einen inhaltlichen Programmierfehler gestoßen:
Code: Alles auswählen.
WHEN 'P20'. MOVE p2011-ltime TO ausgabe-gehzeit. MOVE ausgabe-gehzeit TO ausgabe-backupgehzeit. CLEAR: ausgabe-kommzeit, ausgabe-gehzeit, ausgabe-kurzbeschreibung.Bei näherer Betrachtung halte ich COLLECT in Deinem Fall doch nicht für so geeignet, weil COLLECT verlangt, dass die interne Tabelle nur numerische Felder als Nichtschlüsselfelder enthalten darf. Du willst ja aber offenbar z.B. auch Felder der P0001 drinhaben (ich bin mal exemplarisch von P0001-ENAME ausgegangen). Nun könntest Du natürlich eine separate Rechentabelle aufmachen, die dieser Bedingung genügt, darin die Werte zusammenCOLLECTen und anschließend diese Tabelle verwenden, um Deine eigentliche Tabelle ausgabe mit allen ihre Feldern aufzubauen. Das finde ich dann aber nicht mehr effizient.
Mir ist aber auch nicht klar, was Du da mit dem P2011-SATZA machst. Wir nutzen hier den Infotyp 2011 nicht, deswegen habe ich keine Beispielzeilen dieser Tabelle vorzuliegen, sondern nur ihre Definition laut SE11, aber ich sehe da als wesentliche Felder P2011-BEGUZ und P2011-ENDUZ (Beginn- und Endeuhrzeit) und würde in meiner Naivität vermuten, dass jede Zeile ein Stechuhreintrag ist und sich die Arbeitszeit eines solchen Stechuhreintrags nicht wie in Deinem Code angegeben, sondern aus P2011-ENDUZ minus P2011-BEGUZ errechnet?
Wenn die Ermittlung über die P2011-SATZA in Deinem Code richtig wäre, dann würde das ja bedeuten, dass Beginn- und Endezeit derselben Arbeitszeit in unterschiedlichen P2011-Zeilen liegen. Wenn jemand mehrfach am Tag ein- und ausstempelt, wäre dann die Frage, wie Du die richtige Paarung der Zeilen hinbekommst, welches Einstempeln also zu welchem Ausstempeln gehört. Oder geht das einfach chronologisch (erstes Ausstempeln gehört zum ersten Einstempeln usw.)? Aber wozu braucht man dann P2011-BEGUZ und P2011-ENDUZ?
Ich bin mal von meiner Theorie ausgegangen und habe Dein Coding basierend darauf ohne COLLECT umgestaltet und dabei die moderne, ab Release 7.40 erlaubte Syntax genutzt. Das sieht dann so aus:
Code: Alles auswählen.
TYPES: BEGIN OF TYPE_AUSGABE,
PERNR TYPE P2011-PERNR,
DATUM TYPE P2011-LDATE,
ENAME TYPE P0001-ENAME,
TAGESARBEITSZEIT TYPE P2011-LTIME,
* ... (add any desired additional fields here)
END OF TYPE_AUSGABE.
DATA: P0001 TYPE P0001,
T2011 TYPE SORTED TABLE OF P2011 WITH NON-UNIQUE KEY LDATE LTIME,
AUSGABE TYPE SORTED TABLE OF TYPE_AUSGABE WITH UNIQUE KEY PERNR DATUM,
WA_AUSGABE LIKE LINE OF AUSGABE.
* ... fill T2011 here
* SORT P2011 BY LDATE LTIME. " entfällt, da Tabelle bereits als SORTED definiert und daher automatisch immer sortiert ist
LOOP AT T2011 ASSIGNING FIELD-SYMBOL(<T2011>) WHERE LDATE > '20181231'. " LOOP sucht effizient, da er erkennt, dass seine WHERE-Bedingung mit dem Anfang des Primärschlüssels von T2011 übereinstimmt
* Zeile in Tabelle ausgabe für diese Personalnummer und diesen Tag suchen (unter Nutzung des Sortierschlüssels)
ASSIGN AUSGABE[ PERNR = <T2011>-PERNR DATUM = <T2011>-LDATE ] TO FIELD-SYMBOL(<AUSGABE>).
IF SY-SUBRC <> 0. " Gibt es noch keinen Eintrag für diese Personalnummer und dieses Datum?
INSERT VALUE #( PERNR = <T2011>-PERNR
DATUM = <T2011>-LDATE
ENAME = P0001-ENAME
TAGESARBEITSZEIT = <T2011>-ENDUZ - <T2011>-BEGUZ " Arbeitszeit dieses T2011-Eintrags berechnen
* ... (fill any desired additional fields here)
) INTO TABLE AUSGABE. " sortiert einfügen (Sortierung erfolgt automatisch anhand des Tabellenschlüssels)
ELSE.
<AUSGABE>-TAGESARBEITSZEIT = <AUSGABE>-TAGESARBEITSZEIT + <T2011>-ENDUZ - <T2011>-BEGUZ. " Das Feldsymbol <AUSGABE> zeigt direkt auf die Tabellenzeile. Wir brauchen also keinen MODIFY-Befehl mehr.
ENDIF.
ENDLOOP.
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
DeathAndPain hat geschrieben: ↑29.05.2019 14:36Wenn Du gerade erst anfängst, wer hat Dir denn dann diese antike Syntax beigebracht? Hast Du ein altes ABAP-Buch auf dem Speicher gefunden?
Sozusagen ... ;-)
Hier steht die Art der Stempelung drin. P10 für kommen; P20 für gehen und 02 für gehen ohne Pause.DeathAndPain hat geschrieben: ↑29.05.2019 14:36Mir ist aber auch nicht klar, was Du da mit dem P2011-SATZA machst.
Ich habe P2011-LTIME verwendet um nach P2011-SATZA Gehen normal und Gehen ohne Pause sortieren zu können. Daraufhin läuft die Auswertung hinaus, später.DeathAndPain hat geschrieben: ↑29.05.2019 14:36Wir nutzen hier den Infotyp 2011 nicht, deswegen habe ich keine Beispielzeilen dieser Tabelle vorzuliegen, sondern nur ihre Definition laut SE11, aber ich sehe da als wesentliche Felder P2011-BEGUZ und P2011-ENDUZ (Beginn- und Endeuhrzeit) und würde in meiner Naivität vermuten, dass jede Zeile ein Stechuhreintrag ist und sich die Arbeitszeit eines solchen Stechuhreintrags nicht wie in Deinem Code angegeben, sondern aus P2011-ENDUZ minus P2011-BEGUZ errechnet?
Bei P2011-BEGUZ und P2011-ENDUZ könnte ich das m.E. nach nicht?
Ja, genau. So siehts m.E. nach aus.DeathAndPain hat geschrieben: ↑29.05.2019 14:36Wenn die Ermittlung über die P2011-SATZA in Deinem Code richtig wäre, dann würde das ja bedeuten, dass Beginn- und Endezeit derselben Arbeitszeit in unterschiedlichen P2011-Zeilen liegen.
Chronologisch.DeathAndPain hat geschrieben: ↑29.05.2019 14:36Wenn jemand mehrfach am Tag ein- und ausstempelt, wäre dann die Frage, wie Du die richtige Paarung der Zeilen hinbekommst, welches Einstempeln also zu welchem Ausstempeln gehört. Oder geht das einfach chronologisch (erstes Ausstempeln gehört zum ersten Einstempeln usw.)
Für die ALV-Ausgabe.DeathAndPain hat geschrieben: ↑29.05.2019 14:36Aber wozu braucht man dann P2011-BEGUZ und P2011-ENDUZ?
Danke!DeathAndPain hat geschrieben: ↑29.05.2019 14:36Ich bin mal von meiner Theorie ausgegangen und habe Dein Coding basierend darauf ohne COLLECT umgestaltet und dabei die moderne, ab Release 7.40 erlaubte Syntax genutzt. Das sieht dann so aus:
Beitrag
von Florian9999 (ForumUser / 44 / 27 /
0
)
»
Ach ja. Und ich hab dir noch ne PN geschrieben :D
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
So richtig habe ich das nicht verstanden. Wenn Ein- und Ausstempeln unterschiedliche P2011-Einträge erzeugen (also vermutlich die Stechuhr bei jedem Stempeln eine Zeile anlegt), wie werden dann BEGUZ und ENDUZ gefüllt? "Merkt" die Stechuhr sich die Einstempelzeit, und trägt diese beim Ausstempeln dann als "BEGUZ" ein? Es wäre hilfreich, wenn Du per SE16 mal ein paar (anonymisierte) Beispielzeilen der PA2011 posten könntest, damit ich ein Gefühl dafür kriege, was in der Tabelle überhaupt genau drinsteht.Ich habe P2011-LTIME verwendet um nach P2011-SATZA Gehen normal und Gehen ohne Pause sortieren zu können. Daraufhin läuft die Auswertung hinaus, später.
Bei P2011-BEGUZ und P2011-ENDUZ könnte ich das m.E. nach nicht?
Aber wie dem auch sein mag, Du willst beide Zeilen auswerten und über LTIME gehen. Das kriegen wir auch noch hin.
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Report ZTEST6
*&---------------------------------------------------------------------*
REPORT ZTEST6.
TYPES: BEGIN OF TYPE_AUSGABE,
PERNR TYPE P2011-PERNR,
DATUM TYPE P2011-LDATE,
ENAME TYPE P0001-ENAME,
TAGESARBEITSZEIT TYPE P2011-LTIME,
SATZA TYPE P2011-SATZA,
* ... (add any desired additional fields here)
END OF TYPE_AUSGABE.
DATA: P0001 TYPE P0001,
T2011 TYPE SORTED TABLE OF P2011 WITH NON-UNIQUE KEY PERNR LDATE LTIME,
AUSGABE TYPE SORTED TABLE OF TYPE_AUSGABE WITH UNIQUE KEY PERNR DATUM,
KOMMZEIT TYPE P2011-LTIME.
* ... fill T2011 here
* SORT P2011 BY LDATE LTIME. " entfällt, da Tabelle bereits als SORTED definiert und daher automatisch immer sortiert ist
LOOP AT T2011 ASSIGNING FIELD-SYMBOL(<T2011>) WHERE PERNR = P0001-PERNR
AND LDATE > '20181231'. " LOOP sucht effizient, da er erkennt, dass seine WHERE-Bedingung mit dem Anfang des Primärschlüssels von T2011 übereinstimmt
IF <T2011>-SATZA = 'P10'.
KOMMZEIT = <T2011>-LTIME.
CONTINUE. " LOOP
ENDIF.
* Zeile in Tabelle ausgabe für diese Personalnummer und diesen Tag suchen (unter Nutzung des Sortierschlüssels)
ASSIGN AUSGABE[ PERNR = <T2011>-PERNR DATUM = <T2011>-LDATE ]-TAGESARBEITSZEIT TO FIELD-SYMBOL(<TAGESARBEITSZEIT>).
IF SY-SUBRC <> 0. " Gibt es noch keinen Eintrag für diese Personalnummer und dieses Datum?
INSERT VALUE #( PERNR = <T2011>-PERNR
DATUM = <T2011>-LDATE
ENAME = P0001-ENAME
TAGESARBEITSZEIT = <T2011>-LTIME - KOMMZEIT " Arbeitszeit berechnen
SATZA = <T2011>-SATZA " Gehen normal oder Gehen ohne Pause merken für spätere Auswertung
* ... (fill any desired additional fields here)
) INTO TABLE AUSGABE. " sortiert einfügen (Sortierung erfolgt automatisch anhand des Tabellenschlüssels)
ELSE.
<TAGESARBEITSZEIT> = <TAGESARBEITSZEIT> + <T2011>-LTIME - KOMMZEIT. " Das Feldsymbol <TAGESARBEITSZEIT> zeigt direkt auf das Feld in der Tabellenzeile. Wir brauchen also keinen MODIFY-Befehl mehr.
ENDIF.
ENDLOOP.Mein obenstehender Code wird nur funktionieren, wenn vor jeder Gehzeit wie versprochen eine Kommtzeit kommt, dieses zugesicherte Konsistenzkriterium also erfüllt ist. Außerdem vermerkt er nur den SATZA der ersten Gehzeit in der ausgabe; unterstellt also, dass es nicht am selben Tag einen P20 und einen 02 geben wird (was nach meinem Verständnis auch inhaltlich keinen Sinn machen würde). Natürlich könnte man meinen Code um zusätzliche Abfragen anreichern, die nachprüfen, ob die Konsistenz gewahrt ist.
Ich habe jetzt auch noch die Personalnummer mit in den Schlüssel der Tabelle T2011 genommen, damit Du auch mehrere Personalnummern auf einmal in diese interne Tabelle einlesen kannst und der Code dennoch funktioniert. Man sollte ja möglichst alles, was man braucht, auf einmal lesen und nicht für jede Personalnummer einen einzelnen SELECT machen. Außerdem habe ich den ASSIGN-Befehl noch verfeinert und lasse anstatt der ganzen Tabellenzeile nur noch das eine benötigte Feld zuweisen. Das ist noch etwas eleganter.
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2516
Views
Views
0
Antw.
Antw.
1414
Views
Views
Doppelte Zeitereignisse im IT2011 während der Abrechnung
von mgennari » 29.05.2009 18:10 • Verfasst in Human Resources
von mgennari » 29.05.2009 18:10 • Verfasst in Human Resources
2
Antw.
Antw.
3078
Views
Views
2
Antw.
Antw.
6491
Views
Views
3
Antw.
Antw.
2235
Views
Views
Monatbrutto mit FuBa RP_FILL_WAGE_TYPE_TABLE auslesen
von Florian9999 » 29.04.2019 17:05 • Verfasst in Human Resources
von Florian9999 » 29.04.2019 17:05 • Verfasst in Human Resources
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 9 Stunden von ralf.wenzel 104 / 10037
vor 9 Stunden von ralf.wenzel 104 / 10037
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 9 Stunden von ralf.wenzel 104 / 10037
vor 9 Stunden von ralf.wenzel 104 / 10037