Dominik kidl

Czy okresowe pobieranie ponowne transakcji jest włączone? Jest wyłączone. Tak, znajduje 20 transakcji. Sprawdziłem je i wszystkie mają w Sello status Gotowe do przetwarzania jednak każda z nich była wcześniej niekompletna, bez wpłaty. Klienci kupili np 5 marca a opłacili dopiero 10 marca. To wygląda jak timeout przy próbie dostępu do serwera SQL. Jak wygląda jego obciążenie podczas synchronizacji? Nie sprawdzałem obciążenia wczoraj jak był ten błąd. Teraz śledziłem w Activity Monitor w Management Studio, wygląda w mojej ocenie na małe obciążenie (Processor Time ~2%, Waiting Tasks 0, Database 0-0,2 MB/sec, Btach-Requests/sec 100-400). Wszystkie synchronizatory są włączone. W ustawieniach systemu sprzedaży na zakładce TOWARY jest odpowiedni parametr sterujący wyświetlaniem tych ostrzeżeń (żółte to ostrzeżenia, czerwone to błędy ) 😮😬😅 Wstyd mi.

Niestety problem nadal występuje. To co zauważyłem: Gdy zawiesza się tworzenie ZK, w tym samym czasie zawiesza się u mnie proces pobierania transakcji. Wcześniej nie zwróciłem na to uwagi. Najdłużej czekałem 2 godziny ale żaden z procesów nie został dokończony. Wraz z pojawieniem się ww problemu w raportach odnajduję dużo starych transakcji, które Sello próbuje pobrać. W Menedżerze zadań znalazłem 2 dodatkowe procesy Sello, które nie zostały z jakiegoś powodu zamknięte. Sprawdziłem wszystkich użytkowników, nikt nie zostawił włączonego Sello. Procesy były uruchomione na użytkowników moim, czyli tym na którym idzie automatyczna synchronizacja. W raportach o 18:53:50 pojawił się błąd "Wykryto nieopłaconą i anulowaną transakcję, dla której w serwisie Allegro występuje wpłata." jednak już nie ma błędów o braku towaru w systemie sprzedaży. Kolejno o 18:59:23 ponownie ten sam błąd, dla tej samej transakcji i również już żadnych innych błędów. Synchronizację z SGT mam co 10 min i ma towary dezaktywowane w SGT, więc Sello co 10 minut wyrzuca błędy o braku tych pozycji. Po błędzie do tej transakcji, już nie robił synchronizacji z SGT. Wygląda, jakby właśnie w tym momencie się zablokował. Sello było cały czas uruchomione. W raportach, kolejny wpis jest dopiero o 23:05:36 o treści "Synchronizacja z systemem sprzedaży: Upłynął limit czasu zapytania". Wczoraj koło 23:00 wszedłem na serwer i zauważyłem ten błąd. Zamknąłem Sello i wymusiłem zamknięcie procesów. O 23:05:37 pojawiły się wpisy o braku towaru w SGT, więc synchronizacja już poszła. Do północy nic się już nie działo. Błędy w obrębie północy opisałem poniżej. W raporcie napotkałem tez takie błędy: Tworzenie w systemie sprzedaży dokumentu początkowego do transakcji 'Grupa transakcji 51117/2021': Odpowiedni dokument (ZK 13596/03/2021) istnieje już w systemie sprzedaży. Powiązano z transakcją istniejący dokument. Kontrahent ani pozycje NIE zostały zaktualizowane. - To znaczy że z jakiegoś powodu Sello próbowało ponownie wystawić ZK do transakcji? W SGT mam to ZK utworzone przez Sello z dnia 16.03.2021. Powyższy błąd był o godzinie 00:03:43 z dnia 17.03.2021. W jakiej sytuacji Sello może próbować ponownie wystawić ZK. Z treści błędu można wnioskować, że przy pierwotnym utworzeniu ZK, nie zostało ono zapisane w powiązaniach z transakcją. ZK zostało wrzucone do SGT 16 marca ale prawdopodobnie tuż przed północą. Zapisywanie klienta "xxxxxx" (9967245) z konta xxxxx na Allegro.pl: Wystąpił błąd (0x80040E31) - czas błędu 17.03.2021, 00:02:08. Zakup z przed północy w dniu 16.03.2021. ZK utworzone po północy. Finalnie udało mu się zapisać klienta w bazie. Mam identyczne błędy pojawiające się co pewien czas dla rożnych transakcji i klientów. Nie można rozpocząć operacji 'Aktualizacja dokumentów zamówień' ponieważ jej poprzednie wykonanie jeszcze się nie zakończyło. - taki błąd znalazłem z godziny 23:57. Nikt już nie pracował, więc jest on wywołany przez automat. Nie można rozpocząć operacji 'Tworzenie dokumentów zamówień' ponieważ jej poprzednie wykonanie jeszcze się nie zakończyło. - taki błąd znalazłem z godziny 23:57. Nikt już nie pracował, więc jest on wywołany przez automat. Mam w raporcie mnóstwo błędów o tym, że towar nie istnieje w systemie sprzedaży. W SGT został dezaktywowany. Wiem, że pisaliśmy o tym wiele razy... w jaki sposób mogę się pozbyć tych błędów? Przy synchronizacji co 10 min, za każdym razem mam prawie 1300 pozycji z błędem. W ciągu 1 dnia tj prawie 180 pozycji z błędami. Może jakieś polecenie SQL do usuwania ich z bazy Sello? Mogę z raportów wyciągnąć symbole tych produktów.

