Author Archives: jiteshdua

Reserve Fields

Reserve fields in the customer master record

The customer master includes reserve fields that are not assigned to any particular function. You can assign value to these fields and use them. To maintain the fields, select “Environment -> Additional data” on a customer master maintenance screen. The general data and the sales area data contain different fields:

    1. Ten fields were included in table KNA1 (general part of customer master record):
    Five two-digit fields:
    • KATR 1 (Attribute 1)
    • KATR 2 (Attribute 2)
    • KATR 3 (Attribute 3)
    • KATR 4 (Attribute 4)
    • KATR 5 (Attribute 5)
    Five three-digit fields:
    • KATR 6 (Attribute 1)
    • KATR 7 (Attribute 2)
    • KATR 8 (Attribute 3)
    • KATR 9 (Attribute 4)
    • KATR 10 (Atrribute 5)
    Check tables TVKO – TVK9 and the corresponding maintenance views
    V_TVV1 – V_TVK9 exist for the fields.
    2. Five three-digit fields were included in table KNVV (Sales data of the customer master record):
    • KVGR1 (Customer group 1)
    • KVGR2 (Customer group 2)
    • KVGR3 (Customer group 3)
    • KVGR4 (Customer group 4)
    • KVGR5 (Customer group 5)
    Check tables TVV1 – TVV5 and the corresponding maintenance views V_TVV1 – V_TVV5 exist for the fields. The fields were included in tables VBAK, VRRP, LIPS, KUAGVZ. Value is also assigned to them in the tables, which means that they were copied from the master record of the sold-party and used in the sales and distribution transaction.

Note

In the standard system, the views are not included in the user interface. However, it is possible for you to include them in the user interface.

Using reserve fields

To use a reserve field of the customer master according to your requirements, proceed as follows:

    1. Change the short descriptions of the data elements by using the SAP enhancement.
    2. Choose Tools -> ABAB Workbench -> Utilities -> Enhancements -> Project management -> Text enhancements -> Key words -> Change.
    3. Maintain the corresponding entity tables TVKO-TVK9 or TVV1-TVV5.

Example

You want to use the reserve fields of the customer master (general part) to store the liquidity level of your customer to use for statistical analyses. Proceed as follows:

    1. Change data element KATR1:
    • Change the short description “Attribute 1” to “Customer liquidity”.
    • Change the corresponding key words.
    2. Aktivate data element KATR1.
    3. Maintain entity table TVK1, by defining the following values:
    • “01” good liquidity
    • “02” average liquidity
    • “03” poor liquidity
    4. Use the same procedure for the remaining reserve fields KATR2-KATR10.

Reserve fields in the material master

Five three-digit fields were also included in material master MVKE. The entity tables TVM1 – TVM5 and the corresponding maintenance views V_TVM1 -V_TVM5 exist for these fields. The fields were included in the tables VBAP, VRRP, LIPS, MAAPV, where value is assigned to them. However, you cannot yet enter the fields in the material master maintenance. To use the reserve fields, proceed as described above for customer master maintenance.

Reserve fields in the sales order

In the sales order, the additional fields VBAK-KVGR1 – VBAK-KVGR5 were included at header level, to which value is assigned from the fields KNVV-KVGR1 – KNVV-KVGR5.

In the sales order, the additional fields VBAP-KVGR1 – VBAP-KVGR5 were included at item level, to which value is assigned from the fields MVKE-MVGR1 – MVKE-MVGR5.

To reach the additional fields in the sales document, select Header -> Additional data or Item -> Additional data.

New Fields For Material Determination

  • The following communication structures are relevant for material determination
    • KOMKD (Material determination – communication header)
    • KOMPD (Material determination – communication item)
    • KOMGD (Material determination – allowed fields)
    • For technical reasons, the communication structure KOMGD is used, which combines KOMKD and KOMPD, and which contains all fields that can generally be used for material determination. When entering new fields in KOMKD or KOMPD, the fields are also automatically included in KOMGD.

New fields for material determination are included in the following INCLUDES:

    • Header data: KOMKDZ (INCLUDE in KOMKD, KOMGD)
    • Item data: KOMPDZ (INCLUDE in KOMPD, KOMGD)

The routines for assigning values to the new fields in order processing are in member MV45AFZA. Use the following user exits:

    • USEREXIT_MOVE_FIELD_TO_KOMKD (header fields)
    • USEREXIT_MOVE_FIELD_TO_KOMPD (item fields)

