Ernest Sadowski

Rozwiązanie własne (Sfera) z wywoływaczem synchronizującym dane z plików na serwerze do tabel bazy danych. Ja osobiście bym w 2 stronę robił. Napisać aplikację tak (ta która używa HTMLa później), żeby czytała z bazy danych Subiekta.

Wiem co się zmieniło. Klient miał kiedyś Gestora w wersji trial 45 dni. Zrobił se 2 konta pocztowe - ich re-autoryzacja działa tylko gdy jest multiprogram z Gestorem. Mniejsza o to i tak. Mam tych licencji nakupionych kilka, to strzeliłem aktywację na podmiocie i elo... Wyrzucone pieniądze, bo i tak nie skorzysta, no ale cóż.

Działały 2 konta pocztowe bez licencji latami (oba były aktywne w nexo, autoryzowane na IMAP i SMTP przez OAuth2 do MS365) Nagle jest ten komunikat. Przy edytowaniu mogę unieważnić i autoryzować ponownie - to się powodzi. Jak spróbuję zapisać po zmianach to mam błąd z tematu. (w uwagach do błędu jest tak jak w tytule tematu) No to stwierdziłem, że dezaktywuje jedno z kont ("OC" na rys. 1). Po zdezaktywowaniu "OC" - drugiego ("Faktury") nadal nie da się edytować (daje ten sam błąd). Ponadto nie da się z powrotem aktywować OC (z tym samym błędem) Koniec końców - nie mogę autoryzować "Faktury", bo gada, że są 2 konta. Nie mogę też aktywować "OC", bo gada, że są 2 konta. Nie chce kasować konta, bo wtedy zgubi powiązania do maili. Na pewno nie było jakiejś zmiany? Wcześniej tego nie było...

Problem pojawił się chyba w v47. Mam klienta, który pracuje bez Gestora. Do tej pory miał zdefiniowane 2 konta pocztowe. Niedawno wygasł token OAuth2, ale z racji na błąd z tematu - nie jest możliwa ponowna autoryzacja (nexo nie pozwala zapisać nowo autoryzowanych tokenów). Czy ta zmiana (blokada do max. 1 konta) była gdzieś zapowiedziana? Jeżeli nie to prosiłbym o umożliwienie autoryzowania istniejących już kont pocztowych. Jeżeli tak - czy trzeba kupić Gestora?

Nie jestem pewny gdzie leży problem. W Bank->Wypłata można wprowadzić (lub wczytać z eksportu banku) przelew na danego kontrahenta. Przelew bankowy tworzy rozrachunek, który można podpiąć pod fakturę jako przedpłatę do FZ lub jako rozliczenie przez skojarzenie do rozrachunku tworzonego przez FZ. Chyba na prawdę nie rozumiem co chcecie zrobić lub osiągnąć, bo powyższe wydaje się zbyt oczywiste żeby było rozwiązaniem.

Nie rozumiem sensu logicznego wykonywania przedpłat za już wystawione przez kontrahenta faktury zakupowe. Są to wtedy po prostu płatności. Przedpłaty natomiast mają pro formy i zamówienia, na których podstawie dopiero wystawia się fakturę. Pod faktury zakupu jako przedpłaty trzeba wybrać rozrachunki sprzed daty wystawienia tych faktur. W przeciwnym wypadku - jest to płatność odroczona, a nie przedpłata, którą się dalej po prostu rozlicza w rozrachunkach wieloma np. przelewami (także przez skojarzenie). Na ZD (zam. do dostawcy) podpinać można rozrachunki "przedpłat" i później przy realizacji ZD na FZ (także zaliczkowe) - te płatności podpina się do przedpłat FZ.

W przypadku wyboru osoby z przedstawicieli (CRM), a nie wpisana ręcznie - sugeruję dodać coś podobnego jak w przypadku danych firmy (nieedytowane pole). (gdzie "Kierownik działu zaopatrzenia" to pole "Uwagi" przedstawiciela) Oczywiście pole mogłoby być wyłączone w konfiguracji widoczności pól. Sugestia dotyczy wszystkich dokumentów. Na ten moment, żeby wyszperać te dane trzeba wejść w kontrahenta i CRM - nieporęczne.

