Toon posts:

ASP/VBscript vs PDF voor het digitaliseren van formulieren

Pagina: 1
Acties:

Verwijderd

Topicstarter
Er moeten op mn werk meer dan honderd formulieren zsm gedigitaliseerd worden. Er is zo'n grote papier stroom en dat moet maar eens ophouden :). Er zijn twee opties (denk ik) om die papierstroom te gaan digitaliseren:
  • PDF of
  • ASP/VBscript
Het verloop van de formulieren is verschillend. Soms dient een hoofd van een bepaalde afdeling een akkoord te geven op een ingestuurd formulier alvorens deze wordt doorgestuurd naar bijvoorbeeld de salarisadministratie (denk hierbij bijvoorbeeld aan reiskostendeclaratie). Soms komen formulieren direct op de afdeling waar ze horen te komen. De informatie die op de afdelingen komt vanaf de formulieren moet via een export functie (indien mogelijk) in bijvoorbeeld Excel, boekhoudprogramma (kan dmv tektsfile) etc worden geplaatst.

Er zijn twee partijen. De een vindt PDF helemaal te gek, de andere hebben zoiets we maken alles in ASP,VBscript (en natuurlijk XHTML) en als de gebruiker het heeft ingevuld en zelf een kopie wil hebben dan genereren we uit de database (want daar willen we wel alle gegevens gaan bewaren) een PDFje (is de PDF groep ook gelukkig :) )

Ik ben zelf voorstander van de ASP/VBscript optie, die in feite op te splitsen is in twee opties:
  • je maakt elk formulier opnieuw.... (beetje simpel werk op den duur)
  • je maakt een applicatie waarin je formulieren kan maken en daarin ook kan aangeven hoe de procedure verloopt... (veelwerk, maar als het goed werkt heb je er een hoop plezier van, ook onderhoudt is dan prettig...)
De PDF'ers hebben het idee: we scannen de huidige formulieren in, die maken we interactief. Dan krijgen we het zelfde formulier: herkenbaar voor de gebruikers (het gaat om een zorginstelling, dwz alles met de computer is eng voor veel medewerkers, dus wat dat betreft hebben ze een punt) via PDF wordt dan de data in de db gestopt.

Er is binnen de afdeling ruim voldoende kennis van ASP/VBscript, maar weinig kennis van het interactief maken van PDF documenten. Ik zelf denk wel dat het werken via PDF wel sneller gaat als je dat onder de knie hebt...

O ja, de identificatie van de gebruiker gaatie via een paar stappen: eerst naam invullen of personeelsnummer, bij het herkennen van het aanwezig zijn van meerdere dezelfde namen dient deze de plaats waar hij/zij werkt en woont in te vullen. Is absoluut geen waterdichtsysteem, maar is voldoende voor de formulieren die gedigitaliseerd gaan worden.

Mijn vraag: heeft iemand ervaring met zulke vraagstukken, hoe hebben jullie het toen opgelost, wat raden jullie aan/af, hoe zit het met de beveilging van de inloggegevens van de database die in een pdf verwerkt moeten worden en zijn er nog andere goede oplossingen?

  • faabman
  • Registratie: Januari 2001
  • Laatst online: 08-08-2024
Zelf heb ik totaal geen ervaring met het interactief maken van .pdf, maar, ik denk dat de snelheid van de applicatie ook erg belangrijk is, als ik kijk hoe lang Acrobat bezig is een Word documentje om te zetten naar .pdf....

Ik weet dus niet wat er allemaal mogelijk is met .pdf, maar, webbased zullen de mogelijkheden allicht groter zijn (dan heb je immers ook javascript / COM tot je beschikking)

offtopic:
oke, ik ben een voorstander van web-based applicaties ;)

Op zoek naar een baan als Coldfusion webdeveloper? Mail me!


Verwijderd

Topicstarter
Binnen pdf heb je ook (soort van) Javascript tot je beschikking dus das voor beide partijen gelijk. Verder hoef het omzetten naar PDF maar één keer te gebeuren en das bij het maken van het formulier, daarna is deze gewoon op te vragen, in te vullen en te versturen voor een gebruiker...

