Obiekty COM biorą datę z pliku dll, w którym są wykorzystywane zamiast datę systemową

0

Witam.
Mam bardzo dziwny problem. Powiedziałbym, że to magia. Od razu informuje, że żadnych zmian, przestawień dat, godzin w systemie nie było. Tyczy się to obiektów COM od Comarch Optima ale to chyba nie wiele wam powie. Skompilowałem usługę w piątek (26.02.2021), a w poniedziałek (01.03.2021) dokumenty próbowały się wystawić z datą piątkową. Skompilowałem usługę w poniedziałek i dzisiaj (02.03.2021) próbował robić dokumenty z datą z poniedziałku... Czy ktoś wie czym może być coś takiego spowodowane? Czy to jest problem stricte Comarchu, czy zdarzało się to ogólnie w .NET Framework, COM itp.? Ogólnie wygląda to tak jakby data była brana z pliku dll/exe zamiast z systemu, która jest aktualna. Dorzuciliśmy nawet statycznie, ręcznie, dla pewności:

DokumentyHaMag WydaniaZewnetrzne = (DokumentyHaMag)Sesja.CreateObject("CDN.DokumentyHaMag", null);
IDokumentHaMag WydanieZewnetrzne = (IDokumentHaMag)WydaniaZewnetrzne[$"TrN_TrNID = {wydanieID}"];
WydanieZewnetrzne.DataDok = DateTime.Now;

Ten sam problem.

0

a optima nie ma przypadkiem czegoś takiego jak data dokumentów, tzn. ustawiana gdzieś data dla całej optimy z jaką się dokumenty wystawiają?

0

Tego nie wiem. Z tą datą, o której tutaj napisałem jest jedynym punktem zaczepienia, ponieważ nie wiedzieliśmy czemu akurat taka data. Jeśli "data dla całej optimy" istnieje, to jakie jest prawdopodobieństwo, że jest brana z daty pliku?

0

niektóre programy (nie znam optimy) miały taką datę ustawianą ręcznie przez operatora żeby nie trzeba było zmieniać daty systemowej jeśli miałeś np. do wystawienia dokumenty "jutrzejsze".
A debugowałeś się przez kod? Co masz w WydanieZewnetrzne.DataDok po tej instrukcji WydanieZewnetrzne.DataDok = DateTime.Now;?

0

Ja nie mam jak tego zdebugować. Oprogramowanie działa na stricte ustalonych zasadach i na konkretnych danych, których nie jestem w stanie zasymulować. Kompilowanie usługi codziennie nie rzuca żadnymi błędami. Jeśli jutro nie zrobię kompilacji to znowu będzie co jakiś czas (nie dla każdego dokumentu) rzucał błędem, że próbuje wystawić dokument (02.03.2021) na towar, którego dostawa była (03.03.2021) mimo iż DateTime.Now jest dniem dostawy czyli błędu nie powinno być. Jedyne co mogę zrobić to spróbować logować te informacje do pliku.

0

Dla WZ/Faktury trzeba trochę więcej dat ustawić:

 Faktura.DataDok = new DateTime(d_rok, d_miesiac, d_dzien);
            //    Faktura.DataSprzedazy = new DateTime(2007, 07, 22);
            Faktura.DataWys = new DateTime(d_rok, d_miesiac, d_dzien);
            Faktura.DataSprzedazy = new DateTime(d_rok, d_miesiac, d_dzien);

0

To nie ma znaczenia. Obojętnie jaką bym datę nie ustawił w obojętnie jakim miejscu to i tak nie jest to data dzisiejsza.

0

Debugowanie najlepiej zrobić, ale możesz też spróbować datę niewłaściwą znaleźć w pamięci i podmienić dynamicznie na właściwą przed wykonaniem ostatecznego zakończenia.

Ciężko coś poradzić jak wcześniej wszystko działało to może jakiś update lub jakieś zmiany i brak testów sprawił, że potem błędów masa się pojawiła.

0

Oprogramowanie pracuje już od ponad roku. Owszem były problemy na początku ale przynajmniej od pół roku nic nie zostało zmienianie oprócz wersji Optimy. Mamy pewne podejrzenia, że przez rząd, pandemię i częste zmiany/poprawy przepisów księgowo/kadrowych Comarch nie wyrabiał się z dopisywaniem rzeczy i robił to na okrętkę bezpośrednio w samej Optimie zamiast w COM. To jest tak bardzo dziwne i tak niespotykane, że aż niemożliwe, że w ogóle się dzieje. Wyobraźcie sobie jaki cyrk się robi z takimi bugami:

  1. Wpada zamówienie z datą 15.02.2021
  2. Nasz system generuje WZ do tego zamówienia (domyślnie powinien z datą 15.02.2021) z dniem 12.02.2021 (z powodu tego buga)
  3. System nie wykrywa nieprawidłowości - dokumenty zostały wygenerowane "poprawnie", bez błędów
  4. Nasz system zamyka dokument WZ, generuje fakturę lub paragon
  5. Klient zgłasza, że dostał FA/PA na jedną pozycję, a kupił 8 produktów.

W związku z tym, że nasz system weryfikuje stany magazynowe na dzień bieżący to dnia 15.02.2021 produkty na stanie były i zamówienie mogło zostać w pełni zrealizowane i to też zrobił ale... WZ zostało wygenerowane z datą wcześniejszą, a wtedy tych produktów mogło nie być i Optima pokazuje, że zamówienie jest "do realizacji", ponieważ nie wszystkie pozycje z zamówienia znajdują się na WZ i tak się stało dla 851 zamówień...

