Użytkownik GT/NEXO

Weźmy pod uwagę najbardziej trywialny przypadek... do ZK (które nie jest zafakturowane fakturą zaliczkową) złożonego tylko z 1 pozycji w ilości TW1=100szt wydano poprzez tylko jedną WZ-kę TW1=200szt. W kolumnie "Zrealizowane" tego ZK, mamy błędną informację że wydano 100szt a fizycznie przecież wydano w w/w przypadku 200szt. Reasumując ZK pokazuje ilości wydane ograniczając się tylko do ilości zamówionych na tym ZK. Widzę tu dwie opcje: a) możliwość wydawania na WZ tylko i wyłącznie do "ilości" zdefiniowanych na ZK (co wymusiłoby na operatorze najpierw poprawę ZK w przypadku chęci wydania więcej niż zamówiono) b) brak ograniczenia jak w pkt. a) ale poprawienie mechanizmu aby pokazywał w ZK, w kolumnie "Zrealizowane" faktycznie wydane ilości czyli w naszym przypadku byłoby to 200szt. Osobiście preferowałbym opcję a) ponieważ wymuszałaby ona bardziej świadome działanie przez operatora. Jeśli z jakiś powodów nie jest to łatwe do zrobienia to proszę wykonajcie na razie chociaż wariant b) który wydaje się łatwiejszy bo to "tylko" poprawa obecnie zaimplementowanego mechanizmu. PYTANIE Czy i kiedy możecie Panowie coś z tym zrobić? P.S. oczywiście gdyby się uprzeć to obecnie zaimplementowany mechanizm ma jakąś tam logikę, którą teoretycznie można próbować bronić, w końcu zamówiono 100szt, i wydano 100szt. z tych 100szt zamówionych. Z tym, że w bieżącej działalności przyjęta logika przeszkadza i ta informacją jest bez użyteczna z punktu widzenia analizy informacji z poziomu ZK.

Wartość w polu "Wartość Zrealizowana" znajdująca się na ZK jest błędnie wyliczana, podawana w ZK kwota wydań to 1319,92 powinno być 1320,00zł. Problem występuje na niektórych zamówieniach - nie odkryłem jeszcze zależności. Jedyny powiązany dokument w tym konkretnym ZK to WZ75/2016, mówiąc inaczej brak jakichkolwiek faktur zaliczkowych czy też faktur realizujących tą WZ-kę, brak podpiętych przedpłat. PYTANIE: Kiedy Panowie to poprawicie? ZAMÓWIENIE WZ 75

TEMAT 1 W każdym ZK, pod przypiętymi przedpłatami jest pole "Pozostało" pokazujące ile pozostało do zapłaty (czyli całkowita wartość zamówienia minus podpięte przedpłaty). No i wszystko pięknie! ale prosilibyśmy abyście dodali możliwość wywołania tego pola na gridzie wszystkich ZK, dzięki czemu moglibyśmy formatowaniem warunkowym (w wyniku porównania z całkowitą wartością zamówienia) podświetlić wszystkie zamówienia w zależności od tego w jakim stopniu są spłacone (np.zielone 100% spłaty, pomarańczowe częściowo, czarne brak spłaty). Działamy z naszymi klientami w zasadzie niemal zawsze na przedpłatach wiec w ten łatwy sposób ogarnęlibyśmy kawałek bardzo istotnego procesu bo informowanie o dokonanej spłacie per dane ZK już na liście. Takie klarowne pokazanie informacji mocno ułatwiłoby nam bieżącą pracę. TEMAT 2 W samym ZK oraz na liście wszystkich ZK (na gridzie) brakuje kolumny sumującej wartości brutto podpiętych przedpłat do danego ZK. To pole (w ZK i na gridzie) przydałoby się mocno ponieważ zwykle do każdego ZK mamy kilka przedpłat i nie musielibyśmy używać kalkulatora aby wyliczyć ile już przedpłacono (w przypadku dłuższej realizacji zamówienia oraz kilku przedpłat ze strony danego klienta to częste pytanie "ile tam wam przedpłaciłem już") TEMAT 3 Przydałaby się również możliwość wywołania na gridzie kolumny pokazującej pozostałą "wartość do realizacji". W tej chwili na gridzie można już taką kolumnę wywołać ale liczona ona jest w ten sposób, że jest to różnica między Wartością zamówienia a dokonanymi wydaniami. Przydałaby się jeszcze jedna wersja (dodatkowa kolumna) pokazująca różnice między Wartością przedpłat/płatności z ZK a dokonanymi wydaniami. Mówiąc krótko w naszym modelu działania wydajemy towary do kwoty przedpłat wiec mielibyśmy w tej kolumnie informację wprost ile jeszcze możemy danemu klientowi wydać. PYTANIE Czy możemy prosić Panowie o implementację powyższego? W jakim terminie?

Wystawiam zamówienie na: TW1 = 100szt. (towar) TW2 = 100szt. (towar) U1 = 1szt. (usługa, akurat w moim przypadku o nazwie zaliczka) Z zamówienia wystawiam fakturę zaliczkową z jej specyfikacji usuwam TW1 oraz TW2, fakturuję zatem tylko U1. Wystawiam w kolejnym kroku WZ-kę do w/w zamówienia, program pyta mnie czy WZ-kę chcę podłączyć do istniejącej faktury zaliczkowej czy może pozycji, które są na zamówieniu ale nie zostały zafakturowane zaliczka (do tego miejsca wszystko jest zrozumiałe i ok). No i teraz wystawienie WZ-ki do faktury zaliczkowej z usługa powoduje wystąpienie błędu (z tym charakterystycznym okienkiem poprzez który mogę owy błąd zgłosić do Insert załączając Printscreen). Oczywiście rozumiem, że nie da się wydać usługi ale program w tym miejscu powinien wyświetlić odpowiedni komunikat a nie sypać błędami. Druga sprawa, zdecydowanie ważniejsza... Gdy ową WZ-ką spróbuję wydać towary które są na zamówieniu to wówczas oczywiście mogę to zrobić (i fajnie) ale tylko raz. Tzn. po wystawianiu WZ-ki np. na TW1=5szt oraz TW2=5szt już kolejnej WZ nie mogę wystawić program błędnie informuje, że: "Podana pozycja nie należy do dokumentu zaliczkowego" 2 inne, kolejne błędy (związane z błędnym informowaniem na ZK co do ilości wydanej poprzez podłączone WZ) zgłosiłem już Panu Mateuszowi Włudyce na priv + udostępniłem bazę. Czy możecie to zbiorczo poprawić jakimś HF-em? Czekanie do wiosny na wersję 15 to marna opcja mając na uwadze te 4 błędy. Zauważone błędy powodują, że "strach" jest używać wydań do zamówień zafakturowanych fakturą zaliczkową bo nie wiadomo ile w końcu wydano towaru.

