Post by wloochaczI Ty uważasz, że trigger jest mniej wydajny od JOB'a w takiej sytuacji?
Nie trigger, ale aplikacja z tym triggerem w porównaniu z aplikację bez tego
triggera.
Post by wloochaczCiekawe jak poradzisz sobie z powiadamianiem systemu FK o tym, że nie może
księgować wszystkich transakcji, ponieważ nie ma wszystkich informacji -
przecież to zaowocuję sporą ilością kodu, który może się okazać po prostu
zawodny.
Jeżeli księgowość jest innym systemem, to tym bardziej transer dokumentów i
klientów powinien odbywać się kompleksowym jobem. Chcesz proces sprzedaży,
który musi działać szybko, obciążyć triggerem, który wykonuje tranfer do
księgowości?
Post by wloochaczIMHO rozbijanie jednego systemu transakcyjnego na kilka baz danych jest
zwyczajnym nieporozumieniem.
Zgadzam się. Ale to Ty mówisz o kilku bazach, a nie ja.
Post by wloochaczPost by Dariusz DrzemickiMasz wybór kiedy i gdzie odpalisz joba, przy triggerze niestety nie.
OK, jak mi powiesz jak mam uruchomić job'a który wykona się po określonej
akcji (np. dodanie nowego rekordu do tabeli X) to stawiam co tam chcesz.
Właśnie tak robię. Podczas wprowadzania zamiennika towaru do katalogu należy
wykonać procedurę serwisowania zamienników. Procedura niestety jest dość
ciężka i może trochę trwać. Podłączenie procedury do zdarzenia spowoduje
chwilowe zawieszenie aplikacji. Aby tego uniknąć zamiast procedury wykonuję
instrukcję definiującą joba jednokrotnego i natychmastowego wykonania tej
procedury.
Post by wloochaczPost by Dariusz DrzemickiPost by wloochaczMoże dlatego, że magazyny to również produkcja nie tylko wyroby gotowe?
Ponieważ moduł gospodarki magazynowej, w istniejącym systemie ERP, mogę
sobie w buty wsadzić. Oczywiście ma wszystko co każdy GM powinien
posiadać, a nawet i więcej, ale nie ma wielu niezbędnych funkcji.
Ale czy rozbijanie magazynu i fakturowania nie tworzy większych problemów?
Zdecydowanie nie - GM, w ujęciu tradycyjnym, to zarządzanie dokumentacją
magazynową a nie magazynami. W WMS jest zdecydowanie odwrotnie (np. WMS
często nie ma ewidencji wartościowej, jest tylko ilościowa).
Trudno mi takie konstrukcje wyobrazić. A jaka jest relacja pomiędzy WZ a
fakturami?
A jaka jest procedura reklamacji, zwrotu, korekty ceny lub ilości,
wielokrotnych zwrotów do jednej faktury, zarządzania WZ niezafakturowanymi?
Jak zwraca się towar do faktury wystawionej na podstawie wielu WZ?
Przecież to wymaga silnego połączenia pomiędzy towarami, a fakturami.
Post by wloochaczPost by Dariusz DrzemickiNie. Ale dlatego, że nie było takich potrzeb. Teraz na zamówienie klienta
rozbudowuję wspólpracę wydawania towaru z systemem kierującym
taśmociągami, gdzie pudełko lub pudełka na określone WZ zatrzymują się
tylko na wymaganych piętrach.
Klient ponosi wtedy koszt modyfikacji, co jest znacznie tańsze, niż zakup
drugiego programu, a potem zmaganie się z intergracją.
He :) To zależy dla kogo tańsze, zważ że ja tu występuje w roli klienta
nie dostawcy oprogramowania.
Koszt to czynnik obiektywny wyrażony w pieniądzach.
Ponadto intergracja wymaga dozoru, a więc większych i stałych kosztów
administracyjnych.
Post by wloochaczPoza tym, bez urazy, modyfukacja o której mówisz ma się nijak, pod
względem komplikacji, do WMS.
Możliwe, chodziło mi jednak o możliwość uzyskania od dostawcy niezbędnych
modyfikacji, niż zakup kolejnego systemu.
Trochę dziwię się, że system, który ma tak zaawansowane funkcje magazynowe
nie potrafi należycie fakturować.
DD