Quantcast
Channel: SCN : Document List - SAP ERP Financials
Viewing all 366 articles
Browse latest View live

Transfer Legacy Assets using SECATT scripts

$
0
0

Key Concept

Legacy data transfer is the transfer of existing data maintained for assets from a previous system or from a manually maintained fixed asset register. The transfer of legacy data is generally the first thing after you configure the Asset Accounting component. This task involves transferring asset master records and transactions from the start of the fiscal year up until you go live.

Reconciling the balance sheet accounts takes place later in a separate step.

 

Introduction and Prerequisites

Now, suppose the Acquisition value is managed in Manual Acquisition account and Deprecation is managed in manual Deprecation account.

  • For understanding purpose let’s take the Manual Acquisition account as 10550001 and Manual Deprecation account as 11550001.
  • Our aim is to create assets in SAP and transfer the manual Acquisition balance to asset sub ledger and manual Deprecation balance to Deprecation sub ledger.
  • For understanding purpose let’s take Sub Ledger Acquisition account as 10560000 and Sun Ledger Deprecation account as 11560000.
  • Fiscal Year – July to June

Setup Process

 

1) Activate Company Code

The company code for which the assets accounting has been configured and to which the data has to be transferred will be activated i.e. it will be made open for transfer as below:

Path: Financial Accounting>Asset Accounting>Preparing for Production Startup>Production Startup>Activate Company Code

1.jpg

                                             Figure1: Activate Company Code for Transfer

2) Asset Transfer Date Settings

 

Transfer Date has to be configured in the system for the company code. For instance actual transfer will take place on 09/30/2013.

 

Path:Financial Accounting>Asset Accounting>Asset Data Transfer>Parameters for data Transfer>Date Specification>Specify Transfer Date/Last Closed Fiscal Year

2.jpg

                                                       Figure 2: Set Transfer Date

 

 

Based on Transfer Date we need to configure the settings for the period in which last depreciation was posted. For instance if the Transfer Date is 09/30/2013 then the last Period in which depreciation was posted would be 3, FY14.

Path:Financial Accounting>Asset Accounting>Asset Data Transfer>Parameters for data Transfer>Date Specification>Specify Last Period Posted in Prev. System

3.jpg

                                        Figure 3: Set Last Period of Depreciatin Posting

 

Transfer Process

After the settings have been done the assets will be transferred, which means new assets shells will be created in SAP and required information will be updated.

We can use LSMW or SECATT scripts to load the assets into SAP. Here I have demonstrated the process with SECATT scripts.

 

Asset Transfer will be done in 2 stages:

  • Previous Years Acquisitions (Assets Acquired till Period 12, FY13 i.e. on or before 06/30/2013)
  • Current Year Acquisitions (Assets Acquired between Period 1 to Period 3, FY14, i.e. between 07/01/2013 to 09/30/2013)

 

Perquisites: Transfer Date has been set to 09/30/2013 as shown in Setup process.

1) Previous Years Acquisitions (Assets Acquired till Period 12, FY13 i.e. on or before 06/30/2013)

a.     Fields in the SECATT script

tab1.jpg

                            

b.     Data used for executing the script

tab2.jpg

c.     Asset Display

4.jpg

                                                        Figure 4: Asset Display

d.     Display of Asset Values for 2014

5.jpg

                                                       Figure 5: Display Assets Values

 

2)    Current Year Acquisitions (Assets Acquired between Period 1 to Period 3, FY14, i.e. between 07/01/2013 to 09/30/2013)

 

a.     Fields in the SECATT script 

tab3.jpg

b.  Data used for executing the script

tab4.jpg

c. Asset Display

6.jpg

                                                       Figure 6: Asset Display

 

d. Asset Values

 

7.jpg

                                                       Figure 7: Display Asset Values

 

Update Accounting Entry

  • Execute report “Asset Balances” – Transaction code: S_ALR_87011964. After verifying this report we can proceed with actual accounting entry.

9.jpg

                                            Figure 8: Home Screen for Asset Balance Report

10.jpg

                                             Figure 9: Output of Asset Balance Report

  • Tcode OASV:In this screen Enter, the Balance sheet GL, accumulated GL,Profit Centre, whichever is applicable. Enter line item text.
  • The difference at the end should be equal to the Net book value.

8.jpg

                    Figure 10: Home Screen for OASV

11.jpg

                                   Figure 11: Screen after executing OASV

13.jpg

                    Figure 12: Posting done through OASV

In the same way post the document for Acumulated Depreciation also and the difference between the amount for aquisition and depreciation should be equal to Net Book value.

Conclusion

So all in all there are 3 major steps to load the legacy assets in the system.

  • Activate Company Code and Transfer Date settings
  • Transfer Assets using SECATT
  • Updating accounting inforamtion with OASV.

Vendor Consignment Process

$
0
0

What is Vendor Consignment?

 

Vendor Consignment is a process wherein the supplier provides materials and stocks them in the purchaser’s premises. The material remains in the books of the supplier (vendor) until the same is withdrawn from the stock of the consignment and put to use. The inventory gets transferred to the books of the purchaser only when the same is removed from the consignment stock. The supplier (vendor) would not invoice the purchaser initially when they come into the premises of the purchaser. The purchaser is liable to pay the supplier (Vendor) only when the stock is withdrawn (consumed).

 

Key Process Design for the Consignment process for Vendors in SAP

-         

     - Consignment has been designed as a special procurement type in SAP

-    -  The consignment stock is not valuated till the time it is consumed or withdrawn, since theoretically, it lies in the books of the supplier (Vendor)

-    -  The consignment material number is the same as that of a material in unrestricted stock in the purchaser’s books

-    -  Since the sourcing of a material can happen from multiple parties, the consignment stock is maintained at the level of each supplier or vendor.

-    -  The price of the consignment is maintained in the purchasing info records (PIR) of the info category, Consignment

-    -  When the withdrawal happens from the consignment stock of a supplier, the goods receipt in the purchaser’s books happens at the price maintained in the  purchasing info records of type consignment for that vendor and material combination.

-    - The goods receipt against a consignment purchase order is always non valuated

        

         Basic Configuration Steps for Vendor Consignment Process in SAP

 

1.       1. Activate Purchasing Info Record for Info category as Consignment. The Configuration transaction code for the same is OMEV.

 

 

PIC1.png

 

1.    2.  Configure the special procurement type 10. This is done in IMG Node:

 

IMG>Production>Material Requirement Planning>Master Data>Define Special Procurement Type

 

PIC2.png

 

3. Assign the special procurement type in the material master. The Master Data transaction code for the same is MM02. This is done in MRP2 view of the material master

 

PIC3.png

 

4. Create a purchasing info record (PIR) of the category, Consignment. This is done using the transaction code ME11.

 

PIC4.png

 

 

PIC5.png

 

5. Maintain the automatic account assignment for material posting. The below transaction need to be maintained in the configuration transaction code OBYC

-           a. Consignment Payables : KON

-           b. Expense/Revenue from Consignment Material Consumption : AKO

-           c. Offsetting entry for Inventory Posting : GBB – VBR

 

 

PIC6.png

Consignment Process Steps in SAP

 

The consignment process steps in SAP are fairly simple. It involves creating a purchase order, doing a good receipt and a withdrawal of the stock from Vendor’s books. The last step in the consignment process for a vendor is the settlement of the vendor’s liability. The steps are highlighted as:

 

PIC1.png

1.    1.  Procurement - A standard purchase order is created with item category as K using the transaction code ME21N.  There is no price which is applicable for a consignment purchase order and hence should not be entered at the time of creation of purchase order.

PIC2.png

     The goods receipt is done using the standard transaction code MIGO. The stock is posted as consignment stock without value. The same would reflect as a special stock for the vendor. Since the material lies in the purchaser’s premises, the same would be reflected in terms of quantity at a storage location as well till the time the same is consumed for use. The same can be checked in the standard stock reports in transaction code like MMBE. There is no accounting document which is created when the GRN is done in case of a consumption purchase order.

PIC3.png

PIC4.png

1.   2. Consumption – Consumption of consignment material happens when goods issue is done with item category K. The price at which the goods issue will be done will be picked from the purchasing info record which has been created for consignment for the material and vendor combination. In this particular case, to elaborate the process a production order was created and a goods issue was done with the item category K against the production order. Generally the consignment materials are part of Bill of Materials (BOM). Goods issue document is posted in such a case when activity confirmation is done for the production order through transaction code CO15.

PIC5.png

PIC6.png

     In the above case, the price is picked from the purchasing info record which would have been created for the material and vendor combination.

 

3.

1. 3.  Settlement – The next step in the vendor consignment process is the settlement of the vendor liability. This is done through transaction code MRKO

PIC7.png

     This would display the withdrawals from the consignment stock which have taken place and for which the liability for the vendor has not been created. You also have the option to check the accounting entries for the withdrawals for consumption made from the consignment stock for a vendor.

PIC8.png

 

PIC9.png

     After analyzing the unsettled withdrawals, you can create the vendor liabilities by selecting Settle from the main screen. This will settle the outstanding entry in Consignment Account Payables account and create a vendor liability. The price of vendor liability creation will happen at the Info Record Price.

PIC10.png

 

PIC11.png

PIC12.png

 

     Accounting Entries

1.       1. At the time of Goods Receipt – No Accounting entries are generated at the time of goods receipt

 

2.       2. At the time of Withdrawal or Consumption of Consignment Stock –

 

(a)             a.  The material is valuated at moving average Price (Price Control in Material Master is “V”)

 

               Consumption Account DR                 (Account Assignment OBYC-GBB-VBR)

                         To Consignment Payable A/c  (Account Assignment OBYC-KON)

 

               The unit value of material comes from the Info record Price for material vendor combination for info category Consignment

 

(b)             b. The material is valuated at standard price (Price Control in Material master is “S)

 

               Consumption A/c DR                                               (Account Assignment OBYC-GBB-VBR)

                                            To Consignment Payable A/c      (Account Assignment OBYC-KON)

                                            Price Difference A/c (Dr/Cr)        (Account Assignment OBYC-AKO)

MM-FI intergaration for beginners

$
0
0

Please find below the doc on MM-FI intergaration .

Regards

Mani

 

 

SAP Materials Management’s

Relationship to Finance

Finance in Logistics

Finance in Logistics - A look from Materials Management

The purpose of this document is to explore the relationship materials management has with accounting in SAP. We will take three swipes at this relationship. First, at an overview level, we will consider a materials management workflow scenario. Next, we will dig deeper as we create documents to support that scenario, and consider the account postings made. Finally, we will consider configuration, and show how SAP automatically posted to various accounts.

A Materials Management Workflow Scenario

Let’s consider the following map :

 

 

 

Starting from the top box, we see that a purchase requisition is created. This can be entered manually (as in the case if a secretary wants to order office supplies), or automatically via MRP (through Materials Requirements Planning, where material requirements are generated based on satisfying customer orders, production lines, and other needs). A purchase requisition would contain information about :

1.     What is being requisitioned? material / service

2.     How much? quantity

3.     When is it needed? delivery date

4.     Where will it be delivered? plant, storage location

5.     How will it be used? item category

6.     How will it be paid for? account assignment category - this may also state how the material/service will be used, as the account assignment may be a sales or production order(for example).

A P.Req. may have to go through a release procedure in order to be converted into a purchase order. At this point, suffice it to say that SAP has ensured that employees do not get to acquire materials just because they have nice smiles.

