braki w sello 1.8

[Paweł Wilk 12]

Faktycznie jest ale nie można go w szybki sposób porównać z tym z ustawień konta. Chodzi o to że program którym importuję listy nie widzi tego ostatnio dodanego pola "telefon" i muszę telefon zmieniać ręcznie już po zaimportowaniu.

[Bartosz Rosa 1 775]

Czy będzie to od prawej do lewej czy odwrotnie jest kwestią drugorzędną (chociaż na intuicję chyba lepiej dać najnowszy formularz po lewej). 

Na moją intuicję, to ja bym ostatnio wypełniony formularz dał po prawej - stąd pytam

 

Chodzi o to że program którym importuję listy nie widzi tego ostatnio dodanego pola "telefon" i muszę telefon zmieniać ręcznie już po zaimportowaniu.

To chyba lepiej, żeby ten program importujący listy brał telefon z właściwego miejsca, czyli z transakcji. Inna sprawa, że telefon mógłby się dodawać również do klienta.

 

[axelhorn 21]

To jeszcze pytanie, które kiedyś daaawno chyba było.

Czy można liczyć na zmianę logiki działania Stanu Transakcji, na bardziej logiczną?

 

W tej chwili, jeśli tworzę nową trans ręcznie, ustawiam stan transakcji na w trakcie i zapiszę, to i tak zapisywana jest ona jako nowa i ma gwiazdkę.

Jeśli edytuję transakcję istniejącą nową, to jej stan automagicznie zmiania się w momencie jej zapisania. Jeśli bym chciał mimo to aby dalej mimo edycji była nowa to się nie da. Trzeba powtórnie ją wyedytować.

Logicznym byłoby, aby sello automagicznie zmianiało stan edytowanej z nowa na w trakcie w momencie edytowania jej a nie zapisywania, gdyż w trakcie edytowania, użytkownik może podjąć inną decyzję niż automat.

To samo przy trans tworzonych ręcznie. Mogę chcieć ją zapisać z innym statusem niż nowa.

[axelhorn 21]

Jeszcze jeden wkur*cy defekt 1.8.

Jeśli edytuję właśnie transakcję np. taką, co to już ma swoje fody, a w tle ściągają się dane i w tym formularze, to nie ma później szans na zapisanie danych zmienianej aktualnie transakcji. Wyskakuje błąd zapisu bazy. Jedyna opcja to anulowanie i powtórna edycja podczas gdy dane się nie ściągają. Co przy pracy na kilku stanowiskach zakrawa na rosyjską ruletkę.

[MARCIN e-kupowanie.pl 1 015]

hmmm a co z transakcją która wpływa jako nowa w zakładce oczekujące na płatność a klient wybrał przesyłkę za pobraniem

Kiedy zatwierdzę, że ma być za pobraniem znajdzie się również w zakładce 'do paczek' - z mojego punktu widzenia jest opłacona, zatwierdzona i gotowa do wysłania.

 

Natomiast jeszcze jedna kwestia, najmłodszy fod po lewej oznacza ten najpóźniej wypełniony (ostatni), starsze mają być po prawej?

Tak, dokładnie. Najnowszy na wierzchu po otwarciu zakładki 'Formularze'. A może by tak węższe te zakładki u dołu i nieprzeczytane formularze na czerwono? Są klienci, którzy potrafią 5 razy przysłać FOD.

 

Wyskakuje błąd zapisu bazy.

Tak, to denerwujące. Ile to razy wpisywałem coś powtórnie...

 

 

[e-strefa 0]

 

Wyskakuje błąd zapisu bazy.

Tak, to denerwujące. Ile to razy wpisywałem coś powtórnie...

 

 

 

Nie poruszajcie tego tematu, bo mi od razu cisnienie skacze

[litex 4]

WAZNE

 

 

1. klient kupuje

2. FOD z adresem zostaje zakaceptowany ikonka zielona

3. klient pisze emaila z NOWYM adres innym niz w FOD

4. dodaje adres , daje ignoruj zmieny w FODA

5. odbieram nowe fody -> ikonka robi sie zielona.

 

6. procownik przy pakowania poprawia.

 

6. wysylka idzie nie na ten adres co miala

 

 

PILNE DO POPRWY @@@

[MARCIN e-kupowanie.pl 1 015]

WAZNE

 

 

1. klient kupuje

2. FOD z adresem zostaje zakaceptowany ikonka zielona

3. klient pisze emaila z NOWYM adres innym niz w FOD

4. dodaje adres , daje ignoruj zmieny w FODA

