Did you ever get any custom messages(Z-messages) while posting FI/CO documents/transactions which posts to FI/CO (Like GI, GR etc)I? Certainly (90%+ cases) these messages must be coming from validations and in few cases these are from user exits. User exit messages can be found by simple where used list option to reach the trigger point. But the messages issued from validations (GGB0) can't be caught in where used list as these dynamic messages issued during run time.

Did you ever observe some fields are populated automatically or over written automatically during document posting? If you want to know where is this happening, what would be your best approach to dig the source of the logic for that field? Are you running to ABAP team to analyze further? Not required anymore once you know this t-code

All above questions can be answered with single t-code GGB4. One might argue why can't we directly search in substitution/validation configuration. This is very difficult when number of substitutions/validations are high. You can try both approaches and see the difference. I am very sure that, variance would be more than 90%

T-code GGB4 has below functionalities.

1. Message usage search:

Once you know the message number and ID and you want to see from which validation this message is coming from, follow below steps.

Go to GGB4 and click on Message usage.

In the next screen, enter the message ID , number and click OK.

Note: Message ID field is shown with 2 digit output length. But, this will accept complete message ID while typing.

Now output will show all the validations where this message is used.

Application point shows from what all applications this message is called. In this sample output, it is called from FI area. Call up point shows whether validation is at header level/item level/at complete document level.

Call point

001-     Header level validation

002-     Item level validation

003-     Complete document level validation.

Direct navigation to the respective validation can be done by double clicking on the validation name. Further logic can be easily checked here.

2.Source of logic for substituted field/to know if a field is being substituted or not.

From GGB4 main screen, click on substituted fields.

In next screen, enter the table and field name (This can be found from FI document, click F1 on the field and go to technical attributes). Most of the time, it would be BKPF/BSEG fields. Click OK after entering the details.

Output will show the details of the substitutions where this field is being changed.

Field can be changed by below means.

1. Direct field to field assignment

2. Assigning a constant to the field

3. Change through ABAP logic in user exit

Above details can be checked once we navigate to respective substitution.

3. Activation of substitution/validation:

GGB4 has small additional functionality for activating the substitutions/validations.

Once clicking on Activate Substitution/validation, select appropriate application area and activate substitution/validation accordingly.

Below statuses are available.

Funny notes: I heard from few consultants that, substitution/validation is available only during FI document creation. This is so incorrect.

These are available for other areas as well like Cost accounting, Asset accounting, Funds management etc. Go to t-code GGB0 to see the entire list.

Finally I could manage to write this blog after long vacation for marriage. SCN love still continues

You can check out other blog related to same topic.

Golden tips while transporting substitutions/validations

Your valuable feed back on this blog is most welcome.

Thanks,

V V

Assumption: Reader is aware of basic "Automatic Payment Process" concepts.

Most of us are familiar with online banking transactions. There would be thousands of bank transactions happening 24/7. Did you ever think, how does payment reaches a bank/payee, if it is done on a bank holiday or on a Sunday (Global holiday in most of the countries)? Usually banks refer to value date while making  a payment to payee instead of transaction date. In case of real time transfers, value date and transaction date are same. In case of payments with say check, value date may be in future as well. Aligning this kind of requirement to SAP, usually payments are handled in SAP through automatic payment program (F110) or manual payments (F111). To understand the complete process in a better manner, first we need to understand few terminology used in payment process.

Payment media:This is the means of communicating the payment related information to bank. This would have information like payee details, bank account, amount to be paid etc.

E.g.: Payment media can be sent to bank through payment IDOC, flat file, XML file etc.

Value date:This is the date on which bank has to dispatch the money to payee account. Please note that payment media is sent in advance to the date on which payment is to be made to payee. How many days before a payment media should be sent to bank is controlled through configuration.

