Last year I conducted an analysis of a particular business who’s main focus is procuring, storing and supplying general products to large facilities. The focus of my investigation was primarily around the integration of SAP EDI in to the supply chain and in particular the Procure to Pay (PTP) process with a heavy emphasis on the Advanced Ship Notification and the automation thereof.

In the examples I refer to the customer as the party that is purchasing the goods from the Supplier / Vendor for resale. The use of “end customer” will indicate the ultimate customer receiving the product for consumption.

The maturity of the supply chain can be measured in the following 4 categories:

Supply Chain Execution – The “Work”
- How well are you matching supply with demand?
- How “real” are your supply and demand forecasts?
- Is your master data and system driving the execution of the process?
- Are all the tasks in the process being performed in a timely fashion by the correct people?
Monitoring and Exception Management – Visibility – the“Reporting / Information”
- How well are you or your partners performing? Are you improving?
- Are you addressing issues in a timely fashion?
- Can you measure success and failure?
- How are you notifying users of exceptions?
System Integration, Performance and Management – the“System”
- How well are your systems working? Are they integrated with each other?
- Is their one source of truth in your process?
- Is the process automated as far as possible? How many manual touches are made in your process?
- Is the solution mobile enabled? Can you access your information while not wired in?
- Does the system solution support your business process?
People and Organization – the “People”
- Is your organization streamlined to handle the exceptions to the process or are they maintaining the process?
- Are your people educated in the process?
- Are the users analytical in focus or custodian in focus?
- Is change management conducted efficiently in your organization?

What goals are we trying to achieve when we strive toward improving the maturity level of our Supply Chain process?

Since the Supply Chain is part of the “cost” side of the customer transaction equation the company would benefit financially from a reduction in the cost to execute the Supply Chain.
The increased pressure to lower Supply Chain costs should not result in a lowering of service levels to the customer. I.e. improved customer service levels need to be achieved in the process of reducing the Supply Chain costs.
The ability to react faster to exceptions in the supply chain in order to catch imbalances in supply and demand.
Visibility to the status of the supply chain process to all key stakeholders. I.e. The supplier, customer, carrier, end-customer all get to see what’s happening in the process near to real-time.

1. Goal

Why do we need a mature supply chain? Listed below are a few key factors highlighting the desire to improve the end-to-end supply chain process.

Each customer would like to reduce compliance errors from their Vendors
- This specifically applies to the automation of the PTP process
- Compliance issues do lead to inefficient processing of the transaction that could ultimately impact the end customer
In general there is a desire to achieve the perfect order. A perfect order has the following 4 characteristics:
- On Time
- Complete
- Free from damage – Readable format
- Accurate documentation
There is a need to eliminate supply chain gaps through the automation of effective and efficient processes
- Utilization of B2B, EDI or SOA techniques
The people, process, information and system need to be aligned
- The process at the customer is configured to work efficiently according to a set plan
- When the plan is deviated from the process becomes inefficient
- These deviations or exceptions need to be mapped out as to how they will be handled but should not be built into the process. i.e. The system process is not designed around a broken process but it needs to accommodate it
The distributed supply chain demands visibility to all stakeholders of the supply chain process
- An efficient, exception free process depends on across-chain communication and visibility
- Need accurate visibility in to product location, quantity, availability, time to deliver and other product measurements. Such measurements could include temperature of the product when leaving location A and temperature when arriving at location B
- In addition visibility for the role players in the process is critical to the process. E.g. Carrier A will pick up the product from the warehouse
- Visibility needs to be provided to the supply chain role players in an effective user friendly manner. E.g. Mobile analytics, mobile event capturing, web reporting

2. The Detail

I found that the 2 main areas affecting the maturity of the supply chain were:

Vendor Management
- Vendor Negotiations
- Vendor Contracts
- On boarding vendors
- Master data capture
  - Vendor master
  - Material master
  - Pricing
Procure to Pay process
- Supply and Demand forecasting
- Purchase Order management
  - Acknowledgement
- Inbound deliveries
  - ASNs
  - Goods receipt
  - Drop ships
- Invoice Receipts
- Returns

The following sections highlight each of the components of these 2 areas together with the recommendations for improvement in each.

2.1. Vendor Management

