Page Comparison

• Library currently communicates all orders with large vendors via EDI. This reduces the amount of duplicate effort needed to manage acquisitions through this vendor. Often this is because the vendor could not or would not support a direct API integration with their ILS system
• Users need to confirm that they don't already own or have an outstanding or for the material they want to acquire. This is most easily done in the LSP system. Libraries will then check multiple vendors to compare pricing before acquisition.

• Library needs to configure different EDI details for different organizations. Often files need to be uploaded to different directories or use different naming conventions or different codes
• Horrasawitz does not accept standing orders via EDI so the library will send PDFs via mail or email.

• The institution has multiple libraries there will be different pickup and dropoff directories for the EDI files. Meaning two separate EDI files would be uploaded to two separate directories OR two separate FTP locations. Eg. one for Main library and one for Law
• Some accounts with different envelope addresses (Library EDI codes) may be included on the same EDI file OR the library may need to have them exported on separate files. 

• When we know files are being uploaded later in the day to the FTP location, someone may notice that an order was included on the wrong file. To correct this they will edit the order and indicate it should be exported and save. This should allow this order to be included in the file before it is uploaded to the Vendors FTP location at the set time.
• The library has not noticed that the box was checked and would like to uncheck the export box after it was opened but before it was included in the export.
• Library occasionally will want to re-send an order in a "new" export file. Say there has been a change of Vendor.

• For a given vendor the library may send most orders through EDI but treat some order types differently.
• Data that drives the identification of a different communication method
  • Account number (Team/location/Acquisition unit. These would likely be represented by account number)
  • Acquisition method (for diff methods the order may of may not be exported for a given Vendor)
  • Order type (One-time, Ongoing, Ongoing-subs)
  • Material type (this could be a concern but generally if it is it will be backed into the account number or order type)

• For some material types the library will send order info through EDI but for others, they may create orders in the vendor systems and recreate in FOLIO.
• The library will differentiate between rush and non-rush. Non-rush orders going through EDI and Rush orders going through email
• Orders that are identified as certain acquisition methods should NOT be exported because the Vendor would already have these orders. 

• If something goes wrong with the upload to ftp (Which does happen) we need to be able to resend the EDI file, without regenerating it and sending additional orders along with it. Eg. If order was changed from hard cover to paperback we would want to send in a new file.

Display export summary on POL. Allow user to click a link and find the export file in the export log area. 

• Generally not many users are involved in trouble shooting EDI issues. Being able to find the file that a specific vendor did not receive is important but would be done by administrators.

• It is helpful for users to be able to identify the sent date and status of export etc. but only admins should be able to manage exports.

• For rush orders we have the ability to choose to send an order immediately in EDI format. This file is sent as a single record via email to the vendor. These are sent to a specific address noted in the Vendor record. They are sent with specific subject and via an email address specified in the Vendor file.

This allows export decisions to be based on the Organization AND Acquisition method.

Should separate POLs potentially have different export settings?

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.

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.

Often times new orders will be created when significant details change. 

There are some situations where significant details change but we don't want the order to be sent.

Build the export file based on what orders have not yet been sent for a given vendor. When we try to send a previously exported order the system shows error message

Build base on orders that have been opened and not exported yet.

User makes changes of the config for which scheduled export orders In Progress :

What is expected behavior?

a) existing task should be stopped and overwritten by new one

b) new task should wait completion of active scheduler execution in the queue?

Check and confirm that initially set up job is not executed immediately (mod-data-export)

!Checked with Slava Kandramai :  Scheduled job run immediately

Code ref : org.folio.des.scheduling.ExportTrigger#scheduleTaskWithDayPeriod

(mod-data-export-spring) Refactor existing approach to store configuration for Schedulers :

The design should be easily extensible for new types of exports and customer requirements for export settings (for now BurSar configuration is hardcoded).

1. Rework scheduling approach for supporting multiple Cron jobs with different configurations 
2. Implement scheduling of the EDIFACT orders export

Implement EDIFACT export worker (mod-data-export)

• A new worker should be able to query data from mod-orders, convert it from FOLIO format into EDIFACT and upload the result onto FTP
• Is there any existing open-source re-usable implementation, or own implementation is required?
  • UPD: Folijet is using for EDIFACT writes/generates EDIFACT as well as reads/parses: https://github.com/xlate/staedi. Here's the spike regarding selection https://issues.folio.org/browse/MODDATAIMP-317

Move uploading logic on FTP from mod-invoice (src/main/java/org/folio/services/ftp) to mod-data-export-worker (mod-invoice → Kafka → mod-data-export)

Institutions reported that they will send EDIFACT order data to an average of 6-10 different Vendors

Between 100 and 300 orders per week

An average of 50 orders per Vendor per week

Conservative estimate would be that a larger file would include 500 orders. Which could be 5000 order lines in one single export file.

Order/Order line export history

• mod-order-storage  Create table with indexes
• Create mod-orders export-history API
• mod-orders Create Event consumer from mod-data-worker-spring

out of lotus except filter by export date

3 SP + 1 SP