Payment advice:This is the communication sent to payee/accounting clerk (In some cases where vendor doesn't have e-mail address) stating with the details of the payments done (List of paid invoices, amount, payment currency etc.) and to which bank account payment is made. This helps the payee to stay updated about the payment progress.

Usually, F110/F111 is run on a weekday and payment media is generated immediately and sent to bank. But, bank will start the payment process on the value date mentioned in the payment media.

Value date configuration and calculation logic:

Value date can be calculated in two different ways.

1. Without bank calendar
2. With bank calendar

Value date calculation without bank calendar:

Go to below path in FBZP.

Enter required company code and proceed. In the next screen, you can assign the number of days to be added to value date.

By default, value date is same as posting date entered in the payment run. Number of days can be assigned at payment method, House bank, account ID, Amount and currency level.

We can assign different number of days for different amount limit for the same account , currency and payment method

E.G: All checks (Check payment method) up to 100000 USD should be paid on 1 day after the payment run and 100001 USD onwards, should be paid 2 days after the payment run. This feature helps to manage the cash flow and funds in a better manner and won’t cause sudden plunge of bank account balance due to unexpected huge payments. Business will have enough

time to analyze the funds situation at any point in time.

Value date calculation with bank calendar:

This has two steps.

Configuring value date rules:

Go to value date rules from FBZP as shown below. Enter the company code and proceed.

Enter the house bank, account ID, Transaction name(Free field).

Reference date for determining the value date: This can have below options.

1          Document date

2          Posting date

3          Due Date

Most of the cases, posting date is selected as value date base line date (Reference date).

Calendar 1:This is the factory calendar ID used for calculating the value date. Bank holidays defined in this calendar are considered while calculating value date.

+ or – sign indicates weather the number of days mentioned is to be added/subtracted.

E.G: If the value date reference is posting date, Payment run Posting date = 01.04.2014

Considering above screenshot,

If 1^st April is a holiday as per calendar EC, then value date base line would be 02.04.2014.

If 1^st April is a working day as per calendar EC, then value date base line would be 01.04.2014.

Deviation from reference date in days: Number of days mentioned here are added/subtracted based on the sign column to the value date base line date.

From above example, value date calculation happens as below

If 1^st April is a holiday as per calendar EC, then value date base line would be 02.04.2014, value date = value date base line + 2 days = 04.04.2014

If 1^st April is a working day as per calendar EC, then value date base line would be 01.04.2014, value date = value date base line + 2 days = 03.04.2014

Once transaction name with the value date calculation rule is configured, next step is to assign this transaction to payment method.

Go to below path in FBZP. Enter company code and continue.

Enter the payment method, Transaction, House bank, account ID and the transaction name created above.

Don’t get confused with the transaction entered in second column with the one in sixth column. The one in second column is used for distinguishing different types of transactions for the same payment method. Below values are allowed here.

Space    Transaction not relevant

1           Bill/exch. for discount

2           Bill/exch. for collection

3           Check deposit at same bank

4           Check deposit in same region

5           Check deposit (general)

This allows to configure different value date rule for same payment method.

EG: If payment method A is used for check payments, check at same bank might need lesser time compared to check in different bank in same region.

Usually transaction in second column is maintained as blank. The one in sixth column is used for determining value date rules (Configured in previous step).

These steps completes the configuration of value date calculation. These rules would be used when payment media is generated and during value date calculation.

Note: Custom logic can be written in payment user exits if standard customization doesn't meet the requirement.

Your valuable comments and addition of more information on this blog is most welcome

Thanks,

V V

In below blog, we have seen the configuration and calculation logic of value date.

Value date calculation logic during automatic payment process (APP)

There is step where calendar ID has been assigned to house bank and account ID.

Let us see how to configure the bank/factory calendar.

There are three steps involved in this process.

1. Creation of public holidays:

  Go to t-code SCAL, select Public holidays option and click on change.

Click on create button in next screen.

Type of public holiday is defines how a holiday is determined. Select the appropriate option based on requirement and proceed.

E.G: If you want to set up Labor day (1^st May) as holiday, you can select “With fixed date” option, because the holiday date is fixed here.

Enter the day, month and select the appropriate Guaranteed option. “Not Guaranteed” means, if the fixed date falls on  week end, it wouldn’t be moved to next working day.

Maintain the public holiday attributes like sort criteria, holiday class, description etc. Other fields are self-explanatory. Click on create once you enter all the fields.

2. Creation of holiday calendar:

Select below option and click on change.

Click on create icon.

Enter Holiday calendar ID, description and click on holiday assignment.

Select the list of holidays created from popup and click on assign.

In the next screen, you can see the holidays are assigned with validity year from 1900 to 2098. Change the validity if required and save.

3. Creation of factory calendar:

Select below option and proceed.

Click on create and proceed.

Enter calendar ID, description, validity years, Holiday calendar ID (Created above). Select working days and save.

Validate to see if the holiday is correctly assigned or not. Select the calendar created above and click on display calendar.

You can see all the years assigned in the definition.

Select the year and click on display year. You can see all the assigned holidays here. Holidays are highlighted in green. Placing the cursor on holiday date, shows holiday name.

Now Assign this calendar ID in FBZP value date rules.

This completes the calendar set up. Assigned calendar holidays are not added while calculating the value date during payment media generation.

Thanks

V V

Variant creation for reports I have come across the variant creation for report and thought of sharing this to a larger community. Please find the attachment for reference purpose.

Over the last few months, I have been facing an issue whenever I create a TR request. All of us know that for most of our SAP configurations, SAP automatically prompts for a TR number and includes all the relevant data on the TR request.

SAP best practice says that we should not tamper with the TR request contents, meaning, no manual changes to be done to the TR. But, I have seen people have issues with this. They are never ready to leave the poor TR request contents alone, the reasons may be different.

SAP expects that the configuration in our Production client is the same as the one in our Configuration client. This is to be 100% adhered and so does not encourage manual tampering of TR’s. The reason being, when the set up is same, irrespective of the TR contents, the config remains same throughout the landscape once the TR reaches production.

People have reservations because, they are not sure that Prod and Dev configuration is the same or in case of substitutions and validations, where a whole lot of other data along with your changes are also included in the TR (since TR is not created at the step level).

There may be other reasons for manual TR need. Say, a Z table does not prompt for TR when changed. In such a case also you would need a manual TR.

I have heard different approaches for creating this manual TR with the desired entries only. But, recently I came across the easiest one.

In case of say transporting fields to be restricted to be not used in Validation or substitution creation as explained in my document (Restricting/Unrestricting Fields for Substitutions and Validations), the TR SAP prompts for has only the changed entries. So, if we say we have changed or created 2 entries in the table, even if the table has 100 entries, only the 2 are included in the TR.

But, in some cases like OBYC settings, the TR created by SAP tends to include all the entries present for that transaction. Say, for BSX, we have 20 entries and we have added 2 more, all the 22 entries are included in the TR which SAP creates. In such cases, to get people off your back who are concerned about the TR contents, you can easily create a manual TR using SE16 or SE16N.

CATCH: To create a manual TR, you should be aware of all the underlying tables for the config to move correctly. Also, you need to take a call which tables are required and which are not. For OBYC, both T030 and T030R are included in an SAP TR. But, T030R is not required unless you make changes in rules for that transaction. To know the underlying tables, one way is to let SAP create a TR and then you can look at what tables are being included and take the call.

Go to SE16 transaction code and enter the table name.

Hit enter. Then input the relevant criteria to get the desired entries.

In the output screen, select the required entries by clicking on the first column(Use Ctrl + Click for multiple separate entries as shown in the screenshot or use select all button). Go to Table Entry -> Transport Entries

The next screen prompts you for a TR number. Create a TR from here or enter an already existing TR number.

The resulting TR from here has only the 4 entries we selected from the table to transport.

The same process can be done from SE16N as well.

Go to SE16N transaction code and enter the table name.

Hit enter. Then input the relevant criteria to get the desired entries.

In the output screen, select the required entries by clicking on checkbox in the first column (Use Ctrl + Click for multiple separate entries as shown in the screenshot or use select all button). Go to Table Entry -> Transport

The next screen prompts you for a TR number. Create a TR from here or enter an already existing TR number.

The resulting TR from here has only the entries we selected from the table to transport.

P.S: The intent of this blog was to make aware if someone is not aware of the process. I still recommend SAP created TR’s without manual intervention wherever possible

Most of us are comfortable with SD-FI-COPA integration concepts as it is easy to correlate and understand. But, when it comes to MM-FI integration, many of us find difficulties in understanding the concepts and account determination process. When I was trying to analyze my first issue related to how a stock account is determined in a valuated transaction, I was lost in OBYC. Let us try to understand few terminology used in MM-FI integration concepts. Once we are familiar with the concepts, we will further discuss account determination process in a stock movement related transaction.

Valuation area:

Stock of a material owned by a company is an asset to the company. Valuation area defines the organization level at which materials are valuated.

SAP has provided two options for valuation.

1.     Valuation at plant level: All materials are valuated at plant level.

2.     Valuation at company code level: All materials in all plants of a company are valuated at company code level.

This setting is defined in t-code OX14.

Valuated stock:

Total valuated stock = Stock in unrestricted use + Stock in transit between storage locations/warehouses of a plant + Stock in quality inspection.

Material type:

This defines the type of material.

EG: Raw material, Finished goods etc.

Material type is defined during material master data creation.

Movement type:

This defines the type of material movement from one place to other. Movement type enables the system to find predefined posting rules determining how the stock and consumption accounts are to be posted. All possible goods movements are already defined by standard SAP

EG: Movement type 101 refers goods receipt

Movement type is entered while posting stock movement related transactions. Most of the time, standard SAP automatically derives the movement type based on transaction code.

EG: If we go to MIGO, default movement type 101 is displayed by system.

Valuation class:

Valuation class is defined for the combination of plant and material (In Accounting 1 view of material master).

Valuation class allows posting of stock values of

1.     Materials of same material type to different G/L account (Different valuation class is assigned in different plants for the same material)

2.     Materials of different material type to same G/L account (Same valuation class is assigned to materials of different material type)

Note: G/L accounts can be defined at valuation class level along with other parameters.

Valuation grouping code:

Valuation grouping code combines the valuation areas having same business properties for the account determination. This reduces number of entries to be created for automatic account determination for the stock postings.

EG: Valuation area 1 and 2 are required to be posted to same G/L account, these are grouped to valuation grouping code ABC and G/L is determined based on valuation grouping code and valuation class.

Before using valuation grouping code, it needs to be activated in OMWM.

Valuation grouping code is assigned to valuation area in t-code OMWD.

In below example, five valuation areas are assigned to same valuation grouping code.

Account modification/General modification:

This key is used to determine different G/L account for the same kind of goods movement based on origin and target.

EG: During Goods issue, offsetting G/L is determined from transaction key GBB. If business wants to post to different G/Ls for goods issue for cost centers (Movement type 201) and good issues to orders (Movement type 261) for the same material and plant, Account modifier can help here. To understand this better, let us go to t-code OMWN where we define the transaction key and account modification for the movement type.

Transaction key which we see in OBYC is determined based on the movement type. In below screenshot, you can see all parameters are same for movement type 201 and 261 except account modification.

Please read F1 help on different fields in this screen to know more about functionality of each field.

T-code OMWN:

When material document is posted with these movement types, offsetting account is determined from transaction key GBB based on account modifier and valuation class.

From below screenshot, you can see that, different offsetting G/L account can be determined for the same transaction key and valuation class.

By Default, Standard SAP defines account modification keys for below transaction keys. User defined keys can also be defined and respective account determination settings can be maintained.

• GBB (offsetting entry for inventory posting)

• PRD (price differences)

• KON (consignment liabilities)

Below are the modification keys defined by SAP (Extracted from F1 help).

Modifiers for GBB

For the transaction/event GBB (offsetting entry for inventory posting), the following account groupings have already been assigned to the relevant movement types:

• AUF: for goods receipts for production orders with account assignment
• BSA: for initial entries of stock balances
• INV: for expense/revenue from inventory differences
• VAX: for goods issues for sales orders without account assignment object
• VAY: for goods issues for sales orders with account assignment object
• VBO: for consumption from stock of material provided to vendor
• VBR: for internal goods issues (e.g., for cost center)
• VKA: for consumption for sales order without SD
• VNG: for scrapping/destruction
• VQP: for sampling
• ZOB: for goods receipts without purchase orders
• ZOF: for goods receipts without production orders

Modifiers for PRD

If you also activate account grouping for transaction/event PRD (price differences) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

• none for goods receipts and invoice receipts for purchase orders

• PRF: for goods receipts for production orders

• PRA: for goods issues and other goods movements

Modifiers for KON

If you also activate account grouping for transaction/event KON (consignment liabilities) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

• none for consignment liabilities

• PIP: for pipeline liabilities

How are the account determination attributes determined for each transaction key/event?

Did you observe different set of fields appears for different transaction keys in OBYC while maintaining G/L account? Yes. This is defined in Rules for the transaction key.

EG: Select transaction key AUM in OBYC and click on "Rules" in toolbar.

You can see that general modification and valuation modifier is active.

If you go to G/L account maintenance for this key, you would see the same fields.

Quick snap of MM-FI Integration process:

When we do material posting for a valuated material, below flow happens.

1. Movement type and other attributes like special stock indicator, movement indicator etc are determined based on business transaction like goods                       receipt for PO, production order etc.(OMWN). This is defined by standard SAP.

2. Transaction key/event and account modifier is identified based on movement type and other standard attributes in step 1 (OMWN)

3. Valuation grouping code activation is checked from OMWM

4. If active, for the given valuation area, valuation grouping code is identified from OMWD

5. For the identified transaction or event, check if valuation grouping code is active or not in OBYC (Click the rules button for the transaction key)

6. Valuation class is determined from material master.

7. Based on the above identified attributes, select the G/L account from OBYC.

If system can’t find any account for the found attributes, stock posting can’t be done and system through clear error stating for which combination of attributes, G/L account is missing. Such errors are mostly seen during go live/while posting to new materials due to missing G/L account maintenance or due to incorrect valuation class in material master data.

Now you know the process, here is the short cut to find out G/L.

Account determination details are stored in table T030. If you want to know based on what details XXX account is determined, simply give that G/L in T030 table in fieldKONTS. This gives the possible combination of entries where this G/L is assigned. We can further drill down based on the filtered entries.

Please share your valuable feedback, thoughts and add additional information/corrections if any

Check out the next blog in this series.

MM-FI integration: Account determination simulator

Thanks,

V V

Are you facing difficulties in finding out correct BTE to implement for your custom requirements? Doing extensive search over net/SCN? Not required now!!!

Yes, SAP has already given awesome “BTE search tool” which many people are unaware. I came across this interesting tool during my R&D and found it very helpful.

Hence, sharing this with the community.

Before we go on how to use this tool, let us go through little basics of BTE.

Business transaction event is delivered by SAP to code customer specific requirements during predefined standard processes. Call points are already defined by SAP. All we need to do is just plug in our code in the BTE based on our requirements and SAP would play it during standard process

Business transaction events are of two types.

Process BTE:

Process BTEs are called at a fixed, predefined points during the standard SAP program flow at which the system can process user defined/custom function modules instead of the standard function module. The pre-conditions/rules for calling up alternative processes are defined in the  customization of BTEs in t-code FIBF. There would be standard function module OPEN_FI function module assigned by default by SAP. If there are no custom function modules assigned in FIBF, standard function module is processed. Data and process flow of standard SAP can be changed in BTE.

OPEN_FI function module select the FM to be processed for P/S BTE.

Function module PC_FUNCTION_FIND determines the function module to process from the following tables (equal priority):

a) TPS34 Customer-Specific Function Modules