Next, it is up to purchasing to determine a vendor for this requisition. In SAP, the purchasing department has several options : source lists, purchasing info records (material-vendor records), quota arrangements, and vendor master records. A vendor may also be selected based on price quotations attained by the purchasing department.

A purchase order may now be created. Note : in the standard configuration, a purchase requisition is not required in order to create a purchase order. The same information entered in the purchase requisition is entered in a purchase order (note items 1 through 6), plus a purchase order would have a specified vendor.

Purchase order follow-up depends on the purchasing organization. In some organizations, confirmation of a received PO is required. The confirmation could then be a signal to the receiving dock to expect goods on a certain date. Follow-up might include further negotiation, such as price, quantity, or delivery date changes.

A goods receipt for the purchase order is now entered. In the standard configuration, a goods receipt does not require a PO, or any other type of order. With valuated materials, a goods receipt will now cause an account entry. This account entry will typically be against a stock (or production/sales order) account and a clearing account. More about this later. Note that to the side, goods issues and transfer postings are shown. These are also functions of a warehouse, and both can cause account postings. It is important to understand which goods movements will affect accounting and how.

Often an invoice will be received with the goods shipment, but it can be received independently. Invoice verification is the process of determining whether an invoice matches what was received. In SAP, invoices can be entered either from materials management or from the accounts payable side. Most of us would hold that it is up to A/P to enter the invoice, but who better to verify the invoice against the goods shipment and quality than MM? This issue is up to the company and project team installing SAP. The account entries made upon invoice receipt will typically be against the clearing account posted when the goods received and the vendor’s account (indicating that the vendor should be paid). The invoice may be blocked for payment for various reasons (e.g.invoiced too early, wrong quantity), but even blocked invoices can cause account postings in SAP.

The invoice can now be paid. Invoice payment is done by A/P, outside of MM. This is done by means of payment programs where A/P clerks have the ability to select which vendors to pay, the means of payment, and whether or not to block payment (based on subsequent QI, or poor relations with the vendor). The account postings for payment are typically against the vendor’s account (signifying that payment is being received) and against cash (or a bank account).

The Documents

The purpose of this section is to show account postings which relate to documents created from materials management. This will include the creation of the following documents :

1.     Purchase requisition

2.     Purchase order

3.     Goods receipt

4.     Vendor invoice

Note that RFQs and quotations will not be considered. This is because neither of these documents has an account assignment category. Their only relevance to accounting is that they specify a material (and thus a material type), and the quotation specifies a vendor and a price. With no account assignment category, however, there is no specification as to who will pay for the ultimate purchase.

The purchase requisition

The purchase requisition is created through transaction ME51 (Log > MM > Purch > Req. > Create). As mentioned, the following are determined in a purchase requisition :

1.     What is being requisitioned? material / service

2.     How much? quantity

3.     When is it needed? delivery date

4.     Where will it be delivered? plant, storage location

5.     How will it be used? item category

6.     How will it be paid for? account assignment category - this may also state how the material/service will be used, as the account assignment may be a sales or production order(for example).

This is shown on the following screen :

 

As mentioned, neither the vendor, nor the material price is specified in the requisition. A vendor can be specified in a requisition which has been "allocated", but that’s a separate story.

The purchase requisition has no direct account postings. When a purchase order is created with reference to the requisition, the account assignment (category) and the material items are carried over. As of 2.2, the account assignment can be changed when the requisition is converted to a PO, but not the account assignment category. (You can change the account assignment from one cost center to another, but not from a cost center to a sales order -- different account assignment categories).

The purchase order

A purchase order can be created for a known vendor with the transaction code ME21 (accessed by Log>MM>Purchasing>Purchase Order>Create>Vendor known). An un-allocated (no vendor previously selected) purchase requisition might then be referenced. Alternatively, a purchase order can be created with reference to an allocated requisition using transaction code ME58 (Log>MM>Purchasing>Purchase Order>Create>via requisition).

As mentioned, the purchase order has the same entries as a requisition, plus item prices and a specified vendor. A sample purchase order is shown :

 

The purchase order has no direct account postings. However, account postings from goods receipts and invoices made against PO’s are very much affected by accounts designated in the PO’s. As of 2.2, a purchase order’s account assignment can be changed as long as no goods have been received against the PO, and no invoice has been posted against it. (Thus, if no GR or invoice has been posted against a PO, the account assignment can be changed from one cost center to another, but not from a cost center to a sales order -- just like with requisitions).

The goods receipt (for a purchase order)

A goods receipt for a purchase order is created using transaction code MB01 (Log> MM>Inventory Management>Goods movement>Goods receipt>For purchase order). A movement type can then be selected via the menu bar, or using the list of possible entries. In SAP, every goods movement has a "movement type". The three headings of goods movements in SAP are good receipts, goods issues and transfer postings. Most goods movements will cause account postings. More will be said about that later.

With every goods movement (or transfer posting) in SAP, a material document is created. For every goods movement which affects a G/L account, an accounting document will be created (separate, but tied, to the material document). Material documents are not deleted, but they can be canceled or reversed. Thus, if a good receipt was posted with the wrong storage location and the wrong quantity, the receipt could be canceled. The cancellation will create a new material document (and probably an accounting document which will contain reverse debit/credit entries to what were entered in the first accounting document). Note, that if a goods receipt is entered for twenty-five pieces of a material, and only twenty pieces were actually received, a reversal could be entered. This reversal would be for five pieces. It would also have a material document, and the associated accounting document would have reverse debit/credit postings for the value of the five easy pieces.

The following is a goods receipt for the purchase order created in the last picture :

 

The movement type is one of the most important entries in materials management. It controls how account postings are made (as we will see), and it is very easy to overlook, as it is only a three-digit identifier. After several materials movements, one becomes familiar with common movement types (e.g. 101 - goods receipt of a PO, 201 - goods issue for a sales order, 561 - initial stock entry, and so on). The movement type will control the account postings with the aid of other parameters (such as the material type and the account assignment category).

The accounting view of the above transaction is shown in the following view :

 

Using the movement type (101), SAP’s automatic account assignment was able to determine that a debit should be made to the cost center’s account (which was specified on the purchase order), and the GR/IR clearing account should be credited. With automatic account assignment, the proper accounts with their respective "posting keys" were specified. Posting keys determine whether debits or credits are made against given accounts. More will be said about posting keys later.

The invoice (for a purchase order)

Invoices on the materials management side of SAP are entered via transaction code MRHR (Log>MM>Invoice verification>Document entry>Enter invoice). One could also enter credit memos in materials management (via a similar path to that just shown), as well as subsequent debits/credits against previous entries. As mentioned, these are usually entries made by accounts payable (A/P) clerks, but SAP allows its customers the option of entering this information in MM.

In SAP, invoices are not posted unless total debits and credits balance. New in 2.2, preliminary posted invoices can be made for invoices. In such a case, the proper PO to register the invoice against is unknown, therefore an A/P clerk can enter the invoice information, and "park" the document. Note that in "parked" invoices, no account postings are made.

Invoices can be blocked for payment because tolerances are exceeded. For example, the invoice date is much before the expected receiving date stated on a PO, thus date tolerance has been violated (it wouldn’t be the first time a date was violated). Similarly, an invoice can be entered for a quantity greater than that which was received. Here the quantity tolerance has been violated. In SAP, even though an invoice is blocked for payment, account postings are made.

With goods movements, a material document is always created, and an associated accounting document is created when G/L accounts are affected. With invoices, one accounting document is created. An itemized listing of an invoice entered with reference to the PO created for this document is shown :

 

The accounts referenced in the above picture are not posted to until the invoice document has been saved. The "accounting view" of the above saved document is shown :

 

The accounting view of the invoice reflects what the item view showed, but note that the account entries could not be made unless the invoice balanced.

Also shown in the picture are tax codes. Tax codes can be created with a simple valuated entry (which would be manually maintained by A/P, purchasing, and system administrators). Tax codes can also be maintained via an external interface. In the US, tax codes are defined by :

1.     the jurisdictional laws of the place to which the goods are shipped,

2.     the material type of the goods being shipped, and

3.     the taxability of the entity (customer) receiving the goods.

There are more than 50,000 different tax jurisdiction areas in the US (as they are defined by state, county, city, zip codes, etc.). External tax systems (such as AVP or Vertex) maintain the taxation rates for these jurisdictional areas. In 2.2, modifications have been created to interface external tax systems. In 3.0, this interface will be standard.

The account entries described in this section are shown in the following "T" account entries.

 

With the goods receipt, the debit to the cost center account (which could be the cost center’s stock account) represents an increase in on-hand stock, while the credit to the GR/IR clearing account represents an outstanding invoice approval process.

With the invoice receipt, the invoice is verified that, in fact, the goods were received, and were of acceptable quality. This invoice entry creates a debit to the GR/IR clearing account (to balance the account), and a credit to the vendor account. A credit to vendor account signifies that in order to make the account balance, the vendor must be paid (debit the vendor account). Note that if the received goods were of sub-standard quality, payment could be blocked at this point by either not entering the invoice, or (more likely), the invoice would be entered, but blocked for payment. (Invoice verification is considered the third link of "three-way matching" -- the matching of the PO, GR and invoice. The invoice verifies the purchase order price and specifications, and that the goods in the PO were received and of appropriate quality)

The payment of the invoice is the final link in the workflow chain. The vendor is paid (account debited), and cash is decreased (credited). In SAP, maintenance of vendor payment is outside of materials management, but with an integrated system, it is coordinated.

Automatic Account Assignments in Materials Management

Consideration of automatic account assignments in MM will be approached in two steps, according to the accounting documents created in the last section. First, we will pursue the account postings made by goods movements, then we will consider account postings made by invoice entries.

Account postings through goods movements

Let’s start from the basics. As mentioned, with each goods movement there can be an associated account posting. Where are these account postings maintained? A good place to first look is table 156s. This is accessed by table maintenance (SM31), entering "T156S", and hitting either the "Maintain" or "Display" button. The following table is then presented :

 

This table shows configuration information based on all the movement types (hundreds) in SAP. For our discussion on account postings, we do not need to concern ourselves now about the entries in the column and to the right of "SLoc".

From the fields shown, a quantity string and value string are determined. Note, that it is the combination of all the appropriate fields which makes this determination. The quantity string determines which quantity fields are updated (through a sequence of instructions), and the value string determines which account posting keys will be signaled (also through a sequence of instructions). Therefore, in order to determine which quantity string and value string are to be referenced for each goods movement, the significant fields of table 156S are now defined from left to right, the following fields have the following meaning :

Movement type - the three digit code associated with a goods movement. It must be specified with every goods movement.

Value update indicator - every material type is designated as to whether or not the material value is updated during goods movements. Thus, the value update indicator signifies if the account posting can affect the material account.

Quantity update indicator - every material type is also designated as to whether or not material quantities are to be updated during goods movements. Note that the the material type’s quantity update indicator and value update indicator must match a line entry in order to use the associated quantity and value strings.

Special stock indicator - this field indicates who owns the material and who gets the material. For example, the indicator might be blank (" "), where the stock is taken by the user in their plant. The indicator might be "K" (for consignment), where the vendor owns the material, but the stock is taken into the user’s plant.

Movement indicator - This specifies the type of order the goods movement might be against. For example, the movement could be with reference to a purchase order, a delivery note, or with no reference.

