Skocz do zawartości

Radomił Ząbik

Użytkownik
  • Liczba zawartości

    1 962
  • Rejestracja

  • Ostatnia wizyta

  • Wygrane w rankingu

    37

Ostatnia wygrana Radomił Ząbik w dniu 28 Grudnia 2020

Użytkownicy przyznają Radomił Ząbik punkty reputacji!

Reputacja

171 Excellent

Ostatnie wizyty

3 222 wyświetleń profilu
  1. Złota łopata dla mnie, ale chciałbym się upewnić, czy przypadkiem Pola własne do pozycji dokumentu, nie otrzymały jednak jakieś daty wprowadzenia w NEXO, albo całkiem zostały wykreślone z pomysłów
  2. To znowu ja, już się Pan cieszy Dobra wiadomość jest taka, że najwidoczniej gdy podczas aktualizacji, restartowaliśmy system, Windows Server postanowił Sobie wprowadzić jakieś magiczne ustawienia oszczędzania energii, dla SQL'a (po 3 miesiącach pracy), przez co SQL dostawał czkawki i stąd całe problemy wydajnościowe. Przepraszam za zawracanie gitary, zwróciłem uwagę najpierw na zmianę wersji programu. Zła jest taka, że przenoszenie adresów działa, poza jednym wyjątkiem - jeśli na ZK jest ustawiony adres Zamawiającego, który pochodzi z Adresy dodatkowe ustawionego na podmiocie. Efek
  3. O to, to, takie działanie zapobiegło by takiej akcji. Wiadomo, że jak się odwali taki myk numeracyjny, to księgowość wpada w szał
  4. Format mamy na zasadzie YYMMLLLL, gdzie YY to rok w dwóch cyfrach, MM miesiąc w dwóch cyfrach, LLLL licznik. Problem jest taki, że pracownik zaczął procedurę w piątek 3 września i z otwartym oknem tworzenia faktury, uśpił komputer, a w poniedziałek, już po innych użytkownikach zapisał ją, więc data wystawienia była 3 września, a numeracyjnie wplątał się w dokumenty z 6 września. Wydaje mi się, że macie kontrolę kolejności numeracji względem dat i nie wiem, czy nie zadziałała, czy pracownik coś siłowo zrobił.
  5. Akurat takiego scenariusza nie było. W cenniku głównym, gdzie było importowane wiele plików nie występował problem. Teoretycznie wszystkie są nowe, w przypadku tych z problemami. Cennik jest tworzony w UI, potem w narzędziu do importu wskazuje się cennik, którego ID jest przekazywane i wybierane na początku kodu. Tutaj może rzeczywiście jest coś nie tak po stronie użytkowników, tworzących cenniki, tylko co. Sferycznie uzupełnianie są pozycje, kodem, który wstawiałem.
  6. W sensie globalnie system może zacząć się z biegiem czasu zapychać, czy chodzi o dostępne partie dla danego wydania? No jeśli wy potwierdzacie, że u was jest spoko i nie widzi Pan tutaj jakiś błędów z mojej strony, które mogły by zamulać, no to szukamy dalej - może to jakiś problem sieciowy, firmware, albo jakiś Windows Update
  7. [function] => updatePriceList [id] => 100000 [pos] => Array ( [0] => Array ( [type] => add [good] => 113154 [posid] => 0 [buy] => 0.5203 [range] => 100 [sale] => 1.052 ) [1] => Array ( [type] => add [good] => 113154 [posid] => 0 [buy] => 0.5203 [
  8. Troszkę odgrzebię temat, ale nie ma sensu zakładać od nowa. Mam jakiś dziwny problem z uzupełnianiem cenników Sferycznie. Ogólnie kod wcześniej wspomniany po rozdzieleniu procesów, radzi Sobie prawidłowo z uzupełnianiem cenników, a właściwie radził. Postanowiono go użyć do uzupełniania cenników dodatkowych. Skrypt działa, cenniki uzupełnia, ale wprowadzone ceny nie podkładają się same np. w ZK, przypisanym do klienta. Co ciekawe, wejście w cennik, drobna manipulacja na pozycji i zapisanie go ponownie rozwiązuje problem. Pytanie więc, czy w przypadku cenników dodatkowych, powinienem użyć jakieś
  9. Odnotowaliśmy wolniejsze działanie naszej aplikacji, wykonującej zadania w Sferze, które trochę pokrywa się z przejściem z wersji 35.1.0 na 36.0.1. Póki co cały czas szukam przyczyny, czemu w szczególności to zadanie Sferyczne, pochłania najwięcej czasu, co przez kolejkowanie wykonywanych Sferycznie zadań, trochę przytyka nam nasz system. Przeglądając logi, w niektórych przypadkach, skok jest 2x, np. przy 20 pozycjach. Dlatego pytam, czy nie zmienialiście tutaj czegoś jeszcze, bo może akurat coś wpłynęło na nasz kod. Z tego co sprawdzałem, to kluczowa jest ta część poniżej - tutaj po prostu mu
  10. Czy NEXO w raportach obsługuje jakiś format kolumny, w której mógłbym zsumować czas? Dla kolumn typu DateTime nie da się ustawić podsumowania, a w pomocy do raportów i do konfiguracji widoku tego nie znalazłem, no może poza:
  11. Nawet tego nie oczekiwałem, i nikt tego nie oczekuje, bo za dużo raportów w świecie. Zaciekawił mnie tylko brak konsekwencji, bo się notorycznie na to łapie, ale to pewnie robota Microsoftu, a u nich to norma
  12. Ok, metoda z użyciem Konfiguracji działa - pozostaje tylko dopasować teraz typy dokumentów Teraz już widzę, że podstawą mojego problemu było to, że sprawdziłem definicję CHL tekstowo, w zapytaniu, a tam nie można używać tekstu jako klucze - wyrzuca błędem definicji. Jak się użyje zapytania, to klucze tekstowe przechodzą. Aczkolwiek fajnie by było coś zrobić z kluczami tekstowymi w CHL, bo niekiedy trzeba coś tam wrzucić wynikającego z jakiś tam danych, a nie zawsze jest możliwość wrzucania tabeli do bazy klienta, ba, czasem nawet nie chce się tego robić. Jak coś, wersja na próbę, dla pot
  13. Jeszcze wrócę do tematu - czy w związku z tymi zmianami, mogła spaść wydajność takiego procesu jak u mnie? Przeglądam logi, to przed aktualizacją, niektóre proste WZ wystawiały się nawet w sekundę, a teraz uzyskanie 3 sekund jest dobrym wynikiem. Serwer się nie zmienił, ani sam kod poza zmianą powyżej też nie.
  14. Powstał u nas nietypowy problem. Użytkownik rozpoczął wystawianie faktury w piątek, zostało mu przerwany ten proces (uśpił komputer). W poniedziałek, dokończył uzupełnianie faktury i nacisnął zapisz. W efekcie powstała faktura z datą wystawienia 3 września, ale z numerem z 6 września. W śladzie rewizyjnym też się to ciekawie zapisało (poniżej). Czy nie da się temu jakoś zapobiegać - chyba, że były komunikaty, np. o rozwalaniu numeracji, a użytkownik je zignorował:
  15. No właśnie takiego dziubania chciałem uniknąć, ale widać nie ma szans, znowu za dużo SQL'a oczekiwałem od raportów SQL
×
×
  • Dodaj nową pozycję...