12-30-2014 7:18 AM
Hi,
I am trying to extend a Purchasing Info record(PIR) to new Plant using the message type: INFREC, Idoc type: INFREC01 which use the function module IDOC_INPUT_INFREC. Though the PIR gets extended to the new plant, the price (EINE-NETPR) is updated as zero.
This I feel is due to a bug in the standard code. Below is the flow of the code which explains why this can be a bug.
IF kond_copy_preis NE space OR kond_copy_sonst NE space.
*--- Parameter bis auf Konditionsart setzen --------------------------*
eine-werks = retwerks.
PERFORM kond_parameter_setzen.
PERFORM kotabnr_setzen USING komg
space
CHANGING vake-kotabnr.
CLEAR eine-werks.
PERFORM kond_parameter_setzen_refr USING space.
ENDIF.
6. Next in the routine: CALL_KOND_TO_KOND_COPY, function module: 'RV_COND_TO_COND_COPY' is called. Inside this FM , the access program is determined for 018 since WERKS is blank. So, the select happens on A018 instead of A017. Even though the condition records do exist in A017 , because the select is on A018, the select fails and error E102 (Exception: NO_COPY_RECORD) is thrown and control immediately exits the FM. But in the call of the FM RV_COND_TO_COND_COPY, the SUBRC value is set to 0 for EXCEPTIONS - OTHERS. Is this correct ? Because of this SY-SUBRC value, the routine : "info_kond_preis_uebernahme" is called, in which VAKE-DATAB and VAKE-DATBI are checked if they are filled. If they are not, then EINE-NETPR, EINE-EFFPR are set to 0.
7. I tried changing KOTABNR to 017 in debugger in the function module: 'RV_COND_TO_COND_COPY' , then condition records created for the Material Info record(Plant-specific) got picked , but even then DATAB and DATBI in VAKE are still blank.
Could someone please let me know, whether there are any Notes to fix this issue ? Or let me know if I am doing something wrong ? I have checked for Notes but could not find any.
To recap: I need to extend already created Purchasing Info record to new Plant, and also update EINE-NETPR using message type: INFREC.
Thanks a lot.
01-05-2015 6:58 AM
Nice technical explanation but I somehow feel some basic logic is missing.
You extend the info record to a new plant, which means a new level of information.
How can you expect that this level gets a price from condition records?
Condition records are dependent data, they cannot exist before the info record at this level exists, hence you can't have a price based on info records, prices are to be loaded with COND_A Idoc.
01-05-2015 6:58 AM
Nice technical explanation but I somehow feel some basic logic is missing.
You extend the info record to a new plant, which means a new level of information.
How can you expect that this level gets a price from condition records?
Condition records are dependent data, they cannot exist before the info record at this level exists, hence you can't have a price based on info records, prices are to be loaded with COND_A Idoc.
01-05-2015 7:54 AM
Hi Jurgen,
Thanks for your response.
I am not expecting the price in the Info record to be updated from Condition record. I was just trying to say that I tried by creating condition records first and even then the Info record price for the newly extended plant was zero.
I am populating the Info record Price in the Idoc itself. But it gets cleared due to the technical logic I have explained above.
I went through your blogs, but could not find the issue I am facing in them.
Could you please try extending the Info record to a new plant in your system and check if Price gets updated as 0 or not. If it does get updated as 0, please tell me how to fix this issue.
Thanks a lot.
01-05-2015 12:58 PM
01-05-2015 1:06 PM
Can you go to the conditions from your extended info record?
I am just asking this to make sure that the information matches and system is able to find the condition from within the info record.
If yes, then run RM06INP0 and see if the info record price gets updated from the conditions
01-05-2015 1:49 PM
If condition record exists for the new plant, then when we click on 'conditions' button, the condition price is displayed. In this case, if I run the program RM06INP0, then the price from condition record is also getting copied to the info record.
But in my case, the condition records will not always exist for the extended plant, and in the case they dont exist, when we click on the 'Conditions' button, nothing is displayed, so price cannot be copied from condition record to info record using the program mentioned.
Please give some suggestion on what should be done in the above case.
Thanks a lot..
01-05-2015 1:56 PM
Sorry, now you lost me.
if you had loaded conditions and you could get the price update with RM06INP0 where is then the problem?
If you have not loaded the conditions, from where do you expect the price to come?
01-05-2015 6:50 PM
I understand what you are trying to say. This confusion arose because the IDOC_INPUT_INFREC is just updating EINA - EINE tables, but not A017 (Condition record price). When we create the Info record from ME11, automatically even A017 table gets updated along with EINA-EINE tables.
But why does A017 not get updated using IDOC_INPUT_INFREC ? When we use this idoc, do we need to explicitly use 'IDOC_INPUT_COND_A' to create the condition records ?
Please clarify.
Thank you..
01-05-2015 8:04 PM
Yes, INFREC Idoc cares about EINA and EINE and a bit long text, COND_A about A017 or A018 etc plus KONH, KONP, KOMG etc.
IDOCs are pretty much table oriented, already from the names in the IDOC structure you often can conclude about the tables which are updated.
01-30-2015 5:51 AM
Jurgen,
Thanks for your response.
I have another question. When creating or updating Info records from ME11 or ME12, SAP does not allow multiple vendors for a Material to have the Regular Vendor flag checked.
However when creating the info record via Idoc, I am able to set Regular vendor flag for multiple vendors. Does Idoc not handle this functionality ?
01-30-2015 6:13 AM
I don't know.
if the behavior is different then I would think of opening a ticket.
However, you must not forget that this IDOC is meant for ALE distribution and not really for data loads. (OSS note 327090 ). So the original data must have been maintained manually where you could not create this kind of situation, hence it is not really needed to check it in ALE distribution.
01-30-2015 6:28 AM