SAP Jobsuche bei DV-Treff


Suchen
Free SPRO
  • Free SPRO
  • SAP Forum - Experte Thema Starter
vor 6 Jahre
Hallo Allerseits,

ich hab hier zwei Konditionen die über Konditionsausschluss gesteuert werden sollen. Konkret geht es um Frachtkostenkonditionen. Hier haben wir zu einen eine Kondition für die Basisfracht ZHD0 (also z.B. 45,- € pro Sendung) und zum anderen eine gestaffelte Frachttabelle ZHDa, abhängig von den Gewichten der Sendung (z.B. 20,- € per 100 kg; ab 500 kg 15,- € per 100 kg; ab 3000 kg 12,- € per 100 kg etc.)

Nun soll bei einer Sendung von z.B. 20 kg die Basisfracht von 45,- € gezogen werden. Bei einer Sendung von 300 kg soll aber die Basiskondition deaktiviert und stattdessen die gewichtsbezogene Staffel gezogen werden = 60,- €.

Zu Erwähnen ist noch dass die Konditionssätze als Gruppenkondition mit Routine 1 (Gesamtbeleg) definiert sind. Zudem sind beide Konditionsarten sowohl als Kopf- als auch als Pos.kondition definiert um hier eine Zugrifsfolge hinterlegen zu können.

Nun funktioniert die Logik wie gewünscht sobald ich z.B. 2 Positionen a 500 kg im Auftrag hab, dann wird korrekt die ZHDa, in dem Fall ab 1000 kg, aktiv gesetzt. Bei einer Sendung von z.B. 5 Positionen a 20 kg wird die ZHD0 aktiviet was ebenfalls korrekt ist.

Mein Problem entsteht jedoch wenn im Auftrag z.B. eine Position von 1000 kg und eine Position mit 20 kg angelegt wird. In diesem Fall hab ich im Kopf jeweils eine aktive und eine inaktive Kondition der ZHD0 und der ZHDa, es werden also 4 Elemente dargestellt. Offensichtlich funktioniert in diesem Fall die Gruppierung (Gruppenkondition) nicht. 😕

Jemand eine Idee?

Free SPRO
  • Free SPRO
  • SAP Forum - Experte Thema Starter
vor 5 Jahre
Hallo Allerseits,

ich habe auch heute noch bzw. wieder mit dem o.g. Problem zu kämpfen. Hatte es zwischenzeitlich mit einem UserExit gelöst, was ja eigentlich das letzte Mittel sein sollte.

Jetzt wollen wir aber für eine Schnittstelle eine Order_Simulation machen, dort werden UserExits im Save_prepare aber nicht berücksichtigt. Somit ist das Problem für mich wieder akut.

Jemand von den Profis eine Idee?

SanduhrAnzeigeProgramm
vor 5 Jahre
Der einzige vollkommen unproblematische Fall der mir dazu gerade einfällt ( da ich ihn in der Praxis einsetze) ist, dass die Kopfkondition nur befüllt wird, wenn über Konditionssätze nichts in den Beleg eingestellt wurde. Dann ist das natürlich total unproblematisch.

Ein Praxisfall der mir hierzu einfällt ist, dass eine Konditionsart von dem einen Geschäftsbereich als Konditionssatz gepflegt wird der andere immer von Hand auf Kopfebene eingibt.

In den meisten anderen Fällen (eventuelle habe ich zu wenig Fantasie) ist es immer Problemanfällig Konditionen als Kopf- und Positionskondition zu verwenden wenn beides gleichzeitig einen Wert zur selben Kondition, in der selben Pos. liefert.

Dann sind mir solche "Mehrfachzeilen" wie du sie beschreibst, nämlich auch schon begegnet.

Auch das manuelle bearbeiten von ursprünglichen Kopfkonditionen in der Position kann zu "unlogischen" Ergebnissen führen.

Außerdem ist zu beachten, dass die Preifindung für Positionsübergreifende Konditionen (also z.B. Gruppenkonditionen) nach der Preisfindung von Positionen läuft inkl. der Logiken der Konditionsausschlüsse. Gewisse Ausschlüsse können mangels noch nichterfolgter Preisfindung also nicht funktionieren bzw. nicht ohne Programmierung.

In deinem Fall handelt es sich um Auschlüsse zwischen 2 Gruppenkonditionen wenn ich das richtig verstehe und dann musst du auf die Funktionseinschränkung:

"Abschließend kann für Gruppenkonditionen in Ausschlußgruppen daher folgendes Fazit getroffen werden:

Soll eine Gruppenkondition 'B' eine Gruppenkondition 'A' ausschliessen, so darf 'A' keinen Einfluß auf die Ermittlung der Basis von Konditionen haben, welche (gemäss Stufennummer im Kalkulationsschema) zwischen 'A' und 'B' liegen."

siehe auch 217009 - Konditionsausschluss bei Gruppenkonditionen

Ich hoffe meine Ausführungen helfen wenigstens etwas!?


*... who can do field replacements in the debugger can do anything in the system

*so this check can (not) stop (him) anyway.