Maschinelle Lohnsteuerberechnung für 2019

Getting started ... Alles für einen gelungenen Start.
57 Beiträge • Seite 1 von 4 (current) Nächste
57 Beiträge Seite 1 von 4 (current) Nächste

Maschinelle Lohnsteuerberechnung für 2019

Beitrag von cgreiner (ForumUser / 17 / 2 / 0 ) »
Wer von Euch hat sich schon mit dem Thema in ABAP befasst?
a) konventionelle Programmierung
b) als Funktionsbaustein
c) objekt-orientiert, auch als Funktionsbaustein

Erfahrungsaustausch in Bereich HR und allen anderen natürlich auch interessiert!

cg

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Das ist jetzt nur als Vorwarnung zu verstehen.
Leider kann ich dir bei deinem konkreten Problem in HR keine Tipps geben.
Ich hoffe aber du weißt, was du hier gerade losgetreten hast.
Die Diskussionen die hier im Forum immer wieder ausbrechen zum Thema OO oder klassisch prozedural können ganze Bibliotheken füllen.

Trotzdem viel Glück.
ADT

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
SaskuAc

Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
a-dead-trousers hat geschrieben:Das ist jetzt nur als Vorwarnung zu verstehen.
Leider kann ich dir bei deinem konkreten Problem in HR keine Tipps geben.
Ich hoffe aber du weißt, was du hier gerade losgetreten hast.
Die Diskussionen die hier im Forum immer wieder ausbrechen zum Thema OO oder klassisch prozedural können ganze Bibliotheken füllen.
wobei ich nicht glaube, das Leute, die keine Erfahrung mit HR haben, hier wohl eher nicht drauf gehen. ( der Titel ist dann schon recht spezifisch .. ^^ )

@Cgreiner: ich glaube, dass sich hier nur wenige Leute rum treiben die das schon gemacht haben. Mit ABAP aber eher nein. Generell weiß ich nicht genau, was du eigentlich möchtest. Willst du ein Programm, welches die Berechnung automatisch macht ( so zum Jahresabschluss? ) Bin mir nicht ganz sicher. Kann aber mal schauen ob wir bei uns ein Z*Programm für sowas haben ..

und damit ich ADT nicht enttäusche, ich würde dir soweit möglich immer OO-Empfehlen, wobei das in HR ( wenn du dir nicht eine Herscharr an Z-Klassen bauen willst ) eher schwierig ist. SAP vernachlässigt hier den Support extremst... Sie setzen leider alles in SuccessFactors, was ich persönlich nicht schön finde.. ( wobei ja angeblich ab 2023 eine S/4Hana Suite für HR kommen soll .. freu mich schon!.... auch wenn nur support bis 2030 zugesagt wurde... )
Aber wenn du ein wenig Zeit hast und keine Mühen scheust, würde ich dir empfehlen einmal eine ordentliche Anzahl an Klassen für HR zu bauen ( z. B. kann man eine ZCL_HR_EMPLOYEE immer sehr gut gebrauchen ;) ) - Dann hast du's sehr viel leichter als immer die funktionsbausteine zu verwenden .. Bei den Klassen und Methoden kann man ( zumindest, wenn sie so umgesetzt sind wie bei uns ) immer schön in einer Zeile sehen was getan werden soll. Aber damit das alles funktioniert, hat mein Kollege ( der hier die HCM Suite, von der Programmierungsseite her, praktisch alleine aufgebaut hat ) ca. ein halbes Jahr eingesetzt. Jetzt können wir aber alles was zu einem Mitarbeiter, einem OM-Objekt, einem EREC-Objekt, usw. gehört, innerhalb einer Zeile abbilden und es ist auch noch performant! Daher würde ich dir empfehlen, einfach mal ein wenig Zeit und Geld in die Hand zu nehmen und deine HR-Suite aufzufrischen mit ein paar OO-Klassen ;)

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
cgreiner hat geschrieben:c) objekt-orientiert, auch als Funktionsbaustein
Öhhhhm..... Bitte was?


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
ralf.wenzel hat geschrieben:
cgreiner hat geschrieben:c) objekt-orientiert, auch als Funktionsbaustein
Öhhhhm..... Bitte was?
Dein Postfach ist übrigens voll/gesperrt, kann nicht antworten

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Am Postfach kann es nicht liegen - "Ordner ist zu 6% voll (6 von 100 Nachrichten gespeichert)"


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von wreichelt (Top Expert / 1031 / 29 / 188 ) »
Hallo,

