🚀 go-pugleaf

Witam,
ponieważ wlochacz, jest bardzo ciekawy dlaczego (a noc dluga byla i w
chwilach relaxu, cos tam napisalem), dlatego ponizej podaje kilka
zasadniczych powodow, dla ktorych moim zdaniem przyjeta przeze mnie
filozofia w moim projekcie jest optymalna (wlochacz to material do
przemyslen dla Ciebie :-))


Projekt to klasa Aplikacji ERP/MRP/CRM

   (wymieniam tylko to co powinno pozwolic Ci zrozumiec dlaczego dane
pobrane lokalnie jest optymalnie trzymac w MemoryDataSet,
   oczywiscie dane sa pobierane automatycznie w oparciu o relacje
zdefiniowane w DM na TIBTable. Poza tym w takim rozwiazaniu podmiana
   bazy danych nie jest duzym problemem, co tez na pewnym etapie
tworzenia projektu bylo brane pod uwage)

1. Funkcjonalnosci :
   pelna obsluga gospodarki magazynowej w czasie rzeczywstym (FIFO/
LIFO liczone zgodnie z algorytmem w danej chwili, nie po
   zamknieciu okresu ewentulanie inne cuda (przelicz w cenach zakupu
czy jakies tam wynalazki). Co oznacza, ze dla pozycji
   przyjetej np. w 30 roznych cenach zakupu, stanowiacej np stan =
200, pozycja dokumentu sprzedazy rozchodujaca te 200 szt,
   bedzie jedna, natomiast algorytm FIFO/LIFO sobie sam poradzi z
prawidlowym rozchodem tych 200 szt. kontrolujac po drodze
   np. to czy na dzien wystawienia dokumentu sprzedazy jest wymagany
stan magazynu.

). Każdy dokumentu moze byc
   automatycznie ksiegowany w ksiedze handlowej zgodnie z definicja :
   - cel zakupu / sprzedazy
   - podstawy podatkow w stawkach VAT
   - kwoty VAT dla poszczegolnych stawek
   - drukowany jako kod EAN
   - podlegajacy usludze MWS (magazyn wysokiego skladowania)

2. Sprzedaz w dowolnej walucie
   - kazdy doument sprzedazy (zwiazny z podatkiem VAT jest
automatycznie ksiegowany)
   na np. FV moze byc dowolna sprzedaz ze wzgledu na jej cel np.
   - sprzedaz wyrobu
   - sprzedaz towaru
   - sprzedaz uslugi

   kazda z tych pozycji to inna 7 (konto zespolu 7 z planu kont),
czyli dokument musi byc zaksiegowany nie dosc, ze w stawkach i
podstawach VAT,
   to jeszcze musi byc zaksiegowany na okreslone 7-mki, w stawkach i
podstawach VAT. Co zgodnie z zasadami matematyki (suma iloczynow <>
iloczynu sumy)
   spowoduje zaokraglenia (czyli suma dokumentu <> zaksiegowanych
pozycji w ujeciu podstawy i vat i 7). To trzeba przed wyslaniem do
bazy
   walidowac. W MemoryDataSet mozna to wszystko przygotowac i wyslac
spojna postac danych koncowych do bazy danych.


3. Ksiega handlowa - full wypas, srodki trwale, platnosci
elektroniczne, automatyczne wyliczenie roznic kursowych (dla ludzi
kodujacych ERP'y, zmora,
   szczegolnie kompensowanie tych transakcji)

1. Sorotwanie zawartosci dokumentu (potrzebne utworzenie indeksow,
czesto dynamicznie i ponumerowanie pozycji dokumentu zgodnie z nowym
porzadkiem)
2. Agregowanie zawartosci dokumentu (sumowanie po indeks, EAN, cena,
ilosc, ewentualnie innych definiowalnych kryteriach)
3. Komentowanie pozycji dokumentow (pola blob), sumy posrednie
bezposrednio w widoku dokumentu .... (czyli suma np. po x- pozycjach)
4. Pelna walidacja kompletnej postaci danych (zaokraglenia, wartosci w
walucie, sprawdzenie zgodnosci dekretu WN/MA.
   Z tego powodu dokumenty zazwyczaj (jedyne sluszne rozwiazanie) sa
sumowame w podstawach stawek podatku VAT (od netto lub od brutto)).
Dokument w walucie, dodatkowo
   musi byc przeliczony do postaci odpowiadajacej zasadzie "wydruk
musi sie zamykac w walucie dokumentu", co oznacza przeliczenie PLN na
walute (jezeli masz rabaty
   rabat do cen w pozycjach to sytuacja sie dodatkowo komplikuje (kurs
to liczba #.0000, wynik to liczba #.00), z czego ponownie z waluty na
PLN, aby zaksiegowac w PLN)
5. Obsluga transakcji (pelna kontrola atomowosci transakcji w ujeciu
Firebird'a, czyli transakcji wspolbieznych)
6. Pelna transparentnosc Aplikacji w stosunku do bazy danych (oznacza
n-edycji tego samego dokumentu, w tym samym czasie, z obsluga
ewentualnych wyjatkow transakcyjnych)
7. Obsluga mozliwie najmniejszej liczby komponentow TTransaction (tzn.
model jednej globalnej transakcji w obrebie calej Aplikacji)
8. Kontrola FIFO / LIFO na okreslony dzien
9. Baza danych w tym modelu, nie wie co jest w edycji, jest tylko i
wylacznie uzywana do skladowania danych i ich raportowania
10. Wygodna obsluga laczenia dokumentow w jeden dokument (np. FV do n
Wz)
11. W modelu opartym na lokalnym przechowywaniu zawartosci kazdego
dokumnetu (kazdego obiektu biznesowego projektu), bardzo prosto
zbudowac API Aplikacji,
    po prostu tworzysz obiekt nie pokazujac go uzytkownikowi i
wywolujesz zdarzenia tak jak by uzytkownik obrabial go. Masz zachowana
kontrole integralnosci
    danych i spojnosc kodu w obsludze tego typu operacji. Memory
DataSet'y zawsze maja opcje zapisu / odczytu z pliku ... (np. XML)