No jest to jakieś rozwiązanie ale z tego co kojarzę instynkt np. na zamówieniach nadal będzie podpowiadał towary z obu magazynów. Tu naprawdę logiczniejszym byłoby ich systemowe (zrobione przez Insert) ukrycie per dany magazyn w przypadku korzystania z wieloddziałaowosci.

Witam, W module Asortyment [As] mamy miedzy innymi wyszukiwanie [F8] "według instynktu: Asortyment". Wyszukiwanie to nie działa jednak w polu Uwagi (wiem - jest oddzielny instynkt do uwag). Czy wyszukiwanie według instynktu: Asortyment moze również obejmować pole Uwagi? Tak działał w GT według instunktu towaru.

W ramach prowadzonej działalności posiadamy 2 oddziały. Odział O1 funkcjonuje w branży budowlanej i ma przypisany jedynie magazyn M1, oddział O2 funkcjonuje w branży metalowej i ma przypisany jedynie magazyn M2. Chciałbym aby pracownicy z oddziału O1 nie widzieli znajdującego się asortymentu na magazynie M2 i odwrotnie... czyli Ci z oddziału O2 asortymentów z magazynu M1 (bo dziś jest tak, ze kartoteka asortymentów dla wszystkich magazynów jest wspólna jedynie różne mogą być stany towarów per magazyn) Oczywiście cel jest jeden, uproszczenie listy asortymentów poprzez ich wizualne zmniejszenie i nie rozpraszanie na wzajem pracowników oddziałów O1 i O2 dziwnymi nazwami na liście asortymentu ponieważ oddziały te nie współpracują. Jakimś rozwiązaniem byłaby dezaktywacja towarów per dany magazyn/oddział (takim średnim chyba bo wówczas w instynkcie co prawda nie będą się pojawiały ale nadal będzie "bałagan" na w kartotece asortymentów) Zdecydowanie czytelniejszym jednak rozwiązaniem byłoby ich ukrycie per dany oddział. Czy jest szansa na takie rozwiązanie? (ewentualnie: czy to się da zrobić z dobrym serwisantem jakimś rozwiązaniem dodatkowym?) Z góry dziękuję za odpowiedź...

Nam taka funkcja również by się przydała ponieważ korzystamy z kompletacji sprzedając towary (tzn. komplety) ale zamawiamy zawsze (zwykle) składniki. Z tym, że u nas problem jest nieco grubszy bo nigdy nie mamy tak łatwo, że z 1ZK powstaje 1ZD. Konsolidujemy zamówienia więc z wielu ZK powstaje 1ZD. Pisałem o takim mechanizmie tutaj, sądzi Pan, Panie Mateuszu że dacie radę go oprogramować bo nie dostałem odpowiedzi ? https://forum.insert.com.pl/index.php?/topic/812-dodawanie-z-wielu-zk-towarow-do-istniejącego-zd-nowa-funkcjonalnosc/ Czyli przy przekształcaniu takiego ZK musiałoby być okienko gdzie decydowalibyśmy do którego przekształcamy dane zamówienie, dodatkowo powinniśmy móc zdecydować czy zamawiamy w tym konkretnym przypadku komplet czy towar a na samym końcu móc zmienić ilość zamawianych towarów/kompletów (w wyniku przetwarzania powstają straty)

Multum informacji oraz wniosków wynika zasadniczo z: - dogłębnej analizy zaimplementowanego łańcucha - braku jasnej wizji z Państwa strony co do usprawnienia mechanizmy zaliczkowego (wnoszę po tym co Pan napisał) Oczywiście możecie te usprawnienia też robić mały kroczkami, z wersji na wersję... po kawałeczku bez spojrzenia górnolotnie na zaliczki jako na cały proces... tylko dokładając raz pole takie raz inne, tyle że w tym tempie i bez jasnej wizji to zaliczki będą działać jak należy ale w 2021 roku. No i tu różnica między nami jest taka, że dla Państwa ten okres to "naturalny rozwój produktu" a dla mnie to tysiące sytuacji, w których moi ludzie będą się motać i wobec klientów będziemy wychodzić na nieprofesjonalnych. Ta sama sytuacja a jakże rozbieżne odczucia i konsekwencje. No i na koniec, żeby nie było, że tylko marudzę, w NEXO są 1374 rzeczy które wymagają pochwały i widać, że włożyliście w to najlepszą cząstkę siebie

Tak możemy się umówić. Zaproponowane przez Pana rozwiązanie powinno być wystarczające (a jak nie będzie wówczas poproszę o uprawnienie dot. zakazu kasowania). Z tym, że dobrze aby ten komunikat wyskakiwał dla wszystkich wiadomości w folderach (odbiorcza, nadawcza, wysłane, szkice, kosz) ale również dla nowo tworzonej wiadomości.

