A couple of issues I see here, and without further information, don't have
much to offer as a suggestion for accepting or improving the process.  One
is related to required retention periods for POs, Invoices and or anything
that certifies a purchase of a product to ensure you have warranty
protection based on date of purchase proof.

You mention you "create" electronic POs- are these created in a system that
generates an output document that looks like a typical PO, with all the
content and context that when viewed or printed resembles what went to the
vendor?  The reason for asking this is if there' s a subsequent problem,
you may need to generate a copy that matches what you sent out to the
vendor to be able to address a concern.  Some systems store the content of
the PO as fields of data in a database, but not a "PO".  Other systems
store the data and generate an "image" of the PO as it was sent and store
those together.

The other question is what format are these stored in? Is it a simple PDF
or other image, or is it in some proprietary format owned by whoever the
software vendor is that your electronic PO system is from?  If it's
proprietary, you may want to consider an image in some other form, such as
PDF to ensure continued accessibility that isn't application dependent.

You also mentioned "converting" invoices/POs to electronic form.  A bit
more information as to what you mean by converting would help- are you
simply scanning a paper source document and storing the subsequent image
(and again, what format?) or are you receiving something electronically and
then doing something with that data to 'convert' it?

There are many instances where workflow projects designed to eliminate
paper save a lot of effort and time for access to content and they delete
past paper intense practices.  That said, there are also a lot of these
that when clearly reviewed DON'T save anything because the existing process
really doesn't cost that much or isn't that inefficient.  Many times, it
depends on the volume, the disparate location (and number) of users, and if
multiple users require simultaneous access to the same content.  But there
are also requirements for indexing, capturing fields of data/metadata to
provide access, possible needs for controls of access due to privacy or
other issues, etc that make the system cumbersome to establish and provide
ongoing "care and feeding" for.

Larry
[log in to unmask]

-- 
*Lawrence J. Medina
Danville, CA
RIM Professional since 1972*

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]