1. Przeprowadzić konserwację bazy, w tym przebudowę indeksów (Program serwisowy nexo). 2. Sprawdzić latency (opóźnienie) na warstwie fizycznej - to, że po kablu wszystko, nie znaczy, że działa szybciej niż choćby WiFi. Spotkałem się z takimi syfiastymi instalacjami, że płakać się chciało od ilości niepotrzebnych bramek albo ich złej jakości (routery opóźniające pakiety, kable pociągnięte przy liniach napięcia). 3. Zakupić licencję SQL Server która zoptymalizowana jest pod większe bazy.

No to czekamy. Chodziło mi o to, że gdy pozycje już są rozchodowane i opis partii jest zablokowany to naturalnym krokiem było by je wycofać na magazyn (poprawić dokumenty rozchodu), zmienić opis a następnie wydać ponownie. Strategia jest "do przeżycia" dla 1-3 dokumentów, ale gdy np. ZM jest odpowiedzialne za wprowadzenie na stan 100 kompletów, które rozchodowane są później przez 50 dokumentów w okresie kolejnych miesięcy, to nie ma opcji, żeby to sobie wycofać i poprawić opis. Na ten moment wprowadzę w takim razie dodatkowe pole własne partii "Opis produkcja", który będzie można swobodnie manipulować zanim zdejmiecie blokadę.

Pole "Opis dostaw" na dowolnie innych dokumentach przyjęć (PZ/PW) można edytować nawet po rozchodach (można też edytować ilości w partiach, gdy jest ich wiele, które nie są jeszcze rozchodowane, ale to już do ZM/ZR nie potrzeba raczej). Na ZM/ZR tego się nie da robić jeżeli są rozchodowane. Wycofywanie ruchu magazynowego jest możliwe z 1 dokumentu, ale nie z np. 10. Proszę o odblokowanie edycji tego pola. Dodatkowo zwracam uwagę na pola własne partii - nie wiem czy są edytowalne po rozchodzie, ale jeżeli nie to także powinno to być możliwe lub konfigurowalne.

Ponaglam zgłoszenie - od czasu kiedy zaczęliśmy korzystać z bardziej rozwiniętych rozwiązań własnych opartych o dokumenty własne od wersji 47, fakt istnienia tego błędu stał się bardzo uciążliwy - to co widzimy w interfejsach nexo na zleceniach produkcyjnych jest inne niż to co widzą na papierze (dokumenty).

Rodzaj na ten moment jest czymś dla samego działania programu (pewnie w przyszłości się pojawi opcja własnych typów, tak jak ostatnio wprowadzone dokumenty własne) - nie da się tworzyć własnych. Można prosić o info po co? Bo pewnie można to zrealizować polem własnym albo cechą/grupą/działem.

Gdzieś coś jest nie tak przy ruchach MW/MP, bo po takim przeniesieniu w zakładce informatora mamy coś takiego (gdzie oryginalne na MW jest 1600 szt. tej samej partii): Zwracam uwagę na fakt, że w Dostawach powstaje wiele partii z tego samego ruchu (przyjęcia) o różnych ilościach. Nie jest to jedyny taki przypadek. Zjawisko zaobserwowałem dla wielu towarów i ich partii. Kiedy bug się pojawia, to zawsze jest w podobnej formie, mianowicie, dla N ilości partii przenoszonego towaru, przyjęte zostają partie: 1 szt. N - 1 szt. Lub tak jak na zał. obrazie: 1 szt. N - K - 1 szt. K szt. Zjawisko jest o tyle dziwne, że po usunięciu dokumentu i wykonaniu ponownie takiego samego przesunięcia - powstają takie same partie (ilości). Co jeszcze dziwniejsze - przy późniejszym wydawaniu tych partii na WZ/RW w oknie wyboru partii (ctrl+R) - są one pokazane jako jedna dostawa (N szt.), a nie tak jak w zakłądce informatora (zał. obraz). Gdzieś w nexo coś robi "inaczej" w bazie - albo na poziomie przyjmowania oryginalnych partii, albo przy samych MW/MP (bo tylko przy takich ruchach namierzyłem problem). Oprócz denerwującego dziwnego podziału w informatorze wszystko wydaje się działać ok, ale ten bug jest bardzo mylący dla magazynierów.

