Skocz do zawartości

Michał Fułat

Użytkownik
  • Liczba zawartości

    17
  • Rejestracja

  • Ostatnia wizyta

Ostatnie wizyty

Blok z ostatnimi odwiedzającymi dany profil jest wyłączony i nie jest wyświetlany użytkownikom.

Michał Fułat's Achievements

0

Reputacja

  1. Witam, Podczas próby wydruku dokumentu z wybranego wzorca w trybie "EKO" otrzymuję błąd: Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = "InsERT.Moria.Wydruki.IWydrukEKO", name = "(none)". Spróbowałem wykonać test wzorca metodą Wybrobuj() i otrzymałem następujący komunikat: Unhandled Exception: Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = "InsERT.Moria.Wydruki.IWydrukEKO", name = "(none)". Exception occurred while: while resolving. Exception is: InvalidOperationException - The current type, InsERT.Moria.Wydruki.IWydrukEKO, is an interface and cannot be constructed. Are you missing a type mapping? ----------------------------------------------- At the time of the exception, the container was: Resolving InsERT.Moria.Wydruki.IWydrukEKO,(none) ---> System.InvalidOperationException: The current type, InsERT.Moria.Wydruki.IWydrukEKO, is an interface and cannot be constructed. Are you missing a type mapping? at Microsoft.Practices.ObjectBuilder2.DynamicMethodConstructorStrategy.ThrowForAttemptingToConstructInterface(IBuilderContext context) at InsERT.Mox.Runtime.Unity.ReflectionBuildPlanPolicy.BuildUp(IBuilderContext context) at Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp(IBuilderContext context) at Microsoft.Practices.ObjectBuilder2.StrategyChain.ExecuteBuildUp(IBuilderContext context) at Microsoft.Practices.Unity.UnityContainer.DoBuildUp(Type t, Object existing, String name, IEnumerable`1 resolverOverrides) --- End of inner exception stack trace --- at Microsoft.Practices.Unity.UnityContainer.DoBuildUp(Type t, Object existing, String name, IEnumerable`1 resolverOverrides) at Microsoft.Practices.Unity.UnityContainer.Resolve(Type t, String name, ResolverOverride[] resolverOverrides) at Microsoft.Practices.Unity.UnityContainerExtensions.Resolve[T](IUnityContainer container, String name, ResolverOverride[] overrides) at Microsoft.Practices.ObjectBuilder2.DeferredResolveBuildPlanPolicy.ResolveTrampoline`1.Resolve() at System.Lazy`1.CreateValue() at System.Lazy`1.LazyInitValue() at System.Lazy`1.get_Value() at InsERT.Moria.Wydruki.Base.WydrukServices`1.get_WydrukEKO() at InsERT.Moria.Wydruki.Base.Wydruk`2.PobierzWzorzec(Int32 id) at InsERT.Moria.Wydruki.Base.Wydruk`2.PobierzWzorzec(WzorzecWydruku WybranyWzorzec) at InsERT.Moria.Wydruki.Base.Wydruk`2.Podglad(TDoc obiektDoDrukowania) at InsERT.Moria.Wydruki.Base.Wydruk`2.Wyprobuj(WzorzecWydruku wzorzec, Boolean eko) at InsERT.Moria.Wydruki.WzorceWydruku.Wyprobuj(WzorzecWydruku wzorzecWydruku, Boolean eko) I tutaj pojawia się pytanie, czy jest jakiś problem w nexo z tymi wydrukami czy może należy je obsłużyć w jakiś szczególny sposób, inny niż wzorce "nie-eko"? Wersja nexo 32.1.0. Pozdrawiam, Michał
  2. Przeglądając dokumentację z Subiekta 1.63 SP2 HF1 nie widziałem odpowiednich funkcji, ale faktycznie po podniesieniu wersji biblioteki widzę, że są one dostępne. Ważna nauka na przyszłość, żeby nie patrzeć tylko w dokumentację. Dziękuję za pomoc!
  3. Witam Czy w związku z wchodzącymi od 1 października zmianami przepisów dla JPK VAT, czyli: https://www.insert.com.pl/dla_uzytkownikow/e-pomoc_techniczna/5701.html planowane jest wprowadzenie w sferze możliwości ustawiania oznaczeń dla JPK VAT? Czy pozostaje nam wrzucać to bezpośrednio po SQL-u? Pozdrawiam, Michał
  4. Zmieniłem ustawienia uruchomienia tak aby wyświetlić okna GT przed zapisem. Na screenie 1240 widać dostawy w dyspozycji po wykonaniu metody Dysponuj - i jest to prawidłowe, wybrana jest dostawa z kodem SMARTFON_2 w cenie nabycia 970 PLN. Screen 1241 to widok całego dokumentu dodawanego przez sferę - przed zapisem. Tutaj również widać, że wybrana jest poprawnie dostawa z kodem SMARTFON_2, cena nabycia 970. Natomiast po zapisie pozycja dokumentu wygląda jak na screenie w poprzednim poście - nie ma widocznej wybranej dostawy, ale cena nabycia ustawiona na 980 PLN sugeruje, że GT wybrało dostawę z kodem SMARTFON_1, której cena nabycia to właśnie 980. Co więcej, jeśli na takiej pozycji spróbuję ręcznie z poziomu GT zadysponować towar, to otrzymam rezultat jak na screenie 1242 - Subiekt automatycznie wpisze mi kod dostawy SMARTFON_1.
  5. Witam Chciałbym poprzez sferę GT wybrać towar z konkretnej dostawy i umieścić go na dokumencie sprzedaży. Uruchomienie odbywa się na bazie demo z aktywnym niebieskim i czerwonym plusem oraz sferą. Wersja 1.63 SP2 HF1. Analizując log aplikacji wszystko przebiega prawidłowo: w toku procesowania dokumentu wyszukiwany jest towar który umieszczany jest na dokumencie (poprawnie), są nadawane mu podstawowe informacje (stawka vat, cena, inne - wszystko poprawnie) ale problem pojawia się przy próbie zadysponowania towaru z konkretnej dostawy. Teoretycznie cały proces przebiega poprawnie: zaczynam od wywołania SuDokumentyManager.PodajDostepneDostawy, dostaję prawidłowe dane o dostawach, odnajduję pozycję po kodzie i w momencie jej znalezienia wywołuję Dysponuj. Po wykonaniu PodajDyspozycje() otrzymuję prawidłowo wybraną dostawę. I teraz pojawia się problem: dokument jest dalej procesowany, zapisany - żadnych błędów, wszystko przechodzi. Ale w GT nie widać wybranej przeze mnie dostawy (screen) - tak jakby funkcja Dysponuj w ogóle jej nie przypisała. Czy ktoś mógłby potwierdzić występowanie tego problemu? Wybór towaru wykonuję na bazie dokumentacji sfery a jedyną różnicą jest to, że pomijam funkcję WyswietlDyspozycje, ponieważ jest to aplikacja konsolowa i nie wyświetla żadnych okien dla użytkownika. Michał
  6. Rozumiem, faktycznie coś takiego ma miejsce... czyli nexo jakby zakłada, że podając numer oryginału to my jesteśmy osobą przyjmującą dokument i go "odbieramy", a klient jest jakby "wystawcą" tegoż dokumentu zamówienia. Okej, powiedzmy że wszystko jest jasne, dzięki!
  7. Sytuacja następująca: dodajemy przez sferę dokument zamówienia klienta. Z jakiegoś powodu po dodaniu dokumentu, gdy otwieram go w nexo, pola osoby wystawiającej i odbierającej są zamienione. Dla jasności: nie mam na myśli wybranych na tych polach wartości (to można by tłumaczyć błędną logiką aplikacji). One są zamienione kolejnością w ogóle. Przykładowo wrzucam dwa screeny: Capture1218 przedstawia ZK utworzone w UI nexo (poprawne), Capture1217 w sferze (niepoprawne). Jakby tego było mało, niepoprawne zamówienie podświetla pole odbiorcy (tak jakby sugerowało, że jest błędne?) a po rozwinięciu listy pojawiają się pracownicy firmy, czyli zawartość odpowiednia dla pola wystawił. Natomiast w polu wystawił mogę wprowadzić dowolny tekst, czyli odpowiada to polu odebrał. Osoby odbierająca i wystawiająca są w kodzie ustawiane tylko w jednym miejscu i w następujący sposób: zk.Dane.WystawilaOsoba = podmiot.Osoba; zk.Dane.OdebralaOsoba = klient.Osoba; Gdzie podmiot i klient to prawidłowe obiekty typu Podmiot. Co może powodować takie zachowanie nexo?
  8. Czy w Sferze Subiekta GT jest możliwość obsługi kompensat? Nie mogę nigdzie tego znaleźć, chciałbym wykonać usunięcie kompensaty z bazy. FinManager pozwala usunąć cesję, ale to jedyne co widzę w dokumentacji. Jeśli nie ma takiej możliwości to czy planowane jest jej wprowadzenie?
  9. Całego kodu niestety nie mogę udostępnić, ale postaram się jeszcze w tym tygodniu przygotować specjalną testową aplikację która powinna wygenerować ten sam błąd i kod tej aplikacji przekażę w wiadomości prywatnej.
  10. No właśnie to jest zabawne, bo nasz sposób przetwarzania zamówień opiera się na danych adresowych pobieranych z kontrahenta - nigdy ręcznie nie ustawiamy adresu na samym dokumencie. Dlatego bardzo zdziwiło mnie to, że nexo wymaga podania tego adresu. Na tę chwilę zastosowałem pewien workaround, przed samym zapisem dokumentu w nexo zmieniam MiejsceDostawyTyp na MiejsceDostawyTyp.Domyslny i dodatkowo MiesceDostawy ustawiam na null - to rozwiązało problem i adres pobierany jest poprawnie za każdym razem (z kontrahenta). Ciekawi mnie jedynie, dlaczego tak się dzieje, problem wydaje się być losowy, nie mogę znaleźć miejsca, które by za to odpowiadało, bo tak jak wspomniałem, nigdy nie podajemy adresu bezpośrednio na dokumencie, zawsze jest pobierany z kontrahenta.
  11. Strzał w dziesiątkę - faktycznie, ten obiekt na zamówieniu w którym występuje błąd nie jest ustawiony. Jednak pozostaje pytanie, dlaczego tak się dzieje? Od czego zależy to, czy nexo ustawi samo MiejsceDostawy, czy też nie? Każdy dokument jest przetwarzany tak samo, każdy kontrahent posiada adres główny i adres "do wysyłki", więc dlaczego w jednym przypadku wszystko działa prawidłowo, a w innym nexo wymaga wprowadzenia tego ręcznie? I dlaczego taki problem nie występuje przy dodawaniu zamówienia w samym nexo dla tego samego kontrahenta?
  12. Jako uzupełnienie dodam jeszcze, że po wyrzuceniu błędu sprawdziłem jeszcze adresy ustawione na dokumencie zamówienia: 1. Adres płatnika 2. Adres odbiorcy 3. Adres nabywcy 4. Adres mojej firmy 5. Adres kontrahenta I każdy z tych adresów posiada ustawiony prawidłowo obiekt Panstwo i można odczytać wszystkie informacje. Nie wiem dlaczego przy użyciu sfery nexo zwraca ten błąd.
  13. Witam, mam problem podczas dodawania dokumentu sprzedaży poprzez sferę. Po wypełnieniu danych i wywołaniu funkcji Zapisz pojawia się informacja: Nie ustawiono powiązanego obiektu. na polach: AdresHistoria.Panstwo. Co może powodować takie zachowanie nexo? Problem występuje tylko przy niektórych kontrahentach, którzy teoretycznie niczym się od siebie nie różnią, tj. mają oczywiście swoje adresy i każdy z nich ma wypełnione pole Państwo (zweryfikowałem do dodatkowo w samym programie korzystającym ze sfery), ale nic ich szczególnie nie wyróżnia, a jednak problem występuje. Dodając dokument przez program wszystko działa - błąd występuje tylko gdy używam sfery.
  14. Witam Podczas próby usunięcia paragonów (PA, PAI) w GT poprzez Sferę, dostaję błąd: -2147217634: Operacja nie powiodła się. Należy ponowić próbę. Dzieje się tak chyba dla wszystkich paragonów w programie. Usunięcie jest możliwe jedynie poprzez Subiekta (wtedy działa wszystko prawidłowo), ale w Sferze dostaję powyższy błąd. Problem dotyczy tylko paragonów, inne dokumenty usuwają się prawidłowo. W czym może być problem? Jak go rozwiązać?
  15. Powracam jeszcze raz do tematu przepisywania płatności na dokumentach, z ZK na FS, PA, PI itd. Po zastosowaniu się do tej porady, faktycznie przepisywanie płatności zadziałało na moim nexo, problem w tym, że to chyba nie jest jedyne ustawienie, które jest wymagane aby funkcja działała. Zastosowałem powyższe na bazie produkcyjnej, tj. włączyłem metody płatności na ZK, a mimo to przepisywanie nie działa. Dokładnie wygląda to tak, że ustawiając parametry grupowania płatności na 'Przepisz', płatności z ZK wogóle przestają być widoczne (zk.PlatnosciDokumentow jest puste, nic tam nie ma). Nie przenoszą się automatycznie i nie można ich też odczytać, aby przepisać je na dokument sprzedaży. Natomiast jeśli parametry grupowania ustawię na brak przepisywania płatności, to wtedy płatności na ZK-ach są widoczne i mogę je wpisać na dokumenty sprzedażowe. Problem w tej sytuacji jest jednak to, że takie działanie generuje w nexo podwójne dokumenty KP - jeden dla zamówienia, drugi dla FS/PA/PI itd. Nie wiem jak mógłbym tego uniknąć bez użycia funkcji przepisania automatycznego. Tak jak wspomniałem powyżej, na obu bazach - developerskiej i produkcyjnej - włączone są płatności na zamówieniach.
×
×
  • Dodaj nową pozycję...