Receipt indicator - This field is currently not used. In the future, it is expected that specification will be possible to determine if this movement was for a stock transport order or an outside purchase order

Consumption posting indicator - this field is used in the case of goods receipts for purchase orders, and is defined from the account assignment category in the PO. Thus, in our previous example, the account assignment of "K" (for cost center) in the purchase order ensured that the receipt debited the cost center’s account, and not the stock account.

So with the right combination of these seven (actually six) entries, we determine quantity and value strings. The quantity string is handled very similarly to the value string. Quantity strings are maintained in table 156M (accessed via SM31 and display/maintain "T156M"). In the last picture, the quantity string for the top entry is ME02. In table 156M, the quantity string indicates if orders are to be updated and other relevant quantity information. This table will not be analyzed here.

Value strings are handled in table 156W (accessed via SM31 with display/maintain "T156W"). The value string for the top entry in the last picture was WE06. Table 156W is shown :

 

The value string WE06 has two entries. These entries have different transaction/event keys (also called account keys). The transaction/event (t/e) keys specify the type of account to be posted to. These transaction/event keys are found in table 030. Thus, WE06 specifies that t/e key KBS will be referenced first, followed by key WRX. Let’s look at table 030 (accessed through SM31, display/maintain "T030", and select group RMK; OR via the menu path Tools > Cust. > Config > Acc. > Fin. Acc. > Book. > Bus. trans. > Gen. Ledger > MM > Auto posting).

 

Paging down through this table we see that KBS signifies an account specified in a purchase order, and WRX signifies a GR/IR clearing account. If we double-click on (or choose) KBS, we are brought to the following screen :

 

