Ernest Sadowski

Zostać zostanie ale jest to tzw. zachowanie nieokreślone programu - czyli BUG. Zalecam tu nie kombinować bo w dalszych etapach (wystawianie FZ i rozliczanie) się syf robi i traci powiązania. Wygląda na to, że ZD może przyjąć (jako przedpłata) tylko SZ realizowanym przez wykonane już operacje (np. bankowe, tj. przelew). Stworzyłem rodzaj płatności jak wyżej. Jest to jednak płatność a nie przedpłata. Innym faktem jest to, że kiedy wybierzemy ją jako Płatność na ZD to nie wygeneruje ona żadnych rozrachunków (a Pan pisze, że tak). Można kilka słów więcej bo albo robię coś inaczej albo mówimy o totalnie innych rzeczach. Edit: Wydaje mi się jednak, że mówimy o tym samym i dopowiem, że owszem - rozrachunek się wygeneruje ale po realizacji ZD (przez FZ), a istotą problemu tego tematu jest ustalenie sposobu na powiązanie przedpłat z zamówieniami i rozrachunkami, co aktualnie nie jest możliwe w sposób 100% satysfakcjonujący (np. brak możliwości automatycznych dyspozycji przy podłączaniu Zobowiązania).

Tym samym się aktualnie bawię. Zalecam (cały proces): Stworzenie ZD. Wysłanie ZD do dostawcy. Otrzymanie proformy. Utworzenie nowego Rozrachunku o typie Spłata Zobowiązania. Wejście w ZD i w płatności wybranie z listy Przedpłat ten Rozrachunek. Rozrachunek zostanie skojarzony z ZD, a później automatycznie z FZ. Jakiekolwiek edycje i płatności/rozliczanie także będzie dokonane automatycznie. Dodam, że musi to być Spłata Zobowiązania, Zobowiązanie nie będzie wykryte na liście w ZD. Dodatkowo istnieje bug (chyba należy to zablokować, prawda? W sensie zabronić edycje Rozrachunku powiązanego.): Jeżeli stworzymy Spłata Zobowiązania, później podłączymy je do ZD i edytujemy na Zobowiązanie, to ZD utraci relacje nic nie mówiąc - tutaj mówię żeby nie kombinować.