To już zostało zgłoszone. Bartek obiecał poprawkę ale też pisał, że do 1.37.6 nie dadzą rady tego wprowadzić. Trzeba czekać na 1.38 lub 1.37.7.

Jest to serwer. Sello uruchomione na moim koncie (administratora), gdzie zaglądam tylko jak się coś dzieje lub nie dzieje. Nikt nie pracuje na tym użytkowniku, natomiast na samym serwerze za pomocą pulpitu zdalnego, na innych użytkownikach pracuje jeszcze kilka osób w tym jedna również na Sello. Do wczoraj, osoba która pracowała na serwerze miała stary synchronizator 😅 (nie wiedziałem, że trzeba na każdym użytkowniku zrobić wpis do rejestru). Dziś jednak miałem ponownie "zawias" przy tworzeniu ZK. Raczej nie, na tyle na ile można zaufać innym osobą, jeśli twierdzą, że tego nie robią Do automatycznej synchronizacji, celowo mam osobnego użytkownika, który ma tez ustawione hasło. Jeśli ktoś inny używałby skrótów i tworzył dokumenty ze swojego użytkownika w Sello, to miałbym ZK wystawione przez tą osobę a takich dokumentów nie mam. Odeszliśmy niemal w 100% od ręcznego tworzenia dokumentów w Sello. Wszystko załatwia automat.

@Bartosz Rosa Od zainstalowania wersji 1.37.6, kilka razy dziennie zawiesza się przy tworzeniu ZK. Nie mogę znaleźć przyczyny. Nie zgłaszałem od razu, chciałem zobaczyć czy to będzie się powtarzało. W raportach nic nie znalazłem. Sello w automacie zaczyna synchronizację z SGT i wystawia dokument początkowy. I od czasu do czasu na jednej z transakcji się zawiesza proces tworzenia dokumentu i nie kończy się. Transakcja jest zablokowana. Pomaga wyłączenie i włączenie programu. Może ktoś miał jeszcze taki przypadek? Subiekt GT wersja 1.66 SP2 HF1

