Wojciech Szopiński

Problemem w Pana kodzie jest prawdopodobnie ta linia: parametryGrupowania.MetodaWyliczeniaCen = MetodaWyliczeniaCen.Brak; Powoduje ona, że ceny nie są w ogóle przepisywane z dokumentu realizującego i program wstawia tam po prostu aktualne ceny z cennika. Proszę zmienić ją na: parametryGrupowania.MetodaWyliczeniaCen = MetodaWyliczeniaCen.BezKonsolidacji; W zasadzie w przypadku braku konsolidacji pozycji: parametryGrupowania.MetodaGrupowaniaPozycji = MetodaGrupowaniaPozycji.BezKonsolidacji; Nie ma większego znaczenia, która metoda wyliczania cen zostanie ustawiona w parametrach grupowania - istotne jest żeby nie był to Brak. Inne metody wyliczania cen mają znaczenie gdy stosujemy konsolidację pozycji.

Domniemam, że rozwiązanie jest uruchamiane poprzez skopiowanie zawartości sdk do katalogu z rozwiązaniem własnym, a nie poprzez wgranie go do binariów podmiotu. Jeśli tak to czy wspomniany plik jest faktycznie skopiowany do katalogu z rozwiązaniem? Plik wnf.pak zawiera wzorce dla wydruków niefskalnych - czy domyślnym wzorcem jest w tym przypadku wzorzec niefiskalny?

Faktura wystawiona w konfiguracji własnego typu dokumentu ma dokładnie te same funkcjonalności co faktura wystawiona na podstawie typu wbudowanego. Innymi słowy - faktura z własnym typem dokumentu to dalej faktura. Tak. Należy skorzystać z menedżera IKonfiguracje: IKonfiguracje konfiguracje; IEnumerable<Konfiguracja> dostepneTypyDokumentow = konfiguracje .Dane .Wszystkie() .Where(k => k.Domyslna || k.KonfiguracjaBazowaId.HasValue) .ToArray(); Krótkie wyjaśnienie powyższego kodu: Konfiguracje wbudowane w program są oznaczone flagą "Domyslna = 1". Modyfikacja konfiguracji wbudowanej polega na utworzeniu jej kopii z symbolem konfiguracji wbudowanej poprzedzonym znakiem podkreślenia oraz identyfikatorem konfiguracji wbudowanej w polu KonfiguracjaDomyslna_Id. Jest to mechanizm, który pozwala na wprowadzanie zmian w ustawieniach konfiguracji wbudowanych tak aby zachować zmiany wprowadzone przez użytkownika. Konfiguracje własne (własne typy dokumentów) są tworzone zawsze na podstawie jakiejś konfiguracji wbudowanej i mają jej identyfikator wpisany w polu KonfiguracjaBazowaId. Wszystko jest w tabeli ModelDanychContainer.Konfiguracje.

Mimo wszystko jeszcze będę dopytywał - chodzi o wpisanie numeru całkowicie "z ręki" z pominięciem mechanizmu numeracji czy może chodzi o zmianę definicji numeracji "w trakcie wystawiania/edycji dokumentu"? Nie ma natywnego wsparcia dla obu przypadków, ale można się posiłkować pewnymi obejściami. W przypadku chęci wpisania numeru "z ręki" to nie ma możliwości zrobienia czegoś takiego: IDokumentSprzedazy dokument = ...; //... dokument.Dane.NumerWewnetrzny.PelnaSygnatura = "mój nowy numer"; Gdyż pole PelnaSygnatura jest generowane przez mechanizm numeracji i to spowoduje błąd. Można ten numer "ręczny" umieścić w polu własnym dokumentu lub w innym polu, które nie jest wykorzystywane - np. uwagi, podtytuł. Można również sferycznie wpisać go do istniejącego pola na dokumencie NumerZewnetrzny i od wersji 50 będzie można takie pole wyświetlić jako własną kolumnę w widoku dokumentów. Niestety ze względu na to, że dokumenty wystawiane przez użytkownika (w odróżnieniu od dokumentów wprowadzanych z zewnątrz takie jak faktury zakupu) nie mają natywnej obsługi pola NumerZewnetrzny więc nie będzie ono widoczne na formatce dokumentu. Jeśli chodzi o zmianę definicji numeracji w trakcie wystawiania bądź też jak Pan napisał: To również wprost się nie da gdyż konfiguracja musi być ustawiona raz na początku wystawiania dokumentu co powoduje, że dokument inicjalizuje się odpowiednimi parametrami - w tym też używaną definicją numeracji. Można skorzystać z własnych typów dokumentów i zdefiniować sobie osobny typ z inną definicją numeracji. Jeśli w Pana aplikacji zajdzie potrzeba zmiany typu dokumentu w trakcie jego wystawiania można po prostu zapamiętać dane wypełnione na dodawanym dokumencie (klient, pozycje etc), porzucić jego dodawanie (Dispose()) i dodać go od nowa w wybranej konfiguracji wypełniając go uprzednio zapamiętanymi danymi.