Chyba zależy od branży mocno. Przy wykonaniach urządzeń/maszyn i innych podobnych "na zamówienie" bardzo często są zadatki. Co prawda zwykle opisywane w załącznikach/umowach, ale nadal pomyślałem, że może jako, że "zadatek" jest dokładnie zdefiniowany w KC to jest to coś co mogłoby być funkcjonalnością nexo. Co prawda faktycznie nexo używa na wzorcach "minimalna wpłata", którą można dalej opisać w uwagach jako zaliczka lub zadatek, ale taki pomysł rzuciłem. Ja to rozwiązuje (kilka razy wdrożyłem) tak jak opisałem.

Jest na co liczyć w 2024? Bo jak nie to zrobię pole własne do pozycji dokumentu z datą lub booleanem (CzyMaTerminRealizacji), ale wolałbym, żeby to było wspierane przez samo nexo.

Ja to rozwiązuje polem własnym boolean (CzyZaliczkaToZadatek) i wzorcem wydruku co to łapie i zmienia tekst, ale nie myśleliście żeby dodać to do programu (dodatkowy boolean przy zaliczce minimalnej)? Spodziewałbym się, ze to dosyć częsta potrzeba użytkowników.

W 1 firmie: Używane do raportów i integracje, nie ruszamy tego, wartości pozycji mają być po prostu równe magazynowym (wyjątkiem błąd zaokrąglenia) i tyle. Nie będę wykłócać, bo w tym przypadku tak - jest to poważny problem bo wyszedł po czasie. A wyszedł po czasie bo jest to BUG - algorytm dla każdego innego dokumentu działa jak powinien, a dla MP nie. Proszę nie sprzedawajcie mi tego jako nieznajomość programu etc. bo ja to wiem (że lepiej używać magazynową), ale pozostaje fakt, że program się zachowuje inaczej dla różnych dokumentów. W 2 firmie: A czy da się ustawić żeby wartość pozycji i dokumentu była zawsze 0,00 bez ręcznego poprawiania wszystkiego na 0,00 (bo program zawsze skądś bierze wartości i wstawia nie-zerowe ceny, czy to ewidencyjnej, czy innych źródeł)? Gdyby się dało zawsze 0,00 ustawić to nie byłoby wtedy to mylące dla użytkowników. Później pojawiają się raporty - każdy inny, bo jedni używają wartości magazynowych a inni wartości pozycji/dokumentu. EDIT: Ogólnie to trochę zachodzę w głowę dlaczego pola cen/wartości na dokumentach wewnętrznym (ZPM/ZPR i MW/MP) są edytowalne - nie lepiej je zablokować na 0 i nie pokazywać? Przez to, że nie są przyblokowane później właśnie takie raporty o nie oparte serwisanci piszą...

Proszę w takim razie wyjaśnić jeszcze czym jest "w dyspozycji" na MP, bo przecież wybrane zostało 450 szt. na MW. Na MW, PZ, RW i wszystkich innych dokumentach wydających "Średnia ważona z dostaw w dyspozycji" wylicza cenę poprawnie, wagowo po wybranych partiach. MP tego nie robi, mimo, że bazuje na MW. Jedyna różnica jaką widzę to, że MP jest "wyjątkowe" bo to przyjęcie, a nie wydanie. Ale przecież ceny mógłby pobierać z auto-MW.