b) TPS32 Partner Function Modules

c) TPS31 SAP Function Modules

d) TPS01 Standard Function Module

Publish & Subscribe (P/S) BTE:

P/S BTEs are called at a fixed, predefined points during the standard SAP program flow. Data can only be published to another application through P/S BTE i.e. we can only export the data to P/S BTE. Changes to program flow or data can’t be performed here. The pre-conditions/rules for calling up alternative processes are defined in the  customization of BTEs in FIBF.

OPEN_FI function module select the FM to be processed for P/S BTE.

Function module BF_FUNCTIONS_FIND which is called inside OPEN_FI function module determines the function modules to process from the following tables:

a) TBE34 Customer-Specific Function Modules

b) TBE32 Partner Function Modules

c) TBE31 SAP Function Modules

(Source: Partly from F1 help)

How to search BTE:

Assume you have business requirement to implement a custom functionality to send an SMS alert to customers when dunning run is done. Since standard SAP does not have such functionality,

You can look for BTE for this.

Go to below t-codes

BERP: To search for process BTE

BERE: To search for P/S BTE

Both t-codes have same selection fields.

Select the attribute type A (Application component) and click F4 on selection attributes field.

In the next popup, drill down to the process area you are looking for. The paths displayed here are similar to SPRO path.

Select appropriate node. In this case it is DUNNING.

