Step 6 – Determine approval paths
On this post I would like to look at how the system has been designed to transfer balance sheet items to profit centers using the transactions 1KEH, 1KEI, 1KEJ, 1KEK. Often I have come across situations where the total balance of balance sheet accounts on a report painter report based on the library for GLPCT doesn’t match with the total of the line items on the called up report. This is not a Bug rather this is how the system has been designed.
Next we have to find the process interface for duplicate invoice check! To do that, follow the following steps.
Define a new product and activate it
Now go back to FIBF and execute the menu as shown below
Bingo!!!!!! Now every time when a vendor invoice is being posted the invoice check will be carried out using the custom logic built into the function module “ZSAMPLE_PROCESS_00001110”. But make sure that the “double invoice check” tick has been put on the relevant vendor masters!
2. SAP Easy Access Info Catalog
SAP Area menu SAP2
I hope the above SAP Area menus would help you to explore and utilize the standard reports provided by SAP. Please feel free to send me your comments.
How does this concept work?
When an ABAP program issues an open sql statement, the application server will first check whether the table has been activated to be buffered or not, if the table has been activated to be buffered, the server will check the RAM for the buffered data.
If the buffer is available, the program will read the data from the RAM else it will read it from the database, populate the buffer and subsequently read from the buffer.
I think this post should have given you a basic idea about the table buffers. Definitely this concept improves the performance of the system, but we have to take certain facts into consideration when we try to activate the table buffer on any table. On my next post I will talk about the implications of table buffers in a more detailed way. As well as I will take a look at the multi application server environment and the table buffers.
Please send me your comments.
The details of same table on the actual database are shown below.
In addition, Data dictionary works like a remote control to the actual database. Developers create the database objects on the data dictionary and activate them; in the background the system will automatically generate the corresponding SQL statements and create the objects on the actual database.
As a strict rule the developers would never create or modify database objects such as tables directly on the actual database, in case if some one has created or modified a database object directly on the database, there is no way that the data dictionary could synchronize with the database object, which will lead to unnecessary problems and may affect the system performance and stability.
We can create objects such as Tables, Structures, Views, Data domains and Data elements on data dictionary. As well as SAP provides various tools to check the consistency between the database and data dictionary objects. I will look at each of those in detail on my future posts.
Please feel free to send me your comments.
Select the object type as ‘Parked documents’. Please note that we can apply the same logic to other documents such as ‘Documents’, ‘External documents’. ‘Sample documents’, ‘Recurring documents’ and ‘Documents with preliminary postings’
Enter a Field group as a two digit numeric value and type a Description.
Step two:
As the second step we have to group the document fields. Use activity ‘Group Document Fields’ on SPRO to perform this step.
Select the object type as the ‘Parked documents’. Select the Field group that we have created in step one and assign the desired fields.
Step three:
As the next step we have to assign the field groups to the Roles which will then be assigned to the users. Every user can be given authorization to change fields in one or more groups. This means that a user may either change all or no fields of a document. The classification of the fields into groups should be carried out with this in mind.
Execute transaction code PFCG to maintain the roles. Select the desired role and add the desired field groups to the Authorization object ‘F_SKA1_AEN’
Bingo!!! That’s it. Now the users with the role Z100 attached to them would only able to modify the fields ‘Exchange rate’ and ‘Fiscal year’ on the parked documents while the others would not be able to modify any fields at all.
Field groups can also be used to filter the data on report ‘RFBABL00’ (‘Display of changed documents’)
I hope this post would have helped you to understand how SAP even allows us to control the access to each and every field on the documents. I strongly believe this flexibility with SAP is the main factor which makes SAP as the number one ERP in the world.
Please don’t hesitate to send me your comments.
Now you may ask me if the automatic table recording has already been activated for tables I mentioned above, why system gives the following error message when try to view the change documents using SCU3
Yes we have to do one more step to activate the automatic table history functionality on a given client.
Step two:
Maintain the client number, for which we want to activate the automatic table history, against the parameter ‘rec/client’ on the application server profile.
Bingo now we are ready to go. Now we can use transactions SCU3 to view the change documents.
Ok now let me explain how exactly this works. Every time when you perform an ‘Insert’, ‘Delete’, or ‘Update’ statement on an ‘Automatic table history’ activated table, it will maintain a log on the change document table ‘DBTABPRT’. Check the following screen shot to see the structure of the table ‘DBTABPRT’
Details such as Table name, Date of change, Time of change, Host name, Person who has changed, Transaction code that has been used to change, ABAP Program name, Type of the operation (whether is it insert , delete or update) and the data change will be recorded on the table DBTABPRT. Later when we use transaction code SCU3, it will fetch the data from this table and display the change documents.
But it’s not possible to activate the automatic table history to a table where the length of the primary keys is more than 86 bytes and the length of non primary keys is more than 500 bytes.
As well as consider the fact that activating the ‘Automatic table history’ may slow down the database operations since all the tables with the above option activated need to access the table DBTABPRT to update the change documents and which may lead to table locks. So it’s advisable to activate the 'automatic table history' only on the tables which are really crucial.
Please send me your comments about this post.
There should be at least one leading ledger. Along with that we can define any number of non leading ledgers to satisfy our needs. When we define ledgers, system will automatically create ledger groups on a one to one relationship to the ledgers.
A ledger group is a combination of ledgers for the purpose of applying the functions and processes of general ledger accounting to the group as a whole. When posting, for example, we can restrict the update of individual postings to a ledger group so that the system only posts to the ledgers in that group. We can group the ledgers into the ledger groups with a representative ledger from which the system will determine and check the posting periods for that ledger group during postings.
After we have defined the ledgers we can specify the parallel currencies on which we want to maintain the accounts on leading and non leading ledgers for each company code. You can have up to three currencies per ledger per company code. But the non leading ledgers can only be maintained on the currencies that specified for leading ledger. But note that you don’t have to maintain non leading ledgers on all leading ledger currencies.
Another interesting functionality is that you can even specify different fiscal year and posting period variants to the company codes for the non leading ledgers than the leading ledger.
Even we can control how other components like ‘Cost Center’, ‘Consolidation’, ‘Business Area’, ‘Profit Center’, ‘Segmentation’ and ‘Cost of Sales Accounting’ will update the ledger by assigning the necessary scenarios to ledgers. A scenario determines which fields are updated when postings are received from other application components. We cannot define our own scenarios. For example we may only update the leading ledger with the cost center details while keeping the other ledgers untouched. This gives the ultimate flexibility to manage the trade off between the database performance and the financial information requirements.
We can add additional fields to the summery table and capture information that cannot be captured by the existing fields on the summery table FAGLFLEXT. Again we can assign the fields to the ledgers like we do to the scenarios as I explained above. I’ll talk about how we can assign additional fields to the summery table FAGLFLEXT on a different post.
My SAP financial even allows us to maintain multiple planning versions per ledger. For example we can use scenario planning techniques by defining different planning versions for individual ledgers which I feel really useful to the managers on this highly unpredictable business environment.
After we defined the ledgers and the ledger groups we can define the accounting principles on SAP system and assign them to the ledger groups.
Once we have carried out the above activities the next step would be to create the accounting document types and their number ranges for entry view. The important point I want to stress at this time is that we have to define number ranges for the accounting documents specific to the non leading ledger groups too. And we cannot use the same number range object we used for the leading ledger. The reason is when we post documents to a specific ledger group if we have the same number range assignment as leading ledger; it will create number gaps on the leading ledger accounting documents. So system will not allow you to specify the same number range object of leading ledger to be assigned to the non leading ledgers.
When it comes to Document types for general ledger view, we don’t have to do anything for leading ledger since in the case of this ledger, the document number in the entry view always corresponds to the document number in the general ledger view. We only have to make these settings for any non-leading ledgers that have a fiscal year variant that differs in at least one company code from the fiscal year variant of the leading ledger in this company code. In this case, the document number in the entry view does not correspond to the document number in the general ledger view and we have to define a separate document type with document number assignment for the general ledger view.
These are the basic settings that we have to do in order to carry out parallel accounting on MySAP Financials. Now we can use transaction codes FB50 and F-02 to post double entries into all the ledgers and transaction codes FB50L and FB01L to post double entries to selected ledger groups. We can generate the financial statements per ledgers when we need them.
This is a basic idea about how we can configure parallel accounting on MySAP Financials and hope that this post has given you a good idea about some of the new SAP general ledger functionalities. Please feel free to send me a comment.
