The Document Date defaults to the date the document was stored, but OnBase allows it to be changed. And the Document Date does NOT reflect the dates of more recent revisions (unless you take it upon yourself to update the value).
I see three options. None of them are perfect:
- Set up your processes to enforce the rule that the DocumentDate (or a chosen keyword) always reflects this information. You CAN'T enforce that if users are allowed to do one-off imports and revision updates through the clients. However, if documents and revisions are always added through Workflow actions, other API code, Advanced Capture, etc., then you can control it. This would be the "best practice" if possible, because you're tracking a date that obviously has business value for you and is needed for searching.
- My guess from your description is that you can have some confidence that the DocumentDate was left unchanged from the date stored, but you already have revisions in the system that didn't have their date recorded.
- If you are working with a very small number of documents, you can do what Brandon suggested above: Query on ALL documents that MIGHT fit, and then check the dates one by one. Documents have a "DateStored" property that always tells you the date it entered, regardless of whether the Document Date was changed. Documents also have a list of "Revisions", and each Revision has a "Date" property with the date that it was added.
- Unfortunately, querying for EVERY document and then checking this information quickly becomes inefficient and impractical. It doesn't sound to me like you are just checking against a small set of documents. (Note: OnBase doesn't make these fields directly searchable because they aren't needed by most people. It's assumed that if they do have business value, then there will be processes similar to the ones mentioned in option #1.)
- Though you can't use the API (or a client) to search against DateStored or Revision.Date, those values DO exist in the database. You can figure out the appropriate SQL query and get your list that way.
- I never like to suggest database queries as a solution, but because this is a read-only query, it is permitted. And unless my other assumptions were wrong, this is probably the only option left to you.
If at all possible, I would try to structure my solution around option #1.