Vendor management is performed by the buyers and includes the process to on-board a Vendor and their related products. It covers the negotiation process, system configuration, pricing and reporting.

Vendor On-boarding Process

The following process describes the high level activities taken to on-board a new vendor.

New Vendor Negotiation
- SBA Terms and Conditions – Vendor portal
- The Vendors EDI capability is assessed
- It is determined whether the Vendor will be eligible for certain consideration (E.g. Backorders allowed)
- Rebate / Coops
- Order minimums
Approve Vendor
Once the Vendor has been approved they are entered in to the various systems:
- SAP ECC
  - Core info:
    - Contacts, terms, FOB
- Contract Warehouse
  - Web based
  - Rebates / Coops
- Set up technical EDI relationship
Material setup
- Set up material master in ECC
- Set up PIR (Purchase Info Record)
  - Lead times
- Catalog
  - Product attributes
  - Used as the master for the catalog
  - “Can’t be done in SAP” was the comment I heard…
- Source Lists
  - Multiple sources of supply – Determined during the negotiation phase
- MDM
  - Taxonomy
  - Long Description
- Pricing
  - Tier 1,2,3 pricing
Set up Reporting
- Margin reports (BI)
- Sales reports (BI)
- Vendor receipts (BI)
- Fill rate

2.1.1 Issues in the process

The following issues were mentioned when describing the process:

No KPIs (Key Performance Indicators)
No confidence in metrics so cannot entertain chargeback concept
Currently running BI queries to watch inventory levels…
Parts not entered via EDI
Buyer on both material master and PIR (Also on vendor master) – Redundant data leading to confusion
No exposure to lead time accuracy
SAP transaction VK12 (maintain pricing condition) – Cannot be in there more than 1 at a time
Predictive analysis for new part forecasting (sometimes inaccurate)

2.1.2 Root cause analysis

A culture of automation has not been adopted in the group
- Partners not on EDI leads to an inefficient PTP process
System usage
- SAP has not been fully adopted to manage the process
  - Vendor management / scorecard is not performed within SAP
  - BI is called on to run queries to help with forecasting
  - No trust in the data leads to the system not being used
  - No visibility to vendor performance
Master data being entered in to the system at a vendor and material level leads to an inconsistent process
- Lead times cannot be changed because the visibility to current service levels is not there
- Inaccurate forecasting
- Values stored in multiple locations. No single source of truth.

2.1.3 Suggestions for a mature Vendor Management Process

With an understanding of the costs of doing business with a Vendor in a fully automated way vs. a manual way the emphasis should be on working with Vendors with the EDI automation capability
Rather than potentially chasing a “best of breed” solution look towards a “best of breed” integration
- Working with systems that don’t talk to each other is very ineffective
- The following could potentially be brought in to the SAP integrated suite:
  - Catalog management
  - Forecasting
  - 3rd Party logistics system that takes demand and churns out POs
Follow the Data Governance policies to ensure a single source of truth is available in the system
Understand what is needed for effective analytical reporting
- KPI reporting – Internal
- Vendor scorecard reporting – Knowing how the Vendor is performing will lead to more meaningful discussions with them on how to further improve on the process
- Ensure that the data in the underlying systems supports accurate processing and analytics. Analytics must pull from the same set of data that is used for processing and auditing
Ensure that all the relevant Vendor documentation is available and up to date on the Vendor portal
- EDI standards and changes are communicated via the portal (See section on Path to Vendor Compliance)
Ensure that a vendor’s packing process supports our process
- Packing slip change supports our receipt against inbound delivery
- Labeling on cartons supports our receiving process
Collaborate with the suppliers. It’s a win-win when the supplier reduces compliance errors

2.1.4 What is vendor compliance?

The following 3 areas form the basis for determining a vendor’s compliance to the process.

Shipments are:

Accurate according to our order
- On time
- Correct quantity
- Complete
Communicated to us
- Timely communication
- Electronically (EDI)
  - To our specification
- Communication matches actual shipment detail
Packaged correctly
Labeled correctly
- Legible
- In support of our process

Products are:

Good quality
- Damage free
Correctly labeled

Regulations:

Comply with safety regulations
Comply with social and environmental regulations
Comply with legal terms and conditions