5. odbieram nowe fody -> ikonka robi sie zielona.

 

6. procownik przy pakowania poprawia.

 

6. wysylka idzie nie na ten adres co miala

 

 

PILNE DO POPRWY @@@

 

A co nie robi się tak??? Powinno być tak że zaptaszkowany FOD się odptaszkowuje jeśli pojawi się nowy FOD (przychodzący po zaptaszkowaniu)!!!

[Bartosz Rosa 1 775]

Logicznym byłoby, aby sello automagicznie zmianiało stan edytowanej z nowa na w trakcie w momencie edytowania jej a nie zapisywania, gdyż w trakcie edytowania, użytkownik może podjąć inną decyzję niż automat.

To samo przy trans tworzonych ręcznie. Mogę chcieć ją zapisać z innym statusem niż nowa.

Wydaje się to rozsądne, ale po co zapisywać transakcję, skoro nic w niej nie było zmieniane? Można ją anulować (escape).

 

Jeśli edytuję właśnie transakcję np. taką, co to już ma swoje fody, a w tle ściągają się dane i w tym formularze, to nie ma później szans na zapisanie danych zmienianej aktualnie transakcji

Obejście tego problemu będzie trudne. Możemy spróbować zrobić mechanizm, który czeka, powiedzmy 20 sekund w przypadku zablokowanej transakcji, ponawiając próbę zapisu, dając szansę użytkownikowi na zapisanie transakcji właśnie edytowanej.

 

1. klient kupuje

2. FOD z adresem zostaje zakaceptowany ikonka zielona

3. klient pisze emaila z NOWYM adres innym niz w FOD

4. dodaje adres , daje ignoruj zmieny w FODA

5. odbieram nowe fody -> ikonka robi sie zielona.

W poprawce, którą przygotowujemy po ponownym pobraniu tego samego formularza nie są zmieniane stany transakcji. Są zmieniane, tlyko jeśli przyjdzie nowy formularz.

 

[Michał Olszewski 1]

hmmm a co z transakcją która wpływa jako nowa w zakładce oczekujące na płatność a klient wybrał przesyłkę za pobraniem

Kiedy zatwierdzę, że ma być za pobraniem znajdzie się również w zakładce 'do paczek' - z mojego punktu widzenia jest opłacona, zatwierdzona i gotowa do wysłania.

 

 

to ja wiem że wpada do paczek raczej to chyba wszyscy wiedzą tylko chodzi o to że musisz ją jakoś odnaleźć z pośród transakcji oczekujących więc aby nie sprawdzać wszystkich, dodatkowe rozróżnienie ułatwi pracę

[litex 4]

WAZNE

 

 

1. klient kupuje

2. FOD z adresem zostaje zakaceptowany ikonka zielona

3. klient pisze emaila z NOWYM adres innym niz w FOD

4. dodaje adres , daje ignoruj zmieny w FODA

5. odbieram nowe fody -> ikonka robi sie zielona.

 

6. procownik przy pakowania poprawia.

 

6. wysylka idzie nie na ten adres co miala

 

 

PILNE DO POPRWY @@@

 

A co nie robi się tak??? Powinno być tak że zaptaszkowany FOD się odptaszkowuje jeśli pojawi się nowy FOD (przychodzący po zaptaszkowaniu)!!!

 

to sie dzieej

 

cytuje bartka:

W poprawce, którą przygotowujemy po ponownym pobraniu tego samego formularza nie są zmieniane stany transakcji. Są zmieniane, tlyko jeśli przyjdzie nowy formularz.

[Michał Olszewski 1]

potwierdzam ptaszki ignorowania nawet odznaczają się gdzie przesyłkę już wysłaliśmy więc raczej klient nie wypełnił foda

[tadzimir.pl 155]

Logicznym byłoby, aby sello automagicznie zmianiało stan edytowanej z nowa na w trakcie w momencie edytowania jej a nie zapisywania, gdyż w trakcie edytowania, użytkownik może podjąć inną decyzję niż automat.

To samo przy trans tworzonych ręcznie. Mogę chcieć ją zapisać z innym statusem niż nowa.

Wydaje się to rozsądne, ale po co zapisywać transakcję, skoro nic w niej nie było zmieniane? Można ją anulować (escape).