So how do we know which posting key to take? Is this a debit or a credit? We look to table 156 (a.k.a. "T156) in SM31.

 

For movement type 101, we see that the first entry is "S" under D/C. This signifies that the first entry is to be a debit, thus the first t/e key (KBS in this case) is a debit. Therefore, we look to posting key 81.

Note the line "posting keys are independent of chart of accounts" in the screen for key KBS. Let’s look at where posting keys are configured in transaction OB41 (in table TBSL through SM31, or via the menu path Tools > Cust > Config > Acc > Fin Acctg > Book > Bus trans > G/L > Control > Posting keys).

 

Posting key 81 shows a debit to a G/L account. Let’s look into this...(double-click or choose posting key 81)

 

We see that this key causes a debit to the specified G/L account. Thus, an account was specified in the PO (since 101 was a GR for a PO), and by finding the value string in table 156S, then the appropriate transaction/event keys in table 156W, and then by digging into the t/e keys in table 030, we were able to determine the appropriate account postings. So that told us about the debit made, but what about WRX? Let’s also look inside t/e key WRX in table 030 (we first must specify the chart of accounts, in this case CAUS) :

 

Here we see different postings, a valuation grouping code, an account modifier and a valuation class. Since the account modifier is not shown in this screen, we’ll cross that bridge when we get to it. For now, let’s look into the valuation grouping code. This is found in table 001K through SM31 (also available in transaction OMWD; Tools > Cust > Config > Log > MM > Val/Acc.assign > Config > Acct. det. > Val. area grouping).

 

.From this screen, we see that the valuation grouping code is used to group different valuation areas and/or different company codes together within a chart of accounts so that they have similar postings. So we understand the valuation grouping code, now how about that valuation class? That’s attained from the accounting view of the material master (for that specific valuation area).

 

For this material, the valuation class of 3000 is chosen. When this field is drilled into, we see that for this raw material, the system knew that only certain valuation classes were allowed. How did the system know which valuation classes were allowed for this material? It knew because when this material was created, a material type was chosen. Now on to material type configuration. This can be accessed via transaction code OMS2 (T>C>C>L>MM>Master data > material > control data > material type > click on change or display), select "ROH" (for raw materials), then click on the "account assignment" button. This shows the possible valuation classes assigned to the material types.

 

So for this raw material, the valuation class chosen was 3000. Therefore, back in table 030, for the t/e key WRX, using the valuation grouping code found in table 001K and the valuation class for the material (found in the material master), we can determine the GR/IR clearing account entry.

While we’re in the material type screen, let’s look at one other thing -- quantity/value updating. From the last picture, click on the button labeled "quantity/value". The following screen appears :

 

Note that to restrict quantity or value updating of this material type, the button "in no valuation area" under the headings of quantity or value updating would be selected. Thus, FOR EACH MATERIAL TYPE, THIS IS WHERE WE DETERMINE IF THERE IS QUANTITY OR VALUE UPDATING.

Back to our example from II.3 (a goods receipt for a purchase order)

So guess what! With what we’ve covered in this section we’re ready to track down how our goods receipt posting in the last section happened as it did! Let’s consider what we know about the goods movement :

1.     It is a goods receipt for a PO -- movement type 101.

2.     The PO had an account assignment category of "K", for a cost center and therefore is an item set for consumption.

3.     The material used was a raw material with a valuation class of 3000.

4.     For raw materials, there is both quantity and value updating.

5.     It is "standard stock" item (no special stock type)

So lets look to table 156S ==>

 

We are looking for the entry which is the third from the top. It meets all the criteria. Therefore, we are looking to value string WE06 for answers WE06 is found in table 156W.

 

As we said about this screen, WE06 has only two t/e keys. We determined the account posting for KBS in the following way :

1.     We found KBS in table 030

2.     Under KBS, we saw that two posting keys were there, one for a debit, one for a credit

3.     In table 156, we found that the first entry is a debit, thus we select posting key 81

4.     Next we looked to table TBSL (in transaction code OB41), and chose posting key 81

5.     There we saw that posting key 81 causes a debit to a prespecified G/L account (the cost center account specified on the purchase order)

We also determined the account posting for WRX in the following way :

1.     We found WRX in table 030

2.     Under WRX, we saw that we saw that we needed to specify a valuation grouping code and a valuation class in order to determine the proper GR/IR clearing account.

3.     In table 001K, we saw that for our valuation area (US01) and our company code (US01), we have the valuation grouping code US01.

4.     From the accounting view of our material master, we saw that our material has a valuation class of 3000 for the plant we are operating in (US01).

Therefore, in table 030, with a valuation grouping code of US01 and a valuation class of 3000, we have the GR/IR clearing account as account number 191100. This is shown in the accounting document created for the goods receipt.

 

A small change to the purchase order...

We said that a purchase order creates no direct account postings. However, they very much affect account postings for subsequent documents! In the purchase order of section II.2, what if we had chosen the account assignment category as being ‘standard’? Let’s look again at table 156S.

 

In this case, we choose the top entry -- goods receipt for a PO, where there is no consumption specified. We are thus given the value string WE01. Let’s look to table 156W.

 

Here we have 12 different posting keys! Note that there should always be more than one posting key for a goods movement because there should always be at least one debit and at least one credit. We saw that for movement type 101 (in table 156), the first entry is a debit. Thus, let’s look to table 030 to see what a debit under posting key BSX does.

 

Again we see the valuation grouping code US01 and valuation class 3000, we have account 300000. This is exactly what we find with this goods receipt ==>

 

Offsetting entries for inventory postings (Key GBB)

One last point about automatic account assignments from materials movements.

One of the t/e keys definable for a value string is GBB. This is a key often associated with goods issues, but can be used whenever offsets are required for inventory. This key is maintained in table 156X, which is shown :

 

As we determined the quantity and value strings from table 156S, here we not only can find the value string, but also the account modifier. If we look in table 030, we see the t/e key GBB. When we choose that key, we find the following view :

 

Where in the t/e key screens of BSX and WRX we only had to know the valuation grouping code and the valuation class, here we also need the account modifier. This screen shows that a goods movement which has a valuation grouping code of US01, a valuation class of 7900 (commonly used for semi-finished goods), and an account modifier of AUF would have debit and credit postings made to account 895000.

An Easier Way...

To review, we recommend a way of determining account postings from goods movement documents :

1.     Check table T156S for the appropriate movement type

2.     Find the appropriate movement type and value string in table T156S based on :

a.     if the material type is quantity and/or value updated

b.     if the item has a special stock type

c.     what type of movement is occurring

d.     what type of account assignment the item might have (consumption, sales order,

e.     stock account, etc.)

3.     Based on the value string, check table T156W for the sequence of t/e keys accessed

4.     Check table T156 to determine if the sequence from T156W begins with a debit or a credit

5.     Check table 030 to see the possible postings for each of the t/e keys

a.     for the t/e keys which have simple entries of posting keys (as with KBS), look to table TBSL to see what account this posting key affects

b.     for the t/e keys which have a valuation grouping code, account modifier, and a valuation class specification, find the account by the following :

•     look to table 001K to find the valuation grouping code based on the appropriate valuation area and company code

•     look to table T156X if an account modifier must be checked

•     look to the accounting view in the material master to find the appropriate valuation class

To check the account postings, use transaction code OMWB (accessed via the path Tools > Cust > Config > Log > MM > Val/Acc.assign > Config > Acct determ > Auto posting > Simulate). Hit cancel (in 2.2) to get to the next screen, then hit the "Simulation" button choose a plant, material and a movement type, and hit the "Account assignment" button.

This is one way to check the configuration without creating all of the documents.

Postings from invoices

Account postings made by invoices are much easier to understand, but harder to examine, than goods movement account postings. With invoices and credit memos, there is an associated document type (note the initial screen of an invoice)

 

However, we can look at the posting keys for invoices we can expect to be affected. These are maintained with transaction code (accessed via the path : Tools > Cust > Config > Acctg > Fin Acctg > Book > Bus trans > Base params > Control > Posting keys). We are brought to the following screen :

 

We see that posting key 31 is an invoice in which we credit a vendor. Let’s choose this key (or double-click on it).

 

We see that this is a credit to a vendor account. We also see that posting key 31 has a reverse posting key of 22. The previous screen showed that this is a reverse invoice receipt (different from a credit memo). A note about vendors -- in purchasing, vendors can be created with regard to purchasing, or centrally. If a vendor is created with regard to purchasing only, the vendor will not have accounting information maintained. Thus, the vendor would not bill in the SAP system. This is not to say that the vendor will not bill (we should be so lucky), just that it is not done in the SAP system. This might be for SAP users who are using an external system for accounting (or A/P only).

When a vendor is created, it is designated with an account group. The main functions of a vendor account group are :

1.     to designate if the vendor is a one-time vendor

2.     to specify the number range the vendor might be assigned to (to assign a vendor name)

3.     to maintain screen control for vendor maintenance

Vendor account groups are maintained in transaction OBD3 (Tools > Cust > Config > Acctg > FI Acctg > Book > Master Recs > A/P > Control > Acct groups). If we choose LIFA (general vendors), we see the following :

 

The screen shows that the number range for LIFA is "XX" (transaction XKN1 shows this to signify external number assignment). The screen also shows that this is not a one-time vendor. If we double click on "Company code data", and double-click on "account management" in the next screen, we see how accounting fields for this vendor are maintained in the vendor master record.

If an invoice is created with reference to a purchase order, the account postings are already specified, as checking is done as to whether the goods have been received. Note that in creating an invoice, it is not necessary that an A/P clerk reference a PO (although it is advisable if known). If a PO is not reference, the A/P clerk must manually maintain account entries. These account entries have associated posting keys. For example, a freight charge might have a posting key of 50. This account can be seen in table 030. Likewise, unplanned delivery costs can be charged against the group receiving the goods.

During invoice entry, alternative account entries can be entered, either as debits or credits. Thus, account determination is made as the invoice is entered.

Postings from purchasing documents

One last note...

You may find that some account postings happen when referencing purchasing documents, and there is no reference to these postings in table T156S. For example, freight charges. They can be specified in a PO, but how does a goods receipt know to take the PO’s freight charge over to the account posting?

First, let’s remember where freight postings are made in a purchase order. In the pricing condition record (note a special condition type) :

 

So the condition record of the screen shown has a condition type of FRA1, a percentage freight charge. Purchasing condition types are tied to account postings through PURCHASING configuration. Thus if we look into transaction M/08, yes with a "/" (Tools > Cust. > Config > Log > MM > Purch. > Functs. > Conds. > Pricing > Pricing Proc. > Pricing Proc.), we see the following screen :

 

If we now double-click on RM0000 (the first pricing procedure), page down to find FRA1, hit the "change view" button, we find the following screen :

 

Here we see that condition type FRA1 is tied to account key FR1. If we now look in table T030, double-click on "RMK" (MM postings), and double-click on FR1, we see that (in CAUS, for example), these freight postings are made to account number 192100.

 

I found this excellent doc on scn.

 

Thanks.

Irene

Sort Key Functionalities

$
0
0

Contents of the Document:

 

This document is an attempt at analyzing the functionality of sort key in SAP.

 

This document provides a framework for understanding:

 

  • What is a Sort Key

  • What is the functionality of a sort key

  • What are the uses of Sort Key

  • General process flow for using sort key

  • Example for illustrating the sort key functionality

 

Sort Keys:

 

Sort Keys are used to populate the Assignment number field in the line items of customers or vendors or general ledgers.

 

The content of this Assignment number field can be populated in a customer or vendor or general ledger document when the document is created:

 

  • either manually
  • or automatically by the system

 

Whenever a document is created, the Assignment number field in the document line items will be populated automatically, if the requisite sort keys are assigned to the customers or vendors or general ledgers master record.

 

Use of Sort Key - Benefits of Automatic Population of Assignment Field:

 

Whenever any standard reports are executed for displaying the line items of customers or vendors or general ledgers, SAP uses the content of the Assignment number field as one of the criteria to sort and display the line items.

 

What are the contents that can be populated automatically in the Assignment number field:

 

The Assignment number field of a customer or vendor or general ledger document line item can be populated automatically with the contents of one or more fields which are:

 

 

  • Either the data derived from the header of the document
  • Or the data derived from the line item of the document

 

 

The only requirement is that the above mentioned data proposed to be populated automatically in the Assignment number field should be available in one of the database tables – BKPF or BSEG or BSEC or BSED.

 

 

Can partial contents be populated in the Assignment number field:

 

 

The contents of the fields available in the database tables – BKPF or BSEG or BSEC or BSED can be populated automatically in the Assignment number field of the document, either completely or partially.

 

 

This can be controlled by mentioning the length of the field to be transferred in the fields – Length and Offset.

 

 

Applicability of the Sort Key logic:

 

 

The logic defined in the Sort Key is applicable across the client.

 

 

General Process Flow Describing Sort Key Functionality:

 

 

Sort Key - Process Flow1.png

 

Illustration of Sort Key Functionality:

 

Step 1:

SAP Configuration - Define Sort Key:

 

DescriptionTransaction Code
Determine Standard Sorting for Line ItemsSPRO/OB16

 

The standard sort keys provided by SAP can be used to automatically populate the Assignment number field.

 

But custom sort keys can also be defined if the requirements of the client cannot be met with the standard sort keys available.

 

For example, if the standard sort key – 002 is assigned to the customer or vendor or general ledger master record, it would populate the Assignment number field of the document with the document number (BELNR) followed by the fiscal year (GJAHR).

 

Similarly, the standard sort key – 001, would populate the Assignment number field of the document with the posting date.

 

Sort Key SPRO 1.PNG

 

Sort Key SPRO 2.PNG

Parameters of standard sort key 002 - Screen Shot:

 

Sort Key SPRO 3.PNG

Parameters of standard sort key 001 - Screen Shot:

 

Step 2:

 

Master Data maintenance - for illustrating Sort Key Functionality:

 

Assigning Sort Key in the customer master:

 

DescriptionTransaction Code
Create/change Customer masterFD01/FD02/XD01/XD02

 

In the example, the standard sort key – 001 has been assigned to the customer master.

 

Customer Master - Assign Sort Key 001.PNG

 

Assignment of Sort Key in Customer Master Record - Screen Shot:

 

(Similar assignment can be made in the case of vendor or general ledger master record also)

 

Step 3:

 

Transactional data - for illustrating Sort Key Functionality:

 

Post Invoice against customer:

 

DescriptionTransaction Code
Enter Customer InvoiceFB70/VF01

 

An invoice is posted against the customer referred above, without entering anything in the Assignment number field.

 

After the document is saved, if the Assignment number field is checked, it can be seen that the field is automatically populated with the posting date of the document.

 

In the example below, the sort key assigned in the customer master record is 001 - Posting Date.

 

Since the posting date of the customer invoice - 7500205569, is 07/20/2012, the Assignment number field in the document is automatically populated with the posting date in the format YYYYMMDD (20120720).

 

Allocation Field in Invoice.PNG

 

Automatic population of Assignment Number field in the customer invoice - Screen Shot:

 

Similarly, for subsequent documents posted, the posting date would automatically get populated in the Assignment number field.

 

In the example, the posting date of the document 7500208207 is 08/03/2012, and hence the Assignment number field is automatically populated as 20120803.

 

Similarly, the posting date of the document 7500210765 is 08/17/2012, and hence the Assignment number field is automatically populated as 20120817.

 

Step 4:

 

Transactional data - for illustrating Sort Key Functionality:

 

Customer Line Item Display:

 

DescriptionTransaction Code
Customer Line Item DisplayFBL5N

 

When the transaction code is executed to display the customer line items, it can be observed that the line items are displayed sorted on the basis of the content of the Assignment number field.

 

Customer Line Item Display.PNG

 

Customer Line Item Display Report - Screen Shot:

 

 

Step 5:

 

Transactional data - for illustrating Sort Key Functionality:

 

Modify Assignment number field of the customer invoice:

 

DescriptionTransaction Code
Change Customer Document Line ItemFB02

 

The Assignment number field of the customer invoice - 7500205569 is modified manually and the content is changed from 20120720 to 20120920

 

Modified Allocation Field in Invoice.PNG

 

Modification of Assignment Number field in Customer Invoice - Screen Shot:

 

Step 6:

 

Transactional data - for illustrating Sort Key Functionality:

 

Re-run Customer Line Item Display:

 

DescriptionTransaction Code
Customer Line Item DisplayFBL5N

 

When the transaction code is re-executed to display the customer line items, it can be observed that the line items are displayed sorted on the basis of the content of the modified Assignment number fields.

 

The customer invoice - 7500205569 which was previously displayed as the first invoice in the report is currently being displayed as the third invoice, because the content of the Assignment number field has been modified.

 

Modified Customer Line Item Display.PNG

 

Customer Line Item Display Report after modification of Assignment number field - Screen Shot:

 

Conclusion:

 

Based on the above discussion, it can be concluded that:

 

  • The Assignment number field of a customer or vendor or general ledger document, if not manually populated, will be automatically populated with the data from the header or line item of the document as per the sort key assigned to the customer or vendor of general ledger master record.

  • The content that will be populated in the Assignment number field will be derived from the database tables – BKPF or BSEG or BSEC or BSED.

  • The customer line items are displayed in standard SAP reports after being sorted on the basis of the content of the Assignment number field.

Golden tips while transporting substitutions/validations

$
0
0

Reader Note:Below tips are by assuming, reader is aware of substitution/validation concept in SAP.

 

Introduction:

 

Substitution and validation is one of the most important function which many functional consultants are not comfortable with.

 

Substitutions are used to substitute the transaction data based on custom business logic. Data source can be a constant value, field to field assignment or user exit.

Validations are used to do custom business specific validations (Which is not covered by standard SAP).

 

Both are called during document posting.

 

There are already couple of articles in SCN explaining the details of substitution and validation. So, I will not go into details on what is the purpose and how to use them.

 

I would like to stress on points to be considered while transporting the changes related to Substitution/Validation.

 

During development:

 

1. Compare the existing steps in production system with development system. This has to be done manually for each step as there is no version comparison option. There is a high risk that someone can do change in development and leave it without reverting. As the change is not automatically recorded in TR, unintentional changes would get moved to production system when a new change is moved.


2. Only one step in validation/substitution can't be included in TR. When we transport a validation/substitution, all the steps included in a folder would get transported (Even though there are no changes). Due to this, before releasing the TR, we need to make sure that all the steps in validation/substitution in production system and in the development system are in Sync. If this is not done, there is chance that unintentional validation/substitution steps will get transported to production system which may have serious implications as these are called for every FI document creation.

 

Other alternative could be to delete the entries manually from TR which are not related to our change (Best option I feel). But, this has to be done with utmost care as required entries shouldn't be deleted.

 

3. If, any change is being made in user exit (for validation/substitution), make sure that all the related transports move to production system at same time. This avoids any dumps that can occur due to syntax errors.

 

After transport:


4. When validation/substitution is moved from one system to another system, it is advised to run the program RGUGBR00(validations/substitutions regeneration). This ensures proper linking of the changes done in customization/user exits.

 

5. After moving the TR, do monitor the system proactively to see if any dumps are happening because of substitution/validation changes.

 

Please feel free to comment/add any other suggestions which are missed here

 

Best Regards,

Vinod Vemuru

How to add net due date as selection criteria in Line Item Reports?

$
0
0

There is always a requirement to get the line items between a due date when executing FBL1N and FBL5N. But, surprisingly, this is not available either in the dynamic selection or the selection screen. Screen shot of FBL1N is shown below (before making the trick). However, a small trick will fetch the “Net Due Date” field as one of the selection parameters on the above mentioned transaction codes. This would help the users to get the open items which are due between certain net due dates.

 

File1.png

 

You are required to visit SU3 in order to change your user parameters.

 

 

File2.png

 

Go to “Parameters” Tab and scroll down further to enter the last line. Please enter FIT_DUE_DATE_SEL as the parameter ID and parameter

value as “X”.


After entering, please press “X” on your key board. Then the screen should look appear as follows:

 

 

File3.png

 

Click on Save Button in order to save the changes.

 

Now please go to FBL1N or FBL5N and check the selection screen.

 

 

 

 

File4.png

 

File5.png

 

Now, you will see the “Net Due Date” field as one of the “Selection Parameter” on FBL1N and FBL5N.

 

FI Validation

$
0
0

Contents:-

 

1. Creating the validation.

2. How to activate the validation

3. About few Condition logics used during validation creation.

4. Creating Set & Rule and how to use in the validation. and the purspose of set and rule used in validation

5. How to activate trace/total trace to find out the setp triggered during validation.

6. How to transport validation

 

Transaction code :- GGB0 (Creating the validation)

 

Capture.JPG

As shown in the above screen shot dropdown the Financial Accounting and place cursor on the "Line Item" and click on validation Capture.JPG

 

Capture.JPG

 

New line item will appear as above (1). Enter the Validation name (2) and description (3). and press enter

 

Note: - Kindly ignore the lines wherever I strikeout using blue pen those are my client information which already created in system. 

 

Capture.JPG

 

than click Step Capture.JPG

 

Capture.JPG

 

Enter the Validation Step description. We will take simple example ( restricting Transaction Type for a GL account, however i will explain in details the validation logics so that you can create your own validations.

 

I am naming the validation as "Transaction Type Validation"  as shown in the below screen shot

 

Capture.JPG

than click on prerequisite

 

Capture.JPG

I am going to restrict transaction types for a GL account 1650000. Meaning system should accept only few (specified) transaction types for the GL. so the GL can only be posted with the specific transaction type.

 

Prerequisite:- The name Prerequisite itself self explanatory. The system will determine based on the logic/criteria mentioned here whether the validation is relevant for the business transaction we do or not. If the prerequisite is satisfied than only system will go for the further check (for the Check step). If not it will exit from the validation.

 

system behaves as below

 

Prerequisite   => if True => go to Check condition

                  => if False => the validation is not relevant for the transaction type.

Check:-    here we mention the condition for the business transactions. System check the condition during business transactions performed. the condition should get satisfied. If condition is not satisfied than the system will behave as per the message we define in the next step

Check    = > if True than business transaction is allowed proceed further

              => if False than will react as per the message we define in the next step

 

Message:-

 

E = > Error. In this step the user is not allowed to proceed further unless he satisfies the check condition.

 

W = > Warning. Just warning will be given by system to make aware the user about the condition. user needs to decide whether to proceed or correct the business transaction.

 

Ok. now we will proceed with our validation creation.

 

I am going to give GL account as prerequisite. Meaning when the GL account is used than the user should use only certain Transaction types.

Double click on the Structure BSEG = > Accounting Document Segment ( refer the below screen shot). BKPF only for header data. Since we are searching the field in the BSEG table.

 

Capture.JPG

 

Once you double click the screen will appear as below

 

 

Capture.JPG

 

 

click Capture.JPGsearch button and search for G/L or HKONT. You can see the field G/L from the below screen shot. Capture.JPG

 

again double click on field G/L. It will get added in the argument as below.

 

Capture.JPG

 

And click on symbol  "=". It will get added in the argument. again click on constant and input the GL name. Finally the argument field will appear as below

 

Capture.JPGmeaning if the GL account 1650000 is used. We have completed the prerequisite.

 

Than choose step "Check" . I am going to restrict the GL for the below transaction types ( Z03, Z04, Z08, Z90)

 

Capture.JPG

 

Ok, we have used condition "OR" here. Hence, we will see about the conditions

 

let me explain based on our example transaction type

OR (meaning either) => whether any one of the transaction type is used than the check condition comes true. Otherwise the check condition fails

And (meaning both/all) => The And condition needs to be used when you check values from more than one field. example. i say transaction type should be XXX and posting key should be YY. so both the condition needs to be satisfied by the user during the business transaction he perform.

IN = > we need to use the condition when we use Set or Rule

LIKE = > you can use this when you want to mention only prefix of suffix. for example transaction type like 'Z0*'. in this case all transaction type starts with Z0 will be considered

 

please refer the below link if you like to work with boolen logic

 

http://help.sap.com/saphelp_46c/helpdata/EN/27/06e23954d9035de10000000a114084/frameset.htm

 

Step 3. Message 

 

Capture.JPG

I have set message E (error).

 

The message you can create using SE91

 

input the message class and click on view. see the next available number range can be used. and agin come to main screen and click on change buttton. Input the description and save it.

 

 

Ok. we completed the validation sucessfully. whether it is will work now.

 

Unless you activate the validation at company code level it wont work in the company code. How to activate ?

 

 

Go to transaction code OB28

Capture.JPG

 

Company code

 

Validation are controlled at company code level. The validation needs to be activated here for the specific company code. 

Callup point

 

1. Document header (here you define validation for BKPF table fields)

2. Line Item (here you define validation for for the PKPF and BSEG table fields)

3. Complete document ( (here you define validation for for the BKPF, BSEG & Structure SYST)

 

Validation - which we created. all the steps created under this Test validation will be active

 

Activate Level- here you define whether the validation is ativate or not in the company code.1 is active 2 is inactive.

 

How to Activate the trace

 

The trace can be used to find out the validation step getting triggered at the time of postings.

 

Either you can activate trace only for the folder you placed cursor or you can activate total trace ( trace will be activated for all validation created in the system)

 

Place cursor on the validation folder and from menue Extras = > Activate trace Or Activate total trace

 

 

------------&-----------------

 

Set

 

We can use the set when you have many number of GL accounts company codes etc to be mentioned in the validation. It simplfies the maintenance of the validation. If you directly mentioned in valdiation itself than you need to use many number of OR & AND conditions.

 

GS01

 

Enter the set name you want. and the table name ( the fields you are going to maintain in the set belongs to ).

 

Capture.JPG

 

 

Capture.JPG

Capture.JPG

 

press F4 and select the respective field and press enter ( i have choosed company code)

 

Capture.JPG

 

Rule:-

 

It is just next node in the valdiation. Which you can see below screen shot

 

Use:-

 

1.You can maintain the same logic as you maintain in prerequist and check condition. It also makes the easy maintenance of the validation.

2. When every you transport validation you can find Transport sets open box in the screen. You can check the box and transport the sets along with the validation.

 

Capture.JPG

 

How to transport

 

Place cursor on the validaton folder and from menu Validation => Transport 

 

Note:- you need to untic the boxes other than rule. rule also need not to be ticked if you have not created any rule

How to get period texts in Finance Balances Reports?

$
0
0
Users may intend to see the period texts in the balances reports such as FS10N, FK10N and FD10N. Usually, they are not available in these transactions, unless they are already being configured in “Fiscal Year Variant”. By making a small configuration change would enable the users to see the period text. For this the period texts are required to be maintained in OB29.
Within the configuration, the period texts are required to be entered as shown below. Then these period texts are available in FS10N, FK10N and FD10N transaction codes.
File 1.png
This would allow you get the periods in the totals reports for GL accounts, customers and vendors.
Example of FS10N is shown below. It will also applicable for FK10N and FD10N
Initially it shows as follows:
File 2.png

You can change the layout to get the period texts of the report.

File 3.png

Please bring the  “Month” column from the right hand side context menu to the left hand side menu.

File 4.png

Please click on “OK” button (Green tick box)


Now you should able to see the period texts in the balances reports.

 

 

File 6.png


Service Tax in India and SAP Configuration

$
0
0

Hi

 

This document will give a brief idea on how to configure Service tax in Indian Scenario

 

Regards

Praveen

How to use dynamic variables in the variants?

$
0
0
SAP users must be running number of reports on a daily basis. There are number of selection parameters like dates and periods etc. are to be entered. Every time, entering these values must be cumbersome task. However, following small trick would let the system dynamically select the dates based on the values maintained in the variable of the variant.
File 1.png
Would like to run this report on a daily basis, however, the open items (open at key date) has to be dynamically changed when running, we can create variant with dynamic variables. Click on “save” button.
File 2.png
Give Name and Description and Variant Name.
File 3.png
Now this field we are expecting the system should calculate the date dynamically when running on each day.
File 4.png
For Dynamic Variables, SAP has provided some standard variables, we can use them. Select “D” for this purpose.
File 6.png
The above are the standard variables created by SAP for this purpose. Now for this purpose, I am selecting Current Date. Anything beyond these standard variables, we may have to create customized variables.

I am selecting “Current Date” for this purpose.
File 7.png

Click on save button

 

File 8.png

 

You can please see the dynamic variant.


For example, if we schedule this job to run on a daily basis, the system would dynamically take the “Current Date” into “Open at Key Date” Field and run the report.

 

 

Some fields can be changed even after the FI posting, How to restrict?

$
0
0

There will be requirement like baseline date should not be modified after the posting, you may required to do the configuration, in below screen shot, you can edit the field of baseline date (T code – FB02)

 

Change document1.png

Actually there are several fields which can be modified after the post of FI document. So, one must analyze and bring control over it according to the standard requirements for a company.

 

Below is the IMG path

 

Change document2.png

 

The list displayed are the fields which are used in the FI document, here I am selecting a baseline date for account type K and click on details or double click the line item.

 

Change document3.png

 

Change document4.png

 

Now uncheck the “Field can be changed” and stipulations for changing section, please refer below screen shot. You can also use stipulations for changing according to the client requirement.

 

Change document5.png

 

Click on save button and save the changes,

Go to FB02 and check, the field cannot be changed now.

 

Change document6.png

 

 

 


Lockbox Configuration

$
0
0

Lockbox process

 

The predominant way payments are made in US is by checks. Lockboxes help in speedy deposit of funds and clearance of customer accounts. Lockboxes are special depository accounts set up at a bank to which customer remit their invoice payments.

 

Banks daily than submit company’s an electronic file listing all deposits and invoices that are paid against. Company’s than upload these files in SAP and update their balance and clear customers i.e. A/R accounts.

 

Some company’s setup single lockbox whereas others set up lockboxes at different locations thought the country in order to decrease the time it takes to receive the customer payments.

first Image.png

     Figure 1: Lockbox Process Flow

Lockbox File Formats

 

SAP supports both US lockbox file formats – BAI & BAI2.Each bank has its own standard BAI and BAI2, hence configuration and testing needs to be done depending on bank file configuration.

Hence if you are not comfortable with bank file format either you can approach them to modify it depending on your requirement else ABAP can help in writing a preprocessing program and make file fit with SAP standard format.

 

Difference between BAI and BAI2

Table.JPG

BAI2 is advised as because it has greater probability of producing automatic matches in the processing and because it allows one to record deduction information and create proper residual postings.

 

Relationship between EBS and Lockbox

 

Assume on Day 1 company receives Lockbox file from bank and on Day 2 receives EBS file.

 

Day 1 When the bank receives a check from customer with remittance information its sends it in Lockbox file. Lockbox file when processed will generate below accounting posting

 

          Dr Bank Clearing account - incoming

 

     Cr Lockbox Clearing Account

 

 

          Dr Lock box clearing account

 

     Cr Customer account (customer sub ledger)

 

 

Day 2 when the check is cleared in bank, it appears in EBS. EBS when processed produces below accounting entry

 

Dr Bank Main GL

 

          Cr Bank Clearing Account - incoming

 

 

Dr Bank Account

 

          Cr Incoming Payments

 

 

Dr Incoming Payments

 

          Cr Customer Account

 

 

 

Lockbox Configuration

 

House Bank Configuration

 

Create House banks

 

  1. Menu Path: Financial Accounting à General Ledger Accounting à Bank – Related Accounting à Bank Accounts à Define House Banks

 

Transaction Code: FI12

 

1.JPG

Under the house bank create Bank account from FBZP transaction code.

 

2.JPG

 

After creation of House bank and Bank account under company code, it should look like this in FBZP transaction code.

3.JPG

 

Lock Box Configuration

 

  1. Path: IMG à Financial Accountingà Bank Accounting à Business Transactions à Payment Transactions à Lock box àDefine posting parameters

 

T Code: OBAX

4.JPG

 

Select highlighted row and click on change item button.

5.JPG

 

Document Number Length: Field is only applicable for BAI record

  1. Num. of doc numbers in type 6: Field is only applicable for BAI record
  2. Num. of doc numbers in type 4: Field is only applicable for BAI record

G/L account Postings: Activate this indicator to make postings to your cash account in the G/L for deposits. Activating this field is recommended

Incoming Customer payments: Activate this indicator to make postings to A/R sub ledger in order to clear customer accounts and create residual postings. Activating this field is recommended

Insert Bank Details: Applicable for batch input session name that updates bank details of master records for customers who have either changed bank information or did not have bank information maintained for them

G/L account posting type

1 - Creates posting to G/L account for every check in the file      

2 - Creates one posting to the G/L account for entire lockbox file

3 - Creates one posting to the G/L account for entire batch

 

 

Automatic Posting from lockbox         

 

  1. IMG à Financial Accountingà Bank Accounting àBusiness Transactions àPayment Transactionsà Lock boxà Define posting data

 

OBAY

 

6.JPG

 

Destination: This field should contain the destination code the bank submits to you in your lockbox file

Origin: This field should contain the your lockbox number (bank account) number at the bank

 

7.JPG

 

IMG à Financial Accountingà Bank Accounting àBank Accounts à Define Lockboxes for House bank

 

Click on first option

 

8.JPG

 

9.JPG

 

Customer Master Data

 

Transaction Code: XK03

Maintain Bank details in customer master data which bank will send in lockbox file

10.JPG

11.JPG.

 

Customer Invoice Posting

 

Post one 600 amount customer invoice. Invoice will display in open state.

 

T code FB70

13.JPG

 

Open the invoice

Transaction code: FB03

14.JPG

15.JPG

T code: FBL5N (Customer Report)

 

Below report shows customer item and it’s not cleared.

 

16.JPG

 

Lockbox file processing

SAP gives option of using one of the two standard algorithms for lockbox processing. A common misrepresentation is that one can create own algorithm which is not correct. We can only use the pen delivered by SAP. Program RFEBLB00 is the processing program. Documentation can be viewed for this program from SE38 transaction code. This program contains lot many user exits whether one can add any additional business logic.

Two algorithms that are used are 001 and 003. If file contains checks that cannot be applied against specific invoice but for which customer account is known, SAP posts them on the customer account without reference to any specific invoice. Using algorithm 003, SAP distributes the check across open invoices, beginning at the oldest invoice and working its way forward until the check amount is fully distributed.

           

 

 

File Import:

 

  1. Menu Path: SAP Easy Access à Accounting àFinancial Accounting àBanks  à Lockbox à FLB2 Import.

 

Transaction Code: FLB2

 

Save the lockbox file attached with this document and modify the document number in file with open customer invoice.

 

20.JPG

Click on green execute button.

21.JPG

 

Click on back button.

22.JPG

 

Transaction Code: FLB1

Enter Lockbox details and click on execute button

 

23.JPG

 

Select the one which contains data in file. For example if file contains 1123456 is second session name will be 1123456. Right click on 1123456 and select Process Checks options.

 

24.JPG

30.JPG

 

Right click on Session name and click on Process option.

31.JPG

 

Vendor Document Clearing Report

 

Again view customer invoice it will be displayed as cleared from the payment received and posted via lockbox

 

32.JPG

 

Notes

 

1)   If you get below message, modify the following in file. Unique key for each lockbox file is its header record i.e. Destination, Origin name, Date and time. Modify the seconds’ part and rerun the file.

33.JPG

 

1)   Sap file generation

 

            Use Test Lockbox Generation Programs RFEBLBT2 to generate BA12 format and RFEBLBT3 for IDOC format. These programs will generate customer open items and a lockbox file for processing.  Utilize program RFEBKA96 to delete loaded test data

    

 

2)   Sample File Understanding

