What we're stuck with

Ideally, an inventory system should have features to manage entering new orders. However, we are married to an Old Legacy Online Inventory Management system (OLOIM) that does not have such features. This can't change. Data entry looks like uploading a PDF to a new service ticket in the system and keying in the data from the PDF into the web page for that ticket.

Our customers can submit orders to us however they want - postal mail, email, fax, etc. This also can't change.

What we're doing now

Everything after this point is mutable.

Postal mail orders are scanned in by us and sent to an email address, we use a web fax that goes straight to the email. Emailed orders are usually in PDF format, but some customers send multiple orders in one PDF, and some send multiple PDFs for one order.


All of the PDF attachments are saved to a shared Google Drive folder using a Google Apps script. Matilda (who works from home) uses Google Drive Sync to sync a copy of the PDFs to her computer, where she combines the multi-PDF orders into one PDF and splits the muti-order PDFs into multiple PDFs using Adobe Acrobat. When she is done, the shared folder now has a sub-folder where every order is on its own PDF. Each PDF has also been given a helpful name.

Upload and Data Entry

When Matilda is done, Abner, Pythagoras, and Jebediah (who all works from their respective homes) sync a copy of the Google Drive folder to their respective computers, so they can manually upload the PDFs, one at at time, to the OLOIM and key in the data from the PDF to the appropriate fields in the OLOIM.

Problems with the Current Setup

We need to get away from Google Drive Sync if we can. I think we need to get away from synchronization in general.

  1. Google Drive Sync doesn't handle that many files well. We're talking tens of thousands of PDFs. These users will turn on their computer after they've been gone for the day, and Google Drive Sync will be syncing file 600 out of 63,000. It slows down their computers a lot, even after upgrading to SSDs.

  2. Synchronization errors. Something will go wrong somewhere and we will get duplicate copies, or copies on the wrong folder, etc.

  3. Google Drive Sync itself will crash for a couple days without the user noticing so they miss the new work that is coming in.

Wish List

  1. Some kind of cloud-based solution that doesn't require synchronization - all of the files are stored on the cloud, and users don't need to get a local copy of the file to work with it; they can manipulate it and upload it from the cloud. There's only one working copy of each file, so there's no sync issues.
  2. Ability to combine and split PDFs from the cloud-based solution - again, no downloading a local copy of the file.
  3. Ability to upload a file to a site directly from the cloud without downloading it first - I asked about this already on SuperUser, but didn't receive a conclusive response.
  4. Needs to be cloud-based since everyone is working from home, unless you think a VPN to connect to a NAS or something would be helpful.

Possible Solutions

  1. I thought we may be able to stick with Google Drive's cloud storage if I can figure out a way to manage PDFs and simulate a browser upload using Google Apps Scripts, but I'm not clever enough to figure out how to do this. I could pay someone to write such a script for me, but I figure it would be better to see if something like this already exists. It doesn't have to be with Google.

  2. Get a hosted Windows server somewhere, and have Matilda, Abner, Pythagoras, and Jebediah log onto a remote desktop session on that server. All of the PDFs are stored on that server, so Matilda can combine and split PDFs, and Abner, Pythagoras, and Jebediah can upload them using the browser on the server desktop. This way, there is only one working copy of all of these PDFs to worry about; we don't have to download a copy to each users computer and worry about keeping all the copies in sync.

  • How are the pdfs generated - are they pdf forms filled in on screen or horror of horrors printed forms, filled in by hand, and then scanned? – Steve Barnes Jul 18 '16 at 18:15
  • The horror! Our customers are large businesses, so they send us their orders in whatever format their system outputs. The emailed ones usually aren't that bad, but some of them are (shudder) screenshots from the customers' DOS-based system. No handwriting, though. The ones sent via postal mail are currently scanned in without OCR, but we could probably add that without too much trouble. None of these are forms. – browly Jul 18 '16 at 18:19
  • Personally I would say don't to OCR as it is rarely 100% especially for numbers - was that 11 or 77, 100 or 788, most of the better OCR systems use context, i.e. if there is any uncertainty about a letter does it make a correctly spelt word, is that word one that fits the ones about it, to correct which isn't present with numbers. First I would consider about adding a per order data entry fee for any orders not submitted via an online ordering system. If you have to stick with pdfs look at pdf forms. You can extract the data reliably from those. – Steve Barnes Jul 18 '16 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.