New Fields For Output Control

  • The following communication structures are relevant for output control:
    • KOMKBK1  (Output Determination Communication Area CAS Appl. K1)
    • KOMKBV1  (Output Determination Communication Area Header Appl. V1)
    • KOMKBV2  (Output Determination Communication Area Header Appl. V2)
    • KOMKBV3  (Output Determination Communication Area Header Appl. V3)
    • KOMKBV5  (Communication Structure for Output Control Groups Appl. V5)
    • KOMKBV7  (Output Determination Communication Area Shipment Appl. V7)
    • KOMPBV1  (Output Determination Communication Area Item Appl. V1)
    • KOMPBV2  (Output Determination Communication Area Item Appl. V2)
    • KOMPBV3  (Output Determination Communication Area Item Appl. V3)
    • KOMB     (Field Catalog for Condition Keys: Output Control)
  • New fields for output control are entered in the following INCLUDEs:
    • Sales activities: KOMKBZ1 (in KOMKBK1)
    • Sales document header: KOMKBZ3 (in KOMKBV1)
    • Delivery header: KOMKBZ4 (in KOMKBV2)
    • Groups header: KOMKBZF (in KOMKBV5)
    • Billing document header: KOMKBZ5 (in KOMKBV3)
    • Sales document item: KOMPBZ1 (in KOMPBV1)
    • Delivery item: KOMPBZ3 (in KOMPBV2)
    • Billing document item: KOMKBZ5 (in KOMPBV3)
    • Shipment: KOMKBZH (in KOMKBV7)
    If you also want to use a new field for the setup of condition tables (key field) it must also be included in the structure KOMBZ (contained in KOMB).
  • The routines and user exits for assigning values to the new fields are found in the programs RVCOMFZZ, RVCOMFZ1, RVCOMFZ4, and LVCOMFZ1. It is also possible to copy partners here.
    The following user exits exist in member RVCOMFZ1:
    • USEREXIT_KOMPBV2_FILL (item fields in delivery)
    • USEREXIT_KOMPBV2_PARTNER (item fields for partners in delivery)
    • USEREXIT_KOMPBV3_FILL (item fields in billing document)
    • USEREXIT_KOMPBV3_PARTNER (item fields for partners in billing document)
    The following user exits exist in member RVCOMFZZ:
    • USEREXIT_KOMKBK1_FILL (header fields in sales activities)
    • USEREXIT_KOMKBK1_PARTNER (header fields for partners in sales activ.)
    • USEREXIT_KOMKBV1_FILL (header fields for sales documents)
    • USEREXIT_KOMKBV1_PARTNER (header fields for partners in sales documents)
    • USEREXIT_KOMKBV2_FILL (header fields in delivery)
    • USEREXIT_KOMKBV2_PARTNER (header fields for partners in delivery)
    • USEREXIT_KOMKBV3_FILL (header fields in billing document)
    • USEREXIT_KOMKBV3_PARTNER (header fields for partners in billing doc.)
    The following user exit exists in member RVCOMFZ4:
    • USEREXIT_KOMKBV5_FILL (header field for groups)
    The following user exits exist in member LVCOMFZ1:
    • USEREXIT_KOMPBV7_FILL (Shipment fields for header and stage)
    • USEREXIT_KOMPBV7_PARTNER (Shipment fields for partners)

In output determination, communication table KOMB contains all key fields that can be used for conditions for output determination.

When you create new fields for output determination, you can distinguish between two types of fields:

  • Fields that are used in condition tables
  • Fields that are only used to query conditions.

Both types of field have to be included in KOMKBV1. Fields which are only used to query conditions do not have to be included in KOMB and T681F or in the field catalog.

Note concerning name assignment

There are two possibilities for naming the field:

    • If the field is identical to the field in the communication table (e.g. VBAK), a value is assigned to it automatically by MOVE-CORRESPONDING. If SAP delivers the field in a subsequent system version, no generation errors will be caused.
    • If the field is not identical with the field in the communication table,you have to assign a value to it using the MOVE command. Begin the field name with the letters ZZ. This will avoid generation errors if the field is later delivered by SAP in a subsequent system version.

Example 1: Creating a new key field in output control

If, for example, you want to use the field ERNAM (name of sales employee) from the sales order (table VBAK) for output determination, proceed as follows:

    1. Enter the field ZZERNAM in communication structure KOMKBV1 in INCLUDE KOMKBZ3 in the Data Dictionary.
    By entering the field in KOMKBZ3, you automatically include it in communication table KOMKBV1.
    2. Enter ZZERNAM in the communication table KOMB (in KOMBZ).
    3. Assign values to the fields
    Values are  assigned to the fields in function module KOMKBV1_FILL. You have to enter the field and assign value to it manually in user exit USEREXIT_KOMKBV1_FILL. You will find the statements that you can use as a reference in the user exits.
    Copying partner numbers is a special case and will be explained in Example 3.
    4. Include ZZERNAM in the field catalog for the condition table for sales documents. The field catalogs must contain all the fields which you want to use to structure condition tables.

Example 2: Entering a condition field in the communication block

If you want to use condition field VBAK-AUDAT for output determination, proceed as described in Example 1. Remember that it is not necessary to include the new field in KOMBZ (KOMB) or to maintain table T681F or the field catalog.

Example 3: Entering a partner number in the communication block

Example 3 presupposes that there is a new partner function for buyer ZY in the sales document and that the number of this partner is to be copied.

When entering partner numbers in the communication block, proceed as described in the examples above. Partner function ZY is assigned to partner type AP in this example.

Remember to use a different routine to assign values to the new fields. If, for example, you want to copy the partner function ZY into the new field ZZEINKA, for example, the statement is:

USEREXIT_KOMKBV1_PARTNER

WHEN ‘ZY’.COM_KBV1-ZZEINKA = COM_VBPA-PARNR.

The VBPA field used to assign a value to the new field depends on the partner function determined in the sales order. Each partner function is assigned to a partner type (e.g. partner function LF – partner type LI), which controls the assignment. Other source fields should be used for other partner types: COM_VBPA-KUNNR, COM_VBPA-LIFNR, COM_VBPA-PERNR and COM_VBPA-PARNR.

The following assignments exist:

  • KU => COM_VBPA-KUNNR
  • LI => COM_VBPA-LIFNR
  • PE => COM_VBPA-PERNR
  • AG => COM_VBPA-PARNR

ASAP

1.1 Customized ASAP Methodology

Company ABC follows the ASAP Methodology for SAP Implementation and Rollout programs. However the methodology is customized to leverage the Company ABC Global Delivery Model (GDM) and the requirements of the engagement. For the purpose of this engagement, only the Project Preparation and Business Blueprint stages are in scope. However the complete methodology is presented for a complete overview.