Dzień dobry, Podejrzewam, że problem był już poruszany niejeden raz. Otóż bardzo starałem się stworzyć role użytkowników z takimi uprawnieniami i zaplanować ich pracę tak, żeby silnie rozdzielić: magazyn handel księgowość Handlowiec (sprzedawca, etc.) miałby możliwość: Wystawiania i zmiany statusów ZD, ZK. Wystawiania FP w ramach prowadzonej sprzedaży (wraz z ZK). Magazynier miałby wgląd do ZD, ZK i według nich obsługiwałby magazyn - pakowanie, wysyłki, przyjęcia i korekty: Wystawianie PZ, KPZ, PV, KPV, WZ, KWZ. Wgląd i zmiana statusów ZD, ZK (trzeba nadać prawo do zmiany statusu bo inaczej program wysypie błąd przy 100% realizacji chcąc je zamknąć automatycznie) Księgowość wprowadzałaby wszelkie faktury, prowadziła rozliczenia i przygotowywałaby dyspozycje bankowe dla osoby uprawnionej (np. szef czy główny księgowy). Wprowadzanie przedpłat do ZD na podstawie proform od dostawcy. Wprowadzanie FZ dla jednej lub wielu PZ zrobionych przez magazyniera w ramach realizacji ZD i ogólnie wszystko inne żeby doszlifować dokumentacje handlową/magazynową. Wystawianie FS i FL dla opłaconych ZK w ramach proform (przy przedpłacie) wysłanych do klienta przez handlowca lub po prostu wystawianie ich w ramach płatności odroczonych. No i oczywiście rachunkowość/bank/przelewy, ale tu już Rachmistrz więc nie wchodzę w te tematy. Brzmi prosto, na pewno widziałem podobne tematy dotyczące podziału (działy sprzedaży / magazyn / księgowość) ale sposób implementacji jest trudny i wymaga przedwczesnego ostrego planowania procedur wewnątrz firmy, które nawet jak działają to wymagają zbyt dużych interakcji między różnymi działami - szczególnie między magazynem a księgowością. Kontynuując - wiadomo, że Insert nexo (PRO) nie implementuje jakichś turbo rozwiązań security (np. nie ma ACL obiektów tylko zwykłe globalne role/user, a na poziomie SQL to już w ogóle zero ochrony) więc tutaj nie spodziewam się magii (to nie SAP ;p), jednak można by usprawnić działanie dodając kilka dodatkowych operacji i uprawnień do nich. Patrząc na model powyżej weźmy przykład prostego ZD gdzie dostawca wymaga 100% przedpłaty (a jest cała masa innych scenariuszy, które też analizuje i szukam obejść): 1. Handlowiec tworzy ZD. 2. Dostawca wystawia Proformę. 3. Proforma trafia do księgowości a ta sprawdza, że ZD istnieje i tworzy Rozrachunek (i zleca np. dyspozycje/przelew bankowy) na daną kwotę, który podłącza pod ZD. No i teraz mamy 2 rozgałęzienia (zakładając, że towar będzie wysłany dopiero po realizacji przedpłaty): Towar może przyjść wraz z FV. FV może przyjść przed towarem (e-mail). No to weźmy sobie sytuacje taką, że FV przyszła z towarem (kontynuuje numeracje 1,2,3,...): 4. Magazynier odbiera przesyłkę, realizuje ZD jako PZ i przekazuje FV księgowości. 5. ZD jest zrealizowane, księgowość widzi niezafakturowaną PZ, ale chwilę później dostaje na biurko FV, którą fakturuje PZ jako FZ. 6. Wszyscy są szczęśliwi. A teraz dajmy na to FV przyszła wcześniej (kontynuuje numeracje 1,2,3,...): 4. Księgowa wprowadza FV jako FZ realizując ZD i teraz... albo odłoży przyjęcie towaru albo je zablokuje. 5. Przychodzi dostawa, ZD jest zrealizowane, auto-PZ wisi odłożona albo jej nie ma (zablokowana). 6. Jedyny sposób na powiązanie takiej dostawy (PZ) z obecną już FZ to zrzucenie roli magazyniera na księgowość (poprawiają PZ za magazyniera) lub danie magazynierowi uprawnień do edycji FZ a co za tym idzie wszystkich widoków, list, zestawień. Podobna sytuacja jest ze sprzedażą i multum innych scenariuszy gdzie ciężko prowadzić modularny podział roli pracowników. Ciężko skalować i usprawniać działalność firmy kiedy różne osoby muszą robić to samo i chodzić prosić innych o wprowadzanie poprawek. Obecnie takie głupoty robię, że np. dla powyższego scenariusza (FV przyszła wcześniej), księgowość odkłada przyjęcie towaru, drukuje PZ, daje ja magazynierowi, a ten sprawdza kartkę jak jakaś dostawa przychodzi, po czym sprawdza dostawę czy się zgadza i wraca do księgowości z info, że przyjęcie jest sukcesem (lub np. wymaga korekty). Wszystko fajnie i tak większość problemów można załatwić (jak nie chcemy wszystkim dawać uprawnień do wszystkiego, tylko jasno mówić kto za co odpowiada) ale to nadal jest trochę nieoptymalne i nadal finalizacja procesu angażuje 2 działy. Dla tego przypadku widzę miłe rozwiązanie: auto-PZ z odłożenia przyjęcia są mocno powiązane z FZ, dlatego na podglądzie przyjęć jak klikniemy na taką PZ i zmianę statusu (a właściwie jakąkolwiek edycję), dostaniemy: A tutaj można by pozwolić np. takiemu magazynierowi na przyjęcie towaru z auto-PZ bez dawania dostępu do FZ. Już pomijam korekty po tam to dopiero rzeźnia ale chciałem przedstawić zarys problemów jakie istnieją w Subiekcie przy jakimkolwiek podziale obowiązków. Czy prowadzone są może jakieś prace w tym kierunku? Ciągle coś czytam, że będzie możliwość np. powiązania dowolnych dokumentów między sobą - może takie coś też by wiele spraw tu rozwiązało? Ew. może jakieś dodatkowe uprawnienia i operacje, które pozwoliłyby jakoś pracować przy takich sytuacjach?

Próbując wyeksportować dyspozycje bankową do .txt ("Rodzaj wysyłki: Santander (zgodny z KS (Elixir-0))") takie coś dostaje i wywala. Problem zachodzi dla nr. nie-NRB jak widać, w tym przypadku jest to 20-cyfrowy nr. z banku w Chinach (a tam kosmos a nie standard jest... np. IBANa nie ma też). Można gdzieś ustawić lub dodać feature gdzie błąd będzie tylko warnem?

