Skocz do zawartości
Forum użytkowników

Ernest Sadowski

Użytkownik
  • Ilość treści

    24
  • Rejestracja

Reputacja

3 Neutral
  1. 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).
  2. 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ć.
  3. 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?
  4. 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?
  5. 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.
  6. 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ż!
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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ę!
  12. 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)?
  13. 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.
  14. 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!
  15. 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.
×