Company ABC has categorized the rollout track-wise as the Business Process Design, Technical Requirements, Data Migration and Training Tracks. The Rollout Track will be governed by the Company ABC Project Management Methodology. The subsequent sections explain the various phases of project as proposed by Company ABC.

ASAP Implementation Methodology for Implementation and Rollouts

The proposed Company ABC approach involves appropriate pieces of the project work being done at our offshore facilities. This approach differentiates Company ABC in that our mature Global Delivery Model (GDM) allows us to do the work where it makes the most sense. Our experience in delivering projects in this manner acknowledges that many ERP implementation project activities require hands-on, face-to-face interaction onsite. There are, however, other tasks which do lend themselves very readily to a combined onsite – offshore delivery model. The Company ABC Global Delivery Model lowers cost, enhances quality and speeds time to completion.

Phase 1: Project Preparation

The objectives of the Program Preparation phase involve aligning the program to the overall organization strategy, drafting overall project plan, resources for various phases, and conducting fit- gap analysis. The participants for this phase would be Company ABC and the client Team, Business Process Owners and super users.

Activities

Deliverables

Accelerators

· Conduct stakeholder interviews

· Identify drivers for rollout

· Understand existing systems landscape

· Discuss and agree on scope and detailed project-plan

· Finalize roles and team structure for project tasks

· Develop roadmap

· Identify Milestones

· Formalized Resource Requirements

· Project Team Roles and Responsibilities

· Project Standards

· Preliminary Training and/or Overviews

· Finalize Project Plan

· Finalize Budget

· Experience from past rollouts projects enables quick problem definition and roadmap preparation tailored to the client’s needs.

· Conduct workshops and interviews with project stakeholders

· Questionnaires for interviews and workshops to help determine scope and key pain points

Table 1. Project Preparation Snapshot

Phase 2: Business Blueprint

The objectives of the Business Blueprint phase are to lock down scope, define functional specifications, define required customizations and prepare data migration plan.

Activities during the Business blueprinting stage

Activities

Deliverables

Accelerators

· Define to-be business processes

· Develop reference template for US and Canada

· Conduct an as-is business process study

· Develop future IT landscape

· Prioritize customizations

· Finalize scope, gather requirements for conversion, customization and reporting

· Prepare Training Material and impart training

· Plan for development and documentation of requirements for data mapping, cleansing, conversion and validation

· Organizational and Master Data Design

· Detailed Process Analysis

· Gap Resolution

· Process and Solution Documentation

· Authorization Design and Approach

· Development Request Documentation

· Test Strategy

· Templates for gap analysis, functional requirements, high-level design and detailed-design documents

· Knowledge of industry best-practices

Table 2. Business Blueprinting Snapshot

Phase 3: Business Realization

The realization phase includes developing functional and technical specifications, work flow, system test plans, baseline and the final configuration. Additional activities also include creation of reports, forms; data cleansing, data migration and integration testing.

Activities during the Business Realization stage

Activities

Deliverables

Accelerators

· Complete custom development

· Final system configuration

· Functional/unit testing

· Conduct data clean-up activities

· Finalize cutover strategy

· Develop test plans and test cases

· Build integration test environment

· Build UAT environment

· Develop security roles

·

· RICE objects, forms and workflows

· Baseline and final configuration

· Converted data

· Unit test plans/scripts

· Cutover strategy and high-level plan

· Integration testing

· Security roles and profiles

· Performance monitoring plan

· Detailed strategy/plan for final prep and UAT

· Company ABC development methodology

· Best practices from Company ABC consultants

· SAP Solution Manager (optional)

· Templates for creating knowledge repository for specific industry.

· Experience in client system and business processes

· CMM Level 5 Quality Processes

Table 3. Business Realization Snapshot

Phase 4: Final Preparation

The final preparation involves validation of the solution design and development, extensive testing across the complete business cycle, user acceptance testing and preparation for Go–live & Support.

Activities during the Final Preparation stage

Activities

Deliverables

Accelerators

· Lead UAT

· Assist UAT activities

· Trial cutover

· Prepare for Go-Live including, security profile setup, helpdesk process

· Complete production data conversion

· Completed UAT; including documented test cases/scenarios

· Organization prepared for cutover

· Final configuration guide and support structure

· Impact analysis for “Go/No-Go” decision, including Go-Live success criteria

· Security roles/profile in production environment

· Production data conversion completed

· SAP, LSMW

· Company ABC consultants best practices

· Templates from Company ABC

· Checklists

· Use of testing tools like CATT for stress/ volume testing

· Test script templates enabling efficient remote execution

· Online Web-based issue tracker with context search

Table 4. Business Realization Snapshot

Phase 5: Go-live & Support

Go live & support involves transporting the customized system to the production environment and monitoring the live system.

Activities during Go-Live stage

Activities

Deliverables

Accelerators

· Execute business and systems cutover

· Activate helpdesk

· Transition to post go-live warranty support

· Finalize project documentation

· Handover to support organization

· Begin continuous improvement process

· Live production system

· Business and systems cutover

· Final configuration guide

· Service model

· Stable production system – acceptance documentation and go-live success checklist

· Production hand-off completed

· Established Procedures to ensure flawless cutover and data migration

· Extended business hours leveraging GDM to provide system support

· Proven handover methodology

Table 5. Go-Live Snapshot

1.2 Company ABC Training Methodology

Training Methodology is an integral part of the ASAP methodology at different phases of the project, namely Blue print, Realization, Final preparation & Go-Live support phases. Company ABC facilitates the Training process for the project but the client is responsible for training the users.

