PO Close Indicator at header Level

Hi,
Is there any way of determining that the PO is closed at the Header Level instead at Line Item Level.
We are implementing 4.6C and in 4.6C there is no field which will determine that the PO is closed, in the sense that Goods Receipt is done for all Line Items.
I am not sure if there is any indicator at PO header level in the higher versions other than 4.6c
Please let me know if there is any indicator available in the higher versions.
Thanks,
Vani.

Hi ,
1. open PO ---> you have not recieved the /GR complete qty of PO.
2. Open for GR -
> complete invoicing for recieved material qty has not taken place.
3. Open for Invoicing -
> Account posting has not taken place for invoice which you have created.
hoppe it helps....
manoj singh

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.

How to close a PO at the header level

Is it possible to close a PO at the header level or a way to deactivate the PO so that no new items can be added? Thanks in advance for any suggestions.

> Is it possible to close a PO at the header level
Po can be closed at Item level and not Header level. You can set Deletion Indicator and further can be archived thru SARA MM_EKKO
or a way to deactivate the PO so that no new items can be added?
You can activate Release strategy and Choose a Proper Release indicatory so that no new changes to be carried out.
Else go for User Exits

Complete delivery indicator in the sales order header level

my order quantity is 10 and having the complete delivery indicator in the header level
Complete delivery indicator in the sales order header level
when i am doing the partial delivery i got below error
Delivery quantity is less than quantity of 10 PC assigned to batches
this is warehouse linked.
Please let us know how to do the partial delivery.
when i click on the bacth icon to reduce the quantity it is greayed out.
is there any posiblity to reduce the quantity in the transfer order
Please do the needfull
thanks
Raju.

Hi
Usually this Complete delivery indicator flow from Customer master data. you need to change this data in Customer Master
Sales Area Tab under Shipping view Remove the Complete delivery indicator, also in Partial delivery per item keep the field Blank ( Partial deliveries allowed )
I hope this will solve your issue
Award if useful to you

Sale order close at header level

Hi
How can I cose a sale order completely at header level having more than one line items so that no schedule line can be used for delivery.
Regards
Rajesh

Dear Mr.G. Lakshmipathi
Thanks for your answer.I know this option but it does n't fulfill my requirement.
There are more than one sale orders of the same material at a time for different customers having daywise schdule.System confirms the complete qty.in sale order used in first.While I need partely qty.to be sale to the other customer also.How can I transfer the qty.confirmed in first sale order to other sale order.
Thanks
Rajesh

How to manually delete Po at header level ?

Hi,
I can delete PO line items in my ECC60 system
However, i would like to delete PO at header level.
In EKKO , i can see the deletion flag in LOEKZ field.
BUT in ME22N, i cannot find any button to delete PO at header level...
Could somebody clarify the PO deletion at header level and the LOEKZ deletion flag in EKKO ?
Kind regards,
Yann

Yann,
To my knowledge you cannot directly delete PO from the system. You need to follow the archiving steps...
1. Program: RM06EV47 - For setting Deletion Indicator
2. Program: RM06EW47 - For archiving the document.
3. Program: RM06ED47 - For Deletion from the system.
If you need further details you can go through this link <a href="http://help.sap.com/saphelp_47x200/helpdata/en/8d/3e4b63462a11d189000000e8323d3a/frameset.htm">Archiving Purchase documents</a>
Hope this helps....Reward your points and close the thread if so,
Regards,
Prasobh

Issue while creating a field at header level in CRM 4.0

Hi,
Using transaction EEWB, I tried to add a custom field at the header level to an existing Project. The Project already had an extension created to which I made the modifications i.e. added the field at header level. But, when I tried to generate the changes, I got the following two errors : 1. No task for editing objects can be determined and 2. Creating of BAdi Implementation failed.
Now, when I try to revert back the changes I am not allowed to do so. Please help me as I am new to CRM. Thanks a lot in advance.

Hi,
if ur still not able to do that
goto EEWB
Enter the Project Name
Right click on the Enhancement---->Select back to previous version.
Please Reward Points & Mark Helpful Answers
To mark Helpful Answers ;click radio Button next to the post.
RadioButtons
o Helpful Answer
o Very helpful Answer
o Problem Solved.
Click any of the above button next to the post; as per the anwers
To close the thread; Click Probelm solved Radio Button next to the post , which u feel is best possible answers

Deletion of the Purchase order at the item level and header level

Hi Gurus,
We are using SRM 7.0 system.
In standard SRM 7.0, the PO can be deleted at header level and at line item level. I need to know the differnce between these deletions. I found that if the PO is deleted at the line item level the deletion indicator (DEL_IND) field in BBP_PDIGP table is 'X'.
But i could not find any clue to find the PO which is deleted at the header level. I need to code this logic in a report .
Kindly provide your valuable inputs.
Thanks,
RK