W niniejszy poście odniosę się wprost do Pana poprzedniej wypowiedzi. Panie Mateuszu, cieszę się, że zgodziliśmy się razem, że uzyskanie szybkiej oraz jednoznacznej informacji w powyższych kontekstach (tzn. ile zamówiono, ile już wydano, ile pozostało - w sensie ilościowym jak również wartościowym - w jednym miejscu, w ramach 1 grida) jest kluczowe oraz absolutnie fundamentalne jeśli mamy sprawnie obsługiwać zamówienia zaliczkowe klientów. Sprawdziłem dokładnie i mam świetną wiadomość, przy zachowaniu pewnych rygorów, obecnie zaimplementowany mechanizm zaliczkowy umożliwia zapanowanie nad zamówieniami zaliczkowanymi i uzyskanie pożądanych informacji w jednym miejscu, tzn. z poziomu zamówienia klienta. Wszystko co potrzebne można znaleźć w specyfikacji zamówienia. Aby powyższe jednak było możliwe musi zaistnieć szereg zasad postepowania z zamówieniem w czasie jego realizacji: 1) W przypadku gdy klient domawia nowy asortyment (całkiem nową pozycję) do już istniejącego zamówienia popartego wcześniej wystawioną fakturą zaliczkową FL, należy bezwzględnie tą nową pozycję dodać bezpośrednio do zamówienia (nowo utworzonego a najlepiej tego pierwotnego) i realizować tą pozycję tylko i wyłącznie kolejnym, nowym łańcuchem. Zwracam na to taką szczególną uwagę ponieważ NEXO w tej chwili umożliwia wiele sposobów na inne postępowanie (dodawanie nowej pozycji do WZ, FL, KFL) i postępując bez tej świadomości wpędzamy się w kłopoty informacyjne! Czyli w szczególności nie powinniśmy: 2) Nie powinniśmy dodawać tej nowej pozycji na kolejnej podłączanej WZ w ramach pierwotnego łańcucha - bo wówczas ta nowa pozycja niejako wycieknie poza pierwotne ZK i nie będzie w nim nawet widoczna. Tu zgodziliście się wprowadzić zmiany (stosowną blokadę) więc chwała Wam za to! 3) Nie powinniśmy dodawać tej nowej pozycji na kolejną FL w ramach pierwotnego łańcucha - bo wówczas ta nowa pozycja niejako wycieknie poza pierwotne ZK i nie będzie w nim nawet widoczna. Proszę o dodanie zatem stosownej blokady jako opcja. 4) Nie powinniśmy dodawać tej nowej pozycji poprzez KFL w ramach pierwotnego łańcucha - bo wówczas ta nowa pozycja niejako wycieknie poza pierwotne ZK i nie będzie w nim nawet widoczna. Proszę o dodanie zatem stosownej blokady jako opcja. Dodatkowo, trochę mniej ważne ale też istotne jeśli faktycznie chcecie dążyć, cytując Pana wypowiedz do "ograniczenia błędów pracowników": 5) Nie powinno być możliwości zapisania FL wystawionej na 0zł. 6) Powinna być możliwość wystawienia KFL do FL bezpośrednio z poziomu menu kontekstowego zamówienia. Oczywiście ta korekta nadal będzie tyczyć się ostatniego dokumentu w łańcuchu. W tym miejscu mi jedynie chodzi o pewną spójność działania Nexo a nie zmianę sposobu działania łańcucha!... bo daliście Państwo możliwość wystawiania kolejnych faktur zaliczkowych (FL) z poziomu zamówienia więc bądźcie spójni i dajcie też możliwość wystawiania korekt z zamówienia (ergonomia i spójność). 7) Skorygowanie całkowite (w sensie ilościowym) danej pozycji z faktury zaliczkowej FL poprzez korektę KFL powoduje, że... wystawiając kolejną fakturę zaliczkową lub też fakturę końcową ta pozycja (co prawda z ilością 0) pojawia się nadal na specyfikacji - moim zdaniem zachęcając wręcz do popełnienia błędu przez pracownika w ferworze wykonywanych czynności. Skoro tą pozycję skorygowaliśmy całkowicie pozycja ta powinna definitywie wylecieć z łańcucha i nie być podpowiadana na kolejnych FL zaliczkowych, FL końcowej czy też kolejnej KFL. 8) W przypadku gdy do zamówienia zaliczkowego (np. składającego się z 3 pozycji) wystawiono FL ale tylko do 2 pozycji przyporządkowano zaliczki na tej FL to w zamówieniu klienta nie powinniśmy móc usunąć (del) tych zaliczkowanych pozycji lub wydanych. Powinna być zatem jedynie możliwość usunięcia tylko i wyłącznie pozycji, co do której nie ma zaliczki na kolejnych FL oraz tych, które nie zostały wydane. W tej chwili beztrosko z zamówienia można usunąć wszystkie pozycje! (zero jakiejkolwiek blokady), mimo iż to właśnie z ZK wystawiono Faktury zaliczkowe a nawet wydano towary, usuwając daną pozycję z ZK tracimy obraz ile wydano/ile zamówiono/ile pozostało do wydania dla tej konkretnej pozycji - a to jest ważne. 9) W celu dalszego zapanowania nad zaliczkami, chciałbym zaproponować oto taką przebudowę... w tej chwili Nexo daje znów nam moim zdaniem niekorzystną elastyczność polegającą na tym, że jak klient zmieni zamówienie to zasadniczo możemy zrobić to na ZK, ale równocześnie możemy tego nie dokonać na kolejnej FL lub za pomocą KFL (bo np. coś nas w tym momencie oderwało od biurka i zapomnieliśmy wrócić do tego tematu). Może być też odwrotnie, pracownik poprawi ostatni dokument w łańcuchu a nie poprawimy ZK. Ta elastyczność w połączeniu z rozwleczonymi w czasie łańcuchami nie będzie dawać pewności czy aby na pewno poprawiono i ZK i dokument końcowy łańcucha (jednocześnie!). To jest bardzo duże pole do motania sią i błedów bo po miesiącu nie będzie wiadomo, który dokument jest "aktualny". Uważam, że to ZK powinno być "Centrum Świata" i to od niego powinny zaczynać się wszystkie ewentualne zmiany - bez poprawy ZK nie powinna być możliwa poprawa ostatniego dokumentu w łańcuchu (FL lub KFL) oraz dodatkowo ewentualne wydania cząstkowe powinny być możliwe do ilości wpisanych do ZK. W ten sposób wymusimy aby ewentualne zmiany zamówienia wprowadzać począwszy od edycji ZK. Oczywiście to nie załatwia tak całkowicie sprawy, bo znów można poprawić ZK ale równocześnie zapomnieć o dokumencie końcowym, jednak da ona nam jako użytkownikom pewność, że to ZK jest zawsze "ostateczną" postacią zamówienia. Ponadto, przewiduje również celowe sytuacje oto takie, że po dokonaniu zmian zamówienia przez klienta, poprawimy ZK (ale jeśli to nie będzie w danej chwili konieczne bo klient nie wpłacił dodatkowej zaliczki a np. tylko poinformował o zmianie) to nie wystawimy na tą okazję od razu KFL by nie generować dodatkowych, kolejnych dokumentów (bo w naszej branży ten klient jeszcze może zmienić 3 razy zdanie zanim dojdzie do jakiekolwiek realizacji) więc z generowaniem dokumentów będziemy czekać do ostatniej chwili. Oczywiście jeśli Panowie przećwiczycie to tylko na jednostkowych przykładach to powyższe może wydać się przerostem. Spróbujcie Panowie jednak zasymulować 100 zamówień jednocześnie, każde 100 pozycyjne w których na przestrzeni pół roku (u nas tyle może trwać łańcuch i dłużej) dokonano 10 zmian po drodze dla każdego przypadku, zmieniając z każdą iteracją np. 6 towarów. Wtedy zobaczycie Panowie, że wymuszenie 1 miejsca od którego wszystko się zaczyna jest absolutną koniecznością. Przykładowo: W tej chwili w Nexo na zamówieniu mogę mieć zamówioną np. 1szt. jakiegoś towaru na FL mogę to zwiększyć bezkarnie do np. 1000szt. a wydać w ramach 1 WZ mogę cały stan tego towaru, czyli np. 1 000 000 000! Implementując rozwiązanie które opisałem w pkt. 9, aby przykładowo: wydać 1mln szt. danego towaru to na zamówieniu też by musiałoby być 1mln szt. tego towaru, aby zaliczkować 1000 szt. danego towaru to na zamówieniu też musiałoby być 1000szt. tego towaru. 10) Do ZK należałoby dodać nową kolumnę, która by informowała ile danego towaru mamy zamówione na ostatnim dokumencie w łańcuchu (FL, KFL) oraz na jaką ilość przyjęto zaliczkę. Czyli zasadniczo mielibyśmy 3 kolumny: Ilosć zamówiona na ZK: np. 1000szt. Ilośc zamówiona na FL/KFL np. 950szt. oraz ilość tego towaru zaliczkowana na wszystkich FL np. 900szt. Można też uprościć i z 2 kolumn zrobić tylko jedną, pokazującą od razu dwie liczby, tzn. 950(800). Przy takim zestawie informacji (bezpośrednio z poziomu specyfikacji konkretnego ZK) użytkownik już z poziomu zamówienia wiedziałby, że w jakiś sposób musi być czujny i realizując np. ten łańcuch fakturą końcowa aby zwiększyć ilość do 1000szt . Wiedziałby też, że jeśli klient nagle pyta o zmniejszenie zamówienia do np. 800szt. to z tego tytułu musi powstać korekta (bo ma już zaliczkę na 900 szt). Mówiąc krótko, implementacja pkt 10. spowodowałaby większe panowanie przez użytkownika na tym co ma na zamówieniu vs kolejnych FL/KFL. W tej chwili jest to rozstrzelone i porównać 5 pozycji na 2 dokumentach to nie problem. Porównajcie Panowie w ramach "rozgrzewki" jednak 100 pozycji ZK vs FL/KFL. Zmierzam do tego, że porównywanie w ramach 1 widoku/listy jest łatwiejsze. Tu w ogóle byłoby super gdyby formatowanie warunkowe działo nie tylko na listach np. zamówień ale i w konkretnych zamówieniach, wtedy po ustawieniu formatowania kolorystycznie byłoby łatwo wyłapać pozycje na których mamy różnice miedzy ZK i FL/KFL). Jak widać powyżej jest sporo "dziur" gdzie można się w tym mechanizmie nieźle zagubić! Zasadniczo nie powinno być też tak, że każdy pracownik firmy będzie postępował inaczej przy realizacji zamówień zaliczkowych bo to będzie jeden wielki chaos informacyjny. Stosowanie rygoru i postępowania zawsze według w/w zasad powinno zapewnić pożądane informacje i względnie dobrą czytelność tego mechanizmu dla wszystkich pracowników! Ja też Was rozumiem, że projektując tak rozbudowane systemy jak Nexo, jako wytrawni programiści i analitycy łatwo stracić Wam wrażliwość co jest łatwe a co może być trudne dla "Kowalskiego". Zapewniam jednak, że w typowych firmach nie ma znów tak tęgich głów i program zasadniczo powinien umożliwiać poprzez zastosowanie opcjonalnych blokad wybranie 1 zunifikowanego sposobu postępowania który będzie dla wszystkich czytelny i możliwie prosty. Ja do tego dążę i to jest mój cel jeśli chodzi o ten mechanizm. Zmierzam z tym wywodem, że nawet jeśli uważacie, że ta "elastyczność" robienia wszystkiego w mechanizmie zaliczkowym na wiele sposobów to właśnie zaleta Nexo to proszę dodajcie w konfiguracji tylko blokady jako opcjonalne do włączenia, które pozwolą zapanować na punktami opisanymi w 1-9. My je wykorzystamy a ja jako zarządzający będę spokojniejszy, że moi ludzie nie motają się każdego dnia bo każdy obsługuje zaliczki na swój własny sposób! Oczywiście poprawa/dodanie blokad w zakresie pkt. 1-9, skokowo poprawi czytelność i ergonomię a ponadto w mojej opinii to jedyny sensowny, odkryty przeze mnie sposób pracy z zaliczkami (przy tych ilościach, które my mielimy). Niestety zrealizowanie nawet wszystkich punktów o których wspomniałem wyżej jedynie (i aż!) powoduje doszlifowania obecnego łancucha w kontekście jego ergonomii i szczelności, nie powoduje to rozwiązania problemów, o których pisałem w poprzednim poście wiec tym samym jest on nadal aktualny. Tutaj też mam prośbę, poświęciłem "chwilę" aby zebrać to wszystko w całość. Proszę zatem Panie Mateuszu, aby skonsultował to Pan z kimś decyzyjnym i odpowiedzialnym za ten łańcuch w waszej firmie a najlepiej abyście Państwo na spokojnie razem z tym materiał się zapoznali. Wierze, że moje uwagi są rozsądne i znajdą poparcie ułatwiając w konsekwencji pracę użytkownikom... Cieszę, się, że zgodziliście się Panowie z moimi uwagami dotyczącymi podłączania WZ do zamówień zaliczkowych,tj: - aby specyfikację wydawanych towarów ograniczyć tylko do towarów z Zamówienia/Faktury zaliczkowej (o tej sprawie pisałem również w punkcie 1 niniejszego posta). - oraz zniesieniu blokady wydań (aby była możliwa wydań ponad przyjętą zaliczkę) Proszę jednak abyście zostawili opcjonalną blokadę gdzieś w konfiguracji polegającą na wystawianiu zaliczek do kwoty przyjętych zaliczek (w firmach mogą być różne filozofie pracy w tym zakresie - sami nie wiemy co wybierzemy bo jesteśmy przed wdrożeniem). Zwracam od razu uwagę, że i tak wymagana jest tutaj poprawka bo obecny mechanizm jest niby do kwoty zaliczki ale jest dziurawy bo pierwsza WZ można wydać nawet wszystkie towary. Jeśli to NIE jest możliwe (ta opcja wyboru w konfiguracji) to dobrze byłoby aby była jakaś dynamiczna informacja podczas wystawiania WZ, informująca czy w ramach danego wydania następuje ewentualne skonsumowanie całej zaliczki (np. dodanie w WZ, pod gridem z specyfikacją, nowego pola z wartością poprzednich wydań w ramach danego łańcucha i w przypadku przekroczenia wartości wynikającej z nieskonsumowanych zaliczek, kolorowania wartości w tym polu co dla usera znaczyłoby: "uważaj, za chwile wygenerujesz WZ-kę do zafakturowania bo nie wystarczy Ci kasy na bieżące wydanie aby je w 100% pokryć wcześniej przyjętą zaliczką"...

Panie Mateuszu, Myślę, że powinniśmy w tym miejscu na chwilę się zatrzymać i koniecznie spojrzeć na temat fakturowania zaliczek raz jeszcze tylko z nieco innej perspektywy. Powyższe podejście pozwoli nam usystematyzować wiedzę co do obecnego działanie mechanizmu zaliczkowego oraz wyznaczy ewentualne dalsze kroki jego rozbudowy. Myślę, że zgodzimy się razem, że powinniśmy spojrzeć na mechanizm zaliczkowy jako na cały proces, który z definicji powinien odzwierciedlać rzeczywistość zachodzącą w przedsiębiorstwach oraz uwzględniać charakterystykę tychże biznesów. Mając na uwadze powyższe, powinniśmy rozpocząć nasze rozważania od zauważenia fundamentalnego podziału charakterystyki biznesów waszych klientów w kontekście specyfiki realizacji zamówień zaliczkowych. To właśnie ten podział powinien zasadniczo determinować sposób działania mechanizmu zaliczkowego w programie. Zasadniczy podział charakterystyki biznesów, w zakresie specyfiki realizacji zamówień zaliczkowych: I. Biznesy w których zwykło się nie robić dużych zmian w zakresie już złożonego zamówienia (np. zamówienie samochodu z importu lub też komody pod wymiar) II. Biznesy w których praktycznie każde zaliczkowane zamówienie podlega wielu zmianom i jest to sytuacja całkowicie naturalna dla danego typu biznesu a realizacja łańcucha może ciągnąć się miesiącami i dotyczy wielu drobnych pozycji (np. branża budowlana) Obecnie zaimplementowany mechanizm doskonale obsłuży pierwszą (I) charakterystykę biznesu, zapewniając przy tym dodatkowo takie zalety jak: - pokazanie przebiegu zmienności zamówienia poprzez kolejne dokumenty w łańcuchu, - możliwość przyjęcia zaliczki do pozycji (co jak Pan wspominał, dla niektórych Państwa klientów było kluczowe - słowa uznania, że się wsłuchujecie w rynek). Obecny mechanizm obsłuży również (II) drugą z charakterystyk ale w sposób ułomny i z wieloma negatywnymi konsekwencjami. Tak jak już wykazałem w ramach niniejszego wątku (poprzednie posty), zaliczka do pozycji przy wielu zmianach asortymentowych będzie rodziła wiele korekt KFL w danym łańcuchu oraz generowanie dodatkowych faktur zaliczkowych różnicowych końcowych wynikających z faktu, iż wpłacona zaliczka jest przypisana do pozycji a nie do całego dokumentu. Ponadto, fakt pobierania specyfikacji zamówienia z poprzedniej faktury zaliczkowej wymusza niejako korygowanie specyfikacji w przypadku zmian zamówienia na aż 2 dokumentach co również może (i będzie) rodzić pomyłki. Istnieje też zasadniczy podział klientów w kontekście ich oczekiwań co do działania mechanizmy zaliczkowego - oczekujący przypisania zaliczki do pozycji - NIE oczekujący zaliczki do pozycji (ponieważ w ich modelu działania zaliczka jest do całego zamówienia klienta) Co zatem proponuję? W mojej opinii nie pogodzicie Państwo w ramach 1 mechanizmu tych dwóch jakże różnych charakterystyk biznesów oraz oczekiwań klientów. Proszę zatem rozważyć zaimplementowanie (dodatkowego) nowego typu zamówienia, na wzór tego z GT: - przyporządkowującego zaliczkę do całego dokumentu a nie do pozycji (dzięki czemu usuniecie danej pozycji, nawet zaliczkowanej i wymiana na inną nie będzie rodzić wielu niepotrzebnych KFL oraz dodatkowo wydania zewnętrzne do kwoty zaliczki nie będą rodzić wielu dodatkowych faktur zaliczkowych różnicowych końcowych) - pobierającego specyfikację towarową dla WZ oraz FL zawsze z ZK (dzięki temu tylko w 1 dokumencie będzie trzeba odzwierciedlać zmiany w zamówieniu) Mając zaimplementowane w NEXO te 2 typy zamówień pogodzicie Państwo wszystkich klientów w zakresie realizacji zamówień zaliczkowych. Oczywiście widziałbym to tak, że dany Państwa klient w zależności od charakterystyki swojego biznesu wybierze dla siebie tylko jeden typ zamówienia i w sposób konsekwentny i spójny będzie go stosował. Proszę zauważyć, że coś podobnego jest również w GT, zaimplementowaliście Państwo 2 typy zamówień, Zamówienie zwykłe oraz Zamówienie zaliczkowe (nowego typu) i można było na jedno z nich się zdecydować a drugie z nich np. wyłączyć uprawnieniem. W mojej opinii "problem" jest istotny i dość znany dla osób związanych z NEXO. Z racji, że na przełomie 16/17 planujemy się z migrować z GT a sam wybór systemu to jakże istotna decyzja dla firmy na kolejne długie lata, to też chcąc minimalizować niespodzianki, postanowiliśmy zapytać o opinię dotyczącą NEXO. Skontaktowaliśmy się w tym celu z około 10 firmami zajmującymi się wdrożeniami oraz z około 10 przypadkowo znalezionymi w Internecie użytkownikami NEXO. W zdecydowanej większości, zwrócono nam lojalnie uwagę właśnie na ten mechanizm realizacji zaliczek, wskazując go jako ewentualne słabe ogniwo NEXO (w zależności od charakterystyki biznesu w zakresie realizacji zamówień zaliczkowych). Osobiście uważam, że obecnie funkcjonujący mechanizm jest doskonały i bardzo szczelny dla firm, które mają pierwszą (I) charakterystykę realizacji zamówień zaliczkowych (patrz podział). Niestety dla II charakterystyki biznesów, czyli również dla naszej branży (budowlana) obecny sposób działania tego mechanizmu rodzi wiele dodatkowych (niepotrzebnych/kłopotliwych) dokumentów. Niby nic a jednak wielka różnica! Żeby nie być goło słownym, sprawdziłem rzeczywiste przypadki realizacji zamówień zaliczkowych naszych klientów, które mamy w GT. Gdy je odzwierciedliłem w NEXO to zauważyłem, że powstaje od kilku do nawet kilkunastu dokumentów więcej niż przy mechanizmie z GT (tylko w obrębie 1 zamówienia klienta, które składa się zwykle z wielu małych pozycji, zaliczkowane jest kilka razy jak również wydawane na wiele rat). Pragnę w tym miejscu zaznaczyć, że dla zamówień zaliczkowych jesteśmy dość dobrym testerem ponieważ mamy ich średnio miesięcznie kilkaset (100-200). Łatwo zatem policzyć, że przy obecnie działającym mechanizmie w Nexo ilość dokumentów "około zaliczkowych" (czyli korekty, faktury różnicowe zaliczkowe końcowe) zwiększy nam ilość dokumentów przekazywanych do księgowości kilka razy! Czyli kilkaset dodatkowych dokumentów każdego miesiąca. Warto też zauważyć, że każda z korekt musi być też podpisana więc to za chwile będzie prawie dodatkowy etat by nad tym zapanować (wysyłka oraz zapanowanie nad podpisanymi zwrotkami). Panie Mateuszu, jak Pan widzi w ramach niniejszego wątku zaangażowałem się w temat zaliczek bardzo szczegółowo poświęcając analizie tego mechanizmu wiele czasu. Pragnę zaznaczyć, że mam tylko dobre intencje w stosunku do Nexo, kibicuję mu od dnia premiery. Uważam ponadto, że Nexo jest szansą dla polskich małych firm, no i jeśli tylko poziom szybkości rozwoju tego oprogramowania zostanie zachowany, to z całą pewnością Nexo odciśnie pozytywne piętno na wzrostach tych firm a więc w konsekwencji na gospodarce. Zmierzam z tym wywodem do relatywnie prostej konkluzji - robicie Państwo rzeczy naprawdę ważne dla nas, przedsiębiorców. Mając na uwadze całokształt sytuacji - mam serdeczną prośbę - proszę może ten post pokazać osobie, która jest decyzyjna w zakresie kształtu oprogramowania jeśli chodzi o zaliczki w Nexo. Być może wspólnie podzielą Państwo moje obserwacje i rozważą implementację dodatkowego mechanizmu, dzięki któremu obsłużycie dwa typy charakterystyk biznesów, uszczęśliwiając tym samym wszystkich klientów a nie tylko 1 grupę. Pozdrawiam serdecznie no i miłego weekendu

Dziękuję za wskazówkę Radomił, faktycznie istnieje w NEXO możliwość zbiorczego przekształcenia ZK do ZD. Przetestowałem i opisywany przez Ciebie mechanizm nie do końca niestety spełnia nasze oczekiwania (minimalnie o coś innego mi chodzi). Rozdzieliłem wątek celowo i stworzyłem nowy ponieważ niniejsza sugestia nie do końca jest tożsama "z ręcznym wiązaniem dokumentów", tzn. z tym wątkiem: https://forum.insert.com.pl/index.php?/topic/685-ręczne-powiązanie-dokumentów/ Przechodząc do meritum, obecnie wskazany przez Ciebie mechanizm pozwala przekształcać zbiorczo wiele ZK tworząc zawsze nowe ZD. My mamy potrzebę (tak jak zresztą pisałem wyżej) przetwarzania kolejnych ZK do już istniejącego ZD. Chciałbym to robić nie tylko zbiorczo jednorazowo ale również na pojedynczych zamówieniach, czyli w miarę składania kolejnych zamówień przez klientów wypełniamy ZD zamówionymi towarami. Mechanizm, który wskazałeś niestety nie poradzi sobie z tak wydawałoby się prostą sytuacją: Mamy kilka zamówień ZK w systemie, tworzymy zatem z nich ZD które odbierzemy własnym transportem np. za 3 dni. Po utworzeniu ZD, przychodzi jeszcze 3 klientów i składa ZK, chcemy je dorzucić do istniejącego ZD (bo jesteśmy małą zwinną firmą i nam zależy na kliencie) - jak to zrobić? Oczywiście powyższy przykład jednostkowy to nie wszystko. Tak jak mówiłem konsolidujemy zamówienia od różnych dostawców, praktycznie zawsze używając aut 24 tonowych bo tylko wtedy biznes się kalkuluje. To wszystko sprowadza się do tego, że po stronie ZD chciałbym widzieć na bieżąco ile i jakie pozycje mamy zamówione, oraz o jakiej wadze. Bo w oparciu o: - wagę, - obiecane terminy realizacji klientom, - dostępność samochodu, - dostępność towarów, podejmowana jest decyzja o wysłaniu zamówienia do dostawcy. To, że w tej chwili NEXO tego nie obsługuje powoduje, że: - narażeni jesteśmy na liczne błędy bo czasem nazwy produktów są podobne i łatwo się pomylić co do ilości wklepywanej ręcznie na ZD (protezą byłaby możliwość kopiowania listy ctrl+k oraz ctr+L która jest w GT ale tego niestety nie ma... LUB ogólnie jakiś fajny schowek ogólno-nexowy gdzie byśmy zrzucali zaznaczone pozycje z listy zamówienia a następnie z tego schowaka wrzucać do istniejącego ZD - też rozwiązanie ręczne ale poniekąd załatwiłoby problem) - oczywiście przy ręcznym dopisywaniu pozycji do ZD nie mamy również powiązań miedzy ZD a ZK Panie Mateuszu, jesteście w stanie zaimplementować (tak naprawdę troszkę rozbudować obecny mechanizm) dodawania do istniejącego ZD pozycji z danego ZK ? Oczywiście wówczas chętnie podeślę specyfikację jakby to widział. Pomożecie? P.S. Jakimś rozwiązaniem byłaby analiza z poziomu widoku "Asortyment zamówiny przez klienta" w wersji PRO, z tym, że na liście nie można pokazać wagi per dana pozycja i łącznie do zamówienia oraz dodatkowo nie ma możliwości grupowania towarów per dany (domyślny) dostawca. Przy okazji - czy możecie powyższe potrzeby dołożyć czy to w formie nowego widoku czy to w formie filtra który by pokazywał asrtyment tylko do danego dostawcy? Pytanie: Czy w wersji PRO taki widok możemy sami dołożyć (podział zamówionych towarów ze względów na dostawców)?

Nexo obsluguje scenariusz przetwarzania ZK do ZD w ten sposob, ze kazdorazowo tworzony jest nowe ZD. W praktyce biznesowej nie zawsze jest tak prosto, ze 1 ZK = 1 ZD. Konsolidujemy zamowienia do dostawcow i z wielu ZK zwykle tworzymy 1 ZD (w tej chwili recznie to robimy tzn. uzupelniamy ZD co prowadzi do bledow). Reasumujac obecny mechanizm jest jak najbardziej wporzadku ale musiaby byc wzbogacony (np. poprzez zaznaczenie jakiegos chceboxa w oknie gdzie dokonuje sie przetwarzania) o mozliwość dodania aktualnie przetwarzanego ZK do istniejacego juz ZD (np. wybor z listy konkretnego ZD) Oczywiscie moglbym podac pelna specyfikacje jak to mialoby wygladac... Pomozecie?

Rozumiem... pewnie jest też tak, że tego typu strategiczne decyzje podejmowane są przez wasz Zarząd więc domyślam się, że nie jest to decyzja na 15 min W każdym razie, jeśli czasem z ciekawości zagląda tu wasz Prezes lub ktoś mocno decyzyjny, to mała dygresja: Wiem, że jestem "marną próbka" bo reprezentuje tylko 1 firmę ale... Na rynku można spotkać się z opinią, że producenci rozwiązań pudełkowych trochę celowo unikają takich modułów typu fabryka obiektow aby móc rozróżnić Pudełko od np. własnego ERP-a. Przyznaje - jest to jakiś sposób aby zachęcić potencjalnych klientów właśnie do migracji na ERP-a Tyle, że dokładając takie "elastyczne moduły" do Nexo jesteście w stanie jeszcze bardziej pozamiatać konkurencję w segmencie pudełkowym (gdzie już jesteście przecież Liderem szczególnie gdy weźmiemy pod uwagę kategorię: cena/funkcjonalność) i dzieki temu zwiekszyc dominacje na rynku a nie tylko utrzymac pozycje. Dokładając takie moduły jak "fabryka obiektow" w ERP paradoksalnie już to takiego ŁAŁ to nie robi, bo tam dopiero musicie udowodnić swoją wartość co trwa długimi latami... Ponadto porównywani pewnie wówczas jesteście z całą plejadą dostępnych na rynku rozwiązań (przynajmniej gdy rozwazalismy Erp dla naszej firmy to takie porownanie robilismy), wiec to co może być ŁAŁ w NEXO i stanowić kolejną istotną przewagę Nexo w segmencie pudełkowym.. to w klasie rozwiązań ERP jest traktowane jako standard i pewnie nikt tam się wielce nad tym nie rozczula, przynajmniej ja bym się nie rozczulał płacąc kilka krotnie / kilkanascie razy więcej... W każdym razie pomyślnych decyzji Drugi temat: Kolejna rzecz gdzie można wykorzystać ręczne wiązanie elementów Nexo. U nas nigdy nie jest tak banalnie, że 1 ZK = 1 ZD (bo konsolidujemy zamówienia u naszych dostawców). Czyli z wielu ZK (a tak naprawdę z konkretnych pozycji, bo przecież dane ZK może być na towary od róznych dostawców) robimy w finale jedno ZD do danego dostawcy. Oczywiscie pisząc "robimy" mam na myśli ręczne uzupełnianie ZD. Możliwość ręcznego powiązania pozwoliłaby bardziej nad takimi ZD panować i stworzyć/pokazać powiązanie między ZK-ZD. Oczywiście to tylko znow proteza bo... przecież dane ZK nie musi byc w całosci powiazane do danego ZD a jedynie wybrane pozycje beda zwykle zwiazane z danym ZD (czyli wiązanie musiałoby być na poziomie pozycji, żeby to nie była proteza).

Korespondując z klientami istnieje naturalna potrzeba załączania linków, np. do strony/sklepu firmowego, gdzie w trakcie rozmowy odwołujemy się do produktów, porad, regulaminu, cennika, kontaktu... w sumie oczywista potrzeba poprzez którą ułatwiamy szybkie porozumienie się z klientem. W tej chwili działa to tak, że gdy wkleimy wprost link ze schowka to w mailu nie jest to widoczne jako hiperlink a jako zwykły tekst (czyli brak niebieskiej czcionki i podkreślenia). Po wysłaniu takowej wiadomości... co ciekawe, gdy odbieram to np. w Outlook to widzę to już jako link (podkreślenie, niebieska czcionka), klikam a tu zonk - 404 not found. Oczywiście mogę skorzystać z narzędzia do dodawania linków ale jeśli to ma być bardziej ergonomiczne (szybkie w działaniu) to po wklejeniu linka ze schowka lub stworzeniu go wprost w mailu na zasadzie wpisania adresu www, np. insert.com.pl to taki adres powinie stawać się automatycznie linkiem. Czyli już w tworzonej wiadomości, autor może go kliknąć i przenieść się do docelowej lokalizacji. Oczywiscie powyzsze powinno działać również w odniesneiu do @ Poprawicie to? Wówczas ten przycisk z ręcznym dodawaniem linków bym usunął.

Panie Marku, Jeszcze jedna uwaga - wspominał Pan na forum, że być może podziałacie w kontekście mobilności (coś Pan pisał o kalendarzu itd.) jeśli chodzi o nexo. Jeśli tam będzie też klient pocztowy to być może też będą tam potrzebne dedykowane uprawnienia. Używam dodatku do Oulooka pozwalającego udostępniać foldery w których są wiadomości (przekierowywane z drzewa głownego za pomocą reguł). Tutaj mogę per dany folder danego uzytkownika (a nie tylko globalnie) ustawić prawa. Oczywiście można też bardzo łatwo te same prawa skopiowac na pozoistałe foldery wiec ta matryca tylko skomplikowanie wygląda .... daje bardzo duże możliwości. Nam wystarczy brak możliwości usuwania wiadomości jako uprawnienie ustawiane per danego użytkownika. Ale skoro startujecie z PRO również do podmiotów średnich (do 249 etatów) i robicie rozwiązanie na kilkanaście lat to taka matryca pewnie dla nie jednego podmiotu byłaby wybawieniem....

Chciałbym zaproponować pewne ułatwienie wynikające z obserwacji co do pracy użytkowników z klientem poczty. Zwykle jest tak, że jak chcemy wysłać komuś załącznik to albo go kreujemy (np. jakąś umowę) lub też jeśli nawet taki dokument jest już sporządzony to i tak upewniamy się co do jego zawartości przed wysłaniem aby czasem jakieś bzdury nie wysłać. W kolejnym kroku odpalamy klienta poczty, piszemy wiadomość i załączamy ostatnio tworzony / ostatnio otwierany plik. Bardzo przydatne byłoby podpowiadanie ostatnio używanych plików (tych nowo stworzonych ale również tych ostatnio otworzonych) na liście gdzie dodaje się załącznik. Mogłoby być podpowiadane np. 10 ostatnio używanych plików, lokalizacji w komputerze może być wiele grze użytkownicy zapisują róznego rodzaju pliki więc to mocno usprawni proces dodawania załączników. Printscreen jakby to widział. .

Gdy montuje komplet, korzystając z komendy "Zmontuj" dostępnej w menu kontekstowym na ZK to... a/ gdy w danej chwili montuje tylko 1 pozycje z kompletami to status utworzonego ZPM mam "Przyjęty Towar" i zlecenie ZPM jest widoczne w widoku zlecenia zrealizowane (czyli w mojej opinii OK) b/ z kolei gdy montuje jednocześnie wiele pozycji z kompletami to status utworzonych ZPM mam "Do Realizacji" (?) Oczywiście zależy mi na maksymalnym uproszczeniu i zautomatyzowaniu procesu montowania ponieważ 80% naszych faktur zawiera komplety dlatego pytania: 1. Dlaczego program zachowuje się inaczej w przypadku a/ i b/ skoro to de fakto ta sama operacja montowania ? Gdzie i co ustawić aby ZPM też się automatycznie realizował w wyniku montowania wielu pozycji z kompletami (tzn. aby ZPM przyjmował z automatu stan "Przyjęty towar") 2. Czy możecie Państwo dodać skrót klawiaturowy do operacji Montuj dostępnej w menu kontekstowym na liście oraz w samym zamówieniu w operacjach? (dziękuję) 3. Pytanie o nazewnictwo - bo jakoś nie mogę tego załapać intuicyjnie - tworząc komplet poprzez operację ZPM generuje mi się zasadniczo: - RW na rozchód towaru - PW na przychód kompletów Czy to nie jest tak, że ten status powinien nazywać się "przyjęty komplet" lub "wydany towar" w przypadku montowania kompletów (chociaz bardziej intuicyjny jest przyjęty komplet)? W chwili obecnej status nazywa się "Przyjęty towar" - dlaczego?

Pracuje na kliencie pocztowym z Gestora pewnie kilka tygodni (równolegle z dużym Outlookiem) ale nadal zdarza mi się w ferworze walki i pośpiechu usunąć przypadkiem załącznik. Po prostu krzyżyk [x] do usuwania jest na wierzchu i łatwo go kliknąć przypadkiem. Dobrze byłoby dodać uprawnienie uniemożliwiające usuwanie załączników LUB schować funkcję usuwania w Menu kontekstowe pod danym załącznikiem.

Otrzymujemy duże wiadomości z załącznikami plikowymi (pewnie kilkadziesiąt dziennie). Przydałaby się możliwość kopiowania tych załączników (jednego lub wielu - np. poprzez zaznaczenie z CTRL) do schowka systemowego Windows a następnie wklejenia tych załączników np. w nowo tworzonej wiadomości. (Oczywiście jest możliwość ich zapisu np. na pulpicie i ich ponownego załączenia do nowo tworzonej wiadomości ale to trochę okrężna droga, to nie jest tak wygodne jak wyzej wymieniona operacja)

Mechanizm sprawdzania pisowni koloruje wyrazy w których popełniliśmy błąd w pisowni ale bardzo brakuje w menu kontekstowym (gdy klikniemy na danym wyrazie) sugerowanej poprawnej pisowni tego słowa. Oczywiście oprócz podglądu zasugerowanego słowa chciałbym mieć możliwość wyboru i wstawienia wyrazu z właściwą pisownią.

Sprawdziłem i w nowym panelu ING import MT940 działa dobrze. Po zaimportowaniu praktycznie od razu są przelewy są widoczne w Zleceniach (jako paczka lub oddzielne przelewy).

W ramach niniejszego posta pytałem miedzy innymi, czy można byłoby dorobić moduł zleceń transportowych które używamy praktycznie do każdego ZD oraz niektórych ZK bo to my jesteśmy organizatorem transportu. Widzę, że w Navireo pojawił się moduł "fabryka obiektów", który byłby wybawieniem na tego typu potrzeby. Sądzicie Panowie, że kiedyś go ujrzymy w NEXO?

Przydałyby się dymki informujące o nadejściu nowej wiadomości (coś na wzór jak ma duży Outlook) Charakterystyka: - dymek ten powinien być jednocześnie linkiem do danej wiadomości, - powinien zawierać temat - powinien zawierać np. pierwsze zdanie z wiadomości - powinien zawierać nazwę skrzynki której dotyczy wiadomość - byłoby dobrze aby ten dymek był skalowalny (mamy duży obszar roboczy - wysoka rozdzielczość - wiec może być tak, że nie tylko 1 zdanie ale i 2 zdołalibyśmy wyświetlić u nas mając dymek skalowalny) - z racji, że w NEXO, można dany użytkownik programu może być użytkownikiem wielu skrzynek... byłoby dobrze móc przypisać czy dany user ma otrzymywać powiadomienia ze wszystkich skrzynek czy tylko z wybranych np. tylko swojej (aby inne powiadomienia go nie rozpraszały). Handlowcom przypisałbym powiadomienia dot. wiadomości skierowanych do nich ale już kierownikowi sprzedaży powiadomienia dot. wszystkich skrzynek handlowych...