cancel
Showing results for 
Search instead for 
Did you mean: 

Derivation of Sales Employee into COPA

Former Member
0 Kudos

Hi everyone,

Right now, we are trying to add the sales employee into COPA report.

The SD maintained the "partner function" sales employee in the Sales Order, in which can be input by Header --> Partner.

I have added the characteristics "sales employee" (KMVTNR) into the report, but the sales employee inputted in the SO can't flow into COPA Report. I did not maintain anything else regarding this characteristic and its derivation.

While trying to maintain the characteristics KMVTNR, the system issue this following error:

*Characteristic KMVTNR has no check table (or check table is T242B)

Message no. K6392

Diagnosis

Characteristic 'KMVTNR' does not have a check table, or the character- istic is an old one (Release 2.1) with check table T242B.

System Response

No attributes can be maintained for this characteristic.*

Are there some other steps i am missing?

Any kinds of help is really appreciated.

Thank you all in advance.

Regards, Erwin

Edited by: Erwin Hartono on Oct 26, 2010 2:43 PM

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Maintain the characteristic with origin table 'PAPARTNER' and origin field 'VRTNR' in transaction KEA5. This should automatically derive 'sales employee' without any derivation rule.

Check table is not required..

Regards,

Ganesh

Edited by: Venkata Ganesh Perumalla on Oct 26, 2010 9:17 AM

Former Member
0 Kudos

Thank you Venkata,

Will try your suggestion soon.

Can you guide me what other characteristics' origin and check table should i use, if i want to use:

sales order and billing document as characteristic?

