Users only be able to 'Park' the document and will be posted by au,

[chandrasekharbadeti_chand]

Hi Friends,

Can any one guide me, How to restrict the Users to Post FI document from T Code F-02 or from any other T Code, users only be able to 'Park' the document, is it ther any possibility for this scenario without using Workflow concept?

Best Regards,

Chandra

[Former Member · Accepted solution]

Hi,

There was a exact requirement in our project, we have acheived it through by writing a enhancement in the standard screens.

Thanks

Aravind

[Former Member]

The best way is it to use BTE.

Regards,

John

[yogesh_kshatriya2]

Hi Chandra,

Consult with BASIS, I think with the help of authorization it can be done. Ask then to remove posting authorizations.

--Yogesh

[Former Member]

Dear All,

I was having the same requirement from my client.

I used the auth object F_BKPF_BUK & removed the activity 01 to disable the Post tab in FV50/FV60,etc. But remember the user will not be able to post any other entry directly to FI e.g. JV in F-02.

Hope the above will help.

Regards!

Pulak Das

[Former Member]

Dear All,

Even we had same requirement in our project and I would like to share my experience:

After trying a lot from roles and authorizations we decided to use transaction SHD0. Using this we could disable post/park as required in the various screens.

This is how we have done it. Initial testing results look to be fine.

If anyone has any suggestion on this way, please let me know.

Thank you

Abhinav

[chandrasekharbadeti_chand]

Closed

[former_member184992]

Hi Chandra,

This is design in the system: the person who is authorized to park the

documents, should also have the authorisation to post it. In these

ENJOY transaction, all these functionalities are provided like Post,

save, park etc., and normally one person is the key person in the

department. In earlier versions it was separated like F-65 to park and

and FBV0 was to Post the document, where as in Enjoy transaction all

the authorizations is given in one transaction itself. This is addi-

tional functionality in system design.

To segregate the authority to park and to post, we suggest that you

either

- use the exit provided by note no 361420 to deactivate the posting/

parking button depending on users.

OR

- set up a validation to prevent a users from posting/parking

OR

- Use workflow to release the park documents.

Also, you can try the following in order for you to disable the POST

function. Within the transaction you need to have set-up the proper

activities for authorization objects.

The proper authorization objects must be setup to prevent users from

posting documents. The related authorization objects must then be linked

to the desired profile / user via trans SU02. The following

authorization objects are checked via FB / FV transactions:

F_BKPF_BES Accounting Document: Account Authorization for G/L Accounts

F_BKPF_BUK Accounting Document: Authorization for Company Codes

F_BKPF_BUP Accounting Document: Authorization for Posting Periods

F_BKPF_GSB Accounting Document: Authorization for Business Areas

F_BKPF_KOA Accounting Document: Authorization for Account Types

This can be reviewed via trans SU24. It is necessary to set up the

proper activites for authorization objects: Pre-enter, display, change,

display changes and/or activate / generate and remove the "create"

activity to prevent users from posting the document.

Please also see the online documentation regarding the use of authorizat

groups. The documentation about the authority check within posting is

given in the online documentation for the posting transaction eg. FB01.

The system does not check the authorization for document types or

gl accounts (etc..) that are not assigned an authorization group.

In the IMG for document types under financial accounting you enter

the authorization group. Maintain auth group for accounts in the

gl master record on the control data tab.

I will briefly explain the logic of authorization in SAP.

In SAP concept the person who is able to post the parked document

should have more authorization than a person who only parks the document

(requires only 77). The person to post a parked document must also have

the authorization to park a document because the document can be changed

when displayed in FBV0.

a)If you want to restrict the authorization to PARK-only, you can do

this by assigning activity 77 (park)to the relevant authorization object

b) you cannot restrict the authorization to POST-only (save as complete)

as this requires also activity 01 (and this cannot be given without 77).

In this case, if you want to segregate 'park' and 'post' authority,

we suggest that you either:

- set up a validation to prevent a users from posting/parking

OR

- Use workflow to release the park documents.

I hope that this answer your inquiry.

Best Regards,

Vanessa Barth.

[chandrasekharbadeti_chand]

Hi Friends,

Thank you very much for all your information and suggestions.

Actually who ever parked documents they should not change and post. only some authorized users can post the parked documents, as our client is having many business transactions each day and the authorized users will check the same parked document then they will post the parked documents.

Best Regards,

Chandra

[Former Member]

Hi Vanessa,

I am testing the following scenario, for park/post of InterComp documents, via FBV0.

There are two (2) Company Codes, CC1 & CC2.

1) UserCC1 parks an InterComp doc (credit for CC1, debit for CC2).

2) UserCC2 should be able to post the InterComp doc created at step #1.

3) UserCC2 should NOT be able to post any other DocType (besides the InterComp DocType) in CC1

<Q1> Is this doable?

<Q2> I have tried to 'control' it by using the Auth. Object F_BKPF_BUK but it doesn't seem to work, do you think I have to use another Auth. Object?

<Q3> I am thinking of using FI Validations to 'control' the combination of CC and DocType, but I am having way too many CC's to deal with! Is it an option?

Best regards,

Tom

[Former Member]

Hello Vanessa,

I have the same requirement as in the original post (this is a small implementation, ERP2005, but sold as BAiO). In your answer you mentioned that validations are an option, but despite the fact that I am pretty good with validations and substitutions, I could not get that to work for this (my guess: because the user field (UNAME or USNAME) is only updated when the commit to the database happens). Question therefore: Do you have more details or documentation on how this can work?

Thank you very much - greetings to Brazil!

HC

[former_member194797]

You should create authorizations with activity 77 (park) and without activity 01 (add/create).

[Former Member]

Hi,

You can acheive the same thro BTE or Workflow.We have achived the same with both BTE and Worflow for different clients.

Take the help of ABAPer for the same.

Give a try,else revert for further suggestions,

Regards

[Former Member]

Unless you have workflow where you can prohibit specific users from posting as against parking etc, enhancing the code is the only way to go.