Ernest Sadowski

1. Na wzorcu wydruku tak* (edycja zaawansowana wzorca i napisanie tabeli, która liczy co trzeba - dodam, że będzie to BARDZO trudne zrobić poprawnie samemu). * Nie ma to sensu. Zaraz będzie KSeF i tabele i tak będą robione tak jak przewiduje rząd (odsyłam do formatu KSeF). 2. Ponownie - na wzorcu się da to zrobić (łatwo) edycją zaawansowaną. I ponownie ten sam problem co wyżej z KSeF - należy się zastanowić czy jest sens.

EDIT Proszę wejść w typy dokumentów, wybrać dokument i zakładka sposobu wyliczania cen.

Czy da się użyć typ noty (obciążeniowa / uznaniowa) jako warunek? Poniższe nie przechodzi:

Nic tylko czekać. Moje zalecenie: Używać tylko dokumentów RW z zdefiniowanym odbiorcą i podpinać je do FS po fakcie. Na WZ jako koszt czekamy... Inne podejście: Utworzyć nowy typ dokumentu (laboratorium) z RW i nazwać go np. "WZ kosztowa" - będzie tym samym co RW, ale lepiej się "oddzieli" od normalnych RW i nie będzie się gubić/mylić.

Czy planowane jest wprowadzenie edytora/wsparcia HTML dla OE? RTF jest trochę (bardzo) meh, poza tym HTML jest pozbawiony problemów z renderowaniem do różnych dokumentów, jest web-ready i dosyć łatwo go wdrożyć w UI nexo (bo już w kilku miejscach macie - co prawda są "słabe", ale są). Zaznaczam, że chodzi mi o edytor w oknach ofert, ponieważ nexo już jest zdolne do robienia HTML: Edycja zaawansowana wzorca i użycie pola tekstowego z "Allow HTML tags". Problem w tym, że teraz trzeba pisać HTML w innym programie i kopiować source do nexo. Alternatywnie naprawcie RTF.

Chcieliśmy zacząć w większym stopniu używać pól RTF w ofertach Gestora ale są one obarczone problemem eksportowania do PDF. Ku mojemu braku zaskoczenia - nie jestem jedynym z problemami: W tym temacie jednak poruszam 2 kolejne problemy - eksportowanie do PDF w niektórych przypadkach: odcina zawartość RTF renderuje dodatkowe puste pole na końcu obrazu RTF Mówiąc "obraz RTF" odnoszę się do obrazu umieszczanego na PDF (ponieważ RTF jest renderowane do obrazu zamiast do tekstu). Poniżej przykład wzorca wydruku standardowego (zmieniłem tylko tło pól RTF żeby było widać) na wersji 48.1.0. Błędy: Informacje wstępne - w RTF są 2 linijki, na PDF widzimy puste pole pod (jest to część obrazu RTF). Wariant 2 - w RTF jest jeszcze jedna linijka "TEST WARIANT 2". Na PDF została obcięta. Zjawisko nie jest związane z wariantem, a (chyba) z zawartością RTF. Informacje końcowe - w RTF są 2 linijki, na PDF widzimy puste pole pod. Wyraźnie się tu nakłada kilka problemów, moje obserwacje: Przy Wydruk->Podgląd nie zachodzi obcinanie "TEST WARIANT 2" i RTF jest tekstowy. Przy Wydruk->Podgląd -> Zapisz jako... PDF (z podglądu Stimulsoft) zachodzi obcinani i RTF jest tekstowy. Przy Drukuj do pliku (PDF) zachodzi zarówno obcinanie jak i renderowanie RTF do obrazu (nie tekstowe). Dodatkowe puste pole za RTF zachodzi w każdym przypadku. Coś jest nie tak w narzędziach eksportu PDF - pytanie czy to biblioteki czy zależne od środowiska.

Problem nie jest po stronie odczytu PDF przez samego Adobe, a przy tworzeniu obrazu RTF umieszczanego w pliku PDF przy eksporcie. Obraz RTF wygenerowany na podstawie danych z bazy przez nexo/Stimulsoft jest niskiej rozdzielczości. Sprawdziłem kilka innych programów do czytania PDF wygenerowanych w nexo i rozdzielczość nadal jest słaba - RTF renderowane są do obrazów o niskiej jakości (nie jest to wina ich czytania). EDIT: Stimulsoft sobie radzi z eksportem RTF. Jeżeli użyjemy Wydruk->Podgląd (Stimulsoft) i ręcznie wyeksportujemy do Adobe PDF to RTF wyeksportuje jako normalne pola tekstowe. W przypadku eksportu za pomocą Drukuj->Zapisz do folderu (PDF) pola RTF są konwertowane do obrazów o niskiej rozdzielczości. Ponadto:

W autotekstach mamy dostęp do podstawowego adresu email i telefonu opiekuna klienta oraz kontakty opiekuna oferty umieszczone na dokumencie oferty jako lista. No właśnie - "jako lista" jest tu kluczowe, bo <<kontakt opiekuna oferty>> wypluwa je po przecinku i bez spacji. Czy można prosić o wprowadzenie jakiegoś licznika <<kontakt opiekuna oferty (1)>> aby można było budować bardziej czytelne emaile? Alternatywnie proszę o wprowadzenie: <<podstawowy email opiekuna oferty>> <<podstawowy telefon opiekuna oferty>>

Czy coś źle rozumiem mechanizm i sens tego czy to błąd?

Ręcznie z pomocą serwisanta. A szkoda. InsERT powinien wprowadzić funkcję "czyszczenia" bazy "do zera" (z obiektów nie-kartotekowych). Można to jednak także zrobić ręcznie - skasować wszystkie wystawione dokumenty i inne obiekty oprócz kartotek, wykonać konserwację i bam - mamy prawie czystą bazę. Problem w tym, że sporo spraw blokuje się wzajemnie i taki proces może trochę potrwać.

A pytanie po co? Czy na pewno jest sens ruszać coś wstecz? Nie wystarczy sprawdzić zgodność i pracować w przód na nowych numeracjach?

A nie może Pan po prostu edytować pola płatności faktury? Edycja faktury zapłaconej gotówka sprawi, że po edycji skasują się dokumenty kasowe i rozrachunki i powstanie nowy rozrachunek należności z np. tytułu przelewu odroczonego. Jest to scenariusz wyjątkowy i zasługuje na wyjątkowe traktowanie. Edycja faktury (a właściwie jej pól nieobowiązkowych) jest całkowicie na miejscu. Można to opisać dalej np. w uwagach, lub wewnętrznie w module komentarzy i wystosować też odpowiednie pismo do klienta (oraz podłączyć załącznik do obiektu).

Na fakturze nie ma obowiązku umieszczania sposobu płatności, a jedynie sumę należności z jej tytułu. Jeżeli na oryginalnej fakturze znajduje się taka informacja, to jest to bardziej wskazówką i nie należy tej wskazówki traktować jako część faktury. Tym samym edycja po stronie wystawcy jest absolutnie na miejscu, ponieważ kluczowe obowiązkowe dane są nadal takie same, a zmieniają się jedynie elementy dodatkowe. Co ja bym robił to zmienił po prostu sposób płatności i przedłożył nowy PDF klientowi z notatką, że jest to jedynie zmiana sposobu płatności, a nie samej faktury. W swoim systemie klient nie ma potrzeby jej wprowadzać jako osobny dokument, a jedynie zmodyfikować odpowiednio sposoby płatności czy rozrachunki. Inne pytanie jest jednak o KSeF - nie patrzyłem na sposoby mapowania płatności (o ile w ogóle jest), ale zainteresowałem się teraz, bo faktycznie, czy wtedy KSeF musi także otrzymać skorygowane dane nieobowiązkowe (takie jak płatności i inne pola dodatkowe)? Czy możemy wtedy wysłać tylko zedytowany PDF do klienta?

Ciężka sprawa. Może korekta PZ zwracająca wszystko co się nie sprzedało, zafakturowanie tego co zostało , a tego co nie ponowne przyjęcie nową PZ? Pytanie jak dużo towarów i jak często fakturują. Inna opcja to wprowadzanie FZ z blokadą przyjęcia magazynowego (czyli bez powiązania z PZ), ale to też słabe.

