Wstęp
Moduł: Zamówienia, jest przewidziany dla dokumentowania czynności towarzyszącym procesowi dokonywania sprzedaży/zakupów. Ma on szczególne zastosowanie w przypadku podmiotów, które dokonując obrotu, muszą dokonywać rejestracji wpływających zamówień i prowadzą sformalizowane negocjacje z klientem.
Zalety korzystania z modułu: Zamówienia są szczególnie widoczne przy rozpatrywaniu trzech sposobów prowadzenia sprzedaży.
W pierwszym z nich – sprzedaży bezpośredniej, klient dokonuje zakupu, otrzymując fakturę, dokonując płatności bądź uzyskując odroczenie płatności. Taki sposób prowadzenia sprzedaży wymaga prowadzenia systemu „fakturocentrycznego”, czyli takiego, który będzie umożliwiał szybkie wystawienie faktury, sugerując domyślne ceny, wysokości i warunki rabatów oraz należne płatności. Wymienione funkcje znakomicie wykonuje moduł: Sprzedaż, a korzystanie z modułu: Zamówienia, w tym przypadku, nie jest konieczne.
Druga metoda prowadzenia sprzedaży, polega na dostarczaniu określonych towarów dla stałych odbiorców według składanych przez nich zamówień. Odbiorcy tacy, mają z reguły określone warunki, na jakich dokonują zakupu. Przy tego rodzaju sprzedaży element negocjacji raczej nie występuje, stąd korzystanie w tym przypadku z modułu: Zamówienia, niezbędne jest tu jedynie w sytuacji, gdy zachodzi konieczność rejestracji napływających od klientów zamówień.
Należy tu zauważyć, iż jeżeli wprowadzane do systemu Comarch ERP XL rejestrowane dokumenty mają służyć wyłącznie rezerwacji towaru dla określonego klienta (wielkość rezerwacji, czas realizacji dostawy, wielkość towaru zamówionego u dostawcy) wystarczające do tego celu może okazać się wykorzystanie funkcji: Rezerwacje, w module: Sprzedaż.
Trzecim sposobem dokonywania sprzedaży jest sprzedaż związana z prowadzeniem negocjacji. Sytuacja taka ma często miejsce w sytuacji, gdy zbywany towar ma charakter niestandardowy, np. jest to towar dostępny w wybranych opcjach, lub składający się z wybranych (na życzenie klienta) modułów, lub w przypadku uczestniczenia przez sprzedawców w przetargach. Dokonanie wówczas sprzedaży poprzedzone jest przeprowadzeniem negocjacji.
W takim procesie sprzedaży można wyróżnić następujące etapy:
- Zapytanie od klienta – może mieć różny charakter: formalnego zapytania ofertowego, zaproszenia do przetargu, lub nawet pytania zadanego w rozmowie telefonicznej.
- Oferta – sprzedawca przedstawia ofertę na towary, lub usługi będące następnie przedmiotem zamówienia.
- Zamówienie – jest wynikiem prowadzonych do tej pory negocjacji. Złożenie zamówienia oznacza, że klient zdecydował się na ofertę przedstawioną przez sprzedawcę, jednak i na tym etapie może dojść do modyfikacji uzgodnionych warunków.
- Dokonanie sprzedaży – wystawienie faktury. Na podstawie zamówienia wystawiana jest faktura, co stanowi finalny etap sprzedaży. Z tego względu, powyższy sposób jej dokonywania, można określić jako zamówieniocentryczny.
Przedstawiony sposób prowadzenia sprzedaży nie zawsze obejmuje wszystkie wymienione etapy. Opisany kształt ma charakter modelowy, który w zależności od potrzeb, może przybierać różną formę realizacji.
Moduł: Zamówienia, stanowi znakomite narzędzie, służące sprawnemu dokumentowaniu czynności opisanych w trzecim sposobie prowadzenia sprzedaży. Czynności te może rejestrować w zaprezentowanej kolejności, ale może równocześnie służyć w procesie sprzedaży, dokonanej z pominięciem zapytania od klienta, bądź oferty. Przez swą wielofunkcyjność spełnia wymagania wszystkich Użytkowników, dla których element rejestracji zamówień lub prowadzenia negocjacji jest niezbędny w prowadzonej działalności. Należy również zauważyć, że służy w równej mierze procesowi sprzedaży, jak i zakupów.
Opis
Praca z modułem: Zamówienia, odzwierciedla proces sprzedaży, uwzględniający kierowanie do sprzedającego zapytań, a także składanie ofert oraz zamówień. Przez możliwość generowania z zamówień dokumentów handlowych, obejmuje całościowo ten sposób prowadzenia handlu.
Kolejność wykonywania czynności
Dokumentowanie czynności może odbywać się w porządku chronologicznym, uzyskując wtedy następującą kolejność:
- skierowanie zapytania ofertowego
- złożenia ofert
- złożenie zamówienia
- wystawienie dokumentu handlowego ze złożonego zamówienia
W praktyce możliwe jest omijanie niektórych z wymienionych etapów. I tak, np.: skierowanie zapytania ofertowego nie jest niezbędne do wygenerowania ofert, natomiast dla złożenia zamówienia nie jest konieczne uprzednie przygotowanie oferty. Należy jednak pamiętać, że wystawienie dokumentu handlowego można dokonać jedynie z zarejestrowanego w systemie i potwierdzonego zamówienia.
Dualizm zamówień zakupu i sprzedaży
Moduł: Zamówienia zbudowany jest symetrycznie. Oznacza to, że wszystkim dokumentom sprzedaży, powstałym w trakcie pracy z modułem: Zamówienia, można przypisać analogiczne dokumenty, ale związane z procesem zakupu.
- Dokumenty związane z zamówieniami sprzedaży to:
- zapytanie ofertowe składane przez klienta do Użytkownika modułu: Zamówienia
- oferta dla klienta
- zamówienie składane przez klienta
- potwierdzenie zamówienia dla klienta
- faktura sprzedaży wystawiona dla klienta.
- Dokumenty związane z zamówieniami zakupu to:
- zapytanie skierowane przez Użytkownika modułu: Zamówienia, do dostawcy,
- oferta przedstawiona przez dostawcę
- zamówienie skierowane do dostawcy
- potwierdzenie zamówienia Użytkownika
- faktura zakupu.
Ten dualizm widoczny jest po otwarciu okna: Lista zamówień. Zakładki poziome w tym oknie dzielą listę na dokumenty związane ze sprzedażą – zakładka: Lista zamówień sprzedaży i z zakupami – zakładka: Lista zamówień na zakup. Natomiast zakładki boczne są wspólne dla dokumentów sprzedaży i dokumentów zakupu i określają ich typ (zapytanie oferta lub zamówienie). Z zamówienia na sprzedaż można przygotować zamówienie na zakup (dla dostawcy).
W wyniku przygotowania (wygenerowania) zamówienia zakupu z zamówienia sprzedaży przepisywane są pozycje towaru oraz cechy na dokumencie. Powyższa funkcja skraca w ten sposób czas przeznaczony przez Użytkownika na przygotowanie zamówienia zakupu. Należy tu zauważyć, iż możliwy jest odwrotny kierunek generowania dokumentów, czyli z zamówienia zakupu można przygotować zamówienie sprzedaży. Wariantowość oferty polega na tym, że można przygotować dowolną liczbę ofert dla jednego zapytania ofertowego. Taka sytuacja jest możliwa, jeśli zapytanie ofertowe dotyczy pozycji, które, z różnych powodów, należy rozdzielić. W takiej sytuacji można z jednego zapytania wyprowadzić oferty dotyczące oddzielnie każdej z pozycji. Użytkownik chce przedstawić kupującemu kilka ofert do wyboru. Z jednego zapytania ofertowego przygotowywane są różne oferty na ten sam towar. W systemie Comarch ERP XL istnieje możliwość rezerwowania zamówionego towaru. Funkcjonują dwa rodzaje rezerwacji: Przy generowaniu dokumentów handlowych/magazynowych z zamówień będą pobierane zarezerwowane zasoby. Rezerwacja na zasobach polega na wiązaniu rezerwacji z zasobami w magazynach i tym samym blokowanie związanych zasobów. Zasoby rezerwowane są automatycznie, bądź poprzez wskazanie zasobu przez operatora. Do jednej rezerwacji będzie można przypisać jedną dostawę i magazyn. Jeden element zamówienia może generować wiele rezerwacji. Z poziomu elementu zamówienia można wykonać, zmieniać i usuwać przypisanie dostaw do rezerwacji. Zarezerwowany zasób będzie niedostępny przed upływem daty ważności rezerwacji, dla wszelkich innych operacji niż realizacja rezerwacji. Rezerwacja na zasobach ma pierwszeństwo przed rezerwacją ilościową, czyli rezerwacją bez przypisanych zasobów. Przy rezerwacji na zasób kontrolowana jest zgodność cech na dokumencie dla którego generowane są rezerwacje i cech na zasobach, które będą objęte rezerwacją. Możliwe jest jednak spięcie rezerwacji z zasobem, który ma inną cechę niż towar na dokumencie. Na rezerwacji istnieje możliwość określenia dat aktywacji oraz realizacji. W przypadku, gdy określimy datę realizacji na nieokreśloną wówczas również zmieni się data aktywacji na Brak ograniczenia. Rezerwacje ilościowe nie mają przypisanych zasobów. O kolejności ich realizacji decydują priorytety. Jeżeli w systemie istnieje rezerwacja o wyższym priorytecie, rezerwacja o niższym priorytecie będzie dopuszczona do realizacji tylko wówczas, gdy po tej operacji na magazynie pozostanie jeszcze wystarczająca ilość towaru do zrealizowania rezerwacji o wyższym priorytecie. Podczas dodawania elementu na niepotwierdzone ZS system od razu utworzy stosowną rezerwację/wiele rezerwacji. O takim zachowaniu systemu decyduje parametr w definicji dokumentu ZS->zakładka Inne: „Rezerwacje na niepotwierdzonym ZS” . Podczas edycji elementu system stosownie zmodyfikuje powiązane z nim rezerwacje, czyli w przypadku zmniejszenia ilości zachowane zostaną zasady modyfikacji rezerwacji jak podczas zmniejszania ilości na elemencie potwierdzonego ZS, tj.: ilość w związanych rezerwacjach zostanie odpowiednio zmniejszona, przy czym najpierw przetwarzane będą rezerwacje bez zasobów, a potem – z zasobami. W obu przypadkach będzie zastosowana kolejność: priorytet (od najniższego), data realizacji (od najpóźniejszej), data ważności (od najniższej), numer kolejny od najwyższego). W przypadku zwiększania ilości na elemencie zachowanie systemu jest zależne od parametru w definicji dokumentu „rezerwuj zasoby” wg. poniższych zasad, jeżeli : ww. parametr: Ww. zasada obowiązuje zarówno podczas zwiększania ilości na potwierdzonym, jak i niepotwierdzonym ZS. Rezerwacje mogą ulec modyfikacji w wyniku zmiany towaru na elemencie ZS, czyli po: Zmiana klasy/wartości cechy na elemencie niepotwierdzonego zamówienia Po zmianie klasy/cechy na elemencie niepotwierdzonego zamówienia system usunie dotychczasowe rezerwacje zasobowe, na rezerwacjach niezasobowych zmieni cechę, na koniec wygeneruje rezerwację, jeżeli będzie taka potrzeba. Zmiana magazynu na elemencie niepotwierdzonego zamówienia Jeżeli zmiana magazynu na elemencie zamówienia będzie polegała na wskazaniu konkretnego magazynu, wówczas system pozostawi bez zmian te rezerwacje, dla których ustalony jest tenże magazyn, w przypadku niezgodności magazynu system odłączy zasób od rezerwacji, zmieni na niej magazyn, a następnie zachowa, lub usunie powiązanie rezerwacji z BST, w zależności od tego, czy na BST znajduję się magazyn zgodny z magazynem rezerwacji. W przypadku zmiany magazynu na wartość <wszystkie> system zachowa rezerwacje zasobowe, bez względu na magazyn na tychże rezerwacjach, a na rezerwacjach niezasobowych ustali magazyn na opcję <wszystkie>. W ten sposób zachowane zostaną powiązania rezerwacji z BST. Zmiany dokonywane na nagłówku niepotwierdzonego ZS posiadającego rezerwacje są odzwierciedlone na tychże rezerwacjach, a zmiany te to: zmiana kontrahenta, zmiana właściciela zamówienia, zmiana magazynu na dokumencie, zmiana dat na dokumencie, zmiana priorytetu rezerwacji, uruchamianie funkcji „rezerwuj zasoby”. Jeżeli zmiana magazynu na nagłówku nie spowoduje zmiany magazynu na elementach ZS (operator udzieli negatywnej odpowiedzi na pojawiające się pytanie), wówczas nie są dokonywane zmiany w rezerwacjach. Jeżeli zmiana magazynu na nagłówku spowoduje zmianę magazynu na elementach ZS, wówczas dla każdego z elementów ZS zostanie wykonana operacja jak przy ręcznej zmianie magazynu na elemencie. Historia towaru/kontrahenta/Rezerwacje Na liście rezerwacji istnieje możliwość wyróżnienia kolorystycznie rezerwacji powiązanych z niepotwierdzonym ZS wg. poniższych zasad: W związku z udostępnianą możliwością rejestrowanie ZS w taki sposób, aby już zamówienie niepotwierdzone tworzyło rezerwacje, została zmodyfikowana akcja „otwierania” zamówienia, tj. cofania go do stanu zamówienia niepotwierdzonego. Dotychczas operacja taka zawsze powodowała usunięcie rezerwacji, obecnie system nie będzie usuwał rezerwacji z zamówienia, które zarejestrowano w trybie „generowania rezerwacji na niepotwierdzonym zamówieniu”. W przypadku zamówienia rejestrowanego w dotychczasowym trybie, rezerwacje zostaną usunięte. Na karcie operatora jest parametr „Rozdzielanie przyjmowanych zasobów pomiędzy rezerwacje” decydujący Na definicji dokumentów przychodowych został udostępniony parametr: Przydzielaj tworzone zasoby do rezerwacji. Na definicji tych dokumentów przychodowych, na których zaznaczono parametr „Przydzielaj tworzone zasoby do rezerwacji” operator może zaznaczyć parametr „Przydział ręczny” oraz „Proponuj ilość”. Jeżeli parametr będzie zaznaczony, wówczas po zatwierdzaniu danego dokumentu pojawi się formatka pozwalająca na zmianę zaproponowanego przez system „powiązania” zasobów tworzonych danym dokumentem z poszczególnymi rezerwacjami. Na formatce jn. system prezentuje w formie drzewiastej: poszczególne towary o określonej cesze, przyjmowane na dany magazyn, a pod każdym z nich listę rezerwacji, z którymi przyjmowany zasób może zostać powiązany. Domyślnie kolejność rezerwacji oraz proponowana do powiązania ilość z tychże rezerwacji jest zgodna z dotychczasowymi zasadami automatycznego wiązania rezerwacji z przyjmowanym zasobem, tj. rezerwacje te będą uporządkowane wg priorytetu, daty realizacji, daty ważności i daty utworzenia rezerwacji. Parametr „Proponuj ilość” jest możliwy do edycji wyłącznie, jeżeli zaznaczony jest parametr „Przydział ręczny”. Od wersji XL 2018.1 jeżeli operator zamknie to okno bez zapisu to taka operacja będzie interpretowana jako całkowita rezygnacja z przydzielania zasobów do rezerwacji, o czym Użytkownik zostanie uprzedzony komunikatem „Zasoby nie zostaną przypisane. Czy pomimo to zamknąć okno bez zapisu?”. Opcja TAK – funkcja wiązania zasobów z rezerwacją nie będzie wołana, bez względu na to jakie ilości zostały ustalone w kolumnie „Ilość do powiązania”, a okno zostanie zamknięte, opcja NIE – okno zostanie podniesione. Do wersji 2018.1 podczas zapisu formatki system przypisywał poszczególne zasoby do rezerwacji, przy czym przypisanie to odbywało się w ilości zgodnej z ilością ustaloną w kolumnie „Ilość do powiązania” dla poszczególnych rezerwacji. Jeżeli ww. parametr „Przydział ręczny” był odznaczony, lub operator nie miał prawa (parametr na karcie operatora „Rozdzielanie przyjmowanych zasobów pomiędzy rezerwacje” jest odznaczony), a na definicji dokumentu parametr „Przydzielaj tworzone zasoby do rezerwacji” był włączony, wówczas system samodzielnie dokonywał wiązania zasobów z rezerwacjami, nie prezentując dodatkowego okna. Operator mógł zmienić kolejność rezerwacji poprzez ich sortowanie po poszczególnych kolumnach. Mógł również zmienić proponowaną ilość do powiązania ręcznie, metodą edit-in-place na tej kolumnie lub też poprzez wybór jednej z opcji rozdziału zasobów: wg priorytetu (dotychczasowa metoda automatycznego rozdziału), wg kolejności na liście (np. operator sortował rezerwacje wg jednego z kryterium np. daty utworzenia rezerwacji, a następnie wybierał tą opcję. W ten sposób system przypisywał poszczególnym rezerwacjom zasoby w ilości zgodnej z ilością w tychże rezerwacjach, aż do wyczerpania zasobu.), lub „proporcjonalnie” (system rozdzielał zasób proporcjonalnie do niepowiązanej ilości dla poszczególnych rezerwacji). System umożliwia zaznaczanie/odznaczanie rekordów właściwych dla poszczególnych „grup” zasobów, bowiem operacje polegające na zmianie sposobu rozdziału zasobów pomiędzy rezerwacje można dokonywać wg poszczególnych zasobów i wszystkich podpiętych do nich rezerwacji. Nie można natomiast zaznaczyć/odznaczyć tylko niektórych rezerwacji z danej grupy, tzn. po zaznaczeniu danego rekordu zostaną zaznaczone wszystkie podpięte rezerwacje, a po odznaczeniu danego rekordu zostaną odznaczone wszystkie podpięte rezerwacje. Od wersji 2018.1 zachowanie Systemu w tej kwestii jest zależne od parametru „Proponuj ilość” na definicji dokumentu. Jeżeli parametr ten będzie zaznaczony, wówczas System będzie proponował, jak dotychczas ilości wg danego kryterium, w przypadku zaś, gdy będzie on odznaczony, żadne ilości nie będą proponowane (System ustali 0,0000 jako ilość do powiązana na wszystkich rezerwacjach). Na wyżej ww. oknie prezentowane są rezerwacje, które spełniają poniższe warunki: Warunki dotyczące sekwencji dokumentów ZS-ZZ-PZ/FZ: Warunki, które muszą być spełnione podczas wiązania zasobów z konkretną rezerwacją: Grupowanie rezerwacji na formatce rozdzielania zasobów pomiędzy rezerwacje: Jeżeli istnieją rezerwacje dla danego towaru i magazynu z określoną cechą, wówczas ww. rezerwacje bez cechy (ale na dany towar i magazyn), zostaną podpięte do tej z grup dla danego towaru/magazynu, dla którego istnieje „grupa zasobowa” z największą, niezerową „ilością możliwą do zarezerwowania” Jeżeli nie istnieją rezerwacje jw., lub nie istnieje „niezerowa” grupa zasobowa, wówczas taka rezerwacja zostanie podpięta w odrębnej grupie: towar/„pusta” cecha/magazyn. W przypadku rezerwacji na magazyn <wszystkie> rezerwacje będą weryfikowane jak niżej, jeżeli: Podczas „dołączania” rezerwacji do grupy <towar/cecha/mag<wszystkie> będzie sprawdzany właściciel rezerwacji, i będą tworzone „odrębne grupy” dla różnych właścicieli tychże rezerwacji, jeżeli: Od wersji 2016.0 wprowadzony został parametr [Przelicz elementy niepotwierdzonych ZS]. Parametr został wprowadzony na potrzeby funkcjonalności promocji na konkretną dostawę towaru. Przy zaznaczeniu parametru, dla każdej rezerwacji wskazującej na niepotwierdzone zamówienie, z której dostawa jest odłączana, dany element zamówienia będzie ponownie przeliczony zależnie od zdefiniowanej promocji na konkretną dostawę towaru. Funkcjonalność przydzielania zasobów dostępna jest również dla wielu wskazanych zamówień jednocześnie. Po zaznaczeniu na liście zamówień sprzedaży określonych dok. ZS możemy skorzystać z opcji w menu kontekstowym: Rezerwuj zasoby. Wówczas pojawi się okno: Przydzielaj zasoby do rezerwacji. Funkcjonalność dostępna jest dla wskazanych zamówień sprzedaży oraz zamówień wewnętrznych. W wersji 2017.1 dokonano zmian usprawniających funkcjonalność automatycznego wiązania zasobów towarowych z rezerwacjami. Zmiany te dotyczą zarówno zasad tworzenia powiązań pomiędzy zamówieniami/zleceniami źródłowymi a zamówieniami/zleceniami generowanymi na ich potrzeby, jak i zasad „honorowania” takich powiązań w funkcjach wiązania zasobów z rezerwacjami. Podczas automatycznego wiązania zasobów System honoruje powiązania, utworzone w wyniku generowania zamówienia/zlecenia na potrzeby konkretnego zamówienia/zlecenia sprzedaży. Oznacza to, że do rezerwacji tegoż zamówienia sprzedaży zostaną automatycznie przypisane wyłącznie dostawy, założone przez dokument przychodu realizujący to zamówienie zakupu. Zasada ta została w wersji 2017.1 poszerzona o weryfikację stanu takiego wynikowego zamówienia zakupu. Mianowicie, jeżeli zamówienie to ma status zamówienia zrealizowanego, zamkniętego lub anulowanego, wówczas powiązanie z takim zamówieniem jest ignorowane, taki status zamówienia/zlecenia oznacza bowiem, że nie będzie ono już realizowane, stąd rezerwacja sprzedażowa nie może „czekać” na jego realizację. Dla rezerwacji sprzedażowych powiązanych z takimi zamówieniami wiązanie zasobów przebiega wg ogólnych zasad. Opisana wyżej zasada obowiązuje podczas operacji: Operacja wiązania zasobów do wskazanych ZS/ZW działa niezależnie od parametru „Przydziel zasoby…” i dotyczy wszystkich zasobów towaru, a nie przyjmowanych konkretnym typem dokumentu natomiast parametr „Proponuj ilość” dotyczy automatycznego rozdzielania przyjmowanych zasobów i konkretnych typów dokumentów. W przypadku operacji wiązania zasobów do wskazanych zamówień zachowana została zasada domyślnego ustalania przez System „Ilości do powiązania” dla poszczególnych rezerwacji. W oknie wywoływanym operacją „Rozdziel zasoby…” z listy dokumentów przychodowych System prezentuje okno identyczne, jak podczas zatwierdzania danego dokumentu przychodu, z tym, że dodatkowo prezentuje w nim te rezerwacje zasobowe, które powiązane są z dostawami założonymi przez ten dokument (po to, aby można je było tutaj odpiąć i przypiąć do innych rezerwacji). Przyjęta została zasada, zgodnie z którą System nadal proponuje Ilość do powiązania dla rezerwacji wg dotychczasowych zasad, bez względu na parametr Przydziału Ręcznego. Dotychczas podczas generowania zamówień/zleceń z Bilansu Stanu Towarów, System każdorazowo tworzył powiązania (ZamZamLinki) generowanych elementów ze wszystkimi elementami, na które wskazywały niezasobowe rezerwacje sprzedażowe BST, również takimi, dla których wygenerowano już wcześniej zamówienie/zlecenie, czy to za pośrednictwem wcześniejszego BST, czy to wprost z tychże zamówień/zleceń. Zasada taka powoduje, że w sytuacji, gdy realizacja zamówień zakupu przebiega wg innej kolejności, niż kolejność generowanych zamówień, tworzone zasoby przydzielane są do innych rezerwacji, niż oczekuje Użytkownik. Ponadto dla wielu Użytkowników tworzenie i prezentacja wszystkich powiązań jest nieczytelna, Użytkownik nie zawsze wie, na jakie ZZ czeka dane ZS. Aby uniknąć ww. niedogodności wprowadzona została opcjonalnie zasada, zgodnie z którą podczas tworzenia powiązań z ZZ/ZW/ZK/ZP generowanego z BST System pomija te elementy źródłowe rezerwacji sprzedażowych, które mają już „swoje” zamówienia/zlecenia na które czekają, czyli dla których istnieje już stosowny rekord ZamZamLink wskazujący na zamówienie/zlecenie, którego status świadczy o tym, że będzie ono jeszcze realizowane. Zachowanie Systemu w zakresie tworzenia powiązań j.w. zależy od ustawienia parametru „Pomiń elementy już powiązane” na dokumencie BST, domyślnie ustalanego na podstawie jego definicji. Wyłączony parametr oznacza, że System będzie tworzył, jak dotychczas powiązania generowanego zamówienia/zlecenia ze wszystkimi elementami źródłowymi. Włączenie go oznacza, że System utworzy powiązania wyłącznie z tymi elementami, które takich powiązań jeszcze nie mają. Dotychczas, podczas korygowania zamówienia, informacja o powiązanych z nim zamówieniach/zleceniach źródłowych, czy też wynikowych była tracona. Od wersji 2017.1 Systemu powiązania te są na korektę przenoszone. Jeżeli więc na poczet zamówienia sprzedaży wygenerowano zamówienie zakupu, a następnie skorygowano to zamówienie sprzedaży, wówczas zamówienie-korekta nadal będzie powiązane z ww. zamówieniem zakupu. Podobna zasada obowiązuje również w przypadku korekty zamówienie zakupu, czy też zamówienia wewnętrznego wygenerowanego na potrzeby zamówienia sprzedaży, zamówienia wewnętrznego, czy też zlecenia. Kopiowanie powiązań pozwala na sprawne automatyczne wiązanie zasobów przyjmowanych w ramach realizacji zamówień wynikowych, również w przypadkach gdy to one, bądź ich zamówienia źródłowe były w międzyczasie korygowane. Przykład: Zarejestrowano ZS1 na 10szt towaru T1, a następnie wygener owano z niego ZZ1 na całość, zamówienie zakupu zostało wysłane do Dostawcy. Skorygowano ZS1, korekta dotyczyła zwiększenia ilości towaru do 12szt. Z ww. zamówienia- korekty ZS2 wygenerowano ZZ2 na 2szt. Przyjęto dostawę PZ1 na 10szt, realizującą ZZ1:Wariantowość oferty
Rezerwacje
Rezerwacja na zasobach
Rezerwacja ilościowa
Rezerwacje na niepotwierdzonych zamówieniach
Zmiany na nagłówku niepotwierdzonego ZS a rezerwacje
w kolorystyce wybranej w konfiguracji dla zamówienia „niepotwierdzonego”, odpowiednio, gdy kursor:Zmiana zasad „otwierania” zamówienia
Przydzielanie zasobów do rezerwacji
o tym, czy operator będzie mógł przydzielać zasoby do rezerwacji podczas zatwierdzania dokumentów przychodowych.
Zmiany w zakresie wiązania zasobów z rezerwacjami
Uwzględnianie stanu zamówienia powiązanego w funkcji rezerwacji zasobów
Okno ręcznego wiązania wołane opcją „Rezerwuj zasoby” z listy ZS/ZW
Okno ręcznego wiązania wołane wtórnie do dokumentu przychodu
Pomijanie elementów powiązanych podczas generowania dokumentów z BST
Kopiowanie powiązań zamówień podczas ich korygowania
Czy ten artykuł był pomocny?