Provided below is the training methodology, that Company ABC follows for all its SAP Implementation/ Rollout engagements. Company ABC proposes a Training spanning across the entire SAP Rollout engagement. However considering the small number of users and already existing template in Dubai, the training activities will be redefined after discussions with Mittal Steel.

Training Project Phases Deliverables

Assess

Plan

Design Program

Audience analysis

Existing materials review

Hardware/software requirements

Identify tools

Identify standards

Work plan

Training strategy

Team onboarding

Curriculum

Templates

Develop Program

Pilot Program

Design Program

Course materials

Exercises

Job aids

Training environment

Training data

Course schedule

Role/course mapping

Course pilots

Facilities/software tests

Train-the-trainer

End-user registration

Course evaluation form

Administer training data base

Deliver courses

Course evaluations

Post Appraise Program

Provide Ongoing Support

Course evaluation summaries

Recommendations for improvement

Maintenance processes

Maintenance of training materials and data bases

Transition to permanent owners

 

Sales Order Changed History Display

You can execute the report by :

1.  Change Date

2.  User Name

3.  Sales Order Number

REPORT ZSDCHANGE LINE-SIZE 132 NO STANDARD PAGE HEADING

                 LINE-COUNT 065(001)

                 MESSAGE-ID VR.

TABLES: DD04T,

        CDHDR,

        CDPOS,

        DD03L,

        DD41V,

        T685T,

        VBPA,

        TPART,

        KONVC,

        VBUK.

DATA: BEGIN OF ICDHDR OCCURS 50.

        INCLUDE STRUCTURE CDHDR.

DATA: END OF ICDHDR.

SELECT-OPTIONS: XUDATE FOR ICDHDR-UDATE,

                XNAME  FOR ICDHDR-USERNAME,

                XVBELN FOR VBUK-VBELN.

SELECTION-SCREEN SKIP.

SELECTION-SCREEN BEGIN OF BLOCK BLK1 WITH FRAME TITLE TEXT-001.

PARAMETERS: SUDATE RADIOBUTTON GROUP R1,

            SNAME  RADIOBUTTON GROUP R1,

            SOBID  RADIOBUTTON GROUP R1.

SELECTION-SCREEN END OF BLOCK BLK1.

DATA: WFLAG,

      WCHANGENR LIKE CDHDR-CHANGENR,

      WUDATE LIKE CDHDR-UDATE,

      WNAME  LIKE CDHDR-USERNAME,

      WVBELN LIKE VBUK-VBELN,

      WDEC1 TYPE P DECIMALS 3,

      WDEC2 TYPE P DECIMALS 3,

      WDEC3 TYPE P DECIMALS 3,

      WDEC4 TYPE P DECIMALS 3.

DATA: UTEXT(16) VALUE 'has been changed',

      ITEXT(16) VALUE 'has been created',

      DTEXT(16) VALUE 'has been deleted'.

DATA: BEGIN OF ICDSHW OCCURS 50.

        INCLUDE STRUCTURE CDSHW.

DATA: END OF ICDSHW.

DATA: BEGIN OF ITAB OCCURS 10.

        INCLUDE STRUCTURE CDSHW.

DATA:   UDATE LIKE CDHDR-UDATE,

        USERNAME LIKE CDHDR-USERNAME,

        CHANGENR LIKE CDHDR-CHANGENR,

        VBELN(10),

        POSNR(6),

        ETENR(4),

        INDTEXT(200),

  END OF ITAB.

SELECT * FROM VBUK WHERE VBELN IN XVBELN.

  CLEAR CDHDR.

  CLEAR CDPOS.

  CDHDR-OBJECTCLAS = 'VERKBELEG'.

  CDHDR-OBJECTID   = VBUK-VBELN.

  PERFORM READHEADER.

  PERFORM READPOS.

  LOOP AT ITAB.

    CASE ITAB-TABNAME.

      WHEN 'VBPA'.

        IF ITAB-FNAME = 'KUNNR' OR

           ITAB-FNAME = 'LIFNR' OR

           ITAB-FNAME = 'PARNR' OR

           ITAB-FNAME = 'PERNR' OR

           ITAB-FNAME IS INITIAL.

         MOVE ITAB-TABKEY TO VBPA.

         SELECT SINGLE * FROM TPART WHERE SPRAS = SY-LANGU

                                   AND   PARVW = VBPA-PARVW.

         IF SY-SUBRC = 0.

           REPLACE '&' WITH TPART-VTEXT INTO ITAB-INDTEXT.

         ENDIF.

       ENDIF.

     WHEN 'VBAP'.

       IF ITAB-FNAME IS INITIAL.

         REPLACE '&' WITH 'Item' INTO ITAB-INDTEXT.

       ENDIF.

     WHEN 'KONVC'.

       MOVE ITAB-TABKEY TO KONVC.

       SELECT SINGLE * FROM T685T WHERE SPRAS = SY-LANGU

                                 AND   KVEWE = 'A'

                                 AND   KAPPL = 'V'

                                 AND   KSCHL = KONVC-KSCHL.

       IF SY-SUBRC = 0.

         REPLACE '&' WITH T685T-VTEXT INTO ITAB-INDTEXT.

       ENDIF.

     ENDCASE.

     IF ITAB-INDTEXT(1) EQ '&'.

       REPLACE '&' WITH ITAB-FTEXT(40) INTO ITAB-INDTEXT.

     ENDIF.

     IF ITAB-CHNGIND = 'I'.

       REPLACE '%' WITH ITEXT INTO ITAB-INDTEXT.

     ELSEIF ITAB-CHNGIND = 'U'.

       REPLACE '%' WITH UTEXT INTO ITAB-INDTEXT.

     ELSE.

       REPLACE '%' WITH DTEXT INTO ITAB-INDTEXT.

     ENDIF.

     CONDENSE ITAB-INDTEXT.

     MODIFY ITAB.

   ENDLOOP.

