BAPI_CONTRACT_CREATE

[greg_hhl]

Mam taki proces (system EHP8 FOR SAP ERP 6.0), który jest oparty na kontrakcie SD i umowie ramowej MM:

Robię (w dialogu) kontrakt SD, w którym są pozycje:
1. dowolna ilość pozycji typu "sprzedaż"
2. pozycja "zakup"

Przy zapisie kontraktu SD tworzona jest informacja wyjściowa, która na podstawie pozycji "zakup" tworzy (używając BAPI z tytułu) umowę ramową i numerze identycznym z numerem kontraktu SD (konstrukcja wykorzystana by na poziomie raportu w prosty sposób zestawić sprzedaż i zakup i mieć kontrolę nad stopniem realizacji takiego powiązanego kontraktu; mówiąc inaczej - sposób kontroli umowy barterowej).

Proces zrobiony kilka lat temu, działał bez zarzutu dopóki nie pojawiły się transakcje barterowe, w których po stronie zakupu pojawiło się więcej pozycji zakupowych (np. ze względu na różne stawki podatku VAT). W umowie ramowej mam kilka pozycji ale ceny są skumulowane na pierwszej pozycji. Dołączam także obrazki: dokument oraz fragmenty zawartości wybranych tabel na wejściu do BAPI.

Czego brakuje? Co może być źle podane na wejściu do BAPI?

[greg_hhl]

Cd dalszy zrzutów - nie chciał przyjąć wszystkich plików w jednym poście

[greg_hhl]

I kolejna porcja

[greg_hhl]

Ostatnia porcja

Z góry dziękuję za pomoc

[dominik.tylczynski]

Najwyraźniej warunki z ITEM_CONDITION są niepoprawnie przypisywane do pozycji kontraktu - oba warunki są przypisane do pierwszej pozycji.

Proponuję następujące rozwiązanie:

1. Utwórz w ME31K poprawny kontrakt z dwoma pozycjami i przypisanymi do nich warunkami
2. W dokumentacji do BAPI_CONTRACT_CREATE jest przykładowy program, który kopiuje kontrakty przy pomocy BAPIs
   20250123_140253.jpg
   20250123_140330.jpg
3. Zaimplementuj ten program i wykonaj go pod debuggerem dla poprawnego kontraktu. Zobaczysz wtedy jak powinny być wypełniane parametry BAPI_CONTRACT_CREATE
4. Wykonaj program i pozwól mu skopiować kontrakt. Sprawdź czy w kopii są poprawne warunki. Jeśli nie to znaczy, że w BAPI_CONTRACT_CREATE jest jakiś błąd, który trzeba zgłosić do supportu SAP

[greg_hhl]

Najwyraźniej warunki z ITEM_CONDITION są niepoprawnie przypisywane do pozycji kontraktu - oba warunki są przypisane do pierwszej pozycji.

[*]Wykonaj program i pozwól mu skopiować kontrakt. Sprawdź czy w kopii są poprawne warunki. Jeśli nie to znaczy, że w BAPI_CONTRACT_CREATE jest jakiś błąd, który trzeba zgłosić do supportu SAP[/list]

Na razie zrobiłem pierwszą część - kontrakt i skopiowanie z użyciem tego programu. Wynik - pozytywny. Znaczy - u mnie coś nieustawione lub błędnie. Teraz gorsza zabawa - porównanie ...

Dzięki.

[wojtas7]

to prawdziwy komercyjny sap czy jakieś studia podyplomowe?

[dominik.tylczynski]

to prawdziwy komercyjny sap czy jakieś studia podyplomowe?

Myślę, że prawdziwy, komercyjny - na studiach podyplomowych raczej nie bawią się takimi zintegrowanymi scenariuszami.

[wojtas7]

Bardziej mnie ciekawi nomenklatura, typu materiał o nazwie "BARTER" czy "przekąski i wino RMF"

[dominik.tylczynski]

Bardziej mnie ciekawi nomenklatura, typu materiał o nazwie "BARTER" czy "przekąski i wino RMF"

Faktycznie, nie zwróciłem na to uwagi. Możesz mieć rację, że to jakiś rozrywkowy scenariusz.

[greg_hhl]

Bardziej mnie ciekawi nomenklatura, typu materiał o nazwie "BARTER" czy "przekąski i wino RMF"

Faktycznie, nie zwróciłem na to uwagi. Możesz mieć rację, że to jakiś rozrywkowy scenariusz.

No tak ... nie zauważyłem tego, mogłem wyczyścić ... ale to jak najbardziej prawdziwa sytuacja. W transakcjach barterowych pojawiają się naprawdę najdziwniejsze rzeczy a ów test jest po prostu opisem by wszyscy, którzy zerkną na dokument wiedzieli czego to dotyczy. Oczywiście - wszelkie opisy można wrzucać do tekstów nagłówka ale to pole ma tę przewagę nad tekstami, że jest wprost na nagłówku więc łatwo dostępne do raportów.

A sam materiał BARTER? Ponieważ przedmiotem barteru może być niemal nieograniczona ilość towarów i usług a z punktu widzenia firm (na tej instalacji) nie jest istotny przedmiot barteru (zobowiązanie dostawcy) to taki magiczny materiał załatwia wszystkie przypadki.
Padnie pewnie pytanie - to skąd wiemy, że dostaliśmy to, na co zgodziliśmy się w Umowie? Ano sama Umowa (papier/PDF) jest podłączana jako załącznik do DMS tworzonego z referencją do kontraktu (SD) i ci, którzy powinni mają do tego DMS dostęp i mogą to zweryfikować. Zresztą - w procesie akceptacji faktur zakupowych trafiają one do osób odpowiedzialnych za daną transakcję barterową (odpowiednia rola partnera), które muszą to potwierdzić. Ostatecznie księgowość przed zaksięgowaniem może także to sprawdzić (i robi to!) - również ma dostęp do DMS z Umową ....

