Temat: ewidencjonowanie faktur i przepływ informacji między...

Witam,
mam za zadanie zrobić bazę danych w Accessie 2007, która będzie miała za zadanie gromadzić kopie faktur i kilka informacji o nich. Cały proces wprowadzania danych o fakturach i ich zatwierdzania ma przebiegać w sposób następujący:
1) Dział administracji kopiuje fakturę i zamieszcza ją w formie pdf w bazie oraz uzupełnia kilka informacji o tej fakturze, tzn. nr faktury, data wprowadzenia, termin płatności itp. Po wprowadzeniu danych pracownik administracji zapisuje ją.
2) Następnie ten sam pracownik wybiera jednego z kierowników działów (produkcji, inżynierii, jakości itp.) do którego wysyła informację o konieczności opisania faktury. Informacja ta powinna być wysyłana na maila wybranego kierownika automatycznie oraz powinny do niego przychodzić ponaglenia o konieczności opisania faktury co 24h, jeśli tego nie zrobi od razu. Wyobrażam sobie to tak, że pracownik działu administracji wybiera kierownika Jana Kowalskiego po czym klika przycisk "Wyślij fakturę", co jest równoznaczne wysłaniem maila w którym będzie znajdował się odnośnik do bazy danych. Zanim kierownik działu zacznie opisywać fakturę, powinien mieć możliwość zatwierdzenia lub odrzucenia danych wprowadzonych przez pracownika administracji i wysłaniu mu informacji zwrotnej z opisem popełnionych błędów. Kierownik działu powinien mieć możliwość jedynie podglądu danych wprowadzonych przez pracownika administracji, np. w raporcie. W przypadku zatwierdzenia wprowadzonych danych, kierownik działu powinien mieć możliwość opisania faktury (jedno pole w którym będzie wpisany tekst - kilka zdań). Kierownik działu powinien mieć również możliwość delegowania uprawnień do opisania faktury dla jednego ze swoich pracowników z działu, jednak sam powinien później zatwierdzić ten opis. Wyjątkiem byłaby sytuacja, gdyby kierownik przeszedł na urlop. Wtedy miałby możliwość delegowania pełnych uprawnień dla jednego ze swoich podwładnych (wraz z zatwierdzaniem opisu faktury).
3) Po zatwierdzeniu opisu faktury kierownik działu (lub jego podwładny, jeśli to on opisywał i zatwierdzał fakturę) powinien ją wysłać do działu księgowości, który otrzymuje kopię faktury oraz odpowiadające jej informacje wprowadzone przez dział administracji oraz opis faktury. Najlepiej gdyby to było w formie raportu, który później będzie można wydrukować. Dział księgowości powinien również mieć możliwość zatwierdzenia lub odrzucenia nadesłanych danych przez kierownika działu oraz wysłania mu informacji zwrotnej nt. koniecznych poprawek itp.

Czy jest możliwe zrealizowanie opisanego przeze mnie przepływu między działami?

Czy jest możliwe delegowanie uprawnień dla podwładnych przez kierownika działu?

Proszę o jakieś wskazówki, jak ugryźć taką bazę? Od czego zacząć?

Temat: ewidencjonowanie faktur i przepływ informacji między...

duzo Ci zaproponowali za ten projekt? jesli tyle ile to jest warte to doradz zeby ktos poszukal jakiegoś rozwiązania workflow na rynku (nawet nie jakieś wypasione, ale przy okazji zakupu marnego softu fin-ksieg mozna takie ułomne rozwiązanie znależć. to tyle zeby CIę do tego zniechęcic.

przerazajaca jest prosba "jak to ugryzc" bo z takim podjesciem sukcesu nie
wróże, a nie oczekuj ze forum odwali za Ciebie kawał ciężkiej roboty.

1). przy całej mojej wiedzy access nawet w wersji 2007 nie trzyma żadnych pdf, więc kopiowanie i zamieszanie w bazie to troche inny proces.
w accesie najwyzej mozesz sobie jakiegos linka stworzyc do tego pdf
reszta w pkt 1. to misz-masz - trescu niewiele, ale pomiesanie procesow z poplątaniem. musisz usiąść i rozpisac to jak się należy, na procesy, i pola ktore bedziesz potrzebowal, a dalej juz łatwiej usiąść do tabel
samo wprowadzenie faktury to jest formularz z polami o ktorych wspomniales, ale na moje oko to masz co najmniej 3 rzeczy do zrobienia:
- pracownik siada i uzupelnia jak sie nalezy wiec klik zapisz i po robocie
-- pracownik siada i uzupelnia, ale zanim skonczy musi sprawdzic poprzednia z jakiegos powodu (bo moze sie pomylil) i co? w polowie zamyka a informacje? znikają? zapisują sie tyle ile wpisaL? a jak zapomnie uzupelnic?
--- a jak sprawdzi poprzednia i okaze sie ze jednak sie pomylil to moze poprawic? (ale jak z pkt2 juz wyslal dalej do akceptacji szefowi?) to nie moze poprawic? szef ma akcpetowac błedy? a jak poprawi pomijajac wszystko inne, to rekord powinien byc zaktualizowany, czy moze zapisany nowy ver.2? poprawic mozna raz czy więcej? w okreslonyum czasie czy sprzed 5 lat tez? a poprawic moze autor czy ktos jeszcze?