ENDSELECT.

IF SUDATE = 'X'.

  SORT ITAB BY UDATE VBELN POSNR ETENR.

ELSEIF SOBID = 'X'.

  SORT ITAB BY VBELN POSNR ETENR UDATE.

ELSE.

  SORT ITAB BY USERNAME VBELN POSNR ETENR UDATE.

ENDIF.

LOOP AT ITAB.

  CLEAR WFLAG.

  IF SUDATE = 'X'.

    IF WUDATE NE ITAB-UDATE.

      SKIP.

      WRITE:/001 ITAB-UDATE,

             023 ITAB-USERNAME,

             037(10) ITAB-VBELN.

      WFLAG = 'X'.

      WUDATE = ITAB-UDATE.

      WCHANGENR = ITAB-CHANGENR.

    ENDIF.

  ELSEIF SOBID NE 'X'.

    IF WVBELN NE ITAB-VBELN.

      SKIP.

      WRITE:/001 ITAB-VBELN.

      WVBELN = ITAB-VBELN.

    ENDIF.

  ELSE.

    IF WNAME NE ITAB-USERNAME.

      SKIP.

      WRITE:/001 ITAB-USERNAME.

      WNAME = ITAB-USERNAME.

    ENDIF.

  ENDIF.

  IF WCHANGENR NE ITAB-CHANGENR.

    WRITE:/023 ITAB-USERNAME,

           037(10) ITAB-VBELN.

       WFLAG = 'X'.

       WCHANGENR = ITAB-CHANGENR.

    ENDIF.

    IF WFLAG = 'X'.

      WRITE: 013 ITAB-CHNGIND,

             049 ITAB-POSNR,

             057 ITAB-ETENR,

             065 ITAB-INDTEXT(60).

    ELSE.

      WRITE: /013 ITAB-CHNGIND,

              049 ITAB-POSNR,

              057 ITAB-ETENR,

              065 ITAB-INDTEXT(60).

    ENDIF.

  WRITE:/065 ITAB-F_OLD.

  WRITE:/065 ITAB-F_NEW.

ENDLOOP.

FORM READHEADER.

  CALL FUNCTION 'CHANGEDOCUMENT_READ_HEADERS'

       EXPORTING

            DATE_OF_CHANGE    = CDHDR-UDATE

            OBJECTCLASS       = CDHDR-OBJECTCLAS

            OBJECTID          = CDHDR-OBJECTID

            TIME_OF_CHANGE    = CDHDR-UTIME

            USERNAME          = CDHDR-USERNAME

       TABLES

            I_CDHDR           = ICDHDR

       EXCEPTIONS

            NO_POSITION_FOUND = 1

            OTHERS            = 2.

  CASE SY-SUBRC.

    WHEN '0000'.

    WHEN '0001'.

      MESSAGE S311.

      LEAVE.

    WHEN '0002'.

      MESSAGE S311.

      LEAVE.

  ENDCASE.

ENDFORM.

FORM READPOS.

  LOOP AT ICDHDR.

    CHECK ICDHDR-UDATE

                        IN XUDATE.

    CHECK ICDHDR-USERNAME

                          IN XNAME.

    CALL FUNCTION 'CHANGEDOCUMENT_READ_POSITIONS'

         EXPORTING

              CHANGENUMBER      = ICDHDR-CHANGENR

              TABLEKEY          = CDPOS-TABKEY

              TABLENAME         = CDPOS-TABNAME

         IMPORTING

              HEADER            = CDHDR

         TABLES

              EDITPOS           = ICDSHW

         EXCEPTIONS

              NO_POSITION_FOUND = 1

              OTHERS            = 2.

    CASE SY-SUBRC.

      WHEN '0000'.

        LOOP AT ICDSHW.

          CHECK ICDSHW-CHNGIND NE 'E'.

          CLEAR ITAB.

          MOVE-CORRESPONDING ICDHDR TO ITAB.

          MOVE-CORRESPONDING ICDSHW TO ITAB.

          CASE ITAB-TABNAME.

            WHEN 'KONVC'.

              MOVE ICDHDR-OBJECTID TO ITAB-VBELN.

              MOVE ICDSHW-TABKEY(6) TO ITAB-POSNR.

            WHEN OTHERS.

              MOVE ICDSHW-TABKEY+3(10)  TO ITAB-VBELN.

              MOVE ICDSHW-TABKEY+13(6)  TO ITAB-POSNR.

              MOVE ICDSHW-TABKEY+19(4)  TO ITAB-ETENR.

          ENDCASE.

          MOVE '& %' TO ITAB-INDTEXT.

          APPEND ITAB.

          CLEAR ITAB.

        ENDLOOP.

      WHEN OTHERS.

        MESSAGE S311.

        LEAVE.

    ENDCASE.

  ENDLOOP.

ENDFORM.

TOP-OF-PAGE.

WRITE:/ SY-DATUM,SY-UZEIT,

       50 'SALES ORDER CHANGE HISTORY',

      120 'Page', SY-PAGNO.

WRITE: / SY-REPID,

         60 'SALES ORDERS STATISTICS'.

SKIP.

ULINE.

