...
- Folijet:
- Update UI matching screen to include options for POL and VRNs for each Inventory record type
- Instance: UIDATIMP-1046
- Holdings: UIDATIMP-1047
- Item: UIDATIMP-1048
- Add stories for happy path and exception E-to-E tests: UIDATIMP-1050
- Update UI matching screen to include options for POL and VRNs for each Inventory record type
Automated Testing Scenarios (for API Karate and UI E-to-E)
Scenario 1: Match on POL and update Instance, Holdings, Item (fill in some details about necessary profiles, and supply test data)
Scenario 2: Match on POL, but no match
Scenario 3: Match on POL, but multiple match
Scenario 4: Match on VRN, and update Instance, Holdings, Item
Scenario 5: Match on VRN, but no match
Scenario 6: Match on VRN, but multiple match
Developer Questions:
Question | Status | Conclusion | Comments | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| What changes are needed to the UI matching screen? |
| Add POL and VRN options for each Inventory record type | |||||||||||
| Any different considerations if the match-from and/or match-to field is repeatable? |
| ||||||||||||
| Where do we pull the POL and VRN from? |
| Pull POL or VRN from the MARC field/subfield designated in the match profile | |||||||||||
| If we only wanted to match on POLs or VRNs for orders that are Open (and maybe Closed), but NOT Pending, would that be an issues? (we already use similar logic for EDIFACT invoice matching between Invoice line and POL/VRN) |
| No, not an issue, but confirm with Thunderjet exactly what story/work is needed from them | POs with Ongoing status (in receipt or payment) are included with Open Order status is at the PO level, but POL/VRN are at the POL level. May need to hit a composite endpoint to get the number and the status. Per Siarhei H, can use cross-index query to also find the status of a POL | ||||||||||
| E-to-E automated tests; how many, and happy path only, or negative too? |
| See draft test Jira UIDATIMP-1050 |
|
...