Maschinelle Lohnsteuerberechnung für 2019


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Maschinelle Lohnsteuerberechnung für 2019

Beitragvon cgreiner » 27.11.2018, 20:44

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
cgreiner
ForumUser
 
Beiträge: 17
Registriert: 18.10.2018, 17:12
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon a-dead-trousers » 27.11.2018, 23:19

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
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.07
Basis: 7.40

Für diese Nachricht hat a-dead-trousers einen Dank bekommen :
SaskuAc
a-dead-trousers
Top Expert
 
Beiträge: 3107
Registriert: 07.02.2011, 13:40
Dank erhalten: 767 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon SaskuAc » 28.11.2018, 06:07

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 ;)
SaskuAc
Specialist
 
Beiträge: 215
Registriert: 01.06.2015, 10:16
Dank erhalten: 21 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon ralf.wenzel » 28.11.2018, 09:52

cgreiner hat geschrieben:c) objekt-orientiert, auch als Funktionsbaustein


Öhhhhm..... Bitte was?


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon deejey » 28.11.2018, 10:43

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
deejey
Specialist
 
Beiträge: 150
Registriert: 31.07.2016, 11:20
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon ralf.wenzel » 28.11.2018, 10:46

Am Postfach kann es nicht liegen - "Ordner ist zu 6% voll (6 von 100 Nachrichten gespeichert)"


Ralf
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon wreichelt » 28.11.2018, 10:56

Hallo,

den aktuellen Plan gibt es hier:

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

hab sowas schon mal in COBOL gemacht.

Gruß Wolfgang
wreichelt
Expert
 
Beiträge: 658
Registriert: 17.07.2005, 09:46
Wohnort: Hessen
Dank erhalten: 110 mal
Ich bin: sonstiges

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon deejey » 28.11.2018, 11:46

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.
deejey
Specialist
 
Beiträge: 150
Registriert: 31.07.2016, 11:20
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon cgreiner » 28.11.2018, 11:47

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...
cgreiner
ForumUser
 
Beiträge: 17
Registriert: 18.10.2018, 17:12
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon ralf.wenzel » 28.11.2018, 12:11

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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon DeathAndPain » 29.11.2018, 17:40

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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon ralf.wenzel » 29.11.2018, 19:10

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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon SaskuAc » 30.11.2018, 06:29

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 ^^ )
SaskuAc
Specialist
 
Beiträge: 215
Registriert: 01.06.2015, 10:16
Dank erhalten: 21 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon DeathAndPain » 30.11.2018, 13:01

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.)

Für diese Nachricht hat DeathAndPain einen Dank bekommen :
Romaniac
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitragvon ralf.wenzel » 30.11.2018, 14:13

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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Nächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Umrechnung Stück in KG
vor 3 Minuten von wreichelt 2 Antw.
gelöst Sel.Screen in Subscreen - VA06
vor 16 Stunden von bapimueller 2 Antw.
gelöst Prüfen Konfiguration Kundenauftrag gene Type
vor 22 Stunden von mfromg 0 Antw.
Auswertung Orders erhalt per Mail oder FAX oder beides
vor 16 Stunden von ewx 2 Antw.
SAP und Gamification
Gestern von ewx 1 Antw.

  Ähnliche Beiträge beta
Keine Beiträge gefunden - versuche es mit der erweiterten Suche.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder