Grzegorz W.

Jedyna rzecz której nie próbowałem... Faktycznie, zamieniłem kolejność i działa. Dzięki za szybką pomoc

Dzień dobry Tworzę sobie zamówienia od klienta przez Sfere, według przykładów w SDK. Ustawiam sposób dostawy: SposobDostawy sposob = sposobyDostaw.Dane.Wszystkie().Where(m => m.Id == 5).FirstOrDefault(); result.Dane.SposobDostawy = sposob; Gdzie result to wcześniej utworzone zamówienie: IZamowienieOdKlienta result = zamowienia.Utworz(konfiguracja); A sposób dostawy pobieram tak: ISposobyDostaw sposobyDostaw = this.Sfera.Manager<ISposobyDostaw>(); Gdzie Sfera.Manager to wrapper do PodajObiektTypu return this.sfera.PodajObiektTypu<T>(); Wszystko działało pięknie i ustawiało mi w zamówieniu sposób dostawy, jednak po aktualizacji do wersji 30 przestało działać. Przypisanie jest ignorowane (w tabeli "Dokumenty" SposobDostawyId jest nullem). Wcześniej wszystko ładnie działało. Podejrzewam, że ma to związek z aktualizacją i zmianami w sposobach dostawy - po aktualizacji można ustawiać domyślne sposoby dostawy; więc pewnie coś się zmieniło. Debugowałem przez Console.WriteLine() w różnych częściach kodu; tak SposobDostawy istnieje (w moim przypadku o Id==5 jest to Kurier DPD). Próbowałem nadpisywać ten domyślny sposób w konfiguracji, bez skutku. Dzięki z góry za pomoc

Witam. Chciałbym odświeżyć temat. Podobnie jak przedmówca - mamy problem z pojawiającymi się ujemnymi wartościami w kolumnie Rezerwacja Dostaw, co automatycznie przekłada się na błędne wskazania w kolumnie Niezarezerwowane (np. stan = 5, RD = -2, Niezarezerwowane = 7). Problem pojawia się z tego co zauważyliśmy w chwili, gdy zmieniamy status ZK na Anulowane/Zrealizowane (np. z ZK zrealizowane 3 z 4 pozycji czyli wygenerowane WZ, 4 pozycja została przez klienta anulowana, zatem zmieniamy status ZK na ANULOWANE/ZREALIZOWANE tak, aby rezerwacja została zwolniona na tą 4 pozycję - tak się jednak nie dzieje i stan w kolumnie RD przyjmuje wartość ujemną równą ilości nie zrealizowanej pozycji 4 z ZK). Pytanie - co robimy źle i jak poprawić obecne stany w w/w kolumnach do poprawnych wartości. Dodam jeszcze, iż próbowaliśmy już odszukania ZK i zmiany jego statusu na R jednak to tylko połowiczne rozwiązanie, gdyż owo ZK pojawia się wówczas w zamówieniach do realizacji - jego ponowna zmiana do statusu Z lub A powoduje powrót do punktu wyjścia. Zmiana statusu na R i usunięcie niezrealizowanej pozycji z ZK, po czym przywrócenie ZK statusu A lub Z także nie przynosi efektu. Z góry dziękuję za wszelką pomoc w rozwiązaniu problemu.

Tak, opcja dla nowo wygenerowanych dokumentów zaznaczona jest domyslnie. Logi przesłane na priv.

Tak - efekt tożsamy z opisanym przez przedmówcę. U nas odbywa się to w dwóch momentach: - w chwili pojawienia się okna DRUKUJ i zdefiniowania w nim wszystkich parametrów - kliknięcie OK powoduje pojawienie się "biegających" kropeczek, a po kilku chwilach program zawiesza się - lub po przejściu w/o etapu - pojawia się widok zdefiniowanego szablonu wiadomości i w tym momencie program zwisa i wyłącza się

Dołączam do zapytania. Wg. naszych obserwacji problem może leżeć po stronie szablonów wiadomości?

Po licznych próbach niestety dochodzimy do wniosku, że problem lezy po stronie aktualizacji. W ustawieniach konta pocztowego sprawdzanie konfiguracji przeróżnych serwerów pocztowych zawsze kończy się niepowodzeniem i komunikatem "podana konfiguracja serwera poczty wychodzącej jest niepoprawna" lub "nieprawidłowa nazwa użytkownika lub hasło" . Co zastanawiające - przed aktualizacją wszystko funkcjonowało poprawnie na tych samych danych. Czy problem może leżeć po stronie starszej i dawno nie aktualizowanej wersji Gestora Pro? Próbowaliśmy już wszystkiego łącznie z uruchomieniem programu bez Gestora Pro (sam Subiekt Nexo Pro). Dorzucam plik z logami. KlientPoczty-20190711.log

Po aktualizacji Subiekta Nexo Pro do wersji 26.0.1 (posiadamy również Gestora - ostatnia aktualizacja z kwietnia 2017) zauważyliśmy problem związany z wysyłką powiadomien np. dla scenariuszy windykacyjnych za pośrednictwem wbudowanego klienta pocztowego. Przed aktualizacją wysyłka powiadomień dla wspomnianych scenariuszy odbywała się bezproblemowo - zaznaczaliśmy dany dokument, z menu kontekstowego wybieraliśmy wykonaj działanie i automatycznie wiadomość e-mail z powiadomieniem była wysyłana na wskazany (domyślny dla danego klienta) adres. Po aktualizacji - wszystkie wiadomości tego typu lądują w Skrzynce nadawczej i tam już pozostają. Czy ktoś z forumowiczów miał styczność z takim problemem i znalazł jego rozwiązanie. Z góry dziękujemy za odpowiedzi.

Podłączamy się pod temat. Ostatni kurs, jaki Subiekt Nexo pobrał nam automatycznie pochodzi z dnia 22.03.2019. Od tej daty (tj. w dniach 25,26,27,28) Nexo się obraziło i nie chce pobierać kursów walut. Nie ma żadnych błędów w dzienniku (BL), brak zdublowanych tabel kursowych, wykonywany restart synchronizacji z kontem Insert, przebudowana baza danych (program serwisowy), konfiguracja dokumentów sprawdzona, konfiguracja systemowa dotycząca automatycznego pobierania sprawdzona - obie bez zmian od kilku miesięcy. Nadal bez efektu. Co ciekawe jeszcze kilkanaście dni temu, w przypadku problemu z pobieraniem kursu, na górnej belce programu pojawiał się komunikat o błędzie - na chwilę obecną nie pojawia się wcale. Pomaga tylko ręczne pobieranie kursu, co wydaje się być średnim rozwiązaniem w zestawieniu z działającym jeszcze do niedawna pobieraniem automatycznym. Czy ktoś z forumowiczów ma pomysł na rozwiązanie problemu? Z góry dziękuję za wszystkie propozycje.

Poszukuję sposobu na rozwiązanie poniższego problemu: W module WYDANIA, dla dowolnego dokumentu WZ definiujemy sobie wygląd listy asortymentu (rodzaju i ilości kolumn). Czynimy to dla jednego z użytkowników (w tym przypadku z uprawnieniami admina). I teraz kluczowe pytanie - jak zduplikować takie ustawienie widoku asortymentu dla pozostałych użytkowników systemu nexo (aby każdy z nich miał dokładnie taki sam wygląd dla listy asortymentów na edytowanym dokumencie WZ)? Ustawienie w/w dla jednego użytkownika (admina) i skopiowanie wpisu bezpośrednio w bazie danych (tabela WidokiSerwisowe) niestety nie przenosi tego widoku na innych użytkowników. Z góry dziękuję za wszelakie sugestie.

Dziękujemy za informację - metoda działa.