Path would come as shown below.

You can further restrict the search by entering other selection parameters which are self-explanatory. Now execute the program.

Output would show the list of available BTEs for the given node. Most of the times, description of the BTE says functionality.

Select appropriate BTE and use below tool bar options to explore further. We can see the sample FM delivered by SAP, interface of the BTE, Documentation etc.

Custom FMs can be created with the same interface as of sample FM. One common error seen while implementing the BTE is, custom FM interface may differ than standard FM interface.

In this case, the process would go for dump. This is because, SAP determines the FM name during run time (Dynamic call).

Similarly, search can be done based on other parameters like based on Business object name, IMG nodes etc.

You are welcome to post your comments and feedback on this blog

Regards,

V V

Note: Assuming that reader is aware of MM-FI integration concepts. You can go through below blog  as well to understand the MM-FI integration concepts.

MM-FI integration: A conceptual understanding

Now we know how MM and FI are integrated and how the account determination happens. If we want to test inventory account determination, neither you need to do actual material posting in the system nor go through master data and customization to identify the accounts. SAP has delivered account determination simulation tool.

This helps to find how an account is determined while posting stock related transactions. We just need to input plant, material, movement type and select the transaction we would like to check say GR for purchase order, GR for process order etc. Based on above inputs, system would read customization, master data and simulate the account determination process. Apart from above, system would also identify missing account assignments for a given transaction. This would further help to analyze issues in an easy manner.

Go to T-code OMWB and close the initial popup. Click on Simulation button.

Fill in plant, material , movement type and enter. Transaction list would be automatically refreshed based on the movement type. Double click on required type of transaction to be checked say GR and click on Account assignments.

In next screen, we can see the list of all available transactions possible for this movement type, plant and material combination. Some fields like material type, valuation class etc. are derived from material master data. Some fields like valuation area, valuation grouping code etc. are derived from customization of the plant.

In this screen, we can see what all accounts are determined for different kind of transactions.

EG: For Inventory posting, you can see Debit/Credit posting keys and respective G/L accounts. If there are any missing account assignment for a given transaction, this is also highlighted with text as “Missing”.

In above example, you can see this happened for Purchase account and purchase offsetting account. We don’t have any account assignments here as we are not using this scenario. By this way, we can clearly identify the gaps in account assignment without even doing the actual posting.

We can change to different movement types and transaction combinations and see how account determination happens and based on what fields it happens. You can try this in your system for various permutations and combinations.

Second feature available with this tool is, to check the screen layout. This would help to identify any conflicts in screen layout rules for the inventory G/L account item during material document posting.

Screen layout for the inventory account item is determined at two levels.

1. From field status group of movement type
2. From field status group of inventory G/L account.

Click on “Check screen layout” button. In Next screen, we can see what is the field status set at movement type level and G/L account level. We should ensure that, there is no conflict between these two field status exist.

EG: We can’t have a field mandatory in one FSG and suppressed in other FSG. Posting would fail in such cases.

Sample output:

Just hover on the small ICON to see if a field is Mandatory/Optional/Suppressed/Display only. Any conflicts found should get reported in the error log in tool bar.

In case of conflicts, priority would be given in the sequence below with the exception of Required and suppressed combination which is not allowed.

1. Suppressed
2. Display
3. Required
4. Optional

Third option provided by this tool is, “where used list of G/Ls”. This would help to Identify in what all scenarios a G/L has been configured in the system.

From the main screen of OMWB, click on where used list of G/L.

Enter company code and valuation area in next screen and execute.

Sample output:

This output shows the list of valuation classes and transaction keys a G/L has been assigned to.

Hierarchy is as below.

Chart of accounts

                |-G/L account

                                |-Valuation class

                                                |-Transaction event key

                                                                |-Account grouping code

Hope this information would be helpful in your projects

Your valuable feed back/comments are much appreciated.

Regards,

V V

As a functional consultant, we might have seen SPRO screen day in and day out. But, many of us may have missed to notice, there are many additional functionalities available in SPRO. Usually, we just run to the node where we wish to do the changes, complete required changes and rush for testing.

Through this blog, I would like to bring to the notice of fellow community members about many unnoticed functionalities available in SPRO.

1. How to find the list of tables that are updated through particular SPRO node?

Place cursor on the node where changes are being done and go to below path in SPRO.

In next screen, double click on underlying view.

Note: Usually last 4 letters of IMG activity ID is transaction code for that node.

Select other view and double click on Piece list option.

Next screen shows the list of tables that are updated under this node.

2. How to Search in SPRO?

Looks pretty straight forward option right? I am sure everybody must have already used this option.

But did you notice “Text Index info” in the search popup?

SAP search engine uses Indexing concept. We can correlate this to normal text book index. Index have the address number of a topic like page number. Similarly, SAP stores the database address of the nodes of SPRO. When search is done, system would first go to this Index data and find the position of the node in SPRO path. Then respective node would be pointed out. If multiple addresses are found for the search word, complete list is displayed in popup. We can further navigate by selecting appropriate item.

System has the information on when was last index generated. If we have implemented some patches/upgraded system to next version, we may face issues with search engine. In this case, just regenerate the Index. It is suggested to do this activity in background with the support of BASIS team.

3. Expand all:

This option will expand all the sub-nodes of a particular parent node.

4. Position:

This helps in scrolling down a node to topmost row. Place the cursor on the node and click on position. This action moves the node to topmost row.

5. Change logs:

Precondition for this functionality is, change logs are active in system. For the reasons related to performance and database optimization, change logs are usually activated in development system only.

This displays list of all changes done in the node with details like date, time, change done by user ID etc.

Enter appropriate selection parameters in next screen and execute.

If the node has multiple tables (How to find was discussed earlier), select the required object in the popup and proceed. Output would show the changes done in the selected period and object.

6. Additional information:

Document name: This is the name of the documentation key with which IMG documentation is stored.

IMG activity: Each node of SPRO is stored with the key field as IMG activity name. This is the unique key to identify a particular node in SPRO.

Attributes: Each SPRO node has different attributes. These attributes are stored with key field attribute key.

E.G.: If a node is critical/non-critical, mandatory/optional, is it country specific etc.

Maintenance object: This shows the name of the maintenance object which has the information of list of tables/views which are updated through that node.

Enhancement ID: This is used to enhance SPRO/add any custom paths in SPRO.

E.G: If you want to add some custom add-on to SPRO paths, you can enhance it with this option. Check t-code S_IMG_EXTENSION for more details.

Release notes: By selecting show notes, we would see small ‘i’ Icon beside the SPRO node. Clicking this would list the component names and respective release version through which this node was created/changed.

Other attributes:

Below attributes are self-explanatory. Name itself says what that option stands for.