Zadam pytanie raz jeszcze:

Chodzi o podmianę domyślnej numeracji w parametrach czy podmianę numeracji w trakcie dodawania/edycji obiektu (dokumentu)?

Jak sam Pan zauważył: Tu jak rozumiem chodzi o brak możliwości wprowadzenia danych szczegółowych na ręcznie wpisanym adresie dostawy na dokumencie? Bo inne miejsca wpisywania adresu są wolne od tego typu ograniczeń.

Ogólnie adresy są przechowywane w kilku tabelach. Główny aktualny adres przechowywany jest w tabeli Adresy i jest tam zapisywany w formie liniowej. Każdy adres wpisywany do tabeli adresów jest również zapisywany w formie szczegółowej z podziałem na ulicę, miejscowość etc. w tabeli AdresySzczegoly. Wpisy głównej tabeli adresów są również historiowane (tzn. każda edycja adresu zapisuje nowy wpis historyczny) w tabeli AdresHistorie również w postaci liniowej. Dodatkowo w wersji 32 InsERT nexo zostało dodane historiowanie również adresów w postaci szczegółowej i od tej wersji po edycji adresu powstaje również wpis w AdresSzczegolyHistorie. Powyższy opis dotyczy obiektów, które mają powiązanie z encją typu Adres (tabela Adresy) - są to obiekty takie jak Podmiot, Magazyn, Oddział etc. Teraz przechodząc do obsługi adresów dostawy na dokumentach można rozróżnić dwa przypadki. Adres dostawy może być pobierany z jakiegoś zewnętrznego obiektu w systemie powiązanego z dokumentem (tzn. klienta, magazynu, oddziału etc). Wtedy na dokumencie w polu MiejsceDostawyTyp w tabeli Dokumenty jest ustawiona wartość z typu wyliczeniowego InsERT.Moria.Dokumenty.Logistyka.MiejsceDostawyTyp inna niż Reczny (64), a w polu MiejsceDostawyZewnetrzneId jest wskazanie na odpowiedni wpis historyczny z tabeli AdresHistorie. Zakładając, że mamy do czynienia z obiektem dodawanym w wersji późniejszej niż 32 to od tego wpisu w AdresHistorie można dojść do historycznego wpisu szczegółowego w tabeli AdresSzczegolyHistorie (obiekty dodawane PRZED wersją 32 nie mają wpisu historycznego ze szczegółami). Dodatkowo takie powiązanie adresem dostawy powoduje, że dokument nie może takiego adresu edytować - jest on możliwy do zmodyfikowania tylko poprzez obiekt, którego ten adres dotyczy. Szczególnym przypadkiem adresu dostawy na dokumencie jest adres wpisany ręcznie (MiejsceDostawyTyp = InsERT.Moria.Dokumenty.Logistyka.MiejsceDostawyTyp.Reczny = 64). Wtedy w tabeli Dokumenty w odróżnieniu od powyższego przypadku adresu "zewnętrznego" jest tworzony nowy wpis historyczny w tabeli AdresHistorie, który NIE ma powiązania z głównym adresem (AdresHistorie.Adres_Id IS NULL), a także nie tworzy się dla niego wpis historyczny w tabeli AdresSzczegolyHistorie. Taki adres wpisany ręcznie na dokumencie jest już możliwy do modyfikacji tylko i wyłącznie od strony dokumentu, który go stworzył. Teraz spróbuję odpowiedzieć na postawione przez Pana pytania: Ciężko tutaj powiedzieć jaki jest dokładnie powód takiego stanu rzeczy, ale może mieć na to wpływ to co napisałem wcześniej - obiekty "zewnętrzne" (klient, oddział, magazyn etc), z których został pobrany adres dostawy zostały dodane do nexo PRZED wersją 32 i dla nich po prostu w tej tabeli nie ma odpowiedniego wpisu. W takim przypadku proszę spróbować edytować np. klienta z którego został pobrany adres, zmienić "coś" w adresie, zapisać i wystawić na tego klienta nowy dokument - wpis w AdresSzczegolyHistorie powinien się pojawić. Jeśli nie to będziemy potrzebowali więcej szczegółów do przeanalizowania tego przypadku. To nie zadziała. Dokument z adresem wpisanym ręcznie tworzy jak wspomniałem wcześniej wpis w tabeli AdresHistorie BEZ powiązania z adresem głównym (Adresy) tym samym nie ma możliwości powiązania go z rekordem w AdresSzczegoly. Nie zadziała również sferyczna próba podłączenia do utworzonego na dokumencie adresu dostawy wpisu w AdresSzczegolyHistorie z prostego powodu - dokumenty po prostu nie mają zaimplementowanej obsługi parsowania adresu liniowego na szczegóły.

