Manual Transaccion Fb01 Sap

13.12.2019by admin
Manual Transaccion Fb01 Sap Rating: 9,0/10 5904 reviews
Sap
  1. Fb01 Tcode In Sap Fico
  2. Bapi For Fb01
  3. Manual Transaccion Fb01 Sap Online

FB01 is the transaction that generatet the accounting documents but in most cases, you start with a different transaction. For example, if you generate an invoice using VF01, it will call FB01 to generate the accounting document - you don't have to do this manually yourself. The same happens when you use transaction F-02 to perform G/L account posting. FB01 is call to create an accounting doc when you save the journal posting. You can then display the posting/accounting doc later with FB03.

This is the reason why unlike other SODs which require 2 or more transactions to create a conflict, FB01 alone is enough to create the conflict if it has authorizations that permit the same user to generate accounting documents based on activities from subsidiary ledgers (i.e. Sales invoices, Vendor invoices, account write-offs, etc.) as well as general ledger (i.e. Journal entries).Peter Lee. Thanks for your reply. I understand your first half and got some help with your second half.So my new found understanding is that a subsidiary ledger is linked to a customer / vendor etc and config either fixes subsidiary ledger(s) to customers / vendors or allows more flexibility. If flexibility is allowed then the scenario you describe can happen which explains SAP's view on this.However our subsidiary ledger assignment is fixed in config - so no manipulation (without opening up the client) is possible.

Access to the subsidiary ledger can only come via a Customer / Vendor so therefore controls around those can be used as per my previous testing.Am I on the right page? Thanks Peter,I understand what you're saying but I'm not sure how to post to a subsidiary ledger without going via another account (customer / vendor etc).If I use FB01 I get error message F5354 with diagnosis 'Account xxxx in company code yyyy is marked as a reconciliation account for account type 'K' and cannot therefore be directly posted to.'

Do I conclude we (with current config) cannot directly post to a subsidiary ledger or should I be using a different tcode? (If so - which).Cheers,James. Hi Adrian,Thanks for your comments.I did mention in my original post that FB01 was only an example of the issue. I did ask a pretty narrow question but it is actually part of a much bigger issue which I am looking at and you've touched on it with your post.Program SAPMF05A which is called by FB01 is called by over a hundred other tcodes - such as all of the tcodes you mentioned.

Fb01 Tcode In Sap Fico

F-02 you label as 'more appropriate' but in fact the definition of F-02 (in SE93) is that it calls FB01 with 2 default values (which can be overwritten when using the tcode).So in fact F-02 is no more secure than FB01 in my experience. I have entered a vendor invoice with F-02 that looks identical as one entered in FB60 - but using the tcode whose description is 'Enter G/L Account Posting'.

(FB60 also uses SAPMF05A)There may well be hard coded logic in SAPMF05A which differentiates between tcodes but I can't see any alternative to treating the majority of those tcodes as being as dangerous as FB01 until they are individually tested.I'd certainly value your thoughts on this as an easy solution would be great.Cheers, James. Not sure if we are on the same page. Let me try to elaborate and hopefully less confusing.A subsidiary ledger is a detail ledger containing all the detail invoices, credits, payments, etc. Of the customers or vendors. Having access to the subsidiary ledger allows one to apply payment to the invoices, clear offsetting debits and credits or write-off uncollectable items, etc. In the case of SAP, all activities in the subsidiary ledger are automatically echoed in the general ledger. This means any unjustified or malicious act in the subsidiary ledger will eventually show up in the control ledger (i.e.

Good business practice dictates that a different person review and analyze the G/L and investigate any abnormalities. So you can imagine the risk if this person happens to be the same who create the malicious activities in the subsidiary ledger in the first place.Obviously, the risk do not exist if the person has only access to account type D (Customer) or K (Vendor) only but not S (G/L).

Sure the user can still hide his misdeeds if he can find another user with access to account type S to manipulate the G/L to hide what he did, but then, this becomes collusion. Something that requires more than authorization objects to detect.Peter Lee. I really think the approach here is not the best and offer thefollowing1. You need to talk to functional teams as security should not bedecided solely by the security person - functional experts and businessmanagement also have to agree what is necessary security.1 FB01 should only be available to power users as it is a 'super' (myterm) FI transaction, which can be limited by authorisations but it isbetter to use more appropriate transactions such as F-02, F-07, FB50 etc2. All sub ledgers are linked to and summarised in GL controlaccount(s).

Bapi For Fb01

You cannot post directly to a control account, you mustpost to the subsidiary ledger account (with the authorisation needed)and the control account is automatically updated - no direct postingsare allowed to the GL control account. Your concern about adjustingpostings is not possible by manipulating a control account.3 IT is not possible in SAP to delete a posted document - it can onlybe reversed, leaving a full audit trail.4 Before being concerned about tightening FB01 I suggest you makecertain more appropriate transactions are allocated to end users.5 As a security consultant you need to ask questions and includefunctional experts and others in your decisions as part of your job. There is some hard logic in the abap which differentiates between XNcodes (certainly not all but many). In addition remember we aretalking an end user so there is less likelihood they can or will override defaults proposed by these other transactions. F-02 is for vendorpostings so it will be more difficult to post to non vendor accounts(but not impossible).However FB01 is unrestricted for account type, document type, postingkey etc which can be manually entered provided there are fullauthorisations. Why would such an open transaction be given to an enduser when there are more specific transaction available even if they dohave shortcomings. More specific transactions are also easier to use.Remember the user may be a novice so it should be made as easy as possible.In terms of FI postings FB01 is a sledge hammer more prone to mistakesand a security nightmare.I restrict FB01 to power users and require informed process ownerapproval prior to granting access.

Manual Transaccion Fb01 Sap Online

Start asking what document typesaccount types and posting keys of the process owner if they persist withfb01 and make certain they are aware it is a power transaction.