Acquisitions API migration enhancements
Related Feature
UXPROD-2619: Acquisitions API migration enhancementsOpen
Stability - Batch size
Set a reasonable goal for what batch sizes the modules can handle and make sure the modules can deliver on the promised numbers given it is run/hosted under the minimum requirements. Make this super clear by throwing exceptions for too large batches.
Legend
Priority | Description |
|---|---|
P1 | Blocking a requirement and no viable workaround |
P2 | Blocking a requirement and workarounds are extremely time consuming |
P3 | Compromising a requirement but workarounds are reasonable |
P4 | Unfortunate limitation that we can live with for now |
P5 | Desired functionality that would exceed expectations |
Organizations
Challenge | API | Release Version | Priority (P1-P5) | Comments | Identified by | JIRA Issue |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Orders
Challenge | API | Release Version | Priority (P1-P5) | Comments | Identified by | JIRA Issue |
|---|---|---|---|---|---|---|
Order date cannot be set in the past |
|
| P2 | Without this ability we cannot properly migrate current orders | @Dennis Bridges |
|
FOLIO requires different cost and quantity keys depending on format, but this is not broken down in incoming data |
|
| P2 | Desirable to create appropriate objects/keys depending on format and let total quantity govern – do not enforce quantity data restrictions when not connected to holdings/items – | @Kyle Banerjee |
|
Intelligent defaults for related keys/objects |
|
| P2 | Required fields in FOLIO frequently don't exist in source. For example, physical and electronic quanities are rarely differentiated in source. If order is electronic resource, API ideally knows set listUnitPriceElectronic in additionto quantityElectronic and not to have a listUnitPrice or quantityPhysical keys either in the cost object or locations array. Likewise, if an order type is ongoing, we'll want to set subscription to true and manual renewal to false -- incoming data won't have an isSubscription or manualrenewal fields.
Likewise, if something is an electronic resource, it knows the to set listUnitPriceElectronic in additionto quantityElectronic and not to have a listUnitPrice or quantityPhysical keys either in the cost object or locations array. | @Kyle Banerjee |
|
Receiving
Challenge | API | Release Version | Priority (P1-P5) | Comments | Identified by | JIRA Issue |
|---|---|---|---|---|---|---|
Piece records require titleId which doesn't exist until after po line is posted. | /orders/pieces |
| P3 | Must post po & po line, extract titleId from po line and assign it to piece record, then post piece record. Honeysuckle release. | @Anne L. Highsmith, TAMU |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Invoices
Challenge | API | Release Version | Priority (P1-P5) | Comments | Identified by | JIRA Issue |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Finances
Challenge | API | Release Version | Priority (P1-P5) | Comments | Issue identified by | JIRA Issue |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
General
Challenge | API/Area of FOLIO | Release Version | Priority (P1-P5) | Comments | Identified by | JIRA Issue |
|---|---|---|---|---|---|---|
It is currently hard to pin down the version of the schemas used in the Tenant. It would be great if the API:s could expose the json schemas . This would be very useful for creating mapping files, and validating data before migrating. As part of this, it would be great to have the referenced schemas in schemas either added as part of the schemas or at least make the links resolvable. Please ask it the last part is unclear. | All APIs that are using JSON Schemas |
| P3-P4... |
| @Theodor Tolstoy (One-Group.se) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|