Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Problem(s):
- Libraries often create orders in their own LSP system to keep track of order commitments and manage receiving. If the library has no means of transmitting this data to the relevant vendors they would need to manually re-create these orders in a vendor system.
- Creating orders in a vendor system requires the library to first confirm in their own system whether they currently own the material or not. If the order can be created in the library system and electronically sent it helps prevent the duplication acquisitions work.
Use Cases & Requirements:
Requirement | Status | Use cases | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
Generate EDIFACT format files based on FOLIO Orders. |
|
| ||||||||
Send orders in different formats as specified in the Organization record. Eg EDIFACT format, email etc |
|
| ||||||||
Send orders based on different export method configurations for the same vendor. Configure multiple export methods per Organization record |
|
| ||||||||
Allow user to indicate they want the order to be sent AFTER the order has been opened. "Automate export" can be edited after order is opened. However, once exported this field must be locked down an user must explicitly state they want the order exported again for it to be included in a second export file. |
|
| ||||||||
Send orders in different formats for the same Organization based on account number |
|
| ||||||||
Limit what orders are sent based on Acquisition method for a given vendor |
|
| ||||||||
Allow library to trigger a "Resend" for the generated file |
|
| ||||||||
Display export summary on POL. Allow user to download file ?from POL. |
|
Proposed workflow:
Export details are configured for each organization in the organization record by acquisition method
Acquisition method is a controlled vocabulary
Automated export is set by acq method with "Export via" set by account number in the organization record
Each organization can have multiple Integration details and details types configured. Ie. Possible multiple EDI configuration, Email, csv etc.
Each organization account number can be associated with 1 export detail type. (Ie. EDI 1 OR EDI 2)
Each export configuration can have multiple accounts associated with it. (Ie. EDI 1 can be assigned 3 accounts) NOTE we would need to consider No account specified as a separate assignment for organizations that have no accounts configured.
Integration details are configured for each order line
The POL as a whole will have "Automate export" checkbox set and will be exported via the described format. This way it can be adjusted on an order by order basis.
Note: "Export method" is only editable if Automate export = true
Each order line could have a different account number (Or no account number) associated with it. This will attach it to the correct export details for the format selected at the PO level. Ie. if EDI is selected the account may indicate EDI 1 or 2 etc. If email it could be different per account as well
In this workflow the export path for acq method + account number = export details for POL.
Export details summary is be presented on the POL so user can easily confirm what happened with an export
Accordion contains key details of the export
View export history
View export history for a specific export type by clicking the associated link or button
Arrive at the full screen view of the export history for that organization
User Questions:
Question | Status | Conclusion | Comments | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Should the decision to export be determined by the acq method on the POL and be based on organization? |
| Yes, this provides the flexibility we need. | This allows export decisions to be based on the Organization AND Acquisition method. | ||||||||
Should separate POLs potentially have different export settings? |
| This is not needed at the POL. Nor is it necessary to adjust the export method per POL beyond the default. It would either be Automate export or Not. | No use cases were identified for creating orders with multiple POLs for different accounts that should have different export details. | ||||||||
Do export details need to be shown at the PO level? |
| Yes display export details for PO as a whole | Most institutions will create separate orders for separate accounts which means the export data will often be relevant for the order as a whole | ||||||||
How will this relate to renewals? |
| Waiting for use cases via Slack channel to confirm. No specific use cases brought forward in meeting. |
Vendor Questions:
Question | Status | Conclusion | Comments | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Do you have multiple configurations for individual libraries? |
| Even if the the library or entities within the library have different base accounts they MAY have separate Library EDI Codes or not. FOLIO will need to allow different configuration to have the same library editing code and vendor editing code. | If there were going to be multiple configuration there would likely be multiple vendor records. This is generally the case when there are separate base accounts. | ||||||||
Do you separate orders by account in separate EDI files in in a single file? |
| Separate accounts sometimes appear on the same file in the same location. They can also be separated, this is not a concern for the vendor processing and is common practice. | From the GOBI perspective the same customer may send multiple files in a single day. It is unusual to have separate locations for an individual institution. It typically happens when you have one base account but separate subs for law, bus, etc. which will be uploaded to diff directory locations. | ||||||||
Does the file need a specific identifier? |
| Doesn't have to be specific format just needs to be unique over time | What the ID is is not really a concern so long as the file names are not duplicated. If you are going to "re-send" a file within 90 days. The danger is if the file name is the same it will not be "Reprocessed" because GOBI keeps track of what's been processed. | ||||||||
Does the library need to contact GOBI when a file needs to be "Re-loaded"? |
| As long as they have a resend function they can contact the vendor and the vendor will sort out the file. | The concern is more that the file never reach gobi. Ie. it wasn't successfully uploaded. In this case it would need to be resent. |
Development Questions:
Question | Status | Conclusion | Comments | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
If user unopens order and reopens should this order be exported again? |
| ||||||||||
How are the export dates managed? What will be the start and end date of each export? |
| ||||||||||
Should we allow different POLs on a single order to be exported via different methods |
|
Work Breakdown Structure:
Features:
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
UI Stories
Jira Legacy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
MOD Stories
Jira Legacy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|