A “Perfect Order ” completely fulfills ALL the above stipulations.

2.1.5 Path to vendor compliance

IT

IT Path to Vendor Compliance

IT works together with the business to normalize the EDI process (Described in detail in the subsequent PTP sections)
- Standardize on IDoc interface structure
- Standardize on communication / structure (IDoc) with 3rd party EDI service provider
- Implement standard EDI error handling via workflow
- Reflect the business changes made to accommodate an automated PTP process in the vendor EDI specifications
Bring the required changes to fruition – Realization
- Establish supplier portal
- Update EDI on-boarding procedure
- Publish vendor EDI specifications created in step 1
- Enable PTP process to 3rd party EDI service provider via SAP NetWeaver PI
- Enable KPI reporting
Support the process
- Ensure efficient use of IDoc processing –Performance
- Ensure effective use of workflow – Exception management – The business takes care of business errors
- Manage relationship with 3rd party EDI service provider
- Execute on-boarding procedure
Compliance support service
- IT ensures message status is transferred to SAP from 3rd party EDI service provider
- Reflect the information of message status in vendor related KPIs / reporting

BUSINESS

Business Path to Vendor Compliance

The business reworks their SBA to adopt clearer and more forceful EDI requirements
- EDI automation
- Service Level Agreements (SLA)
- Chargeback agreement
- Definition of a “compliance error”
- Determine cost of non-compliance
Business to communicate guidelines to the supplier
- Own the supplier portal
  - Ensure publication of supplier specifications
  - FAQs
  - Label specifications
  - TPAs (Trading Partner Agreement)
  - Warehouse locations
  - Sample documents
- Communicate criticality of EDI process
  - Cost of non-compliance
- Internally educate the enforcement of EDI culture
Monitor, measure and publish findings
- Monitor for exceptions
- Measure against compliance SLAs
- Communicate findings with suppliers
- Give visibility to KPIs to key stakeholders
Enforce compliance as per SBA
- Violation management
  - Charge-backs
- KPI visibility
  - Performance trending
- Vendor mentorship / coaching opportunity
- Revise EDI specifications accordingly
- Audits – System, process and warehouse

3 Procure to Pay Process

The Procure to Pay (PTP) process covers the following areas:

Purchase Order management
- Acknowledgement
ASNs / Inbound deliveries
- ASNs (Advanced Ship Notice)
- Goods receipt
- Drop ships
Invoice Receipts
Returns

3.1 Purchase Order Management

This section deals mainly with how the customer handles the creation and management of Purchase Orders. 2 key aspects of this process are often forgotten, these being the PO acknowledgment and PO changes. If not handled correctly or if not handled at all potentially leads to a compromised process.

The 4 aspects that we will deal with in detail are:

Purchase Order (850)
- The customer creates a PO based on the demand and sends the PO to the Vendor
Purchase Order Acknowledgement (855)
- The Vendor receives the PO and agrees to the PO terms (or changes them accordingly)
- The agreement or acknowledgment is communicated back to the customer and this is noted in the system against the PO
- If discrepancies occur between the PO request and the PO acknowledgement then they need to be quickly resolved in order to still meet the demand
Purchase Order Change (860)
- Any subsequent change to the PO needs to be communicated back to the Vendor
- On average, how many changes per order are made?
Purchase Order Change Acknowledgement (865)
- The Vendor receives the PO change request and agrees to the changes (or changes them accordingly)
- The agreement or acknowledgment of the change is communicated back to the customer and this is noted in the system against the PO
- If discrepancies occur between the PO change request and the PO change acknowledgement then they need to be quickly resolved in order to still meet the demand

3.1.1 PO Process Data

There are 2 distinct areas to cover here. One pertains to the PO detail and the second pertains to the response to the PO detail by the Vendor.

3.1.1.1 PURCHASE ORDER AND PO CHANGE REQUEST

Key information is communicated during the PO process including the following:

Address detail
- Ship to address
- Bill to address
Product details
- Product identification
- Product pricing
- Inner pack detail
Shipping detail
- Carrier detail
- Quantity, weight, volume
- Special handling
Payment detail
- Payment terms
- Discounts
Date requirements
- Expected delivery date
- Do not deliver before
Reference numbers
- Customer order number
- Purchase Order number