to jest kilka pomysłów tylko (dotyczacych 1 punktu), więc pomysl i moze zmiec podejście,bo szkoda Twoich nerwow i wysiłku.

przy 1 punkcie nawet nie zająknąłeś się o bardzo waznym problemie tj. dostpie do bazy. jak kierowników duzo, zakladam ze pracowników co najmniej tyle samo. czytales jak ugryzc temat jednoczesnego dostępu do bazy?

zrealizowanie jest mozliwe, ale to dużo pracy, access jest ok generalnie, ale tutaj się malutki trochę wydaje.

ps. gdybys wpadł na pomysl pewncyh kompromisow (np. umawiamy sie ze nie poprawiamy i uzupelniamy do konca od razu rekord) to od razu pomysl do kosza mozesz wyrzucic, bo łatwiej będzie przesłać tabelkę w excelu do uzupełnienia.
pozdrawiam
tomek

Temat: ewidencjonowanie faktur i przepływ informacji między...

Nie oczekuję, że forum za mnie odwali całą robotę tylko chciałem zapoznać się z pomysłami innych bardziej doświadczonych ode mnie osób na ten temat. Chodzi mi głównie o to jak rozwiązać przepływ pracy nad bazą danych między działami. Jeśli znajdę na to jakieś rozwiązanie to z resztą powinienem sobie poradzić. Myślę o integracji bazy danych w Accessie z Windows SharePoint Services. Jeśli chodzi o zamieszczanie kopii faktur w formie pdf to będzie ono się odbywać na zasadzie zamieszczania załączników.
Jeśli chodzi o zatwierdzanie lub odrzucanie wprowadzonych danych to odbywałoby się to w ten sposób, że pracownik administracji wprowadza dane w formularzu i wysyła raport do odpowiedniego kierownika działu, jednak cały czas ma możliwość edytowania danych wprowadzonych w formularzu, więc jeśli otrzyma informację o jakimś błędzie to zmieni dane i odeśle wersję poprawioną.
A ile Ty byś sobie zażyczył za taki projekt? Nie sądzę żeby ten projekt był AŻ TAK pracochłonny jak sugerujesz.
Pozdrawiam,
Łukasz

Temat: ewidencjonowanie faktur i przepływ informacji między...

Tomasz J.:
duzo Ci zaproponowali za ten projekt? jesli tyle ile to jest warte to doradz zeby ktos poszukal jakiegoś rozwiązania workflow na rynku (nawet nie jakieś wypasione, ale przy okazji zakupu marnego softu fin-ksieg mozna takie ułomne rozwiązanie znależć. to tyle zeby CIę do tego zniechęcic.
przerazajaca jest prosba "jak to ugryzc" bo z takim podjesciem sukcesu nie
wróże, a nie oczekuj ze forum odwali za Ciebie kawał ciężkiej roboty.

No, niestety, ale muszę się tutaj z Panem Tomaszem całkowicie zgodzić.

Sprawa nie jest wcale taka prosta, jak by się mogło wydawać (pozornie), bo w praktyce wyjdą różne dodatkowe rzeczy.
Do tego, ja jako osoba dobrze znająca Accessa z racji pisania takich aplikacji, również zastanawiam się, jak Pan Łukasz chce sobie z tym dać radę skoro oczekuje jakiś sugestii w tej sprawie?
Trzeba od razu wiedzieć, jakie rzeczy da się zrobić w Accessie, a jakich nie i co z tym można zrobić dalej (wykorzystanie funkcji serwera, innych aplikacji itp.).
No a już robienie tego za tzw. "free", to dopuszczalne wyłącznie w ramach np. pracy dyplomowej czy innej tego rodzaju.

1). przy całej mojej wiedzy access nawet w wersji 2007 nie trzyma żadnych pdf

