Piotr Widliński

Update. Producent przestał odpisywać w zgłoszeniu serwisowym. Także, jak widać, każda sprawa może mieć swój finał w czeluściach matrixa. Do niedawna byłem ambasadorem firmy, co skutecznie się zmieniło po tym zdarzeniu. Nie polecam. Strach myśleć, co mogło by się stać, w przypadku błędów w module księgowym/finansowym?

Właśnie taką informację dostałem w swoim zgłoszeniu. Proszę zwrócić jednak uwagę na fundamentalną sprawę - zgłoszenie dotyczy wady oprogramowania, a nie nowej funkcjonalności, która ma się pojawić na wiosnę. W oparciu o wyłączoną w aktualizacji funkcjonalność został zbudowany nasz podstawowy proces biznesowy. To jest sedno tego wpisu. Rozumiem, że mogą pojawić się błędy w nowych wersjach (aktualizacjach), jednak po to producent buduje swoje wsparcie techniczne, oraz relacje z klientami, mającymi aktywny kontrakt serwisowy, aby aktywnie reagować na tego typu zdarzenia. Mam nadzieję, że teraz jasno wytłumaczyłem sprawę. Proszę o naprawienie zgłoszonej wady w trybie serwisowym.

Wątek dotyczy sposobu postępowania ze zgłoszeniami. Sytuację opisałem dosyć jasno. Po aktualizacji, przestała działać poprawnie jedna z podstawowych dla nas funkcji i mimo zgłoszenia tego problemu, oraz świadomości, że zmiana nie była awizowana w aktualizacji, nie dostaję rozwiązania. Nie tak wyobrażam sobie wsparcie techniczne. Wątek założyłem po ponad tygodniu korespondencji z działem technicznym w tej sprawie. Przesyłam zrzut ekranu obrazujący działanie na moim asortymencie.

Podam przykład, który nie ma zastosowania u mnie, ze względu na specyfikę asortymentu, jednak powinien zobrazować sprawę. W wersji 24 można było utworzyć model w taki sposób: Reebok - 41, a od wersji 25 włącznie Reebok - Rozmiar - 41. Gdzie 41 to nazwa cechy, a Rozmiar to nazwa właściwości asortymentu.

Dzień dobry Chcę napisać w tym miejscu o problemie ze wsparciem technicznym. Zapewne miałem pecha trafić na jakąś niekompetentną osobą, jednak nie mam na to żadnego wpływu i liczę, że może w tym miejscu otrzymam potrzebną pomoc. Do rzeczy. Wykonałem aktualizację z wersji 24 do wersji 37. Po aktualizacji okazało się, że funkcja aktualizacji opisu asortymentowego przestała działać w sposób jaki działała wcześniej. Po zgłoszeniu do działu technicznego dostałem odpowiedź, że funkcja ta została wyłączona w wersji 25.00 i że do tej pory nikt nie zgłaszał z tym problemu. W odpowiedzi napisałem, że właśnie ja zgłaszam problem i że mam zbudowany słownik cech całego asortymentu w oparciu o funkcjonalność, która została wyłączona i proszę o jej włączenie - na co otrzymałem odpowiedź, że włączenie tej "funkcjonalności" jest przewidywane w wersji planowanej na przyszły rok. Na moją odpowiedź, że jest to błąd uniemożlwiający pracę, oraz, że usunięcie tej funkcjonalności nie było w liście zmian nowych wersji, jak też żądanie poprawienia tej wady, nie dostałem już odpowiedzi. Spodziewam się wyższych standardów od tej zacnej firmy - stąd próba rozpoczęcia konstruktywnej dyskusji w tym temacie.

Zastanawiam się nad zagadnieniem/możliwością ustawienia różnych cen zakupu na ten sam produkt u jednego dostawcy dla różnych klientów (coś w rodzaju inforekordów w SAP). W tej chwili można ustawić w asortymencie tylko jedną cenę zakup u producenta/dostawcy i jest to pewnego rodzaju ograniczenie. Dodatkowo można byłoby też zaimplementować tam skale - czyli cena uzależniona od zamawianych w zleceniach ilości. Może w wersji 17 lub 18 udało by się to zaimplementować?

Postanowiłem napisać temat, w którym moglibyśmy się podzielić przydatnymi skryptami SQL. Na początek coś nad czym pracowałem ostatnio - poszukiwanie asortymentu przypisanego (lub nie przypisanego) do danej cechy. select Asortymenty.[Symbol] ,Asortymenty.[Nazwa] ,Asortymenty.[Opis] from [ModelDanychContainer].[Asortymenty] ,[ModelDanychContainer].[WlasciwosciAsortymentu] ,[ModelDanychContainer].[WlasciwoscAsortymentuCechyAsortymentu] ,[ModelDanychContainer].[CechyAsortymentu] where [ModelDanychContainer].[CechyAsortymentu].Nazwa = 'tutaj wpisujemy nazwę cechy' and Asortymenty.Id = WlasciwosciAsortymentu.Asortyment_Id and WlasciwosciAsortymentu.Id = WlasciwoscAsortymentuCechyAsortymentu.WlasciwoscAsortymentu_Id and WlasciwoscAsortymentuCechyAsortymentu.CechyAsortymentu_Id = CechyAsortymentu.Id Mam nadzieję że taki wątek okaże się przydatny. Zachęcam innych do dzielenia się wiedzą.