A przypadkiem nie korzystasz jeszcze z jednego komputera, gdzie nie włączyłeś nowego synchronizatora? Ewentualnie kilku użytkowników jednego urządzenia posiadających swoje konta na kompie. U siebie tak zrobiłem Zapis w rejestrze uruchamiający nowy synchronizator, działa per użytkownik na komputerze. Zrobiłem zapis w rejestrze na serwerze przez pulpit zdalny i założyłem, że u wszystkich użytkowników uruchomiony został nowy synchronizator. Tak się jednak nie stało. Pozostali pracownicy, korzystający z pulpitu zdalnego na swoich użytkownikach, nadal mieli stary synchronizator. Sprawa wyszła dopiero dziś, bo dokumenty były wystawiane przez użytkownika w sello o nazwie "Automat", który był uruchomiony na moim koncie. Wczoraj jednak postanowiłem zapisać sobie w pliku Sello.xml, żeby program uruchamiał się od razu na użytkowniku automat i tu moje zdziwienie (choć teraz wydaje się to oczywiste), okazało się że to ustawienie działa już globalnie. Każdy użytkownik, korzystający z pulpitu zdalnego, po uruchomieniu Sello od razu był logowany na użytkownika, który jest przypisany do działań automatycznych. W jednym czasie działał nowy i stary synchronizator Trochę bałaganu się narobiło. M.in. to o czym Ty piszesz. Poza tym, teraz mam problem z pobieraniem transakcji, bo próbuje porać wszystkie dostępne w historii zamiast tylko te niepobrane.

😎

@Bartosz Rosa W ubiegłym tygodniu spotkałem podobna sytuacje w innej firmie. Sprawdzałem z nimi co i jak i nie znalazłem żadnego błędu, nic co mogłoby powodować dublowanie ZK. W mojej ocenie taki scenariusz był możliwy tylko poprzez zdublowanie ZK w SGT. Ewentualnie, gdyby faktycznie powiązanie z ZK zostało usunięte. To było jeszcze na wersji 1.37.5. Mieli dzwonić jeśli powtórzy się ten scenariusz. Teraz, gdy ktoś jeszcze zgłasza taka sytuacje, mocniej wierze, ze to nie musiał być błąd człowieka. Dziwne tylko to, że u nas przy około 2 tys transakcji tygodniowo nie pojawił się nigdy taki błąd.

To również jest w nowym synchronizatorze. Jest opcja ograniczenia do transakcji oznaczonych jako "Gotowe do przetwarzania".

Tak, do uwag da się. Bylem pewien, że chodzi o ustawienie "Sposób dostawy"

Nie ma.

Jeśli Subiekt GT, to Administracja\Parametry\Kontrahenci zakładka "Dodatkowe" Zapewne masz tam włączoną kontrolę NIP. Zmień na np Kontrola częściowa - wszystkie numery poza pustym. Jeśli Nexo, to System\Parametry numerów NIP, PESEL symboli W pozycji Numery NIP wyłącz "Przestrzegaj unikalności numerów NIP"

Korzystasz z Subiekta GT? Jeśli tak, to synchronizator s2sgt od LC Soft może zmieniać sposób płatności na dokumencie w zależności od tego jaką metodę wybrał klient.

W ustawieniach "Zewnętrzny system sprzedaży", zakładka "DOKUMENTY", na dole znajdziesz opcję do wyłączenia "Blokuj wystawienie dokumentu, gdy znaleziono powielony NIP (ZALECANE)". Pozostawienie tej pozycji włączonej będzie blokowało wystawienie dokumentu, jeśli już miałeś kontrahenta z tym nr NIP w systemie.

1.38 ? Kiedy wyszła? Chyba chodzi o 1.37.4

Podpinam się pod prośbę. Ważne, żeby to nie było kosztem kolejnych wdrożeń związanych z Allegro.

Słusznie I to jest rozwiązanie. Zostawiając ustawienie jako opcję, każdy będzie mógł zdecydować, czy mu pasuje, czy też nie.

Działa, mam ją włączoną. Nie napisałem o tym wcześniej. Opisując scenariusz jak poniżej, uwzględniał ona włączaną opcję zmiany stanu transakcji. Jak wspomniałem następuje to w chwili utworzenia ZK, więc nadal mamy wspominane różnice czasowe, gdzie coś może pójść nie tak. Nadal opcja z dodatkowym ustawieniem j.n. wydaje mi się właściwa: Zmieniaj stan transakcji z NOWA na W TRAKCIE REALIZACJI po pobraniu zamówienia tylko oznaczonego MOŻNA PRZETWARZAĆ