[dominik.tylczynski]

Dzięki za objaśnienie procesu.

[greg_hhl]

Dzięki za objaśnienie procesu.

Sam proces wygląda, w skrócie, tak:

Tworzony jest dokument SD (typ G) z dwoma kategoriami pozycji (nie piszę typami bowiem typ pozycji sprzedaży zależy od rodzaju naszej usługi - są różne spółki i mają różne usługi):
- pozycja sprzedaży
- pozycja zakupu
w trakcie przetwarzania (etap wprowadzania lub na etapie kontroli przed zapisem) wykonywane są głównie kontrole:
- wypełnienie parametrów, które w procesie księgowania faktur sprzedaży wpływają na konta przychodowe
- połączenie odbiorcy z dostawcą
- odpowiednie role partnera (osoby odpowiedzialne po stronie naszej i kontrahenta)
- wartość końcowa dokumentu - brutto musi być równa 0 (gdy pojawiają się różne stawki podatku VAT jest dodatkowy checkbox, który uruchamia sprawdzanie netto; pierwotnie było to wykorzystane w momencie startu kontroli procesu - było już trochę umów barterowych na różnym etapie realizacji i chcieliśmy je wszystkie mieć w systemie od razu a nie czekać aż się zakończą; okazało się przydatne właśnie dla umów z różnymi stawkami podatku VAT).

Informacja wyjściowa tworzy w tle po stronie MM umowę ramową.

Do gotowego dokumentu SD tworzony jest DMS, do którego załączane są Umowy i wszelkie "papierowe" dokumenty.

Procesy sprzedaży i rejestracji zakupu prowadzone są niezależnie od siebie, zgodnie ze standardowymi procesami. Jedyna modyfikacja dotyczy procesu SD - Umowa barterowa może być rozliczana ilościowo (konkretna ilość usług po naszej stronie) lub wartościowo (określamy jakiej wartości usługi przekażemy a dział sprzedaży może wykonać ją kilkakrotnie - wówczas jednostkowa wartość wykonanej usługi jest określana ręcznie a dział handlowy raportowo porównuje wartość wykonanej do wartości cennikowej). Żeby to wyjaśnić precyzyjniej musiałbym opisać dokładniej typy świadczonych usług.

Etapem końcowym procesu jest zaraportowanie stanu realizacji Umów barterowych - jest to raport ALV, który na ekranie podzielonym na 3 części pokazuje;
- ogólnie przedmiot barteru, wartość do realizacji, wartość pozostałą do realizacji po stronie sprzedaży i zakupu
- DMS z załącznikiem
- dokumenty SD (kontrakt, zlecenia, faktury)
- dokumenty MM (umowa ramowa, zamówienia, faktury)
Po dwukliku jest wejście w każdy z dokumentów.

Pierwszego dnia każdego miesiąca uruchamiane jest zadanie, które na każdego handlowca generuje raport ze stanu realizacji jego kontraktów i wysyła mailem. Dodatkowo przełożeni (ci, którzy sobie tego życzą) dostają podobne zestawienie dla swoich podwładnych. Jest także dodatkowy raport roczny przeznaczony dla wybranych decydentów.

O implementację procesu barterowego poprosiły Zarządy, które chciały mieć pełną kontrolę nad barterami i stanem ich realizacji. Dzięki temu całkowicie uporządkowaliśmy bartery i skończyło się przysłowiowe przeglądanie szuflad w poszukiwaniu zakamuflowanych umów barterowych o nieznanym stanie realizacji. Sam raport stał się podstawowym narzędziem pracy dla osób zajmujących się umowami barterowymi.

[greg_hhl]

Najwyraźniej warunki z ITEM_CONDITION są niepoprawnie przypisywane do pozycji kontraktu - oba warunki są przypisane do pierwszej pozycji.

Proponuję następujące rozwiązanie:

1. Utwórz w ME31K poprawny kontrakt z dwoma pozycjami i przypisanymi do nich warunkami
2. W dokumentacji do BAPI_CONTRACT_CREATE jest przykładowy program, który kopiuje kontrakty przy pomocy BAPI
3. Zaimplementuj ten program i wykonaj go pod debuggerem dla poprawnego kontraktu. Zobaczysz wtedy jak powinny być wypełniane parametry BAPI_CONTRACT_CREATE
4. Wykonaj program i pozwól mu skopiować kontrakt. Sprawdź czy w kopii są poprawne warunki. Jeśli nie to znaczy, że w BAPI_CONTRACT_CREATE jest jakiś błąd, który trzeba zgłosić do supportu SAP

Porównałem, znalazłem i działa.

Tajemnica tkwiła w polach 'SERIAL_ID' i 'SERIAL_NO' znajdujących się odpowiednio w tabelach *CONDITION* i *ACCOUNT - w tych pierwszych w kolejnych pozycjach wartość w polu musi być rosnąca w kolejnych pozycjach, w tej drugiej w każdej pozycji musi być ta sama. Najlepiej = 1.