Don't heading levels convert to TOC?

I just upgraded to RH7 from RH5. I'm on XP Pro 2002 SP 2, RH
for Word v 7.0 Build 145. I've got a Word file I'm converting to
FlashHelp. The word file has headings H1 H2 H3 tagged. I swear, in
RH5 (it's been a while) when I imported, the topics broke at the
headings and arranged themselves according to heading level; the
TOC was indented to three levels where necessary and followed the
chronological order of content in the Word file. Now in RH7 all the
topics come in and don't appear in the TOC indented according to
heading level. Was I hallucinating? I'd check RH5 myself but it no
longer works on my cptr and Adobe won't support it. Last, I can't
get the TOC to keep my topics in chronological order. My section A
has only one level; my section B has three levels, etc and RH wants
to put all the single-level topics together. Is there a way I can
get my conversion and my TOC to behave the way I swear it behaved
in RH5?

You either use
the Export PDF function in the Tools panel on Adobe Reader
do the conversion online after signing in to the https://cloud.acrobat.com/exportpdf site
[topic moved to ExportPDF forum]

Similar Messages

Rounding Up to be done at Header Level.

Hi experts,
I want to carry out rounding up at header level where there will be a multiple line items.
E.G. Condition type JEXP (BED) is a item condition . There are two line items in a sales order and duty applied is Rs. 1.40 per item. Now system is carrying out rounding up at item level i.e. Rs. 1.40 is taken as Rs. 1per line item and total duty becomes Rs. 2 . Instead it should be Rs. 2.80(Rs. 1.40 per item) and after rounding up it should be Rs. 3. Same rounding should be carried out for all condition type.
Please guide on the same.
Regards ,
Pallavi

Hello,
You cannot do Rounding-up at Header level for Item level conditions.
If you have Header Conditions, you can do Rounding at Header Level.
What you can do is setting Rounding for your Condition Type at Item Level (by Rounding Rule in Condition Defination) & also by applying a Routine 13.
Hope this helps,
Thanks,
Jignesh Mehta

Heading 1 level missing from TOC?

I have this little RH 7 sample project.
When converting to PDF using 'Printed Documentation Wizard',
the primary Heading 1 level is NOT included in the MS Word/PDF
'Table of Contents'.
I'm not using any MS Word templates, just the project's CSS
styles.
Arcrobat PDFMaker settings in MS Word are set to default and
include Heading 1-9.
I've searched and searched but I don't know how to include
this Heading 1 level in the TOC.
When checking the MS Word 2003 document through Insert
>> Reference >> Index and Tables, the Heading 1 level
is missing from the tab 'Table of Contents'.
When adding the Heading 1 level there through 'Options'
button, the TOC updates correctly, but I don't know how to include
this Heading 1 level through RH.
Sample project
here
A note on the sample project:
You'll see that every topic title associated with TOC book is
excluded from PDF through conditional build tags.
This was done so prevent titles from being printed twice in
PDF.
For example, in the TOC there's an item titled 'Balance
sheet', the associated topic Balance_sheet.htm has exactly the same
title 'Balance sheet'.
To prevent this title from being printed twice in PDF, the
topic title was excluded through conditional build tag.
Any help would be appreciated.
Best regards,
Herman

> > Are you sure the print layout is 100% the same on
both PCs, particularly the Build Expression?
> I'll check again this evening when I have access to the
other PC.
I took a copy of the project on the rogue machine, copied it
to the second machine, ran the printed documentation wizard and
checked the settings. The result is as expected. I get the TOC with
the correct headings, the second one in my PDF.
In the meantime I've also compiled the printed documentation
on a third PC (with XP + PDF plugin that comes with RoboHelp). The
result is the wrong TOC, the first one in my PDF.
> Try generating on the rogue machine to just Word, not
the PDF. When the document opens in Word instead of reinserting the
TOC, right click to the right of the TOC and select Update Field.
Does that correct it?
I'll try that tomorrow when I have access to that PC.
Very weird.
Thanks again Peter.
Herman

Heading level hierarchy errors when topics are in TOC more than once

I have discovered that the hierarchy in the Heading levels in
the Printed Documentation will differ from than in my online help
table of contents hierarchy, and that the problem is due to topics
that are intentionally in the TOC more than once.
For example, in chapter 5 of a particular help system the
hierarchy should be:
Heading 1 < Chapter 5 title from top-level book>
Heading 2 <title of second level book>
Heading 3 <title of topic that appears under second-level
book>*
What I actually get is:
Heading 1 < Chapter title from top-level book>
Heading 2 <title of second level book>
Heading 4 <title of topic that appears under second-level
book>*
* This same topic appeared in an earlier chapter. In that
chapter it was really at a Heading 4 level.
Due to company styles, etc. we use a numbering system at the
headings and in the TOC, so instead of
5
5.1
5.1.1
I erroneously get
5
5.1
5.1.1.1
This type of hierarchy issue appears multiple times in this
particular document (which I inherited by the way.)
Other than restructuring the document to not reuse topics in
different places in the TOC, is there a solution or a workaround
for this problem?
What I am doing so far, is generating the Print Documentation
one chapter at a time. As long as a topic is not reused with the
same chapter, my hierarchy of heading levels is maintained;
otherwise, it is not. Then I can put the chapters back together
after fixing the few places that still have heading level problems.
This however, will be quite cumbersome as this document is
translated into nine other languages.
I am using RoboHelp X5 for Word / Word 2003 for the source
and most of the translations; RoboHelp Asian Edition, Simplified
Chinese / Word 2003 for the Chinese translation. The heading level
hierarchy error occurs in both versions.

>> AF: I've commented in sections...
Without Maintain Heading Levels, RH will apply heading levels
to the books and then the topic levels will get bumped down. So a
top level book will be Heading 1 and the Headings in the topic will
get bumped down to 2, 3 and 4 etc. If then you have another book
one level down so that it gets Heading 2 applied, the same topic
but under the level two book would then get 3, 4 and 5 applied.
That is not the original problem but hopefully we are agreed
that is how things work on that.
>> Yes - that is the expected behavior. When it didn't
happen as expected, that's what led me to the discovery of the
cause of the problem (topic reuse).
Your problem was that firstly Heading 3 got bumped to Heading
4 if the same topic was inserted into the TOC twice. I assume it
was OK in the first instance, or is it that when you add it twice
it goes wrong everywhere?
>> Your assumption is correct. First occurrence is
correct. Second, third, and fourth (yes - there is one topic that
is used 4 times! ) are not correct based on TOC hierarchy.
On the numbering, nothing surprises me. If you look at my
site you will see that for RH HTML, i gave up on getting it right.
I have had many queries on this and more than a few people have
indicated they will work on the problem and get it working. I'm
still waiting. There are many posts about outline numbering
problems. Has anyone got it working satisfactorily?
>> I don't really have numbering problems. The
numbering is following the RoboHelp-generated hierarchy and the
.dot template that I apply. It's just that the RH-generated
hierarchy and its heading levels don't correspond to the "real"
hierarchy because of the reuse issue.
I have seen various Word gurus maintain that numbering has
not worked entirely satisfactorily since Word 2! Also enough posts
to convince me this is a Word issue, not a RH issue.
If you want to create a new project and knock something up
that demonstrates this problem, by all means zip it up and send it.
I'll assume it will be a small project and zip to less than 5mb. If
more, contact me first.
>> Unless you have RoboHelp X3 Asian Edition,
Simplified Chinese, there is really no need. I plan to either avoid
the reuse issue in the source, or build the print doc in sections
which is easy enough in RoboHelp X5 for the non-Chinese languages.
It is in the older Asian edition where the problems are compounded
by the omitted reuse topics. If you do have RoboHelp X3 Asian
Edition, Simplified Chinese and want to experiment, I can send you
a cut-down version of the project. Don't feel obligated though;
unless you can read Chinese (I can't) it is very tedious to work
with.

Down Payment Request at Header Level of PO

Dear Friends
We want to create Down Payment Request and subsequently the Down Payment at Purchase Order Header Level. We are looking for a standard solution without any Custom Development.
While creating a Down Payment Request (F-47) the system does not ask for the reference of the Purchase Order. But if Purchase Order Number is referred then the system will ask for the line item also.
When we convert this Down Payment Request to Down Payment (F-48), we can refer the Purchase Order Number. If referred, the system asks for the line item also, which becomes mandatory.
However we want to understand if there is a possibility of posting the Down Payment against the Purchase Order Header.
This is required, since if there are multiple line items in the purchase order, then creation of Down Payment Request as well as Down Payment becomes a tedious activity in SAP.
Someone innovative and has already worked on such requirement please reply.
Regards
Ketan Patel

Hi,
Try the following steps to pay to Vendor w.r.t PO:
1.Check the Vendor reconciliation A/C,
2.Go to FS00, and check Filed Status Group,
3.Go to OBC4, check the Filed Status Group, what u have mentioned for the Vendor reconciliation account.
4. Go To material management segment and put optional entry for the field of Purchase Order and save.
5.Now come to F-48, enter the date, vendor, assign the sp.G/L transaction(A),bank sub account, amount,
then enter, it will take to next screen
Here you enter amount & your purchase order number with reference to your are going to make the payment. Now simulate and save.
After the GR & IR is done, Perform F-54 for Down Payment Clearing
Regards,
Biju K

Levels in the TOC?

How many numbering levels are supported in the TOC?
In portrait author mode I can see my TOC taking shape as I add Chapters, Sections, and Headings. Within a Section I now have several TOC entries which I have defined with Heading 1, and these are listed with numbers such as 2.3, 2.4, 2.5 etc where the 2 is the Section and the .3, .4, and .5 are the paragraphs delineated by headings. But can I create TOC entries as 2.3.1; 2.3.2; 2.3.3? I don't seem to be able to do so, though I can create indented paragraphs and bulleted lists, and headings defined as Heading 1 or Heading 2 style - however each heading is listed in the TOC as though it were at the same level of indent (for numbering purposes) as every other...
For a well-formatted TOC I need more levels than appears to be supported. Is there any way to achieve this?
ps: Apple - a proper manual would be nice... I lost a week on this project because the TOC behaves differently in landscape and portrait modes, and landscape is the default so the TOC appeared not to work as described. I even reported it as a bug, though of course feedback just disappears into a black hole... Really, Apple, there is no substitute for a good manual - achieving reasonable productivity depends on it...

It appears to be impossible to do what you want. While you can add any paragraph style to the TOC, there is no way to specify at what level that style should appear. So, if you add Heading1, Heading2, Heading3, Heading4, they all appear at the same single heading level underneath the chapter level, which is useless, of course.
Michi.

How to preserve Heading levels

Hii,
Is there any method by which we can preserve the heading
levels of the topics. I mean, presently all the headings from my
word document get converted into a different topic, irrespective of
their level (heading1, heading2, heading3, etc.) I want that all
the headings below level 1 be treated as the part of the same topic
yet they show up in the table of contents (while auto creating the
TOC). I hope you get me..

System Administration>Support>Version is one way.
Should display your version as 6.0.2.2.0 depending on what service pack, patch, and hotfix you are on.

Purchase Order Total Amount at Header level and Report Execution

Dear Experts,
Here by i am facing problem with Purchase Order Total amount.
I have local Pricing Procedure for price stipulations (like discounts, Freight, packaging). the calculation at item level is correct. tax calculation is done by tax code. The total PO Price is including all items in PO and tax amount. But at header level conditions net value is showing only gross price.
How to pick up total price including tax amount at header level conditions?
Please provide me solution on it ?

Dear Experts,
Here by i am facing problem with Purchase Order Total amount.
I have local Pricing Procedure for price stipulations (like discounts, Freight, packaging). the calculation at item level is correct. tax calculation is done by tax code. The total PO Price is including all items in PO and tax amount. But at header level conditions net value is showing only gross price.
How to pick up total price including tax amount at header level conditions?
Please provide me solution on it ?
Edited by: Kiran Mujumdar on Feb 23, 2009 7:08 PM

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.

Delivery address at Item Level and not at the Header Level

Hello Experts,
We are facing an issue as described below:-
We are in SRM 7.0 using classic scenario.
After approval of multi line Shopping Cart in SRM ,PR's are getting
automatically created in backend R/3 system.After converting PR's into
POs in backend R/3,we are observing that the delivery address for these
PO'are getting printed at Item level and not at the Header Level
inspite of the delivery address being same for all the Item level.
As desired,the delivery address in the PO's should have the delivery
address at the header level if the the delivery address is identical
for all the Item Levels.
However,if we create a PR directly in R/3 system and then convert these
PR's into PO's in the backend R/3 system,we find that the deliver
address are getting printed at the Header Level if the delivery address
is same for all the item level(which is as desired)
Any pointers will be highly appreciated.
Thanks & Regards,
RKS

It is standard process only.
In Po delivery address is maintained at item level because to which address perticular material to be delivered,
this may change from material to material or may not change

Price Condition at the Header Level

Dear SAPfans,
Can we set the pricing procedure at the header level of sales order,
i would like to configure the rounding mechanism work on the header condition on the sales order, can it be done thru pricing procedure ?

Hi,
You can make condition type either header or item level.
header level coniditon type doesnt have access sequence and you generally enter the value manually.
You can use this condition type in Pricing procedure.
Check all about Condition type in V/06
Hope this will help.
Reward Point if helpful.
Thanks,
Raja

Release of PO at header level

why is that we release PR at "ITEM" leval and PO at "HEADER" level ???
is that because PO is been created with reference to a specific vendor so we do it in the header level
in PR we issue it for all the materials so it is done at item level
is tht the right explanation or do we have any ?? please help
regards
Pavan

Hi,
PR is an internal document. Suppose if you have 3 line items in a PR you will release 1 line item and PO can be created for the particular line item (PO with reference to PR).
Where in PO is an external document and has to be released at Header level.
Regards,
Nagaraja Achar

Two production orders at the header level one for one single requirement

Hi Gurus, Please provide me your valuable suggestion on the issue.
*Client wants to have a only two production orders at the header level one for one single requirement .*
1) Manufacturing Order u2013 In this order for Finsihed prodcut system should pick all the assemblies whcih are manufactured inside i.e depending on the material type.\
2) Assembly order u2013 In this order system should pick all the assemblies whicih need to be assembled also procured or subcontracted items in this order against depending on the material type.
It means for Sales order of 5 EA there is going to be only 2 order ( MFG & assy order).
For Example.
L45-7000 is the header material now client wants only two production orders one Manufacture order and anothe Assmebly order , thet dont want to use Phantom assembly concept and also multiple production orders for SFG.
Please confirm if this requirement can be mapped in SAP ?
Thanks...

Hi Shishir,
As soon as each order is related to only one material, if your manufactured (or purchased) assemblies are of different materials, you will have a separate order for each material rather than a single order for all manufactured assemblies. I don't thing all your assemblies are of the same material - thus I would say no, it is not possible to map your requirement.
Regards,
Sergiy

Custom field at Header level in Additional Data B tab of VA01/VA02

Kindly help me out , I have a requirement to add a custom field at Header level in Additional Data B tab of VA01/VA02.
Program: SAPMV45A
screen 8459
This can be done only through access key or not. Can any body tell me procedure to do that.
Appreciate your response.Thanks in advance

Please help me out this

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

Don't heading levels convert to TOC?

Similar Messages

Maybe you are looking for