Niezupełnie, Panie Tomaszu. W 2007 można trzymać pliki w załącznikach, a więc tam można podpiąć PDF-a. Jednak nie będzie możliwości wyświetlenia PDF-a bezpośrednio, np. w rekordzie. Trzeba będzie otworzyć załącznik.
Można też wymusić na pracownikach skanowanie pliku i do PDF, i do JPG - bo jak rozumiem będzie się to odbywało w jakimś urządzeniu wielofunkcyjnym (np. w drukarce ze skanerem, podłączonej do sieci), która ma takie możliwości.
Można by było wtedy podpinać plik PDF jako załącznik, a plik graficzny wyświetlany byłby w samym rekordzie, np. w formularzu. Chociaż do zastanowienia jest, czy to w ogóle byłoby potrzebne.
Nawiasem mówiąc, to od razu zastanawiam, jak to będzie z tym skanowaniem faktur przez każdego z pracowników do PDF - z doświadczenia wiem, że ludzie nie radzą sobie z taką czynnością, nawet w urządzeniu wielofunkcyjnym.
Przecież taki skan PDF trzeba gdzieś wysłać, choćby na swój e-mail, aby go móc potem podłączyć. No to od razu pytanie, czy ktoś będzie wiedział, że PDF-a z załącznika trzeba zapisać, aby móc go potem dodać do bazy danych?
Ech, tu jeszcze kwestia ustalenia, gdzie miałyby być te PDF-y przechowywane.

Dalej: jeśli to aplikacja, do której miałby być dostęp dla każdego pracownika, to musi pracować w sieci. To się wiąże z koniecznością umieszczenia odpowiednich danych na jakimś serwerze, a czy w firmie jest serwer?
Prawidłowo również powinno być tak, że same dane powinny być rozdzielone od aplikacji-interfejsu, po to, aby była możliwa wielodostępność, archiwizowanie danych, aby nie zapychać sieci ciągnięciem wielu MB danych itd.
Czyli optymalnie to: baza danych, np. MSSQL Server (np. darmowy Express), Firebird, MySQL, a na każdym komputerze klienckim - baza danych Accessa, która miałaby podłączone tabele z bazy danych na serwerze, z serwerów SQL, jak wyżej wymieniłam.

Łukasz K.:
powinny do niego przychodzić ponaglenia o konieczności
opisania faktury co 24h, jeśli tego nie zrobi od razu

W zasadzie, w Accessie niemożliwe jest, aby stworzyć taki system ponagleń co 24 godziny. Precyzując: musiałaby być gdzieś non-stop otwarta aplikacja, która sprawdzałaby, czy faktura została opisana i wysyłała ponaglenie. Do tego musiałaby zbierać informację o czasie wysyłki ostatniego ponaglenia, aby na podstawie tego - wysłać następne.
Inne rozwiązanie, to sprawdzanie stanu i ewentualne wysyłanie ponagleń, gdy ktoś otwiera aplikację. Ale co, jeśli nikt w ciągu 24 godzin nie otworzy aplikacji? Albo nie będzie dostępu do Internetu (zakładam wysyłkę ponagleń e-mailem)? Zresztą takie ponaglenia powinny być realizowane z serwera.
Być może trzeba by było zrobić osobną bazę danych Accessa na serwerze, która korzystałaby z danych użytkowników, ale jej głównym zadaniem byłoby właśnie weryfikowanie stanów wypełnienia danych i inne tego typu procedury.
Musiałaby być cały czas uruchomiona.

Sprawa delegowania uprawnień do opisywania faktury, to jeszcze więcej pytań i wątpliwości. W jaki sposób nadane uprawnienia miałyby być odbierane? Co, jeśli kierownik wraca z urlopu, a delegował uprawnienie panu X?
Jak zapomni mu odebrać uprawnienie, to co?
Czy może będziemy wpisywać czas urlopu kierownika i z datą powrotu automatycznie wyłączamy uprawnienia panu X? A jeśli kierownik przedłuży urlop albo wróci z urlopu wcześniej?