To i tak nie wykluczy tych luk czasowych na pobranie i zaktualizowanie statusu w których klient może anulować zamówienie. No i jeśli celem klienta jest anulowanie zamówienia to bez względu na to co powie system, Sello, czy Allegro, klient i tak będzie chciał anulować zamówienie. Więc jeśli to ZK powstanie to i tak trzeba je będzie odkręcać, tylko drogą mailową albo telefoniczną, zamiast statusem zamówienia. Raczej zatem przydało by się rozwiązanie tego problemu a nie utrudnianie klientowi życia. Rozwiązanie ze zmiana statusu transakcji zaraz po jej pobraniu do bazy Sello - Takie scenariusze widzę: Pobieranie transakcji co 5 min Tworzenie ZK co 5 min Klient kupuje o 12:00, anuluje o 12:03, Allegro robi zwrot środków, Sello pobiera transakcję o 12:05. W bazie Sello jest informacja o anulowanym zakupie, ZK nie zostaje utworzone - w tym przypadku klient miał 5 minut na reakcję Klient kupuje o 12:00, Sello pobiera transakcję opłaconą o 12:02 i zapisuje od razu status "W trakcie realizacji", klient próbuje anulować transakcję o 12:03 jednak otrzymuje informację, że sprzedawca już przetwarza zamówienie i nie ma możliwości jego anulowania, nie dochodzi do automatycznego zwrotu pieniędzy. Klient nadal może wysłać wiadomość z prośbą o anulowanie. Możemy wtedy ZK unieważnić - w tym przypadku klient miał 2 minuty na reakcję Może zdarzyć się tak, że klient kupuje o 12:00, Sello pobiera transakcję o 12:02:20 i zapisanie statusu "W realizacji" zajmuje mu 30 s, to klient będzie miał te 30s na anulowanie ZK. Wąski zakres czasowy, więc powinno być tych sytuacji jeszcze mniej. Przy aktualnym ustawieniu Sello, dochodzi do poniższych sytuacji: Pobieranie transakcji co 5 min Tworzenie ZK co 5 min Klient kupuje o 12:00, Sello pobiera transakcję o 12:02, klient anuluje ZK o 12:03, Sello tworzy ZK o 12:04, Sello pobiera informację o anulowaniu transakcji o 12:07 jednak ZK już jest w systemie. - w tym przypadku klient miał 7 minut na reakcię Klient kupuje o 12:00, Sello pobiera transakcję o 12:05, klient anuluje ZK o 12:08, Sello tworzy ZK o 12:09, Sello pobiera informację o anulowaniu transakcji o 12:10 jednak ZK już jest w systemie. - w tym przypadku klient miał aż 10 minut na reakcję Wg mnie, stosując proponowane ustawienie, żeby dla transakcji kompletnych już po ich pobraniu do Sello był zmieniany status na "W trakcie realizacji", drastycznie zmniejszymy prawdopodobieństwo wystąpienia sytuacji, gdzie klient anulował zakup, my o tym dowiadujemy się za późno, bo paczka poszła a pieniądze zostały zwrócone. Można wywołać unieważnienie dokumentu lub jego usunięcie z bazy SGT. Niestety obie opcje są procesami nieodwracalnymi. W naszym przypadku stosujemy statusy dla ZK z użyciem kategorii dokumentu. Wystarczyłoby zmienić kategorię ZK na "Anulowane". Myślę jednak, że to będzie rozwiązanie mocno pod naszą firmę i mało użytkowników z tego skorzysta. Wyżej opisane rozwiązanie pozwalające skrócić czas na anulowanie transakcji z max 10 minut do max 5 minut. Zmniejsza też ryzyko wystąpienia luk czasowych. W aktualnym rozwiązaniu luka czasowa wynosi nawet 5 minut, przy proponowanym rozwiązaniu może wynieść max kilkadziesiąt sekund (pomijam ewentualne błędy w połączeniu). Nie chodzi o to, żeby zabrać klientowi prawo do anulowania transakcji. Zawsze ma możliwość napisania wiadomości lub zadzwonienia. Jeśli tylko nie spakowaliśmy i nie wysłaliśmy paczki, to oczywiście zostanie zakup anulowany. Klient i tak zawsze może paczki nie odebrać i poprosić o anulowanie zakupu. My akurat nie ścigamy za nieodebrane paczki. Jeśli mamy informację od klienta o anulowaniu a już jest ZK w SGT, to ustawiamy status na Anulowane, unieważniamy ZK i zwracamy wpłatę. Mamy jednak nad tym kontrolę. Aktualnie pracujemy na 2 zmiany. Handlowców nie ma w firmie do 22 ale magazyn pracuje. Dodatkowo na tyle zautomatyzowaliśmy proces przyjmowania ZK, że dodatkowy program sprawdza nam ZK, czy prawidłowo ustawiła się płatność, czy dane zostały przeniesione, czy towaru nie brakuje do zamówienia, czy klient nie napisał jakiejś uwagi do zakupu i jeśli wszystko jest OK, to ZK ląduje od razu w aplikacji dla magazynierów. Po godzinach pracy handlowców, magazyn może przygotować paczkę i jeśli kurier przyjedzie późno, to również ją wysłać bez udziału biura. Musze wykluczyć lub zminimalizować ryzyko, gdzie paczkę wyślemy a Allegro automatycznie zwróci wpłatę. Klient odbierze i trzeba będzie się z nim szarpać o zwrot towaru. Pamiętajmy, że chodzi o dobrowolną funkcję automatycznego zwrotu środków z Allegro Finanse, gdy klient ustawi status Anulowane. Nie muszę jej włączać, ale zmniejszyłaby czas poświęcany na obsługę zamówień anulowanych. Włączone AutoZwroty pieniędzy (co zapowiada Allegro) w najbliższym czasie będą oznaczały również automatyczny zwrot prowizji. trochę pracy nam odpadnie. Zrobiłem edycję - był błąd w czasach przy ostatnim przykładzie.