100MANGDESTINMANGORIGIN130903123557

20000000000000000000000

56660011123557130903MANGDESTINMANGORIGIN

666600200000600000110003900345205865100000002

466600360191800000023   00000000600000000000

766600411235571309030010000060000

8666005112355713090300010000060000

9000000

 

File content explanation with help of differnet Color Codes

 

100000002 =Check Number

666 = Batch ID

1800000023 = FI customer Invoice

123557130903 = Date & time in Header (i.e. first record) and Time & Date in below records.

600000 = Check/Invoice Amount depending on Row

110003900345205865 = Customer Master Record Bank details.

 

3)   Sample file of BAI2 program can also be generated from SAP directly on execution of programs

 

Same can be downloaded and uploaded with just modification of document number else copy from below location

 

100MANGDESTINMANGORIGIN130903123557

20000000000000000000000

56660011123557130903MANGDESTINMANGORIGIN

666600200000600000110003900345205865100000002

466600360191800000023   00000000600000000000

766600411235571309030010000060000

8666005112355713090300010000060000

9000000

Version comparison of customization objects is a cakewalk!!!

$
0
0

Version comparison:

Comparing an object with in a system (Different versions) or between different systems (Same/Different versions) to identify if the object data is same or not is called as version comparison. Object can be an ABAP program, data base table definition, a customization object etc.

 