Tylko do takiej funkcjonalności z tym przeniesieniem uprawnień to cały jeden moduł, chyba najtrudniejszy do realizacji, ze względu na powiązania, możliwe wydarzenia i zdarzenia występujące w rzeczywistości - sedno tkwi w opracowaniu algorytmu, diagramu zależności, a nie w tworzeniu tabel i oprogramowaniu bazy Accessa.

Przy pisaniu takich aplikacji pojawiają się dodatkowe pytania, które powinny być zadane, bo wiele zagadnień będzie miało wpływ na przyjęte rozwiązania, aby nie było komplikacji w przyszłości:
* ilość użytkowników;
* konfiguracje komputerów;
* posiadane wersje aplikacji;
* uprawnienia użytkowników na komputerach klienckich;
* dostęp do sieci, Internetu z komp. klienckich;
* czy profile są w domenie, czy lokalnie;
* dostęp do serwera;
* dostęp do bazy danych SQL;
* jakie oprogramowanie do obsługi poczty jest zainstalowane na komp. klienckich
* i wiele innych...

Np. tutaj ważne byłoby, czy w firmie jest używany Outlook Express, MS Outlook (w której wersji?), czy może np. używany jest Bat, Thunderbird, czy inne oprogramowanie do obsługi poczty - od tego będą zależeć przyjęte rozwiązania, bo jeśli jest mieszanka w firmie, to może się okazać, że pewnej funkcjonalności nie da się zrobić.

Tomasz J.:
zrealizowanie jest mozliwe, ale to dużo pracy, access jest ok generalnie, ale tutaj się malutki trochę wydaje.

To jest możliwe do realizacji, ale trzeba mieć pojęcie o możliwościach Accessa i o jego brakach. Trzeba umieć w takim przypadku znaleźć sprytne rozwiązanie, czasem z wykorzystaniem innego programu.
Trzeba mieć doświadczenie w realizacji już jakiejś aplikacji w Accessie, zwłaszcza pracującej w sieci.
Inaczej można popełnić wiele błędów już na poziomie tworzenia struktury bazy (bardzo częsty błąd), które potem komplikują dalsze działania i np. dodają więcej pracy, zamiast jej odejmować. Często potem okazuje się, że tak naprawdę, to całość trzeba by było od początku przebudować, aby wszystko miało ręce i nogi.

Jeśli Pan Łukasz chciałby realizować ten projekt, to będzie to bardzo trudne, jeśli oczekuje pomysłów na rozwiązanie poszczególnych zagadnień. To czeka Pana, Panie Łukaszu wiele nauki, a i czas na realizację znacznie się wydłuży.
Być może warto rozważyć możliwość współpracy z kimś bardziej obeznanym, zwłaszcza jeśli np. robi to Pan jako jakąś pracę na uczelni.
Ale nie wyobrażam sobie, aby to była praca na zaliczenie, bo to zdecydowanie za dużo roboty, chyba że na początek robimy część funkcjonalności, a rozwijamy całość, np. w ramach dalszych prac zaliczeniowych albo kończymy jako pracę dyplomową.

Temat: ewidencjonowanie faktur i przepływ informacji między...

Łukasz Kuriata:
A ile Ty byś sobie zażyczył za taki projekt? Nie sądzę żeby ten projekt był AŻ TAK pracochłonny jak sugerujesz.

