Hi,

Custom events are powerful, but since they rely on database table triggers, they need something to trigger on, and the options are inserts, updates and deletes. Nothing can trigger based on that a certain amount of time have passed, which you want here.

Ideally, there should be a background job, running once per day or so, which would check for expired documents, and removing them. We don’t have that in place, nor do we have a method for this purpose that you could create your own background job for, and call.

Now, you could use custom events anyway, but they would need to trigger on something else, something that happens regularly and which, if the code connected to the custom event (via an event action), does not cause problems for the flow that causes the custom event (trigger) to execute.

One idea could be to have a custom event that executes when a document is released. If that happens often and regularly enough, you could then attach an event action to such a custom event, that would look for expired documents and remove them. It’s a little bit of a hack, but it might work depending on your needs. If you want to delete the files connected to the documents as well, you need to keep them in the database, since deleting files from an FTP or Shared repository might not be possible to do from a custom event (not 100% sure on this, there might be a way that I don’t remember).

If you cannot develop such a custom event yourself you probably need to find someone here that is willing to spend time to do it, or contact your favorite IFS consultant to get the job done.

Good luck!

You could also consider a lobby element to list documents due to expire

@KIMKIMANDREW from where should the Expiry Date of the document to be fetched? I wasn’t really sure about that

Good idea!

There is an attribute called DaysExpired in the DocIssue entity, that is the main way to control this. This is not used for more than to calculate the number in the Remaining Days field, and we calculate this using Days Expired in combination with the date when the document revision was set to Obsolete.

There isn’t an expiry date as such for a document, you either have to introduce a custom field or else (mis)interpret an existing field e.g. The Development Tab Planned and Actual Finish Dates are popular choices.

To me, this seems a ‘flaw’ in DocMan - there is no standard ‘date of next review’ or ‘expiration date/period’ field.

You’re right, of course. We don’t have a way to set the expiry date. I tried to describe the little we have when it comes to “expiring” documents.

About custom fields, and this is not the same thing, but one of the ideas behind the six description fields that we have on a document revision is that you as a customer can use them for what you want. Of course, since these fields are just text fields, there is not even a validation to make sure the user enters a date. That, on the other hand, can be done quite easily using a custom event.

Just wanted to mention the option.

Good luck @EnzoFerrari! 

Did something similar to this on an Apps10 project a few years back. Customer had the same requirements for being notified that a supplier's certificate was coming up for review. Sketchy on the details as I have no documentation of the exact final configuration, but I recall something along the lines of:

On Document Revision page:

1. Custom field "Latest Review Date". User or Doc Admin would assign this, or maybe it was set systematically when the document was released.
2. Custom field "Review Cycle". A drop down list in which the Doc Admin would assign a duration of the review cycle (e.g., 6 months, 1-year, 2-year, etc.)
3. Custom field "Next Review Date". Calculated field based on settings in 1 & 2.
4. Lobby Element for "Supplier Certificates within ‘X’ days of Next Review Date".

@matt.watters I think this’ll work for me. I will work with my developer to bring about a similar solution. Thank You.