den aktuellen Plan gibt es hier:

https://www.bundesfinanzministerium.de/ ... -2019.html

hab sowas schon mal in COBOL gemacht.

Gruß Wolfgang

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
ralf.wenzel hat geschrieben:Am Postfach kann es nicht liegen - "Ordner ist zu 6% voll (6 von 100 Nachrichten gespeichert)"


Ralf
klappt nicht:

Einige Benutzer konnten nicht hinzugefügt werden, da sie den Empfang Privater Nachrichten deaktiviert haben.

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von cgreiner (ForumUser / 17 / 2 / 0 ) »
wreichelt hat geschrieben:Hallo,

den aktuellen Plan gibt es hier:

https://www.bundesfinanzministerium.de/ ... -2019.html

hab sowas schon mal in COBOL gemacht.

Gruß Wolfgang
Hallo Wolfgang,

Entwickle seit etliche Jahren im Lohn/Gehalt-Bereich und auch die Steuerformel laut Angaben des Bundesministerium liegen in verschiedenen Programmiersprachen zur Verfügung, auch in Cobol und Abap.

Auf keinen Fall wollte ich eine Diskussion über konventionelle und objekt-orientierte Programmierung anstoßen, glaubt man aber den Anzeigen und Personalvermittler in SAP-Umfeld sind hauptsächlich OO-Entwickler gefragt, weil jeder auf den Zug aufspringen will.
Ich will aber auch hier keine überflüssige Debatte anstoßen, der Markt entscheidet...

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
cgreiner hat geschrieben:Auf keinen Fall wollte ich eine Diskussion über konventionelle und objekt-orientierte Programmierung anstoßen, glaubt man aber den Anzeigen und Personalvermittler in SAP-Umfeld sind hauptsächlich OO-Entwickler gefragt, weil jeder auf den Zug aufspringen will.
Ja, weil die Anwendungen immer komplexer und anspruchsvoller werden. Der Batch-Input ist halt nicht mehr gefragt und ab einer gewissen Komplexität lohnt sich das. Außerdem muss man das zunehmend in OO geschriebene Coding der SAP verstehen können, wozu (oft auch massive) OO-Kenntnisse erforderlich sind. Ich hatte aber auch schon Fälle, wo ich gefragt wurde, ob ich auch "ABAP-Null-Null" kann. Ohne Witz. Das sind dann Leute, die haben was gesehen und wollen das auch.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
saskuac hat geschrieben:Jetzt können wir aber alles was zu einem Mitarbeiter, einem OM-Objekt, einem EREC-Objekt, usw. gehört, innerhalb einer Zeile abbilden und es ist auch noch performant!
Das ist eben die Frage, ob es performant ist, denn mit solch eierlegender Wollmilchsauklasse liest Du - genau wie die SAP mit ihren Funktionsbausteinen - in aller Regel deutlich mehr Daten als die, die Du im jeweiligen Kontext gerade brauchst. Ich sehe den Nutzen, bin aber vorsichtig mit dem extremen Jubel. Ein SELECT ist schnell programmiert, auch nicht lang, ohne Studium eines Methodeninterfaces gut verständlich und liest dann genau das, was Du im jeweiligen Kontext brauchst.

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ein SELECT ist schnell programmiert, eine generische Persistenzschicht ist etwas mehr Arbeit, ist aber wiederverwendbar und kann punktgenau selektieren, wenn man weiß, wie man sowas macht. Und man hat mehrere Teilschichten, die man ändern kann, um mehr oder weniger global Änderungen durchzuführen.