Numeracja operuje w obrębie jednego "obiektu numerowanego" i nie śledzi zmian w obiektach powiązanych. Powinien zadziałać plugin sfery zdarzeniowej reagujący na zdarzenie po zapisie dokumentu, w którym edytujemy dokumenty automatyczne i korzystając z metody ZarezerwujNumer() wymuszamy nadanie numeru z uwzględnieniem nowego numeru dokumentu nadrzędnego.

A sprawdzał Pan na najnowszej wersji nexo? Ta jest już dość "archiwalna". Jeszcze raz ponawiam prośbę o: Może być w wiadomości prywatnej. Czy w Subiekcie pozycje zamówienia są oznaczone jako częściowo/w całości zrealizowane? Jaki jest stan realizacji takiego zamówienia w Subiekcie? Czy na dokumencie realizującym jest widoczne powiązanie z zamówieniem? Proszę jeszcze podesłać zrzuty ekranu z zamówienia oraz dokumentu realizującego (zakładka podstawowe oraz powiązania).

Rozumiem, że dokładnie to samo rozwiązanie uruchamiane na wersji 36.0.2 po zapisie dokumentu realizującego (jak rozumiem zmienna dok jest dokumentem sprzedaży lub wydaniem zewnętrznym?) powoduje, że na zakładce powiązania w zamówieniu jest widoczny utworzony dokument, a na wersji 38.0.1 już nie? Czy sprawdzał Pan na aktualnej wersji nexo? Jedyne co mi przychodzi do głowy to dalsze operacje na pozycjach - jeśli te pozycje, które zostaną utworzone poprzez WypelnijNaPodstawie zostaną usunięte i później dodamy te same pozycje na nowo to takie zachowanie jest normalne gdyż realizacja opiera się na pozycjach i usuwając pozycje odłączamy dokument realizujący od realizowanego. Czy mógłby Pan podesłać większy kawałek kodu?

Jeśli chce Pan zachować "procent" płatności przy przewalutowywaniu dokumentu wystarczy przed zmianą waluty ustawić odpowiedni tryb przeliczania: using (IZamowienieOdKlienta zamowienie = zamowienia.Znajdz(...)) { zamowienie.Platnosci.TrybPrzeliczania |= TrybPrzeliczaniaPlatnosci.PrzeliczanieWgProcentu; // zmiana waluty } Warto jednak wspomnieć, że w przypadku gdy zmienia Pan walutę na dokumencie z już dodanymi pozycjami to samo ustawianie jej tak jak to zostało opisane w przytoczonym wątku może być niewystarczające gdyż wtedy NIE zostaną przeliczone odpowiednio ceny na pozycjach więc będziemy mieli "pomieszane różne systemy walutowe". Można wtedy skorzystać z metody Przewalutuj, która przelicza również odpowiednio ceny na pozycjach: ILinieKursowWalut linieKursow = sfera.LinieKursowWalut(); var linia = linieKursow.Dane.Wszystkie().Where(...).FirstOrDefault(); using (IZamowienieOdKlienta zamowienie = zamowienia.Znajdz(...)) { Waluta usd = sfera.Waluty().DaneDomyslne.USD; Waluta pln = waluty.DaneDomyslne.PLN; zamowienie.Platnosci.TrybPrzeliczania |= TrybPrzeliczaniaPlatnosci.PrzeliczanieWgProcentu; zamowienie.ObslugaWaluty.Przewalutuj( // ustawiana waluta: usd // wybrana linia kursów walut: , linia // kurs na wybrany dzień: , linieKursow.Dane.PobierzKursNaDzien(linia, usd, pln, zamowienie.Dane.DataWprowadzenia) , true , null , null); if (!zamowienie.Zapisz()) zamowienie.WypiszBledy(); }

Można dodać szablon "na podstawie asortymentu wzorcowego":

Nie ma takiej możliwości.

Najlepiej jest skorzystać z szablonów projektów dla Visual Studio. Proszę spojrzeć do dokumentacji SDK w sekcji Pierwsze kroki -> Szablony projektów dla Visual Studio gdzie opisana jest instalacja szablonów. Kompilując projekt utworzony na bazie jednego z szablonów (tutaj najlepiej wybrać oczywiście szablon "Sfera zdarzeniowa") jest tworzony automatycznie instalator rozwiązania, którym można łatwo wdrożyć swoje rozwiązanie na bazie nexo.