Closed alisan16 closed 1 year ago
1 |
2 |
3 | |||
5 | |||||||
8 | ||
Noticed a discrepancy between counts_by_priority_and_readiness
and the number of appeals actually ready to distribute
VACOLS::CaseDocket.counts_by_priority_and_readiness
=> [..., {"n"=>766, "priority"=>1, "ready"=>1},...]
One thing this method does not take account of are blocking mail tasks and diary entries. A case is classified as "ready" if the case is in case storage.
If we filter out these instances, we get down to 661
SELECT_PRIORITY_APPEALS = "
select BFKEY, BFDLOOUT, VLJ
from (
select BFKEY, BFDLOOUT,
case when BFHINES is null or BFHINES <> 'GP' then nvl(VLJ_HEARINGS.VLJ, VLJ_PRIORDEC.VLJ) end VLJ
from (
#{VACOLS::CaseDocket::SELECT_READY_APPEALS}
and (BFAC = '7' or AOD = '1')
order by BFDLOOUT
) BRIEFF
#{VACOLS::CaseDocket::JOIN_ASSOCIATED_VLJS_BY_HEARINGS}
#{VACOLS::CaseDocket::JOIN_ASSOCIATED_VLJS_BY_PRIOR_DECISIONS}
)
"
VACOLS::CaseDocket.connection.exec_query(SELECT_PRIORITY_APPEALS).count
=> 661
This function is used to count legacy appeals when calculating our priority count (total number of priority cases available to distribute) and calculate our docket proportions
Found by looking at priority_count and the counts of each docket's ready appeal ids
DocketCoordinator.new.dockets.map { |docket_type, docket| docket_type == :legacy ? 661 : docket.appeals(priority: true, ready: true).pluck(:uuid).count }
=> 858
DocketCoordinator.new.priority_count
=> 963
We have a request from John Gosnell to investigate 500+ AOD appeals that are in VACOLS case storage and have not been distributed with the Caseflow automatic case distribution algorithm. Based on Mike Sanford's initial manual investigation, some of these cases are tied to AVLJs and are not distributed because AVLJs cannot order cases. The goal of this ticket is to classify why these appeals are not being distributed.
The team may be asked to come up with a Caseflow solution for distributing these cases, but that solution is out of scope of this ticket
Acceptance criteria