Panie Łukaszu - bez obrazy, ale to stwierdzenie właśnie świadczy o tym, że nie ma Pan doświadczenia w tworzeniu podobnych aplikacji.
I nie chodzi o to, aby Pana zniechęcić, ale by miał Pan świadomość właśnie ogromu pracy, jaka stoi przed Panem.
To nie jest lekki temat bazy danych z kontaktami, które można stworzyć z kreatora Accessa.
Jeśli ja się podejmuję stworzenia takiej aplikacji (po bardzo szczegółowej analizie wymagań, tzw. "fotografii" stanowisk pracy i wielu, wielu pytaniach dotyczących różnych przypadków, które mogą zaistnieć), to nie szukam rozwiązań na forach, nie pytam innych - mam już pewną wiedzę i doświadczenie, więc tylko planuję co, gdzie i jak. A jak brakuje mi jakiegoś rozwiązania do zaplanowanej przeze mnie opcji, to szukam, np. konkretnej funkcji, np. jak zrobić DCount dla unikatowych rekordów, gdy nie można w niej używać DISTINCT albo czym to zastąpić. Ale nie zadaję pytań, tylko googluję, googluję aż coś mi przyjdzie do głowy.
Tu trzeba mieć np. wiedzę na temat działania systemów Windows, różnic, uprawnień użytkowników i związanych z tym problemów, co zrobić, aby nie zapychać sieci, co zrobić, aby nie zaczęło "mulić" itd.
Z takimi rzeczami borykają się twórcy nawet wielkich systemów typu ERP, jak np. CDN XL, SAP i inne. I to już po ich wdrożeniu, przerabiają takie rzeczy na co dzień, a przecież mają do dyspozycji ogromne narzędzia programistyczne i rozbudowaną infrastrukturę, doświadczonych programistów, gdzie w większości każdy zajmuje się tylko jakąś wydzieloną częścią, dziedziną.

Jeśli jest Pan ciekawy, ile może kosztować taka aplikacja, to proponuję zadzwonić do kilku firm zajmujących się tworzeniem oprogramowania "na miarę" (do firm, które już mają doświadczenie, a nie np. w serwisie Z.P.N, gdzie osoby, którym się wydaje, że dadzą sobie radę oferują wykonanie za 100 zł) i zapytać o cenę (można wysłać e-mail ze specyfikacją). Może Pan zasugerować rozwiązanie w Accessie, ale też pozostawić swobodę wyboru środowiska programistycznego.
Przykład: rozwiązanie rozliczania handlowców farmaceutycznych, oparte tylko na Excelu: 14-15 tys. zł.

Temat: ewidencjonowanie faktur i przepływ informacji między...

Widzisz, jesli zadjesz pytanie jak to w ogóle ugryźć - a niżej dodajesz ze nie sądzisz zeby był az tak pracochłonny, to smiało próbuj. to Twój czas, Twoja praca, Twoja frustracja, Twoje rozczarowanie efektem.

to nie będzie zamykał formularza? nie obrażaj się, ale spóbuj sobie rozpisac ten proces na części składowe, musisz przewidzieć wszystkie mozliwe zachowania userów.

wiesz, po tej wypowiedzi ciekawi mnie jescze jedna rzecz. do czego w efekcie ta baza ma służyć, bo to pytanie zasadnicze. tylko i wyłącznie do fajnego gadzetu z interfejsem dla usera "kliknij" "wyslij" "odrzuc" akceputj"?

nic bym sobie nie zażyczył, access słuzy mi jedynie po drodze robienia innych rzeczy.

Łukasz Kuriata:
Nie oczekuję, że forum za mnie odwali całą robotę tylko chciałem zapoznać się z pomysłami innych bardziej doświadczonych ode mnie osób na ten temat. Chodzi mi głównie o to jak rozwiązać przepływ pracy nad bazą danych między działami. Jeśli znajdę na to jakieś rozwiązanie to z resztą powinienem sobie poradzić. Myślę o integracji bazy danych w Accessie z Windows SharePoint Services. Jeśli chodzi o zamieszczanie kopii faktur w formie pdf to będzie ono się odbywać na zasadzie zamieszczania załączników.
Jeśli chodzi o zatwierdzanie lub odrzucanie wprowadzonych danych to odbywałoby się to w ten sposób, że pracownik administracji wprowadza dane w formularzu i wysyła raport do odpowiedniego kierownika działu, jednak cały czas ma możliwość edytowania danych wprowadzonych w formularzu, więc jeśli otrzyma informację o jakimś błędzie to zmieni dane i odeśle wersję poprawioną.
A ile Ty byś sobie zażyczył za taki projekt? Nie sądzę żeby ten projekt był AŻ TAK pracochłonny jak sugerujesz.
Pozdrawiam,
Łukasz

Temat: ewidencjonowanie faktur i przepływ informacji między...

Sprawa nie jest wcale taka prosta, jak by się mogło wydawać (pozornie), bo w praktyce wyjdą różne dodatkowe rzeczy.
Do tego, ja jako osoba dobrze znająca Accessa z racji pisania takich aplikacji, również zastanawiam się, jak Pan Łukasz chce sobie z tym dać radę skoro oczekuje jakiś sugestii w tej sprawie?
Trzeba od razu wiedzieć, jakie rzeczy da się zrobić w Accessie, a jakich nie i co z tym można zrobić dalej (wykorzystanie funkcji serwera, innych aplikacji itp.).