Jak najbardziej, u nas to standardowe zjawisko i nigdy się nie przyczepili. Jedyne co robimy to oznaczamy pod koniec msca, że luki zaistniały. Znacznie poważniejszym problemem są duplikaty numerów - to od razu przyleci kontrola. Lukami się tak bardzo nie interesują. Ponadto dodam od "strony IT" opinię: Świat, czego również dowodem jest sam KSeF, dąży do pozbycia się sygnatur "naturalnych" (klucze/numeracje naturalne/biznesowe) na rzecz unikalnych kluczy syntetycznych - czym w tym przypadku są numer faktur KSeF (nadawane przez system zewnętrzny). Większą wagę i właściwie jedyną będą miały rzeczy faktycznie wysłane do KSeF, niż symbole jakie nadamy im osobiście, bo po wejściu w życie KSeF - tylko takie będą się liczyć (przynajmniej w handlu PL). Numeracje naturalne były dla porządku i możliwości weryfikacji - ta potrzeba (istnienia ciągłości) staje się coraz mniej potrzebna, gdy w grę wchodzi weryfikacja zewnętrzna KSeF. Pomijam, już, że niektórzy (firmy) numeracje mają per-pracownik (księgowy) i jest to zupełnie legalne. Widziałem także numeracje oparte o systemy base16 i base32 - nie było z tym problemu.

Opiszę 3 rzeczy: W bazie danych są faktyczne dane. W widoku (program) są pokazywane dane z bazy. Na wydrukach są pobierane dane z bazy i umieszczane "na papierze" na podstawie wzorców wydruku. (Nie ma zatem związku widoku w nexo z tym co na papierze) Jeżeli chce Pan ukryć Rabaty tylko "na papierze" to należy edytować wzorzec wydruku (proszę wpisać w wyszukiwarkę nexo "Szukaj poleceń" w górnym lewym rogu). Aby edytować wbudowane wzorce należy je wpierw powielić. Aby usunąć odpowiednią kolumnę z wzorca wystarczy ją skasować z pozycji kolumn przy edycji.

Domena i Hosting a VPS i Dedyk to różne sprawy. Potrzeba conajmniej VPS (a najlepiej Dedyk) i na nim normalnie wszystko poinstalować jakby było stacjonarnie. Trochę konfiguracji zabezpieczeń i hop (ale to bym powierzył komuś kto ogarnia). Dedyki WinSrv są bardzo drogie, dlatego sugeruję zacząć od VPS WinSrv gdzie można załapać się od tysiaka do kilku tys. rocznie (pod Nexo raczej minimum kilka). Koniec końców to WSZYSTKO sprawa budżetu i od tego powinien Pan zacząć jak chce porady. EDIT: Ano i uwaga - praca z nexo zdalnie jest BARDZO uciążliwa (opóźnienia). Zwykle się pracuje na RDP (wymaga trochę konfiguracji na wielu użytkowników i dużo zasobów = drogi serwer), aczkolwiek prosto do bazy danych tez można się łączyć (mniej zasobów bo nexo biegają wtedy na komputerze użytkownika). Co ja bym sugerował to prywatny serwer w firmie do z którym można pracować na LAN (po kablach i szybko), a dodatkowo dostęp do niego zewnętrzny zdalny dla innych aplikacji itp.

ZK są kijowe dla celów produkcyjnych, bo nie umieją robić RW+PW jak ZM/ZR. Aczkolwiek dla Pana Marka, możliwe, że wystarczy sama realizacja przez RW (bez PW). EDIT: Chciałbym jednak zaznaczyć, że jestem jednocześnie wielce zadowolony ostatnimi (v47 i v48) nowościami w nexo i w Laboratorium. Side quest: Ja standardowo "pushuje" swoje propozycje rozwoju programu pod budowanie oprogramowań (rozszerzeń / pluginów / rozwiązań własnych) związanych z produkcją i wzbogacaniem towaru, dla których potrzebne jest wprowadzenie czegoś jak sugerowałem w temacie niżej, czyli nowego podtypu dokumentów produkcyjnych, które nie mają ograniczeń typów przyjmowanych i wydawanych asortymentów/usług:

Efektem ZM jest jeden KT (nie TW czy US), z wielu składników (to już dowolne). Efektem ZR jest wiele "składników" z jednego KT. EDIT: Odpowiadając wprost na Pana pytanie - nie da się tak zaadaptować, ale ja również liczę na "oswobodzenie" konfiguracji dokumentów produkcyjnych. Side quest: Jako składniki ZM można używać usługi, problemem jest fakt, że nie wliczają się one do wartości magazynowej powstałego kompletu (bo usługi mają 0 koszt magazynowy). Do ZR nie specjalnie jest jak (bo nie da się rozmontować na usługę). Ja osobiście czekam na możliwość doliczania wartości usługi (wzbogacanie) do wartości magazynowej tworzonego kompletu.