PS.
Pytam tutaj, bo może to jest jakiś znany błąd .NET, że już się kiedyś coś takiego działo i niekoniecznie ma to coś wspólnego z Comarch Optima.

1

U mnie się data kursu walut nie przypisuje na wczorajszą tylko jest zawsze dzisiejsza ale ja mam po drodze api innej firmy i dopiero Optimę więc może to nie problem samej Optimy.
Twoj problem można obejść updatem w sql? Wcesniej do bufora, podmiana daty i wyciagniecie z bufora?

0

A co z numerem dokumentu na przełomie miesiąca? Jeśli stworzę dokument z datą np. 27.02.2021 to numer np. byłby WZ/543/02/2021, zmieniam datę na marzec, to numer będzie ten sam tylko miesiąc się zmieni (WZ/543/03/2021) i każdy kolejny już będzie w takiej (wysokiej) numeracji.

0

No troche problem ale numer to tylko numer. Jesl bedzie unikalny to nie ma problemu poza tym, że będzie mylący.
A numeratory też są dostępne chyba przez COM ale nie wiem w jakim zakresie.

0

Sprawdziłem w swojej apkce, baza Optimy w wersji 2021.2.1 i mogę wstawić datę dowolną na WZ. Przećwiczyłem nawet kwestię zmiany daty na przełomie miesiąc i też mi działa (numeracja miesięczna dokumentów).
Aplikacja Winformsowa, referencje do obiektów COM.

0

Ja to mam w usłudze, nie w oknie. I mam wersję 2021.1.2 i liczę, że aktualizacja naprawi problem. Jak nie to będę fakturował klienta za dzienną kompilacje 😂

0

offtop:

Czemu ta Optima jest na COMach?

Jak ją pisali, to HTTP/gRPC nie było modne?

0

Program powstawał pod koniec lat 90 , został pierwotnie cały stworzony w generatorze aplikacji Clarion. W tam tych czasach to był najszybszy sposób produkcji aplikacji. Około 2010 Comarch wymienił interface na .Net , dokładnie na DevExpressa. Niestety logika biznesowa została w 32-bitowych obiektach COM stworzonych w Clarionie :(

Szansą jest migracja Comarchu z bazy MS-SQL na PostgreSQL, może coś się zmieni w obszarze logiki biznesowej. Ale znając Comarch to potrwa kolejne 10 lat :)

0

Jestem jeszcze w stanie zrozumieć, że przepisanie COMów jest czasochłonne, kosztowne i może nawet niepotrzebne (skoro działa) ale mogliby chociaż inaczej traktować partnerów i nie palić głupa, że nie wie o czym mówię byle by tylko zagrać na czas, zakończyć wątek i mieć święty spokój.

Co do postgre to czuje w kościach, że nic się nie zmieni, a jak już to na gorsze.

@WeiXiao
Pan prezes jeszcze wtedy chyba nie miał studentów i musiał sam myśleć i wymyślił 😉

0

Cześć, trafiłem tutaj z wyszukiwarki, bo sam jak się okazało męczę się z podobnym ale trochę odmiennym błędem i ta dyskusja mnie trochę naprowadziła na rozwiązanie.

Mam program, do Optimy, który wykonuje szereg operacji na dokumentach, konwertuje z RO do Paragonu (fiskalizuje) a następnie na podstawie Paragonu wystawia Fakturę sprzedaży w przypadku płatności online dodaje zapis KB i rozlicza dokument na koniec drukuje fakturę do pliku PDF i wysyła do klienta.

Okazało się, że po wdrożeniu u klienta, faktura przy generowaniu PDF dziwnie się zachowuje, brakuje w niej danych sprzedawcy. Żeby było ciekawiej, u mnie działa to bez problemu.

Sedno: Okazało się, że u mnie działa OK, bo po każdej kompilacji uruchamiam program na nowo. A u klienta działał on jako usługa kilka dni (nawiasem to dziwne, że przy operacjach na obiektach COM się nie wysypuje 😂).
Tak jakby program przy uruchomieniu zapamiętał sobie w jakiś dziwny sposób datę (przy ładowaniu obiektów COM) i przy kolejnym dniu już działał niepoprawnie.

Może to kwestia ponownego uruchomienia programu?

Dodam, że u mnie wszystko działa w pętli, loguję się i wylogowuje z programu kiedy trzeba a w niektórych miejscach odpalam Garbage Collectora.

Na chwilę obecną nie znam dokładnej przyczyny, zaleciłem klientowi restart programu codziennie, jeśli nie znajdę rozwiązania to zaimplementuję automatyczny restart 😂

3

Siemandero. Pozwolę sobie oficjalnie przywitać, nie dość, że w gronie forumowiczów, to jeszcze optimowców 😁 A to jest odpowiedź z Comarchu na ten problem, który odziwo, na tę chwilę, działa:

Przy starcie aplikacji data bieżąca jest ustawiana dla wszelakich użyć w obiektach com.
Jeśli aplikacja nie jest restartowana/uruchamiana każdego dnia tylko działa w sposób ciągły, to najlepiej ustawić poprawną datę po północy, albo przed uruchomieniem przekształcenia jeśli data w aplikacji jest zła.
Należy sprawdzić - Application.AppToday
i jewentualnie ustawić:
DateTime dt = DateTime.Now; //tutaj jest dobra data
Application.AppToday = dt .ToOADate();

Good luck 😉

0

Super, czyli rzeczywiście coś z datą jest na rzeczy...

Dzięki za podzielenie się tym info od producenta :)

Pozdrawiam

1 użytkowników online, w tym zalogowanych: 0, gości: 1