Ralf *steht nicht auf Einweg
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
DeathAndPain hat geschrieben:
saskuac hat geschrieben:Jetzt können wir aber alles was zu einem Mitarbeiter, einem OM-Objekt, einem EREC-Objekt, usw. gehört, innerhalb einer Zeile abbilden und es ist auch noch performant!
Das ist eben die Frage, ob es performant ist, denn mit solch eierlegender Wollmilchsauklasse liest Du - genau wie die SAP mit ihren Funktionsbausteinen - in aller Regel deutlich mehr Daten als die, die Du im jeweiligen Kontext gerade brauchst. Ich sehe den Nutzen, bin aber vorsichtig mit dem extremen Jubel. Ein SELECT ist schnell programmiert, auch nicht lang, ohne Studium eines Methodeninterfaces gut verständlich und liest dann genau das, was Du im jeweiligen Kontext brauchst.
Ich gebe dir zwar recht, dass ein select schnell programmiert und performanter ist. Vorausgesetzt man programmiert den richtig. Und man macht davor noch eine Berechtigungsprüfung .. Nun haben wir einen haufen Entwickler welche das nicht machen. Da wird vergessen im select aufs Datum einzugrenzen und machen danach einen loop über die interne Tabelle und prüfen dort dann aufs datum. Das macht es einerseits unnötig kompliziert und gleichzeitig wird dann die performance erheblich schlechter.
Diese probleme haben wir mit der Klasse nicht. Aber allgemein haben wir die Klasse schon so programmiert, dass die performance sehr gut ist und nur das selektiert was man braucht. ( wie gesagt, wir haben eine Herscharr an Klassen entwickelt - damit man nirgends zu viele Daten selektiert, welche nicht gebraucht werden. )

Außerdem ist es ein einzeiler, welcher gut zu lesen ist und immer funktioniert. Da kann man nichts dran aussetzen.
Natürlich, wenn wir mal ein programm schreiben, welches rein auf performance aus ist ( z. B. ein BW-Extraktor der abermillionen von Datensätzen lesen muss und ich da auch auf jedes Bisschen achten muss ) dann schreibe ich einen SELECT. Aber sonst? So mache ich keine Fehler und habe immer das was ich brauche.

Das schöne ist, die Klassen puffern einwandfrei, heißt, wenn man einmal einen Datensatz gelesen hat, greift die Klasse danach nicht mehr auf die Datenbank zu, sondern puffert alles intern - was dann sogar wieder schneller ist als der direkte Select. ( natürlich, wenn wir das beispiel von oben nehmen, den BW-Extraktor, nutze ich den Select dennoch. Da sonst der speicher voll läuft und dann hat man nichts gewonnen ^^ )

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ralf hat geschrieben:Ein SELECT ist schnell programmiert, eine generische Persistenzschicht ist etwas mehr Arbeit, ist aber wiederverwendbar und kann punktgenau selektieren, wenn man weiß, wie man sowas macht.
Fragt sich nur, was der Vorteil ist. Mit einem SELECT kann man nämlich auch punktgenau selektieren :P , und einen einzelnen Befehl (nämlich SELECT) in ein Konstrukt zu kapseln, dessen größter Vorteil es ist, (im günstigsten Fall) das zu können, was der eine Befehl auch kann, finde ich eine äußerst zweifelhafte Entscheidung.

Sobald man eine Sammlung zusammengehörender Daten lesen möchte, zwischen denen ein logischer Zusammenhang besteht, so dass man solch Sammlung häufiger benötigt, macht eine Kapselung Sinn. Aber nicht für den einzelnen SELECT.

