SAP Jobsuche bei DV-Treff


Suchen
anfaenger
vor 2 Jahre
Hallo,

ich habe eine Frage zur einer Gruppenkondition und deren Verteilung auf Positionen.

Diese wird bei Auftragserfassung ermittelt und anteilig auf alle Auftragspositionen verteilt.

Bei Fakturierung allerdings wird der komplette Konditionswert (aller Positionen) dieser Kondition in die erste Position gesetzt, die anderen Positionen haben den konditionsanteil aus dem Auftrag nicht mehr.

Wenn ich in der Faktura eine neue Preisfindung mache, ist der Wert wieder auf die Positionen verteilt.

Frage: handelt es sich hier um Standardverhalten? Ich habe weder im Schema noch in der Kopiersteuerung was dazu finden können.

VG


ECC 6.07, NW 7.4, SD, Logistik, C4C, EDI
157
  • 157
  • SAP Forum - Guru
vor 2 Jahre
Hallo anfaenger,

ich keine beide Möglichkeiten einer Kopfkondition in der Faktura komplett auf die erste Position mit der ersten Rechnung zu berechnen oder diese wie im Auftrag verteilt zu fakturieren.

Jedes Verfahren hat seine positiven wie negativen Auswirkungen.

Wir haben damals auf das Verfahren erste Position erste Rechnung umgestellt-

Für uns war damals entscheiden, das die Kunden dies in der ersten Faktur nicht verstanden haben, warum der Wert der Kopfkonditon so "unrund" war. Außerdem hat das verteilte Fakturieren Rundungsprobleme erzeugt zumindest wenn es eine Teilrechnung gab.

Also du merkst entscheidend war die hohe Anzahl an Teilfakturen.


Gruss 157
SanduhrAnzeigeProgramm
vor 2 Jahre
Zitat von: anfaenger 

...

Bei Fakturierung allerdings wird der komplette Konditionswert (aller Positionen) dieser Kondition in die erste Position gesetzt, die anderen Positionen haben den konditionsanteil aus dem Auftrag nicht mehr....

Das ist kein Standard, aber hört sich für mch sehr nach dem Modifikationsvorschlag der SAP zum Thema Frachtkondition und Teilfakturen an, OSS 25144

Zitat:

"Dieser Hinweis bewirkt ..., daß ... der Gesamtwert der Kopfkondition in die erste Position der ersten Faktura eingestellt wird"

P.S. Teil 2 des Themas ist in OSS 434526, der 25144 ist aber der "Erklärbär" - Hinweis


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

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