Spisy zdawczo-odbiorcze - Archiwa państwowe z systemem ZoSIA

[crash0]

Taka refleksja, wyniesiona jeszcze z pracy dla AP z Poznania.
Archiwiści (Ci z archiwów państwowych, jak i Ci zakładowi, którzy będą chcieli przekazać dokumentację do AP), spisy zdawczo-odbiorcze najlepiej przyjąć/przygotować w postaci pliku Excel (najlepiej .csv, ale i .xls można potem zapisać w tym pierwszym formacie), zwłaszcza dotyczy to tych AP gdzie jest system ZoSIA. Łatwo wówczas zaimportować taki plik, poprzez kilka kliknięć

Nie polecam tabelek w .doc i tym podobnych, chyba że ktoś ma czas na zabawy

[Marek Gieroń]

Taka refleksja, wyniesiona jeszcze z pracy dla AP z Poznania.
Archiwiści (Ci z archiwów państwowych, jak i Ci zakładowi, którzy będą chcieli przekazać dokumentację do AP), spisy zdawczo-odbiorcze najlepiej przyjąć/przygotować w postaci pliku Excel (najlepiej .csv, ale i .xls można potem zapisać w tym pierwszym formacie), zwłaszcza dotyczy to tych AP gdzie jest system ZoSIA. Łatwo wówczas zaimportować taki plik, poprzez kilka kliknięć

Nie polecam tabelek w .doc i tym podobnych, chyba że ktoś ma czas na zabawy

ech....
http://www.ifar.pl/index.php/topic,3139.msg20353.html#msg20353

Idę o zakład, że 60% spisów w wersji elektronicznej to doc. jakieś 20% to .xls, reszta to "dziwadła".

[Marcin Buczek]

Czemu import tabelki z doc czy docx nie stanowi problemu. Problem pojawia się gdy spisy są podpisywane elektronicznie to w przypadku doc, docx są zamieniane do pdf i wtedy dopiero zaczyna się zabawa bo trzeba negocjować z podmiotem wersję edytowalną spisu, nie ma tego problemu przy xsl i xslx gdyż system tworzy dla nich plik Xades a oryginalny plik jest nieruszony. Ciekawą pomocą którą udostępnił ostatnio NAC to programik do sprawdzania spisów przed ich migracją do ZoSIA. Testując zauważyłem jeden błąd z którym system sobie nie radzi, to zapis w datach skrajnych anteriorów i posteriorów. Problem jest również w przypadku migracji do ZoSIA spisów dokumentacji osobowej która zawiera więcej pól niż standardowy spis i dobrze by było by programik pozwalał na łączenie danych z kilku kolumn w jedną

[Marcin Kapała]

Może czas pomyśleć o interfejsie dla archiwów zakładowych w systemie ZoSIA.

[Anna Sobczak]

NAC jakiś program dla archiwów zakładowych chyba jakiś czas temu rozwijał...

[Marcin Buczek]

Może czas pomyśleć o interfejsie dla archiwów zakładowych w systemie ZoSIA.

Tylko po co? Obecny system EZD PUW posiada wbudowany moduł archiwalny do obsługi archiwum zakładowego. Wiadomo nie od dziś że przyszłe EZD RP będzie w dużej mierze bardzo podobne do EZD PUW co najwyżej z eDok-a zaczerpnie trochę rozwiązań open source gdyż z tym obecny system ma problemy i w przeważającej większości składa się z komercyjnych rozwiązań np. baza, serwer. Już dziś powinniśmy przygotowywać integrację ZoSIA z EZD PUW w kontekście nowego modułu nadzoru który zastąpi aplikację NiKA. Połączenie tych dwóch systemów pozwoli na lepszą prace zarówno po stronie AP jak i archiwów zakładowych

[Jarek]

