Delete sales employee in header level with BAPI_CUSTOMERQUOTATION_CHANGE

hi experts,
I try to delete sales employee in header level, but i always get the error message:
FB call: insufficient parameters
The sales document is not yet complete: Edit data
Sales document 0007002015 was not changed
Please give a light how to delete sales employee successfully . Thank you very much!!
My program:
REPORT z_test_change_partner .
DATA:
      order_header_inx LIKE bapisdh1x,
      order_header_in LIKE bapisdh1,
      return LIKE bapiret2 OCCURS 0 WITH HEADER LINE,
      quotation_item_inx LIKE bapisditmx OCCURS 0 WITH HEADER LINE,
      partners LIKE bapiparnr OCCURS 0 WITH HEADER LINE,
      partnerchanges LIKE bapiparnrc OCCURS 0 WITH HEADER LINE
order_header_inx-updateflag = 'U'.
quotation_item_inx-updateflag = 'U'.
quotation_item_inx-itm_number = '000010'.
APPEND quotation_item_inx.
CLEAR partners.
partners-partn_role = 'VE'.
partners-partn_numb = '00001000'.
APPEND partners.
CLEAR partnerchanges.
partnerchanges-document = '0007002015'.
partnerchanges-itm_number = '000000'.
partnerchanges-updateflag = 'D'.
partnerchanges-partn_role = 'VE'.
*partnerchanges-p_numb_old = '00001111'.
*partnerchanges-p_numb_new = '00001000'.
APPEND partnerchanges.
CALL FUNCTION 'BAPI_CUSTOMERQUOTATION_CHANGE'
EXPORTING
    salesdocument                = '0007002015'
   quotation_header_in          = order_header_in
    quotation_header_inx         = order_header_inx
SIMULATION                   =
BEHAVE_WHEN_ERROR            =
INT_NUMBER_ASSIGNMENT        =
LOGIC_SWITCH                 =
NO_STATUS_BUF_INIT           = ' '
TABLES
    return                       = return
QUOTATION_ITEM_IN            =
   quotation_item_inx           = quotation_item_inx
   partners                     = partners
   partnerchanges               = partnerchanges
PARTNERADDRESSES             =
CONDITIONS_IN                =
CONDITIONS_INX               =
QUOTATION_CFGS_REF           =
QUOTATION_CFGS_INST          =
QUOTATION_CFGS_PART_OF       =
QUOTATION_CFGS_VALUE         =
QUOTATION_CFGS_BLOB          =
QUOTATION_CFGS_VK            =
QUOTATION_CFGS_REFINST       =
SCHEDULE_LINES               =
SCHEDULE_LINESX              =
QUOTATION_TEXT               =
QUOTATION_KEYS               =
EXTENSIONIN                  =
LOOP AT return.
WRITE / return-message.
ENDLOOP.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
   wait          = 'X'
IMPORTING
RETURN        =

Hi Edith,
Thank you very much for your reply.
I changed my program by following your steps in the reply. Now the BAPI is showing error messages: "Instance 7200000060 of object type PurchaseOrder could not be changed" and "Price without service not allowed".
Please refer my code below.
poitem-po_item = '0010'.
poitem-pckg_no = '0000001964'.
poitem-item_cat = '9'.
APPEND poitem.
poitemx-po_item = '10'.
poitemx-po_itemx = 'X'.
poitemx-pckg_no = 'X'.
poitemx-item_cat = 'X'.
APPEND poitemx.
Parent line
poservices-pckg_no = '0000001964'.
poservices-line_no = '0000000001'.
poservices-ext_line = '0000000000'.
poservices-subpckg_no = '0000001965'.
poservices-matl_group = '01040107'.
*poservices-delete_ind = 'X'.
*poservices-quantity = ' '.
*poservices-base_uom = ' '.
*poservices-gr_price = ' '.
APPEND poservices.
CLEAR: poservices.
Child line.
poservices-pckg_no = '0000001965'.
poservices-line_no = '0000000002'.
poservices-ext_line = '0000000010'.
poservices-quantity = '1'.
poservices-service = '000000000005000010'.
poservices-base_uom = 'EA'.
poservices-gr_price = '150'.
poservices-subpckg_no = '0000000000'.
poservices-matl_group = '01040107'.
poservices-delete_ind = 'X'.
APPEND poservices.
CALL FUNCTION 'BAPI_PO_CHANGE'
EXPORTING
    purchaseorder = '7200000060'
TABLES
    return        = return[]
    poitem        = poitem[]
    poitemx       = poitemx[]
    poservices    = poservices[]
    posrvaccessvalues = posrvaccessvalues[].
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
Regards,
Revanth

Similar Messages

