Wpis z mikrobloga

@mnht: Nie znam się na FI ani tym bardziej na CO i nie wiem do końca o czym piszesz, ale kiedyś miałem do czynienia z rozłożeniem materiałów w WM na kilka godzin przed ich przyjęciem do systemu. Przyczyna była tak prosta, że aż się wydawała niemożliwa, jeden z użytkowników miał w profilu źle zdefiniowaną strefę czasową ( ͡º ͜ʖ͡º).
Co się nagłowiliśmy to nasze ;)
@Usurper: tutaj niestety to nie wchodzi w rachube :( Joby odpalone przez background usera, ale tez dzialo sie to kiedy normalni uzytkownicy tworzyli dokumenty. Dlatego jestem ciekaw czy da sie odzyskac logi jobow; posprawdzalbym sobie czasy ich odpalenia z godzinami utowrzenia dokumentow. Chociaz i to pewnie nie daloby mi sensownych odpowiedzi. Normalnie zagadka.
@Qrystus: akcja miala miejsce 12 - 19 luty i juz logow znalezc nie moge. Joby musialy wystartowac bo zapoczatkowaly caly proces tworzenia faktur (tcode VF04: SD -> FI -> CO-PA), zagadka w tym, ze CO-PA stworzyl sie godzine przed SD... Tak jakby cos za kazdym razem odpalenia joba blokowalo ksiegowania SD / FI (joby chodza co 5min i wariant ustawiony na konkretnego klienta).
Do tego dochodzi proces manualny, inicjowany przez zwyklych
@mnht: Z księgowaniem?
Rozumiem, że Security Audit był wyłączony?

Podejrzewam locka na bazie na konkretnych tabelach, które zblokowały SD i FI. Po zwolnieniu locka zaległe joby ruszyły, tylko w takim razie joby są źle ustawione, ponieważ powinny się wykonać każdy proces po sobie, a nie równolegle.
@Qrystus:

Rozumiem, że Security Audit był wyłączony?


nie mam pojecia, pewnie bede musial znowu do basisu uderzyc...

Podejrzewam locka na bazie na konkretnych tabelach, które zblokowały SD i FI. Po zwolnieniu locka zaległe joby ruszyły, tylko w takim razie joby są źle ustawione, ponieważ powinny się wykonać każdy proces po sobie, a nie równolegle.


To nie jest (chyba?) takie proste. Dokumenty ksiegowane byly przez caly tydzien (nie tylko jobami, ale rowniez
@mnht: dokument copa tworzony jest tylko przez Joba? Jeśli tak to sprawdź te ustawienia czasu na użytkowniku który jest wpisany w Joba (pewnie BATCH cos takiego). A tak w ogóle scn nic nie pomógł?
@mnht: a może jakiś mądry hinduski developer naklepał coś w jakimś user-exicie ? Popatrz może jakie obiekty dev były transportowane w dniu (dniu przed również), od którego zaczęły dziać się cyrki :)
@fledgeling: Konsultant CO po stronie SAPa przekazal incydent do developerow, uprzednio probujac mnie "zbyc" przykladem jednej faktury, gdzie SD/FI zaksiegowalo sie o polnocy 12.02.2015, a CO dokument o jedenastej wieczorem 12.02.2015 (23 godziny po SD) tlumaczac to bottleneck'iem... Pokazalem mu przyklady faktur SD / FI, ktore powstaly po dokumencie CO i chyba zwatpil i przekazal incydent dalej.
Moze jakis junior z niego... ciezko okreslic
@whill3r: Z reguly transporty ida u nas w czwartki rano, gdzie problemy zaczely sie okolo wtorku. Ale podpowiedz moze, jakie takie cos szybko wyszukac, bo z hinduskimi devami nie chce mi sie walczyc zeby podali jakies info bez otwierania tiketa do ich grupy
@fledgeling: zawsze godzina (kilkoma sekundami moze sie niektore roznia, ale zawsze godzina-1). Jak tylko bede mial odpowiedz od SAP, dam znac. Spodziewam sie standardowego "temporary perfomance issue"...
@fledgeling: @DominaTuByla: @Usurper: @Qrystus:

Odpowiedz SAP developera:

Dear mnht,


the 'Time created' value for the CO-PA line item is not stored at

database but calculated from the timestamp that is stored at database

(considering the value of system parameter SY-TZONE that represents

the difference to UTC reference time). Since there was a time

changeover in Brazil at 15th of February (from summer to winter time)

SY-TZONE changed from