Dominik kidl

Log wysłałem na priv. Transakcja, którą opisałem wyżej z danymi klienta z Anglii, to niestety moje niedopatrzenie. Pochodzi z 14 stycznia, więc ze starszej wersji Sello. Problem jednak występuje. Wczoraj mieliśmy drugą sytuację, ze świeżą transakcją. Poniżej screeny. Mamy trzy adresy: a) adres z konta - nie posiadał ulicy b) adres odbiorcy - klient wskazał inny niż jego dane z konta c) adres paczkomatu InPost zwrócił błąd z powodu braku ulicy w danych odbiorcy. Sello w transakcji ma tylko dwa adresy "a" oraz "c". Poniżej dane z konta klienta: Poniżej dane z transakcji:

Bartek jesteś pewien, że nie może podać innego adresu? Przykład poniżej: W tej sytuacji, do etykiety został pobrany adres Paczkomatu i tu jest OK, oraz dane odbiorcy z adresem z Wielkiej Brytanii. InPost zwraca komunikat "receiver - address - post_code - invalid". Niestety ma racje. Kod pocztowy jest nieprawidłowy.

Poprawka z mojej strony. W Sello nie widzę nigdzie 3 adresów. Są dwa, adres punktu odbioru i adres z danych konta. Niestety dochodzą dane odbiorcy, które mogą być inne niż dane z konta allegro. Zamawiający Jan Kowalski, może wprowadzić, że paczkę w Poczcie odbierze córka, która z męża ma Grażyna Kochanowska. Poczta może nie wydać paczki. Przykład z dzisiaj. Klientka ma konto zarejestrowane ma dane z Wielkiej Brytanii. Kupiła towar z dostawa do Paczkomatu, Odbiorcą jest osoba z adresem z Polski. Trzy różne adresy. gdyby to był odbiór w Poczcie, klientka mogłaby nie odebrać paczki z powodu braku zgodności danych odbiorcy.

Szukałem na forum - nie znalazłem, lub nie miałem tyle czasu żeby znaleźć. Tworzymy z Sello ZK i dalej procesujemy zamówienie w Subiekcie. Listy przewozowe są generowane za pomocą ProstejPaczki. W przypadku paczkomatów, mamy do czynienia z 3 adresami: Adres klienta z konta allegro - wrzucany do danych głównych kontrahenta w SGT Dane paczkomatu - wrzucane do danych do wysyłki w SGT Adres odbiorcy paczki - nie wrzucane nigdzie do danych kontrahenta w SGT Z punktem 3 jest problem. Ważne jest, żeby te dane były zgodne ze stanem faktycznym. Szczególnie na wypadek przygód w doręczeniu paczki. Niestety Subiekt na tą chwilę nie dostaje nigdzie danych odbiorcy od Sello. @Bartosz Rosa i @Piotr Taraszkiewicz jakieś pomysły jak sobie z tym poradzić? Dane Paczkomatu wrzucamy również do Pola własnego za pomocą funkcji ProstejPaczki. W ten sposób sa one przypisane per zamówienie a nie per klient. W sytuacji, gdy ten sam klient w krótkim czasie złoży kilka zamówień, to dane nie zostaną nadpisane. Jeśli się nie mylę (za mało czasu, żeby szukać po ZK przykładu), to w przypadku Punktów odbioru Poczty Polskiej, będzie ten sam problem. Sello wrzuci do karty kontrahenta dane z konta Allegro jako główne, do adresu dostawy dane z punktu odbioru i brakuje nam danych odbiorcy, co w przypadku Poczty Polskiej może być problemem. Mogą nie wydać paczki.