There are two ways:
1. From the Header by clicking the DELETE button. And this is only possible when the PO is not yet output to Vendor.
2. The second way is to delete all the items in the PO. This is possible any time irrespective of the output sent to the vendor. But provided if there are no follow-on documents for this.
Some times we could see the Deletion icon active in Header , it is because there is change version existing.
When a PO is created and ordered, this is the first version of the PO. And this PO is sent to the backend and output is sent to
the vendor.
Now when you make a change and hold it, SRM creates the 2ndversion of this PO. Then when you delete this PO, SRM marks this 2nd
version of PO to closed. Also you receive the pop-op confirmation that PO was deleted at this point. However, this PO deletion is never sent to the backend and output is not sent to the vendor since this PO has never been ordered. This version is the Change Version. This is shown after the PO number field if you pay attention on the screen.
When you search for the PO, it will show you the ordered PO (No change version shown after the PO number). The system does not show you the deleted version which is version 2. That is why you see status is 'ordered'.

Freight charges in PO at header level

Hi Friends,
I have created a PO having 10 line items. I dont have individual freight charges for each line item.I have total freight charges for the whole PO. I have defines a freight charge at header level.I want the system should devide the whole freight charges among the line items as per the value. But when I enter any value in the header freight condition type, its simply multiplying the freight by 10. The system is not dividing the freight charges amonth the line items as per their valuation.
Please guide me and suggest how to do the settings in customization so that system should divide the freight charges as per line item value.
Thanks & Regards
Satya

HI,
Go to M/06.select the frieght condition type and tick the group condition indicator and Group condition routine as 1 Overall document .and then enter condition value at header level in PO.
reward if helpful.
Regards,
Chetan.

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'.

Attachments at header level from SRM BI/BID to ECC PO

Hello All,
Our landscape is SRM 5.0sp09 & backend ECC 6.0.
SRM tech scenario - CLASSIC
SRM business scenario - Sourcing with Bid Invitation
We have set up DMS in ECC and are now able to transfer item level attachments from SRM BI and BID to ECC follow-on PO.
Our customer desires header level attachments since they want to avoid DMS maintainance.
We have checked this with sap OSS and the responce was---
this is a limitation/desired behavior. SRM is not
passing the attachments as the same cannot be viewed at header level in
PO(as indicated by you). Hence only the item level attachments are
passed. I am not sure if the same is taken care in SRM 6.0.
Our customer is still insisting for header level attachments.
Can anybody give relevant inputs?
BR
Dinesh

Hi Dinesh,
I am not sure about the exact technical details of the same. But i just know that SRM50 will not support this functionality. Sorry that i am not able to help you in this regard
Hope we will get some other reply here....
Thanks & Best Regards
Raj

If you enter a WBS at header level can it be copied down to the item lines?

We have sales orders which require a WBS to be entered at header level (PS-POSID), and then on order save (VA01), it copies the WBS elements down to the item lines.
Has anyone come across this requirement before and if so, how did you do it?
Is anyone aware of an OSS for this or is it a development?
Thanks!
Rochelle

Hello Rochelle,
Could you please check to see if the sales order item has the consumption posting indicator VBAP-KZVBR = 'P' (transaction OVZG)? If so then this seems to be the correct system behaviour.
This is the relevant coding:
Bedarfsdaten ermitteln
     perform vbap_fuellen_t459k.
Transport Hpos - Upos braucht KZVBR wegen Kontierungvorschlag
     perform vbap_fuellen_hvbap.
if vbap-kzvbr = kzvbr_p and
        vbap-ps_psp_pnr is initial.
       vbap-ps_psp_pnr = vbak-ps_psp_pnr.
     endif.
Also consulting note 459734 may be helpful.
I hope this helps.
Best regards,
Ian Kehoe

PO Delivery tolerance at header level

Hello Gurus,
My client wants to have delivery tolerance at header level which means while doing GR system should accept over delivery for the total qualtities of all line items of a singel PO. Please let me know how this can be achieved?
Srinag

Underdelivery and overdelivery tolerances in purchase orders
You can change underdelivery and overdelivery tolerances in purchase orders at material level and at SKU level. As long as you have entered tolerances in the purchasing info record, the system will copy them as default values to purchase orders. Changes in underdelivery and overdelivery tolerances in purchase orders are made according to the following logic:
In order to change underdelivery and overdelivery tolerances at material level, enter the values that have been changed for an item in the detail view in the fields Underdel. tol. and Overdeliv. tol. If you change the tolerance values at material level, all the SKU default values that were copied from the purchasing info record to the purchase order without manual processing will be adjusted to the new percentage.
To change underdelivery and overdelivery tolerances at SKU level, enter the changed values of the appropriate SKU in the detail screen ( in the standard toolbar to the right of the table view). With the confirmation of your changes the system sets the indicator MT (manually set tolerances), which prevents this SKU tolerance value from being overwritten by a material tolerance value. Manually changed values at SKU level therefore remain unaffected by changes at material level.
PO Delivery tolerance at header level ,you have to make some alternate arrangment i.e. through user exit

Condition at Header Level

Dear all,
Following is my requirement.
My condition (ZPPV)is at both header& item level (In M/06, header & item level condition check boxes are ticked).
My client requirement is if at header level, I enter condition amount say $ 50 & that perticular purchase order is having 7 line items, $50 should get equally divided to each line item i.e.( 50/7= $7.14).
Please tell me which setting should I do for it?
Best Regards,
Shailendra
Edited by: Shailendra Sabale on Jun 15, 2010 4:03 PM

Hi,
In M/06 you select the group condition indicator for your condition type.
Cheers,
Satish Purandare

TO ADD TAB AT HEADER LEVEL IN ME21N

Hi guys
I have to add a tab at header level of ME21N using BADI ME_GUI_PO_CUST and ME_PROCESS_PO_CUST
can someone guide me how to do this?
Thanks

Hi,
Try with SMOD enhancement MM06E005. I know this works well for adding a tab in PO header or item level . Read OSS 407975 for implementing this screen exit
here i am pasting OSS Notes and if you need clearly then login into service.sap.com
Symptom
You are using SAP customer enhancement MM06E005. There is no sample source code for this enhancement.
Other terms
User exit, customer enhancement, MM06E005, example, sample
Reason and Prerequisites
You want to activate user exit MM06E005. Note that this is a consulting note and not a correction of the user exit.
Solution
You can use the sample source code attached here to recognize the basic functions of the exit. This example is, however, only one of many options that are offered by the customer enhancement.
The sample source code includes the following functions:
Supply of an additional field on header level
Supply of an additional field on item level
Derivation of a field on item level from the copied reference document
Now, in order to be able to use the sample source code, you must create field ZZFLAG on the header level of the document and field ZZFIELD on the item level.
Double-click on Include table CI_EKKODB
Enter the following values:
Name    Component type DType Length DecPlace Short text
ZZFLAG CHAR1          CHAR 1      0        1-digit indicator
Save and activate the include table.
Double-click on Include table CI_EKPODB
Enter the following values:
Name    Component type DType Length DecPlace Short Text
ZZFIELD CHAR1          CHAR 1      0        1-digit indicator
Save and activate the include table.
In order to activate the sample source code, you additionally have to carry out the following changes on screens 0101 and 0111.
1. Screen 0101: Create the following fields:
              "Checkbox"            Name: EKKO_CI-ZZFLAG
2. Screen 0111: Create the following fields:
              "Input/output field" Name: EKPO_CI-ZZFIELD
              "Pushbutton"          Name: BUTTON
                                    FctCode: ZZDETERMINE
The following assignments apply to the sample source code:
EXIT_SAPMM06E_006 --> LXM06F36
EXIT_SAPMM06E_007 --> LXM06F38
EXIT_SAPMM06E_008 --> LXM06F37
EXIT_SAPMM06E_009 --> LXM06F39
EXIT_SAPMM06E_016 --> LXM06F41
EXIT_SAPMM06E_017 --> LXM06F42
EXIT_SAPMM06E_018 --> LXM06F40
Copy the source code from the attachment and insert it into the corresponding function modules. Save and activate the function modules.
Create the following variables in the corresponding TOP include in order not to get any syntax errors:
INCLUDE ZXM06TOP
data: gl_aktyp type c,
      gl_no_screen type c,
      gl_rekko like ekko,
      gl_ekko_ci like ekko_ci,
      gl_ekpo_ci like ekpo_ci,
      gl_ekpo like ekpo,
      gl_ucomm like sy-ucomm.
types: begin of ekpo_tab,
          ebeln like ekpo-ebeln,
          ebelp like ekpo-ebelp,
          ekpo like ekpo,
       end of ekpo_tab.
data: gt_ref_ekpo_tab type table of ekpo_tab.
Save and activate the TOP include.
On header level, you can now store a character, X or space, via field ZZFLAG on the database with the document and read it also again.
On item level, you can fill field ZZFIELD with a one-digit value and save it with the document. If you copy this document, the system displays an additional function button on tab page "Customer data". If you press this button, the value of the reference document is copied to field ZZFIELD.
If you want to store the source code as sample source code in your system, start Transaction SMOD. Enter MM06E005 as an enhancement. Select "Components". Press "Change". Position the cursor on the corresponding module and choose "Sample code". Create the corresponding include and copy the source code from the note. Save the include. Note that, of course, syntax errors may occur when you check components. This is because the includes of the sample code are not integrated into a program but rather are completely independent and, therefore, do not have any relationship to each other either. For this reason, only save the include and do not activate or check it. The sample code has to be copied into the corresponding function modules in order to become active.
If you use the user exit in the new purchase order, it is not guaranteed that the customer screen is always processed. To make sure that possible required fields are checked, include a corresponding message into the EXIT_SAPMM06E_012. This screen is always processed.
Header Data
Release Status: Released for Customer
Released on: 07.09.2006 13:07:34
Priority: Recommendations/additional info
Category: Consulting
Primary Component: MM-PUR-PO Purchase Orders
Secondary Components: MM-PUR-GF-CE Customer Enhancements
I have not done BADI for PO,so i am not sure that whether BADI will work for Screen exit or not
Thanks
Seshu

PO Close Indicator at header Level

Similar Messages

Maybe you are looking for