BC Sets:

BC sets (Business configuration set) are used for collecting the customizing settings. They can also be used for a group  rollout, where the customizing settings are bundled by the group headquarters and passed on in a structured way to its subsidiaries. SAP has delivered BC sets for some standard industry processes. We can create custom sets as well. Please check out below WIFI which has detailed information about this.

http://wiki.scn.sap.com/wiki/display/Basis/Business+Configuration+Sets+(BC+Sets)+and+their+use

Business add-ins: This option would display, if there are any BADIs available for a node.

Translation: This is used for maintaining translations for the text fields available in a node (If applicable).

Hope you enjoyed reading this and got to know some new things

Please feel free to share your feedback.

Thanks,

V V

You use this program in new General Ledger Accounting to perform closing and opening entries for a change in fiscal year.

Note

For classic General Ledger Accounting, you use the program: Year-End Postings (RFSUMB00).

For New GL use the program:  FAGL_YEC_POSTINGS or FAGL_YEC_POSTINGS_EHP4

This program creates the following postings:

• Postings for year-end closing of the profit and loss statements for the fiscal year result

Account Selection  Parameter:      E      1st Run: P&L Accounts

• Postings for closing and opening the balance sheet accounts for the new fiscal year

                        Account Selection  Parameter:      P      2nd Run: Balance Sheet Accounts

In this program, the postings are created in real time using the interface to Accounting (with reference transaction AWTYP Reference procedure      = GLYEC          Year-End Closing Doc).

The totals records resulting from the closing and opening entries are updated with RRCTY Record type = 5 to be able to distinguish them in reporting from totals
records from operational postings (record type 0). The postings are made using the account assignments in the totals record table.

To summarize balances using specific account assignment characteristics, you can use the Business Add-In (BAdI)

Summarize Balances Using Account Assignment Characteristics.

Note

Validation is not performed for transferred account assignment characteristics.

You can choose between the following country versions of the program:

• Italy        SAP&ITALY      Standard Variant for Italy

• Slovakia SAP&SLOVAKIA Standard Variant for Slovakia

• Turkey    SAP&TURKEY              Standard Variant for Turkey

• Portugal  SAP&PORTUGAL      Standard  Variant for Portugal

• Romania SAP&ROMANIA          Standard      Variant for Romania

• France  SAP&FRANCE  Standard Variant for France

• Colombia  SAP&COLUMBIA    Standard Variant for Columbia

When creating your own report variants, always use the respective system variant SAP&* as a template.
Parameters that are set in the background in these system variants influence how the report performs postings. To ensure that the posting logic meets the
legal requirements for the respective country, you should always start the report with the respective system variant or with a modified copy. The standard
delivery corresponds to the posting logic for Italy.

Prerequisites

You must fulfill the following prerequisites before you can execute the program:

• The accounting  reconciliation of last fiscal year has been printed out.
• The posting periods for posting the year-end closing and for opening the current fiscal year is open.
• The last transaction for the balance sheet has been performed.
• Apart from the special periods for closing entries, the posting periods of the last fiscal year are closed.
• The accounting reconciliation of current fiscal year has been printed out and the totals have been validated.

Customizing prerequisites: 

Closing/Opening Postings (Specific Countries Only)    
Define Account Determination

 
Table: TABKT

You need entry’s in table TABKT before you can start the report we need dummy account for Vendor end Customer postings

For the account determination, you have to assign a dummy customer or vendor account to your reconciliation accounts. Your closing/opening postings are posted to these accounts.

For reconciliation accounts for special G/L transactions you have to enter the special G/L indicator.

Requirements

Before you can assign a ummy customer or vendor account to a reconciliation account, you must have reated this dummy account with master data in the required company code. You ust be able to post to the account directly.

Activities

To assign a dummy ustomer or vendor account to a reconciliation account, proceed as follows:

1. Choose New Entries.
2. Enter the company code for which you ant to make the assignment.
3. In the field G/L Account, enter the umber of the reconciliation account, and in the field Account Type, enter the account type for the reconciliation account (customer or vendor).
4. In the field Customer or Vendor nter the account number of the dummy customer or vendor account.
5. In the field Sp.G/L, enter the indicator for a special G/L transaction.
6. In the fields Debit and Credit enter the posting keys for the debit and credit postings to the dummy customer or vendor account.
7. Save your assignment.

Features

Year-end closing entries for profit and loss statements

The program saves the annual net profit or loss in table FAGL_TRVOR as the comparison value for closing the balance sheet accounts.

Note

In Turkey, you have to close account group 7 separately. To do this, use the program Turkey: Closing Account Class 7 (RFIDTRCLACCL7).

Since the postings are made using the reference transaction GLYEC, you can make postings directly to G/L accounts for which the Post Automatically Only
indicator is selected. You cannot enter any other characteristics or account assignments.

Before performing the program in an update run, ensure the following:

• No other postings are made in your system at the same time.
• For  the postings with this program, you use a separate document type with its own document number range. This enables you to clearly identify this type
        of posting in reporting (document journal).

Run the  Program with the following Parameters for opening postings 2013

Select your company code - fiscal year 2012 base for the opening postings 2013

Accounts Tab

The procedure is as follows regarding to the P&L Accounts:

• 1st Step: Closing balances of revenue accounts are 'moved' to  REA (retained earnings account) defined in the customizing OB53. Closing
  balances of expenses accounts are moved also to REA.
• 2nd Step:  The total debit balance of REA is moved to CLosing PL account - defined as paramater  1 in the tab Accounts of the report. The
  total credit balance of REA is moved to debit side of the  Closing PL account.
• 3th Step: The total balance from the Closing PL account is moved to  Net Result Account defined as parameter  2 in the tab Accounts.

Postings

Go in tab Postings use two Document Types 

One for the Closing and one for the Opening 

Start the report and generate the postings.

In the Log you can see the selected accounts with the total amounts and the totals what the program would post.

I would like to introduce you to the SAP ERP Financial Accounting Learning Room, a key feature of the new and expanded SAP Learning Hub offering from SAP Education.

The SAP Learning Hub gives you access to a wealth of materials a lifetime is hardly enough to go through. And it is expanding as technology develops. As immensely useful and important it is to have access to knowledge, it is equally important to have guidance and help when navigating the materials, it is also much more engaging to have others to learn with and from. Enter the Learning Rooms.

Learning Rooms are special on-line sites (think enhanced forums) dedicated to a particular class, curriculum or topic. A Learning Room moderator with expert knowledge (in this case me) will post the room’s objectives* and guide participants through achieving them. The learning rooms are an offering tied to the SAP Learning Hub. This means that when you subscribe to SAP Learning Hub  you can subscribe to Learning Rooms as well (yes, for no additional fees).

