SAP SRM SCENARIOS
1. Shopping cart is created in SRM. Cost objects, (e.g. GLAs and WBS
elements), are validated against the R/3 system.
2. Shopping cart goes through shopping cart workflow / approval within SRM
3. Once approved, the shopping cart is transferred to the R/3 system and becomes a purchase requisition or purchase order based on business rules. (The PR/PO decision is driven off an object on the shopping cart such as the Product Category (i.e. Material Group / Commodity Code). For example, Catalog items could become PRs automatically, and Non-Catalog items could become POs requiring a buyer to create the PO in R/3).
4. Any subsequent changes to the PO would need to be made directly in the R/3 system and therefore would bypass the approval process (could not go through a re-approval in SRM).
5. Goods Receipts can be performed in SRM or in the R/3 system.
6. Invoice Receipts can be performed in SRM or in the R/3 system.
2. Shopping cart goes through shopping cart workflow / approval within SRM
3. Once approved, the shopping cart is transferred to the R/3 system and becomes a purchase requisition or purchase order based on business rules. (The PR/PO decision is driven off an object on the shopping cart such as the Product Category (i.e. Material Group / Commodity Code). For example, Catalog items could become PRs automatically, and Non-Catalog items could become POs requiring a buyer to create the PO in R/3).
4. Any subsequent changes to the PO would need to be made directly in the R/3 system and therefore would bypass the approval process (could not go through a re-approval in SRM).
5. Goods Receipts can be performed in SRM or in the R/3 system.
6. Invoice Receipts can be performed in SRM or in the R/3 system.
Advantages:
Cleanest from an implementation, data standpoint
Smaller change management impact:
Besides the requestor (shopping cart) role, all R/3 MM purchasing
activities will remain "As Is".
Less reporting changes:
PO data will only exist in one system.
Disadvantages:
" Does not support the PO approval process, however a customized
solution could be implemented to conduct PO approvals on the R3 side.
1. Shopping cart is created in SRM.
2. Shopping cart goes through SC approval workflow approval within SRM.
3. After approval:
" If shopping cart is incomplete, (e.g. it does not have a vendor), it creates the 'sourcing cockpit' within SRM where buyer performs vendor selection.
" If shopping cart is complete (e.g: catalog items), it creates a complete PO within SRM.
2. Shopping cart goes through SC approval workflow approval within SRM.
3. After approval:
" If shopping cart is incomplete, (e.g. it does not have a vendor), it creates the 'sourcing cockpit' within SRM where buyer performs vendor selection.
" If shopping cart is complete (e.g: catalog items), it creates a complete PO within SRM.
4. Shopping cart goes thru P.O. approval process.
5. Once a PO is created in SRM a PO image is created in the R/3 system. This is a 'read-only' copy of the PO and supplies the reference needed for the creation of goods receipts and invoices in the R/3 system.
6. Any subsequent changes to the PO in SRM will reflect in the R/3 PO.
7. Goods Receipts can be performed in SRM or in the R/3 system.
8. Invoice Receipts can be performed in SRM or in the R/3 system.
5. Once a PO is created in SRM a PO image is created in the R/3 system. This is a 'read-only' copy of the PO and supplies the reference needed for the creation of goods receipts and invoices in the R/3 system.
6. Any subsequent changes to the PO in SRM will reflect in the R/3 PO.
7. Goods Receipts can be performed in SRM or in the R/3 system.
8. Invoice Receipts can be performed in SRM or in the R/3 system.
Key Advantages:
" To take full advantage of the SRM sourcing, order approval and
purchase order output capabilities, while being able to process invoices and
payments in R/3
" Some clients save on SAP license costs through keeping all users,
buyers and approvers strictly within the SRM environment but this is not the case
for Visteon
" The ability to trigger standard workflow for changes to purchase
orders is a highly desired feature for many companies
" The ability to trigger standard workflow for changes to purchase
orders is a highly desired feature for many companies
" PO approval process is supported without any custom development.
" All purchasing functionality will be contained within one system.
Disadvantages:
" Unable to tap into SAP inventory from EBP
" Not all purchase order fields transfer to the backend R/3 system,
though we can add key fields using CUF functionality.
" PO output will most likely have to be maintained both in EBP and
SAP R/3
" Not all standard purchasing data will be available from the R/3
system to feed into the Business Warehouse reporting system.
" EDI is not as readily available in the EBP system as it is in the
traditional R/3 system.
No comments:
Post a Comment