IF SUDATE = 'X'.

  WRITE:/001 'Change Date',

         013 'Time',

         023 'User Name',

         037 'Sale Order',

         049 'Line',

         057 'Sch No',

         065 'Changes'.

ELSEIF SOBID = 'X'.

  WRITE:/001 'Sale Order',

         013 'Line',

         021 'Sch No',

         029 'Change Date',

         041 'Time',

         051 'User Name',

         065 'Comment'.

ELSE.

  WRITE:/001 'User Name',

         015 'Time',

         025 'Change Date',

         037 'Sale Order',

         049 'Line',

         057 'Sch No',

         065 'Changes'.

ENDIF.

ULINE.

 

Implementing SAP

Implementing a package can be a traumatic affair for both the customer and the vendor. Get it wrong and the vendor may get paid late or have to resort to lawyers to get paid and tarnish their reputation. For the company the new package may not work the way they expected, be late or cost a more than budgeted for and take management will take their eye off running their business.Recently a client asked me what I would consider to be the five most important things one should consider before embarking on an implementation. This isn’t a simple question, although there are many factors to think about after some consideration for me the top five are way ahead of the others.

My top five factors to consider would be:

1. Set up a Project Board,
2. Secure the resources,
3. Complete the GAP Analysis,
4. Have detailed Cut Over Plans,
5. Train the users.

Taking each one in turn:

The Project Board
The correct set up and operation of the Project Board in my view is major factor in the success failure of the project. The Project Board will consist of the stakeholders, key users and the vendor. The Project Board is part of the governance of the project. The Project Board will meet regularly to ensure that the project plans are created and being executed as planned, moves from stage to stage with all the deliverables being signed off is resourced properly.

The Resources
Three types of resources are absolutely necessary — end users, change team and technicians.

Early involvement by the end users is absolutely necessary, as they will be the ones living with the system for hopefully many years to come. They will want to feel involved in its implementation. Buy in from the end users of the system is absolutely essential if the system is to have a long and stable life in any organisation.

The Change Team will identify the gaps between the package and the business requirements, re-engineer some of the businesses process to cope with the package, train the users to ensure implementations is smooth as possible into the business.

The Technical Team will prepare the systems environment for the package, apply any software fixes from the vendor, implement the software in the best way possible for the organisation set up and tune the software for the particular technical environment.

GAP Analysis
A through gap analysis will identify the gaps between how the business operates ad its needs against what the package can can’t do. For each gap there will be one of three outcomes which must be recorded and actioned, GAP must be closed and customised software can be developed close the gap, GAP must be closed but software cannot be written therefore a workaround is required, GAP does not need to be closed.

In simple terms: Gap means small cracks. In SAP world. In information technology, gap analysis is the study of the differences between two different information systems or applications( ex; existing system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as “the space between where we are and where we want to be.” Gap analysis is undertaken as a means of bridging that space.
Actual gap analysis is time consuming and it plays vital role in blue print stage.

Cut Over Plans
Detailed plans need to be developed for cutting over from the old system(s) to the new. Parallel runs of what will happen over the conversion period using test data, convert and watch for a period after wards to ensure nothing unexpected happens.

Train Users
Well trained users will support and defend the system on site. Unsupportive users will continually undermine the system and eventually it will be replaced. Therefore the more effort you put into helping the users master the system early the better.

Explain Cutover Activities/Strategies in SAP FI.

Cutover Activities or Master Data Uploading Strategies Depending upon the when we are going live. As per that, you have to give the information to your core team. If you goling live at the middle you have to upload the all P&L Account items and B/S Items. If you going live at the financial year start, you have to only Upload the B/S Items. Activities for Golive:

1. G/L Master Upload Thru BDC or LSMW (TC-Fs00 and extended one co code to another company code Fs01)
2. Vendor Master Upload Thru BDC Or LSMW (Will be Taken Care By MM)
3. Customer Master Upload Thru BDC or LSMW (Will be Taken Care By SD)
4. Asset Master Upload(Thru As90)
5. Cost Element Master Upload
6. Cost Center Master Upload
7. Profit Center Master Upload
8. G/L Balances Thru F-02
10. Vendor Balances thru F-43
11. Customer Balances thru F-22
12. Customer Advances thru f-29
13. Vendor Advances thryu F-48

Before uploading Vendor Balances you have to take care of WHT(TDS) Information.

Difference between the User Exit & Gap analysis.

Both are quiet a different and has a small relation.

User exits are standard gate ways provided by SAP to exit the standard code and we can write our own code with the help of ABAP workbench. its not new functionality which we are trying to build in sap but its slight enhancement within the same code.

Gap analysis is start point of Realization and once blue print is finished we have to find the realization of sap system for client requirment and there will be certain gaps when compared to system fit. Those gaps can be closed either by re-engineering of business process to fit with SAP or we have to use USER exits in case of small deviations or complete enhancements with the help of ABAP to fit with the SAP system.

What is roll out of SAP Project?

As per dictionary, Rollout means “Inauguration or initial exhibition of a new product”.

As per SAP specific definition, rollout is the strategy for international SAP implementation. Rollout strategy normally include the following
– Whether to implement SAP simultaneously (also known as big-bang) in all the countries, or
– Go live in sequence of phased manner
– Or to go for the combination of both (phased manner implementation for some of the countries and big-bang for others).

Rollout strategy is the most important decision that a client can make during SAP implementation. Normally, steering committee decides the rollout strategy.

SAP Landscape

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.-  DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
–  QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.
–  PROD may have something like a 200 Production.

These names and numbers are the implementer’s discreet on how they want it or they have been using in their previous implementations or how is the client’s business scenario.

Now whatever you do in the Sandbox doesn’t affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don’t run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO  (Display IMG) screen. It’s a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the ‘database’ (if you wanna call it that) or you may rather call it the ‘ultimate’ reference client for all the good, complete and final configuration that is being used in the implementation.

In summary:
Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT —> QUALITY —-> PRODUCTION

DEVELOPMENT : is where the the consultants do the customization as per the company’s requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server: – Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production.

These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have.
Application Server – Where SAP Installed.
Database Server – Where Database installed.

What is the meaning of “R” in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1) Presentation
2) Application
3) Database

