Subiekt nexo
Rachmistrz nexo
Rewizor nexo
Gratyfikant nexo
Gestor nexo
Biuro nexo
Subiekt GT
Rachmistrz GT
Rewizor GT
Gratyfikant GT
Gestor GT
Biuro GT
Ernest Sadowski
-
Liczba zawartości
627 -
Rejestracja
-
Ostatnia wizyta
-
Wygrane w rankingu
2
Posty dodane przez Ernest Sadowski
-
-
<<numery dokumentow realizowanych>> - numery nadane przez numerator
<<numery oryginalne dokumentow realizowanych>> - numery klienta
Są to numery, ponieważ dokument magazynowy i/lub handlowy może realizować wiele ZK/FP, wtedy ciąg ma formę: <numer_1, numer_2, numer_3>
-
Potrzebna będzie zaawansowana edycja wzorca.
Dobry wstęp:
Nie jest to takie proste jak wyżej, bo to pola własne pozycji dokumentu. Edycja będzie polegała na tym samym, tylko będziemy dodawać pola własne encjiPozycji zamiast np. asortymentu.
Jeżeli ma to być w formie dodatkowej kolumny to należy zastosować odpowiednie nazewnictwo obiektów jak na "Stronia_dodatkowa" raportu skąd nexo pobiera dane.
P.S. Teoretyzuje, bo możliwe, że pola własne pozycji/dostaw nie posiadają jeszcze odpowiedniego interfejsu programistycznego tak jak inne pola własne. Proszę InsERT o potwierdzenie i ew. dodanie swojego wkładu i/lub poradnika.
-
2 godziny temu, Daniel Kozłowski napisał:
Tak z ciekawości, gdyż nikt z Państwa nie wyjaśnił w jakich przypadkach pojawia się taka potrzeba, dlaczego tylko część towaru ma być oznakowana, a część nie ?
Zwykle dodrukowywanie oznaczeń, szczególnie podczas inwentaryzacji. Ja i tak jestem już cały szczęśliwy tym co wprowadzono w 47.
Ilość i wzorzec (jak w przypadku drukowania dokumentów gdzie można wybrać wzorzec i ilość kopii) byłby mile widzianym dodatkiem, ale aktualnie i tak działa to o niebo lepiej niż działało (trzeba było robić zestawy naklejek pod każdy wydruk).
-
1
-
-
16 minut temu, Mariola Niełacna-Białek napisał:
Przepraszam za brak wersji programu. Pracuję na najnowszej wersji. Sugestia tyczy się miejsca gdzie zaznaczamy wybrane pozycje z dokumentu - w tabeli podana jest ilość z dokumentu - tam przydała by się możliwość zmiany na taką jaką się uważa za potrzebną. Zaznaczenie wybranych pozycji i skorzystanie z powielania nie rozwiązuje tego problemu bo może być potrzebna w jednym przypadku jedna naklejka, a w innym trzy i to akurat nie będzie się pokrywało z ilością z dokumentu.
+1
Miałem dokładnie taką samą myśl jak testowałem.
Na ten moment jak się chce wydrukować np. 5 z 20 z dostawy X i 6 z 30 z dostawy Y to trzeba 2 razy drukować osobno dostawy * ilość (raz 5, raz 6).
Jest miejsce na usprawnienie.
-
Numeratory partii wydają się działać nieco inaczej bo np. nie śledzą luk w numeracji.
Wiem, że z poziomu asortymentu da się ostrzegać/blokować duplikaty numerów partii:
- w obrębie asortymentu
- w całej kartotece
Chciałbym jednak aby była to blokada w obrębie numeratora, który współdzielony jest przez kilka asortymentów.
Czy da się to jakoś skonfigurować?
Jedyną alternatywę jaką widzę to zdefiniowanie pola własnego "Nazwa Numeratora" i użycie tego pola w Numeratorze partii, do nadawania numerów partii z prefixem jako wartość pola własnego "Nazwa Numeratora" po czym ustawieniu w asortymentach unikalny w całej kartotece, tym sposobem mamy partie z prefixem:
<Nazwa numeratora z pola własnego>/<Numer partii z numeratora>
...które są unikalne w całej kartotece.
Problem, że to STRASZNIE DUŻO niepotrzebnej roboty i dodatkowych znaków w numerach partii.
-
Obsługuje właśnie inną firmę, gdzie zlecają dużo ZD i odbiory osobiste EXW z jednej lub różnych hal produkcyjnych (adresy których wpisane są w kartotekach tych dostawców), i "Adres dostawy" (a w tym przypadku "Adres odbioru") z auto-wyborem adresów tych hal byłby niezmiernie pomocny, bo później od razu wiadomo gdzie wysyłać tiry.
Jest szansa (realna), że pojawi się to gdzieś w v. 48/49?
Bo jak nie to muszę myśleć o jakimś pluginie pod integracje, bo za każdym razem wpisują ręcznie i błędy powstają lub podobne ale inne dane wpisują.
-
W przeszłości ten temat poruszałem także ja. W przypadku z zleceń (ZD) wnosiłem o udostępnienie nowych Statusów dokumentów:
- D - Do realizacji
- R - Rezerwacja numerów partii
- C - Częściowa rezerwacja numerów partii
- Z - Zrealizowane
- A - Anulowane
....które udostępniałyby zakładkę Partie i pozwalały na wpisanie ręczne lub wygenerowanie ich wg standardowych numeracji przypisanych do asortymentów, honorując przy tym ich zasady unikalności lub wymagalności wg kartoteki - tutaj oczywiście nadać jakieś ostrzeżenia na innych dokumentach przyjęć, w momencie przyjmowania asortymentu, który ma zarezerwowany numer partii na ZD, że "Partia <numer> została już zarezerwowana przez Zlecenie <numer>".
Biznesowe zastosowanie:
- Dostawcy dostarczają spisy dostaw jeszcze przed dostawą z numerami partii, które można by wtedy ręcznie wprowadzać do programu przed przyjęciem i przygotowywać naklejki dla magazynierów do oznaczania podczas przyjmowania.
- Producenci mogą także przyjmować nasze numery partii z zlecenia ZD i używać ich do oznaczania produktów naszymi numerami (produkcja na zlecenie).
Ponadto ten sam pomysł pojawił mi się ostatnio na ZPM i ZPR, które to także stanowią Zlecenie i mogłyby działać dosłownie tak samo jak opisuję wyżej (przeczytać temat niżej jako kontynuację tego posta):
Zwracam także uwagę, że podczas gdy w przypadku dokumentów "wydających", np. FS, w przypadku ustawienia statusu jako B (blokada wydania magazynowego) - znika nam dostęp do zakładki partii towarów.
Nie dzieje się tak natomiast dla dokumentów "przyjmujących" takich jak FZ - tutaj przy blokadzie przyjęcia posiadamy dostęp do partii i ich numerów - mimo, że PZ jeszcze nie istnieje (bo numery partii są sterowane przez dokument FZ).
Wg powyższego - postulowałbym, że od strony architektury programu - istniałaby nieinwazyjna-do-wdrożenia możliwość rozszerzenia funkcji programu do sterowania numerami partii z dokumentów ZD, ZPM i ZPR - na podobnych zasadach jak przez FZ i ich auto-PZ (lub brak przy statusie B). Sterowanie numerami partii mogłoby się oczywiście przenosić z ZD na FZ w momencie realizacji.
-
Doprecyzować co ma na nim być albo porównać z czymś co istnieje i czym miało by się różnić, bo narzędzi analitycznych/raportowych, które mogą się tu przydać jest kilka, ale skoro Pan pyta, to możliwe, że żadne nie podeszło pod potrzeby.
-
Ja też mam takie wrażenie, ale nie moje miejsce narzucać sposób komunikacji ludziom. Daję tylko scenariusz, bo wiem, że ludzie skrótowo lubią używać numerki indeksu a nie szukać nazw w kolumnach, nawet jeżeli są posortowane alfabetycznie.
-
Seba: *w ręku wydruk*
"Grażynka, ile tam tego jest faktycznie z pozycji nr 117?"
Grażyna: *liczy 117 pozycji od 1*
(już pomijam, że Seba też liczył do 117)
Dodam, że podobne zgłoszenia pojawiły się na forum (LP na wydrukach raportów) i było mówione, że będą sukcesywnie dodawane (a nawet je dodano już w niektórych miejscach).
-
1
-
-
Tylko ręcznie PW lub wdrożeniowo (programowanie) poprzez Sferę zdarzeniową:
- Przy zapisie dokumentu przyjęcia:
- Skanuj produkty o np. polu własnym "Posiada opakowanie" = "Typ opakowania".
- Utwórz dodatkowe PW do oryginalnego PZ z opakowaniami "Typ opakowania" w odpowiedniej ilości wg PZ.
- Skojarz PW z oryginalnym PZ.
-
Nie jest to odp. na pytanie dlaczego tak działa ale może być rozwiązaniem:
Może to kwestia ustawienia magazynu? Jest FIFO (po datach przyjęciach, i w tym przypadku zwrotów) oraz FIFO po datach ważności.
Pytanie czy daty ważności program ustawia odpowiednio.
Ja ponownie wnoszę do InsERTu o dodanie konfiguracji "Sposobów wydawania towaru" = "Ręczny wybór", żeby błędy magazynierów zredukować do zera (świadome wybieranie partii, a nie z automatu).
-
Dodam od siebie - ostatnio też zauważyłem w zwrotach, że partie trafiają do innej dostawy, a kiedyś (dawno temu) bardzo mi się wydaje, że wracały do oryginalnej jak to opisano.
Czy coś było zmienione kiedykolwiek w tej kwestii? Może wraz z rozwojem programu zaistniała potrzeba rozbijania zwrotu na osobną dostawę, żeby nie ingerować w oryginalną i stąd zmiana? A może moja pamięć dotyczy innego scenariusza biznesowego i jest jakiś podział, że raz działa tak a raz inaczej?
-
To ja zgłaszam, żeby nie była to cena ewidencyjna z kartoteki, tylko po prostu była możliwość skonfigurowania (np. w "typy dokumentów") aby PW z ZP pobierało koszt magazynowy danej partii z pola "Cena netto" na ZP. Może dodać to jako konfiguracja "Sposób wyliczania kosztu magazynowego kompletu" do ZPM/R.
Alternatywnie coś w stylu dodania do pozycji na ZM dodatkową kolumnę "korygowanie kosztu magazynowego" gdzie będzie można wpisać coś dosłownie takiego jak KKD dla powstałego kompletu (ZPM) lub zdekompletowanych składników (ZPR). To by dało największą kontrolę.
Można by też zrobić to na bazie US i UJ - żeby ich cena netto podana w ZP wliczana była do kosztu magazynowego kompletu.
Pewnie się nie pojawi dłuuugo, jeżeli w ogóle.
-
Zmieniałem chyba każde możliwe pole na ZPM ale wart. mag. pozostaje równa składnikom.
Można oczywiście zmieniać koszt przez KKD do PW, ale to strasznie dużo roboty na większą skalę.
Nie da się tego jakoś zrobić na samym ZPM albo auto-dokumentach?
Po co zatem są pola ceny netto/brutto pozycji (zarówno składników jak i kompletu) na ZPM (i ZPR)?
Dla jakich raportów są ważne i jeżeli nie są - to po co w ogóle można je zmieniać (na inne niż zero).
-
Scenariusz:
- Tworzymy ZPM.
- Robimy rezerwacje lub wydanie danych partii składników.
- Pracownik bierze te partie i produkuje jakiś komplet.
- Pracownik wraca z gotowym towarem, a my zmieniamy ZPM na "Przyjęty towar" z aktualną datą.
- ZPM zmienia się na zrealizowane.
Problem w tym, że mimo iż ZPM ma kontrole nad kodami dostaw partii i ich opisem (można manipulować rozbiciem na partie jeszcze przed przyjęciem), to nie daje opcji drukowania naklejek z tym rozbiciem.
Efektywnie jeżeli produkcja wymaga przygotowania naklejek z kodami partii (generowanymi przez nexo) - to te trzeba drukować po przyjęciu - a więc towar nie jest gotowy (bo jeszcze nieoznaczony) ale ZPM jest zrealizowane i PW przyjęte, a np. odpowiednie oznaczenia tysiąca sztuk towaru to cały dzień roboty, wiec w rzeczywistości nie jest dostępne do sprzedania.
Wnoszę o umożliwienie drukowania asortymentu z rozbiciem na partie z poziomu ZPM.
Aktualną alternatywną jest przyjęcie, wydrukowanie z PW i następnie jego skasowanie, ale to dużo klikania i dziurawienia numeracji magazynowych.
P.S. ZPR - to samo.
EDIT:
Ref do podobnego tematu:
-
Aktualnie są na to 2 obejścia:
- Wprowadzić pole własne z numerem i wdrożeniowo sferą zdarzeniową przy zapisie zaprogramować przenoszenie numerów zamówień z pola własnego ZK do pola własnego FS (lub jeszcze po drodze WZ). Wymaga programisty.
- Zmodyfikować zaawansowanie wzorce wydruku i ręcznie "odkręcić" InsERTowskie "shenanigans" po swojemu (obracać wystawce/odbiorce na swoje miejsca jeżeli pole numeru jest niepuste) - niestety to rozwiązanie będzie widoczne tylko na wydrukach, a nie np. w kolumnach przy przeglądaniu dokumentów w interfejsie programu.
Także ja - tak jak trąbiłem - tak będę trąbił w zgodności z @Andrzej Kubik.
-
1
-
Godzinę temu, Łukasz Gręziak napisał:
Przy ręcznym przekształceniu "nowego" ZK nie tworzy się niedopłata.
Zatem to wina integratora. Tam należy kierować zgłoszenie.
Możliwe, że EUR działa bo jest bardziej wszechobecną walutą, a CZK coś źle zaimplementowali.
-
Raport własny z prostym zapytaniem o tabele modeli?
-
Można korygować koszt magazynowy poszczególnych dostaw poprzez KKD i później KKH i KKM.
Jednak może się to okazać BARDZO czasochłonne przy wielu pozycjach.
Resztę pozostawiam Panu, bo instrukcji jest od tego aż za dużo.
-
Jak ma Pan kopie zapasowe jakieś, to na start bym wczytał bazę sprzed X dni i sprawdził czy problem jest replikowalny gdy go "jeszcze nie było".
Jeżeli nie jest, to faktycznie coś z bazą/nexo i można się skupić na tym.
Skoro to problem tylko z Asort. to może dobiliście do jakiegoś limitu i macie brak zasobów.
-
Edycja zaawansowana wzorca w nexo PRO (w Stimulsoft).
Należy odpowiednio wybrać pole zamawiającego, przejść na podmiot (który w tym przypadku jest Przedstawicielem wybranym w polu "Zamawiający") i wybrać imie/nazwisko oraz telefon z kontaktów podstawowych (z racji, że może ich być wiele. Można też iterować po wszystkich telefonach i podać wiele).
Nie jest to w żadnym wypadku łatwe dla osoby bez styczności z programowaniem lub przynajmniej z programami pracującymi z bazami danych.
-
Z zakresu zaawansowanego:
Raporty własne SQL i wyciąganie z bazy timestampa obiektu Asortymentu.
Z racji, że baza zawiera także dane historyczne asortymentu - można także zrobić raporty ostatnich edycji.
Z zakresu standardowego - idk.
Panie Arturze - moja sugestia to znaleźć sobie dobrego wdrożeniowca i rozpocząć stałą współpracę, bo znam "ten" rodzaj potrzeb i PRO może dużo, ale najwięcej w nim może Sfera i raporty własne, która wymagają programowania/SQLa.
-
1. Dodam jeszcze ciekawostkę, że standard EDI++ do komunikacji między rożnymi programami obcina symbol do 20 znaków - ostrożnie z tym faktem, bo później eksporty/importy się mogą zachowywać... beznadziejnie.
2. Też zgłaszam taką potrzebę:
17 godzin temu, Krzysztof Rzeszut napisał:według mnie brakuje możliwości ustawienia maksymalnej ilości znaków
3. Ostrożnie z takim generowaniem symboli. Asortyment ma swoje dane własne (symbol, nazwa, opis, CN, etc.) zachowujące historię zmian, która wykorzystywana jest na dokumentach historycznych (faktury, etc.). Pola te mogą być tylko aktualizowane edytując sam asortyment, natomiast pola takie jak cechy, producent itp. mogą być edytowane poza.
Tym samym jeżeli nastąpią zmiany w polach nie-historycznych, to Symbol automatyczny (jeżeli się o nie opiera) się nie zmieni i będzie inny niż powinien (nie zostanie wykryta zmiana). Jeżeli już coś wykorzystywać do generowania symbolu to pola asortymentu.
4. Osobiście zalecam Symbole pozostawić numerowane standardowo a do SKU użyć pola własne i nadawać je ręcznie - lub lepiej - napisać plugin, który robi to kontrolowanie na kliknięcie użytkownika (i go puszczać jak trzeba dla nowych asortymentów albo masowo dla wszystkich pozycji, gdzie program użyje danych w bazie do wygenerowania nowych SKU i umieszczeniu ich w pole własne).
Plugin = Sferyczne rozwiązanie, które trzeba napisać oczywiście.
Pola własne dla pozycji dokumentu
w Subiekt nexo
Napisano · Edytowane przez Ernest Sadowski
Tak jak wspomniano wyżej w temacie - nie jest to takie proste.
Szczerze to jest na tyle trudne, że pewnie nie zobaczymy przez długi czas, jeżeli w ogóle (raczej to 2). Od takich zmian są serwisanci.
Kod źródłowy wzorców jest przetwarzany przez program Stimulsoft i aby obsługiwać pola własne - muszą się one w tym kodzie znaleźć.
Pola własne standardowe działają, bo są tam zakodowane na stałe (hard coded).
Pola zaawansowane są nie tylko znacznie bardziej rozbudowane (ich typy i opcje), ale żeby w ogóle pojawiły się w kodzie wzorca, nexo musiałoby edytować wszystkie lub wbudowane wzorce w momencie edycji pól własnych i dodawać do nich kody odpowiadające za przetwarzanie tych pól. Takie przetwarzanie kodu jest nie tyle trudne, co bardzo niestabilne. Możliwe, że powstanie taka opcja, ale jeżeli - to na pewno tylko i wyłącznie dla wbudowanych wzorców (a nawet to będzie trudne w utrzymaniu), które następnie będzie trzeba powielać, bo nie wyobrażam sobie jak nexo mogłoby manipulować kodem już edytowanych przez użytkownika wzorców.