Popieram Axelhorna.  Wprawdzie dla mnie ten sposób działania jest dość rzadko irytujący, ale jednak.  Nie chodzi kwestię, czy zapisać, czy anulować zmiany tylko o sytuację, gdy zmiany zostały wprowadzone, ale pomimo tego chcę, żeby transakcja była w stanie Nowa.  Obecnie w momencie zapisywania zmian jej stan jest zmieniany na W trakcie realizacji (co powoduje, że trzeba transakcję edytować 2 razy - raz żeby wprowadzić zmiany i drugi raz żeby zmienić z powrotem na Nowa) - gdyby stan był przestawiany w momencie otwarcia okna edycji to sprawa załatwiona - mogę od razu zmienić dane i z powrotem ustawić stan Nowa.

 

Jeśli edytuję właśnie transakcję np. taką, co to już ma swoje fody, a w tle ściągają się dane i w tym formularze, to nie ma później szans na zapisanie danych zmienianej aktualnie transakcji

Obejście tego problemu będzie trudne. Możemy spróbować zrobić mechanizm, który czeka, powiedzmy 20 sekund w przypadku zablokowanej transakcji, ponawiając próbę zapisu, dając szansę użytkownikowi na zapisanie transakcji właśnie edytowanej.

Najlepiej byłoby żądania zapisu dla zablokowanych transakcji kolejkować i wprowadzać je dopiero po zwolnieniu blokady - rozumiem jednak, że takie rozwiązanie może powodować kolejne problemy w przypadku obiektów, których użytkownik długo nie zwalnia.  Może więc taki kompromis z niewielkim opóźnieniem będzie dobrym rozwiązaniem - tylko _koniecznie_ z wyświetleniem informacji użytkownikowi edytującemu transakcję, że musi ją zapisać w ciągu x sekund, bo inaczej straci dane.

Podobne rozwiązanie należałoby wprowadzić w przypadku tworzenia dokumentów, gdzie również następuje aktualizacja transakcji w tle.

[Bartosz Rosa 1 775]

gdyby stan był przestawiany w momencie otwarcia okna edycji to sprawa załatwiona

Niestety musi być on przestawiany w momencie zapisywania transakcji. Przy zapisywaniu transakcji wykonywanych jest naprawdę sporo rzeczy, które również zależą od stanu transakcji. Wszystkie te algorytmy mogły by się po prostu "rozjechać" gdyby stan był ustawiany w innym miejscu. Wymagało by to zatem gruntownych zmian w logice działania transakcji a jest to dosyć newralgiczny punkt.

 

Z zapisem danych w tle pomyślimy, ale na pewno nie wejdzie do tej poprawki, bo sprawa wymaga dokładnego zbadania, czy w ogóle da się to zrobić.

 

[pozy 4]

Chciałbym jeszcze wrócić do tematu porównywania wpłat z PayU z wpłatą w transakcji.

Teraz jest tak:

-Gdy w formularzu jest jakaś wpłata z PayU, to wartość ta jest porównywana z wpłatą w transakcji i gdy te wartości są różne, to ikonka formularza robi się czerwona. Jeśli nie ma wpłaty przez PayU, to nie jest ona z niczym porównywana (bo nie ma to sensu).

-Ikonka z dolarem jest zielona wtedy, gdy wpłata z PayU jest taka sama, jak wartość transakcji (czyli w uproszczeniu wartość towarów+koszt dostawy). Wysokość kwoty wpłaconej nie ma tu nic do rzeczy.

Rozumiem, że ma być tak:

-Wpłata PayU nigdy nie ma być porównywana z wpłatą w danych transakcji i nie powinna ona wpływać na kolor ikonki formularza.

-Działanie ikonki z dolarem nie zmienia się.

 

Po takiej zmianie możliwa będzie sytuacja, że obie ikonki (formularz i PayU) będą zielone, mimo że wysokość wpłaconej kwoty z transakcji będzie wzięta z kosmosu, bo po prostu w żadnych porównaniach nie będzie ona uwzględniana.

 

Pojawiają się też dodatkowe pytania:

- Czy na zakładce 'Formularze' linijka z wpłatami powinna się świecić na czerwono, gdy wartości są różne?

- Czy ma pozostać przycisk do kopiowania tej wartości?

- Oraz czy po naciśnięciu przycisku 'Kopiuj wszystko' wpłata także ma się kopiować , czy nic ma się nie dziać?

[e-strefa 0]

Po takiej zmianie możliwa będzie sytuacja, że obie ikonki (formularz i PayU) będą zielone, mimo że wysokość wpłaconej kwoty z transakcji będzie wzięta z kosmosu, bo po prostu w żadnych porównaniach nie będzie ona uwzględniana.

Dlatego ja proponuje w takim przypadku zmienic kolor ikonki dolara.

 