i jeszcze jedna informacja - aby wyprowadzić numer zamówienia (zewnętrzny) na wydruku pozycji w Formularzu WZ, należy użyć takiej kombinacji: {Dokument.Pozycje.encjaPozycji.PozycjaZrodlowa.PozycjeRealizowane.PozycjaRealizowana.Dokument.NumerZewnetrzny} Trochę się tego naszukałem - może się komuś przyda.

Bardzo dziękuje za przekazaną informację. Uprzejmie proszę o opracowanie dedykowanego patcha, chyba że wersja 16 ma wejść jakoś na dniach.

Okazuje się, że problem jest poważniejszy niż na początku myślałem. Oto szczegóły: Jeżeli przypiszemy np. po trzy cechy z pięciu właściwości, zapiszemy indeks a następnie po jakimś czasie chcemy zmienić jedną z cech np. usuniemy, to opis asortymentu zmienia się w losowy sposób (niezgodnie z jakimkolwiek wyborem, alfabetem itp.) - co więcej, po usunięciu źle sortujących się cech z danej właściwości i ponownym ich przypisaniu, nazwa asortymentu zbudowana z cech w obrębie danej właściwości również jest budowana/zmieniana losowo. Dodatkowo, podczas edycji jednego indeksu (sortymentu) w ZK, w innych indeksach, które nie są edytowane, również zmienia się losowo opis asortymentu, który wcześniej był dobry. To wygląda na błąd programu - w moim przypadku tworzenie opisów na podstawie właściwości i cech ma kluczowe znaczenia dla całego (długiego już) projektu. Bardzo proszę o pilną pomoc.

Witam i dziękuję za odpowiedź. Ad1. Oczywiście, zgłaszałem to - choć moje sugestie były inne niż obecna funkcjonalność. Od wersji 15 nie działa sortowanie alfabetyczne - coś się zmieniło i nie ma tego w liście zmian - proszę o pilne przywrócenie poprzedniej funkcjonalności, gdyż cała koncepcja została napisana pod starą (sortowanie alfabetyczne cech przypisanych/w obrębie danej właściwości). Ewentualnie wyobrażam sobie opcję w programie, która sterowałaby zachowaniem się funkcji aktualizującej opis asortymentu (nowy i stary sposób) Ad2. Dziękuję za informację - będę czekał cierpliwie na poprawkę. Uprzejmie proszę o pomoc.

Podczas tworzenia asortymentu na podstawie modelu pojawiają się następujące błędy: Dla wybranych cech (kilku) w ramach jednej właściwości, funkcja aktualizująca opis asortymentu działała wcześniej w kolejności alfabetycznej a w tej chwili (prawdopodobnie od wersji 15) według kolejności wybrania danej cechy w "konfiguratorze" . Nie pomaga wywołanie ręczne funkcji "Aktualizuj opis według modelu, właściwości i cechy" W tym samym miejscu - po wywołaniu funkcji "Aktualizuj właściwości modelu" (w menu podręcznym modelu podczas tworzenia asortymentu), wszystkie właściwości zmieniają swoje miejsce i opis asortymentu zmienia się losowo po każdym jej wywołaniu. Uprzejmie proszę o pilne sprawdzenie tego, gdyż właśnie mieliśmy wystartować z systemem po długim czasie opracowywania koncepcji nazewnictwa cech (sortowanie alfabetyczne). Pozdrawiam,

Przepraszam za zamieszanie - już sobie poradziłem z tym błędem:)

Dzisiaj mam niespokojny dzień. Podczas próby przekształcenia zamówienia u dostawcy pojawia mi się dziwny błąd: "Nie udało się znaleźć domyślnej formy płatności dla dokumentu" Co dziwne - wcześniej działało to bez zarzutu. Bardzo proszę o jakieś wskazówki.

Bardzo dziękuje za szybką odpowiedź. Zgadzam się że nie powinno być dwóch takich samych asortymentów z identycznymi cechami, natomiast ciężar sprawdzenia tego przesunąłbym na moment próby zapisania takiego asortymentu - wszak o to chodzi w powielaniu: powielamy, modyfikujemy np. jedna cechę, a następnie zapisujemy. Pozdrawiam

