Change Pointers

[tendi001]

Pomijając fakt niepotrzebnej implementacji własnego typu IDoc'a przypuszczam, że bezpośrednią przyczyną Twojego problemu jest brak następującego wpisu w transakcji BD66.


Powyższy zrzut ekranu pokazuje naturalnie standardowe ustawienia dla typu komunikatu ALE DEBMAS. Sprawdź czy masz ten wpis dla swojego typu komunikatu ALE.

Podobny problem jest opisany w nocie: 69123 - Cust.master record:Change pointer:Create KNKA data

Niestety, w dalszym ciągu Idoc nie generował się.

Czy dodanie tego wpisu w BD66 dla Twojego typu komunikatu ALE spowodowało zapisanie wskaźników zmian podczas tworzenia danych bankowych? Sprawdźmy najpierw czy wskaźniki działają poprawnie. Wklej też proszę zrzut ekranu z wpisem, który dodałeś.

Dodane dla Naszego Zetowego komunikatu, oraz Z-segmentu. Mam nadzieję że w porządku.
Jak poprzednio, dokument zmiany jest a wpis w BDCP2 pojawił się jedynie w przypadku "E" usunięcia pozycji.

[tendi001]

Grzebię i grzebię... i nasuwa mi się pytanie.
Co, na przykładzie standardowego DEBMAS'a odpowiada za wywołanie generowania IDOC z wskaźnika zmiany.
MASTERIDOC_CREATE_SMD_DEBMAS czy coś innego ?

[dominik.tylczynski]

Grzebię i grzebię... i nasuwa mi się pytanie.
Co, na przykładzie standardowego DEBMAS'a odpowiada za wywołanie generowania IDOC z wskaźnika zmiany.
MASTERIDOC_CREATE_SMD_DEBMAS czy coś innego ?

Tak, to jest ta funkcja; MASTERIDOC_CREATE_SMD_DEBMAS odczytuje wskaźniki zmian i buduje IDoc DEBMAS.

[tendi001]

Tak walczę i walczę, i natchniony twoim wpisem stwierdziłem, że pole KNBK-KEY powinno również znaleźć się w BD52.

Pomijając fakt niepotrzebnej implementacji własnego typu IDoc'a przypuszczam, że bezpośrednią przyczyną Twojego problemu jest brak następującego wpisu w transakcji BD66:2020-01-20_13h50_33.png


Powyższy zrzut ekranu pokazuje naturalnie standardowe ustawienia dla typu komunikatu ALE DEBMAS. Sprawdź czy masz ten wpis dla swojego typu komunikatu ALE.

Podobny problem jest opisany w nocie: 69123 - Cust.master record:Change pointer:Create KNKA data

Dodałem, i jest bliżej - Wpis widoczny w tabeli BDCP2 jak w przypadku usunięcia. Problem jedynie jest taki, że generowanie IDOC z wskaźników zmian nie generuje w dalszym ciągu niczego. Wpis w BDCP2 widoczny jest jako "I"

Człowiek uczy się na błędach...

[dominik.tylczynski]

Brawo
Tak to jest jak się coś implementuje od zera zamiast wykorzystać to co daje SAP w standardzie.

Teraz przynajmniej temat wskaźników zmian masz ogarnięty. To że IDoc się nie generuje mimo że są wskaźniki zmian wynika już wyłącznie z funkcji, która czyta wskaźniki i tworzy IDoc, takiej podobnej do MASTERIDOC_CREATE_SMD_DEBMAS.

Skoro masz własny typ komunikatu to najpewniej masz również własną Z-funkcję. Trzeba ją przejrzeć i sprawdzić dlaczego nie tworzy IDoc'ów dla wskaźników typu I.

[tendi001]

A wszystko głównie dzięki Tobie i Twojej ogromnej wiedzy. Dziękuje

Zacząłem przeglądanie mf o którym pisaliśmy wyżej, odnosi się on do obiektu w INCLUDES, a w nim wspomniane coś o MSGFN.
Czym prędzej edytowałem nasz Ztowy segment KNBK (WE31), o wpis MSGFN (analogicznie jak standardowy segment E1KNBKM).
I o dziwo ZDebmas wygenerował się. Był jednak błąd:
Błąd podczas kompilacji wersji: Strukt. docel. ZDEBMAS nie zgadza się z IDoc
A dodatkowo Typ podstawowy komunikatu DEBMAS07 ( powinien być nas Ztowy )

Dla testu edytowałem więc Profil partnera (we20) a dokładniej zmieniłem typ podstawowy dla Zdebmas'a na DEBMAS07
Tym razem, w WE02 błędu nie było, ale IDOC był pusty.

Nie podjąłem się grzebania w kodzie, więc pełny smutku i desperacji zacząłem porównywać system DEV do QAS.
Znacznie się różnił...

Koniec końców na systemie QAS dodałem wpis do BD52 obok pozostałych z KNBK

Kod: Zaznacz cały

DEBI	KNBK	KEY

I wszystko działa! Produkcja również.
UPDATE, INSERT, DEL - wszystko generuje IDOC'a o poprawnym typie, z poprawnymi danymi

Podsumowując:

Jedynie czego brakowało to wpisu w BD52

Kod: Zaznacz cały

DEBI	KNBK	KEY

Obok oczywiście pozostałych pól z KNBK

Swoją drogą, jak to działa że KEY nie jest widoczny jako pole w tabeli? Jest to oznaczenie pól kluczowych ?

Wracam do DEV'a zobaczyć co tam jest nie tak

[dominik.tylczynski]

Swoją drogą, jak to działa że KEY nie jest widoczny jako pole w tabeli? Jest to oznaczenie pól kluczowych ?

Tak, ten wpis identyfikuje pola kluczowe tabeli i jest konieczny, żeby wskaźniki zmian tworzyły się podczas tworzenia danych.

[dominik.tylczynski]

Nie podjąłem się grzebania w kodzie, więc pełny smutku i desperacji zacząłem porównywać system DEV do QAS.
Znacznie się różnił...

To różnicy przydałoby się wyczyścić. Inaczej bardzo trudno jest cokolwiek zrobić porządnie i przetestować dokładnie. Czasem jak już DEV się tak całkiem rozjedzie z QAS i PRD konieczna może być kopia systemu.

[tendi001]

Nie podjąłem się grzebania w kodzie, więc pełny smutku i desperacji zacząłem porównywać system DEV do QAS.
Znacznie się różnił...

To różnicy przydałoby się wyczyścić. Inaczej bardzo trudno jest cokolwiek zrobić porządnie i przetestować dokładnie. Czasem jak już DEV się tak całkiem rozjedzie z QAS i PRD konieczna może być kopia systemu.

Posprzątałem, porównałem wszystko głównie błąd leżał w WE57 dopisany był moduł standardowy ...
Wszystko ułożyło się w miarę logiczną całość.
Koniec jest taki, że wszystko działa już na 3 systemach

Dziękuję!
Temat wyczerpany