Data fv ma być równa dacie podstawowej przy określonych z góry założeniach
MIRO PODSTAWIENIE DATY
-
sylwia123
- Posty: 295
- Rejestracja: czw mar 22, 2018 8:39 am
- Has thanked: 96 times
- Been thanked: 34 times
MIRO PODSTAWIENIE DATY
Jakie macie pomysły jak najprościej zrobić podmiankę dat w MIRO?
Data fv ma być równa dacie podstawowej przy określonych z góry założeniach
Data fv ma być równa dacie podstawowej przy określonych z góry założeniach
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
-
sylwia123
- Posty: 295
- Rejestracja: czw mar 22, 2018 8:39 am
- Has thanked: 96 times
- Been thanked: 34 times
Re: MIRO PODSTAWIENIE DATY
Podczas wprowadzania dokumentu. Żeby ta data się zmieniała. Nikt nie wie?
-
sylwia123
- Posty: 295
- Rejestracja: czw mar 22, 2018 8:39 am
- Has thanked: 96 times
- Been thanked: 34 times
Re: MIRO PODSTAWIENIE DATY
Wydaje mi się że MRM_PAYMENT_TERMS będzie tu odpowiednie. Macie jakieś przykłady użycia?
-
dominik.tylczynski
- Posty: 8071
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1775 times
- Been thanked: 1395 times
-
RKISIEL
- Posty: 553
- Rejestracja: pn lut 14, 2011 9:10 pm
- Has thanked: 388 times
- Been thanked: 248 times
Re: MIRO PODSTAWIENIE DATY
Cześć,
Ustalenie aby data podstawowa była równa dacie faktury/księgowania to nie jest problem - warunki płatności (OBB8) decydują o tym tym i dalej FM: FI_CHANGE_PAYMENT_CONDITIONS i FI_FIND_PAYMENT_CONDITIONS.
Wystarczy jeśli w warunku płatności jest zaznaczona (w części Wartość domyślna dla daty podstawy) opcja "Data dokumentu"/"Data księgowania"
Trudniejsze zadanie jest gdy warunki płatności muszą opierać się na dacie otrzymania (REINDAT) zarówno w transakcjach Enjoy (MIR*, FB*, FV*) jak i w starszych bazujących na FB01 - tam zawartość pola ZFBDT musi być równa zawartości REINDAT.
Jeszcze trudniejsze jest gdy liczba dni przesunięcia płatności (ZBD1T) jest zmienna np. dla warunku: 14 dni roboczych od daty otrzymania dokumentu. Smaczku dodaje jeszcze to, że dni robocze mogą być określane dla kalendarza dostawcy/wystawcy lub nabywcy/odbiorcy - o tym świadczą warunki umowy.
Czy znaleźliście może jakieś standardowe rozwiązanie?
Ja niestety nie znalazłem i zadania rozwiązałem przez EI w ww. modułach - na końcu każdego z nich.
Niestety również musiałem (dla MM) zmodyfikować MODULE get_form w LFDCBI01 aby przy zmianie REINDAT dla warunków płatności opartych na wartości z tego pola aktualizowała się wartość ZFBDT i data płatności była zgodna z algorytmem - szczególne znaczenie dla warunkach związanych z liczbą dni roboczych gdzie wartość ZBD1T również może ulec zmianie.
Dla dokumentów pochodzących z SD gdzie używane są warunki płatności oparte na dacie otrzymania (REINDAT) też nie ma problemu przy księgowaniu - w BTE 1120 ten problem można łatwo rozwiązać. Problemem może być określenie wartości REINDAT - przyjęliśmy, że jest to data dokumentu (BLDAT) + liczba dni przesunięcia.
Liczba dni przesunięcia jest zależna do kanału dystrybucji np. e-mail, wysyłka pocztą (?!?) czy obieg wewnętrzny (wewnątrz systemu) - każda JG określa wartości liczby dni w zależności od kanału. Informacje o kanale dystrybucji dla układu JG/BP/kanał kreślone są w SD. Liczba dni może mieć dodatkowe wskazanie czy są to dni robocze. Dwie Z* tabele konfiguracyjne: JG/BP/kanał i JG/kanał/liczba dni przesunięcia/robocze.
Ustalenie aby data podstawowa była równa dacie faktury/księgowania to nie jest problem - warunki płatności (OBB8) decydują o tym tym i dalej FM: FI_CHANGE_PAYMENT_CONDITIONS i FI_FIND_PAYMENT_CONDITIONS.
Wystarczy jeśli w warunku płatności jest zaznaczona (w części Wartość domyślna dla daty podstawy) opcja "Data dokumentu"/"Data księgowania"
Trudniejsze zadanie jest gdy warunki płatności muszą opierać się na dacie otrzymania (REINDAT) zarówno w transakcjach Enjoy (MIR*, FB*, FV*) jak i w starszych bazujących na FB01 - tam zawartość pola ZFBDT musi być równa zawartości REINDAT.
Jeszcze trudniejsze jest gdy liczba dni przesunięcia płatności (ZBD1T) jest zmienna np. dla warunku: 14 dni roboczych od daty otrzymania dokumentu. Smaczku dodaje jeszcze to, że dni robocze mogą być określane dla kalendarza dostawcy/wystawcy lub nabywcy/odbiorcy - o tym świadczą warunki umowy.
Czy znaleźliście może jakieś standardowe rozwiązanie?
Ja niestety nie znalazłem i zadania rozwiązałem przez EI w ww. modułach - na końcu każdego z nich.
Niestety również musiałem (dla MM) zmodyfikować MODULE get_form w LFDCBI01 aby przy zmianie REINDAT dla warunków płatności opartych na wartości z tego pola aktualizowała się wartość ZFBDT i data płatności była zgodna z algorytmem - szczególne znaczenie dla warunkach związanych z liczbą dni roboczych gdzie wartość ZBD1T również może ulec zmianie.
Dla dokumentów pochodzących z SD gdzie używane są warunki płatności oparte na dacie otrzymania (REINDAT) też nie ma problemu przy księgowaniu - w BTE 1120 ten problem można łatwo rozwiązać. Problemem może być określenie wartości REINDAT - przyjęliśmy, że jest to data dokumentu (BLDAT) + liczba dni przesunięcia.
Liczba dni przesunięcia jest zależna do kanału dystrybucji np. e-mail, wysyłka pocztą (?!?) czy obieg wewnętrzny (wewnątrz systemu) - każda JG określa wartości liczby dni w zależności od kanału. Informacje o kanale dystrybucji dla układu JG/BP/kanał kreślone są w SD. Liczba dni może mieć dodatkowe wskazanie czy są to dni robocze. Dwie Z* tabele konfiguracyjne: JG/BP/kanał i JG/kanał/liczba dni przesunięcia/robocze.
Rafał Kisiel