I maintained billing doc using data element VBELN_VF, is this the right choice (haven't got the chance to check it yet)

While using the data element VBELN_VA for Sales order.

Thank you in advance

Regards, Erwin

Edited by: Erwin Hartono on Oct 26, 2010 4:52 PM

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

One option is to use PAPARTNER

However, I prefer to use a derivation rule always and there is a little catch in this...

Create 2 derivation rules using table VBPA for the same partner function

1. In one Der Rule, make the sale order item KDPOS as constant value 0000

2. In the other one, dont make it a constant....Leave it as it is

Two rules are required because,

a. the partner function is updated in VBPA table without line item if the same is derived from customer master and not changed in sale order.. In this case line item is 0000 in VBPA table...

b. It updates the table VBPA with line item incase it is changed or entered during Sale order creation...

Regards

Ajay M

PS - Sales order is a fixed char and is always derived in COPA... As far as I know, you can derive billing doc no in COPA... It is populated in the Ref Field of the COPA doc no....

Edited by: Ajay Maheshwari on Oct 27, 2010 12:05 AM

Edited by: Ajay Maheshwari on Oct 27, 2010 12:06 AM

Former Member
0 Kudos

Thank you Ajay

Can you guide me more about referencing the billing document number into characteristics of COPA?

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

If you look at table look up in KEDR - Table VBRP (Billing tables) are not allowed in the list of permitted tables....

THere is some technical issue why this is not allowed.... But I could not recollect it now...

Nevertheless, you can try to populate billing doc no in a WW* char by using Exit COPA0005... You will not be able to use COPA001 because for that you need to write derivation step in KEDR using VBRP, which is not possible

Interestingly, if you achieve this, you will be one of the very few who might have achieved this

Regards

Ajay M

Former Member
0 Kudos

Thank you again, Ajay

You have helped me a lot

I will take a look into the user exit you have mentioned, and i will get back to you on the outcome.

Regards, Erwin

Former Member
0 Kudos

Billing document number is updated in CO-PA documents as reference document (RBELN), this is default system design; you do not need to have billing document again as characteristic and create derivation rules for that. I don't think there is any benefit in doing this exercise, because there is no use in defining this field as segment level characteristic or it won't be of any help in creating summarization levels.

Sales Order and Item number are also referenced by default; these are not required to be created as characteristics.

I would appreciate if you could provide the justification to create 'billing document' as characteristic.

Regards,

Ganesh

Former Member
0 Kudos

Thank you for your reply,

The reason why i had the idea to create billing document as characteristic is because there is a need to be able to see the incentive based on billing document number. Is there a standard way to do this without creating the billing document as characteristic?

While searching for the answer, i have come across many references that mentioned the RBELN. But i am still unable to understand what it means. Can this "reference document RBELN" be included in the COPA reports?

Regards, Erwin

Former Member
0 Kudos

Is there a standard way to do this without creating the billing document as characteristic?

Yes, CO-PA gets the reference billing document by default. It will be available in CO-PA line item, nothing to be done for this. In KE24, you can see the incentive based on billing document number.

Can this "reference document RBELN" be included in the COPA reports?

Field values that are repeated in many documents are characteristics normally. But every CO-PA document will have a unique billing document value. In CO-PA drill down reports, only characteristics can be used as selection criteria. So one should see KE24 to check incentive by billing document.

Regards,

Ganesh

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

As I mentioned in my earlier reply under "Post Script", billing doc is populated as ref field in your COPA doc... But this is not available for drilldown...

If you want it for drilldown - Then include it as a char and follow the steps I mentioned

If you want it for the purposes of incentive calculation - I think you can use some std SD reports.. I am sure there wud be some reports in SD to give you details partner wise...

Or Else, you can prepare ABAP report using Table CE1XXXX and CE3XXXX incase you dont want to define Billing doc as a char

Regards

Ajay M

Former Member
0 Kudos

Thanks to both of you, now i can distinguish between the pros and cons of using "Billing document" as characteristic or not.

One other thing, regarding the " Sales Employee" characteristic. I still have some questions regarding deriving Sales Employee using PAPARTNER. As far i know, the standard SAP system already provided this characteristic, but when i tried to include it in the COPA report, the characteristic is "not assigned"

Actually my problem is solved using a SAP note (32878). Is this the right approach if i were to use the PAPARTNER? Or is there something missing?

I am curious about what Ajay has mentioned earlier, about using the derivation rule, if you could clarify what you meant, that will be a great help.

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

I am not aware of this note.. If it has solved your issue you should go ahead with it.... I think this note pertains to older releases....

What I meant about the derivation rules is this

1. If you choose to derive part func in COPA - You should remember that VBPA is the table

2. VBPA stores the partner info at header level i.e. at Sales order level if the part func are derived from customer master and not touched in SO.. IN this case, the sale order item is always 0000 in VBPA

3. In case the partner info is entered or changed during SO, then partner info is stored in VBPA at Sales order and Item level... i.e. sale order item in this case is 0010 or 0020 as the case may be

hence you need to write 2 der rules... there is also a SAP note which describes this... Unfortunately, I lost the note no....

Regards

Ajay M

Former Member
0 Kudos

It is not entirely correct that RBELN is not available in drill-down reports.

As it is not a characteristic, it won't be available in standard drill-down reports that use the segment level or summarization levels to read the data from.

RBELN is available, however, in line item based COPA drill-down reports. I am using it in those.

Regards

Nikolas

Former Member
0 Kudos

I just realized that the sales employee number is included in the characteristic in COPA report, but the name (text) of the partner function is not included.

I am also using the 'Sales Office' characteristic, while i check in the SO, it is entered, but when i check the COPA Line item using kE24, it is not entered

Can anyone help to solve these issues?

Thank you very much

ajaycwa1981
Active Contributor
0 Kudos

Hi

For the former - You can search OSS notes.. there are notes available on this, as far as I remember

For the later (sales ofc) - Check if Sales Ofc is a segment level char in KEQ3.... If it is not, then sales ofc wont populate in COPA line item

Regards

Ajay M

Former Member
0 Kudos

Hi Ajay,

Found the note

36406, but haven't tried it yet, will try it soon...

I find it weird though, in the note, it said "this problem occurs up to and include release 3.0C). However, as far as i know, we are currently using the newest version (EHP4 if i am not mistaken).

I tried using the Sales Employee characteristic in IDES, all i have to do is just move the characteristic to include it in the operating concern, activate it, and everything works fine. Do you have the same problem with Sales Employee? I mean does it really need these extra efforts?

Meanwhile, about the KEQ3, the Sales Ofc is already maintained as profitability segment characteristic.

The Sales office also contain value (i checked in KES1 under the Reference Characteristic (VKBUR)

As always, Thank you

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

HI Erwin

I never had to invest these extra efforts to get the part func... They have always worked in my case...

if sales ofc is a segment level char - then it shud have populated from billing doc.... Check the derivation rule that you have in place for this...

In case you wish to debug it, follow the steps below

1. Func Module KEDR_COPA_DERIVE

2. set DEBUG-SHOW_TRACE to 'X' in order to get a trace list at the end (I think you do this in SU01)

set DEBUG-BREAK_AT to the step number you want to analyze. The system will stop in the process loop for that step.

Check the step no of your der rule and enter the same here

Regards

Ajay M

Former Member
0 Kudos

Hi Ajay,

Do you mean that you maintained those partner function derivation using the steps u have mentioned earlier? (the one about using 2 derivation rule) Or do you only need to include the 'Sales Employee' into the desired Operating Concern?

if sales ofc is a segment level char - then it shud have populated from billing doc.... Check the derivation rule that you have in place for this...

In my case, it is still in the step of creating Sales Order (record type A), but i think if correctly maintained, it can also be derived into record type A?

Thank you.

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

1. Yes... Include the Sales Emp field in your data structure in KEA0 and write 2 der rules....

2. Yes, it can also be derived from record type A as well

Regards

Ajay M

Former Member
0 Kudos

Hi Ajay.

If you have the time, would you mind guiding me step by step on how you maintain your derivation of "sales employee" partner function? Eq: start with the definition of the characteristic, which derivation rule should be used, etc...

Thank you for your help

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

Time is never a constraint to help those who put own effort 1st

In 1st Der Rule

1. Go to KEDR and click on Create using "Table Look up". Enter table = VBPA

2. SOURCE FIELD

Origin Fields from VBPA-VBELN, POSNR and PARVW

Map VBELN to COPA-KAUFN; POSNR to COPA-KDPOS; and PARVW to GLOBAL-USERTEMP1...

Click on magnifying lens icon beside USERTEMP1 and enter your Part func, say, PE as a constant

3. Assignment of table field to target field

Map VBPA-PERNR to COPA-KMVTNR.... This applies if you have HR module

if you dont have HR, map KUNNR instead of PERNR (because you would have used SD sales employee in that case and maintain the same in customer master)

In the 2nd Derivation rule, follow the same steps as above.... Only exception is

Click on magnifying lens icon beside COPA-KDPOS and enter 0000 as a constant

Regards

Ajay M

Former Member
0 Kudos

Hi Ajay,

I have tried to maintained it like the way you have told me, we are not using HR module, so I tried to find the KUNNR, what characteristic is this? If i can't find this characteristic, should i just use the KMVTNR or should i create a new characteristic instead?

In the GLOBAL-USERTEMP1, i enter 'SE' as the constant, because we are using SE in the Partner in creating SO

I tried it in IDES using a new characteristic (without own value maintenance, let's name it characteristic Test1), i ticked the "issue error if no value found" in the attributes of the derivation rule, but the system gives the following error:

While executing this table lookup, the system could not find an entry for the specified source values in table VBPA.

This derivation step is defined so that an error message is displayed when this occurs.

Table VBPA lacks entries for the following source values:

Sales Order Numb/Item Number in S/Temporary field

13562/10/

Can you please guide me further,

Thank you so much in advance

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

Using KMVTNR or TEST1 wont make a difference, as this is a target field

KUNNR means customer...

may be try to use PERNR instead of KUNNR and check... Map KUNNR or PERNR to KMVTNR

Regards

Ajay M

Former Member
0 Kudos

Hi

Tried using both KUNNR and PERNR, but nothing works,,

I think the problem happens when the system tries to find the partner function during the source field table look up...

The Sales Order / Sales Order Item is populated, but not the Partner function (GLOBAL-USERTEMP1)

Please kindly suggest

Thank you in advance

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

I have successfully used GLOBAL-USERTEMP1 in my system

Another option is to avoid USERTEMP1 and use a WW char instead of USERTEMP1... Say, WW100... In this case, Maintain SE in KES1 for WW100

Also, I assume you have not used USERTEMP1 in any other derivation rule... If you have used, then you must write a der rule using CLEAR to clear its value from the memory....

take a note of the following

1. If you have written 2 derivation rules as I suggested, do not activate the option of issing error message in KEDR as one of the rules will always be unsuccessful.. But yes, it should not be unsuccessful on account of USERTEMP1

2. Can you check in VBPA table if SE is updated or not during Sales Order creation

3. Uncheck the indicator in KEDR and post the document.... Then see in COPA doc if it is populated...

Repeat the steps using KUNNR as well as PERNR

Regards

Ajay M

Former Member
0 Kudos

Hi,

Still got no luck, i have tried creating the SO using PERNR and KUNNR, and unchecked the indicator in the KEDR.

I checked the VBAP during the creation of sales document using SE11, i can see that the SD document is being populated with PERNR instead of KUNNR, and the PARVW field is populated with SE

It is written like this:

VBELN: 2010000114

PARVW: SE

KUNNR: blank

PERNR: 1000005

It is still not being derived into COPA. Now i am sure i have to use the ZE / PERNR and map them to one target characteristic. We are not using GLOBAL-USERTEMP1 anywhere, but i wrote the CLEAR derivation rule also.

Maybe tomorrow i will try it again with the WW*** chars

Thank you for your help, Ajay

Regards, Erwin

Former Member
0 Kudos

Hi all,

Have to revisit this issue again

The Sales Employee number is being derived into COPA, but the description is not.

Actually, the sales employee is able to be derived using the OSS note 36557, I did not manage to derive it using the "normal configuration way"

I checked the VBPA table, it is populated with the sales employee data, but the KE24 is not, so i think the problem must be in the derivation rule.

Below data is populated with VBPA:

- VBELN : 2010100035

- POSNR : 000000

- PARVW : ZE

- PERNR : 10000014

The sales employee is created using the transaction VPE1 (as far as i know this is the HR tcode, which i think won't effect the derivation, because it will be read from VBPA anyway)

Suppose that i don't want to use that OSS, but want to derive it using the "normal" way, is there any way i can do?

The Characteristic used is the KMVTNR with origin table PAPARTNER and origin field VRTNR.

Please kindly help

Any help is greatly appreciated.

Thank you

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

Section 2 of the note 36557 describes how customer defined partner functions are to be fetched... It lays down a series of steps to be followed...

Well, I always used the approach of derivation rules which I mentioned in my earlier replies... Two derivation rules where in SAles Item is made constant in one of the rules

I used a Custom defined Char WW without own value maintenance so that the value from SD is fetched into COPA.... Also used KMVTNR in one of the clients...

You can try by writing a derivation rule now..

Source Fields

VBPA - VBELN = COPA-KAUFN

VBPA - POSNR = COPA-KDPOS (make this as Constant 0000 in one der rule)

VBPA - PARVW = GLOBAL-USERTEMP1 (Constant ZE)

Target Fields

VBPA-PERNR = COPA-KMVTNR (OR) VBPA-KUNNR = COPA-KMVTNR

Regards

Ajay M

Former Member
0 Kudos

Hi Ajay,

The derivation rule does work.

When i tried to check the derivation using the "Test" function in KEDR, i enter the sales order number and the sales employee is populated. But when i run ke24, it is not there. What can possibly be the cause?

And during the test function in KEDR, the sales employee number is populated, but no description

Thank you very much for your help

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

May be you should try with a WW char "without own value maintenance"

Regards

Ajay M

Former Member
0 Kudos

Hi

Tried it with both WW001 chars (without own value maintenance) and with KMVTNR, both are derived in KEDR

I analyzed the derivation, the statement says that "derivation carried out" and i can see that the content after is populated with the sales employee number.

And yet, when i check KE24, nothing is in the sales employee field

Any ideas where to check ?

Thank you so much in advance

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi Erwin

As far as my understanding goes, you have 2 choices now

1. To try a WW* char with own value maintenance, Where by you would be required to maintain Sales Employee in KES1

2. Implement section 2 of your note 36557 which talks about how to populate sales employee texts

I think you should go in KEA5 and check KMVTNR.. I guess the Check table would be blank.. Is it so? If yes, then you should follow section 2 of the note

Regards

Ajay M

Former Member
0 Kudos

Hi

Hm...tried that one also (the chars with own value maintenance).

The conclusions of my testings so far:

- WW001 (own value maintenance) : in the derivation test in KEDR, the number and text are derived

- WW002 (without own value maintenance) : in the derivation test in KEDR, only number exists, no text

- KMVTNR : the sales employee in populated with number only, no text

All of those three steps don't update the KE24, i always create a new SO after i change these settings.

While in KEDR testing, the field is populated, but after creating the new SO and look it up in KE24, nothing is in the employee field, even the number does not exist, so i think there must be another problem which stops the derivation.

What do u suggest?

Thank you very much

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

1. Write 2 derivation rules as I suggested i.e. making POSNR constant 0000 in one der rule

2. In the tab Attribbutes, check the option of issuing error message so that you will come to know whats the error

Regards

Ajay M

Former Member
0 Kudos

Hi

Did like what you suggested.

The following error occured:

Diagnosis

Table VBPA lacks entries for the following source values:

Sales Order Numb/Item Number in S/Temporary field

13584/10/

Procedure

Make an entry in table VBPA for the specified source values.

If you do not want derivation to be performed in every instance, change the derivation step so that no error message is displayed if no entry exists.

So, i guess the temporary field is missing?

Thank you

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

Yes, seems so...

Check Table VBPA.. I am sure the Partner Func Type ZE would be existing there..

I have myself used the temp field and it has populated with the part func type..

Also, check the attributes of the derivation step.. Click on the magnifying lens beside USERTEMP1 and see if the attributes you specified are correct... Also, see if you have typed some extra space or some thing like that..

If all this does not work, then use a WW* char for the part func type also instead of TEMP field...

Regards

Ajay M

Former Member
0 Kudos

Hi,

Checked that VBPA table, well, the ZE is there when i enter the VBELN

In the attributes for USERTEMP1, it is already correct, it is entered with ZE

Tried changing that USERTEMP1 with WW* chars, but still, the effect is the same

During test (F8) in KEDR, it is derived, but not transferred to COPA actual line items (KE24)

I find this to be weird, because i checked the other derivation rule also, but no derivation rules that CLEAR or MOVE this KMVTNR. Then agian, why is it looking for the USERTEMP during that previous error? Shouldn't it has been populated with constant ZE according to derivation rule?

Again, thank you so much for your time and help

I really appreciate it

Thank you

Regards, Erwin

ajaycwa1981
Active Contributor
0 Kudos

Hi

I am equally surprised as you... If it is successfully simulated in TEST (F8), the same behaviour should be replicated during actual update as well..

I forgot to tell you, if you have written two der rules as I suggested, then you should not check "Issue error msg" in the attributes section... Because, one of these rules will always fail with respect to POSNR

But, why the constant ZE is not being supplied, is really bugging me

Use Function module KEDR_COPA_DERIVE... (SE37).. Put a break point here and check during actual update why is the constant not being supplied.. Sit with your ABAPer....

Debugging this func module needs a special care... Once you go inside it in SE37, CTRL+F and find the text "DEBUG-SHOW_TRACE".... Here, it is written how to debug this func module....

At the parameter DEBUG-BREAK_AT, you will have to specify your Der Rule Step No as 0034 if your derivation rule no is 34... It will exactly stop at this der rule during sales order creation

Regards

Ajay M

Former Member
0 Kudos

Hi,

Sorry for the late reply, I will try this soon and get back to you later

Thank you very much

Regards, Erwin

0 Kudos

Hi,

I think (as far as in SAP ECC 6.0):

1. The error is not because of missing "temporary field".

2. The right time when saving sales order & SAP [ECC 6] call your Char. Derivation step, right "then" the data of VBPA for this sales order is not still existent => So the comparison failed as in VBPA - COPA fields: that's the meaning of:

.. "Table VBPA lacks entries for the following source values:

.. Sales Order Numb/Item Number in S/Temporary field ..."

3. Even if in case you test your Char. Derivation step by KEDR test [F8] or Valuation Simulation COPA [KE21S], the result still show the correct logic in Char. Derv. => But it gives error in saving your SO.

Regards, Thang TD

Answers (0)