Why should version comparison be done before making any changes to any object?

 

It is very important to do version comparison with production system before making any change to any object in development system. Because, when we do some changes to an object and move to production, only the intended changes should get moved to production system. For this, we should ensure that production and development versions are same before making any change.

 

Eg: There is a live object in production system. Some changes was done in development system, object is deleted from TR and left like that for a while in development system without reverting the changes. When a new change comes later, if version comparison is not done, old changes would be moved to production along with new changes which is unintentional and may cause many issues like dumps/malfunctioning of program etc.

 

We all know how to do version comparison of ABAP objects between different systems (Say between development and production) like programs, includes, tables, structures etc. This is inbuilt standard SAP functionality. But it is often ignored by most of the functional consultants while doing the customization changes. Reasons could be unawareness on how to do this or ignorance.

 

SAP has given a standard tool (Transaction SCU0) for doing version comparison of customization objects too. In this document i will explain the step by step process on how to use SCU0.

 

Step 1: Identify the customization node in SPRO where changes are being done and identify underlying database tables that are updated

 

Eg: I am taking payment terms as the change here.

 

Go to SPRO path and right click on the node where changes are being done. Select Display technical info.

Untitled.png

In the next screen, select the tab "Maint. Objects". This helps to identify the maintenance view for the relevant node. As you see in below screen, it is V_T052.

Untitled.png

Now let us identify the underlying tables for the view V_T052.

Double click on V_T052 and select other view as shown below.

Untitled.png

In the next popup, double click on "Piece list" option.

Untitled.png

Now, we can find underlying tables that are updated when we do any change through the respective node in customization.

Untitled.png

 

Other alternative is to find the list of tables from view definition in t-code SE11/SE12.

 

Step 2: Find out the version differences.

 

Go to t-code SCU0, select "Manual selection" option and click on create.

Untitled.png

 

In the next popup, enter the list of table names identified earlier.

Untitled.png

In next screen, Enter some description and RFC destination of the system to be compared with. You can find the destination name from t-code SM59 or your BASIS  consultant can help to identify this. Once the details are entered, click on "Total comparison".

Untitled.png

System prompts for user ID and password of destination system. Enter the details and proceed.

Untitled.png

After this, A report summary is displayed with the list of differences between the two systems. This is self explanatory.

Untitled.png

Going into details of the differences between the systems, select one table at a time (This is a restriction) and click on comparison button in tool bar.

Select the appropriate option in next popup. If we select restrict number of entries, addition popup would appear to ask for selection criteria for filtering.

In this case, I am selecting total table comparison. After this, enter the log in credentials of destination system again.

Untitled.png

 

Below is the sample output (Part of the output is masked due to confidentiality).

Untitled.png

 

Step 3: Decoding output:

 

It is very simple to decode the output as SAP has given simplest approach by different colour coding for different scenarios in addition to code letter.

Below figure shows the different scenarios that are possible which are again self explanatory.

Untitled.png

 

Step 4: Decide to proceed with change or not.


If you are trying to change some existing entry, that should be shown same as the production entry (White/light gray background). If it is different, further analysis can be done through change logs t-code SCU3 and proceed accordingly. There shouldn't be any issue if our change is related to creation of new entries as these entries doesn't exist in target system.

 

Same procedure has to be repeated for all the tables of the maintenance view to confirm the dependency. This T-code can be used for any customization change irrespective of module.

 

There are many other options/t-codes that are being explored further to find out more Gems hidden by SAP in their treasure...

 

Your valuable feedback on this document is most welcome

 

Best regards,

Vinod Vemuru

Account assignment can be changed during invoice processing, how to bring control over it

$
0
0

Cause: If account assignment e.g. for cost center is changeable in the Invoice, then posting to cost object can be different from that done during goods receipt. This will cause inconsistency in the system.


One must do a configuration setting in order to bring control over the accounting documents

 

IMG path

 

IMG / Materials Management / Purchasing / Account Assignment / Maintain Account Assignment Categories

You will get the below screen

AAC1.png

There is lot of account assignment category, one must need to verify according to the scenario of the customer. Here, I have taken example of a cost center “K” . Double click the line item, you will be followed by below screen shot.

ACC2.png

Now uncheck “ AA chgable at IR” and save the configuration setting,

 

AAC3.png

User now will not be able to edit account assignment in Invoice receipt. This is very useful and also was noticed in one of our clients and I made the required changes.

TDS threshhold limit Define in SAP

$
0
0

Dear team,

 

Can any body suggest where we are fix the TDS threshhold limit in SAP.

Like:

Section 194A: Rs.10000/Rs.5000/- P.A.

Section 194B: Rs. 10000/-P.A.

 

Regards,

 

Sahoo


SEPA Pre-notification and SDD Timelines Functionality

$
0
0

SEPA SDD Time Lines and Pre-notification


SEPA stands for ‘Single Euro Payments Area’. It’s a system that is designed to create financial efficiency for countries using the currency Euro by providing a unified system in which to perform financial transactions. The SEPA seeks to create a better system for credit transfers, an improved debit system and a cheaper way for individuals and firms to make transactions within member countries or regions.

The implementation of SEPA is mandatory by 1st of February 2014 for the Euro area countries.

The changeover of national collection procedures to SEPA Direct Debit requires, along with the use and management of SEPA mandates, that the business partner or Customer be notified in advance about the items to be collected and the mandate to be used must be named.

The SEPA Direct Debit (SDD) Core and the SDD Business to Business (SDD B2B) Schemes developed by the European Payments Council (EPC) - like any other direct debit schemes. With SDD Schemes enable consumers to make cross-border direct debit payments throughout the 32 Single Euro Payments Area (SEPA) countries1. At the same time, the SDD Schemes can be used for payments domestically.

The payer and the biller must each hold an account with a payment service provider (PSP) located within SEPA. The accounts may be held in either euro or in any other currency. The transfer of funds (money) between the payer's bank and the biller's bank always takes place in the euro currency.


SEPA requires to meet modified lead times, examples:

 

  • The pre-notification must always reach the payer with a period of 14 calendar days

 

  • The lead time for submitting a SEPA CORE direct debit at the bank is 5 days for the first use of a mandate and 2 days for the subsequent use.

 

  • The lead time for submitting a SEPA B2B direct debit at the bank is 1 day for the first use of a mandate and 1 day for the subsequent use.

 


Pre- Notification :

A pre notification is a notice to the debtor or payer informing at least 14 calendar days before collecting the payment, unless a different timeline has been agreed between the debtor and the billing organization or unit. The pre notification includes the amount of collection, due date.

