Description of the problem

In German libraries, it is necessary to automate the sending of orders in FOLIO via e-mail to a greater extent. For example, the SLUB Dresden sends about 2500-3500 orders per year via e-mail, which cannot be sent manually.

• Status quo of functionality in FOLIO
  • In FOLIO only EDIFACT integration is available so far
  • An e-mail integration for an automated e-mail dispatch is needed

  • Jira Legacy
    server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1129

    is a good basis, but yet not sufficient due to the lack of automated processes
• EDIFACT cannot be applied in several use cases
  • Suppliers do not use EDIFACT (small publishers, ...)
  • This affects especially publishers of deposit copies for state and national libraries
• In the D-A-CH region, automated order dispatch has a very high priority and developments will be commissioned and carried out by institutions of the D-A-CH area, as soon as the necessary resources are available.

Proposals / Examples UB Leipzig and SLUB Dresden

App Organisations

• The integration details in the app Organizations could be expanded: 
  
  • Integration for e-mail dispatch
  • Use of a schedule function (corresponding to EDIFACT Scheduling) for an aggregated order dispatch - all orders for one vendor are send in one email

App Orders

• Display/Selection of the integration method in the app Orders
  
  • Default-Selection of the integration method by configuration of the vendor in the app Organization
  • There should be no manual selection per order!
• Configuration of the texts of the orders
  
  • Different email templates must be configurable 
• Management of logging and error message
  
  • This should ensure that orders have actually been sent correctly
  • This is not available for EDIFACT so far and could be designed and implemented for all integration details
• Dispatch/send date
  
  • In some institutions, the dispatch/send date of the order should trigger the claiming process 
    
    • There are different requirements in the institutions for the start of the claiming process: dispatch/send date vs. opening date 
  • Therefore a function should be implemented, which allows each institution whether to apply the dispatch/send date (yet to be created) or the opening date (already existing) as trigger of the claiming process. 
    
    • Institutions that previously applied the opening date should be able to continue to do so
    • Compare the following functions with different settings opportunities for institutions 
      
      • Approval required → to open orders in settings of app orders
      • Disable instance matching → in app orders settings
• Order cancellations
  
  • Cancellations of orders should also be sent automatically

Questions/notes

Notes

• Ongoing developments that could be considered:
  
  • Order reminder
  • Journal management
• Opening The first aim is opening a discussion in the Acquisitions SIG - for the next aims see the questions below

Questions

• Can a JIRA ticket be created for this issue?
• Do the requirements fit into the general concept of FOLIO acquisition?
• Are there any international requirements regarding the issue?
• Should a small working group work out the issue?

JIRA tickets and related comments

• Jira Legacy
  server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1129

• Jira Legacy
  server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UIOR-670