Pojawiają się też dodatkowe pytania:

- Czy na zakładce 'Formularze' linijka z wpłatami powinna się świecić na czerwono, gdy wartości są różne?

- Czy ma pozostać przycisk do kopiowania tej wartości?

- Oraz czy po naciśnięciu przycisku 'Kopiuj wszystko' wpłata także ma się kopiować , czy nic ma się nie dziać?

 

3xtak.

[Michał Olszewski 1]

Chciałbym jeszcze wrócić do tematu porównywania wpłat z PayU z wpłatą w transakcji.

Teraz jest tak:

-Gdy w formularzu jest jakaś wpłata z PayU, to wartość ta jest porównywana z wpłatą w transakcji i gdy te wartości są różne, to ikonka formularza robi się czerwona. Jeśli nie ma wpłaty przez PayU, to nie jest ona z niczym porównywana (bo nie ma to sensu).

-Ikonka z dolarem jest zielona wtedy, gdy wpłata z PayU jest taka sama, jak wartość transakcji (czyli w uproszczeniu wartość towarów+koszt dostawy). Wysokość kwoty wpłaconej nie ma tu nic do rzeczy.

Rozumiem, że ma być tak:

-Wpłata PayU nigdy nie ma być porównywana z wpłatą w danych transakcji i nie powinna ona wpływać na kolor ikonki formularza.

-Działanie ikonki z dolarem nie zmienia się.

 

Po takiej zmianie możliwa będzie sytuacja, że obie ikonki (formularz i PayU) będą zielone, mimo że wysokość wpłaconej kwoty z transakcji będzie wzięta z kosmosu, bo po prostu w żadnych porównaniach nie będzie ona uwzględniana.

 

Pojawiają się też dodatkowe pytania:

- Czy na zakładce 'Formularze' linijka z wpłatami powinna się świecić na czerwono, gdy wartości są różne?

- Czy ma pozostać przycisk do kopiowania tej wartości?

- Oraz czy po naciśnięciu przycisku 'Kopiuj wszystko' wpłata także ma się kopiować , czy nic ma się nie dziać?

 

 

przede wszystkim linijka do zapłaty powinna się sumować jeśli jest więcej niż jeden FOD.

 

Klienci często potrafią do każdego foda wpłacić kwotę więc skoro przełączam się miedzy zakładkami to kwota w lewym oknie powinna się sumować a nie zastępować jaka już została wprowadzona

 

ja bym jednak wszystkie linijki wpłat oddzielił od adresu i notatek

[Alwin Kolano 143]

... no i dziś moje zaufanie do fod'ow sellowych (allegrowych) trochę spadło, otóż zadzwonił klient czy jego przesyłka została wysłana (tydzień po złożeniu zamówienia) - sprawdziliśmy i okazało się, iż są maile Nowa wpłata etc. a informacji w sello o formularzach i wpłatach - brak.

 

Po odznaczeniu "Na podstawie dziennika zdarzeń" formularz się pojawił.

 

Pytanie jak często należy tą opcję wyłączać ?

 

Druga sprawa to w Transakcjach oczekujących na płatność są transakcje z "czerwonymi dolarami" - okazuje się, iż są podpięte formularze z dostawą i płatnością dotyczą już historycznych paczek dawno wysłanych - problem polega na tym, że przez nieuwagę można zarejestrować mniejszą kwotę, a następnie wysłać maila z informacją o niedopłacie.

Czy to tak ma działać ??

[herman 3]

... no i dziś moje zaufanie do fod'ow sellowych (allegrowych) trochę spadło, otóż zadzwonił klient czy jego przesyłka została wysłana (tydzień po złożeniu zamówienia) - sprawdziliśmy i okazało się, iż są maile Nowa wpłata etc. a informacji w sello o formularzach i wpłatach - brak.

 

Po odznaczeniu "Na podstawie dziennika zdarzeń" formularz się pojawił.

 

Pytanie jak często należy tą opcję wyłączać ?

 

Druga sprawa to w Transakcjach oczekujących na płatność są transakcje z "czerwonymi dolarami" - okazuje się, iż są podpięte formularze z dostawą i płatnością dotyczą już historycznych paczek dawno wysłanych - problem polega na tym, że przez nieuwagę można zarejestrować mniejszą kwotę, a następnie wysłać maila z informacją o niedopłacie.

Czy to tak ma działać ??

 