Dokładnie tak. czym innym jest pytanie czy z tabeli można wyciągnąć niekompeltny rekord (np. 5 z 16 pól) i go zakutlaizować, a czym innym pytanie jak ugryźć taki temat.

1). przy całej mojej wiedzy access nawet w wersji 2007 nie trzyma żadnych pdf

Niezupełnie, Panie Tomaszu. W 2007 można trzymać pliki w załącznikach, a więc tam można podpiąć PDF-a. Jednak nie będzie możliwości wyświetlenia PDF-a bezpośrednio, np. w rekordzie. Trzeba będzie otworzyć załącznik.

tak, to mój skrót myślowy. pytanie padło o bazę i pdf w niej (jak rozumiem mam pliczek mdb i tam wszystko), a co innego miec mdb i 15000 pdf;) załączniki kopmlikują sprawę, bo dochodzi kwestia trzymania tego gdzieś na sieci, a także zarządzania uprawnieniami.

teoretycznie to nawet zeskanowanego pdf można przebić na postać binarną i zapisać go jako string,a albo memo;)

Pani Moniko, dziękuję za dobre słowo - ja człowieka nie chcę dołować, ale widać generalnie porywanie się z motyką na Słońce. Ja rozumiem ducha walki i siłę do przenoszenia gór, ale jednak zyejmy w realnym świecie, i możliwości na te realia trzeba przekładać.

Można też wymusić na pracownikach skanowanie pliku i do PDF, i do JPG - bo jak rozumiem będzie się to odbywało w jakimś urządzeniu wielofunkcyjnym (np. w drukarce ze skanerem, podłączonej do sieci), która ma takie możliwości.
Można by było wtedy podpinać plik PDF jako załącznik, a plik graficzny wyświetlany byłby w samym rekordzie, np. w formularzu. Chociaż do zastanowienia jest, czy to w ogóle byłoby potrzebne.
Nawiasem mówiąc, to od razu zastanawiam, jak to będzie z tym skanowaniem faktur przez każdego z pracowników do PDF - z doświadczenia wiem, że ludzie nie radzą sobie z taką czynnością, nawet w urządzeniu wielofunkcyjnym.
Przecież taki skan PDF trzeba gdzieś wysłać, choćby na swój e-mail, aby go móc potem podłączyć. No to od razu pytanie, czy ktoś będzie wiedział, że PDF-a z załącznika trzeba zapisać, aby móc go potem dodać do bazy danych?
Ech, tu jeszcze kwestia ustalenia, gdzie miałyby być te PDF-y przechowywane.

Dalej: jeśli to aplikacja, do której miałby być dostęp dla każdego pracownika, to musi pracować w sieci. To się wiąże z koniecznością umieszczenia odpowiednich danych na jakimś serwerze, a czy w firmie jest serwer?
Prawidłowo również powinno być tak, że same dane powinny być rozdzielone od aplikacji-interfejsu, po to, aby była możliwa wielodostępność, archiwizowanie danych, aby nie zapychać sieci ciągnięciem wielu MB danych itd.
Czyli optymalnie to: baza danych, np. MSSQL Server (np. darmowy Express), Firebird, MySQL, a na każdym komputerze klienckim - baza danych Accessa, która miałaby podłączone tabele z bazy danych na serwerze, z serwerów SQL, jak wyżej wymieniłam.

Łukasz K.:
powinny do niego przychodzić ponaglenia o konieczności
opisania faktury co 24h, jeśli tego nie zrobi od razu

W zasadzie, w Accessie niemożliwe jest, aby stworzyć taki system ponagleń co 24 godziny. Precyzując: musiałaby być gdzieś non-stop otwarta aplikacja, która sprawdzałaby, czy faktura została opisana i wysyłała ponaglenie. Do tego musiałaby zbierać informację o czasie wysyłki ostatniego ponaglenia, aby na podstawie tego - wysłać następne.
Inne rozwiązanie, to sprawdzanie stanu i ewentualne wysyłanie ponagleń, gdy ktoś otwiera aplikację. Ale co, jeśli nikt w ciągu 24 godzin nie otworzy aplikacji? Albo nie będzie dostępu do Internetu (zakładam wysyłkę ponagleń e-mailem)? Zresztą takie ponaglenia powinny być realizowane z serwera.
Być może trzeba by było zrobić osobną bazę danych Accessa na serwerze, która korzystałaby z danych użytkowników, ale jej głównym zadaniem byłoby właśnie weryfikowanie stanów wypełnienia danych i inne tego typu procedury.
Musiałaby być cały czas uruchomiona.