Chcielibyśmy zasugerować dodatkową funkcjonalność w zakresie grupowania pozycji asortymentu wg. jego cech (dla KONFIGURACJA WIDOKU --> GRUPOWANIE --->Cecha). Wydaje się, iż byłoby to mocne usprawnienie pozwalające na utworzenie różnych zakładek dla asortymentu (np. z różnych grup) i przypisanie kilku cech do danej grupy - co w efekcie pozwoliłoby na występowanie jednej pozycji asortymentowej w kilku grupach jednocześnie. Obecnie takie rozwiązanie możliwe jest tylko poprzez dodanie słowników własnych, co jednak ma (przynajmniej takie wrażenie odnieśliśmy) znaczący wpływ na szybkość działania np. Instynktu.

Mamy taki problem. W wersji 20.01. subiekta nexo dostępna była możliwość edycji dokumentu WZ powiązanego z wystawionym dokumentem sprzedaży (czyli najpierw powstaje FV, do której z automatu tworzony jest dokument powiązany w postaci WZ). Po aktualizacji do wersji 20.1 już tej możliwości nie ma (pojawia się kłódeczka z informacją: "nie można edytować dokumentu magazynowego powiązanego z dokumentem handlowym). Była to o tyle przydatna w naszym przypadku możliwość, iż wykorzystując pole opis pozycji, po wystawieniu FV i automatycznym wygenerowaniu powiązanej z nią WZ-tki, magazyn mógł zaedytować dokument WZ i w polu opis pozycji dodać np. numery seryjne wydawanych produktów. Czy gdzieś w ustawieniach możliwe jest cofnięcie w/w blokady?

Wszystko już jasne - kolejne wersje następujące po 14.2.0 wprowadzały nową funkcjonalność pozwalająca z widoku użytkownika (mającego przydzielone własności administratora) definiować elementy widoku dla poszczególnych użytkowników (czyli powstała funkcja obsługiwana już z poziomu użytkownika programu, którą wcześniej trzeba było realizować ręcznie, przekopując "po nocach" bazę danych w opisanym post wcześniej zakresie i kopiując mozolnie wszystkie nastawy widoków administratora do pozostałych użytkowników ). Ponieważ w wyniku tego ręcznego dodawania powstawały "sztywne" wpisy z odniesieniem do określonych ID wpisów oznaczonych jako bazowe, były one rozpoznawane przez aktualizację jako nie posiadające prawidłowych powiązań/przypisań w bazie (wszyscy użytkownicy mieli na sztywno przypisane odwołania do ID widoków administratora, co standardowo chciały wprowadzić kolejne aktualizacje). Zatem - podczas aktualizacji bazy danych program wypluwał w pewnym momencie przedstawiony komunikat. Usunięcie z bazy danych wszystkich wpisów dla innych niż dotyczących administratora widoków (oznaczonych dodatkowo tagiem NULL i ustawionych jako widok bazowy) automatycznie rozwiązało problem i spowodowało, iż niejako domyślnie widoki administratora zostały przez program przypisane samodzielnie do pozostałych użytkowników. uff...

Dziękujemy za zainteresowanie rozpoczętym tematem i cenne uwagi, które w znacznym stopniu naprowadziły nas na trop. Sytuacja wstępnie opanowania - problem tkwił w bazie danych - ModelDanychContainer.WidokiSerwisowe. Jakiś czas temu definiowaliśmy sobie widoki dla poszczególnych użytkowników systemu i ręcznie dodawaliśmy kolejne wpisy w bazie przypisując je do ID użytkownika. Zapewne na tym etapie powstały jakieś błędy. Pomogło wykasowanie wpisów dotyczących wszystkich użytkowników z wyjątkiem tego posiadającego uprawnienia administratora systemu. Zgłębimy jeszcze temat bardziej szczegółowo w zakresie które ze wspomnianych wpisów powodowały błędne odwołania do kolumny ID i postaramy się podzielić zdobytą wiedzą.