What is the Purpose of R/3?

The sole purpose of an R/3 system is to provide a suite of tightly integrated, large-scale business applications.The standard set of applications delivered with each R/3 system are the following:

  • PP (Production Planning)
  • MM (Materials Management)
  • SD (Sales and Distribution)
  • FI (Financial Accounting)
  • CO (Controlling)
  • AM (Fixed Assets Management)
  • PS (Project System)
  • WF (Workflow)
  • IS (Industry Solutions)
  • HR (Human Resources)
  • PM (Plant Maintenance)
  • QM (Quality Management)
  • CRM (Customer Relationship Management)

These applications are called the functional areas, or application areas, or at times the functional modules of R/3. All of these terms are synonymous with each other.Traditionally, businesses assemble a suite of data processing applications by evaluating individual products and buying these separate products from multiple software vendors. Interfaces are then needed between them. For example, the materials management system will need links to the sales and distribution and to the financial systems, and the workflow system will need a feed from the HR system. A significant amount of IS time and money is spent in the implementation and maintenance of these interfaces.

R/3 comes prepackaged with the core business applications needed by most large corporations. These applications coexist in one homogenous environment. They are designed from the ground up to run using a single database and one (very large) set of tables. Current production database sizes range from 12 gigabytes to near 3 terabytes. Around 8,000 database tables are shipped with the standard delivery R/3 product.

An Introduction to SAP

SAP was founded in 1972 in Walldorf, Germany. It stands for Systems, Applications and Products in Data Processing. Over the years, it has grown and evolved to become the world premier provider of client/server business solutions for which it is so well known today. The SAP R/3 enterprise application suite for open client/server systems has established a new standards for providing business information management solutions.SAP product are consider excellent but not perfect.  The main problems with software product is that it can never be perfect.

The main advantage of using SAP as your company ERP system is that SAP have a very high level of integration among its individual applications which guarantee consistency of data throughout the system and the company itself.

In a standard SAP project system, it is divided into three environments, Development, Quality Assurance and Production.

The development system is where most of the implementation work takes place. The quality assurance system is where all the final testing is conducted before moving the transports to the production environment.  The production system is where all the daily business activities occur.  It is also the client that all the end users use to perform their daily job functions.

To all company, the production system should only contains transport that have passed all the tests.

SAP is a table drive customization software.  It allows businesses to make rapid changes in their business requirements with a common set of programs.  User-exits are provided for business to add in additional source code.  Tools such as screen variants are provided to let you set fields attributes whether to hide, display and make them mandatory fields.

This is what makes ERP system and SAP in particular so flexible.  The table driven customization are driving the program functionality instead of those old fashioned hard-coded programs.  Therefore, new and changed business requirements can be quickly implemented and tested in the system.

Many other business application software have seen this table driven customization advantage and are now changing their application software based on this table customizing concept.

In order to minimized your upgrading costs, the standard programs and tables should not be changed as far as possible.  The main purpose of using a standard business application software like SAP is to reduced the amount of time and money spend on developing and testing all the programs.  Therefore, most companies will try to utilized the available tools provided by SAP.

What is Client? What is the difference between Customization and Configuration?

The difference between cutomizing and configuration is:
– CONFIGURATION: we will configure the system to meet the needs of your business by using the existing data.
– CUSTOMIZING: we will customise or adapt the system to your business requirements, which is the process of mapping SAP to your business process.
– CLIENT: A client is a unique one in organizational structure, can have one or more company codes. Each company code is its own legal entity in finance.

Configuration  vs. Customization
When considering enterprise software of any type, it is important to understand the difference between configuration and customization.The crux of the difference is complexity. Configuration uses the inherent flexibility of the enterprise software to add fields, change field names,modify drop-down lists, or add buttons. Configurations are made using powerful built-in tool sets. Customization involves code changes to create functionality that is not available through configuration. Customization can be costly and can complicate future upgrades to the software because the code changes may not easily migrate to the new version.Wherever possible, governments should avoid customization by using configuration to meet their goals.Governments also should understand their vendor’s particular terminology with regard to this issue since words like “modifications” or “extensions” often mean different things to different vendors.        *– Sivaprasad, Sonali Sardesai

What is SAP R3?
We know that SAP R/3 is software, it particular it is client-server software. This means that the groups/layers
that make up a R/3 System are designed to run simultaneously across several separate computer systems.

When you install Microsoft Excel on your PC, each component of Excel (printing components, graphing components, word processing components, and etc.) is stored, managed, and processed via the hardware of your PC.   When a company installs SAP’s software each component (or “layer” in R/3’s case) is stored, managed, and processed via the hardware of separate and specialized computer systems. Each of the various layers is capable of calling upon the specialty of any of the other installed layers in order to complete a given task.

Those components/layers that are requesting services are called “clients”, those components/layers that are providing services are called “servers”.  Thus the term – “client/server”.

Deletion / Archiving of IDOCs