Similar information is communicated whenever a PO change is made except the change that is needed is highlighted so that the change request can be addressed.

3.1.1.2 PO ACKNOWLEDGEMENT AND PO CHANGE ACKNOWLEDGEMENT

Key information is communicated during the PO acknowledgement process including the following:

PO acknowledgment status
- Was the PO accepted, rejected or accepted with changes?
Product details
- Product identification – A new product may be proposed
- Product pricing – A new price may be proposed
- Product quantity – A new quantity may be proposed
  - Items on backorder
Payment detail
- Payment terms
Date requirements
- Expected delivery date – A new date may be proposed
Reference numbers
- Vendor sales order number

Similar information is communicated whenever a PO change acknowledgement is made.

3.1.2 Advantages

The following advantages can be attributed to a mature Purchase Order process

Impact on the supply is known at the earliest possible moment
- Differences in product, quantity and delivery date are exposed early
Customer impact is reduced through timely accurate information especially in the case where the procurement is “factory direct” or “drop ship” in nature
Purchase order changes flow through subsequent documents which lead to a standard Accounts Payable process
Purchase Order rejections can immediately be re-sourced
Back-office processing savings
- Correct information on the PO combined with mature vendor processes and information leads to a more effective and efficient Accounts Payable process
  - Fewer resources needed to handle exceptions
Differences between the purchase order and the acknowledgement are uncovered in a timely fashion
- Pricing discrepancies are uncovered and addressed

3.1.3 Errors in the Process

Typical errors that are experienced during this process include:

Purchase order contain the wrong details
- Dates (Lead times?)
- Product
- Quantities
- Terms
Incorrect information / data is received from the Vendor
- Acknowledgements don’t reflect what the Vendor agrees to or is misinterpreted by the customer
Purchase Order Change issues
- Manual PO changes lead to the possibility of entry errors and error in interpretation
- Untimely purchase order changes are made
  - PO changes are made when the product has already been shipped
  - PO changes are made and assumed to have been accepted by the Vendor when in fact they have not been. This leads to an imbalanced supply chain
Communication
- Purchase Orders are not received by the Vendor
- Timely communication does not occur

3.1.4 Root cause analysis

The following areas lead to some of the issues mentioned in the previous section:

Master Data Management
- Key master data is not managed efficiently or effectively leading to purchase orders not accurately reflecting the supply plan to the customer
Incorrectly entered PO data leads to incorrect shipments which leads to incorrect invoice receipt information
- Accounts payable is often left holding the responsibility of trying to correct the upstream issues
PO changes are made outside a valid window where change is allowed
Vendor PO Acknowledgements are not used by the customer
Communication is not handled automatically
- Manual touches lead to more potential for errors to be introduced to the process
- Confirmations / acknowledgements are not transmitted and processed automatically

3.1.5 Suggestions for a mature Purchase Order process

Configure and utilize the Order Acknowledgement process in your system
Establish an audit function to ensure the process is adhered to
Master Data Management – Ensure master data is maintained in the ERP application
- Ensure that the people who “own” the master data elements are the ones responsible for owning the updating of those elements
  - Lead times
- Adhere to Master Data governance policy
Understand the financial impact of inaccurate or frequently changed POs that follow an exception process
- Quantify disruptions to the process, customer impact
  - Inventory
  - Customer service
Procurement process – Keep PO changes to a minimum
- Strive towards more accurate demand and forecast management
- Ensuring a tight, informed supply chain keeps the data in the ERP application current and will lead to fewer adjustments to existing POs due to erratic supply and demand documents
Buyers need to focus on exception management
- Ensure discrepancies in Vendor PO Acknowledgements are handled by the correct people in as close to real time as possible
  - Each buyer should be responsible for addressing errors in posting PO acknowledgements
  - Workflow enable this error handling process
Automate the communication of POs and PO changes
Automate the entire process (typically through EDI)

EDI Procure to Pay Process

