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 Not Allowed for Non-PO will be automatically rejected, except for credit memos or invoices originating from the OCR 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

Dependencies

Security, Integrity and Controls

Configuration Requirements

Language Requirements

Special Requirements

Design Rationale

Functional Requirements

Proposed Technology to Use

Data Source Considerations

Data Validation Considerations

Custom Tables

Master Data

Configuration Table

Selection Screen Enhancement

Processing Logic

Volumetrics

Performance Considerations

Error Handling

Testing

How to Test

Test Conditions and Expected Results

Test Considerations/Dependencies

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