zoukankan      html  css  js  c++  java
  • Plan Driven Procurement III: Classic Scenario in SRM 5.0

    Business Flow:

    1. Created requisition in ECC
    2. Ran program RM06BZ10 - After running this program, system assigned EPROFILE to requisitions without source and requisitons appear in EPRTRANS table
    3. Ran BBP_EXTREQ_TRANSFER in ECC to transfer the requisitions (without source) to SRM.
    4. System does not transfer the requisition and error "Object ID not found" is seen in transaction SMQ1.

    When we created local purchase organization and purchaseing group in SRM, system transferred the requisition from ECC to SRM without any error message. It means the above flow works in extended-classic. We do not want to create local purchse organization / purchasing group as we are using classic scenario.

    Note: 505030

    15. The integration of external requirements does not support a classic scenario for SRM 2.0. As of SRM 3.0, this is possible with the following restrictions:

        o  You cannot procure direct materials using the classic scenario.
        o  When you procure services, you cannot use the classic scenario to process limits without an expected value.

        o  When you procure services using the classic scenario, the service packages transferred to SRM are not grouped together in SRM.

    Reply from IMS:

    The order of direct material results in creation of local purchase order which is then replicated to the backend. Creation of a PO directly in backend with a direct material is not possible. Even using BADI BBP_BADI_EXTREQ_OUT or BADI BBP_PGRP_ASSIGN_BADI it will not be possible.

    Standard Steps:

    1) In order to use the Plan-Driven Procurement scenario you should have the following settings:

    1.1 - Settings in the backend system

    -> keep RFC destination for the SRM System in SM59 transaction. On the logon tab, maintain the RFC user assigned to the entry channel organizational unit as the logon user.

    -> keep view V_T160PR using SM30 transaction. Define profiles for all external procurement systems and assign the logical target systems.

    -> keep ciew V_T160EX  using SM30 transaction. Maintain the combinations of the material group and purchasing group and the profile for the external procurement system. From these settings, the system identifies the procurement system for the purchase requisition..
    Settings: -> material group, -> Purchasing group, -> profile (V_T160PR), -> Manual (only if you have a unique source of supply withing ERP0

    Note: user exit BBPK0001 can be used if you want to influence the profile detemination.

    program BBP_EXTREQ_TRANSFER is used for transferring the requirements from ERp to SRM. you can execute this program whenever requires or schedule the program to run periodically.

    1.2 - Settings in the SRM System

    -> define an entry channel in the Organizational Plan for the backend system. In PPOMA_BBP transaction, create a node in the org plan to act as an entry channel.

    -> create an RFC user in SRM and assign it to the Org unit for the entry channel in PPOMA_BBP transaction.

    -> define the local purchasing group responsible for the org unit for the entry channel in PPOMA_BBP transaction.

    -> define attribute DP_PROC_TY and locations for the Purchasing Group in PPOMA_BBP transaction.

    -> define attributes BUK and BSA for the Purchasing Organizational Unit in PPOMA_BBP transaction.

    2) To combine the Plan-Driven Procurement with the Classic scenario you should have the following settings:

    2.1- Important settings that determine the classic scenario

    -> at least one backend system and accounting system is connected to the SRM and defined in the configuration setting Define Backend System (SPRO transaction)

    -> product categories from the backend system are replicated and used in SRM.

    -> the target system for each product category is the backend system in the configuration Define backend systems for product category. Optionally BADI BBP_DETERMINE_LOGSYS can be implemented to determine the backend system based on shopping cart data.

  • 相关阅读:
    springcloud中常用的注解
    MySQL--Profiling和Trace使用
    MySQL Execution Plan--IN查询计划
    MySQL Config--参数system_time_zone和参数time_zone
    MySQL Replication--全局参数gtid_executed和gtid_purged
    MySQL Transaction--事务无法正常回滚导致的异常
    MySQL Execution Plan--数据排序操作
    MySQL Session--批量KILL会话
    MySQL Transaction--MySQL与SQL Server在可重复读事务隔离级别上的差异
    MySQL Transaction--事务相关查询
  • 原文地址:https://www.cnblogs.com/lazymango/p/2001896.html
Copyright © 2011-2022 走看看