Nie jestem pewny dokładnie w jakich sytuacjach się pojawia i też nie wydaje się krytyczny, ale warto zgłosić - może już znany. Przytrafiał się przy różnych okazjach na wersji 25 i 26 pozostał. Najłatwiej odtworzyć wchodząc w "Użytkownicy" i "Popraw" jednego z wpisanych. Jeżeli w trybie "popraw" przejdziemy (zakładając, że rozpoczęliśmy w karcie "Podstawowe") na kartę "Uprawnienia" to program zacznie ssać RAM i się potwornie zawiesza (coraz mocniej) do etapu gdzie np. drop-down "Kategoria:" wyświetla się w w złym miejscu (górny lewy róg ekranu). Jedyny sposób gdzie można uprawnienia edytować sprawnie to wpierw podgląd użytkownika, przełączenie karty na "Uprawnienia" i dopiero kliknięcie "Popraw" z poziomu karty. W takiej sytuacji po przejściu na edycje możemy pracować, ale np. jeżeli w czasie edycji zmienimy kartę na inną i znowu na "Uprawnienia" to stanie się to samo (zawiesi). Gdzieś w jakiejś funkcji powiedzmy "init()" tej karty jest błąd, który robi syf. Skoro thread UI szaleje i źle renderuje to z dośw. zakładam duplikaty obiektów (zatem memory leak) i złe łączenie referencji obiektów danych z wątkiem UI. Ew. po prostu gafa w inicjalizacji karty lub tabeli uprawnień. Proszę o potwierdzenie buga i info o fixie.

Dziwie się, że jeszcze Santandera nie ma (właściwie to mało który jest bo chyba 3?). Dodam może jeszcze, że przy wprowadzaniu placówki Banku Santander jeszcze figuruje jako Oddziały BZWBK (nie wiem czy wszędzie ale np. we Wrocławiu). Przekształcenie już jakiś czas temu (placówki po remontach już) było wiec chyba się ustabilizowało wszystko. Innymi słowy - Santander mile widziany! Edit: PKO BP też!

Próbuje znaleźć konkretny powód dla istnienia obu PZ i PV (od strony logistycznej, logicznej i informatycznej) - dlaczego nie tylko jedna z np. 2 szablonami wydruku (z vat i bez)? Gdzie nie spojrzę (google, inne programy, jakieś fora o prowadzeniu magazynu, itp.) to mówi się tylko o PZ i czasem wspomina, że może mieć VAT lub nie. Na podstawie obu można wystawić FZ, tak samo przy WZ - po co ta WV skoro to i tak to samo? Jedyna różnica jaką widzę to zakładka VAT, która właściwie nic nie robi (pokazuje to co okno główne tylko w innej tabelce). Czy można prosić o realne zastosowanie osobnych dokumentów? Przecież to samo osiągam mając 2 wzorce wydruku (z i bez VAT), a sama PZ/WZ to dokument wewn., nie księgowy ani handlowy - więc po co w ogóle ten VAT (bardzo często kupujący nawet proszą o nie podawanie cen na WZ, a o VAT też nikt nie pyta bo jest na FS/FZ)? Jaki był zamysł tej osobnej kartoteki? Pamiętam kiedyś spytałem księgowych i odp. +/-: "a czasem tak się robi a czasem tak, kwestia preferencji w przedsiębiorstwie". EDIT: Pytanie też kieruję do innych userów - kiedy i jakich używacie? Dlaczego tak? Sam po prostu nie widzę "prawdziwej różnicy" a nie chcę mieć później problemów i wymieszanych dokumentów (raz WV, raz WZ) jak się okaże, że jednak różnica istnieje i nagle czegoś się nie da.