Otrzymaliśmy wczoraj inf od Allegro o możliwości włączenia automatycznych zwrotów pieniędzy, jeśli klient dokonał płatności i później anulował zakup. Chciałbym to włączyć, jednak od razu zrodziła się obawa. Transakcje obsługujemy z poziomu Subiekta GT, przerzucamy z Sello zakupy do dokumentów ZK. Po utworzeniu ZK transakcja jest oznaczana jako "W trakcie realizacji", co oznacza że klient nie powinien mieć już możliwości zmiany zakupu czy też jego anulowania. Sporadycznie (raz na kilkaset zakupów) zdarza się, że klient anuluje zakup i okazuje się, że ZK jest już w SGT. W teorii nie powinno to mieć miejsca. Podejrzewam, że to zbieg zdarzeń. Np klient w tym samym czasie anulował zakup, co Sello tworzyło ZK. Informacja o zmianie statusu transakcji nie zdążyła się jeszcze zapisać. Druga możliwość, bardzo podobna do pierwszej, to Sello pobrało transakcję, po czym klient anulował zakup. Sello pobiera inf o zakupach powiedzmy co 5 min, więc w przeciągu 5 minut nie będzie wiedział co się dzieje z tym zakupem. W międzyczasie tworzy ZK. Właśnie takich sytuacji dotyczy moja obawa. Jeśli Allegro zrobi automatyczny zwrot środków, to pozostanie jedynie proszenie się klienta o oddanie towaru. Obsługując zakup z poziomu SGT nie będzie widać, że transakcja została anulowana. Zrodziła się myśl. Może udałoby się dorzucić ustawienie, żeby każda transakcja jaka wpada do Sello i ma oznaczenie w serwisie "można przetwarzać" otrzymywała od razu stan "W trakcie realizacji". Zablokuje to od razu możliwość anulowania zakupu, gdy tylko ten zostanie pobrany do bazy Sello. Program dalej może już sobie tworzyć ZK bez obaw, że coś pójdzie nie tak. Pobieranie transakcji można ustawić np co 20 min, więc w wielu przypadkach klienci będą mieli trochę czasu na ewentualne anulowanie. Pozostanie to w decyzji sprzedawcy ile czasu chce dać kupującym na przemyślenie zakupów.