Samo konto, tj. SMTP/IMAP - być używane jestem niemal pewien że tak (ale klient pocztowy w zakresie podstawowym). Natomiast jego użytkowanie będzie okrojone (bo bez włączonego Gestora, a tym samym jego licencji na stanowisku gdzie jest włączony - nie ma się dostępu do wszystkich funkcji klienta pocztowego). EDIT: Najlepiej spróbować. Teoretycznie do użytkowania więcej niż 1 konta pocztowego potrzebna jest licencji Gestora. Natomiast ta potrzeba tylko występuje przy edycji konta pocztowego, a nie jego użytkowaniu. Do czego na pewno potrzeba Gestora to do użytkowania pełnego klienta poczty.

Proszę odpalić multiprogram z Gestorem. Musi być włączony aby licencja Gestora była "używana". Wtedy zadziała.

Mamy: Traktowanie jako Materiał do pozycji (tylko do usługi) Dodanie (do dowolnej pozycji) kosztów dodatkowych z RW Problem, jakiego wciąż nie jesteśmy rozwiązać "schludnie" to gdy coś zostanie wydane WZ, ale nie ma podstaw żeby to zafakturować. W idealnym świecie są RW, które zawsze są kosztem czegoś, a jeżeli trzeba je zafakturować, to można stworzyć US na FS i podpiąć te RW do pozycji. Można te podpięcia robić zarówno do US, ale też i innych TW czy KT. Tutaj jest wszystko ok i wygodne, bo te RW można podpinać po fakcie wystawienia dokumentu handlowego. Z WZ natomiast jest problem. Jak coś pójdzie z zamysłem sprzedaży, ale okaże się później (czy to przez błąd, czy dodatkowe ustalenia), że będzie to zawarte w cenie czegoś, to jest dylemat. Jeżeli dokument handlowy powstaje po WZ, to można tą WZ rozliczyć następującym dokumentem FS traktując pozycje WZ jako materiał. Nie działa to natomiast, jeżeli na FS nie ma żadnej usługi (bo nie może wtedy być materiałów, czyli trochę inaczej niż z kosztami dodatkowymi jak z RW). Nie działa to także wstecznie - jeżeli dokument handlowy jest już wystawiony. Problem (z widocznością) takich wiszących WZ został częściowo "załatany" funkcją ZMIANA STATUSU FAKTUROWANIA: Nie. Ta łatka jednak nie pozwala na odpowiednie podpięcie pozycji z WZ do żadnych innych dokumentów/pozycji, więc dużo nie rozwiązuje. Aktualnie jedyna droga to wystawienie KWZ do zera, po czym RW tych samych pozycji i podpięcie RW jako dodatkowy koszt pozycji FS. Czy są już jakieś plany albo czy potrzeba opisana wyżej jest wystarczająca, żeby tłumaczyć wprowadzenie dodatkowej funkcji, która dla WZ oznaczonych jako Nie podlega fakturowaniu - nexo traktowałby je podobnie jak RW i wyświetlał jako opcja w wyborze na liście kosztów dodatkowych pozycji dokumentów handlowych.

W typach dokumentów można zmienić domyślną strategie zmiany statusu przy realizacji (pełnej). Można by to także połączyć z własnym typem dokumentu (własny typ ZK) i mieć różne strategie dla różnych typów ZK. O ile o to chodzi:

Od v47 można drukować z "Drukuj naklejki z asortymentem rozbitym na partie" z wyborem danych partii. Brakuje jednak możliwości drukowania naklejek z asortymentem z poziomu widoku Dokumentu -> Asortyment. Brakuje także możliwości "Drukuj naklejki z asortymentem rozbitym na partie" z poziomu widoku Dokumentu -> zakładka Partie. Pewnie w temacie chodzi o to 1. U nas bardziej liczą na to 2.

Autorem pliku jest program, a wiec pośrednio Autor tego programu. Jeżeli plik by nie był tworzony przez program, to by sugerowało ręczne pisanie, co zaprzecza założeniu "Autor nie możliwości ingerencji w plik komunikacji". Niemniej jednak - należy zwrócić się do autora programu/pliku dlaczego nie tworzy wg przyjętych standardów/schematów.