Ansicht
Dokumentation

Changes to SAP Business Workflow (Enterprise Buyer 4.0) ( RELNEBP_40_WORKFLOW )

rdisp/max_wprun_time - Maximum work process run time ROGBILLS - Synchronize billing plans
This documentation is copyright by SAP AG.

Short text

Changes to SAP Business Workflow (Enterprise Buyer 4.0)

Use

The following changes to SAP Business Workflow are realized in Enterprise Buyer (EBP) 4.0 / Supplier Relationship Management (SRM)3.0:

WS14000030 - One-Step Approval During Creation of Vendor

WS14000043 - Workflow Without Approval During Creation of Vendor

WS14000044 - Completion of Shopping Cart by Purchaser

WS14000045 - Deletion of Items after Application Error

WS14000075 - Workflow Without Approval for Purchase Order

WS14000086 - Workflow Without Approval for Contract

WS14000088 - One-Step Approval of Contract

WS14000089 - One-Step Approval of Purchase Order

WS14000091 - Alert Workflow for an External Auction

WS14000109 - N-Step Shopping Cart Approval over Value Limit

WS14000133 - N-Step Shopping Cart Approval (BAdI)

WS14000148 - N-Step Contract Approval (BAdI)

WS14000032 - Subworkflow to Send Mail During Creation of Vendor

WS14000076 - Wait for BUS2202 Events (Purchase Order) During Approval

WS14000077 - Update Purchase Order After Approval/Rejection

WS14000080 - Subworkflow to Send Mail During Approval of a Purchase Order

WS14000083 - Subworkflow to Send Mail During Approval of a Contract

WS14000084 - Update Contract After Approval/Rejection

WS14000085 - Wait for BUS2000113 Events (Contract) During Approval

WS14000108 - Subworkflow for N-Step Approval of Shopping Cart Over Value Limit

WS14000134 - Subworkflow N-Step Approval of Shopping Cart (BAdI)

WS14000147 - Subworkflow N-Step Approval of Contract (BAdI)

WFL to Create/Change Contract (CTR) and Purchase Order (PO)

Changes, such as addition or deletion of items can be carried out on released CTRs (status released) and ordered POs (status ordered).
(See Release Note: Purchasing Document Versions)

These changes are saved in change versions of original documents. They are subject to a 0-step approval process, before the changes that they contain are transferred to the active document during approval.

The change workflow starts when the change version is ordered (event ChangeVersionSaved business object BUS2000113[CRT] or BUS2201[PO]). When the change version is changed again, this is taken from the approval process.
The approver can compare the change version and original version for each work item.
It is only possible to completely approve/reject the changes. It is not possible to do this on item basis. It is not possible to carry out changes to the change version.

During Approval of the change version, the system checks whether all changes can be transferred into the active document without causing inconsistencies in follow-on documents. (For example, the confirmed quantity in a PO could be greater than the quantity in the approval). If an error occurs, the approver does not see an error message. The approver is only able to reject the changes.

If the approver rejects the changes, the change version status changes to held and can then be changed again or rejected.

Depending on the IMG setting Define Recipient of Notification the last processor of the change version and/or all approvers is/are informed about the approval/rejection of the changes.

Note:

The workflow template for the change workflows of CTR and PO are identical to those for the creation workflows [WS14000086(WFL Without Approval for CTR), WS14000088(One-Step Approval of CTR), WS14000075(WFL Without Approval for PO), WS14000089(One-Step Approval of PO)]. Only the start conditions vary: Events Saved(Saving of Original Version) or ChangeVersionSaved (Saving of Change Version). The start conditions for the change workflow evaluate specific attributes, that are only used in case of changes (for example difference of current total value to original and list of changed fields).
(The system uses the documentGUID from the work item to a change version.

See also Release Note: Approval of Changes to Active Purchasing Documents.

Offline Approval for Confirmation and Invoice

As well as offline approval for shopping carts (see Release Note Offline Approval (EBP 3.0A)) these functions are available from Enterprise Buyer 4.0 for documents awaiting approval of type confirmation and invoice.
The functional scope corresponds to that of the (already integrated) offline approval for shopping carts (report RSWUWFMLEC). The buttons Approve and Reject are added to the e-mail as an enhancement only when the document has been successfully checked and has been completed. (Where a document is still incomplete, the approver is only able to use a link to access the EBP system and approve/reject the documents there.)

Completion Workflow (Purchaser Workflow)

From Enterprise Buyer 4.0 you can use the start conditions to incorporate the scenario for the completion workflow:

If an employee releases an incomplete shopping cart (SC) by ordering it, an appropriate approval workflow is not started immediately. Instead, the attributes of the business object shopping cart (BUS2121) are checked to determine whether the SC needs to be sent to the responsible operational purchaser* for completion. If this is the case, the operational purchaser completes the shopping cart and releases it again. (If not, the shopping cart approval process starts.)
Next, the SC is presented to the requester of the shopping cart. This employee can see the changes made by the operational purchaser (deleted, replaced, changed items) - and can process the shopping cart further if necessary. Only when the shopping cart is completed and has been ordered does the shopping cart approval process start. (If the shopping cart is incomplete, it is again sent to the purchaser.)
The new attributes (that are evaluated in the start conditions) are:

ExistFreeTextLineItem - Does an item exist from a free entry
(Does the SC contain an item with free text entry. Is there an item without product assigned?)

ExistNoPriceLineItem - Does an item exist without a price
(Was it not possible to get a price for an item?)

ExistNoVendorLineItem - Does an item exist without a vendor
(Was it not possible to get a vendor for an item?)

If this workflow is to be used, the workflow templateWS14000044 has to be activated. The attributes can be implemented in the default settings or in the start conditions as check criteria.

* All operational purchasers of the associated purchasing group of the SC receive a work item. After the first purchaser has released the SC, the work items are deleted from the (approval) inboxes of the other purchasers in this purchasing group.

Open Partner Interface (OPI) Workflow

Business partner data is transferred from external sources for each OPI. (See also: Release Note Open Partner Interface)

If a business partner (vendor) is generated via OPI, the event BusinessPartnerBBP.Create is triggered for the Business Object BUS1006200 (business partner BBP). An approval workflow is started.
Depending on transaction authorization (business partner maintenance [BBPMAININT]) of the responsible purchaser, either a one-step (WS14000030) workflow or a workflow without approval (WS14000043) is started.

Note:
These approval workflows are not triggered by start conditions!
WS14000030 is triggered by the event ToBeReleased - The creator does not have sufficient authorizations to complete the vendor.
WS14000043 is triggered by the event Completed (business partner completed) - The creator is authorized to create the business partner completely.

No-Step Approval Workflow

The approval status of the vendor is set to released.

A notification workflow (approval of vendor) is used to inform the appropriate recipient of the approval. The recipient (user roles include Initiator, Approver, Purchaser of Purchasing Organization) is defined in the IMG activity Define Recipients of Notifications.

One-Step Approval Workflow

The manager of the affected purchasing organization is determined as standard approver using the organizational plan.

The approver receives a work item with link to business partner maintenance of the vendor to be approved.

If the vendor is rejected, he/she receives the status Rejected, is deleted as business partner, and a notification workflow (rejection of vendor) is used to inform the appropriate recipient. Initiator, Approver, Purchaser of Purchasing Organization) is defined (Scenario: Approve Vendor).

If the vendor is approved, he/she receives the status released and a notification workflow (approval of vendor) is used to inform the recipient (user roles include Initiator, Approver, Purchaser of Purchasing Organization) defined in the IMG activity Define Recipients of Notifications (Scenario: Approve Vendor).

Admin. Workflow for Collective Invoice

From Enterprise Buyer 4.0, collective invoices - invoices with reference to several purchase orders - can be created. (See Release Note collective invoices).

During the approval of such a collective invoice, checks run to determine whether the individual items originate from different requesters.
If yes, the administrator is determined as approver. *
If all items were created by one requester, the standard approval process applies, dependent on the Customizing settings (in the case of one-step approval, the requester is also the approver).

*,,Approver determination occurs either via the BAdI
,,BBP_WFL_ADMIN_APPROV (Determine Approver (Administrator))
,,or via standard task TS10407925.

Purchasing Budget Workflow

This workflow-controlled scenario is used if the approval of shopping carts (SC) does not depend on the value of individual shopping carts to be ordered. Rather, the scenario is used when a purchasing budget available to a user in Enterprise Buyer is exceeded.

Note:
This budget is defined in the Enterprise Buyer system and does not relate to budgets in FI-CO!

During each purchase, the purchasing budget is compared with the total value of all purchases (AmountSpent) to date in the current period. (All SC values of a user are updated in summated fashion in the field AmountSpent of the database table BBP_USRBDGT).

The purchasing budget

Can be defined for each user

Is valid for a certain period (monath, quarter, year) and