850 – Purchase Order
- Ensure that all vendors comply to the published electronic standards
855 – Acknowledge Purchase Order (Vendor agrees to the terms and detail in the PO)
- Handle 855 discrepancies automatically using workflow. Workflow should immediately be delivered to the person owning the PO so that they can make the decision to accept or reject the acknowledgement
- Thresholds should be maintained in the system that will allow certain changes to go through without having to be reviewed by the owner of the PO
- If the Purchase Order is linked to a Sales Order for the end customer then this message needs to update the sales order schedule accordingly to reflect what the Vendor has agreed to deliver
860 – Purchase Order changes
- All changes to the PO must be made in the system and the system automatically communicates the changes to the Vendor
865 – Purchase Order Change Acknowledgement
- The message is to be sent by the Vendor in response to the 860 PO change sent. It informs the customer as to whether the Vendor has accepted the change with or without changes or whether they rejected the change request. The customer can then react accordingly to the response
- Once again, workflow can be used to route exceptions to the owner of the PO

3.2 Advanced Ship Notice (ASN – 856)

The purpose of the ASN is to give visibility to the customer for a shipment in advance of its arrival at its destination. All industries utilizing a supply chain process are driving, in some form or other, toward exchanging ASN type information.

Customers use the ASN to prepare for the pending shipments arrival. Vendors continue to struggle to adhere to ASN compliance which can be described in the following way.

The shipment:

Has all the key information documented
Has information that is readable
Has information in a usable format (e.g. EDI X12 856 standard)
Has accurate information (i.e. The packing information reflects the actual packing details, the product serial numbers on the shipment are the actual ones)
Has information received within the agreed timeframe

3.2.1 ASN Data

Various pieces of critical information are sent on the ASN.

Packing information
- Carton labels
- Packing configuration. E.g. Pallet 1 has 2 cartons in it. The 1st carton has 10 units of item 1 in it and the 2nd carton has 5 units of item 2 in it
Carrier detail
Reference Numbers
- Purchase Order number of the customer
- Tracking numbers
- Bill of lading number
Physical Item information
- Quantity shipped
- Product ID – Customer / Vendor ID number for the product
- Product description
- UPC, UCC/EAN-128, Serial numbers
Dates
- Expected Delivery date
- Shipment date

3.2.2 Advantages

The following advantages are attributed to having the ASN information available to the customer.

It allows the customer to receive goods against the ASN
- Improved warehouse receiving process (Can reduce costs by up to 40%[1] (Brian Gibson and Brent Williams, 2011))
  - Greater control, speed and accuracy of receiving
  - Labor cost savings (Warehouse)
- Facilities savings
  - Utilize drop ship model
  - Less area needed to break down pallets for individual receipt.
    - Can receive by pallet or inbound delivery
Differences between the purchase order and the shipment are uncovered prior to the arrival of the shipment
- Allows for planning, order and rescheduling to occur in order to match supply and demand
- Increases product availability
- 3% of all units shipped are shipped in error and 87.46% of shipments had an accurate ASN[2] (Auburn University, Compliance Networks, VCF, 2010)
Fewer discrepancies in downstream processes:
- Billing, Accounts Payable queries
- Customer Service interventions
- Planning / Forecasting imbalances
- Inventory discrepancies
Drop shipped product allows the buyer to send the shipping detail to the customer (Packing, tracking, Serial info)
- The end customer can receive their own 856 ASN
- Customer satisfaction (Receipt of ASN information detail)

3.2.3 ASN errors

ASN inaccuracy greatly reduces the chance of realizing the advantages described above. Errors in ASN information can be caused by many issues in the supply chain process but here are a couple of the more common ones:

Picking discrepancies
UPC, label, tagging discrepancies
Illegible documentation or messages
Purchase order errors
- Incorrect or missing data, product detail, quantities entered
Purchase order changes
- Incorrect changes made, changes made but not communicated in time to the Vendor
Shipment received does not match the ASN sent by the Vendor

The majority (59%[3]) of partners believe that a 1% error rate is unacceptable and an additional 38% believe that a 2% error rate is unacceptable.

3.2.4 Root cause analysis

What are the areas that are causing these ASN errors?

Vendor processes not aligned with customer requirements
- Vendors have little knowledge or understanding of the customer’s requirements or processes or the reasons behind them
- The criticality of key attributes to the customer is not fully understood by the Vendor and thus they devote little time to ensure the quality of these attributes
- Ensure that minimum order quantities are adhered to by the Vendor
  - Customer should ensure minimum order quantity is aligned with an efficient receiving process