Każdy trochę inaczej wykorzystuje Sello o SGT. Może trochę uogólniając, wg mnie są dwie sytuacje wykorzystywania sello w obrębie transakcji: obsługa transakcji z poziomu Sello, tworzenie listów itd. Tutaj wg mnie nie powstaje tworzenie ZK a jedynie dokumentu końcowego obsługa zamówień poza Sello, np przez SGT. Sello służy tylko do zaciągnięcia transakcji i przeniesienia do innego systemu. W tym przypadku użytkownik może przerzucać wszystkie transakcje tworząc ZK nawet gdy jest nie opłacona - tak robiliśmy do listopada 2019, dalej procesując ZK w SGT przerzucać tylko transakcje gotowe do realizacji, czyli "zielone". Pozostałe (nieopłacone, bez formularza itd) zostają w Sello. Wg mnie tj lepsze rozwiązanie. Skoro klient może zmienić dane, to tworzenie ZK przed zamknięciem transakcji nie ma sensu. Po utworzeniu ZK, nie mamy możliwość przerzucenia nowych danych z transakcji do SGT. Aktualnie stosujemy to rozwiązanie. Transakcje wiszą w Sello do czasu ich zamknięcia. Opcja 2.2. niestety nie rezerwuje stanów magazynowych, co faktycznie jest pewnym problemem. Trzeba wybrać mniejsze zło, albo brak rezerwacji albo ewentualne pomyłki w danych transakcji. Stosując poniższe moglibyśmy wybrać, czy chcemy mieć automatyczne ZK do wszystkich transakcji, czy tylko do tych kompletnych. Wg mnie ta opcja ma same plusy. Trzymam mocno kciuki za szybkie wdrożenie nowego synchronizatora i za tym, żeby wspomniane opcje tam się pojawiły. Przypomnę tylko Gdybyśmy zdążyli do tego czasu, to zaoszczędzę realne pieniądze. Na pewno nie raz wypiję Wasze zdrowie

Jeśli uda się wdrożyć automatyczne grupowanie transakcji, to może aktualne auto tworzenie ZK wystarczy? Trzeba byłoby tylko jakoś opóźnić utworzenie ZK, tak żeby wcześniej Sello zrobiło grupowanie. A może udałoby się dodać do ustawień coś typu filtr "twórz ZK tylko do zielonych transakcji". To załatwiłoby całkowicie temat. Zamówienia niekompletne zostałyby w Sello do "ręcznej obróbki". Zamówienia kompletne miałbym w SGT i mógłbym kolejnymi automatami ustalić ich "wstępny los". P.S. Sezon wiosenny coraz bliżej, mamy wtedy 2-3 razy więcej zamówień. "Całowałbym po rękach" gdybyśmy zdążyli zautomatyzować ten proces

