Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

fd32 limiting changes made.

Former Member
0 Kudos

Is there a way to give users the ability to change all fields within this transaction except the credit limit field. Or is there another transaction that would act in this manner. I have tried fd33.

Thank you all

6 REPLIES 6

Former Member
0 Kudos

Hi,

This has objects starting with F_KNKA_AEN F_KNKA_KKB F_KNKA_MAN & Few others thats is accountable for controling the ' credit management"..

You will now need to go into these objects ( search for these in the PFCG > Change authorizations>binoclours ..type in these names ) and then see what possible values they can have. then tailor it accordingly !

Thanks

0 Kudos

or use su21 to look for the description and possible entries of the objects

0 Kudos

I have modified all those fields to display or used variations and it basically gives me all or nothing screens to modify. But I found the object F_KNKA_AEN which is Credit Management Change Authorization for Certain Fields, Does this need to be configured, or how does one create field groups. Does anyone know an alternative transaction.

Much Thanks

0 Kudos

Authorization objects which control groups for authorization checks in general require a declaration of the available groups and the value of a group maintained in customizing, in this case on the fields you want to protect.

Ask your functional consultant to look in the IMG (tcode SPRO, S&D, Basic Functions, Credit Management, CM Control... (somewhere there).

As they are generally optional (until declared and maintained), you might want to consider making such fields mandatory for the master record maintenance (SPRO... field layouts...)

There are also other customizing dependencies... for example, if the customer is not assigned to a risk class for the automatic credit check, then the credit limit value is meaningless except for the checks when processing the sales order - which again can be customized to be an error (cannot process the order), a warning (which can be accepted) or blocking only the delivery (processing continues but delivery not executed until the credit standing is changed or accounts recievables are reduced.

A usefull "trick" for finding customizing transactions is to search in table TCTCP for the name of the table in the "parameter" string. Try KNKK or KNKA or something close to those.

Of course, finding a different transaction which generically does a "grey out" of the credit limit fields would be nice, but if the user has the authority to change the fields, then chances are fairly good that they will find a way to do so regardless of the transaction.

Cheers,

Julius

0 Kudos

Thanks I am awaiting for our consultants to come back. I have attempted to utilize change fd32 via su24. Then define field groups and assign fields to field groups. And modifying F_KNKA_AEN. Still nothing. It will still allow me to change credit limit.

Thanks,

Maritza

0 Kudos

Hello Maritza,

Check whether the customer have a risk class assigned?

I think Credit Control Areas also play a role here?

Check the documentation on those whether there is any credit limit influence.

I am not logged on, but it could be another "grouping concept" which is a prerequisite for protecting the credit limit and activating the authorization checks on the K_KNKA* objects??

For a better answer (than mine) I would recommend opening a second thread in the ERP Finance or an "SD" forum and reference this thread, as chances are better that a good "SD" functional consultant would have the in-depth knowldge to know activate it for FD32.

Kind regards,

Julius