Caseflow: Add document ID validations during attorney and judge check out

Created on 21 Jun 2018  ·  7Comments  ·  Source: department-of-veterans-affairs/caseflow

The Board found that a common error at BVA dispatch is incorrect document IDs. Paul Saindon and the IDT team have requested that Caseflow validate the various formats of a document ID during attorney and judge check out to reduce potential for errors at BVA dispatch.

They would also like us to validate that the decision document is located at a particular path (e.g. Located at “\bvacofil1.dva.va.gov\dt1\Board\” & Left(theID, 5) & theID & “.docx”). This is not in scope for this github issue.

AC

  • Verify that all decisions have document IDs with any of the below formats:

    • “#####-########”
    • "#########.###"
    • "#########.####"
  • Verify that all VHA work products have document IDs with either of the below formats:

    • "V#######.###"
    • "V#######.####"
  • Verify that all IME work products have document IDs with either of the below formats:

    • "M#######.###"
    • "M#######.####"
  • If the document ID does not have that validation, prompt the user with the required validation

caseflow-queue Foxtrot 🦊

Most helpful comment

You're going to love my answer to this - there is no field in VACOLS that differentiates whether the decision is IDT or not. VACOLS just checks the document type based on the formatting specified in this github issue.

We don't need to validate whether it was an IDT decision or not, though, just that it has a valid document ID number format to move forward.

All 7 comments

What determines new vs. old? It is BEAAM/RAMP/AMA/etc vs. legacy?

It looks like the "all documents" format for old documents has 9 characters before the period, while the VHA/IME document id formats only have 8 (letter included). Does this mean that non-VHA/IME work products should have the extra character in front? Or should all "old" document ids have 8 characters before the period?

snippet

irb(main):001:0> old_generic = "#########.###"
=> "#########.###"
irb(main):002:0> old_generic.split('.').first.length
=> 9
irb(main):003:0> vha = "V#######.###"
=> "V#######.###"
irb(main):004:0> vha.split('.').first.length
=> 8
irb(main):005:0> ime = "M#######.###"
=> "M#######.###"
irb(main):006:0> ime.split('.').first.length
=> 8
irb(main):007:0> 



Also, should all "#"s be numbers, alphanumeric?

What determines new vs. old? It is BEAAM/RAMP/AMA/etc vs. legacy?

  • "old" here refers to decisions NOT using the interactive decision template, thus having old document ID formats
  • "new" refers to decisions written using the interactive decision template, having the new document ID format

It looks like the "all documents" format for old documents has 9 characters before the period, while the VHA/IME document id formats only have 8 (letter included). Does this mean that non-VHA/IME work products should have the extra character in front? Or should all "old" document ids have 8 characters before the period?

  • VHA/IME document types have a letter in front. Non-VHA/IME should be all numbers

Also, should all "#"s be numbers, alphanumeric?

  • all #'s are numbers

Awesome, thanks! Is there a way in code to differentiate decisions prepared with versus without the IDT?

You're going to love my answer to this - there is no field in VACOLS that differentiates whether the decision is IDT or not. VACOLS just checks the document type based on the formatting specified in this github issue.

We don't need to validate whether it was an IDT decision or not, though, just that it has a valid document ID number format to move forward.

Ok, that works! Last question: I assume decisions prepared w/the IDT can still have VHA/IME work product types (i.e. a "new" decision with an IME work product type should have a document ID like M1234-12345678)?

At this time, I don't think the Interactive Decision Template has incorporated VHA or IME decision types. They are working on it, but I don't think they've released it yet.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

laurjpeterson picture laurjpeterson  ·  4Comments

lomaxap picture lomaxap  ·  3Comments

hschallhorn picture hschallhorn  ·  4Comments

laurjpeterson picture laurjpeterson  ·  4Comments

nikitarockz picture nikitarockz  ·  3Comments