How to delete a PO at header level - Restrict to a specific order type

Hi,
Deletetion of PO at header level is not recomended but still in my project they are using it to delete a particular PO type and should not allow to delete the other PO types. Recently Support Pack upgrade was done. After this activity deletion is not happening. Hope the relevent code got over writed with the original.
Here creation and change of PO will be done from a third party system through IDOC. Deletion of PO at header level should be possible only through IDOC.
Can some one give me the idea where(BAdI/Enhancement) we need to write the code to allow the deletion of PO of a particular type?
Regards,
Balaram Devineni

Hope you are referring to "setting of deletion indicator at header level of PO" (EKKO-LOEKZ = 'L'). Standard method CL_PO_HEADER_HANDLE_MM->PO_CANCEL may be helpful (you may have to integrate this with IDOC processing function module). Wiki post [Purchase Order Cancellation (Header) using ABAP Classes|http://wiki.sdn.sap.com/wiki/display/ABAP/PurchaseOrderCancellation%28Header%29usingABAPClasses] will be a good reference.

Deleting multiple POs are header level

Hi,
We are in SRM 5.0, is there any function module by which we can delete old POs at header level.
Rgds,
Madhan

See the foll link:
Re: How to delete a PO in SRM

Billing plan (Downpayment) for saved and open sales orders at header level?

Hi gurus,
I have configured billing plan in my SD environment at Item Level.
I want to change it to header level.
Questions:
1- When I make the changes to update the system to have billing plan at header level for future sales orders, is that possible for me to change all my saved orders and open orders with the new settings so that I can also have those saved and open orders with a billing plan at item level?
2- If that scenario is not possible, could we for example copy the data of a previously saved or open sales order into a new sales order with the new customizing (Billing plan at Header level?)
Thanks for your input
Kind regards
Chris

Hi
I am afraid you cannot do that converstion for the existing orders. BP at header level are enabled at teh document type level, while BP at item level is done at item category. So both are independent. Mostly it is advisabel to use BP at item level only.
If you are already using item level BP, and want to mvoe to header BP, then only future transactions can be executed with BP at header level. Existing item level BPlans will remain so in the system.

Clearing Sales Tax at Header Level in an Order

Hi,
I have a requirement to not charge any tax on an order if the credit card used on the order is a government credit card. Currently I have implemented this logic in USEREXIT_SAVE_DOCUMENT_PREPARE. I am able to clear out the sales tax at the line level but this change does not reflect at the header level. I have to manually click on update pricing to zero out the tax displayed at the header level. I could not find a variable to tap into header level pricing condition and tax value field.
I would greatly appreciate if any one can give me some pointers on where to look for header level data for tax. Also, is there any better user exit to implement this functionality.
Folliwing is the code I am using to clear out line item level tax:
          LOOP AT XKOMV INTO WA_XKOMV WHERE KSCHL EQ 'UTXJ'.    "GET THE TAX CONDITION
              CLEAR WA_XKOMV-KWERT.                               "Set the TAX to 0
              CLEAR WA_XKOMV-KAWRT.
              CLEAR WA_XKOMV-KBETR.
              MODIFY TABLE XKOMV FROM WA_XKOMV
                TRANSPORTING KWERT KAWRT KBETR.
          ENDLOOP.
          LOOP AT XVBAP INTO WA_XVBAP.    "GET THE TAX VALUE
              CLEAR WA_XVBAP-MWSBP.                               "Set the TAX to 0
              MODIFY TABLE XVBAP FROM WA_XVBAP
                TRANSPORTING MWSBP.
          ENDLOOP.
Thanks,
Paresh

Hi,
In the case of sales cycle, All the item level taxes are summirised and come to the header level. So we can't find the conditions at header level for taxes. Check the user exit , because, the values are already moved to the header level structure and then you are clearing the item level taxes. I hope thats why the changes are not reflected in header level.
Regards,

Rounding of sales tax at header level

HI
I want to roundoff tax at header level . we already using the tax rounding off at item level .
But new requirement is instead of Item level roundoff , they want the roundoff at header level
Plz provide solutions

Hi
U have 2 options
1. Conversion rule(OY04)
2. SPRO-Ref IMG-Global setting Data- Conversion Rule
or once u r maintaining the condition record for Tax value (FV11/ vK11/Vk19)
there u can find rounding rule.
thanks
mk

Deactivating Ship to party as mandatory in sales order create-header level

Hi,
I have tried to deactivate the Ship-to-paty as mandatory function,like i don't want to have a ship to party under the sold to party in the sales order header as a mandatory field.
To do this i have removed the partner function SH assignment with KU and 07 in the partner procedure for Sales doc header, and now in the sales order it is not a mandatory function.
But the issue now here is, there is not partner function SH in item level also.
can u pls suggest
SR

Hi,
That is not correct process, U are deleting entire partner function from sales order..
I think what u are asking is while creating order system is showing Ship to party is mandatory. If u want to delete this message then u have to change the Incomplete procedure for that sales order doc type.
Please select that Incomplete procedure in IMG configuration there u just made this ship to party field as optional and dont put it as mandatory then try to create order. It will take data with out ship to party..
( Hope u know how to go through Incomplete procedrue steps )
Please let us know if u still get issue once u do changes in incomplete procedure..
Regards
Sankar

PO no.& PO dt. to be copied from contract to sales order at header level??

Hi,
I have a requirement, Purchase Order number & date has to be copied to the sales order (header fields below the SP & SH fields) when i create a sales order with reference to a contract. Can you tell which routine to be used in copy control??
Thanks
Ghanesh
Edited by: Ghanesh Visu on Feb 16, 2010 9:17 AM

Hi,
I as far as my understanding you have to create new routine or copy from existing and modify that
and maintain condition P.O & Date should not be change.
Kapil

Copy Billing plan from Quation to Sales order at header level

Dear Gurus,
I am using custom routine (600) to copy Billing plan from Quotation to Sales Order.
I used following code to copy Billing plan.
LOOP AT CFPLT.
MOVE-CORRESPONDING cfplt TO FPLT.
CLEAR FPLT-FPLNR.
FPLT-FPLNR = FPLA-FPLNR.
MOVE-CORRESPONDING FPLT TO XFPLT.
XFPLT-UPDKZ = 'I'.
APPEND XFPLT.
CLEAR XFPLT.
ENDLOOP.
UPD_FPLT = 'I'.
I also tried with CFPLA instead of CFPLT.
Using this code all line item Billing plan is coping into header Sales order Billing Plan (Duplicating records). When I save and come back it is giving Express Document error.
I could not able to save document.
Please guide me this regards.
Thanks,
Vasanth.

Hello Nag,
Did you check your copy control routines in transaction VTAA? You need to see if these fields are included in the routines maintained for copy control between your contract and sales order.
I hope this helps.
Best regards,
Ian Kehoe

Query on PO Deletion at Header Level

Hello Everybody,
We are using SRM 4.5 system (standalone without any MM backend). Our business needs to Delete POs which have already been ordered. Currently SAP is allowing us to delete the PO items once a PO is Ordered. But our requirement is to delete the PO from the header level itself, i.e., even if the PO is in ordered status, the Delete option at PO Header level should be present and allowed. Is there any way to achieve this requirement?
Kindly help.
Thanks and Regards,
Debanjan

Hi,
There is no option to configure at header.
Thanks

Delete the PO at the header level after it has been output sucessfully

Can we change the status of a Purchase order in SRM from 'ordered' to 'deleted' ?
It seems we can do it only if the PO has not been output successfully.
I have checked for a few POs and found for such POs if you go ti change mode , the delete button at the header level
does not become enabled.
But I have found a PO in the system which was output suceessfully but its status is deleted. The PO has not been transfered to ECC .
Please help .
I do not want to forcibly change the status from the backend.

We have some BI reports which requires the POs to be deleted at the header level

BADI for sales order header level data

Is there any BADI which will give me the sales order header level data? I need net price of the sales order in header level. KOMK structure does not contains the net price value.

My requirement is:
I am writing a pricing routine for calculating ZSMR condition value in sales order header level. The formula for calculating is (NET PRICE / NET SALES COST) / NET PRICE.
I can't use VBAK because I have not saved the sales order yet. I need to use some structure.
Which structure contains the net price of the sales order in header level. KOMK structure does not contains the net price value.
Edited by: dossgs on May 21, 2010 4:08 PM

Which structure field contains the header level net price of sales order ?

Hi Friends,
I am writing a pricing routine for calculating ZSMR condition value in sales order header level. The formula for calculating is (NET PRICE / NET SALES COST) / NET PRICE.
Which structure contains the net price of the sales order in header level. KOMK structure does not contains the net price value.
Any ideas is highly appreciable.
Thanks,
Sakthidoss.

Sivanand,
I can not use VBAK as I have not saved the sales order yet and before that I need to calculate the pricing condition. In the sales order header level, net price is showing. I want to know which structure contains that net price value.
You have any thoughts whether I am in correct path?
I will certainly appreciate your help by rewarding points.
Edited by: dossgs on May 20, 2010 2:13 PM

SIS - sales employee

Hi experts,
How to activate the report named "MCTI - sales employee"? Pls advise. Thx.
Moreover, partner determination for sales doc has been maintained. Customer & material have been maintained well as other standard analyses can be run, such as MCTA - customer.

Dear Cathy,
Please confirm:
1. Have you created Sales Employee/ Personnel Records with T. Code: VPE1?
2. Have you mainatined Partner Determination for the same?
For Info-sake: [Sales Employee|Re: Sales Employee]
3. Have yoy key-in Sales Employee/ Personnel in to Sales Document i.e. Sales Order at Header-Level (Go To --> Header --> Partner)?
If, above-said configurations are done already, Have you maintained SIS and LIS related settings:
[SIS Activation|Re: Sales Information System]
Best Regards,
Amit
Note: Some more references -
Re: MCTA & MCTC - no data available

BADI enhancement for Enjoy PO Tcodes at "header level".

I could successfully add an item level tab to MEXXN PO tcodes. Somebody help me with the ME_GUI_PO_CUST and ME_PROCESS_PO implementations to add a customer field , say ZZ_ETYP in a separate header level tab "Expense type".
Do I need to add subscreen2 attribute to the implementing class ?
Will one structure do for both header and item level data ?
Do I need to create a separate table ( like ZMEPO_BADI_EXAMPL for items ) for the header also ?
It would be gr8 if i could get the code for the above BADIs and MEPOBADIEX's function modules.

Dear Iyer,
Kindly go through the code.. hope this will help you...
DETAILED DATABASE DESIGN SPECIFICATIONS
1. ZTPTP_HEADER
Header: Expense Type
Field Name Field Type Key Information Field Description
MANDT MANDT X Client
EBELN EBELN X Purchasing Document Number
ZZ_EXPTYPE ZZEXPTYPE Expense Type
2. ZTPTP_ITEM
Item: Retainage
Field Name Field Type Key Information Field Description
MANDT MANDT X Client
EBELN EBELN X Purchasing Document Number
EBELP EBELP X Item Number of Purchasing Document
ZZ_RETAINAGE ZZRETAINAGE Retainage
3. ZSPTP_HEADER
PO Enhancement structure: Header
Field Name Field Type Key Information Field Description
EBELN EBELN Purchasing Document Number
ZZ_EXPTYPE ZZEXPTYPE Expense Type
4. ZSPTP_ITEM
PO Enhancement structure: Item
Field Name Field Type Key Information Field Description
EBELN EBELN Purchasing Document Number
EBELP EBELP Item Number of Purchasing Document
ZZ_RETAINAGE ZZRETAINAGE Retainage
Detailed logic
LZPTP_PORETAINAGETOP (TOP INCLUDE) FG: ZPTP_PORETAINAGE
persistent item data
data: git_persistent_data type sorted table of ztptp_item
 with unique key mandt ebeln ebelp,
actual item data
 git_data type sorted table of ztptp_item
 with unique key mandt ebeln ebelp.
persistent header data
data: git_persistent_head type sorted table of ztptp_header
 with unique key mandt ebeln ,
actual header data
 git_head type sorted table of ztptp_header
 with unique key mandt ebeln .
dynpro output structure
tables: zsptp_item,
 zsptp_header.
definitions required for dynpro/framework integration
data: ok-code type sy-ucomm.
Following is a SAP include.
include lmeviewsf01.
1. ZPTP_COMMIT_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_COMMIT. In this Function module we update the database table ZTPTP_HEADER i.e. as per a change / insert or delete command at the header level. This database tables size will always be low. It just contains the PO s data just being edited or created.
The interface would look like:
 TABLES
 IMT_DATA_NEWHD STRUCTURE ZTPTP_HEADER
 IMT_DATA_OLDHD STRUCTURE ZTPTP_HEADER
 Comparing the old and new data we update 3 different internal tables and using these we can update the internal tables ZTPTP_HEADER before actually updating the database table EKKO.A similar logic is coded in the sample FM : MEPOBADIEX_COMMIT

2. ZPTP_COMMIT_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_COMMIT. In this Function module we update the database table ZTPTP_HEADER i.e. as per a change / insert or delete command at the item level. This database tables size will always be low. It just contains the PO s latest data just being edited or created.
The interface would look like :
 TABLES
 IMT_DATA_NEW STRUCTURE ZTPTP_ITEM
IMT_DATA_OLD STRUCTURE ZTPTP_ITEM
 Comparing the old and new data we update 3 different internal tables and using these we can update the internal tables ZTPTP_HEADER before actually updating the database table EKPO. A similar logic is coded in the sample FM : MEPOBADIEX_COMMIT
3. ZPTP_GET_DATA_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_GET_DATA. This FM is responsible for updating an internal table (git_head) which would hold the data the user has changed or created or displayed till the current point of time. It would also hold the latest customer header data that is to be displayed in case of a change transaction.
The interface would be as follows:
Local Interface:
IMPORTING
 REFERENCE(IM_EBELN) TYPE EBELN
 REFERENCE(IM_EBELP) TYPE EBELP OPTIONAL
EXPORTING
 REFERENCE(EX_HEAD) TYPE ZTPTP_HEADER
Read expense type from git_header. If not found, get expense value from EKKO.
4. ZPTP_GET_DATA_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_GET_DATA. This FM is responsible for updating an internal table (git_data) which would hold the data the user has changed or created or displayed till the current point of time. It would also hold the latest customer item data that is to be displayed in case of a change transaction.
The interface would be as follows:
Local Interface:
IMPORTING
 REFERENCE(IM_EBELN) TYPE EBELN
 REFERENCE(IM_EBELP) TYPE EBELP
EXPORTING
 VALUE(EX_DATA) TYPE ZTPTP_ITEM
Read Retainage from git_data. If not found, get Retainage value from EKPO.
5. ZPTP_INIT FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_INIT. This FM is responsible for clearing the header and item internal tables.
clear: git_persistent_data[], git_data[],git_persistent_head[],git_head[].
6. ZPTP_OPEN FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_OPEN. This FM is responsible for existing information from respective database tables.
The interface would be as follows:
Local Interface:
IMPORTING
REFERENCE(IM_EBELN) TYPE EBELN
Get Expense type and Retainage from customer created Tables and assign it to respective global internal tables.
7. ZPTP_POP_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_POP. This FM is responsible for getting header values from screen fields.
The interface would be as follows:
Local Interface:
EXPORTING
 REFERENCE(EX_DYNP_DATAHD) TYPE ZSPTP_HEADER
get dynpro data
ex_dynp_datahd = zsptp_header.
8. ZPTP_POP_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_POP. This FM is responsible for getting item values from screen fields.
The interface would be as follows:
Local Interface:
EXPORTING
 REFERENCE(EX_DYNP_DATA) TYPE ZSPTP_ITEM
get dynpro data
ex_dynp_data = zsptp_item.
9. ZPTP_POST_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_POST. This FM is responsible for preparing header data for posting.
Local Interface:
IMPORTING
 VALUE(IM_EBELN) TYPE EBELN
prepare customers data for posting
check not im_ebeln is initial.
lit_data_newhd[] = git_head.
lit_data_oldhd[] = git_persistent_head.
lwa_head-mandt = sy-mandt.
lwa_head-ebeln = im_ebeln.
modify lit_data_newhd from lwa_head transporting mandt ebeln where ebeln is initial.
Commit data in Database ztptp_header.
call function 'ZPTP_COMMIT_HEADER'
 tables
 imt_data_newhd = lit_data_newhd
 imt_data_oldhd = lit_data_oldhd.
10. ZPTP_POST_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_POST. This FM is responsible for preparing item data for posting.
"Local Interface:
IMPORTING
 VALUE(IM_EBELN) TYPE EBELN
data: lwa_data like line of git_data,
 lit_data_new type standard table of ztptp_item,
 lit_data_old type standard table of ztptp_item.
prepare customers data for posting
check not im_ebeln is initial.
lit_data_new[] = git_data.
lit_data_old[] = git_persistent_data.
lwa_data-mandt = sy-mandt.
lwa_data-ebeln = im_ebeln.
modify lit_data_new from lwa_data transporting mandt ebeln where ebeln is initial.
Commit data in Database ztptp_item.
call function 'ZPTP_COMMIT_ITEM' in update task
 tables
 imt_data_new = lit_data_new
 imt_data_old = lit_data_old.
11. ZPTP_PUSH_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_PUSH. This FM is responsible for populating header values to screen fields.
Local Interface:
IMPORTING
 REFERENCE(IM_DYNP_DATAHD) TYPE ZSPTP_HEADER
set dynpro data
zsptp_header = im_dynp_datahd .
12. ZPTP_PUSH_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_PUSH. This FM is responsible for populating item values to screen fields.
Local Interface:
IMPORTING
 REFERENCE(IM_DYNP_DATA) TYPE ZSPTP_ITEM
set dynpro data
zsptp_item = im_dynp_data .
13. ZPTP_SET_DATA_HEADER FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_SET_DATA. This FM is responsible for keep update header information in git_header.
delete a line from git_data
 delete table git_head with table key mandt = sy-mandt
 ebeln = im_datahd-ebeln.
update customer data
 read table git_head assigning <lf_datahd> with table key
 mandt = sy-mandt
 ebeln = im_datahd-ebeln.
 if sy-subrc is initial.
update existing data
 <lf_datahd>-zz_exptype = im_datahd-zz_exptype.
 else.
make a new entry into the data table
 lwa_head = im_datahd.
 lwa_head-mandt = sy-mandt.
 insert lwa_head into table git_head.
 endif.
14. ZPTP_SET_DATA_ITEM FG: ZPTP_PORETAINAGE
Get the sample function module code from the standard FM: MEPOBADIEX_SET_DATA. This FM is responsible for keep update item information in git_data.
delete a line from git_data
 delete table git_data with table key mandt = sy-mandt
 ebeln = im_data-ebeln
 ebelp = im_data-ebelp.
update customer data
 read table git_data assigning <lf_data> with table key
 mandt = sy-mandt
 ebeln = im_data-ebeln
 ebelp = im_data-ebelp.
 if sy-subrc is initial.
update existing data
 <lf_data>-zz_retainage = im_data-zz_retainage.
 else.
make a new entry into the data table
 lwa_data = im_data.
 lwa_data-mandt = sy-mandt.
 insert lwa_data into table git_data.
 endif.
DETAILED SCREEN DESIGN SPECIFICATIONS
screen 0002
Item Retainage
ZSPTP_ITEM-ZZ_RETAINAGE DEC 5 Retainage
Screen Logic / Process before Output
call method call_view->handle_event( 'PBO' ).
Screen Logic / Process after Input
call method call_view->handle_event( 'PAI' )
Screen 0003
Header: Expense type
ZSPTP_HEADER-ZZ_EXPTYPE NUMC 4 Expense Type
Screen Logic / Process before Output
call method call_view->handle_event( 'PBO' ).
Screen Logic / Process after Input
call method call_view->handle_event( 'PAI' )
DETAILED CLASS DESIGN SPECIFICATIONS
A. ZCL_IM_ME_GUI_PO_CUST
Description
Imp. Class ZME_GUI_PO_CUST
Attributes
Name Level Visibility Type
SUBSCREEN1 Constant Public MEPO_NAME
SUBSCREEN2 Constant Public MEPO_NAME
DYNP_DATA_PBO Instance Attribute Private ZSPTP_ITEM
DYNP_DATA_PAI Instance Attribute Private ZSPTP_ITEM
DYNP_DATA_PBOHD Instance Attribute Private ZSPTP_HEADER
DYNP_DATA_PAIHD Instance Attribute Private ZSPTP_HEADER
Methods
Name Level Visibility
IF_EX_ME_GUI_PO_CUST~SUBSCRIBE Instance Attribute Public
IF_EX_ME_GUI_PO_CUST~MAP_DYNPRO_FIELDS Instance Attribute Public
IF_EX_ME_GUI_PO_CUST~TRANSPORT_FROM_MODEL Instance Attribute Public
IF_EX_ME_GUI_PO_CUST~TRANSPORT_TO_DYNP Instance Attribute Public
IF_EX_ME_GUI_PO_CUST~TRANSPORT_FROM_DYNP Instance Attribute Public
IF_EX_ME_GUI_PO_CUST~TRANSPORT_TO_MODEL Instance Attribute Public
1. SUBSCRIBE
Description
Publisch Customer's Own Screens
Detailed logic
when lc_item.
the name is a unique identifier for the subscreen and defined in this class definition
lwa_subscriber-name = subscreen1.
the dynpro number to use
lwa_subscriber-dynpro = '0002'.
the program where the dynpro can be found
lwa_subscriber-program = 'SAPLZPTP_PORETAINAGE'.
each subscreen needs his own DDIC-Structure
lwa_subscriber-struct_name = 'ZSPTP_ITEM'.
a label can be defined
lwa_subscriber-label = text-001.
the position within the tabstrib can be defined
lwa_subscriber-position = 1.
lwa_subscriber-height = 7.
append lwa_subscriber to re_subscribers.
Header subscreen
when lc_header.
the name is a unique identifier for the subscreen and defined in this class definition
lwa_subscriber-name = subscreen2.
the dynpro number to use
lwa_subscriber-dynpro = '0003'.
the program where the dynpro can be found
lwa_subscriber-program = 'SAPLZPTP_PORETAINAGE'.
each subscreen needs his own DDIC-Structure
lwa_subscriber-struct_name = 'ZSPTP_HEADER'.
a label can be defined
lwa_subscriber-label = text-002.
the position within the tabstrib can be defined
lwa_subscriber-position = 1.
lwa_subscriber-height = 7.
append lwa_subscriber to re_subscribers.
endcase.
2. MAP_DYNPRO_FIELDS
Description
Build Up Field Catalog
Detailed logic
loop at ch_mapping assigning <lf_mapping>.
*Assignment of metafields to the customer fields.
 case <lf_mapping>-fieldname.
 when 'EBELN'. <lf_mapping>-metafield = mmmfd_preq_no_po.
 when 'EBELP'. <lf_mapping>-metafield = mmmfd_preq_item_po.
 when 'ZZ_RETAINAGE'. <lf_mapping>-metafield = mmmfd_cust_01.
 when 'ZZ_EXPTYPE'. <lf_mapping>-metafield = mmmfd_cust_02.
 endcase.
endloop.

3. TRANSPORT_FROM_MODEL
Description
Data Transport from Business Object
Detailed logic
 when subscreen1.
Get the item object
 mmpur_dynamic_cast lif_item im_model.
 check not lif_item is initial.
 lwa_mepoitem = lif_item->get_data( ).
transport customer fields
 call function 'ZPTP_GET_DATA_ITEM'
 exporting
 im_ebeln = lwa_mepoitem-ebeln
 im_ebelp = lwa_mepoitem-ebelp
 importing
 ex_data = lwa_customer.
store info for later use
 move-corresponding lwa_mepoitem to dynp_data_pbo.
 move lwa_customer-zz_retainage to dynp_data_pbo-zz_retainage.
 when subscreen2.
Get the header object
 mmpur_dynamic_cast lif_header im_model.
 check not lif_header is initial.
transport standard fields
 lwa_mepohead = lif_header->get_data( ).
transport customer fields
 call function 'ZPTP_GET_DATA_HEADER'
 exporting
 im_ebeln = lwa_mepohead-ebeln
 importing
 ex_head = lwa_customerhd.
store info for later use
 move-corresponding lwa_mepohead to dynp_data_pbohd.
 if not lwa_customerhd-zz_exptype is initial.
 move lwa_customerhd-zz_exptype to dynp_data_pbohd-zz_exptype.
 else.
 move dynp_data_paihd-zz_exptype to dynp_data_pbohd-zz_exptype.
 endif.
 when others.
endcase.
4. TRANSPORT_TO_DYNP
Description
Data Transport to Screen
Detailed logic
case im_name.
 when subscreen1 .
 Pushing item data to screen fields
 call function 'ZPTP_PUSH_ITEM'
 exporting
 im_dynp_data = dynp_data_pbo.
 when subscreen2 .
 Pushing header data to screen fields
 call function 'ZPTP_PUSH_HEADER'
 exporting
 im_dynp_datahd = dynp_data_pbohd.
 when others.
endcase.
5. TRANSPORT_FROM_DYNP
Description
Data Transport from Screen
Detailed logic
case im_name.
 when subscreen1.
Getting item data from screen fields
 call function 'ZPTP_POP_ITEM'
 importing
 ex_dynp_data = dynp_data_pai.
 if dynp_data_pai ne dynp_data_pbo
 or dynp_data_paihd ne dynp_data_pbohd.
If data changed we have to notify the framework
to transport data to the model
 re_changed = mmpur_yes.
 endif.
 when subscreen2.
Getting header data from screen fields
 call function 'ZPTP_POP_HEADER'
 importing
 ex_dynp_datahd = dynp_data_paihd.
 if dynp_data_paihd ne dynp_data_pbohd
 or dynp_data_pai ne dynp_data_pbo.
If data changed we have to notify the framework
to transport data to the model
 re_changed = mmpur_yes.
 endif.
 when others.
endcase.
6. TRANSPORT_TO_MODEL
Description
Treatment of Function Codes
Detailed logic
case im_name.
 when subscreen1.
is it an item? im_model can be header or item.
 mmpur_dynamic_cast lif_item im_model.
 check not lif_item is initial.
 lwa_mepoitem = lif_item->get_data( ).
standard fields changed?
 if dynp_data_pbo-ebeln ne dynp_data_pai-ebeln or
 dynp_data_pbo-ebelp ne dynp_data_pai-ebelp or
 dynp_data_pbo-zz_retainage ne dynp_data_pai-zz_retainage.
update standard fields
 lwa_mepoitem-ebeln = dynp_data_pai-ebeln.
 lwa_mepoitem-ebelp = dynp_data_pai-ebelp.
 lwa_mepoitem-zzretainage = dynp_data_pai-zz_retainage.
 call method lif_item->set_data( lwa_mepoitem ).
 endif.
customer fields changed?
 if dynp_data_pbo-zz_retainage ne dynp_data_pai-zz_retainage.
 call function 'ZPTP_GET_DATA_ITEM'
 exporting
 im_ebeln = lwa_mepoitem-ebeln
 im_ebelp = lwa_mepoitem-ebelp
 importing
 ex_data = lwa_customer.
 lwa_customer-zz_retainage = dynp_data_pai-zz_retainage.
Commit changes to database.
 call function 'ZPTP_SET_DATA_ITEM'
 exporting
 im_data = lwa_customer.
 endif.
 when subscreen2.
is it an header? im_model can be header or item.
 mmpur_dynamic_cast lif_header im_model.
 check not lif_header is initial.
 lwa_mepohead = lif_header->get_data( ).
standard fields changed?
 if dynp_data_pbohd-ebeln ne dynp_data_paihd-ebeln or
 dynp_data_pbohd-zz_exptype ne dynp_data_paihd-zz_exptype.
update standard fields
 lwa_mepohead-ebeln = dynp_data_paihd-ebeln.
 lwa_mepohead-zzexptype = dynp_data_paihd-zz_exptype.
 call method lif_header->set_data( lwa_mepohead ).
 endif.
customer fields changed?
 if dynp_data_pbohd-zz_exptype ne dynp_data_paihd-zz_exptype.
 call function 'ZPTP_GET_DATA_HEADER'
 exporting
 im_ebeln = lwa_mepohead-ebeln
 importing
 ex_head = lwa_customerhd.
 lwa_customerhd-zz_exptype = dynp_data_paihd-zz_exptype.
Commit changes to database.
 call function 'ZPTP_SET_DATA_HEADER'
 exporting
 im_datahd = lwa_customerhd.
 endif.
 when others.
endcase.

B. ZCL_IM_ME_PROCESS_PO_CUST
Description
Imp. Class for BAdI imp. ZME_PROCESS_PO_CUST
Methods
Name Level Visibility
IF_EX_ME_PROCESS_PO_CUST~INITIALIZE Instance Attribute Public
IF_EX_ME_PROCESS_PO_CUST~OPEN Instance Attribute Public
IF_EX_ME_PROCESS_PO_CUST~PROCESS_HEADER Instance Attribute Public
IF_EX_ME_PROCESS_PO_CUST~PROCESS_ITEM Instance Attribute Public
IF_EX_ME_PROCESS_PO_CUST~POST Instance Attribute Public
IF_EX_ME_PROCESS_PO_CUST~CLOSE Instance Attribute Public

1. INITIALIZE
Description
Initializations (Invoked Once Only)
Detailed logic
initializations
call function 'ZPTP_INIT'.
2. OPEN
Description
Open a Purchase Order
Detailed logic
data: lwa_mepoheader type mepoheader.
read customer data
this has to be done when we open a persistent object
check im_trtyp eq 'V' or im_trtyp eq 'A'.
lwa_mepoheader = im_header->get_data( ).
read customer data from database
call function 'ZPTP_OPEN'
 exporting
 im_ebeln = lwa_mepoheader-ebeln.
3. PROCESS_HEADER
Description
Processing of Header Data
Detailed logic
data: lwa_mepohead type mepoheader,
 lwa_customerhd type ztptp_header.
include mm_messages_mac. "useful macros for message handling
here we check customers data
lwa_mepohead = im_header->get_data( ).
if lwa_mepohead-loekz eq 'D'.
a physical deletion of the header was carried out.
 lwa_customerhd-ebeln = lwa_mepohead-ebeln.
 call function 'ZPTP_SET_DATA_HEADER'
 exporting
 im_datahd = lwa_customerhd
 im_physical_delete_request = 'X'.
endif.
4. PROCESS_ITEM
Description
Processing of Item Data
Detailed logic
data: lwa_mepoitem type mepoitem,
 lwa_customer type ztptp_item.
include mm_messages_mac. "useful macros for message handling
here we check customers data
lwa_mepoitem = im_item->get_data( ).
if lwa_mepoitem-loekz eq 'D'.
a physical deletion of the item was carried out. therrefor we have to
delete customer data on the level of the item
 lwa_customer-ebeln = lwa_mepoitem-ebeln.
 lwa_customer-ebelp = lwa_mepoitem-ebelp.
 call function 'ZPTP_SET_DATA_ITEM'
 exporting
 im_data = lwa_customer
 im_physical_delete_request = 'X'.
endif.
5. POST
Description
Post
Detailed logic
*Posting header data
 call function 'ZPTP_POST_HEADER'
 exporting
 im_ebeln = im_ebeln.
*Posting item data
 call function 'ZPTP_POST_ITEM'
 exporting
 im_ebeln = im_ebeln.

6. CLOSE
Description
Closing Processing
Detailed logic
close customer data
call function 'ZPTP_INIT'.

Delete sales employee in header level with BAPI_CUSTOMERQUOTATION_CHANGE

Similar Messages

Maybe you are looking for