Dziś już dostałem informację o terminie uruchomienia wersji serwisu Allegro pod nazwą Allegro Biznes. Start na 9 lutego. Cóż tu wiele pisać? Mamy sporo kont, mamy w ofercie również produkty kierowane do firm, które w ostatnich latach znacznie podupadły na sprzedaży tym kanałem. Chciałbym spróbować na Allegro Biznes i oczywiście móc to obsłużyć z poziomu jednego programu. @Bartosz Ros jakie macie plany wobec tego tworu? Czy rysuje się jakaś koncepcja? Znane są jakieś terminy? A może nie bierzecie tego pod uwagę? Osobiście myślę, że znajdzie się grono klientów, którzy przejdą z zakupami firmowymi do Allegro. Dużą zachętą może być odroczona płatność nawet do 60 dni oraz możliwość korzystania ze SMART'a. Osobiście wielokrotnie kupowałem artykuły do firmy na Allegro tylko dlatego, że sprzedawca nie miał różnicy w cenach pomiędzy sklepem a Allegro lub na sklepie było taniej ale po doliczeniu kosztów transportu wychodziło podobnie lub drożej. Gdyby ktoś nie widział tej informacji, podsyłam link: https://allegro.pl/zobacz/sprzedaz-dla-firm?utm_source=coma_email&utm_medium=927ab85c-2876-4116-82e7-21dedd59ae1b#promocja_na_start

Nie na jednej bazie Sello. W jednej bazie możesz mieć obecnie tylko przypisany jeden magazyn, bez względu na to ile będziesz miał kont na Allegro. Rozwiązaniem jest stworzenie kilku baz. Każda pod inne konto i w każdej z nich możesz ustawić oddzielny magazyn. Nie wiem tylko jak to będzie działało w praktyce, gdybyś uruchomił kilka razy Sello i każde z nich działałoby w automacie.

Mam tutaj inne doświadczenie. Niemal codziennie zdarza się, że jedna osoba kupuje kilkukrotnie i nie mamy 30 tys transakcji dziennie Czasem są to zakupy na różnych naszych kontach, czasem z jednego ale oddzielne (np. bo smart ma max 4 paczki, więc klient rozbija na kilka zamówień) a czasem po prostu omyłkowo zdublowane zamówienie. Wielokrotnie miewaliśmy problemy z adresami mailowymi. Teraz zamieszczamy je w Polu własnym ZK, dzięki czemu jest zawsze jeden adres przypisany do jednej transakcji. Oczywiście wdrożenie wspomnianej funkcji z możliwością wyboru jej włączenia, nikomu nie będzie przeszkadzało a niektórym osobą się to może nawet przydać.

W takiej sytuacji musisz przejść na płatnego SQL'a. Nie będziesz miał ograniczeń w rozmiarze bazy. Można go kupić również od Insertu: https://www.insert.com.pl/programy_dla_firm/cennik/microsoft.html Jeśli się nie mylę, to ma jednak ograniczenia do programów wydanych tylko przez Insert (zasłyszane pogłoski do potwierdzenia). Oczywiście nie zmniejszy to bazy a jedynie pozwoli pracować na znacznie większej. W kwestii jej rozmiaru i ewentualnego spowolnienia w pracy, przyznam że gdy przeszliśmy na urządzenia typowo serwerowe, nie odczuwam większej różnicy przy korzystaniu z Sello pomiędzy bazą 8GB a 40GB (z drobnymi wyjątkami). Gorzej było z Subiektem GT, który mając historię dokumentów z 6 lat strasznie spowalniał.

@Dominik Heidemann Robiłem 2 miesiące temu czyszczenie bazy istniejącej, zostawiając tylko oferty trwające. Historia transakcji została wyczyszczona, dzięki temu można było też wyczyścić oferty zakończone. Nie musisz tracić historii sprzedaży. Zrobisz sobie kopię aktualnej bazy i zawsze będziesz mógł do niej wrócić. Czyszczenie bazy zostało poruszone też w tym temacie: Udało się bazę zmniejszyć prawie do coś około 10GB z prawie 40GB (nie pamiętam już dokładnych wartości). Nie jest to jednak rozwiązanie długoterminowe, raczej traktuj je jako doraźne. Po 1,5 miesiąca działania na wyczyszczonej bazie jej rozmiar urósł już do 33 GB. Chyba, że zamierzasz co roku zakładać nową bazę.