Ja swój dzień zaczynam zawsze od synchro transakcji i formularzy pobieranych od poczatku. Po tym robie synchro jeszcze raz na podstawie historii aby ewentualnie coś jeszcze wpadło.

[pozy 4]

Pojawiają się też dodatkowe pytania:

- Czy na zakładce 'Formularze' linijka z wpłatami powinna się świecić na czerwono, gdy wartości są różne?

- Czy ma pozostać przycisk do kopiowania tej wartości?

- Oraz czy po naciśnięciu przycisku 'Kopiuj wszystko' wpłata także ma się kopiować , czy nic ma się nie dziać?

 

3xtak.

OK, da się tak zrobić. Ale podejrzewam, że dla wielu użytkowników (zwłaszcza nieczytających forum) mogłoby to być niejasne. Na liście transakcji ikonka jest zielona, a po wejściu w edycję transakcji, w zakładkę Formularze mamy linijkę zaznaczoną na czerwono. I nie wiadomo dlaczego. Ciągle nie jestem przekonany, czy to jest dobry pomysł.

[Alwin Kolano 143]

przede wszystkim linijka do zapłaty powinna się sumować jeśli jest więcej niż jeden FOD.

 

Klienci często potrafią do każdego foda wpłacić kwotę więc skoro przełączam się miedzy zakładkami to kwota w lewym oknie powinna się sumować a nie zastępować jaka już została wprowadzona

 

ja bym jednak wszystkie linijki wpłat oddzielił od adresu i notatek

 

Sumowanie to bardzo zły pomysł. Powodem jest, że w transakcji z 16 grudnia podpięte mam trzy formularze jeden z 2011-11-22 (paczka już wysłana) i drugi z 2011-12-07 (paczka wysłana)i trzeci prawidłowy z 16 grudnia z godz. 19:18 , nie wiem czy to normalne ale chyba tak się dzieje w przypadku gdy klient dokonuje ponownego zakupu na tej samej aukcji (np. aukcje sklepowe 30 dni).

 

 

[nakina 0]

a ja już drugi raz mam głupi błąd... po zaakceptowaniu formularza, a w nim przesyłki pobraniowej.... Sello się... zamyka   Po ponownym uruchomieniu transakcja dalej siedzi w niezapłaconych a nie "do wysyłki". Przez akceptację FOD za żadne skarby się tego nie da zrobić bez natychmiastowego zamknięcia się sello, próbowałam parę razy dla tej samej transakcji. Obie musiałam akceptować krok po kroku, po staremu, ręcznie.

Miałam już 2 takie przypadki.

 

No i taki drobiazg, ale dla mnie przydatny. Przy tworzeniu klienta do głównego okna z adresem dodano okienko do wpisania telefonu (i chwała !!!), ale czy można by jeszcze dodać tam okienko do wpisania e-mail? Teraz trzeba wchodzić do kontakt do e-mail i wpisywać go. Dla transakcji ze sklepu internetowego wpisuje się klienta od zera, taka mała dogodność przyspieszyłaby troszkę pracę. Małe, a cieszy, i oszczędza te parę sekund skakania po okienkach. Pewno to drobiazg do zrobienia, więc jakby się w poprawce też znalazł, to byłoby miło.

Pozdrawiam

nakina

[damianus21 1]

Nie zauważyłem w tym wątku informacji o braku filtrów opartych na formularzach. Naszym zdaniem bardzo by się przydały szczególnie kiedy chcemy wysłać informacje do klientów, którzy nie wypełnili jeszcze formularza.

 

Np. z instrukcją jak to zrobić ;-)

[herman 3]

Zdecydowanie trzeba zmienić podpinanie FODów do transakcji. Nie może być tak, że FOD z wcześniejszą datą podpinanay jest do transakcji z datą późniejszą.

 

Jest to kategoryczny błąd - mam Klientów, którzy kupują 2-3 razy w tygodniu, płacą przez PZA i do transakcji w czwartek i piątek mam FODY oraz wpłaty z transakcji poniedziałkowych co tylko utrudnia księgowanie.

[Bartosz Rosa 1 775]

Zdecydowanie trzeba zmienić podpinanie FODów do transakcji. Nie może być tak, że FOD z wcześniejszą datą podpinanay jest do transakcji z datą późniejszą.

To akurat można poprawić, ale już do późniejszej transakcji będą podpięte wcześniejsze formularze. Niestety transakcja jest bytem wymyślonym w Sello i nie ma 100% przełożenia na to co jest w Allegro. Do danej aukcji jest do pobrania po prostu lista fodów, które jakoś trzeba podpiąć do transakcji.