Is renewed periodically (at the end of a period, the budget debit entries are reset. In other words, the value for AmountSpent at the time of the first purchase in the new period is set to initial).

The purchasing budget can be stored in several objects in the system and prioritized in descending order by the system:

User
In user maintenance (transaction SU01), the amount available to an employee is stored on the tab Personalization in the personalization object BBP_USER_BUDGET.
This entry has the highest priority.
Role
In role maintenance (transaction PFCG) as in user maintenance, the purchasing budget can also stored with subsequent priority.
Organizational Management
(Transaction PPOMA_BBP)
At this point, the purchasing budget can be assigned to a structure. (Data is inherited to the subordinate structure nodes.)
This entry has the same priority as the one in role maintenance.

If budgets are defined for roleand organizational unit and if an employee is assigned to both, the higher always overrides the lower. (Both are ignored if the user has a budget assigned.)

Process Flow

When a SC is saved, the user-defined purchasing budget is checked.

If the amount of AmountSpent is larger than the value of the purchasing budget, the system displays a dialog box that states the amount by which the budget was exceeded and warns you of the subsequent approval process.
The user can confirm this message with (OK). AmountSpent is updated and a one-step approval workflow is started.
If the user rejects this message with (Cancel), the user can then continue processing the current SC and is able to reduce the shopping cart value.

If the amount of AmountSpent is smaller than the value of the purchasing budget, the system starts a workflow without approval and the SC receives the status approved.

Update of AmountSpent

The value of the database field AmountSpent is updated if the:

SC is ordered

Employee changes or deletes data

Manager rejects the SC or individual items in the SC

Individual Method to Determine SC Value

The BAdI BBP_SC_VALUE_GET provides you with a method to determine the SC value for update of AmountSpent.
See: BAdI documentation Determine Shopping Cart Value for Purchasing Budget

Workflow Settings for Stochastic Document Check

The stochastic document check for invoice (IV) and confirmation (CF) in Enterprise Buyer 4.0 allows for a great deal of flexibility as regards the use of different workflows, depending on the type of the document to be checked, the subtype, and the document gross value.

The entries in the Customizing Table of the IMG activity Define Stochastic Check of Documents override the settings defined in the workflow start conditions. (You can find more information in the documentation for the IMG activity Supplier Relationship Management → SRM Server → Cross-Application Basic Settings → SAP Business Workflow → Define Stochastic Check of Documents.)
For each specific case, these entries determine a stochastic probability used to replace the workflow determined in the start conditions with an alternative.

These results can in turn be overridden by those determined using the BAdI BBP_STOCH_CUST_BADI. (See the BAdI documentation Workflow Control for Stochastic Document Check.)

Alert Workflow for External Bid Invitations (SAP Bidding Engine)

The initiator of a bid invitation can use the SAP Bidding Engine to forward the bid invitation to external auction tools where it can be processed further as an auction.
This alert workflow is started when the item is sent. It waits for a reply from the external auction tool and informs the last processor on Bidding Engine side (generally the initiator) concerning the result of the bid invitation.

The workflow (WS14000091) starts when the event BidInvitationEC.ExternalAuctionStarted (external auction started) is triggered for Business Object type BUS2200 (bid invitation EC).

Three events are used to notify the initiator:

Auction deadline expired -TS14007971(external auction expired)
The initiator is informed via e-mail (in Enterprise Buyer Inbox) that the auction has expired unsuccessfully.
(BOR event: BidInvitationEC.ExternalAuctionCompleted)
End result of auction received -TS14007973(external auction successful)
The initiator is informed via e-mail that the auction has ended successfully.
(BOR event: BidInvitationEC.ExternalAuctionCompleted)
Error message from external auction tool -TS14007972(external auction: error)
The initiator is informed via e-mail that the auction has ended with errors. The system outputs an error message.
(BOR event: BidInvitationEC.ExternalAuctionError)

Effects on Existing Data

Effects on Data Transfer

Effects on System Administration

Effects on Customizing

BBP_SC_VALUE_GET (Determination of Shopping Cart Value for Purchasing Budget Workflow)

BBP_WFL_APPROV_BADI (Determination of Approver for n-Step Dynamic Approval Workflow)

BBP_STOCH_CUST_BADI (Workflow Control for Stochastic Document Check)

Further Information

RFUMSV00 - Advance Return for Tax on Sales/Purchases SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up
This documentation is copyright by SAP AG.

Length: 23683 Date: 20240521 Time: 000919 sap01-206 ( 221 ms )

Ansicht Dokumentation