High- Level Specification

Functional Overview

A custom function module will be developed to validate incoming vendor invoices that are not associated with a Purchase Order (Non-PO invoices). The module will enforce the company’s “No PO, No Pay” policy by verifying whether the vendor is authorized to submit Non-PO invoices, allowing only limited exceptions. Non-PO invoices flagged as Vendor Not Allowed For Non-PO will be automatically rejected, except for credit memos or invoices originating from the OCR/E-Invoice channel.

Scope and Objectives

The objective of this enhancement is to implement a functional control mechanism that automatically identifies and rejects Non-PO invoices submitted by vendors who are not authorized for Non-PO invoice processing as per the Vendor Master Data settings. This will ensure adherence to company policy, improve invoice validation accuracy, and reduce manual intervention.

This functional module will have:

1. Validation Logic

   • Check all incoming invoices to determine whether they are Non-PO invoices.

   • Cross-reference each Non-PO invoice with the Vendor Master Data to verify if the vendor is flagged as allowed for Non-PO invoices.

2. Exception Handling

   • If the vendor is not allowed for Non-PO invoices:

     • The system will auto-reject the invoice.

     • The rejection will apply only if:

       • The source input channel is not OCR (Optical Character Recognition), and EDICOM

       • The invoice is not a credit memo.

3. System Behavior

   • For invoices meeting the exception criteria (vendor not allowed, not from OCR, and not a credit memo), the system will automatically:

     • Flag the invoice as “Rejected – Non-PO not allowed for vendor”.

     • Send rejection status to source Portal

     • Terminate the workflow

4. Audit and Reporting

   • Maintain a log or report of all invoices auto-rejected under this rule, rejection reason, and timestamp, for audit and compliance purposes.

Assumptions

The reference field indicating whether an invoice is allowed for Non-PO processing will be maintained in the Vendor Master Data.

Dependencies

Return to Vendor logic enhancement which will trigger the email to vendor or status update based on the source of input channel as per following development card:

ERP-950 - Authenticate to see issue details

Security, Integrity and Controls

There is no specific security required for this enhancement.

Configuration Requirements

Configure custom business rule 'Vendor Not Allowed For Non-PO'.

Custom FM  to be configured for this VIM exception.

Language Requirements

RTV email templates will be created in multiple languages in SO10 as part of the configuration. Rejection reasons will also be maintained in all required languages. During automatic rejection, the system should select the appropriate email template based on the supplier’s country to trigger the auto-rejection email. For the portal status, the logic should automatically derive  the rejection reason from the table based on the supplier’s country.

Special Requirements

N/A

Design Rationale

Functional Requirements

Non-PO Invoice Validation Logic-A custom function module will be developed to validate all incoming vendor invoices that are not associated with a Purchase Order (Non-PO invoices). The purpose of this module is to enforce the company’s “No PO, No Pay” policy by ensuring that only vendors authorized for Non-PO invoicing can submit such invoices. Invoices submitted by vendors who are not permitted for Non-PO processing will be automatically rejected, with limited exceptions.

Data Validation Logic:

• Identify all incoming invoices that qualify as Non-PO invoices.

• Validate each Non-PO invoice against Vendor Master Data to confirm whether the vendor is authorized for Non-PO invoicing.

Exception Handling

If a vendor is not allowed for Non-PO invoices, the system shall automatically reject the invoice, except in the following cases which will be routed for manual review:

• The invoice originates from the OCR or EDICOM channel

• The document is a credit memo

Auto Rejections

For Non-PO invoices not meeting the exception criteria, the system shall:

• Flag the invoice as “Rejected – Vendor Not Allowed For Non-PO”

• Send the rejection notification/status back to the source channel

• Terminate the workflow for the rejected document

Audit and Reporting

The system shall maintain a log of all automatically rejected Non-PO invoices, including:

• Rejection reason

• Timestamp

Proposed Technology to Use

A custom Function Module will be developed to implement the required validation logic. This Function Module will be integrated into the system through a custom business rule named "Vendor Not Allowed for Non-PO" to ensure consistent and automated enforcement of the defined controls.

Data Source Considerations

Vendor Master Record will be referred to validate vendors allowed for Non-PO or not.

Data Validation Considerations

Vendor Master Record will be referred to validate vendors allowed for Non-PO or not.

Custom Tables

N/A

Master Data

N/A

Configuration Table

N/A

Selection Screen Enhancement

N/A

Processing Logic

A custom Function Module will be developed to validate all incoming vendor invoices that are not linked to a Purchase Order (Non-PO invoices). This functionality ensures compliance with the company’s “No PO, No Pay” policy by confirming that only vendors authorized for Non-PO processing can submit such invoices. When an invoice is identified as a Non-PO document, it will be checked against the Vendor Master Data to determine whether the vendor is permitted to submit Non-PO invoices. If the vendor is not authorized, the system will automatically reject the invoice unless it meets specific exception criteria. Exceptions include invoices originating from the OCR or EDICOM channels or cases where the document is a credit memo; these invoices will instead be routed for manual review. For all other unauthorized Non-PO invoices, the system will automatically reject with comments “Rejected – Vendor Not Allowed for Non-PO,” and send the rejection status to the source channel using RTV logic, and terminate the workflow.

Volumetrics

The logic is designed to execute on a per-invoice basis and is not expected to affect system performance

Performance Considerations

Failed workflow tasks, email retries, or RTV failures can increase system load if many retries occur simultaneously.

Error Handling

Ensure the Email notification fails and Supplier Portal/SAP Business Network update fails are handled. System should retry 3 times and update the status as Communication Pending and notify the actor to take actions. Application logs should help to update document history with relevant details.

Testing

How to Test

To test, send a few invoices without a purchase order via any VIM channel (Email, IDoc, Supplier Portal, SAP Business Network, via EDIWIN). The custom function should:

• Mark invoice as “Vendor not allowed for Non-PO” if they are unauthorized.

• Allow processing for authorized Non-PO vendors.

• Auto-trigger RTV and show the correct rejection message for auto-reject cases.

• Send other flagged invoices for manual review without auto-rejecting them.

Test Conditions and Expected Results

Test Considerations/Dependencies

N/A

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.

See also

Change log