Schau Dir doch die Krücken an, die die SAP da liefert. Bei der SAP sind es meist noch Funktionsbausteine, aber ob ich einen FB oder eine statische Klasse aufrufe, die mir die Daten von der Datenbank liest und zurückliefert, macht jetzt nicht den Unterschied. Da brauchste einen einzigen Wert, aber der FB liefert eine komplette Ergebnistabelle mit allen Spalten, so dass Du nach dem Aufruf erst mal einen LOOP darüber machen musst, um dann in der WHERE-Bedingung des LOOPs doch wieder Deine tatsächlich relevanten Bedingungen unterzubringen und anschließend die eine Spalte zu verwerten, die Du eigentlich haben wolltest. Dass der FB dabei noch ohne Ende Customizingoptionen liest und auswertet, von denen Du genau weißt, dass sie für Deine konkrete Anfrage völlig irrelevant sind (selbst wenn die dadurch eingestellte Funktionalität im Unternehmen tatsächlich genutzt wird), kommt erschwerend hinzu.
SaskuAc hat geschrieben:Ich gebe dir zwar recht, dass ein select schnell programmiert und performanter ist. Vorausgesetzt man programmiert den richtig.
Wenn Du Deine Datenzugriffe nicht vernünftig programmierst, dann ist Dein Code so oder so Mist. Ich gebe Dir recht, dass man in dem Bereich sehr häufig Schlamperei sieht. Aber ich behaupte, Schlamperei bekommt man mit einem Methodenaufruf auch hin. (Das halte ich für einen der verbreitetsten Trugschlüsse unter OO-Apologeten, dass OO für besseren Code sorgen würde, indem es die Leute dazu zwingt, sauberer zu arbeiten. Ich halte eher das Gegenteil für zutreffend, denn wenn man mit den OO-Konstrukten schlampig umgeht, dann hat ein anderer hinterher noch viel weniger eine Chance, da durchzusehen, als wenn man dasselbe mit herkömmlicher prozeduraler Programmierung macht.)
SaskuAc hat geschrieben:Und man macht davor noch eine Berechtigungsprüfung ..
Tatsächlich braucht man die in sehr vielen Fällen nicht wirklich, weil die gelesenen Daten nach meiner Erfahrung in den meisten Fällen nicht berechtigungskritisch sind. Und das sage ich als jemand, der (wie Du) im HCM unterwegs ist, wo Berechtigungen generell eine große Rolle spielen.
SaskuAc hat geschrieben:Aber allgemein haben wir die Klasse schon so programmiert, dass die performance sehr gut ist und nur das selektiert was man braucht. ( wie gesagt, wir haben eine Herscharr an Klassen entwickelt - damit man nirgends zu viele Daten selektiert, welche nicht gebraucht werden. )
Das grundsätzliche Problem, das Du Dir damit einhandelst, ist, dass jemand, der den Code liest, verstehen muss, was Deine Klasse macht. Ggf. muss er sich in die Doku Deiner Klasse einlesen oder gar in den Quelltext schauen, wie genau Deine Datumsparameter zu interpretieren sind etc. Das ist eben die Sache mit Methoden: Sie sind eine Form von selbstprogrammierten Befehlen, was bedeutet, dass niemand sie kennt, obwohl er ABAP kann. Noch schlimmer wird es, wenn da ein Bug drin ist, denn dann weißt Du nie genau, ob das wirklich ein Bug ist oder ob Du nur das Sollverhalten der Methode nicht richtig verstanden hast. Bei ABAP-Befehlen stellt sich diese Frage so gut wie gar nicht; da kennst Du das Sollverhalten ganz genau.

Und dass man einen Bug in einem fremden Code finden soll, würde ich sogar als alltägliches Vorkommnis bezeichnen wollen.

Wenn da aber steht:

Code: Alles auswählen.

SELECT WERKS BTRTL INTO TABLE M FROM PA0001
 WHERE PERNR IN S_PERNR
   AND SUBTY = SPACE
   AND OBJPS = SPACE
   AND SPRPS = SPACE
   AND ENDDA >= SY-DATUM
   AND BEGDA <= SY-DATUM.
