Cash management transactions from order/payment processing, payroll, employee expense reimbursement and most other cash payment/receipt transactions can and should be automated.  I usually ask a simple question of the CFO of any potential client company: "How do you pay your electric bill?".  In most (95%) I get a standard response that they don't write a check and mail it; no either they or their spouse pays 'paperless' via a free banking service called 'Electronic Bill Pay.  Most financial institutions, Banks, Savings & Loans and even some stock portfolio companies like E*Trade, offer this service!  Who do companies continue to print/mail/fax invoices, checks and other payment instruments?  Oftentimes it is because the Financial Institution they are using still is operating with 1970's technology (although even then EDI transactions were fully supported!).

The cost of handeling, the paper/forms themselves are hugely expensive.  Just the operational/security aspects are so costly that there is almost no way it could be cost justified in a proper ROI study/analysis.

Most ERP systems, especially JD Edwards have fully functional payment/cash-receipt processing interfaces built into the standard infrastructure; yet so few companies utilize them.  Sure, companies sent out electronic Purchase Orders and Receive electronic Invoices (and visa-versa), but few implement the obvious next step to automate cash management (payment/receipt).  Why?  Frankly I have absolutely NO IDEA~!  The technology has been available for decades.  The cost savings is HUGE and RE-CURRING; savings that continue year after year.  Savings in employee expense, paper and machine costs (don't forget the maintenance contract on those printers, fax machines and mail room equipment!).

This IS 2012 for goodness sake?  Why is your company still operating in the 1970's when it comes to payment/receipt. Float is a non-issue for payments.  Sitting on invoices and holding payments is costly, time consuming and frankly not smart.  It is MUCH more cost effective to pay upon receipt and take early payment discounts (if you don't have these in your contracts negotiate for them!), then then worry about reconcilement of discrepancies later.  These are after all Trading PARTNERS for the most part and would not apply to one-time payments.  These are Vendors or Customers we are talking about; oftentimes organizations you have been doing business with for years/decades. 

Think about how you handle Cash payment/receipts.  We CAN save you money on a recurring basis.  See this simple outline for handling Order to Cash:

EDI Order to Cash Preparation - An Outline

 

Trading Partner

1. Document/retrieve all trading partner agreements.  Update as necessary with legal department.
2. Retrieve/update each trading partner EDI mapping and shipping/receiving document.  This is usually available at the Partner secured web site.  Ensure valid logons are available/created.
3. Identify each Trading Partner EDI help desk contact information.
4. Identify each pre-agreed EDI document to be exchanged.
5. Document pending/untested documents in preparation stages.
6. Prepare announcement letter to each Trading Partner to notify them of the impending change of ERP systems.  Mail/send prior to go-live testing.  Some may require re-certification, but most will not.  Notification is ‘heads-up’ to early detect any deficiencies and forestall initial chargeback due to format/content errors or discrepancies. 

 

JDE Data Structure

1. Analyze the data format, structure and process for the non-ERP to ERP interfaces.
2. Map/Identify data element components from each source system, how retrieved and updated with format and properties defined.
3. Document resulting interface tables/records to be used for EDI processing.
4. Develop corresponding logical file overlay for Inovis EDI mapper.
5. Develop corresponding EDI mapper User File Definition (UFD).
6. Test and validate all file/table creation and included data elements and formats.
7. Create a structural functional test map for each type of transaction format (Order (including SDQ), Invoice, ASN, etc.)
8. Make adjustments as required.
9. Validate that the mapping process will work with the table/file structure as presented.

Business Process – Preliminary Testing

1. Define various order types, processes and data requirements.
2. Define Customer response requirements and change processes (Order confirmation and/or change).
3. Define fulfillment business process scenarios: Packaging, Pick n Pack, Pallet, LTL (Less Than Truck Load), Truck Load.
4. Assign Trading Partners to a business process to group for mapping and testing that correspond to previously defined classification/type.
5. Identify existing or new inbound orders that will meet the business process requirements by Trading Partner.
6. Process each order or set of orders by Trading Partner or Business Process (whichever is more expedient).
7. Map data process flow through the ERP system to verify all elements are passed correctly and data fields are accurately updated (especially for split lines and line change/modification/cancellation).
8. Generate outbound files for test data mapping and validation.
9. Test third party integration data components for accuracy and validity.

Define File, Table and data usage.

1. Document each data element required by the process, its properties and how it will be utilized and passed through (and if it will pass) the ERP system.  Example would be use of user fields and fields normally used for PO numbers.
2. Identify/Create interface files for mapping as determined by preliminary testing.  These may include auxiliary files to compliment the ERP standard EDI interface file structures on both the inbound as well as the outbound side of the fulfillment process.  These files may also compliment third party auxiliary systems external to the ERP system process architecture (i.e. LogPro, Pfastship, etc.)
3. Identify cross reference tables used to identify address book to customer ship to locations, etc.
4. Define external and ERP internal table resources and usage.
5. Specify user exits for EDI mapper tool to access cross reference tables and lookups.

Mapping Process and End to End testing. (Each Trading Partner)

1. Create Trading Partner prototype maps for Order, Invoice and ASN based on available test data and completed orders (see business process above).
2. Process the EDI files and create inbound/outbound EDI transactions records.
3. Validate format of EDI transactions according to individual Trading Partner requirements documentation.
4. Validate format and data content of EDI transactions based on business process and data content.
5. Validate completeness of each transaction (no missing data fields that are required to meet Trading Partner specifications).
6. Compare and Validate ASN transaction data content and format with the corresponding Invoice transaction to verify it matches originating order and subsequent changes (especially line level modifications/splits).
7. Update status sheet and freeze maps for production insertion.
8. Repeat for each trading partner map.

Operational Pre-Production

1. Develop reports, logs and other materials as needed to manage the ongoing production EDI process.
2. Segregate EDI production maps from ongoing development/maintenance (utilize dual data libraries with Inovis).
3. Identify operational procedures to insure that the daily EDI interface processing occurs on a regular, scheduled and confirmable basis.
4. Develop documentation of the EDI Trading Partner agreements, maps, processes & procedures.
5. Document audit trails (as may be required by Sarbanes-Oxley Act) and transaction process flows.
6. Develop charge-back monitoring and control to quickly respond to errors and omissions that result in financial penalties due to incomplete or inaccurate EDI transactions submitted to Trading Partners. (See Trading Partner Agreements).

---