Zelf denk ik ook dat je web-based qua beveliging vele malen effectiever bezig bent, mocht je dat ooit gaan koppelen aan de NT inloggegevens van de gebruiker (niet alle medewerkers hebben eigeninloggegevens voor het netwerk, dus das op dit moment nog geen optie, misschien wel slim om dit in het achterhoofd te houden bij de beslissing PDF of ASP/VBscript) Daarnaast hoef je eenmaal de soort van inlogprocedure wijzigen als dat ooit moet gebeuren, voor PDF zal je dat voor elk formulier moeten doen... maar goed dit zal voor de pdf'ers niet zwaar genoeg wegen om over stag te gaan ben ik bang...

  • Belgar
  • Registratie: Januari 2002
  • Laatst online: 17-08 22:31

Belgar

Archmaster ranzige code..

Even een vraagje. wil je nu het complete PDF formulier op gaan slaan of de gegevens die in het interactieve gedeelte worden ingevuld? Dat is namelijk wel redelijk van invloed hier. Hoe en waar vind de beweking plaats naar de database? Ik bedoel, worden die PDF's ge-emailed door de betrokkenen en vervolgens verwerkt? Uitlezen van de informatie van zo'n pdf is namelijk redelijk makkelijk te automatiseren.

Je zegt ook dat enkele gebruikers geen eigen login hebben ? Dus: wat zijn de belangrijkste punten die hier wegen? de interface die de gebruiker voorgeschoteld krijgt, of het gemak van verwerking richting database? Hoe vind de overdracht plaats van de gebruiker richting database (email, login, etc). Heb namelijk wel wat ervaring hiermee, maar het beeld is me nog niet helemaal duidelijk

...Als het maar werkt


Verwijderd

Topicstarter
Zal proberen wat duidelijker te zijn over het pdf verhaal. en ff beter uit de doeken doen wat het idee was richting het gebruik van PDF voor de hele problematiek
  • De inlogprocedure zal interactief zijn richting de database, zoals beschreven in mn TS
  • De gegevens die ingevuld worden in het document worden opgeslagen, niet het hele pdf document, dat lijkt me onzinnig...
  • De documenten zouden dan op intranet komen te staan die ze daar gewoon webbased zouden moeten kunnen openen.
  • Voor de pdf'ers is de vormgeving het belangrijkst, maar sommige formulieren zien er niet uit dus daar moet toch wat aan gebeuren. Over dit punt moet nog gediscuseerd worden...
  • Daarnaast moet de verwerking van de formulieren voor de mensen die ze gebruiken (degene die het indient, die akkoord geeft en die het verwerkt) heel eenvoudig zijn. Degene die akkoord moet geven moet bijvoorbeeld alleen maar een vinkje te plaatsen dat het akkoord is (of niet)
  • het gaat dus vooral erom: werkt het prettig naar de mensen toe, hoe ingewikkeld het programmeertechnisch er uit gaat zien maakt niet uit...
Toch nog maar ff het verloop van reiskostendeclaratie:

1. gebruiker vult het in en stuurt het op (gegevens worden in db opgeslagen)
2. persoon die akkoord moet geven krijgt melding dat er een nieuwe anvraag is ingediend
3. na akkoord krijgt de salarisadministratie het bericht van een legaal verzoek voor reiskosten declaratie, daar moeten ze mbv een import file dit automatsich verwerken..

Das ongeveer de bedoeling. Voor formulieren zijn verschillende procedures, maar bovenstaand verhaal geeft een goed beeld van hoe het kan lopen.

Hoop dat het wat duidelijker wordt..

  • faabman
  • Registratie: Januari 2001
  • Laatst online: 08-08-2024
Heb je acrobat nodig om .pdf -forms in te kunnen vullen of kan het ook met acrobat reader, als dat eerste het geval is dan praat je over een vorse investering (à €300 per user).

Op zoek naar een baan als Coldfusion webdeveloper? Mail me!


Verwijderd

Topicstarter
Nee, kan gewoon met reader... Dus hoeft verder geen inverstering gedaan worden!

  • Yoeri
  • Registratie: Maart 2003
  • Niet online

Yoeri

O+ Joyce O+

(overleden)
Informeren bij Orbid www.orbid.be naar Infodesk... relatief goedkoop naar ik dacht en doet ongeveer wat je wilt.

Is een ASP applicatie mèt PDF documenten

Kijkje in de redactiekeuken van Tweakers.net
22 dec: Onze reputatie hooghouden
20 dec: Acht fouten


  • ATS
  • Registratie: September 2001
  • Laatst online: 12-02 13:46