SAP provides various OSS notes to incorporate this functionality. Following are the SAP notes to be implemented for SEPA Prenotification.

 

A)     1679118 :

When we  run batch input session for transaction F110. If custom selections are changed by this batch input , change of field name is not transferred.This may result in follow-on-errors.As part of Note implementation 1679118, following list of existing standard Report objects will affect in the system.

             1) F110VI00

             2) F110VO00

             3)F110VTOP


B)     1760564:

When we use the report for automatic scheduling of payment run(F110S). if you have define a value several times in selection of customers and vendors, this leads to document balance not equal to zero during processing. In this case , customers or vendors are included several times in selection and the error message FZ 326 is displayed in log.            

As part of Note implementation 1760564, following list of existing standard Report objects will affect in the system.

        1) RFF110S

        2) RFF110S_DATA

        3) RF110S_FORMS


C)      1770425:

In the payment program for payment requests, as mandate is rejected as invalid eventhough it is  valid.As the mandate is specified as mandatory in the payment request,the system does not check  any further mandates and no payment is made.In order to fix, we need to implement corrections mentioned in note. As part of Note implementation 1770425, following list of existing standard Report objects will affect in the system.

         1)LF11BF01

 

D)       1776076 :

When we use SEPA Mandates, it is not possible to influence SEPA mandate selection according to our requirements or to adjust SEPA Mandate Lead times(five/two/one-day rule) individually during a payment run. As part of Note implementation 1776076, Changes are affected for below list of standard objects.

 

                  1.      Function Module : FI_PAYMENT_BANK_SELECT

                  2.      Function Module : FI_SEPA_CALCUALTE_DAYS

                  3.      Function Module : FI_SEPA_FILTERED_MANDATES_GET

                  4.      Function Module: FI_SEPA_PAYM_SET_PARAMS

                  5.      Class: CL_SEPA_ADD_DAYS_ADJUST_DEMO  and Interface IF_EX_SEPA_ADD_DAYS_ADJUST~ADJUST

                  6.      Class:CL_SEPA_MANDATE_FILTER_DEMO and Interface IF_EX_SPEA_MANDATE_FILTER~FILTER

                  7.      Classical BADI’s  SAPF110S_SEPA_MANDATE_FILTER and SAPF110S_SEPA_ADD_DAYS_ADJUST are migrated to                                                                         Enhancement  Spot ES_SAPF110S_SEPA_MANDATE  from release 6.0.

                  8.   Type group FIPRQ

 

E)      1780941:

Once we enter a payment method for SEPA direct debits in a payment run for SEPA payment methods the system displays a checkbox in the parameters for the payment run (F110) using  which the update run is a run for direct debit pre-notifications. This allows you to send letters and protects the items affected by the direct debit against being otherwise cleared, but does not post and does not permit any payment medium creation either. The new "direct debit pre-notification" object is visible in the payment run (F110), in the document display (FB03), in the line item display (FBL5N) and in mandate display (FSEPA_M4).


F)       1792691:

This error occurs if the creditor identifier is different in the  paying company code and the mandate.In order to fix, we need to implement corrections mentioned in note. As part of Note implementation 1792691, following list of existing standard Report objects will affect in the system.

            1)F110OFS0

 

Once the above notes are implemented, the functionality of SEPA Direct Debit pre-notification will become active.

 

How does PreNotification work in SAP.


When F110 (Automatic Payment Run) is executed –after giving the information such as the Posting Date, Doc Entered up to , the company code , Payment Method , Next Payment Execution date in the in the Parameter tab – we shall get an option to select the Direct Debit Pre-notifications indicator.

Below is the screen shot of the same.

 

1.png

The option of to select the Direct Debit Pre-notifications indicator  shall be coming only for SEPA payment methods – once the SEPA Mandate Required field is marked in Payment Method/Country settings in FBZP.

 

2.png

One should schedule a run for the creation of direct debit pre-notifications before the payment run taking into account the payers or customer items that are due in 14 days for a SEPA Direct Debit pre-notification. The actual payment run can be scheduled and the payment medium can be created as per the notified timelines.


The standard print program RFFOAVIS_DD_PRENOTIF and script form F110_DD_PRENOTIF are used for SEPA direct debit pre-notifications.

 

3.png

To meet any specific business requirement, the standard script F110_DD_PRENOTIF can be copied into a custom script and can be used.

 

Deletion direct debit pre-notifications


If the direct debit pre-notification are not correct –one can delete all the notifications in the payment program run.


Goto F110 => Environment =>Direct Debit Pre-notifications=> Delete

 

4.png

 

 

SDD Timelines (SEPA DIRECT DEBIT)


SAP has released some standard notes to be implemented for SEPA Direct Debit timelines.


A)1601466 : SEPA : Target Calender/ Calculation of lead days         

According SEPA Rule book , a target calender has to be taken into account so that weekends not consider in the calcuation.


B)1605678: F110/SEPA: Consideration of Target calendar

When we calculate the execution date or due date of the SEPA Direct debit, the system does not take any calendar into account in the payment program. However, according to the SEPA guidelines, only bank days according to target calendar should be used for the lead days and the due date.


C) 1757993: PMF SEPA: Increasing the lead time days for B2B mandates


D)1725028: F110/F111:” Superseding” SEPA mandates            

The subsequent use of a mandate may “surpersede” the first use. The SEPA leads time amount to 5 days for the first use and 2 days for the subsequent use.If the next payment run is exucuted only one day later or just few days later , the execution date of the subsequent use may be before the execution date of the first use. This is inconsistent. The bank is supposed to excute the recurring payment for first payment.


E) 1884024: The posting date of the payment documents posted in FPY1 is the same for all documents, whether or not there are different execution dates (field DPAYH-AUSFD).
This is not desirable, especially if "N days in the future" have to be selected due to the SEPA items with a due date.

Once all the relevant OSS Notes are implemented for SEPA Direct debit , we will see in the DME

file the SDD timelines.


How does SDD timelines work in SAP.

The SEPA core direct debit scheme is based on the SEPA Core Direct Debit Scheme Rulebook of the European Payments Council. With the SEPA core direct debit scheme, the payer can effect payments to the payee in euros through its payment service provider within the Single Euro Payments Area (SEPA). For the execution of payments using the SEPA core direct debit scheme, the payer must issue a SEPA direct debit mandate to the payee prior to the payment transaction. The customer (i.e. the payee) initiates the respective payment transaction by presenting the direct debits through the Bank to the payer’s payment service provider.

The SDD timelines are calculated based on standard function module FI_SEPA_CALCULATE_DAYS. 


Example :-

Case 1 – Core Direct Debit Customer and First Time Collection


‘TEST SEPA’ is Core Direct Debit customer and has an invoice due on 23.10.2013 for first time collection.

 

5.png

 

Mandate ID has been created for the customer TEST SEPA

6.png


Execute F110 – the DMEE file will be generated which needs to be sent to bank for the collections. The Invoice is due on 23.10.2013. We have executed the F110 on 23.10.2013. Since it’s a first time collection – lead time for submitting a SEPA CORE direct debit at the bank is 5 days for the first use of a mandate. So the Required Collection Date should be 30.10.2013 (26th and 27th are Bank Holiday)

 

7.png

Below is the screen shot of the DMEE – its shows all the details correctly. The F110 execution date as 23.10.2013, the customer TEST SEPA is CORE customer; it’s the first time collection, in the node sequence type once can notice FRST and required collection date as 30.10.2013.

 

8.png

Once the F110 is executed – the mandate master data gets updated with the USE tab with payment run information.

 

9.png


Case 2 – Core Direct Debit Customer and Recur Collection


Lets take the same customer TEST SEPA. Post another invoice and due date should be less than 30.10.2013. This would be a RCUR collection.


10.png

Execute the F110 and check the DME file.

 

11.png


For a RCUR collection – the lead time for submitting a SEPA CORE direct debit at the bank is 2 days for the subsequent use. So ideally for the above scenarios the due date is 24.10.2013 and being RCUR collection the required collection date should be 28.10.2013.


However the DMEE gives the Required Collection Date as 31.10.2013 – which is correct. The reason for this is – the FRST collection for the Customer TEST SEPA is on 30.10.2013 (Please refer Case 1 above). Hence any other collections due before this day will happen after 30.10.2013 only ie after the FRST collection is collected or completed on 30.10.2013.


Similarly like SEPA Core direct debit, the SDD timelines will work for SEPA B2B direct debit too wherein the lead time is 1 day.

 

Case 3 – B2B Direct Debit Customer and First Time Collection


Lets take a B2B Customer with 2 invoices which are due on 04.09.2013 and 30.09.2013.

 

12.png

13.png

 

Execute the F110 run and check the DME File. Below is the screen shot of the DMEE – its shows all the details correctly. The F110 execution date as 23.10.2013, the customer is B2B customer; since it’s the first time collection, in the node sequence type one can notice FRST and required collection date as 30.10.2013. ( Lead time is 1 day). All the details are being shown correctly.

 

14.png

 

15.png

 

Case 3 – B2B Direct Debit Customer for RCUR Collection


Lets take a B2B Customer with invoices for RCUR collection. The lead time is 1 day. Execute F110 with required details and check the DME File.

 

16.png


The sequence type is RCUR and Required collection date is 25.10.2013.

 

17.png

SAP Bank data customization

$
0
0

Introduction: This is to understand the standard SAP process for managing the cash flow through banking services for day to day business operations.

The scope of this document will cover

Bank Account and other related information is one of the most widely used information on vital business documents, including invoices. But this information is so inconspicuous in SAP that it is very difficult to find. This information is made up of various entities, including

 

Terminologies used:-

 

House Bank: It identifies the payable bank. Each bank for any company is assigned a house bank key to uniquely identify it.

 

Account ID: It is used to uniquely identify various accounts in a particular bank for any company. The combination of house bank and account ID should be always unique.

 

Currency: This is the base currency for any combination of house bank and account ID.

 

GL: It is a general ledger account that will identify the balance of the bank account. Each bank account should be mapped to a particular GL account to track it’s balance in SAP.

 

SWIFT (Society for Worldwide Interbank Financial Telecommunication) Code: Uniquely identifies a bank throughout the world. The S.W.I.F.T. code is used for identifying banks in international payment transactions. SWIFT codes are used mainly for automatic payment transactions

 

Bank Keyis MICR Code which is of Nine numeric numbers (it can be taken from Check book i.e. MICR Code)

 

Control key: 01 is for current Account and 02 for saving account (Generally in U.S.)

 

IBAN (International Bank Account Number): The International Bank Account Number (IBAN) is an international standard for identifying bank accounts across national borders.

 

Bank Sub account (Bank determination T.Code FBZP): Specifies the account number of the G/L accounton which the payment amount is to be posted. For example the number of the outgoing checks account which is created in addition to the giro account is specified here,

 

General Ledger Account (House Bank FI12)

This field contains the number of the G/L account to which the transaction figures are updated.

 

Pr-requisites

Basic understanding of banking operations, concept of payments in SAP

 

 

 

Blow is the Transaction code where we customize the bank related information

 

 

 

 

Define countries in SAP

p1.png

p2.png

 

Enter the 3- character ISO country code for all countries if you want to exchange data with banks via OFX –open financial exchange

 

 

 