There is a plethora of Learning Rooms you can subscribe to. I will be the instructor/facilitator for the Financial Accounting Learning Room. Financial Accounting with the SAP ERP Application is a cornerstone of almost all SAP ERP implementation projects. The fact it’s been around almost since the beginning doesn't mean that it hasn't evolved and improved and it certainly doesn’t mean it is less important than ever. Whether you want to gain a foothold, refresh your knowledge or learn about the new functionalities of Financial Accounting with the SAP ERP Application, this learning room is relevant to you. We will be covering all material needed to achieve the C_TFIN52_66 SAP Certified Application Associate - Financial Accounting with ERP 6.0 EhP6 certification.

Watch the video below to find out more, and read these key related resources right here in SCN:

·         Learning Rooms: Social Learning with SAP Learning Hub

·         SAP Learning Hub FAQ

*Financial Accounting Learning Room Objectives:

•  Gain a fundamental understanding of the financial accounting functionality in SAP ERP, with an ultimate objective to apply this knowledge as a solution consultant in a team setting.

•  Ask SAP ERP Financial Accounting related questions and complete relevant assignments to help you better understand this topic and course materials.

•  Interact with online instructors from SAP and other learners.

•  Prepare for taking the C_TFIN52_66 SAP Certified Application Associate - Financial Accounting with ERP 6.0 EhP6 certification.

1) Different types of Processing Types in FF68.

2) How to delete statement record saved in FF68.

1) Different types of Processing Types in FF68.

Below are the different types of processing types in Manual entry, I am going to show its controls and system behavior.

1:Further processing as batch input (generate online)

2: Further processing as batch input (generate as batch)

3: Further processing as background job

4: Further processing online

1:Further processing as batch input (generate online): in this process when you click on save system will show message (statement/list posted) and creates a batch input session, shows the statistics.

Next step> Execute batch process to post a document.

2: Further processing as batch input (generate as batch): in this process when you click on save system will show message (statement/list posted) and creates a batch input session, it will not show the statistics.

Next step> Execute batch process to post a document.

3: Further processing as background job: in this process when you click on save system will show message (statement/list posted).here system posts document through background.

If you check in FEBA_CHECK_DEPOSIT you can find document number highlighted.

FB03 Document number

4: Further processing online: in this process when you click on save system creates document and shows the statistics.

Now

2) How to delete statement record saved in FF68

Note: Delete the manual entry list before running batch process, don’t delete after created accounting document.

Below is the process to delete, we can delete list entered in ff68 using program RFEBKA96.

  Save a statement record in ff68 below screen is an example

Go to SE38 and program RFEBKA96 and Execute

In the below screen select 0002

Select your Group number ‘2222’

Select the tick box at left hand side

Click on yes

Now you can see details the record has deleted from the tables.

Regards,

Sada Bandla

Head Office and Branch Accounts

In some industries,branches of a company sell their goods independently but the accounting for these sales is performed centrally (at the head office). You can represent this type of organizational structure in the R/3 System by using head office and branch accounts.

First you need to create head office and branch accounts. The sales orders are managed in the branchaccount. The sales and transaction figures, however, are not posted to this account but rather automatically to the head office account. Payments are cleared centrally by the head office, meaning that outgoing payments can be made for several branches in one step, using the head office account.

Link between Branch Accounts and Head Office Account

To link branch accounts to a head office account, you must enter the number of the head office account in the Head office field in the branch account master record. This field is contained in the company code area of the master record.

The head office account can be any vendor account except one-time accounts or branch accounts themselves. Branch accounts and head office accounts must belong to the same company code.

VENDORS :

Headoffice

Branch

Line Item Display

When you are entering the parameters for line item display, you should note the following: for head office accounts, enter the key 004 in the field Sort key. This instructs the system to display the line items for the head office account sorted by branch. This key is defined in the table for allocation rules.

Invoice posting to branch vendor

Document gets posted in the head office with branch in assignment field

FBL1n shows in head office account

FBL1n for branch account gives below message

Clearing

FBL1n for all branches under the headoffice

Payment run

FBL1N after payments

Correspondence

You can set up your system to cater for written correspondence with vendors a) for the head office, broken down per branch or b) for each branch individually. If you want to create correspondence (such as dunning notices and account statements) for the individual branches instead of the head office, you have to select the Local processing field in the vendor master record of the head office on the Create Customer: Correspondence screen.

You can also define payment methods in the master records of the branches and head offices. For example, if you want to have certain payment methods for particular branches, enter these in the master records of the branches concerned and do not enter any payment method in the head office master record. If you enter payment methods in both head office and branch master records, all payment methods are possible.

CUSTOMERS :

Head office customer

Branch office

Invoice posting to branch customer

Posted successfully to the headoffice customers with branch details

Dunning run for headoffice customer

Headoffice customer successfully dunned

Important Notes :

> At Branch accounts system will not allow you to check clearing with customers or vendors. This has to be done at headoffice level

> All the dunning notices related to the branch go to the head office account and the payments (both incoming & outgoing) are made by the headoffice. However if you want the make the dunning and payment programs use the branch account instead, you need to select  "decentralized processing" field in
"correspondence" tab in the head office master data.

Hi All,

I have been getting a few requests lately from users for information relating to the use of the transaction FAGL_ACTIVATE_OP (report FAGL_SWITCH_TO_OPEN_ITEM). I am starting to put together a document on this topic in Wiki Format.

If you have any questions/topics/suggestions etc in relation to this transaction and its use, please let me know and I will be sure to include it in the document.

You can make suggestions by commenting on this blog post and I will add your comments to the list.

Kind regards,

Declan

After reading several posts, I come to the point that most of the company having single excise GL account and want to post excise on plant wise Profit center.

In FAGL3KEH or 3KEH we can assign profit center CC wise (Means one GL can be assign one Profit center)

That’s why excise utilization goes to single profit center in case we are using single Excise GL in to more than one plant.

We are aware the function of user exits and substitutions, some time we use substitution for this requirement by creating number of substitution.

Some time we also used user exit as per own logic to derive plant wise profit for excise account.

Requirement- We have N number of plant in one Company code and we use common Excise GL for all plant , but we need profit center derivation by plant. 

Here I am going to explain User Exit to derive plant wise profit center

Step1.Create Z table with two field Plant and profit center (Here you can add field as per your requirements like Company code)

Step2. Check assigned program in Appl. Area GBLS by Transaction code - GCX2

Please copy this program in case standard

Step3. Create substitution by Transaction code – OBBH

Here if Company code = XXXX than substitute by exit

Step4. Write an exit in program which is assigned in Appl. Area GBLS.

For eg in Program –ZRGGBS000_N

Exit 

Details –

Here SY-TCODE(Transaction code ) = J2IUN or J1IH

IF BSEG-WERKS (Plant ) is not initial

Select single PRCTR (Profit center) from Z table in to BSEG-PRCTR (Profit center)

Where WERKS (Plant) = BSEG-WERKS.

Overview

Investment Management is a sub module of SAP FI. It provides functions to support the planning, investment, and financing processes for capital investments (such as fixed asset acquisition), projects (such as new advertising program) and maintenance programs.

