| Issue Number | 3070 |
|---|---|
| Summary | Global to reconcile CompletionDate with Lead Org StatusDate |
| Created | 2010-01-28 23:30:12 |
| Issue Type | Improvement |
| Submitted By | alan |
| Assigned To | alan |
| Status | Closed |
| Resolved | 2010-02-08 18:10:39 |
| Resolution | Won't Fix |
| Path | /home/bkline/backups/jira/ocecdr/issue.107398 |
BZISSUE::4746
BZDATETIME::2010-01-28 23:30:12
BZCREATOR::Alan Meyer
BZASSIGNEE::Alan Meyer
BZQACONTACT::William Osei-Poku
At our status meeting today we decided that we should have a
global change program to reconcile the CompletionDate with the
StatusDate for the primary lead org for all InScopeProtocols.
Here are some questions regarding how the program should
operate
together with my suggestions for how to answer them:
Q: What if the primary lead org does not have a status of
Completed?
I'm not aware of any software that prevents this from
occurring. However if it does occur, it should be very rare.
A: If the primary lead org does not have a status of
"Completed",
I propose to leave the document alone rather than try to
figure out whether some other lead org StatusDate should be
consulted.
Q: What if the overall CompletionDate has a DateType of
'Actual',
but it is not the same as the StatusDate for the primary lead
org.
A: I propose to ignore the DateType of the CompletionDate and
always use the StatusDate of the primary lead org (assuming it
has a CurrentStatus of 'Completed'.)
In other words, the date set on the primary lead org will
trump any overall date.
This too may be rare or non-existent, but I want to have a
policy on what to do if and when it occurs.
Are those answers right? Or if not 100% right, are they
going to give us something that is simple to understand and
better than what we have now?
If approved, I'd like to write and run this global before
running
the Issue #4721 global, and make that one depend on this.
BZDATETIME::2010-01-29 08:07:24
BZCOMMENTOR::Bob Kline
BZCOMMENT::1
Fixed target version number.
BZDATETIME::2010-02-02 21:24:34
BZCOMMENTOR::Alan Meyer
BZCOMMENT::2
I've written the global change to do the CompletionDate /
StatusDate reconciliation, using the assumptions documented in
the description of the issue.
I plan to test it, then run in test mode on Thursday. It looks
like 6,069 documents will be affected. Does that sound about
right? The great majority of these have no CompletionDate but
there are some that have a projected date that needs updating.
If the assumptions are wrong, please let me know before then,
if
possible, and I'll change the behavior of the program.
My sense in working with the data is that these assumptions
will
be fine, but I don't know the data as well as others do.
Note: if there's a Projected CompletionDate that exactly
matches
the actual LeadOrg StatusDate, I'm leaving it alone. I'm only
updating the ones where the dates don't match. The case where
they exactly match but the CompletionDate is projected should be
rare or non-existent, but I haven't checked to be sure because
the DateType attribute is not in the query_term table.
BZDATETIME::2010-02-03 16:21:49
BZCOMMENTOR::Lakshmi Grama
BZCOMMENT::3
Alan, this is a reflection of how complicated things have gotten. I forgot that there was a change in the definition of completion date relative to the FDAAA law. The Completion Date is really the "Primary Completion Date" which is different from the actual completion date. See the documentation in the schema. I am really hesitant to do anything programmatically at this time related to teh Completion date. Please go ahead and do the part related to updating the Transfer block only.
BZDATETIME::2010-02-04 10:16:58
BZCOMMENTOR::Alan Meyer
BZCOMMENT::4
In light of Lakshmi's last comment, I am marking this
resolved-invalid.
BZDATETIME::2010-02-04 10:17:26
BZCOMMENTOR::Alan Meyer
BZCOMMENT::5
Removing the block on issue 4721.
BZDATETIME::2010-02-08 18:10:39
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6
(In reply to comment #4)
> In light of Lakshmi's last comment, I am marking this
> resolved-invalid.
Issue closed!
Elapsed: 0:00:00.000755