Set Country specific checks for Bank

p3.png

Indicator that a country – specific check of the bank details (bank number, bank account number, bank control key) is to be carried out. The corresponding check routines are installed in the system and can be activated via this switch. The check routine responsible for a country if found by means of the international country code. Activating this indicator also means that SWIFT Code is checked whether or not the country is listed here. To do this you must specify the ISO code for the country.

 

 

Create Bank : T.Code FI01

 

 

 

p4.png

 

Create House Bank: FI12

p5.png

p6.png

 

Bank details check box option at Payment method at country code level T.Code FBZP


Select Bank details if required at payment method

p7.png

If you set this indicator, the payment method is only used if the account number has been maintained for the bank details of the business partner.

 

Bank Determination level

 

Assign House bank in ranking order for payment method

p8.png

Assign the Bank sub account for house bank for payment methods

.p9.png

 

 

Create Check Lots  for House Banks. Code:  FCHI

Here we are maintaining the check lot for the house bank and account ID for paying company code.

 

p10.png

ELECTRONIC BANK STATEMENT CONFIGURATION (EBS)

 

p11.png

p12.png

T.Code OBPM1: Maintain of payment medium formats select the house bank

P1.png

P2.png

T.Code OBPM4: The above fields house bank will be activated in payment medium selection variant

P3.png

 

Updating the Table T028Q:

 

This is the table where we will be linking the bank key and account number to get account number in bank transaction. This we are updating, because while loading the bank file in the testing phase of the Electronic bank statement, an error message will pop up to update the table T028Q. Therefore we need to update this table, if the error message pops up

p13.png

p14.png

 

Update the above four columns

1.Bank number in Bank statement

2. Account number in Bank statement

3. Bank Key and 4. Bank account number

 

 

 

Field Status Group T.Code OBD3( vendors)  and OBD2 (Customers)

Select Bank details if required at payment transactions for  customer and vendor

p15.png


 

 

Activate International Bank account number (IBAN)  without Bank Account Number:

p16.png

p17.png

p.png

p18.png

With SEPA – Bank Account number would no longer be needed in the customer/vendor master data. Only IBAN and Swift code are required based on which the bank key and bank country will be derived. We have activated a central functionality for IBAN. If this indicator is set, a user can maintain an international bank account number manually.

 

 

 

 

Example: After activating the IBAN with out bank account number

p19.png

p20.png

p21.png

View International bank account details in Table: TIBAN

 

IBAN Valid from details can view in T.Code FIBAN

p22.png

LOCK BOX Customization:

p23.png

p24.png

p26.png

 

 

 

 

 

Business transaction codes related to Check information and EB statement process

F110-Auto payment run

FI12-Create House Bank

FCHI-Create Check Lots

FCHV-Define Reasons for check cancellation

FCH1-For Check (Display)

FCH2-For Payment Document (Display)

FCHN-Check Register (Display)

FCH4-Renumber (change)

FBZ5-Print form for payment document

FCH7-Reprint Check (Change)

FCHT-Assignment to Payment (Change)

FCH5-Create Manual Checks

FCH3-Unused Checks
FCH9-Issued Checks

FCH8-Cancel Payment

FCHD-For Payment Run (Delete)

FCHF-Manual Checks (Delete)

FCHE-Voided Checks (Delete)

FCHG-Reset Data (Delete)

FEBA-Bank statement subsequent processing

FF67-Manual Entry (Process Of Manual Bank statement

FEBA-Bank statement subsequent processing

FEBP-Post (Update Bank Statement)

FF_6-Display Electronic Bank Statement

FF_5-Import Electronic Bank statement

FEBAN-Reprocess

FIBLFFP-Free Form Payment (Online payment)

FIBLAPOP-Vendor Payment Request (Online Payment)

FIBLAROP-Customer Payment Request (Online Payment)

F8BT-Display Payment Request (Online Payment)

F8REL-Release Payment Request (Online Payment)

F8REV-Reverse Payment Request (Online Payment)

Depreciation of a period share out to the rest of the year

$
0
0

In an industrial company is very common that it exist periods stopping in manufacture, which is used for maintenance repairs. In these periods, the accounting and controlling departments separate the costs of these repairs to avoid distortions on calculation of production costs: raw material costs are reduced or eliminated and repair external costs increase considerably. In addition, fixed costs are equal apply installations worked or not. A common solution is accounting departments to share out the fixed costs of the shutdown period between the rest of the year accounting periods. This operation is usually an external calculation (in Excel or similar) and posting an accrual entries in SAP system through a recurring document.

 

One of the fixed costs for which SAP has a standard solution without resorting recurring document is fixed assets depreciation. The solution is that the program for posting depreciation (transaction AFAB) do not perform any accounting entry in the accounting period corresponding to the factory stopping and it share out in the other periods, the total annual depreciation unchanged. Let's assume in this example a manufacturing company with a maintenance repair stop in August.

 

There is a customizing that does this automatically:

image1.jpg

image2.jpg

On the first point, fix the valuation area to which you want to assign this behavior, depending on the company code (not dependent on the chart of depreciation)

 

image3.jpg

 

On the second point, are weighted for each variant periods of exercise (currently example is K4):

 

image4.jpg

 

In this example, August (month number 8) is populated with blanks and the weight to other periods is 1, this customizing share out the value of August depreciation in same value to other periods.

 

See an example: nonstop active August, the annual amount of 2013 (5481.19 eur) is distributed proportionately throughout the year:

 

image5.jpg

 

Same asset with customizing stop in August, the annual amount is the same, no change, but in August does not depreciate any value:

 

image7.jpg

 

by-nc.eu_petit.png

Step by Step document for Withholding Tax configuration

$
0
0

Withholding Tax is also called as retention tax. Its requirement of Government to deduct or withhold a particular percentage from paying to the vendor and pay such amount to the Government on behalf of other person. It’s a kind of Indirect Tax.

 

[A] CONFIGURATIONS:

 

All the configurations for the Withholding Tax is done in the following Tab only:

 

Untitled.png

 

 

·         Define Business Places: Business Place is to be created for each Tax Deduction Account Number (TAN) that company has.

 

 

Capture.JPG

·         Define Section Codes: In India for each Business Place a Section Code is created and mapping is done on one to one basis. In Section code information about Local Tax office as well as District Tax office can be made.

 

Capture.JPG

 

The flow for the configuration is such that firstly the Withholding Tax Key (e.g. 194C) is to be created then under that Withholding Tax type is created one at the time of invoice and other at the time of payment and then based on the different rates prevailing in the Income tax Act, different Tax Codes are to be created (e.g. for 194C, 2 different rates are there in the Act, one is 1% TDS on the contract basis and second is 2% TDS on the sub-contract basis)

E.G. 194C à Invoice / Payment Posting àC1/C2 based on different rates.

 

Define Withholding Tax Keys: Withholding Tax key is used to identify different withholding tax types. A name is to be given with the official key.

Capture.JPG

 

 

Withholding Tax can be deducted at two point of time; it can be either at the time of invoice or at the time of payment. So for this Withholding tax types are to be created one for invoice and second for payment.

 

·    Define Withholding tax Type for Invoice Posting: Here the withholding tax type is assigned for the invoice purpose and the same will not get triggered at the time of Payment Posting.

Capture.JPG

Capture.JPG

 

 

·    Define Withholding Tax Type for Payment Posting: Here the withholding tax type is assigned for the payment purpose and the same will not get triggered at the time of Invoice Posting. The withholding information is to be provided while posting for such document for Withholding Tax payment.

Capture.JPG

 

 

Capture.JPG

For each Withholding Tax Type, according to the different rates available in the Income tax rates, the different Withholding Tax Codes are to be created based on the Withholding Tax Type.

 

·         Define Withholding Tax Code: In withholding tax code, different rates are maintained and on what basis the TDS should be deducted is maintained.

Capture.JPG

Capture.JPG

 

Capture.JPG

Capture.JPG

Capture.JPG

 

Here above configuration is done and on the above basis the TDS amount will be deducted from the invoice or payment.

 

·    Defining Document Type for Challan:

 

Capture.JPG

Here we maintain the Document type for posting Challan.

 

·    Define Number Ranges for the Challans create: Here this is important on the basis that the client requires that he want details about the combination of Section Code and the Withholding Tax Key basis, so then different number range can be assigned and so he will be able to know the TDS Challans that are generated for each area.

 

Capture.JPG

·    Maintain Number Groups: Here a Number Group is assigned to the combination of Company Code, Section Code and Withholding Tax Key. From below we can see that Number Group ‘01’ is assigned to the combination of AP01 and all the Tax Types.

 

 

 

Capture.JPG

·    Assign Number Ranges to Number Groups: In this step of configuration, the number Group created above is assigned to an Internal Number Range for the challans.

Capture.JPG

·    Maintain Number Ranges: Here we maintain the number ranges for Challans. The number groups are assigned to number range and these number ranges are maintained for fiscal years which are consumed while challan posting.

Capture.JPG

Here we Edit Groups by clicking on Groups button for defining number ranges specific to Number groups.

 

Capture.JPG           

For example, if we want to maintain the number range for number group 01, then we have to select the number group 01 and then insert the number range for the same.

 

 

Capture.JPG

 

Here we can add or delete the number ranges for particular fiscal years.

 

·    TDS JV Configuration:

For passing the TDS JV for the rectification amount, we need to define the Document Type and the GL account for JV Losses. Following are the configuration nodes for the same.

 

The Document types are configured here in the following Node.

Capture.JPG

 

The JV Losses GL accounts are configured in the following Node.

 

Capture.JPG

 

 

 

Above is the full configuration document for the purpose of implementing Withholding Tax in the system.

 

SEPA Direct Debit DMEE –GERMAN NATIONAL SPECIAL CHARACTERS

$
0
0

In the standard DMEE TREE format SEPA_DD, the German umlauts or the national special characters are replaced.

The translation takes place by use for the function module SCP_REPLACE_STRANGE_CHAR.

 

For example

 

German umlauts

Replaced with

Ä

Ae

Ü

Üe

Ö

Oe

ä

ae

ü

ue

ö

oe

 

This conversion might leads to get the DME file rejected by the bank or some organization have HASH value or CHECKSUM value generated based on the standard table like REGUH etc  from where the details like Customer Name or Vendor Name are fetched.


Predominantly Customer or Vendor Name is one for the key fields based on which the HASH or CHECKSUM values are generated.

So when the DMEE file is sent to the bank or uploaded into the banking web site, the HASH or CHECKSUM value generated will differ.

 

Let take a case and look into the same.

 

Customer Name :  JäüüÖ

 

1.png

 

Format tree SEPA_DD settings are shown below.

 

2.png

 

 

Execute the F110 –for the customer JäüüÖ

 

The customer name is being displayed as JaeueueOe  as per the conversion function.

 

3.png

 

In the standard tables like REGUH – its being displayed as JäüüÖ.

 

4.png

 

 

Now do the required changes in the DMEE format so that the German umlauts or the national special characters are not replaced.

 

Goto DMEE and give the Tree type and Format tree

 

5.png

 

Goto the node Dbtr and do the changes in the conversion function by unflagging Replace National Characters and Exclude/allow defined characters.

 

6.png

 

 

Goto F110 and execute the payment run and check the DME file.

 

7.png

 

8.png

 

The customer name is getting displayed as maintained in the master date without being converted.

Viewing all 366 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>