Yoga FSM - EDI and Automated Invoices

Table of Contents 

Version 1 - EDI 810 Image Processing

Version 2 - EDI 810 Invoice Processing

Automated Invoices CSV - Invoices with GL

Automated Invoices CSV - Invoice with PO Lines

Version 1 - EDI 810 Image Processing

Yoga's version 1 EDI image processing solution runs daily in select client environments. This opt-in is an additional cost to your SaaS subscription. The job picks up raw EDI 810 strings from the past 30 days from Infor's EDI Transaction History business class. Those strings are parsed to create images based on the data provided in the raw strings. A web call is then run in Infor against key information like Invoice Number, PO, Vendor, and Company to determine if a Payables Invoice record has been created or if the record is stuck in Infor's Match Interface tables.

• If Payables Invoice - the image is posted to that record on the invoice layer as well as stored against the Payables Invoice number in Infor Document Management (IDM)
• If no Payables Invoice - the image is posted to Yoga's EDI view in Yoga. The image could remain there for up to 30 days. If a Payables Invoice is created within those 30 days, the image will be exported from Yoga to Infor's Payables Invoice record in CSF and IDM. Users can use the Yoga stored image to assist with resolving the Infor Match Interface issues. 

Below is a redacted example of an EDI image in Yoga. You will notice the form stores additional information from the EDI Transaction History tables in Infor to assist the necessary resources with troubleshooting match interface issues.

Yoga recommendations for EDI images stored in Yoga:

• Images should not be sent through OCR extraction.
  • These images will then come at the cost of a document for the Invoice solution, not the EDI solution.
  • These images then run the risk of duplicates between systems once the Match Interface record can be resolved, and an attempt to create the invoice is conducted twice.
• Images can be used as a source to assist with resolving match interface issues, such as Buyer Messages or PO Discrepancies

Version 2 - EDI 810 Invoice Processing

The Yoga EDI 810 Version 2 Invoice Processing removes a lot of the complexities our clients have today with managing EDI tables, working around P2P workflow issues, and users having to monitor multiple systems for problem invoices. This process seeks to streamline the AP workflow and EDI 810 workflows in 1 system. 

Below is the end-to-end workflow for the EDI 810 - Version 2 Invoice Processing:

1. A Yoga job is ran to pickup raw EDI 810 files from your EDI providers SFTP (usually every 5 minutes)
2. These raw EDI 810 strings then go through a processor to create the image and store the data from the string against the document itself
   1. Customizations can be made in this solution to bypass common EDI 810 issues today and will be maintained by your Yoga SaaS team
3. The images and their now stored data is then sent through Yoga's OCR and Validation scripts to perform custom tenant logic to assist with PO issues and invoice issues that existed in the raw EDI 810 file
4. Invoices that meet Yoga's requirements to go straight-through to the ERP will flow straight to creating the Infor Payables Invoice with attached generated image
5. Invoices that may have PO header or basic line level issues (line closed, line missing, header closed, header doesn't exist) will stop in AP Review to be reviewed by the team and then can be sent to Purchasing Invoice Resolution for additional buyer support if needed.
   1. This allows for 1 streamlined workflow and a central area for the team to resolve outstanding invoice issues that would prevent the invoice from being created in the ERP

Automated Invoices CSV - Invoices with GL

This process available in Yoga supports several of our Government Essential clients and others who may receive mass invoices in a csv template that need to be parsed, posted to a invoice form and have a corresponding invoice image generated to show the raw data to the AP team and invoice approvers.

This process can support custom columns for invoices coming from different areas, multiple available points of ingestion, or GL and invoice validation.

The standard process from for these invoices is called out below but may accommodate customizations:

1. An agreed-upon template for the CSV's is created during project implementation. These columns are then mapped to different value's in the clients masterdata based on the rows.
2. Each row should start with an H (header information) or L (line information). This allows Yoga to determine when one invoice starts and the next begins.
3. For the H rows, information such as the Company, Vendor, Invoice Number, Invoice Amount, Invoice Date, etc should be completed.
4. For the L rows, information pertaining to you general ledger structure should be completed. The spreadsheet does not support validation in the raw form. The validation will be complete upon integration with the ERP
   Example Template:
   
5. Once the spreadsheet is complete, these can be ingested via a new email connection source, custom capture page, or file pickup from a network drive
6. The file is then ingested into Yoga and parsed through to generate the form data and image based on the provided information
7. If no key header level information is missing and all validation checks are met, the invoice will be flagged for STP
8. These invoices can be tracked in Yoga with having a source of "EXCEL". If successful GL lines and header information, the invoices should be in Awaiting Payment. If any missing information or invalid GL coding, the invoice will be in AP Review to be reviewed by the AP team for any potential issues.

Automated Invoices CSV - Invoice with PO Lines

Similar to the above solution for GL Lines, Yoga can also do CSV uploads for PO invoices with PO lines! This process works best for clients not utilizing a formal EDI 810 process today, but the vendor supplies the invoices in a spreadsheet format.

This process can support all necessary PO line columns, validation on PO data from a header and line level perspective. Note - all line-level issues with amounts should still be handled with buyer messages in Infor.

The standard process from for these invoices is called out below but may accommodate customizations:

1. An agreed-upon template for the CSV's is created during project implementation. These columns are then mapped to different value's in the clients masterdata based on the rows.
2. Each row should start with an H (header information) or L (po line information). This allows Yoga to determine when one invoice starts and the next begins.
3. For the H rows, information such as the Company, Vendor, Invoice Number, Invoice Amount, Invoice Date, PO Number, etc should be completed.
4. For the L rows, information pertaining to you PO lines should be completed. This should include at a minimum the line number, UOM, quantity, and unit cost
   
5. Once the spreadsheet is complete, these can be ingested via a new email connection source, custom capture page, or file pickup from a network drive
6. The file is then ingested into Yoga and parsed through to generate the form data and image based on the provided information
7. If no key header level information is missing and all validation checks are met, the invoice will be flagged for STP. For PO invoices, a check is ran against PO lines equaling the invoice amount and if lines may be closed or cancelled in your ERP.
8. These invoices can be tracked in Yoga with having a source of "EXCEL". If successful, the invoices should be in Awaiting Payment. If unsuccessful, the invoice will be in AP Review to be reviewed by the AP team for any potential issues.