Terry,

Thanks for all ideas. I'm still thinking. Here are some questions I've added a minute ago in a document, where I discussing it: (in italic is my manager's response on my prev. questions)

I would treat each day individually. For Monday, check for the number of delinquent accounts for that day and then determine how many to add for Monday, provided that the sum total of all records do not exceed the absolute employee max count. Do the same procedure for each day of the week.

We do not distinguish delinquent accounts by date. I believe, it’s accumulative number. Let’s have a brief meeting either today or on Monday to clarify all these numbers and how are they updated.

First of all, it is not clear for me, which process should set this value in Employee_Queue_Profiles table.

Secondly, you want me to add more logic to never exceed the Total allowed number? Where do we keep this number? In UsGrLink table? Is it per user or per user’s role?


>It seems only 5 pieces of data would be needed to resolve this requirement and any others that may come along.
>
>keyActMan - the account managers id (never changes)
>keyClient - the clients id (never changes)
>keyContract - the contract reference (never changes)
>dOrigSched - date original review schedule (never changes)
>dReSched - date re-queued to (this will change)
>dCompleted - date review completed
>
>The project may need a "history" of dates originally scheduled and/or rescheduled. But that is another issue.
>
>With the data model above, it would seem that any "delinquency" management "reporting" requirement could be made avalable.
>For example, a cursor could be assembled that would report, in descending order (from most delinquent to least):

>create cursor delinquent(keyActMan, c(), keyClient c(), keyContract c(),;
>                         dOrigSched d(),dReSched d(), daysdelinq c(4))
>select delinquent
>index on daysdelinq tag daysdelinq
>* Now go down the master list
>select Master && Whatever file that is
>scan
>if !empty(dCompleted)
>   *Do nothing, this service has been completed
>else
>   * Not complete, calculate the days between originally issued and either
>   * todays date or date reschedule
>   nDaysDelinquent=date()-master.dOrigSched
>   append blank in delinquent && The cursor
>   repl daysdelinq with right(str(nDaysDelinquent+10000,5),4),;
>        keyActMan with Master.keyActMan, keyClient with Master.keyClient,;
>        keyContract with Master.keyContract,;
>        dOrigSched with Master.dOrigSched,;
>        dReSched with master.dReSched in delinquent
>endif
>endscan

>This is just a conceptual schematic. The resulting 'delinquent' cursor has all the prima facia stuff needed for delinquency reporting. A working assumption can be that any account not completed (no date in dCompleted) is delinquent. Logic could be added to filter out negative nDaysDelinquent (those would be those accounts scheduled after "date()". I am a bit old fasion, so the reasont for the right padding the daysdeleinquent with zeros can be forgiven - but its good if you don't like burning resources with a bunch of "cursors" and just want to set the pointer and rip based on multiple field key stacks.
>
>But, with this scheme and cursor, the project could order lists by manager and the number of days delinquent.