Dzień dobry, Podczas wywołania funkcji powielania asortymentu zbudowanego na podstawie modelu, sam model nie kopiuje się. Dodatkowo, po skopiowaniu asortymentu i podczas wskazania prawidłowego modelu, do właściwości przepisują się tylko cechy z dwóch pierwszych właściwości asortymentu. Uprzejmie wnioskuję o naprawienie tego (Subiekt wersja najnowsza 15)

Ad1. Ctrl + strzałki niestety też działają na tej liście. Mam ogromną prośbę do producenta o pomoc w zwiększeniu ilości przypisanych właściwości do modelu. Rozumiem że nie może to być nieograniczona ilość, jednak 16 właściwości to zdecydowanie za mało.

Dzień dobry. W Subiekcie nexo chciałem zacząć używać tej wspaniałej funkcjonalności, jaką jest model asortymentu i budowanie opisu asortymentu, na podstawie przypisanych do modelu właściwości. Właśnie wczoraj zakończyłem wielotygodniową pracę koncepcyjną nad stworzeniem pierwszego modelu i ku mojemu zaskoczeniu okazało się, że do modelu można przypisać tylko 16 właściwości. W związku z tym mam pytanie, w jaki sposób można zwiększyć ilość możliwych do przypisania właściwości do modelu? Dodatkowo, podczas pracy z modelami asortymentowymi, zauważyłem pole do kilku drobnych ulepszeń w modelach: Możliwość swobodnego przypisywania kolejności właściwości modelu (np. przesuń w górę/w dół). Obecnie, w aby dodać właściwość pomiędzy inne, trzeba usunąć wszystkie właściwości i przypisać je na nowo. Właściwości modelu - w przypadku wyboru kilku cech z danej właściwości, opis i/lub nazwa asortymentu buduje się w kolejności alfabetycznej danych cech z pojedynczej właściwości - przydałaby się możliwość określenia konkretnej kolejności. Właściwości - podpowiedź dla wyszukania cechy z listy po naciśnięciu pierwszego znaku cech - obecnie pozostaje wybór z dość długiej listy. Możliwość wyboru znaku rozdzielającego w budowanym przez Subiekta opisie/nazwie asortymentu pomiędzy poszczególnymi właściwościami asortymentu - obecnie jest to kropka.

W mojej ocenie wersja runtime może występować w dwóch wersjach - per core jak i per server/user - w każdym przypadku może to być wersja standard. To co oferuje Insert, zależy pewnie od ich umowy z Microsoft. Wersja runtime umożliwia korzystanie z bazy tylko i wyłącznie dla określonego w umowie produktu. Ja w firmie mam wersję runtime SQL dla SAP ale w wersji Enterprise i stosowny haracz płacę już bezpośrednio do SAP, choć przy okazji zmiany wersji muszę akceptować zmiany licencyjne Microsoft. Dodatkowe przetwarzanie danych (procedury agregujące, tabele pomocniczne itp) wykonuję już w innej bazie do której mam zdefiniowany mirror. Własne przetwarzanie danych w bazie runtime grozi, w przypadku kontroli, finansowymi sankcjami (to wynika z mojej umowy licencyjnej z SAP).

Udało się:) Dziękuję raz jeszcze za wszelkie wskazówki - nie wiedziałem, że tak swobodnie można dodawać inne BO w referencji do poprzedniego obiektu. W moim przypadku musiałem delikatnie skorygować wskazanie do numeru zamówienia klienta na: {Dokument.Pozycje.encjaPozycji.PozycjeRealizowane.PozycjaRealizowana.Dokument.NumerZewnetrzny} Pozdrawiam

Dziękuję za szybką odpowiedź - tamten wątek już przewertowałem, jak też inne techniczne artykuły. Sporo opisanych tam zmian udało mi się zaimplementować . W tym przypadku mam już gotowe pole/atrybut o nazwie numer zamówienia w liniach wydruku, jednak nie potrafię przyporządkować do niego opisanego przez Pana wcześniej obiektu biznesowego: {Dokument.Pozycje.encjaPozycji.PozycjeRealizowane.PozycjaRealizowana.Dokument.DokumentyRealizowane.NumerZewnetrzny} na załączonym zdjęciu próbowałem pokazać, że brakuje w encjach pozycji obiektu "PozycjeRealizowane"

Dzień dobry. Próbuję dzisiaj zrealizować pomysł dodania numerów zamówień do pozycji wydruku faktury, jednak nie mogę odnaleźć kontekstu .PozycjeRealizowane. Prosiłbym jeszcze o jakieś wskazówki/nakierowanie.

Dziękuję za profesjonalną i wyczerpującą odpowiedź. Nie znałem tej dokumentacji - myślę że znajdę tam odpowiedź na wiele przyszłych pytań.

Chciałbym się podłączyć to tego wątku i dopytać, czy istnieje jakiś wykaz możliwych do użycia maetawłasności? Osobiście poszukuję numeru klienta (zleceniodawcy).

Dziękuję za wskazówkę - to podejście wydaje mi się być rozsądne:)