- Vendors do not use systems to control their shipping process. Manually issued ASNs may be unreadable
  - Miss picks
  - Incorrect labeling
  - Pre-pack errors. i.e. Factory related errors
  - Ticketing (UPC)
- If the content of the box does not match the requirement then it’s usually for one of the following reasons:
  - Buyers changing the PO and not reflecting these changes in the system
  - PO changes are not automated
  - Both parties agree to change the sku but the system is not updated
  - UPC data errors
Ineffective customer Purchase Order process
- Purchase Orders are entered in to the system incorrectly
- Acknowledgements not received or not received in a timely fashion
- Customer’s master data not aligned with what the Vendor can deliver. E.g. Lead time
Purchase order changes
- Poor planning or lack of good information around demand and supply leads to purchase order changes
- Customers need to understand the implications of PO changes to the Vendors processes
- Each change is an opportunity for errors to be introduced to the process
- Most PO changes are done manually
- Some PO changes are only affected in the system after the change has been agreed on verbally or in writing. Some changes are not affected in the system at all and the fallout comes when the ASN does not match the PO as well as the invoice not matching the PO
- A study done in 2007/8 showed that a PO was changed on average 4.4 times per order (Retail study)[4] Each change grants an opportunity to introduce an error in to the process
Systems
- Best of breed solutions without tight integration to the back-end ERP application
- Ineffective usage of electronic messaging standards (e.g. EDI) Customers should be sending PO change notifications automatically to the Vendor using an 860 message and the Vendor should acknowledge the PO change using an 865 message
  - Missing carton loop in the 856

3.2.5 Suggestions for a mature ASN process

The following are areas that need to be addressed in order to ensure a mature ASN process.

Master Data Management – Ensure master data is maintained in the ERP application
- Ensure that the people who “own” the master data elements are the ones responsible for owning the updating of those elements
  - Lead times
- Adhere to Master Data governance policy
Accurately document what you refer to as an ASN error
- Has all the key information documented
- The information is readable
- The information is in a usable format (e.g. EDI X12 856 standard)
- The information is accurate (i.e. The packing information reflects the actual packing details, the product serial numbers on the shipment are the actual ones)
- The information is received within the agreed timeframe
Understand the financial impact of inaccurate ASNs
- Quantify disruptions to the process, customer impact
  - Inventory
  - Customer service
- After quantifying the financial impact the costs need to be recovered from the Vendors using chargeback’s
  - Vendors will quickly react to this practice of charging for erroneous ASNs
Procurement process – Keep PO changes to a minimum
- Strive towards more accurate demand and forecast management
- Ensuring a tight, informed supply chain keeps the data in the ERP application current and will lead to fewer adjustments to existing POs due to erratic supply and demand documents
- Either send a PO change automatically or cancel and reissue the PO (also automatically)
Supply chain players need to focus on exception management
Automate the entire process
- Using EDI we should enable the following messages with the Vendors:
  - See the Purchase Order process recommendations for 850, 855, 860 and 865 implementation
  - 856 – Advanced Ship Notification
    - Full details are to be sent by the Vendor
      - GTIN must match shipment with ASN
    - The customer loads the ASN from the Vendor as a potential inbound delivery against which they will be receiving the delivery at the warehouse
    - Receiving should ideally be done using RFID scanning
    - Labels should be validated prior to being put in to production
  - 997 – Functional Acknowledgement
    - Reject an ASN if the structure is incorrect or required information is incorrect
      - Missing carton level or pallet level information
  - 824 – Application Advice
    - Communicate a functional rejection of an 856
      - E.g. Unknown PO, Duplicate ASN
- Using EDI we should enable the following messages with the carriers:
  - 214 – Tracking status messages to transact the carrier status messages to the customers ERP application. A key status is the carrier pickup and the Proof Of Delivery (POD)
- Enact standard EDI error and issue handling
  - For all outbound messages the EDI sub-system must send a status message back to the sending system informing them as to the status of the message
    - Passed syntax check
    - Checked Compliance with standards
    - Sent to Vendor
    - Received technical receipt from Vendor
  - These status messages ensure that the Vendor has in fact actually received and technically verified the Purchase Order or Purchase Order change.
  - Statuses can be monitored for outbound messages to ensure that no errors are received.
    - If errors are received then a workflow should be routed to the PO owner for fixing
    - If a message stays in an intermediate step too long then an exception is raised and the appropriate exception workflow is triggered
