SAP Jobsuche bei DV-Treff


Suchen
hbr@bulth
  • hbr@bulth
  • SAP Forum - Experte Thema Starter
vor 10 Jahre
Hallo zusammen,

folgendes Problem:

Beim Anlegen von Rahmenverträgen/Kontrakten nutzen wir die Funktion "Bezug zur Banf", um Daten aus vorher angelegten und freigegebenen Bestellanforderungen zu nutzen. Funktioniert im Normalfall auch ganz gut.

Wurde aber ein Rahmenvertrag, der sich auf eine bestimmte Banf bezieht wieder gelöscht (bzw. zum Löschen vorgemerkt), dann steht zwar in der Banf eine offene Menge, die Bestellanforderung wird aber über die Selektion der ME31K nicht mehr gezogen - außer man nimmt den Haken bei "Nur offene" raus.

Die Banf zeigt also eine offene Menge, wird bei der Selektion aber nicht als offen erkannt. Nach etwas Recherche bin ich darauf gestoßen, dass diese Banfen in der EBAN nach wie vor beim Bearbeitungsstatus das Kennzeichen K mitführen, was soviel heißt wie "Kontrakt erstellt".

Bin mir jetzt nicht sicher, ob das ein Bug oder ein "Feature" ist... Jedenfalls werden solche Banfen dann mal gerne übersehen, was natürlich nicht sehr schön ist.

Hat schon mal jemand damit zu tun gehabt und vielleicht einen Tipp parat?

Schon jetzt vielen Dank dafür.

asdf
  • asdf
  • SAP Forum - Profi
vor 10 Jahre
Hallo,

hbae gerade den Ablauf getestet (Standard) und kann so nicht bestätigen. Auch wenn ich zu einer Banf den Kontrakt angelegt habe, wird mir diese Banf zu einer weiteren Übernahme vorgeschlagen (mit Häkchen nur offene), habe ohne Meldungen zwei Mengenkontrakte zu einer Banfposition angelegt.

Dann habe ich beide Kontrakte gelöscht und das System hat den Status der Banf wieder auf "nicht bearbeitet" gesetzt...

Hoffe, es hilft weiter,

Grüße,

adsf

Jakucev
vor ein Jahr
Hallo,

ich habe gerade auf diese Thema gestossen.

Ich denke, das Problem liegt in Customizing.

Es gibt Kopierregel fuer Bestellanforderung (wie auch fuer andere Einkaufsbelege). Diese Regel bestimmen die Reaktion des Systems auf die nachfolgenden Belegen wie, z.B. offene Menge, geloeschte Menge, Kontrakte und e.c.

Gruess

Jakucev