Oj, to na pewno nie tak powinno wyglądać. Po pierwsze - co do EZD PUW - skąd pewność że przyszły system rzeczywiście będzie bardzo podobny do EZD PUW? Nie wiemy tego, poczekajmy i dopiero myślmy o integracjach. Druga rzecz - chyba nie widziałeś tego modułu do obsługi az w EZD PUW, bo gdybyś widział, to wiedziałbyś że to moduł przeznaczony wyłącznie do obsługi spraw elektronicznych. W przypadku dokumentacji tradycyjnej punkt wyjścia do wszelkich integracji z czymkolwiek to ZoSIA.

[Marcin Kapała]

Tylko po co? Obecny system EZD PUW posiada wbudowany moduł archiwalny do obsługi archiwum zakładowego. Wiadomo nie od dziś że przyszłe EZD RP będzie w dużej mierze bardzo podobne do EZD PUW co najwyżej z eDok-a zaczerpnie trochę rozwiązań open source gdyż z tym obecny system ma problemy i w przeważającej większości składa się z komercyjnych rozwiązań np. baza, serwer. Już dziś powinniśmy przygotowywać integrację ZoSIA z EZD PUW w kontekście nowego modułu nadzoru który zastąpi aplikację NiKA. Połączenie tych dwóch systemów pozwoli na lepszą prace zarówno po stronie AP jak i archiwów zakładowych

Może dlatego, że na przedpolu archiwalnym mamy spory nawis archiwalny, a powstająca w jednostkach organizacyjnych dokumentacja nadal w przeważającej części wytwarzana jest w formie tradycyjnej. Stworzenie interfejsu, być może w ramach modułu dla nadzoru archiwalnego w ZoSIA, może w istotny sposób skrócić czas pomiędzy przekazaniem materiałów archiwalnych do AP a udostępnieniem informacji archiwalnej o nich w Szukaju. Tak jak napisał Jarek moduły EZD przeznaczone są do obsługi spraw elektronicznych, a w tym przypadku integracja z ZoSIA powinna odbywać poprzez ADE.

[Bolek]

Ale jak sobie to wyobrażacie? Jak taki moduł udostępniać archiwistą zakładowym? Może lepiej jakiś program do rozpowszechnienia wśród archiwistów służący do sporządzania spisów, z którego Zosia będzie mogła zaimportować potrzebne dane. Albo jakaś strona internetowa za pomocą, której będzie można stworzyć takie dane np. z opcją wysyłki do danego AP?

[Marek Gieroń]

Ale jak sobie to wyobrażacie? Jak taki moduł udostępniać archiwistą zakładowym? Może lepiej jakiś program do rozpowszechnienia wśród archiwistów służący do sporządzania spisów, z którego Zosia będzie mogła zaimportować potrzebne dane.

Przerabialiśmy to lokalnie. Nie sprawdza się.

Albo jakaś strona internetowa za pomocą, której będzie można stworzyć takie dane np. z opcją wysyłki do danego AP?

"Akcesja" - http://www.rzeszow.ap.gov.pl/az_59/

[Bolek]

I jak się to sprawdza?

[Marek Gieroń]

I jak się to sprawdza?

Na nasze potrzeby nie chcemy niczego innego. Zacytuję sam siebie -

"Akcesja" działa maksymalnie prosto - baza danych opakowana w php na której AZ się loguje, wprowadza dane i dzwoni do nas po "akceptację". Akceptacja polega na tym, że kierownik opracowania przegląda te wprowadzone dane w poszukiwaniu "kwiatków" i wysyła maila "wszystko ok, drukować i przywozić" Akta ze spisem trafiają do magazynu, koleżanka z ewidencji ze spisem w rączce loguje się, 4 kliki i dostaje plik .mdb, sprawdza go dla zasady "ar ju siur?", kolejny klik i dane z pliku kopiują się do naszej Izy. Magazynier jeszcze układa akta na półce, a korzystający już je może zamówić w pracowni.

