kann es wirklich sein dass pro Werk nur jeweils ein User mit der VK12 Konditionen von einem Debitor ändern kann.

Hintergrund ist, wir haben Debitoren mit tlw. tausend verschiedenen Materalien, die hätte ich gerne im Team gleichzeitig geändert. Leider lässt die VK12 immer nur ein User zum Ändern zu 😕

In unserem alten ERP System konnten mehrere User gleichzeitig auf die Preislisten eines Debitors zugreifen um die Konditionen zu ändern.

Ich habe noch vergessen nachzutragen dass die VK12 nur von einem User im ganzen Werk bearbeitet werden kann, will ein zweiter User auf die VK12 zugreifen erscheint die Meldung "Gesperrt durch User xy"

Wer hat eine Idee ?

LG

Michael

die Preise werden in Tabellen abgelegt. Wenn ein User in einer Tabelle schreibt, muss die logischerweise für andere User gesperrt werden.

Wenn ein User einen Auftrag offen hat, muss er ja auch für andere User gesperrt werden.

Wenn ihr so viele Preise ändern müsst - warum eigentlich? - dann könntet ich auch z.B. mit BatchInput arbeiten.

Im Tagesgeschäft solten sich m.E. Änderungen eigentlich in Grenzen halten.

Viele Grüsse

mas

erstmal herzlichen Dank für deine Antwort.

Ich hätte mir gewünscht dass SAP nur einzelne Debitoren, die ich momentan mit der VK12 bearbeite, für andere User sperrt.

Wir müssen deshalb viele Preise ändern weil unsere Firmenstrategie auf individuellen Preisverhandlungen ausgelegt ist. Da kann es schon mal vorkommen dass zu einem bestimmten Zeitpunkt pro Debitor 1000 Preise geändert werden müssen.

Und wie ich schon geschrieben habe,sollte dies dann im Team bewältigt werden müssen.

Ich denke der Tip mit BatchInput wird wohl etwas für uns sein.

Hast du vllt. eine Idee ob hier grundsätzlich mit programmieren etwas zu machen ist ?

Viele Grüße

Michael

der OSS-Hinweis 45104 erklärt die Sperrlogik:

Symptom

Während ein Benutzer Konditionssätze ändert, hat ein anderer Benutzer u.U. keine Möglichkeit, Konditionssätze zur gleichen Konditionsart zu bearbeiten.

Ursache und Voraussetzungen

Verhalten der Standard-Pflege-Transaktionen (z.B. vk12, vk14)

beim Anlegen:

Bei der Eingabe eines Konditionssatzs wird ein Sperreintrag genau für diesen Konditionssatz erzeugt.

beim Ändern und Anlegen mit Vorlage:

Wie gesperrt wird, hängt vom Selektionsbild ab. Es wird ein generischer Sperreintrag für den Kopf des Selektionsbildes bzw. der Schnellerfassung abgesetzt. Das führt dazu, daß nur ein Benutzer Sätze mit diesem generischen Sperreintrag, d.h. mit diesen Kopffeldern pflegen kann. (Die Kopffelder des Selektionsbildes entsprechen genau den Mussfeldern.)

Lösung

Innerhalb des SAP-Standards gibt es keine Lösung hinsichtlich des Sperrens, was die Standard-Pflege-Transaktionen für Ändern und Anlegen mit Vorlage angeht (z.B. vk12, vk14).

Man hat allerdings die Möglichkeit, die Kopffelder einer Konditionstabelle mit der Transaktion v/04 (oder allgemeiner vk04) unter 'Technische Sicht' zu pflegen. Wandert ein Schlüsselfeld der Tabelle vom Zeilen- zum Kopffeld, wird das Sperrargument spezifischer.

Es besteht weiterhin ab Release 4.0B die Möglichkeit, über eine geeignete Konditionsliste in die Einzelsatzpflege eines Konditionssatzes zu springen (Ändern-Modus). Dabei wird nur der eine, betroffene Satz gesperrt. Beim Absprung aus der Konditionsliste in das Anlegen, genauer Anlegen mit Vorlage, gilt die generische Sperre wie oben.

Weiterhin gibt es die Möglickeit, Konditionen der Preisfindung über eine Konditionsindextabelle zu pflegen. Beim Ändern von Sätzen (oder Anlegen mit Vorlage ab Rel. 4.0B) werden nur die betroffenen, einzelnen Sätze gesperrt.

Ab Release 4.6 wird in der neuen Pflege von Konditionssätzen (TA vk32, vk34) generell über eine Konditionsliste eingestiegen und damit werden Einzelsatzsperren abgesetzt.

Anmerkung: Werden Einzelsatzsperren abgesetzt, kann es bei der Massenpflege u.U. zu Performance-Einbußen bzw. zum Überlauf der Sperrtabelle kommen.

VK14

Gruß

Wolfgang

vielen Dank für die ausführliche Erklärung !

Ich werde mir die Tage die Informationen genauer betrachten, testen und dir dann berichten.

Nochmal vielen Dank

Grüße

Michael