Customers need to initiate a formal ASN audit process to measure “ASN against shipment” compliance
- 93% of retailers audit shipments against the corresponding ASN[5]
- This audit should take place at the receiving DC
- Check every shipment? vs. Sampling strategy – Only check certain shipments based on criteria
- Put together an audit practice together with policies and procedures to support the audit process -> “Live it”
- Make Vendors aware of the audit process and share the results with them
  - Close the loop with the Vendor
- Use RFID (where cost justified) to affect the audit
  - This in turn requires the Vendor to provide compliant bar coding labeling
- Focus on:
  - new Vendors or
  - problematic or key products
- Use audit results for the following:
  - Assess the ASN error cost. i.e. Cost to our business due to ASN error
  - Assess charge backs / deductions to the Vendor
  - Collaborate with Vendor to stimulate improvement in ASN performance
Vendor Collaboration
- Work with the Vendors to eliminate problematic areas in the process\
  - Enforce stricter auditing procedures prior to shipment leaving
  - Increase the frequency of the ASN submission
  - Validate tickets (UPCs) and shipment manifests
  - RF enable picking
- Perform SKU audit with Vendor
- Automate PO change notices
- Ensure that products that are included in a shipment that are not on the PO are shipped in a separate labeled carton
  - No charge: Samples, promotions

3.3 Invoice Receipt

The invoice receipt is an important part of the process that often highlights issues from earlier on in the process. If you get the process wrong up front then the AP folks are the ones who ultimately end up having to research and resolve the issues. With a mature PTP process in place we can limit these issues up front leading to a more efficient AP Invoice Receipt process.

3.3.1 Invoice Receipt (IR) Data

The following data is commonly communication by the Vendor. The customer is responsible for specifying exactly what data is required in order to have an invoice receipt being accepted.

Vendor Invoice number
Invoice Date
Amount
PO Number
Charges and Allowances
Remit to address / partner
Material and Quantity

3.3.2 Advantages

The following is a list of advantages that can be achieved if a mature Invoice Receipt process is in place

A timely posting of an Invoice Receipt à ability to pay within terms to receive the applicable discount
Charge backs can be effected if the vendor compliance can be accurately measured against published standards
- This leads to a more efficient Vendor process
Efficient processing of invoices / CR memos
- Staffing efficiencies

3.3.3 Errors

The following are common errors when receiving an invoice from the Vendor that is out of synch with the customers’ expectations or understanding:

Invalid freight type / charges
- Charges that were received on the invoice were not agreed to on the Purchase Order
EDI related issues (The following issues could also be received when using manual invoice receipt but when the customer is attempting to automate the process these issues prevent it
- Unidentified PO number
- Invoiced amount is zero
- Invoice amount does not equal detail amount – Sum of line item detail amounts
- No reference invoice number provided
- No or incorrect reference dates sent
- Remit to vendor is missing or invalid
- Currency mismatch between Invoice, PO and Remit to
Invoice already received or previously paid – Duplicate checking
Cancelled PO – The Purchase Order has been cancelled and thus an Invoice cannot be received against it
Past due invoice – The invoice date has past the date for which it can be submitted

3.3.4 Root cause analysis

Invoice Receipts are not communicated to the customer automatically
- Fax or manual
Invoices coming in via EDI are not of the correct format or contain incorrect data
- A manual process is used to recover from these errors
Errors are not passed on to a Vendor scorecard such that Vendor compliance can be measured

3.3.5 Suggestions for a mature invoice receipt process

Implement a 3 way-match for Invoice verification
- Invoice receipt amount and quantity vs.
- ASN / GR amount and quantity vs.
- Carrier pickup notification
EDI Automation
- If an error occurs posting the invoice then it can be attributed to a vendor data error or an application error
  - Vendor data Error à Automate sending an 824 message to the Vendor
- EDI error handling is managed through workflow
- EDI errors are passed off to BI for Vendor scorecard processing
- Carrier EDI
  - 214 à Shipment status information based on PO number
  - Information coming from internal shipping system

3.4 Return to Vendor Process

3.4.1 Suggestions for a mature RTV process

Automate the process using EDI
- Implement the 180 (Return Merchandise Authorization and Notification) message to receive a notification from the Vendor when they receive a returned product

RTV Process

3.5 The EDI Procurement process – An Overview

SAP EDI-enabled PTP Process

A purchase order is transmitted to the supplier
On receipt of the PO the supplier chooses the conditions under which the order is accepted. Of course, the option is to reject the order as well. The following can be changed on the PO as part of the agreement:
- Part number – Supplier may substitute 1 part for another similar part
- Quantity – A different quantity may be proposed for the PO (usually lower)
- Date – A different ship date may be proposed due to availability
- Price – A new price may be in affect
Within an agreed amount of time (usually less than 24 hours) and order confirmation notice is sent back from the supplier
The customer receives the acknowledgement and posts it to the PO if the terms are exactly as stated on the PO or within acceptable tolerances. Terms refer to all 4 aspects of the order confirmation that can be changed
It is up to the customer to determine exactly what processes they will allow in their procurement process. Rules govern how these processes work and these rules are dictated to in the outbound 850 and inbound 855 (Order Confirmation) EDI messages. The following are common rules described in the supplier agreement:
- No backorder allowed – i.e. No changes to the date
- Fill kill strategy – i.e. Accept the order in whole or reject in whole
- Backorder allowed – i.e. Provide the quantity that will be shipped on each date where you plan on shipping it (schedule lines)
Exceptions to the posting of the PO confirmation are to be handled by a workflow process. The buyer assigned to the PO will receive and work the error. Since the PO confirmation literally tells us what the supplier agrees to do for the PO it’s a critical document to post ASAP in order to uncover the exceptions. If the PO confirmation does not match with the PO then we basically have an imbalance in supply and demand that needs to be addressed
A period goes by where the supplier is manufacturing the product or making it ready for shipping where the customer can still affect change to the order
- An order changes should be communicated to the supplier electronically with a similar “acceptance” of the change process done in SAP. i.e. Each PO change confirmation should be handled the same way as the PO confirmation
Once the supplier ships the product they have a short period (usually 1-2 hrs) to send an ASN (EDI 856) message to the customer. For each shipment an ASN is received.
On receipt of the ASN the customer creates an inbound delivery for it against the PO. The inbound delivery is found on the PO confirmation tab of the PO. It contains all the information for the actual product that is on the way including tracking #, items detail, packing info, and carrier detail.
- Inbound deliveries should add up to the schedule as transmitted on the 855 PO response
On receipt of the actual product the warehouse receives against the inbound delivery and not individually
- All the detail came in on the ASN so SAP immediately knows what to receive
- Combine with a manual audit function to ensure the EDI ASN sent by the supplier matches the actual shipment 1 for 1
- Goods receipt entries are soon on the PO History tab of the PO
In the ASN and Receiving stage we are not in the position to affect changes to the process. We need to reflect the ASN and GR EXACTLY as the supplier sent it. If we see a true overage or shortage then this fact is captured and the PO is adjusted accordingly

Below is a pictorial of how a virtual sku or drop-ship model could look like

SAP EDI-enabled PTP drop-ship Process

The Supply Chain has many moving parts but if you can choose the 3-4 processes that you wish to support in your organization (e.g. Warehouse PO, drop-ship PO, RTV, …) and standardize their workings within SAP then EDI automation can be quite easily accomplished. The trick is in not providing one-offs for every supplier. Keep it simple and pure…

Acknowledgements:

[1] Advanced Shipping Notification: The Key To Supply chain Visibility (Brian Gibson and Brent Williams, 2011)

[2]ASN Exposed (Auburn University, Compliance Networks, VCF, 2010)

[3] Advanced Shipping Notification: The Key To Supply chain Visibility (Brian Gibson and Brent Williams, 2011)

[4] (Auburn University, Compliance Networks, VCF, 2010)

[5] ASN Exposed (Auburn University, Compliance Networks, VCF, 2010)

Pages

Monday, May 4, 2015

Real use case: Supply Chain Maturity Whitepaper