Ceny/wartość/koszt magazynowy to jedno. Działa pewnie tak jak powinno (tylko pewnie trochę różnie zaokrąglenia liczy, ale to grosze). Mi chodzi o wartości pozycji i przeliczanie dokumentu - tak, używamy tego i zależy nam na tym żeby przeliczone były dokumenty i były równe kosztom magazynowym. Po przeliczeniu MP po "Średnia ważona cena z dostaw w dyspozycji" i wybraniu dostawy (450 szt.) - cena netto na pozycjach "Asortyment" powinno się wyznaczyć na 11,05(...) PLN, bo wyliczona powinna zostać po Cenie nabycia (W) w oknie partii. Nie dzieje się tak - cena zostaje wyznaczona po "Średnia ważona cena z istniejących dostaw" (10,9538 PLN). Mówiąc wprost - Wybór "Średnia ważona cena z dostaw w dyspozycji" w MP używa algorytmu: "Średnia ważona cena z istniejących dostaw" (uśrednia wszystkie dostępne dostawy, zamiast tych wybranych). Jest to na 100% bug.

Zmieniając między algorytmami i wymuszając przeliczenie dotarłem do wniosku jak w temacie. EDIT: Dla jasności - problem zachodzi w przypadku generowania MP z auto-MW. Wartości na MP (i auto-MW) są wtedy "Średnia ważona cena z istniejących dostaw" (przy wybraniu "z dostaw w dyspozycji") W przypadku wydania pierwotnego MW - działa algorytm "Średnia ważona cena z dostaw w dyspozycji" i pozycje mają poprawne wartości. EDIT 2: W przypadku wpierw wygenerowania MW z "z dostaw w dyspozycji" (działa) i później wykonania przyjęcia MP - ceny są poprawnie przepisane. Jeżeli jednak ponownie (wymusimy) przeliczymy na MP wg "z dostaw w dyspozycji"' - błąd pojawia się tak jak z MP + auto-MW. Wniosek prosty - okno MP niepoprawnie wybiera faktyczny algorytm po wybraniu go z listy. --- Nexo dla dokumentów MP nie rozróżnia między 2 algorytmami i zawsze podaje "Średnia ważona cena z istniejących dostaw" (testowałem na wielu dostawach o różnych wartościach oraz liczyłem ręcznie). Ten błąd jest ABSURDALNIE duży i nie chcę myśleć jak wiele ruchów MW/MP (a więc całej wartości magazynu) przez to mamy "za przeproszeniem". Proszę o szybką interwencję i wgranie poprawki w trybie hotfix.

Od 3 lat czekam i nadal zachodzę w głowę dlaczego InsERT nie zabierze się za rozszerzenie wsparcia bankowości on-line o przynajmniej dosłownie 3 największe banki w Polsce: PKO BP Pekao SA Santander Bank Polska Więcej niż połowa firm z jakimi mam do czynienia korzysta właśnie z nich. Już pomijam, że top 2 wyżej wymienione to Polskie banki (nie sugeruje tu jakiegoś patriotyzmu, czy "naszego podwórka", ale możliwe powinno to ułatwić sprawę integracji?). Jedyne natomiast wdrożone to : mBank (Niemcy) BNP Paribas (Francja) ING Bank Śląski (Holandia) Pomyśleć można, że albo te wdrożone same się postarały o integrację z insERT (czyt.: płacą InsERTowi za utrzymanie), albo te 3 największe olewają InsERTa (trudności z integracją), w drugą stronę (InsERT ich nie lubi?), lub oba... (???) To powinien być tak samo ważny feature jak emaile w Gestorze czy kasy fiskalne (prawie). Mamy 2023 rok.

Krótka odp.: Nie Dłuższa: Google Dodatkowo napomnę, że różne programy (klient) pocztowe różnie renderują HTML (i niektóre kiedyś (dekady) pozwalały na skrypty, co było dziurą w security). Dodatkowo umieszczanie skryptów w wiadomościach może być odfiltrowywane przez zabezpieczenia samego serwera pocztowego i zostanie Wasza skrzynka oflagowana jako zło i maile skasowane.

Sam korzystam, działa: Może to przez polskie znaki?

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.

<<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>