There is no special deletion program for IDocs.
Use the archiving programs. IDoc is a separate archiving class. The following programs are available:

1. Archive RSEXARCA and RSEXARCB (as of Release 3.0C)
2. Delete RSEXARCD
3. Read archiveRSEXARCR
4. Restore RSEXARCL

RSEXARCB is similar to RSEXARCA except for the selection screen. The selection options for RSEXARCB are designed for periodic scheduling.

The Idoc archiving is checked against the status. The statuses which can be archived and those that cannot be archived are stored in the “Status maintenance” table. You can change the standard settings. Menu path: Area menu “WEDI”, control, status maintenance.

Program To Generate IDoc

Report  ZZ_Program_To_Create_Idoc

report  zz_program_to_create_idoc                     .
tables: ekko,ekpo.

selection-screen skip 3.
selection-screen begin of block b1 with frame title titl.
selection-screen skip.
select-options s_ebeln for ekko-ebeln.
selection-screen skip.
selection-screen end of block b1.

data: header_segment_name like edidd-segnam value 'Z1EKKO',
      item_segment_name like edidd-segnam value 'Z1EKPO',
      idoc_name like edidc-idoctp value 'Z19838IDOC1'.

data: header_segment_data like z1ekko,
      item_segment_data like z1ekpo.

data: control_record like edidc.

data: messagetyp like edmsg-msgtyp value 'ZZ9838MESG1'.

data: i_communication like edidc occurs 0 with header line,
      i_data like edidd occurs 0 with header line.

data: begin of i_ekko occurs 0,
      ebeln like ekko-ebeln,
      aedat like ekko-aedat,
      bukrs like ekko-bukrs,
      bsart like ekko-bsart,
      lifnr like ekko-lifnr,
      end of i_ekko.

data: begin of i_ekpo occurs 0,
      ebelp like ekpo-ebelp,
      matnr like ekpo-matnr,
      menge like ekpo-menge,
      meins like ekpo-meins,
      netpr like ekpo-netpr,
      end of i_ekpo.

start-of-selection.

select  ebeln aedat bukrs bsart lifnr from ekko
          into table i_ekko where ebeln in s_ebeln.

select ebelp
       matnr
       menge
       meins
       netpr
       from ekpo
       into table i_ekpo
       where ebeln in s_ebeln.

control_record-mestyp = messagetyp.
control_record-rcvprt = 'LS'.
control_record-idoctp = idoc_name.
control_record-rcvprn = '0MART800'.

loop at i_ekko.
header_segment_data-ebeln = i_ekko-ebeln.
header_segment_data-aedat = i_ekko-aedat.
header_segment_data-bukrs = i_ekko-bukrs.
header_segment_data-bsart = i_ekko-bsart.
header_segment_data-lifnr = i_ekko-lifnr.
i_data-segnam = header_segment_name.
i_data-sdata = header_segment_data.
append i_data.

select ebelp
       matnr
       menge
       meins
       netpr
       from ekpo
       into table i_ekpo
       where ebeln = i_ekko-ebeln.

loop at i_ekpo.
item_segment_data-ebelp = i_ekpo-ebelp.
item_segment_data-matnr = i_ekpo-matnr.
item_segment_data-menge = i_ekpo-menge.
item_segment_data-meins = i_ekpo-meins.
item_segment_data-netpr = i_ekpo-netpr.
i_data-segnam = item_segment_name.
i_data-sdata = item_segment_data.
append i_data.
endloop.
clear i_ekpo.
refresh i_ekpo.
endloop.

call function 'MASTER_IDOC_DISTRIBUTE'
  exporting
    master_idoc_control                  = control_record
*   OBJ_TYPE                             = ''
*   CHNUM                                = ''
  tables
    communication_idoc_control           = i_communication
    master_idoc_data                     = i_data
 exceptions
   error_in_idoc_control                = 1
   error_writing_idoc_status            = 2
   error_in_idoc_data                   = 3
   sending_logical_system_unknown       = 4
   others                               = 5
          .
if sy-subrc <> 0.
 message id sy-msgid type sy-msgty number sy-msgno
         with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
else.

  loop at i_communication.
    write: 'IDOC GENERATED', i_communication-docnum.
  endloop.
  commit work.

endif.

initialization.
titl = 'ENTER THE PURCHASE ORDER NUMBER'

IDOC / BAPIs

There are many differences between IDOCs and BAPIs.

BAPIs in 3.1 are synchronous; in 4.+ they can be asynchronous (and I
believe they then drive certain ALE/IDOCs).

BAPIs are called from the outside-in.  That is, an external program
invokes a BAPI that gets data from SAP to display or updates data in
SAP.  The BAPI concept does not include an event concept — you cannot
tell SAP that when certain events happen to a “business object”, to fire
a message or a file to an external system.

BAPIs are invokable from Java or C/C++ or Visual Basic (and I think some
people are using Delphi).

In 3.1x there are very few BAPIs to use.  In 4.+ SAP has added a large
number.

BAPIs are not totally immune to upgrades but if they are to be retired
you supposedly will have them supported for two releases.  Whether those
are point or letter releases, I don’t know.   I believe that IDOCs may
be more changable from release to release.

BAPIs are reasonably well documented and there is a common place to look
to see what is available.   IDOCs — I have heard — are poorly
documented in terms of finding them, and IDOCs were done differently by
different groups in SAP.

BTW, you can also use Java, C/C++, Visual Basic, … to invoke RFCs in
SAP and get or update data.  That’s how the BAPIs work since they
utimately are sets of RFC calls (written to a design spec for BAPIs).