This document explains how we can use Investment Management for planning and management of fixed assets. The complete flow has been divided in 4 parts - Configuration, Master Data, Transaction and Settlement.

1. Configuration

1.1 Create Investment Program and Structure

a.Create Investment Program - In this step, an investment program is created which is used to track budget at asset level.

SAP transaction code – IM01

b. Create Investment Structure - Once the investment program is created, then the next step is to create the investment structure. This is important to        categorize different assets based on its usage.

SAP transaction code - IM22

1.2 Configuration in Asset class for Investment Management - For the purpose of activating investment management for Asset, asset class status should be     selected as “Investment Measure” in Asset under construction asset class.

This is important configuration at asset class level and will ensure that assets under construction in this asset class can be created solely in relation to     capital investment measures.    

SAP transaction code – OAOA

1.3. Create investment profile - The investment profile is assigned to an internal order or work breakdown structure element, and then these objects are designated as capital investment measures. We have the option to select settlement based on summary settlement or line item settlement. By selecting the summary settlement option all the debits on investment measure will be settled in summary form to various assets while settling the investment measures. By choosing this option we can’t break down the values of individual line items. Line item wise settlement can also be possible by choosing the option of line item settlement.

2. Master Data

2.1 Create investment Order - Investment order is used as reference for Asset acquisition. Enter the order type and controlling area in the initial screen. Press ENTER and give necessary details.

SAP transaction code KO01.

2.2 Assign Budget to Investment Program - In this step, the overall budget at investment program level is allocated. This is important to track the investment at individual item level.

SAP Transaction code - IM32

2.3 Assign Budget to Investment order- In this step, we assign budget at each investment order level under the investment position. This helps to control the investment under different categories.

SAP Transaction code - IM52

2.4 Assign Yearly Budget to Investment order - Once the overall budget at investment order level is allocated, the next step is to assign yearly budget to investment order. Asset acquisition will not be successful unless this step is completed.

SAP Transaction code – KO22

3. Transactions

After completing configurations and master data details, the next step is to post transactional data in SAP. We can post the business transactions in either of the below mentioned ways:

1. Creation of Purchase order and posting of goods receipt and other MM (material management) transactions with reference to investment order.
2. Posting of direct FI postings on the investment order.

4. Settlement

After all the above steps and once the invoice has been created for the asset procurement, the investment order is settled to AUC from which it is settled to Fixed Assets. The depreciation run can be done only when AUC is settled to fixed assets.

SAP transaction code – KO88

Hopefully this blog will be helpful.

Regards,

Gaurav Tibrewal

This Blog having impact test reults in FI and SD side if change the payment terms for open sale orders or already posted (Old sale orders) sale orders and this is blog will give clearance with detailed impact analysis also along with step wise.

Solution:-

Step.1 If Change the payment terms at customer master level without changing in Sale order

Before changes

1. Sales order display – VA03 30070974

Note: New payment term is not changed in Sale order.

2. Customer master display – XD03 100038 2

Note: New payment term is not changed in customer master.

After changes

1. Go to XD02 transaction code to Change the customer master Click on Sales area data.

Note: Go to Billing document tab and change the new payment term in customer master

2. Display the Billing document– VF03 625123742

Note: New Payment term not changed in billing document after change the payment term in customer master with out changing the new payment term in open sales order.

3. Financial document display:

Note: New Payment term not changed in financial document after change the payment term in customer master with out changing the payment term in open sales order.

Step-2. If Change the payment terms at open sale order level.

Before change

1. Sales order display – VA03 30070974 6

Note: New payment term 2003 is not changed in Sale order.

2. Customer master display – XD03 100038 7

Note: New payment term - 2003 is changed in customer master.

After Changes

1. Sales order change – VA02 30070974

Note: New Payment term 2003 changed in sales order.

You can see in sale order ,there is no change in the price since we changed the new payment terms -2003

2. Sale order document flow.

3. Display the Billing document – VF03 625123743

Note: New payment term - 2003 changed successfully in billing document after change the new payment term in Sale order.

3. Financial document display:

Note: New Payment term 2003 changed in financial document after change the payment term in Sale order.

Hope this document will helpful with out doing R and D from your side ,Can change new payment term in sale order based on impact test results.

Thank you.

Sudharsana Vamsi

-----------------Document End------------------------

Most of us are comfortable with SD-FI-COPA integration concepts as it is easy to correlate and understand. But, when it comes to MM-FI integration, many of us find difficulties in understanding the concepts and account determination process. When I was trying to analyze my first issue related to how a stock account is determined in a valuated transaction, I was lost in OBYC. Let us try to understand few terminology used in MM-FI integration concepts. Once we are familiar with the concepts, we will further discuss account determination process in a stock movement related transaction.

Valuation area:

Stock of a material owned by a company is an asset to the company. Valuation area defines the organization level at which materials are valuated.

SAP has provided two options for valuation.

1.     Valuation at plant level: All materials are valuated at plant level.

2.     Valuation at company code level: All materials in all plants of a company are valuated at company code level.

This setting is defined in t-code OX14.

Valuated stock:

Total valuated stock = Stock in unrestricted use + Stock in transit between storage locations/warehouses of a plant + Stock in quality inspection.

Material type:

This defines the type of material.

EG: Raw material, Finished goods etc.

Material type is defined during material master data creation.

Movement type:

This defines the type of material movement from one place to other. Movement type enables the system to find predefined posting rules determining how the stock and consumption accounts are to be posted. All possible goods movements are already defined by standard SAP

EG: Movement type 101 refers goods receipt

Movement type is entered while posting stock movement related transactions. Most of the time, standard SAP automatically derives the movement type based on transaction code.

EG: If we go to MIGO, default movement type 101 is displayed by system.

Valuation class:

Valuation class is defined for the combination of plant and material (In Accounting 1 view of material master).

Valuation class allows posting of stock values of

1.     Materials of same material type to different G/L account (Different valuation class is assigned in different plants for the same material)

2.     Materials of different material type to same G/L account (Same valuation class is assigned to materials of different material type)

Note: G/L accounts can be defined at valuation class level along with other parameters.

Valuation grouping code:

Valuation grouping code combines the valuation areas having same business properties for the account determination. This reduces number of entries to be created for automatic account determination for the stock postings.

EG: Valuation area 1 and 2 are required to be posted to same G/L account, these are grouped to valuation grouping code ABC and G/L is determined based on valuation grouping code and valuation class.

Before using valuation grouping code, it needs to be activated in OMWM.

Valuation grouping code is assigned to valuation area in t-code OMWD.

In below example, five valuation areas are assigned to same valuation grouping code.

Account modification/General modification:

This key is used to determine different G/L account for the same kind of goods movement based on origin and target.

EG: During Goods issue, offsetting G/L is determined from transaction key GBB. If business wants to post to different G/Ls for goods issue for cost centers (Movement type 201) and good issues to orders (Movement type 261) for the same material and plant, Account modifier can help here. To understand this better, let us go to t-code OMWN where we define the transaction key and account modification for the movement type.

