janosik-rdzeń

[Codin C. Cool]

W liście z wto, 09-09-2003, godz. 17:23, Michał Cichowicz pisze: 
> Jeżli dobrze rozumiem, to przekaz elektroniczny jest zrobiony (w sensie, że
> coś tam działa, że został dokument wysłany, że otrzymano potwierdzenie).

działa - do końca września. od 1 października format przekazu
elektronicznego ulega zmianie. nie wiem jak bardzo, miejmy nadzieję, że
nie chciało im się bardzo mieszać.

> Jeżeli chodzi o weryfikację, to albo ZUS się ugnie, albo trzeba będzie
> studiować stosy pisanych na kolanie ustaw, w których się nawet nie łapią te
> ciamajdy z okienek w ZUS-ie. Tu myślę, że jest sprawa o tyle prostsza, że
> ZUS nie powie, że nie nie wie kto ma to wiedzieć - bo jeśli nie ZUS, to kto?
> Jeżeli dobrze rozumiem ideę algorytmu tekstowego (tzn. nie wiem co to jest,
> ale próbuję zgadywać - a wydaje mi się, że to są kolejne makrodefinicje,
> jakiś pseudokod), to podstawowe pytanie jest: po co?

dobre pytanie - ja nie wiem po co.

>  Czy nie prościej jest
> stworzyć oddzielny moduł w C (zakładam, że w tym języku byłby stworzony
> rdzeń), gdzie były by tylko funkcje związane z weryfikacją, gdzie były by
> dwa parametry wskaźnikowe (dokument źródłowy, pole na wynik) na zasadzie:
> "int weryfikuj_gornika(); int weryfikuj_hutnika();" zależnie od przepisów.
> Takie cuś na pewno działa szybciej.

obawiam się że to nie takie proste (obym się mylił), bo to ile ma
człowiek wpłacić w danym momencie zależy od szeregu czynników, m.in. czy
nie był chory, czy nie dostawał zasiłków, czy do tej pory wpłaty były
regulowane w terminie, czy nie przysługuje mu ulga albo coś innego z
tytułu nadpłaty etc. niech ktoś kto zna się na księgowości napisze o co
w tym wszystkim chodzi.

> Sama budowa rdzenia nie wydaje mi się skomplikowana:
> 1. Moduł bazy danych. MySQL chodzi świetnie, projekt można zerżnąć z
> Płatnika II i trochę go poprawić, np. podowalać indeksy, poprzestawiać
> trochę pola. On by miał wszystkie funkcje związane z pobieraniem i
> zapisywaniem danych.

to jest pryszcz

> 2. Moduł weryfikacji i wyliczeń. (to powinno być razem).

tu jest główny problem

> 3. Moduł wydruku - tu może być pies pogrzebany, ponieważ tak jak pod Linuxem
> oficjalnym formatem jest postscript, tak pod Windą nie ma oficjalnego
> formatu i albo się będzie wykorzystywać ghostscripta (kolejny pakiet, co nie
> jest pod M$ czymś naturalnym), albo API, które jest pochrzanione (napisałem
> kiedyś pewien program w Delphi pod W'98 używając API - oczywiście pod XP nie
> działa).

moim skromnym zdaniem wydruki 1:1 były potrzebne gdy nie było przekazu
elektronicznego, bo musiały je chwytać zusowe OCRy. teraz mają chyba
znaczenie drugo, albo i trzeciorzędne.

> 4. Moduł przekazu elektronicznego.

miejmy nadzieję że nie będzie z nim problemu

> 5. Być może jeszcze jakiś (np. parzenia kawy).

z tym też ;)

> 
> Całoś byłaby splatana w GUI (ncurses, gtk+, qtlib, czy cokolwiek), ponieważ
> każde GUI ma swój własny pogląd na świat - to jest tak jak pisanie
> JavaScriptu pod IE, Netscape czy Mozillę - każdy jest trochę podobny i
> trochę różny.

ot, co

Plan działania:
1. znajdźmy kompetentną osobę obeznaną z kwestiami ZUSowych formularzy.
2. korzystając z jej pomocy stwórzmy moduł weryfikacji.
3. reszta przyjdzie sama.

-- 
Pozdrawiam
Paweł Hikiert (nsilent22)