Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines
(UXPROD-1146)
|
|
| Status: | Closed |
| Project: | mod-orders |
| Components: | None |
| Affects versions: | None |
| Fix versions: | 3.0.0 | Parent: | Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines |
| Type: | Story | Priority: | P3 |
| Reporter: | Craig McNally | Assignee: | Craig McNally |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||
| Sprint: | ACQ Sprint 52, ACQ Sprint 55, ACQ Sprint 53 | ||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||
| Development Team: | Thunderjet | ||||||||||||||||||||||||
| Tester Assignee: | Craig McNally | ||||||||||||||||||||||||
| Epic Link: | Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines | ||||||||||||||||||||||||
| Description |
|
Define the RAML for the receiving items/check-in pieces functionality. The details can be found in Orders API Listing Acceptance Criteria:
|
| Comments |
| Comment by Piotr Kalashuk [ 19/Dec/18 ] |
|
Sample scenarios for POST /orders/<id>/receive or /orders/<id>/check-in. Let's assume that we are going to receive a few items (check-in a few pieces) for 5 PO lines.
In the 3rd case we might return 500 response but with json content returning either:
Craig McNally - could you please have a look and advise if you are okay with any of the approaches or you think the behavior should be different. Thanks, |
| Comment by Piotr Kalashuk [ 20/Dec/18 ] |
|
This story can be only completed once the changes of the
|
| Comment by Craig McNally [ 20/Dec/18 ] |
|
1) I like your idea of using 201 w/ location of receiving_history w/ query, but I can't think of an elegant way to form the query... All I can think to do is something like: peiceId== <id1> OR pieceId == <id2>... etc. for each piece being received/checked in. I think the query could potentially get quite long very quickly, especially given the length of a single uuid. We also need to keep in mind that in the receiving case we won't actually be creating records, but updating existing records. This may be reason for endpoint semantics to diverge, or we could take a more general approach: Return a 200 (no location header) with a json response body containing the locations of the various receiving_history "records". We might want to include other information in the response body as well about each piece, so it's clear which link/location corresponds to which "piece" in the request. Care must be taken when naming the fields in this schema to avoid confusion... there's already a "location_id" in the check-in collection schema... maybe use the term "link" instead. 2, 3) I think we want to be consistent here... I'm on board with returning a response with a list of errors, but we should respond with the regardless of whether they all failed or only one failed. It might make sense to combine all this into a single schema where we return some information for each peice in the request, whether it be a link,etc. or an error message. Thoughts? |
| Comment by Piotr Kalashuk [ 22/Dec/18 ] |
|
Piotr Kalashuk:
Craig McNally
|
| Comment by Piotr Kalashuk [ 22/Dec/18 ] |
|
The raml file update committed to MODORDERS-72-receiving-endpoints branch. There are following dependencies:
Once both the changes mentioned above are done, the acq-models sub-module in mod-orders should be switched to latest version and pushed to MODORDERS-72-receiving-endpoints. After this the PR can be created. Regards, |
| Comment by Piotr Kalashuk [ 14/Jan/19 ] |
|
The PR #58 of the acq-models repository has been merged. Regards, |
| Comment by Piotr Kalashuk [ 21/Jan/19 ] |
|
The PR #61 has been merged to master. Orders API documentation now has receiving endpoints. |
| Comment by Piotr Kalashuk [ 23/Jan/19 ] |
|
Verification hsa been done against folio-testing-backend01.aws.indexdata.com back-end that all 3 defined endpoints accessible and return expected at this stage 501 (Not Implemented) response: The following requests used:
POST {{protocol}}://{{url}}:{{okapiport}}/orders/receive
{
"toBeReceived": [
{
"poLineId": "{{$guid}}"
}
],
"totalRecords": 1
}
2. Check-in
POST {{protocol}}://{{url}}:{{okapiport}}/orders/check-in
{
"checkInItems": [
{
"poLineId": "{{$guid}}"
}
],
"totalRecords": 1
}
3. Receiving history GET {{protocol}}://{{url}}:{{okapiport}}/orders/receiving-history
|
| Comment by Craig McNally [ 24/Jan/19 ] |
|
I too verified this on folio-testing using similar requests and got 501 responses as expected. |