Sprawa delegowania uprawnień do opisywania faktury, to jeszcze więcej pytań i wątpliwości. W jaki sposób nadane uprawnienia miałyby być odbierane? Co, jeśli kierownik wraca z urlopu, a delegował uprawnienie panu X?
Jak zapomni mu odebrać uprawnienie, to co?
Czy może będziemy wpisywać czas urlopu kierownika i z datą powrotu automatycznie wyłączamy uprawnienia panu X? A jeśli kierownik przedłuży urlop albo wróci z urlopu wcześniej?

Tylko do takiej funkcjonalności z tym przeniesieniem uprawnień to cały jeden moduł, chyba najtrudniejszy do realizacji, ze względu na powiązania, możliwe wydarzenia i zdarzenia występujące w rzeczywistości - sedno tkwi w opracowaniu algorytmu, diagramu zależności, a nie w tworzeniu tabel i oprogramowaniu bazy Accessa.

Przy pisaniu takich aplikacji pojawiają się dodatkowe pytania, które powinny być zadane, bo wiele zagadnień będzie miało wpływ na przyjęte rozwiązania, aby nie było komplikacji w przyszłości:
* ilość użytkowników;
* konfiguracje komputerów;
* posiadane wersje aplikacji;
* uprawnienia użytkowników na komputerach klienckich;
* dostęp do sieci, Internetu z komp. klienckich;
* czy profile są w domenie, czy lokalnie;
* dostęp do serwera;
* dostęp do bazy danych SQL;
* jakie oprogramowanie do obsługi poczty jest zainstalowane na komp. klienckich
* i wiele innych...

Np. tutaj ważne byłoby, czy w firmie jest używany Outlook Express, MS Outlook (w której wersji?), czy może np. używany jest Bat, Thunderbird, czy inne oprogramowanie do obsługi poczty - od tego będą zależeć przyjęte rozwiązania, bo jeśli jest mieszanka w firmie, to może się okazać, że pewnej funkcjonalności nie da się zrobić.

Tomasz J.:
zrealizowanie jest mozliwe, ale to dużo pracy, access jest ok generalnie, ale tutaj się malutki trochę wydaje.

To jest możliwe do realizacji, ale trzeba mieć pojęcie o możliwościach Accessa i o jego brakach. Trzeba umieć w takim przypadku znaleźć sprytne rozwiązanie, czasem z wykorzystaniem innego programu.
Trzeba mieć doświadczenie w realizacji już jakiejś aplikacji w Accessie, zwłaszcza pracującej w sieci.
Inaczej można popełnić wiele błędów już na poziomie tworzenia struktury bazy (bardzo częsty błąd), które potem komplikują dalsze działania i np. dodają więcej pracy, zamiast jej odejmować. Często potem okazuje się, że tak naprawdę, to całość trzeba by było od początku przebudować, aby wszystko miało ręce i nogi.

Jeśli Pan Łukasz chciałby realizować ten projekt, to będzie to bardzo trudne, jeśli oczekuje pomysłów na rozwiązanie poszczególnych zagadnień. To czeka Pana, Panie Łukaszu wiele nauki, a i czas na realizację znacznie się wydłuży.
Być może warto rozważyć możliwość współpracy z kimś bardziej obeznanym, zwłaszcza jeśli np. robi to Pan jako jakąś pracę na uczelni.
Ale nie wyobrażam sobie, aby to była praca na zaliczenie, bo to zdecydowanie za dużo roboty, chyba że na początek robimy część funkcjonalności, a rozwijamy całość, np. w ramach dalszych prac zaliczeniowych albo kończymy jako pracę dyplomową.

Temat: ewidencjonowanie faktur i przepływ informacji między...