Spisy są (prawie) identyczne, wprowadzone dane tak samo i "kompatybilne" z "IZĄ", praktykantów i stażystów nie wykorzystujemy już do klepania danych, bo to robią AZ-y. Dzięki temu mamy praktycznie 100% zasobu w "IZI-e".
Wprowadzenie "Zosi", w której nie będzie możliwości importu z tej postaci (MySQL lub mdb) z poziomu administratora lokalnego, a także z Zosi do Izy (na potrzeby magazynu/pracowni i ich systemu "EMPEU") oznacza cofnięcie nas o dekadę. Cóż... cena postępu.

[Michał Kaca]

Ciekawą pomocą którą udostępnił ostatnio NAC to programik do sprawdzania spisów przed ich migracją do ZoSIA. Testując zauważyłem jeden błąd z którym system sobie nie radzi, to zapis w datach skrajnych anteriorów i posteriorów. Problem jest również w przypadku migracji do ZoSIA spisów dokumentacji osobowej która zawiera więcej pól niż standardowy spis i dobrze by było by programik pozwalał na łączenie danych z kilku kolumn w jedną

Dziękuję za uwagi. Bardzo na nie liczymy, ponieważ dzięki nim możemy ocenić "zapotrzebowanie" na program, naprawić błędy i dostosować go do wymagań archiwistów. Problem z datami ant. i post. został już rozwiązany. Rozbudujemy program o możliwość łączenia danych z kilku kolumn (b. dobry pomysł).

Może lepiej jakiś program do rozpowszechnienia wśród archiwistów służący do sporządzania spisów, z którego Zosia będzie mogła zaimportować potrzebne dane.

Od jakiegoś czasu myślałem o tym, żeby na bazie w.w. programu stworzyć edytor tekstu, służący do przygotowywania spisów z-o. Edytor byłby darmowy, połączony z walidatorem, w związku z czym generujący jedynie spisy gotowe do importu do ZoSIA (oraz w innych formatach, w zależności od potrzeb). Taki edytor gwarantowałby niezależność od oprogramowania służącego do przygotowania spisu oraz inwencji twórców spisu w kwestii formatu i ustawień programu. Co sądzicie na ten temat?

PS
Moim marzeniem jest aplikacja bazodanowa dla AZ-ów (taka mini-ZoSIA, choć oczywiście działająca lokalnie, a nie na centralnym serwerze). Byłoby to duże ułatwienie w codziennej pracy AZ oraz w "komunikacji" AZ z AP.

[crash0]

(...) Wprowadzenie "Zosi", w której nie będzie możliwości importu z tej postaci (MySQL lub mdb) z poziomu administratora lokalnego, a także z Zosi do Izy (na potrzeby magazynu/pracowni i ich systemu "EMPEU") oznacza cofnięcie nas o dekadę. Cóż... cena postępu.

Odświeżam wątek 
Nie musicie się cofać o dekadę  Po  wdrożeniu systemu ZoSIA, możecie prowadzić sobie "wewnętrzną IZĘ" (i tym podobne bazy na potrzeby magazynu/pracowni, różnych systemów "EMPEU", w postaci MySQL czy mdb) tyle, czy to nie będzie podwójna robota?  Zresztą z MySQL czy .mdb można zmigrować to do Excela a dalej do ZoSIA. Procedura dłuższa, a każdego nie da się zadowolić. 

[Marek Gieroń]

Nie musicie się cofać o dekadę  Po  wdrożeniu systemu ZoSIA, możecie prowadzić sobie "wewnętrzną IZĘ" (i tym podobne bazy na potrzeby magazynu/pracowni, różnych systemów "EMPEU", w postaci MySQL czy mdb) tyle, czy to nie będzie podwójna robota?  Zresztą z MySQL czy .mdb można zmigrować to do Excela a dalej do ZoSIA. Procedura dłuższa, a każdego nie da się zadowolić. 

Ech.... Nudzi mnie już powtarzanie tego samego...
NIE CHCEMY "wewnętrznej izy" bo to podwójna robota.
CHCEMY mieć możliwość ZAIMPORTOWANIA WSZYSTKICH rekordów dotyczp