Wypowiedzi
-
Jesli dobrze zrozumiałem to założenia są takie:
- na produktach nie ma kodów kreskowych
- po komisjonowaniu w systemie WMS jest zawartość nośnika wysyłkowego (jest bo drukujemy etykiete zbiorczą z zawartością palety)
Ważenie palety, ktore zaproponował jeden z kolegów jest chyba najszybsze ale nie zawsze możliwe.
Proponuje rozważenie drukowania listy zawartości palety dopiero po sprawdzeniu. Po komisjonowaniu drukujemy listę zawartości bez ilości - tylko kody produktów, pracownik sprawdzający zamiast odhaczać ilości wpisuje rzeczywiście zliczone ilości produktów a następnie przy stanowisku komputerowym porównuje zliczone wartości z tymi zapisanymi w systemie. Jeśli jest OK drukuje ostateczną etykietę zbiorczą.
W zależności od potrzeb można modyfikować ten proces np. nie podpowiadając produktów (wówczas cały musi byc przeprowadzony na stacji roboczej czy terminalu radiowym) czy po sprawdzeniu nie podając zapisanej w systemie ilości a tylko informację czysie zgadza czy nie. -
Pierwsze pytanie jakie należy sobie postawić to skala przedsięwzięcia - to znaczy ile tych wiadomości będzie wysyłanych na dobę czyli jak technicznie wysyłać te SMS
brałem udział w projektach do zarządzania transportem obcym (kierowca nie wraca do magazynu i nie można dać mu GPS ale można go zmusić do wysłania SMS w określonym formacie do systemu) gdzie były dziennie wysyłane tysiące SMSow z wykorzystaniem technologii do masowego wysylania wiadomości tekstowych przez WEB API bezpośrednio do operatora. Jak i mniejszych gdzie przy dziesiątkach wiadomości dziennie wystarczała bramka GSM podłączona do komputera.
Drugie pytanie to sposób pobierania danych
z tego co czytam dane sa w postaci arkusza Excel aktualizowanego na bieżąco - myśle, że żadna gotowa aplikacja tego nie obsłuży i trzeba będzie ją przebudować.
Nasza firma jest autorem platformy softwarowej ukierunkowanej na obsługę procesów logistycznych, dzięki której można łatwo uruchomić tego typu rozwiązanie. -
Maciej Morawski:
>
jeżeli wykonamy operację SELECT z warunkiem WHERE Pozycje.Faktura = 2, to może zostać zwrócony w wyniku tej operacji więcej niż jeden rekord.I tutaj właśnie mam problem, ponieważ nie wiem czy poprawnie wyznaczyłem zależności funkcyjne dla tabeli Pozycje.
Jeśli projekt zakłada więcej niż jedną pozycje do faktury to jest to jak najbardziej prawidłowe.
I koledzy maja racje ze Płatnosc powinna powędrować do nagłówka faktury. Mozesz tak jak sugerują rozbudować tę strukturę pozwalając na przypisanie wiecej niz jednego rodzaju płatności.
W rozliczenia z klientami bym sie nie pakował jeśli nie musze bo tu jest multum zależności (płatności cząstkowe, co zrobic jesli klient zapłaci 2 faktury jednym przelewem) -
Przemysław R.:
Aleksander Latkowski:
jak zrobi joiny to ja nie ogarniam kiedy zrobi left joina a kiedy right.
menu do wyboru jest po kliknięciu prawego klawisza myszy na złączeniu
Przy edycji skomplikowanych zapytan ten graficzny edytor czasem zamienia kolejnośc tabel i jednoczesnie left joina w right joina zmienia co jest mocno denerwujące jak zaznaczam pracowicie napisane zapytanie z 10 left joinami, klikam ekierke coś dłubnę graficznie i nagle mi sie gdzies w zapytaniu right join pojawia
Przemysław R.:
hmm po co? Menagment Studio 2008 Express ma podpowiadanie składni
no ale glowny problem to to że jak sam napisałeś:
Przemysław R.:
działa tylko z SQL Server 2008 :(Aleksander Latkowski edytował(a) ten post dnia 13.06.12 o godzinie 15:18 -
Przemysław R.:
ekierka to graficzny edytor zapytań, powiedzmy że po nauczeniu się nawet całkiem wygodny
umożliwia budowanie naprawdę skomplikowanych zapytań (podzapytania, nietypowe relacje i inne cuda)
Tylko nie radzi sobie np. z unią, a jak zrobi joiny to ja nie ogarniam kiedy zrobi left joina a kiedy right. ja tego używam tylko wtedy kiedy nazwy pól w tabelach nie są unikatowe dla całej bazy.
Jesli chodzi o podpowiadanie to ja SQLDBX uzywam - ale nie dlatego ze podpowida tylko dlatego jest bezinstalacyjne, plik wykonywalny ma 2MB i jesli u klienta mam tylko zdalny pulpit i nie ma narzedzi SQL to sie sprawdza bardzo dobrze.