Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Before reading this document please go through document Enhancements in SAP Project Systems Assembly Processing

Introduction


     The standard assembly processing supports basically two different integration scenarios between SD and PS. The first generates one project substructure for each sales document item and is processed when flag “SD/PS assignmt” (field PROJS-FLGSD) is set in the standard project definition. The second generates only one project structure for the entire sales document and is processed when flag “SD/PS assignmt” is not set in the standard project definition. One integration scenario that the standard system does not support is to have more than one sales document assigned to the same project definition, as illustrated in figure below:

Analysis of the standard behavior of the system


     Both of the aforementioned standard scenarios are performed inside function group CJIW and a key variable for them is the REPLACE_STRING variable, which is global in function group CJWI. This variable is set equal to the sales document number inside form TABLES_STANDARDPSP_INIT, called inside function module CJWI_PROJECT_NETWORK_ATTACH, and then used inside function module CJWB_PROJECT_COPY, when it is moved to field VORBELEGEN of structure RCWKP. This field is then used in form EXTERN_CALL_PSPID_GENERATE to perform a kind of search and replace in order to construct the project definition key. The constructed project definition key is then passed into function module CJWI_PSP_EXIST_EXTERN_CHECK in order to decide whether the project definition already exists or not. If the project definition does not yet exist the system continues in function module CJWB_PROJECT_COPY in order to create a new project definition and its respective structure (based on the standard structure). If on the other hand the project definition already exists then the system raises exception EXISTING_PROJECT, leaves function module CJWB_PROJECT_COPY and forwards the work of adding a new sub-tree to the already existing operative project definition to function module CJWB_ELEMENTS_COPY.



Enhancement possibility

     As the decision whether a new project definition should be created or not depends largely on global variable REPLACE_STRING if two different sales document lead to the same REPLACE_STRING value then the system would find the same project definition for both documents.

     The underlying principle of this enhancement is to create an implicit enhancement implementation at the end of form TABLES_STANDARDPSP_INIT (called inside function module CJWI_PROJECT_NETWORK_ATTACH) and change the value of variable REPLACE_STRING to a value coming from a customer field at sales document header level (table VBAK). All sales documents that should be grouped into the same project definition would then have a common value filled in this customer field. An example of code would be as follows:


* assumption: there is an append in structure VBAK containing a field called ZZALTVBELN. This field is maintainable in the sales document processing transaction (i.e. VA21, VA01, etc).



FIELD-SYMBOLS: <ls_vbak>     TYPE any.
FIELD-SYMBOLS: <ls_zzaltvbeln> TYPE any.
ASSIGN ('(SAPMV45A)VBAK') TO <ls_vbak>.
IF <ls_vbak> IS ASSIGNED.
     ASSIGN COMPONENT 'ZZALTVBELN' OF STRUCTURE <ls_vbak> TO <ls_zzaltvbeln>.
     IF <ls_zzaltvbeln> IS ASSIGNED.
          IF NOT <ls_zzaltvbeln> IS INITIAL.
                replace_string = <ls_zzaltvbeln>.
          ENDIF.
     ENDIF.
ENDIF.



Possible application

     Maybe the most prominent application of such an enhancement is in inter-company projects scenarios in which different companies from the same group work on the same project, but due to legal reasons manage their own contracts with their own sales documents. The reason why different contracts from different companies within a group should be managed below the same project definition could vary from simple reporting requirements to more complex requirements in the areas of result analysis and period end closing.



Important final notes

     It is important to highlight that the enhancement proposed in this document only works in case only one project structure is to be created for all sales documents involved (i.e. flag “SD/PS assignmt” - field PROJS-FLGSD - is NOT set in the standard project definition). For creating cross-sales documents projects with multiple substructures another enhancement is required. This enhancement will be posted in the upcoming weeks.

Labels in this area