Mass Processing: Operations 

Use

Defining and executing operations is a central part of mass processing.

Prerequisites

You are defining a mass processing job in transaction WTYMP_A and want to choose an operation (see: Defining and Executing Mass Processing Jobs).

Features

Possible Operations

·        Change Field Values (Substitution)

¡        Only the fields from the header, version and item of the warranty claim are available, for which substitutions are also allowed in the VSR checks.

¡        The fields that you choose here are displayed later in the selection screen when you execute the job. The end user can enter new field values there.

¡        It makes sense to define fields that you choose here as required/obligatory. The user must then make entries in these fields and cannot leave them empty. Empty fields would have no meaning for a substitution. This is certainly not desired in the majority of cases.

·        Execute Action

¡        You can choose all the actions that have been defined in Customizing for Warranty Claim Processing. You can choose exactly one action per operation.

¡        You have to choose an action that requires no reaction on behalf of the user, that is contained in action control and that is allowed for the processing status that the claim has when the job is executed. If this is not the case, the claim is ignored when the job is executed.

·        Pricing Item, Pricing Header

¡        The condition types that you choose here are displayed later in the selection screen when you execute the job. The end user can enter new values, that is amounts, there.

¡        As soon as you choose one of the two operations for pricing, the field Condition Currency automatically appears when you execute the mass processing job. If the user makes no entry in this field, the currency of the version that has just been processed is used. Otherwise the currency that has been entered here as condition currency is taken for all the condition values that are added or changed by the job.

¡        Here it also makes sense to define fields that you choose as required/obligatory (as when changing the field values).

¡        You can choose all the condition types that have been defined in Customizing for Warranty Claim Processing. If the condition type is not contained in the pricing procedure for the claim, the claim is ignored when the job is executed.

¡        You can also choose standard condition types, i.e.: the condition types that have been defined in Customizing for Warranty Claim Processing under General Settings. If the given standard condition type has not been defined in Customizing or is not contained in the pricing procedure for the claim, the claim is ignored when the job is executed.

·        Check Message Log, Check VSR Check Log

All the existing messages from the message log or VSR check log are checked. On the basis of these checks you can decide whether the job processing or claim processing should be continued.

·        Call Customer Exit

Prerequisites and Checks

·        You can enter prerequisites and checks for all operations for changing values (change field values, execute action, pricing). As prerequisite, define that a claim should only be processed if specific field values or specific messages exist in the message log or in the VSR check log. As check, define that a claim should be skipped or the job cancelled if specific messages occur in the message log or on the VSR check log after the operation has been executed.

Prerequisite: claims that contain items of item type EXP (exploding list); operation: info. text on version level should read: contains exploding list. Execution: the system searches for all the claims that contain at least one exploding list on item level and copies the new info. text on version level for the affected versions of these claims.

Prerequisite: claims that contain a version from claimant; operation: info. text on item level should read: item in version to claimant. Execution: the system searches for all the claims that contain at least one version to claimant and copies the new info. text on item level for the affected items of these claims.

·        You can make several entries one below the other when you define prerequisites for the message log or for the VSR check log. The OR logic then applies, i.e. as soon as the system finds one of the given messages, the prerequisite is regarded as fulfilled.

If you do not make any entries in the fields Work Area, Message Type and Message, this means that all entries are possible.

·        After having executed the operation, you can make several entries one below the other when you define checks for the message log or for the VSR check log.

Only the field Decision is a required field. Possible entries in this field are 1 (skip claim) and 2 (cancel job). If there is at least one entry of 2 for more then one entry, the job is cancelled. If there is no entry with decision 2, but more than one entry with decision 1, then the last entry in the list is logged with decision 1.

If you do not make any entries in the fields Work Area, Message Type and Message, this means that all entries are possible.

In the standard check that you can activate in the global job parameters, there are only the entries for message type (value E) and decision (value 1). This means that the claim should generally be skipped when error messages occur.

·        If you include prerequisites or checks for the VSR check log, only the VSR check logs for this versions that fulfill the prerequisites set by the field values. All the existing VSR messages on version, defect code and item level are then evaluated for these versions.