Transaction key which we see in OBYC is determined based on the movement type. In below screenshot, you can see all parameters are same for movement type 201 and 261 except account modification.

Please read F1 help on different fields in this screen to know more about functionality of each field.

T-code OMWN:

When material document is posted with these movement types, offsetting account is determined from transaction key GBB based on account modifier and valuation class.

From below screenshot, you can see that, different offsetting G/L account can be determined for the same transaction key and valuation class.

By Default, Standard SAP defines account modification keys for below transaction keys. User defined keys can also be defined and respective account determination settings can be maintained.

• GBB (offsetting entry for inventory posting)

• PRD (price differences)

• KON (consignment liabilities)

Below are the modification keys defined by SAP (Extracted from F1 help).

Modifiers for GBB

For the transaction/event GBB (offsetting entry for inventory posting), the following account groupings have already been assigned to the relevant movement types:

• AUF: for goods receipts for production orders with account assignment
• BSA: for initial entries of stock balances
• INV: for expense/revenue from inventory differences
• VAX: for goods issues for sales orders without account assignment object
• VAY: for goods issues for sales orders with account assignment object
• VBO: for consumption from stock of material provided to vendor
• VBR: for internal goods issues (e.g., for cost center)
• VKA: for consumption for sales order without SD
• VNG: for scrapping/destruction
• VQP: for sampling
• ZOB: for goods receipts without purchase orders
• ZOF: for goods receipts without production orders

Modifiers for PRD

If you also activate account grouping for transaction/event PRD (price differences) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

• none for goods receipts and invoice receipts for purchase orders

• PRF: for goods receipts for production orders

• PRA: for goods issues and other goods movements

Modifiers for KON

If you also activate account grouping for transaction/event KON (consignment liabilities) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

• none for consignment liabilities

• PIP: for pipeline liabilities

How are the account determination attributes determined for each transaction key/event?

Did you observe different set of fields appears for different transaction keys in OBYC while maintaining G/L account? Yes. This is defined in Rules for the transaction key.

EG: Select transaction key AUM in OBYC and click on "Rules" in toolbar.

You can see that general modification and valuation modifier is active.

If you go to G/L account maintenance for this key, you would see the same fields.

Quick snap of MM-FI Integration process:

When we do material posting for a valuated material, below flow happens.

1. Movement type and other attributes like special stock indicator, movement indicator etc are determined based on business transaction like goods                       receipt for PO, production order etc.(OMWN). This is defined by standard SAP.

2. Transaction key/event and account modifier is identified based on movement type and other standard attributes in step 1 (OMWN)

3. Valuation grouping code activation is checked from OMWM

4. If active, for the given valuation area, valuation grouping code is identified from OMWD

5. For the identified transaction or event, check if valuation grouping code is active or not in OBYC (Click the rules button for the transaction key)

6. Valuation class is determined from material master.

7. Based on the above identified attributes, select the G/L account from OBYC.

If system can’t find any account for the found attributes, stock posting can’t be done and system through clear error stating for which combination of attributes, G/L account is missing. Such errors are mostly seen during go live/while posting to new materials due to missing G/L account maintenance or due to incorrect valuation class in material master data.

Now you know the process, here is the short cut to find out G/L.

Account determination details are stored in table T030. If you want to know based on what details XXX account is determined, simply give that G/L in T030 table in fieldKONTS. This gives the possible combination of entries where this G/L is assigned. We can further drill down based on the filtered entries.

Please share your valuable feedback, thoughts and add additional information/corrections if any

Check out the next blog in this series.

MM-FI integration: Account determination simulator

Thanks,

V V

Are you facing difficulties in finding out correct BTE to implement for your custom requirements? Doing extensive search over net/SCN? Not required now!!!

Yes, SAP has already given awesome “BTE search tool” which many people are unaware. I came across this interesting tool during my R&D and found it very helpful.

Hence, sharing this with the community.

Before we go on how to use this tool, let us go through little basics of BTE.

Business transaction event is delivered by SAP to code customer specific requirements during predefined standard processes. Call points are already defined by SAP. All we need to do is just plug in our code in the BTE based on our requirements and SAP would play it during standard process

Business transaction events are of two types.

Process BTE:

Process BTEs are called at a fixed, predefined points during the standard SAP program flow at which the system can process user defined/custom function modules instead of the standard function module. The pre-conditions/rules for calling up alternative processes are defined in the  customization of BTEs in t-code FIBF. There would be standard function module OPEN_FI function module assigned by default by SAP. If there are no custom function modules assigned in FIBF, standard function module is processed. Data and process flow of standard SAP can be changed in BTE.

OPEN_FI function module select the FM to be processed for P/S BTE.

Function module PC_FUNCTION_FIND determines the function module to process from the following tables (equal priority):

a) TPS34 Customer-Specific Function Modules

b) TPS32 Partner Function Modules

c) TPS31 SAP Function Modules

d) TPS01 Standard Function Module

Publish & Subscribe (P/S) BTE:

P/S BTEs are called at a fixed, predefined points during the standard SAP program flow. Data can only be published to another application through P/S BTE i.e. we can only export the data to P/S BTE. Changes to program flow or data can’t be performed here. The pre-conditions/rules for calling up alternative processes are defined in the  customization of BTEs in FIBF.

OPEN_FI function module select the FM to be processed for P/S BTE.

Function module BF_FUNCTIONS_FIND which is called inside OPEN_FI function module determines the function modules to process from the following tables:

a) TBE34 Customer-Specific Function Modules

b) TBE32 Partner Function Modules

c) TBE31 SAP Function Modules

(Source: Partly from F1 help)

How to search BTE:

Assume you have business requirement to implement a custom functionality to send an SMS alert to customers when dunning run is done. Since standard SAP does not have such functionality,

You can look for BTE for this.

Go to below t-codes

BERP: To search for process BTE

BERE: To search for P/S BTE

Both t-codes have same selection fields.

Select the attribute type A (Application component) and click F4 on selection attributes field.

In the next popup, drill down to the process area you are looking for. The paths displayed here are similar to SPRO path.

Select appropriate node. In this case it is DUNNING.

Path would come as shown below.

You can further restrict the search by entering other selection parameters which are self-explanatory. Now execute the program.

Output would show the list of available BTEs for the given node. Most of the times, description of the BTE says functionality.

Select appropriate BTE and use below tool bar options to explore further. We can see the sample FM delivered by SAP, interface of the BTE, Documentation etc.

Custom FMs can be created with the same interface as of sample FM. One common error seen while implementing the BTE is, custom FM interface may differ than standard FM interface.

In this case, the process would go for dump. This is because, SAP determines the FM name during run time (Dynamic call).

Similarly, search can be done based on other parameters like based on Business object name, IMG nodes etc.

You are welcome to post your comments and feedback on this blog

Regards,

V V