dann weiß ein Modulfremder zwar möglicherweise nicht, was ich da inhaltlich lese, weil er kein HCM-ler ist, aber selbst er kann auf der Grundlage seines ABAP-Grundwissens ganz präzise sagen, was da technisch passiert. Ist man nicht modulfremd, dann kann man den SELECT damit auf einen Blick zu 100% interpretieren (Da Du HCM-ler bist, habe ich keinen Zweifel, dass Du sofort gesehen und verstanden hast, was ich da lese). Und das, obwohl es kein Einzeiler ist und obwohl Du das umgebende Programm nicht kennst (welches in dem Fall auch nicht existiert, da ich mir dieses Beispiel rasch aus den Fingern gesogen habe).
Das schöne ist, die Klassen puffern einwandfrei, heißt, wenn man einmal einen Datensatz gelesen hat, greift die Klasse danach nicht mehr auf die Datenbank zu, sondern puffert alles intern - was dann sogar wieder schneller ist als der direkte Select.
Und dann bekommst Du komische Werte, weil die Daten auf der Datenbank sich inzwischen verändert haben und Deine Klasse aus ihrem veralteten Puffer liefert. Gewiß wirst Du für solche Fälle irgendeine Form von Refresh-Methode vorgesehen haben, aber da steigt doch sofort wieder die Komplexität, und man muss wissen, wie die Pufferung der Klasse genau arbeitet, und wehe, das, was Du über das Sollverhalten der Klassenpufferung zu wissen glaubst, deckt sich nicht zu 100% mit dem, was sie tatsächlich macht.

Und dann brauchst Du die drei Felder A, B und C. Also musst Du nacheinander drei Methoden aufrufen, für jedes der drei Felder eine. Im Pechfall wird dann dreimal aus derselben Datenbanktabelle gelesen. Oder andersrum Dir reicht Feld A, aber da die Klasse damit rechnet, dass Du im weiteren Verlauf möglicherweise auch die Felder B-Z anfordern wirst, macht sie gleich einen SELECT * in ihren Puffer. Nachher brauchst Du dann tatsächlich Feld H, freilich über einen Schlüssel, der kein Schlüssel der internen Puffertabelle Deiner Klasse ist, wohl aber als Datenbankindex auf der Datenbank existiert... (In dem Zusammenhang: wenn ich aus der HRP1001 lese, dann lese ich fast immer über den Index 3, weil der um Größenordnungen besser ist als der Primärschlüssel der Tabelle. Derjenige SAP-ler, der diesen Index angelegt hat, hat wirklich mal verstanden, wie man mit SQL-Tabellen effizient umgehen muss.)

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Romaniac


Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
DeathAndPain hat geschrieben:
Ralf hat geschrieben:Ein SELECT ist schnell programmiert, eine generische Persistenzschicht ist etwas mehr Arbeit, ist aber wiederverwendbar und kann punktgenau selektieren, wenn man weiß, wie man sowas macht.
Fragt sich nur, was der Vorteil ist. Mit einem SELECT kann man nämlich auch punktgenau selektieren :P , und einen einzelnen Befehl (nämlich SELECT) in ein Konstrukt zu kapseln, dessen größter Vorteil es ist, (im günstigsten Fall) das zu können, was der eine Befehl auch kann, finde ich eine äußerst zweifelhafte Entscheidung.
Welchen Teil von "generische Persistenzschicht" hast du nicht verstanden? Es geht nicht darum, jeden einzelnen SELECT zu kapseln, sondern generisch einen SELECT für alle DB-Zugriffe bereitzustellen. Und die Methode, die schließlich den SELECT macht, in einer Unterklasse gegen ein IMPORT FROM DATABASE zu redefinieren, um über dieselbe Persistenzschicht Cluster-Tabellen zu lesen.

Für das Schreiben gilt Entsprechendes.
DeathAndPain hat geschrieben:Schau Dir doch die Krücken an, die die SAP da liefert.
Die sind mit dem, womit ich gerade arbeite, nicht im Ansatz vergleichbar.
DeathAndPain hat geschrieben:ob ich einen FB oder eine statische Klasse aufrufe
Wer hat hier was von "statisch" geschrieben?


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

2
Antw.
1587
Views
maschinelle Zahlung per Bankeinzug?
von hakan_gueven@yahoo.de » 07.05.2008 09:51 • Verfasst in Financials
5
Antw.
1863
Views
Maschinelle Änderung von Varianten
von KlausB » 02.03.2009 17:31 • Verfasst in ABAP® Core
4
Antw.
11374
Views
maschinelle Buchung mehr als 999 Positionen
von schnaku » 13.02.2009 11:26 • Verfasst in Financials
3
Antw.
3133
Views
Maschinelle Kopieren von Rollen funktioniert nicht
von Adalan » 20.08.2012 09:35 • Verfasst in ABAP® Core

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141