Validation Check
This function provides two categories of check:
· Basic standard checks: a set of very basic business checks essential for data consistency, for example, an inbound delivery must exist before you can post the goods receipt.
· Customer-defined checks: you can implement these checks to enforce rules implemented in their business process, for example, the net weight of a material should be less than its gross weight.
The checks are carried out in two stages:
· Pre-validation: the system performs a bare minimum of checks, for example, the external delivery number should be unique when a new inbound delivery is created. Failure at this stage results in the rejection of the document.
· Validation: semantic checks to ensure that the contents of the document are in accordance with business requirements. If the check fails or returns unsuccessful results at this stage, the system can save the inbound delivery on hold or reject it, depending on the settings that have been made for the validation profiles in Customizing for Service Parts Management (SPM) under Extended Inbound Delivery Processing (SPM) -> Configure Inbound Validations. The semantic checks are defined in the validation routines.
The checks are defined in two ways:
· Required fields: these checks dictate that particular data should be present when the inbound delivery is processed. They are implemented as required field sets. However, the validity of this data is not checked at this stage.
· Semantic checks: these checks analyze the validity of the data provided with respect to the business context in which they are called. They are implemented as validation routines.
A check (either in the form of a required fields check or a semantic check) can be assigned to either the pre-validation or the validation stage to configure system behavior.
Once defined, these checks can be assigned to a combination of inbound action (for example: new ASN, GR) and the system from which these actions come (for example: EWM, vendor). A set of bare minimum checks is delivered to avoid corruption of data. Details of the inbound actions supported and the list of checks which are performed for every inbound action from a particular system are provided in the table below. If any one of these checks fails for a particular scenario, then the action is rejected.
|
Inbound Action/System Type |
Description |
EWM |
ICH |
ERP |
Vendor |
|
NASN |
New ASN |
P-NASN-1 |
P-NASN-2 |
|
P-NASN-4 |
|
RASN |
Replace ASN |
P-RASN-1 |
P-RASN-2 |
|
P-RASN-4 |
|
RHDR |
Replace header |
P-RHDR-1 |
|
|
|
|
REJR |
Rejection for replacement |
P-RREJ-1 |
|
|
|
|
QDIF |
Quantity difference posting |
P-QDIF-1 |
|
|
|
|
ACKR |
Acknowledgement for replacement |
P-AREP-1 |
|
|
|
|
ROD |
Received on dock (partial goods receipt) posting |
P-PAGR-1 |
|
|
|
|
NTPDS |
New TPOP ASN |
|
P-NTPDS-2 |
|
P-NTPDS-4 |
|
RTPDS |
Replace TPOP ASN |
|
P-RTPDS-2 |
|
P-RTPDS-4 |
|
DASN |
Delete ASN |
P-DASN-1 |
P-DASN-2 |
|
P-DASN-4 |
|
SPLIT |
Split inbound delivery |
P-SPLI-1 |
|
|
|
|
CANCEL |
Cancel the whole material document |
P-FCAN-1 |
|
|
|
|
FULLGR |
Full goods receipt |
P-FLGR-1 |
|
|
|
|
ACKD |
Acknowledge deletion |
P-ADEL-1 |
|
|
|
|
REJD |
Rejection deletion |
P-DREJ-1 |
|
|
|
|
DTPDS |
Delete TPOP ASN |
|
P-DTPDS-2 |
|
P-DTPDS-4 |
|
PASN |
Purge ASN |
|
|
|
|
You can view the details of the profiles mentioned here in Customizing for Service Parts Management by choosing Extended Inbound Delivery Processing (SPM) ® Configure Inbound Validations ® Maintain Validation Profiles.