Dziękuję za rady i krytykę. Jako osoba z natury ambitna staram się stawiać czoła trudnym wyzwaniom. Nawet jeśli czegoś nie wiem to próbuję na różne sposoby poznać temat. Mój post na tym forum nie oznacza, że nie korzystałem z innych źródeł, chociaż pytanie ogólne "jak to ugryźć" mogło tak sugerować. Doświadczenie w realizacji baz danych pewne mam jednak nie realizowałem baz pracujących w sieci oraz z wieloma użytkownikami, wiec przyznam, że jestem w tej kwestii zielony.
Jeśli nie dojdę do rozwiązań, które interesują firmę tzn. przede wszystkim flow między działami, (a widzę, że będzie z tym problem) to zaproponuję po prostu taką funkcjonalność tej bazy, którą będę w stanie zrealizować.
Najprostszym rozwiązaniem z mojej strony będzie umożliwienie rejestracji faktury przez pracownika administracji. Następnie pracownik ten wygeneruje raport z zarejestrowaną fakturą i wyśle (w formie pdf) na e-mail do odpowiedniego kierownika działu, od którego otrzyma opis faktury w jakiejś formie (choćby jako odpowiedź na e-maila) i wprowadzi ją do accessowej bazy, uzupełniając w ten sposób wszystkie dane dotyczące faktury. Następnie będzie wygenerowany kolejny raport, który w formie pdf trafi do księgowości.
Pomysł to być może dość prymitywny i nie eliminuje wielu błędów jakie mogą zajść, ale mimo wszystko usprawnia obecny system, polegający na kserowaniu faktur oraz wprowadzaniu danych w Excelu.

Temat: ewidencjonowanie faktur i przepływ informacji między...

wysyłanie maili o określonych godzinach:

sktypt VBS pobierający dane za pomocą ADO dane z pliku mdb umieszczonego na dysku sieciowym, odwołanie w postaci \\serwer\udział\katalog\plik.mdb

wysyłanie maila za pomocą CDO + serwer SMTP, w niektórych przypadkach wystarczy ten od IIS-a dostarczanego z windowsem XP PRO, tudzież inny wynalazek jak jest dostęp np. exchange lub dowolny inny, CDO ma mozliwość podania w parametrach (trochę dziwnie się to robi) serwer-a, portu, usera i hasła, poczta może być w HTML-u, de fakto Outlook jest w takim procesie zbędny

do przechowywania danych fajny by był MSSQL 2008 R2 Express -> można trzymać do 10 GB danych w bazie, co w porównaniu z 2 GB na plik mdb jest niezłym skokiem

Temat: ewidencjonowanie faktur i przepływ informacji między...

Podzielam zdanie,iż temat nie jest prosty. Powiem szczerze, że jest to bardzo rozbudowany projekt w który najeży zaangażować, księgowość, kontrolę kosztów, jednostki biznesowe generujące koszty, tak aby ogarnąć wszystko.

Z tego co piszesz to firma che abyś napisał autorską aplikację ERP. Takie programowanie wymaga podejścia projektowego ze szczegółowym opisem wymagań.

Sam brałem udział od strony biznesowej w jednym z etapów prac nad upgrade-m programu księgowego Epicor do wersji Epicor9 gdzie właśnie będzie funkcjonalność o której piszesz - czyli elektroniczny obieg dokumentów( wstępna rejestracja dokumentów, skanowanie do pliku, elektroniczna akceptacja kosztów zależnie od kwoty itd.)

Powiem Ci tylko tyle, że jest to długi i czasochłonny proces z którym sam raczej sobie nie poradzisz ( bez obrazy ).

Lepiej będzie jak wyślecie zapytanie o informację z wymaganiami do 3-5 firm które zajmują się tym profesjonalnie i zobaczycie ile będzie to kosztowało. Jak policzysz sobie w przybliżeniu ile będzie kosztowała praca twoja i innych osób zaangażowanych w firmie to może wcale nie wyjdzie dużo drożej ( bo przecież nawet wewnętrzna praca też generuje koszty). Weź też pod uwagę, iż z wieloma problemami nie poradzicie sobie od razu, a to wydłuży wdrożenie projektu. Profesjonalne firmy mają gotowe rozwiązania na taki work-flow, które będzie trzeba tylko zmodyfikować pod wasze wymagania.

Vendor, który zrobi to dla was na mocy podpisanej umowy będzie musiał np. świadczyć maintenance, a to jest kluczowe.

Temat rzeka.
:-)

pozdrawiam