Myśleliście kiedyś o wprowadzeniu specjalnego trybu pracy w liniach nexo (szczególnie PRO gdzie często są oddziały), który podobnie jak np. FTP by ściągał tylko deskryptory danych lub zwyczajnie ich część - nie potrzebne jest np. pobieranie od razu wszystkich zakładek w danym oknie naraz - to wszystko można by pociąć i wysyłać per-click. Coś w stylu informatorów i opcji "oblicz" dla raportów. Wiadomo działo by się to kosztem większej ilości zapytań do serwera, ale to i tak jest lepsze niż proponowana praca RDP wszystkich userów na jednym serwerze. Nie jestem też pewien ale nexo także chyba nie utylizuje paginacji, ale może nie dogrzebałem się - w każdym razie otwarcie zakładki np. wzorce wydruku - lokalnie zaczytuje wszystko co się da, a remote wiąże się to zawieszeniem programu na kilka- do -naście sekund (jak nie gorzej). Można by wprowadzić tu wiele udogodnień robiąc paginacje i wspomniane wcześniej deskryptory, bo nie wierze, że wczytanie absolutnie podstawowych danych przez 1Gb łącze zajmowało tak długi czas (zgaduje, że wysyłane jest wszystko naraz, albo np. wszystko w danej liście (mimo, że pewne elementy są pochowane w widoku listy i nie trzeba ich requestować z serwera). Chciałbym wiedzieć co nexo robi, że tak słabo zoptymalizowany jest pod prace zdalną? Nigdy się jeszcze nie spotkałem z tak wolnymi przesyłami programów.

Można się spodziewać jakiegoś prostego tymczasowego rozwiązania typu "Cecha"? Tak jak: Symbol generuje <symbol>:<cecha> Nazwa generuje <nazwa>:<cecha> To "Cecha" by generowała tylko <cecha>? Można by mieć krótkie Nazwy a jedynie długie Opisy (pełne). Doskonałe przy generowaniu wariantów bez klikania miliona razy, szczególnie przy dynamicznych produktach w sklepach internetowych. Może w jesiennej? (To poważnie - mała prosta zmiana na tą chwilę, a w przyszłości można się bawić dalej). EDIT: Dodam jeszcze, ze jest bug! Przy ustawieniu: ...i wygenerowaniu wariantów, a później próbie edycji takiego wariantu, program będzie sypał ostrzeżeniami odnośnie złej nazwy.

Czy istnieje jakaś rekomendacja? Stanowiska klienckie to nowe kompy (9th gen i5 , 8-16GB RAM, SSD) i praca lokalna to komfort. Z Serwerem znacznie gorzej (np. "Wystaw FS" to kilka sec zanim się okno otworzy, zapis podobnie). O konfiguracji już nie wspomnę (wzorce wydruku się wczytują kilkanaście sec.) ale to mogę robić przez RDP na maszynie. Dodawanie asortymentu/kontrahenta to też sieczka bo zabiera kilka sec samo otwarcie karty. Serwer jest wg. mnie spokojnie wystarczający a problem raczej leży po stronie latency - ale może się mylę i chciałbym spytać czy to normalne przy pracy remote? W przyszłości pewnie postawimy serwer w budynku z domeną, ale na razie bardzo ciężko się pracuje z serwerami dedykowanymi zewnętrznymi. Serwer WinServer 2018 z MSSQL Express 14 (2017) na 8GB RAM (których w ogóle nie zużywa praktycznie) i CPU Xeonie, który też nie wybiega nad 10%. Łącze 1Gb. Pomocne byłyby np. wymagania latency/przesyłu/maszyny, przy których nie cierpi user experience. Np. na jakich testowaliście i jakie zalecacie opóźnienia? Może walniemy światłowód do skrzynki prosto i pomoże ale zanim to zrobię przyda się gwarancja, że to faktycznie pomoże.

Testuje zachowanie programu przy wyliczaniu cen. Sytuacja wygląda tak, że importujemy np. kilka palet, na których są te same Lot No. (numer partii) danego produktu. Palety te jednak mogą być wysłane w różnych dostawach - co prawda z taką samą ceną, ale innymi kosztami celnymi (czasem nawet nam cła nie naliczają w ramach "części zamiennych" :P) i transportu - innymi słowy jeden numer partii ma kilka dostaw a te mają osobne KKD (cło i transport). Zasymulowanie tego to trochę czasu i nigdy nie pewne dlatego chciałbym spytać tu. W szczególności chodzi mi o: Wg. poradnika: https://www.insert.com.pl/dla_uzytkownikow/e-pomoc_techniczna/2869,ceny-w-subiekcie-nexo.html Co rozumiem jako: Zgadza się? Teraz co chciałbym doprecyzować to OstatniaCena_Dostawa_i - jak się ona zachowa dla opisanego przypadku importu i kilku dostaw tej samej partii z różnymi KKD? Dziękuję!

Na pewno będzie działać jak dodamy role "db_owner" (tak jak ma to domyślny użytkownik "dbo"). Wiadomo jednak po to ma być user inny żeby miał mniejsze prawa. Aktualnie także eksploruje zabezpieczenia baz InsERTa i na razie ciężko znaleźć jakieś konkretne źródła mówiące o czymkolwiek związanym z SQLem (właściwie czymkolwiek wyżej niż user interface programu). Jakieś hinty może jak ograniczyć np. kasowanie tabel bazy danych (co db_owner może a jest ustawiony jako default dla InsERTa)?

Pozwolę sobie dopytać - albo nie jestem świadomy funkcjonalności (może istnieje under-the-hood :P) albo faktycznie programy nexo mają żadnych domyślnych zabezpieczeń bazy (tylko wizualne pozwolenia z poziomu programów i kont samego nexo). Rozumiem, że jeżeli ktoś ma mieć możliwość korzystania z systemu to musi mieć pełne read/write (conajmniej db_dataread i db_datawrite, pewnie nawet więcej) a jakiekolwiek dodatkowe zabezpieczenia to trzebaby robić samemu poprzez osobne permission na każdy table w bazie? Proste tak/nie już mi da dużo info i zabezpieczę jakąś część sam.

Dzień dobry, Czy mógłbym prosić o bardzo ogólne opisanie w jaki sposób można wystarczająco zabezpieczyć bazy danych programów InsERT nexo? Uwarunkowanie: Dedykowany serwer z bazą danych Subiekt+Rachmistrz (+ew. inne moduły). Dedyk NIE jest domenowy. Wiele stanowisk klienckich (nie domenowe) i konta użytkowników w programach InsERT z rolami np.: "Magazynier Główny", "Magazynier", "Księgowa Główna", "Sprzedawca", etc. Bazy danych udostępnione są na X porcie serwera dedykowanego. Uwierzytelnianie odbywa się poprzez: 1. Certyfikaty (stanowisko klienckie musi mieć certyfikat żeby w ogóle połączyć się z SQL dedyka). 2. Login/Hasło do konta użytkownika zdefiniowanego z poziomu MSSQL (każde konto użytkownika w programie InsERT nexo ma osobno utworzony odpowiednik w bazie MSSQL). 3. Dodatkowo połączenia są wiadomo szyfrowane itp. Co próbuje zrozumieć - autoryzacja: Wcześniej wspomniane role i ew. inne pozwolenia przypisane do danego użytkownika InsERTa są (chyba) zabezpieczeniem interfejsu, prawda? Teoretycznie wszystko czego nie można zobaczyć z racji na brak pozwoleń z poziomu InsERTa, można zobaczyć (a co gorsza zedytować) poprzez proste zapytania prosto do bazy w SQL. W jaki sposób się zabezpiecza bazy InsERTa przed takimi działaniami (wspomniałem, że w MSSQL są odpowiedniki kont do każdego konta w prog. InsERT)? P.S. Można opisać w żargonie programistycznym/security. Dziękuję za pomoc!

Jak kompletny jest taki import z poziomu Subiekta? Wykonałem dziś taki import (nowy podmiot nexo na bazie importy z GT) i tylko część danych jest dostępna: Zaimportowało ogólne ustawienia (dane firmy pracowników), rozliczenia (chyba tylko częściowo), Kontrahentów, Asortyment. Do tego wykonało się kilka PZ które odtworzyły stan magazynowy i tyle. Historia zakupów/sprzedaży jest "zerowa" (brak FV, itp. właściwie żadnych dokumentów nie ma prócz PZ magazynu) Czy to normalne (nexo importuje tylko część danych), czy może wynika to z błędów starej bazy GT? Przyznam, że jest tam syf i i tak planujemy odbudować ją od 0, ale import by się przydał w jakimś stopniu.

Wymaga doprecyzowania. Nie da się mieć Subiekta "tak o" w chmurze. Do tego trzeba mieć serwer z MSSQL. W wersji Express baza danych Subiekta może mieć max 10GB, do większej bazy trzeba zakupić licencje MSSQL Standard (lub wyżej) lub zakupić licencję Runtime dla InsERTa. Aby postawić taki serwer MSSQL trzeba co najmniej serwera VPS (w mojej opinii). Zalecam przynajmniej 2 lub 4 core, i kilka GB RAMu. Nastawić się na dyski SSD. Koszt roczny żeby to dobrze biegało to ok. 1000zł (wiadomo można taniej za słabsze, ale wtedy praca z poziomu klienta to masakra - wszystko wolne). Też dodam, że praca z subiektem przez WiFi to nieporozumienie, TYLKO na kablu, najlepiej światłowodzie (niskie latency musi być). Zaznaczę ponownie - wymaga doprecyzowania.

O to chodziło, dzięki. Jeszcze dopytam dla pewności - Klient (Osoba) może stać się Pracownikiem a Pracownik Wspólnikiem ale nie da się zdegradować Wspólnika do Pracownika ani Pracownika do Klienta (Osoby). Czy to będzie prawda (powyższe)? Czy są jeszcze jakieś opcje (w sferze osób/pracowników), o których warto mieć pojęcie przy przekształcaniu Osób? Może jednak można zdegradować (jak opisane wyżej)?

Zdarzało się już w GT, a teraz w nexo, że chcieliśmy zatrudnić osobę, która figurowała w bazie jako Osoba z historią handlową z naszą firmą. Przy założeniu, że PESEL/NIP mają zablokowaną unikalność z poziomu konfiguracji systemu - czy możliwe jest aby Osoba także była pracownikiem (bez tworzenia duplikatu, która jak wspomniałem jest zablokowany)? Próbowałem to testować ale sekrety systemu są niejasne. Definiowałem Osobę, powstawał Klient ze statusem Standardowy. Później chciałem stworzyć Pracownika z tym samym PESEL, wykryło duplikat - jak się da NIE to nie stworze takiego Pracownika bo system blokuje duplikaty PESEL, jak dam tak to przenosi mnie do zakładki Klient tego pierwszego utworzonego - zakładka Pracownik się nie pojawia (innymi słowy nie można utworzyć zakładki Pracownik na istniejącym Kliencie/Osobie). Jeżeli wpierw stworze Pracownika to zostanie utworzona zakładka Pracownik i zakładka Klient ze statusem Potencjalny - więc tu zakładam wszystko działa bo można by mieć relację handlową z Pracownikiem w przyszłości. Jeżeli utworze Wspólnika to znajdzie mi Osobe (Klienta) lub Pracownika i przekształci go w Wspólnika. Po takiej operacji Wspólnik ma zakładki Klient i Wspólnik, ale nie Pracownik. Nie da się też zdegradować do Pracownika, na zawsze jest Wspólnikiem i nie ma zakładki Pracownika. Czy można prosić o wyjaśnienie i ograniczenia systemu? Czy nexo przewiduje procedury jakieś? Czy jedynym wyjściem będzie zezwolenie na duplikaty PESEL/NIP (sytuacje opisałem na bazie PESEL ale NIP też pewnie będą skomplikowane przy podobnych zmianach danych) i wprowadzenie tej samej fizycznej osoby jako Pracownika, po tym jak był już Osobą(Klientem). Zależy mi na integralności i nie chce mieć raz połączonych Osoba/Klient+Pracownik a innym razem nie (bo Osoby/Klienta nie mogę upgradować do Pracownika), podobnie Wspólnika - więc rozważam ZAWSZE wprowadzanie duplikatów. EDIT Popatrzyłem trochę na bazę danych i pola przy tworzeniu poszczególnych: osoby, pracownika, wspólnika; i chciałbym wskazać możliwe ujednolicenie - porównując owe 3 występują rozbieżności np. dla pracownika dział Opis i Kontakty jest w zakładce Inne, podczas gdy te same działy dla Wspólnika są w zakładce Podstawowe. Ogólnie jak przeprowadzić oględziny to trochę ciężko się poruszać. Nie można by wszystkiego tworzyć jako Osoba i dodawać tylko zakładki "Wspólnik", "Pracownik", kiedy Dana osoba się nim staje? Tak jak wspomniałem - przerobienie Osoby we wspólnika kasuje jego dane Pracownika (dodam - dosłownie kasuje rząd danych z tabeli w bazie). Może nie w pełni rozumiem jak to miało działać? EDIT Kolejne odkopane: Insert definiuje "Grupy pracownicze" i "Grupy klientów" - są to duplikaty, przynajmniej od strony użytkowej - dla utworzonych pracowników jeżeli dodamy Grupę pracowniczą, powstanie także duplikat w Grupie klientów i insert nie rozróżnia obu (modyfikując "Grupa" w zakładce "Klient", zmienimy także "Grupę pracowniczą" w zakładce "Pracownik").

Dobrze wiedzieć, że istnieje rozwiązanie tego problemu (nie zdarza się często ale lepiej naprawiać takie błędy dla integralność danych).

Czy istnieje możliwość powiązania FZ do ZD po fakcie (nie w ramach realizacji ZD jako FZ)? Powstaje sytuacja gdzie wprowadzana jest FZ bez skonsultowania z listą bieżących ZD i nagle się okazuje, że ZD jest już zrealizowane a nadal stoi na 0%/Do realizacji. Na tą chwilę widzę opcje skasowania FZ i wprowadzenie jej jeszcze raz (pod numerem-luką) jako realizacja ZD, ale będzie to niemożliwe w przypadku gdy asortyment z dostawy będzie już zablokowany (rozprowadzony). Coś przeoczyłem? EDIT (Zamiast tematu spytam tu bo blisko): Jest sytuacja, gdzie definiujemy ZD na 10szt. po czym dostajemy od dostawcy część zamówienia (5szt.) i osiągamy 50% ZD. Stwierdzamy, że resztę odwołamy (dostawca się spóźnia lub nie jest w stanie zrobić reszty ZD na czas). Czy w takiej sytuacji Subiekt przewiduje, że Anulujemy ZD i zostawimy je na 50%, czy może przewidziana jest jakaś inna operacja? Czy w zamyśle było przewidziana sytuacja gdzie zamówienie jest anulowane na 50%, czy może powinienem robić jakieś korekty w danych (można by Poprawić, ale wolę zablokować poprawki dla pracowników, bo w końcu raz wygenerowany dokument ZD raczej wyszedł już do dostawcy i lepiej go nie edytować). Powtórzę - czy zamysłem było ustawianie takich sytuacji na Anulowane 50% (nieciekawe te 50%)?

W Szablonach naklejek możemy każde dostępne pole (tekstowe) zakodować w kod kreskowy - a dokładniej QR. Miło by było gdyby można było także dodać pole tekstowe złożone - konkatenacje innych pól, tak żeby tak wygenerowany tekst można zakodować do jednego QR (dla odczytu czytnika/appki). Przykładowo dla "asortyment na dok. magazynowych" można by całość złożyć w długi string i zakodować w jednym QR (bo przecież QR ma mase miejsca na dane), np.: "{ Symbol:" + <symbol> + "; Kod:" + <Kod dostawy> + "; Nazwa:" + <Nazwa asortymentu> + "; }" { Symbol:<Symbol>; Kod:<Kod dostawy>; Nazwa:<Nazwa asortymentu>; } (Bold to Własny tekst rzecz jasna). Z innej perspektywy jeszcze lepiej (elastycznie) by było gdyby można zdefiniować własne SQL/LINQ z poziomu KAŻDEGO typu kartoteki (nie tylko Raporty własne SQL/LINQ). Tutaj wyższa szkoła jazdy bo można wtedy na naklejkach dowolnych kartotek umieszczać dowolne dane bez potrzeby budowania rozwiązań własnych. Tak dodam, że na tą chwilę poradziłem sobie z konkatenacją pisząc totalnie własny raport SQL, który wyciąga identyczne dane z bazy jak "Asortyment na dok. magazynowych" i dodałem dodatkową kolumnę łączącą pola, które potrzebowałem (głównie Symbol+Kod+Nazwa do QR), problem tylko, że nie mogę już korzystać z funkcji kliknięcia z poziomu "Magazyn->Drukuj naklejki z asortymentem", tylko wejść w "Ewidencje dodatkowe->Raporty" po czym odszukać odpowiedni kod dostawy w wspomnianym moim Raporcie własnym SQL i dla niego wydrukować naklejki. Jest to jakieś rozwiązanie ale rozszerzenie funkcjonalności o dodawanie własnych SQL/LINQ do dowolnych naklejek byłoby absolutnie wspaniałe - nie tylko dla przypadku opisanego tutaj.

Wracając do poprzedniej wypowiedzi - zaznaczę, że istnienie Modelu ma ułatwić obsługę wielu jego wariantów - tj. generować asortyment i grupować go na bazie klas cech (właściwości). Fakt istnienia możliwości generowania wariantów nie zmusza nas wcale do wygenerowania wszystkich. Możemy zdefiniować duży model z nawet pierdylionem różnych właściwości i cech, po czym generować (w oknie "Uzupełnianie wariantów") warianty (asortyment) o wybranych cechach. Jasne - na początku może to być troszkę mozolne bo trzeba będzie tworzyć wariant (może 20sec czasu przy dobrze zdefiniowanych szablonach), gdy ten pojawia się pierwszy raz, ale po pewnym czasie sprzedawane warianty zaczną się powtarzać i po problemie. Baza danych schludna, kartoteka asortymentu ma tylko to co się sprzedaje i elo. Jednak subiekt to program magazynowy (i sprzedaży) co silnie raczej wpływa na design - każdy typ towaru na magazynie (wydanie/przyjęcie) MUSI mieć swój przypisany Towar w asortymencie (ew. kod Dostawy ale to inna bajka). A o tym wspominam bo napisano "W kartotece mamy tylko (w tym przykładzie) dwa rodzaje farby" - tak być nie może bo nie istniało być rozróżnienie na różne warianty farb na magazynie i dokumentach. Chciałbym się bardzo odnieść do opisanego procesu mieszania farb ale chyba nie rozumiem co z czym jest mieszane - coś mowa, że każda farba może mieć wiele wzorników a każdy z nich może mieć wiele kolorów, ale nagle jest jeszcze baza A i baza C i już nie wiem co faktycznie jest mieszane a co jest wariantem). To co mówisz Robert to leci raczej mocno w rozwiązanie własne jak chcesz mieć pełną kontrolę nad cechami (zaznaczam, że nie w pełni zrozumiałem proces). Się trochę rozpisuje i wybiegam poza temat możliwe, który kierował się na UI/UX, a tu szczerze osobiście ja nie widzę problemów, bo są całkiem wygodne obejścia (montowanie, usługi z kosztorysem, usługi z materiałami, własne szablony usługi - czyli np. usługa będąca towarem, który składa różne materiały), które mogą to robić lepiej (kwestia raczej też znajomości nexo). Jedyne czego mógłbym się przyczepić to możliwość definiowania pod-właściwości (hierarchia właściwości typu węzeł z właściwościami końcowymi, które mają finalne cechy) - dało by to opcje bardziej elastycznego generowania wariantów, ale to i tak da się zrobić ręcznie więc więcej roboty niż wygody.