Odświeżę ten temat. Oczywiście również jestem za wprowadzeniem sugerowanych rok temu zmian. Potrzebuję wiedzieć jeszcze kilka rzeczy. Jeśli jest cień nadziei, to proszę o przybliżony termin na wprowadzenie: automatycznego grupowania transakcji po formularzach ewentualnego, automatycznego tworzenia ZK w Subiekcie GT Aktualnie istnieje możliwość tworzenia automatycznie ZK, jednak są one tworzone do każdej pozycji oddzielnie (przynajmniej tak było, gdy ostatnio tą funkcję testowałem). Gdy klient kupował 3 przedmioty w jednej transakcji, to od razu powstawały 3 ZK w SGT. Efekt oczekiwany, to zgrupowanie transakcji i utworzenie ZK tylko do tych zielonych (do przetworzenia). @Bartosz Rosa Pytam o powyższe, ponieważ rozważam zamówienie w ProstejPaczce funkcji, które wykonywałyby takie działania na bazie Sello. Niestety nie są to tanie rzeczy i byłbym zniesmaczony, gdyby np za miesiąc lub dwa, takie możliwości pojawiły się bezpośrednio w Sello. Oczywiście jestem za tym, żeby jak najszybciej wdrożyć to do Sello. W naszym przypadku, przy rozwiązaniu gdzie zamówienia obsługujemy przez Subiekta, tracimy codziennie od 2 - 3 godzin na tworzenie ZK. Dziś sprawdzałem i tylko 8% zamówień wymaga interwencji (np notatka od kupującego). Pozostałe można byłoby od razu wysłać na magazyn do realizacji bez ingerencji pracownika. To nie jedyna oszczędność. Przy pracy na dwie zmiany, nie musiałbym trzymać handlowca do 22:00 tylko po to, żeby przyjmował zamówienia. Mając ZK w SGT, przy pomocy ProstejPaczki, resztę działań też zautomatyzuję. Dla nas, w sezonie to oszczędność niemal jednego stanowiska pracy, więc "gra warta świeczki" Do listy propozycji dorzucam jeszcze: tworzenie zestawów zarządzanie ceną (kiedyś już wspominałem o możliwości ustawienia zadań automatycznych, np żeby w niedzielę po południu ceny poszły o 3% w górę) trzymanie kilku cen produktu z SGT i przypisywanie cennika do konta allegro (aktualnie stosując różną politykę cenową na różnych kontach, trzeba przełączać w ustawieniach ceny i zaczytywać je do Sello, wtedy można zaktualizować ceny w ofertach. Odpowiednie i szybkie zarządzanie cenami w ofertach dałoby nam co najmniej kilku procentowy, większy zarobek) obsługa rabatów Dla przypomnienia (nie żeby wywierał presję ? Poniżej jeszcze jeden temat, starszy ale jest tam kilka pozycji ciekawych, których nadal nie ma: Za pozostałe, które wdrożyliście... dziękuję.

Skrzynka nadawcza jest pusta. Brak jakichkolwiek filtrów: Ostatni błąd występował 16 grudnia. Od tego czasu wszystkie testy są OK. Nic nie robiłem w ustawieniach. Szablon pozostał ten sam.

tak, dzisiaj pracownik wysyłał maila i również się powtórzył. Dziś wysyłane były wiadomości za pomocą opcji z PPM "Mailing". Nie wiem ile transakcji zaznaczy do wysyłki wiadomości, ale jest wysłano 11 z 12. Jeśli wysyłałem jedną wiadomość, to błąd był "Wysłano 1 z 2".

przejęzyczenie... W skrzynce nadawczej nie ma nic. W skrzynce "Wysłane", są wiadomości faktycznie wysłane.

Jedno konto z jednym adresem mailowym. Do pozostałych kont nie dodawałem. Specjalnie chciałem przetestować na jednym mailu. W skrzynce nadawczej nie ma nic poza tymi wiadomościami faktycznie wysłanymi.

Testowałem dziś wiadomości. Dotychczas radziliśmy sobie bez obsługi wiadomości przez Sello. Chcę sprawdzić, czy to w czymś nam pomoże. Niestety spotkałem błąd jak w temacie. (null); IDispatch error #3375; -2147217617 Przesyłam screen Dla pewności, wiadomość testowa poszła bez załączników, tylko sam tytuł. Testowałem też z treścią i podpisami. Wysyłałem testowa na swoją drugą skrzynkę i dochodzą pomimo błędu. Czy sello w trakcie wysyłki wiadomości kieruje ją na dwa adresy? Powyżej wygląda jakby wysyłało 2 maile i tylko jeden poszedł. Dla pewności, tj raport z wysyłki jednej wiadomości. Włączyłem logi w serwisowym i uruchomiłem Sello jako admin, plik z logiem został utworzony, ale ma rozmiar 0 KB.

W SGT będziesz miał 1 komplet z wzorem np A, drugi komplet z wzorem B itd? Jeśli tak i podepniesz jeden towar do oferty, to do dokumentu końcowego będziesz go musiał zmieniać. Dużo zależy od tego, jak macie u siebie realizację rozwiązaną. Skąd osoba realizująca zlecenie wie, co ma być na koszulce? Z kartoteki towarowej Subiekta, czy z wydruku z Sello?

W mojej ocenie, oferta z możliwością wyboru koloru, modelu, nadruku itd, w wielu kategoriach lepiej sprzedaje niż oferty rozbite na poszczególne nadruki. Automatycznie będzie to liczone do trafności. Ofertę z wyborem nadruku obejrzy załóżmy 1 tys osób, ale dokona w niej zakupu 5%, czyli 50 osób. Rozbijając to na kilka ofert Allegro, statystyki wykażą ruch w ofertach, ale mniejszy odsetek będzie decyzji zakupowych. To trochę zaniży jakość w trafności. Osobiście przetestowałbym oba modele sprzedaży. Pod kątem SGT, nie ma idealnego rozwiązania. Nie połączysz kilku towarów/kompletów do jednej oferty z Sello. Wystawiając ofertę z wyborem wzoru, skazujesz się na ręczną obsługę takiej transakcji. Wystawiając każdy wzór do osobnej oferty i spinając je w wielowariantowość, będziesz mógł przypisać komplet do konkretnej oferty. Decyzje będziesz musiał podjąć sam.

Dużo zależy od okresu jaki analizowali. My nadal na wszystkich kontach jesteśmy na starych zasadach. Ostatnio 30 października nas informowali o tym, że się jeszcze nie dostosowaliśmy do wymogów nowego rozliczenia. Od naszego opiekuna dowiedziałem się, za jaki okres analizowali nasze przekazywanie maili i faktycznie zawierał on przedział czasowy, gdzie jeszcze częściowo nie przekazywaliśmy wszystkich adresów. W sumie minął już miesiąć, od kiedy spełniamy warunki, ale nadal nas nie przełączyli. Myślę, że tj kwestia ich możliwości technicznych lub czasowych na weryfikowanie przygotowania sprzedawcy. Po wdrożeniu odpowiednich rozwiązań wysłałem im maila, żeby nas sprawdzili, ale dostałem odpowiedź, że nie robią tego na życzenie sprzedawcy i dadzą znać w odpowiednim czasie. A więc czekam... "z niecierpliwością".

Jeśli do metody dostawy mam znacznik COD i podpięte dostawy Allegro z przedpłatami oraz COD, tzn że na liście transakcji, ustawiając filtr "tylko z COD" dostanę wynik zawierający również przedpłaty? Jakoś nie zauważyłem do tej pory tego i nikt mi w firmie nie zgłaszał, żeby tak było.

właśnie miałem stare ustawienia dla DPD, gdzie oddzielnie były przedpłaty i oddzielnie COD. Później chciałem zmniejszyć ilość form wysyłki i zacząłem łączyć je w jedną opcję. To by tłumaczyło, dlaczego w formularzu nie identyfikuje dostawy. Ale, wg mnie, nie tłumaczy dlaczego zaczytało inna formę dostawy niż powinno w transakcji. Mam tak samo skonfigurowane teraz DPD, Pocztex, Paczkomaty i w transakcji forma dostawy jest właściwa. Tylko dla tej jednej opcji GEIS nie przypisało dobrej formy. Czy coś stoi na przeszkodzie, żeby łączyć przedpłaty i COD w jednej metodzie dostawy? Tzn, żeby taka możliwość była w Sello i dobrze program rozpoznawał dostawy? Czy do aktualnego rozwiązania (oddzielnie COD i przedpłata), jest jakieś uzasadnienie?

Wysyłamy do Allegro maila z "+". Nie dostałem od nich potwierdzenia, że jesteśmy gotowi na zmianę, ale tez żadnej inf, że nie jesteśmy gotowi. Dostajemy nadal wpłaty za transport. Poniżej screen zakupu z przed kilku minut: Jak widać, wysyłka z pakietu SMART, kwota za transport wpłacona. Tak jest na wszystkich naszych kontach.

Robiłem ostatnio trochę porządków w sposobach wysyłki. Dodałem Nowy sposób "Geis Cargo" do którego przypisałem dostawy Allegro: Kurier Geis i Kurier Geis pobranie, jak poniżej: W cenniku dostaw włączyłem opcję "Kurier Geis" i wysłałem zmianę do Allegro. Oferta, której sparawa dotyczy, została zaktualizowana. Klient kupuje w danej ofercie. Wybiera tą metodę dostawy: Tymczasem w transakcji Sello mam: 1. W danych z formularza: 2. W danych z transakcji: Pogląd na całość: Skąd "DPD, Nieaktywne3"? Fakt, mam taką metodę dostawy. Nie używam jej już, stąd też nazwa "Nieaktywne". W Sello, ten sposób wysyłki nie ma przypisanej żadnej metody dostawy z Allegro: Dlaczego Sello nie przypisało właściwej metody dostawy? Dlaczego nie rozpoznało metody dostawy w formularzu zakupowym? Coś źle ustawiłem?

U nas bez zmian. Dostajemy wpłaty za przesyłkę na wszystkich kontach.

u mnie było: Nazwa modułu z błędem: Allegro.dll to jest jednak informacja z przedwczoraj. Wczorajszego komunikatu nie skopiowałem. Uznaję na to chwilę temat za zamknięty. Nie mam więcej danych, więc szkoda naszego czasu, Jeśli coś się pojawi, na pewno dam znać.

Tak, plik się utworzył. Data i godzina zgadza się dokładnie z czasem wystąpienia błędu. Waga pliku "0". Wewnątrz brak danych.

@Bartosz Rosa Wczoraj, gdy u nas występował problem, pobranie parametrów nie pomagało (dla ofert trwających oraz oddzielnie robiłem dla wszystkich). Chciałem wygenerować dla Was LOG ale niestety plik był pusty. Uruchomiłem serwisowy jako admin, włączyłem logowanie, zapisałem. Uruchomiłem Sello jako admin, doprowadziłem do wywołania błędu, program się zamknął. Zaglądam do pliku, a tam pusto. Ktoś wyżej też już pisał, że miał taka sytuację. Możliwe, że błąd nie zapisuje się w logu? Czy coś źle zrobiłem.

Nadal występuje problem u Ciebie? Wczoraj wieczorem u nas problem znikną zraz po wyżej wstawionej informacji z odpowiedzią Allegro, że usunęli błąd.

potwierdzam, u nas również działa