ATS

Ik heb niet zoveel van verstand van PDF, maar kan je daar ook inderdaad alleen de ingevulde gegevens makkelijk richting een internetapplicatie/databeest sturen? Zo ja, dan is er wel wat voor te zeggen om het met PDF te doen. De presentatie naar de gebruiker toe is zoals je zegt bekent. Mensen met nieuwe systemen om leren gaan kan heel veel tijd kosten, en je hebt waarschijnlijk al een personeelstekort (zorginstelling...)

Je backend zal zowiezo informatie moeten bevatten over de flow van elk formulier, of je het nu PDF of ASP gebaseerd opzet.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant


Verwijderd

Je praat over formulieren en PFD. Dan denk ik meteen aan papieren formulieren, want daar is PFD volgens mij ook voor bedoeld: het opmaken van gegevens en pagina om het vervolgens uit te printen.

Maar uit jouw verhaal maak ik op dat medewerkers via het intranet een formulier moeten invullen voor hun reiskostendeclaratie. Dan ga je toch niet met PDF werken??? Dit is een informatiestroom die niet via papier loopt! Dan ben je veel beter af met een goed opgezette workflow.

Wat ik denk dat je nodig hebt: een applicatie waarin medewerkers hun declaratie opgegeven en vervolgens hun leidinggevenden een declaratie al dan niet goedkeuren. Goedgekeurde declaraties worden doorgestuurd naar de salarisadministratie. Dit kan in een batchfile, direct in de DB of op wat voor manier ook.

Maarre, moeilijk doen met PDF, dan moet je daar wel een goeie reden voor hebben. Wordt er überhaupt iets uitgeprint???

:7

  • Belgar
  • Registratie: Januari 2002
  • Laatst online: 17-08 22:31

Belgar

Archmaster ranzige code..

Tja, aan de hand van de informatie die je nu geeft neig ik toch meer naar de ASP/VB. Hoewel de eigenlijk discussie puur over de front-end gaat. De verdere verwerking MOET toch via de ASP/VB oplossing. Een uitleg over mijn standpunt:

- Managers zien toch alleen de DB info -> FORM.. dit is niet nuttig om te presenteren in PDF + eventueel directe koppeling aan personeel DB voor authentication
- Managers hebben waarschijnlijk login -> betere security adhv NT-login
- Administratie moet het formulier in standaard tools hebben -> Client-side tool met directe DB access?

Dus blijft alleen de discussie: waar vult het lokale personeel zijn form op in. Als er toch forms herschreven moeten worden, zou ik direct voor een volledige ASP oplossing kiezen. Dit is ook veel makkelijker 'klant-vriendelijk' te krijgen. Denk hiebij bijvoorbeeld aan een simpele login, die vervolgens alle eigen informatie op het formulier invuld (naam, afd nr, etc). Dit soort (eenvoudige) toevoegingen zal de acceptatie van een systeem versnellen. Daarbij is dan ook het laatste voordeel van PDF, de herkenbaarheid, grotendeels ondermijnd.

...Als het maar werkt


Verwijderd

Topicstarter
@robbedoeske: dat zal het waarschijnlijk niet gaan worden, maar zal het wel mee nemen in de discussie en er eens naar kijken

@ATS: je kan idd via PDF met ODCB tegen de db aanpraten, is niet waanzinnig snel voor zover ik begrepen heb... en de voor de workflow maakt het idd niet uit wat je je op de front heb staan...

@typhon: via het intranet bedoel ik eigenlijk dat de documenten op te halen zijn via het intranet middels een doodnormale link daarnaar toe... gebruikers zouden deze frmulieren ook gewoon lokaal op kunnen slaan. Ik kan me verder voorstellen dat gebruikers ff een kopie willen hebben van de declaratie die ze hebben ingediend, tja helemaal paperless zal wel nooit gebeuren...

@Belgar: heb je helemaal gelijk in! Ik voel 100% met je mee en vind standpunt 'verhelderend' _/-\o_ Hoewel dat inlogsysteempje ook wel in te bouwen is in PDF... hoor ik nu de pdf'ers zeggen... Gaat nog een lastig klus worden om iedereen over te halen :)

Meer invalshoeken en ideeën zijn van harte welkom... en vooral ervaringen!!!
Pagina: 1