Przecież jest to zaimplementowane i to całkiem dobrze. Można utworzyć model i nadać mu właściwości. Każda właściwość może mieć różne cechy. Różne cechy mogą być także używane przez wiele właściwości a te przez wiele modeli. Dodatkowo można też utworzyć szablon asortymentu (np. bazujący na Towar), który pozwoli szybko wygenerować warianty wszystkie. Szczegółowy opis: 1. Ewidencje dodatkowe -> Konfiguracja -> Asortyment -> Właściwości asortymentu Definiujemy Kolor i Rozmiar 2. Ewidencje dodatkowe -> Konfiguracja -> Asortyment -> Cechy asortymentu (lub prosto z okna właściwości) Definiujemy Biały, Czarny, S, M, L 3. Te cechy można teraz użyć w wielu właściwościach (relacja wiele do wielu), logicznie przypisujemy Kolor:Czarny/Biały i Rozmiar:S/M/L. 4. Tworzymy Model i nadajemy mu Właściwości. Możemy teraz sobie wygenerować wszystkie warianty klikając na model w liście modeli i Uzupełnianie wariantów. Tam też można wybrać szablon asortymentu tak żeby dla wszystkich wariantów ustawić domyślne wartości. Szablon definiujemy w Konfiguracji (jeżeli trzeba inny niż "Towar"). 5. Dodatkowo Nazwy i Opisy wszystkich wariantów mogą być generowane automatycznie z <właściwość>:<cecha> - ustawiamy to w Konfiguracji Parametry asortymentu. Zgodzę się, że można to ulepszyć ale działa to świetnie jeżeli się zaplanuje dobrze wszystko. W temacie:

Weźmy model z wieloma właściwościami. Generując asortyment z opcją automatycznego nadawania nazwy/opisu mamy kilka możliwości (Parametry asortymentu -> Automatyczna zmiana nazwy/opisu asortymentu). Możemy wybrać "Dołącz właściwość" w formie: Brak Z symbolu: <symbol właściwości>: <cecha> Z nazwy: <nazwa właściwości>: <cecha> Dla takiego Modelu: Wygenerujemy np.: Moje pytanie - czy da się jakoś generować cechy bez nazwy właściwości? Dla przykładu wyżej: FCMB-E • 1um • SC • 20" • Yes • MVQ Przy wielu właściwościach daje to możliwość znacznego skrócenia nazw na np. FS. Z tego co na razie próbuje to nie da się (nazwy nie mogą być puste, a nawet gdyby to też byłby "hack" bo by się wyświetlało nadal ":" przed <cecha>). Można by to na wiele sposobów rozwiązać - w ramach globalnej opcji w "Parametry asortymentu" np. "Poprzedzaj nazwą właściwości: Tak/Nie". Można to też bardziej szczegółowo (per model) dodać w MD w "Właściwości i cechy" jakąś kolumne "Nazwa wyświetlana" i "Separator". Też można to zamieścić w samej Właściwości obok Symbol/Nazwa/Opis. Proszę o info czy da się to aktualnie jakoś zrobić lub czy nadaje się to na funkcję w ramach nexo (czy raczej iść w rozwiązania własne i nie czekać).