Konferencja "e-Dokument" 13 marca 2008
Submitted by Paweł Krawczyk on pon., 2008-02-11 15:26
13 marca 2008 w Warszawie pod patronatem honorowym pani prezes UKE Anny Strężyńskiej odbędzie się konferencja "e-Dokument".
Wstępny program konferencji:
- Propozycja oszczędności dla firm poprzez elektronizację obiegu dokumentów.
- Wprowadzenie e-dokumentu do użytku i wyszczególnienie jego podstawowych cech w porównaniu z dokumentem papierowym.
- Dyskusja merytoryczna na temat zalet i wad elektronizacji poprzez wdrożenie EDI.
- Bezpieczne dostarczenie e-dokumentu do klienta, przedstawienie możliwości rozwiązań.
- Omawianie e-faktury jako naturalnego następcy faktur wysyłanych drogą tradycyjną.
- Format dokumentów elektronicznych na przykładzie e-faktury, polskie standardy czy międzynarodowa praktyka?
- Porównanie modelu ASP i wdrożenia dedykowanych rozwiązań.
- Wykorzystanie
podpisu elektronicznego i usług powiązanych(znacznik czasu, OCSP,
elektroniczna skrzynka podawcza) Centrów - Certyfikacji w procesie
tworzenia e-dokumentu. - Przedstawienie rozwiązań i sposobów archiwizacji dokumentów elektronicznych.
- e-faktury a polskie realia prawne (z uwzględnieniem przykładów zagranicznych).
- Koszty wdrożenia e-faktury – przełożenie na oszczędności.
Patronami merytorycznymi są Adobe oraz itBCG. Będę miał przyjemność uczestniczyć w konferencji w charakterze preleganta.
- Zaloguj się lub zarejestruj by odpowiadać
- Generate PDF file
- Wersja do wydruku









Odpowiedzi
Czy zawieranie podpisu w dokumencie PDF ma ambicje stać się polskim standardem? Czy przetwarzanie programowe takiego PDF'a nie stawrza więcej problemów niż niweluje? wygenerowac fakturę wszystko fajnie, ale wprowadzic ją spowrotem do systemu? A jeśli wzory faktur w dwóch firmach są różne?
Czy używanie dokumentów posiadających funkcje skryptowe nie stwarza zbyt wielu problemów? Czy nie byłoby prostrzym rozwiązanie generowania na podstawie zaufanej aplikacji pliku XML'owego, który to byłby podpisywany? i to nie pliku XML jaki proponuje ebStream (ponieważ wyglądem bardziej przypomina XHTML i ma niewiele wspólnego z założeniami standardu XML), tylko prawdziwego "pliku z danymi", który następnie mógłby być wizualizowany na wiele sposobów?
nie byłoby możliwości osadzania skryptów, podmiany zawartości itp. Dodatkowo zdefiniowanie przekształcenia (XSL) oraz wzoru (XML) w Centralnym Rejestrze Wzorów pozwoliłoby na większe zaufanie do formy? Czy może nie warto by się zastanowić nad centralną witryną, zarządzaną przez Zaufaną jednostkę, która zajmowałaby się generowaniem Widoków na podstawie dostarczonej faktury w formacie XML?
Takie, moje luźne uwagi:)
wygenerowac fakturę wszystko fajnie, ale wprowadzic ją spowrotem do systemu?
w dokumencie PDF można osadzić załącznik z informacją, która może być w prosty sposób parsowana i wprowadzana automatycznie do systemów. Tak wytworzony PDF podpisujemy i wychodzi nam złoty środek bez XSL, XHTML i czego tam jeszcze potrzeba żeby tą fakturę przeczytać.
Tworzenie Centralnego Rejestru Czegokolwiek jest drogą donikąd. Znowu będzie tak że ogłoszony zostanie przetarg, wygra ten co zwykle, pójdze na to [123]0 mln plnów. Jedynym efektem tych działań będzie wygenerownaie kilku megabajtów cyfrowej makulatury, zrobienie stroniki www (skastomizowanie joomli czy innego mambo) i odtrąbienie sukcesu -- na podstawie celów projektu zapisanych w dokumencie otwarcia :). Ot taki drugi e-puap.
Trzeba powiedzeć jasno: fakturowanie to nie wysłanie człowieka na marsa, powinno być tanie i proste w obsłudze.
Dostępna jest moja prezentacja z tej konferencji poświęcona zastosowaniu Adobe Acrobat/Reader jako bezpiecznego urządzenia do składania i weryfikacji podpisu elektronicznego:
Krawczyk - prezentacja e-Dokument 2008.pdf