Payment Terms

Payment term is a part of accounts receivable component that helps you keep track of your receivables more effectively.

They play a vital role in identifying the exact receivable amounts as on a particular date

Background
Any business operates as you very well know on revenue. The revenue  is what helps any business grow and prosper exponentially. Inability to grow revenue hampers business. This must be true, but apart from revenue, there is one more thing that is as important as revenue for any business, COLLECTION. It means, it is not just important to sell any product, but also to recover money from the customer.

The business, everyday, lures its customers by throwing many offers / schemes for buying more and more, but if the money is not collected against this sale, then the business may face a big cash crunch. Hence, it becomes utmost important to get money from customers in time and Payment terms help us in this matter.

Click here to know more.

Field Status in Customer Master Data

Field status plays a very vital role in customer master data.

The Field Status is divided into following  statuses

Suppressed
Mandatory
Display
Optional

The statuses are maintained at following levels

Company Code
Account Group
Activity


All the fields are verified by the system based on the above and the combination is evaluated and accordingly decides about the field.

For more information on Field Status click HERE

Tags#

Field Status in Customer Master, SAP Field Status in Accounts Receivable

Customer Account Group

Account Group in Accounts Receivable component of Finance Module plays important role as far as Customer Masters are concerned.

Background
Each master record has a unique number assigned to it. This number is needed identify the customer and also to call up the master record or to post transactions. This number plays very important role and has lot of significance.


Importance
Now when we have understood the importance of customer numbering, we must also accept the fact that in practical scenario the business can have multiple types of customers. For e.g. Domestic Customers, Export Customers etc. With the different nature of customers, it becomes important to provide different number range for both the customers. 

Use
The Account Groups are used to determine:

• Interval for the account numbers
• Whether the number is assigned internally by the system or externally by the user (type of number assignment)
• Whether it is a one-time account
• Which fields will be displayed, editable, suppressed or mandatory while creating/changing Customer Master Data

The configuration for Customer Account Group is divided into:

• Definition
• Number Range Maintenance
• Assignment of Number Range

Definition

IMG PathFinancial Accounting (New) > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Preparations for Creating Customer Master Data > Define Account Groups with Screen Layout (Customers)

Fields in the Account Group

Account Group
This is 4 digit code that identifies the account group

Meaning
Description of the account group, for e.g. Domestic Customer, Export Customer

One Time Account
Select this option if you want all the masters under this account group to be treated as one time accounts

Field Status
This portion contains three parts viz. General Data, Company Code Data and Sales Data. The field status can be maintained for all the fields relevant for the account group here.


Number Range Maintenance
IMG PathFinancial Accounting (New) > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Preparations for Creating Customer Master Data > Create Number Ranges for Customer Accounts


In this configuration, we maintain the various number ranges required for the customer master data as per the account groups to be created. 

This table contains:
Range Number
From Number
To Number
Number Status


Assignment of Number Range
IMG PathFinancial Accounting (New) > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Preparations for Creating Customer Master Data > Assign Number Ranges to Customer Account Groups

In this configuration, we assign the Number Range to Customer Account Group.

 
Note:

The separate numbering of  will not just help in identifying the type of customer looking at the number, but also helps in many reports where we can enter ranges for executing report.

Tags#
SAP Number range in Customer Master, Customer Account Group Number Range, Assign number range to customer account group

FI-MM Integration (OBYC) - Part II

So we are back, as promised in the last post, we will go through the majorly used transactions in MM-FI Integration

Once again just for your information, Transaction Code: OBYC

Given below  is the information of some important Transactions in MM-FI Integration

Transaction	G/L Type	Remarks
BSV	P&L	Changes in stocks are posted in Inventory Management at the time goods receipts are recorded or subsequent adjustments made with regard to subcontract orders.
BSX	B/S	This transaction is used for all postings to stock accounts. Such postings are effected, for example: -        In inventory management in the case of goods receipts to own stock and goods issues from own stock -        In invoice verification, if price differences occur in connection with incoming invoices for materials valuated at moving average price and there is adequate stock coverage -        In order settlement, if the order is assigned to a material with moving average price and the actual costs at the time of settlement vary from the actual costs at the time of goods receipt Take care to ensure that: -        A stock account is not used for any transaction other than BSX -        Postings are not made to the account manually -        The account is not changed in the productive system before all stock has been booked out of it Otherwise differences would arise between the total stock value of the material master records and the balance on the stock account.
EIN/EKG/ FRE	P&L	These transactions are used only if Purchase Account Management is active in the company code.
FR1/FR2/ FR3/FR4	P&L	Freight clearing (FR1), provision for freight charges (FR2), customs duty clearing (FR3), provision for customs duty (FR4) These transactions are used to post delivery costs (incidental procurement costs) in the case of goods receipts against purchase orders and incoming invoices. Which transaction is used for which delivery costs depends on the condition types defined in the purchase order. You can also enter your own transactions for delivery costs in condition types.
FRL	P&L	This transaction is used to record the charges levied by the vendor for the subcontracting related to the material. Note: The G/L account assigned here should not be created as Cost Element
PRD	P&L	Price Differences Price differences arise for materials valuated at standard price in the case of all movements and invoices with a value that differs from the standard price. Examples: goods receipts against purchase orders (if the PO price differs from the standard priced), goods issues in respect of which an external amount is entered, invoices (if the invoice price differs from the PO price and the standard price). Price differences can also arise in the case of materials with moving average price if there is not enough stock to cover the invoiced quantity. In the case of goods movements in the negative range, the moving average price is not changed. Instead, any price differences arising are posted to a price difference account. Depending on the settings for the posting rules for transaction/event key PRD, it is possible to work with or without account modification. If you use account modification, the following modifications are available in the standard system: None For goods and invoice receipts against purchase orders PRF For goods receipts against production orders and order settlement (Variance) PRA For goods issues and other movements PRU For transfer postings (price differences in the case of external amounts)
UMB	P&L	Revenue/expense from revaluation This transaction/event key is used both in Inventory Management and in Invoice Verification if the standard price of a material has been changed and a movement or an invoice is posted to the previous period (at the previous price).
WRX	B/S	GR/IR clearing Postings to the GR/IR clearing account occur in the case of goods and invoice receipts against purchase orders. Balances in local currency only indicator for the GR/IR clearing account must be set in order to enable the open items to be cleared.

Here I have purposely left the Transaction GBB which contains multiple account modifiers and requires a separate post to explain the same properly.

Tags#

OBYC, MM-FI Integration, Account Modifier in OBYC, Valuation Modifier in G/L Account determination in MM, Material Management General Ledger Integration, Transactions in OBYC

OBYC-BSV, OBYC-BSX, OBYC-EIN EKG, OBYC- FR1 FR2, OBYC-FRL, OBYC-PRD, Production Order Variance G/L, Automatic G/L Account determination for Material Management (MM), OBYC-Revaluation, 

FI-MM Integration (OBYC) - Part I

Definition

When we speak about SAP, we must also talk about integration as we all are familiar with the integrated nature of SAP. Hence, today we will discuss about the integration of Material Management (MM) with Finance (FI) module.

In order to understand the integration, we first need to find answers for some questions:

What are automatic postings in MM-FI Integration?

Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting.

Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center:

o   Stock account
o   Consumption account

How does the system find the relevant accounts?

When entering the goods movement, the user does not have to enter a G/L account, since the ERP system automatically finds the accounts to which postings are to be made using the following data:

o   Chart of accounts of the company code

If the user enters a company code or a plant when entering a transaction, the ERP system determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts.

o   Valuation grouping code of the valuation area

If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code.

o   Transaction/event key (internal processing key)

Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction.

o   Account grouping (for offsetting entries, consignment liabilities, and price diff.)

Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code.

An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities.

o   Valuation class of material

The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction.

Background

As said above, we all know that SAP is highly integrated and creates all the financial documents automatically. In order to automate the financial posting related to Material Management, it becomes very important to map the G/L Accounts to appropriate transactions. The G/L account mapping in this case has to cater a lot of transactions, please keep reading for complete information.

Transaction Code for this integration is OBYC

IMG Path: Materials Management > Valuation and Account Assignment > Account Determination > Account Determination Without Wizard > Configure Automatic Postings

Once you type this code and press enter or use the IMG Path, system will navigate you to the screen which contains a list of Transactions. Before going ahead with individual transactions, lets understand first three radio buttons available in every transaction.

Posting key Button

This button contains the Posting Key that will be used to Debit/Credit the account when that particular transaction is executed.

Rules Button 

This button contains some important options, Valuation Modifier and Valuation Class.

Valuation Modifier
Select this radio button to enable assignment of different G/L accounts for different plants by activating the field Valuation Modifier for Account assignment.

Valuation ClassSelect this radio button to enable assignment of different G/L accounts for different valuation classes by activating the field Valuation Class for Account assignment. In case of transactions like freight where one G/L account is to be assigned to all valuation classes, do not activate this radio button. This will save your time of assigning same G/L account too all the valuation classes.

Select the appropriate option as per your requirement and proceed further.

Accounts Button

This is the button where all the G/L accounts are to be assigned for FI-MM Integration. This button contains, the options to enter G/L accounts based on the radio buttons selection under Rules button.

Note: activation/deactivation of any of the above options has to be done very very carefully. In case of transactions where G/L accounts are already assigned, activation/deactivation of these resets the assigned G/L accounts. Hence, if any such thing is to be done, first note down the already assigned G/L accounts.

Once all the above is done, we will discuss about the mostly use transactions in this integration in the next post.

Please keep in touch..................

Tags#
OBYC, FI-MM Integration, Accounts Button in OBYC, Rules button in OBYC, Posting Key Button in OBYC, G/L Account in OBYC, G/L Account in MM-FI Integration

Cost Centre Accounting Overview

Cost Center Accounting Overview

Use

We use Cost Center Accounting for controlling purposes within your organization. The costs incurred by your organization should be transparent. This requires that all costs be assigned according to their source. However, source-related assignment is especially difficult for overhead costs. Cost Center Accounting lets you analyze the overhead costs according to where they were incurred within the organization.

Dividing an organization into cost centers allows you to follow several goals, depending on the cost accounting method.

• Assigning costs to cost centers lets you determine where costs are incurred within the organization.
• If you plan costs at cost center level, you can check cost efficiency at the point where costs are incurred.
• If you want to assign overhead costs accurately to individual products, services, or market segments, you need to further allocate the costs to those cost centers directly involved in the creation of the products or services. From these cost centers you can then use different methods to assign the activities and costs to the relevant products, services, and market segments. This enables you to valuate semi-finished and finished products in Product Cost Controlling (CO-PC)

Expense Budget Planning

Cost centre planning involves entering plan figures for a particular costs (cost element) and cost centre for a particular planning period. Variances between plan and actual can be analysed using SAP’s standard reporting on real time basis.

Cost centre planning has the following objectives:

To plan the structure of the organization’s future operations for a clearly defined time period

You should define performance targets and target achievement grades. You must consider the internal and external (market) factors affecting your organization.

To control business methods within the current settlement period

This ensures that you keep as closely as possible to the plan. Iterative planning lets you adapt the target performance to reflect any changes in the organizational environment.

To monitor efficiency 

After completion of the settlement period using plan/actual or target/actual comparisons.

Cost Centre & Cost element planning will be done at start of year. This planned data will be entered in SAP. Plan v/s. Actual variance report can be extracted from SAP on real time basis. 

Expense budget planning process will be managed at cost elements in local currency. Budget process will be managed in standard SAP transactions.

Actual Cost booking

Primary costs can be transferred to Cost Accounting from other components, for example, Materials Management (MM), Asset Accounting (AA) and Payroll Accounting (PY). Or the primary cost can be booked manually within Financial Accounting by entering the Cost Centre manually during entry.

Period End Activities

Assessment and distribution

The Assessment/distribution is a period end activity that allocates both primary and secondary costs in the Cost Centre Accounting component (CO-OM-CCA). A cycle needs to be defined for assessment/distribution.

The basic difference in assessment and distribution is given below:

Assessment

The original cost elements are combined in secondary (assessment) cost elements. The original cost elements are not displayed on the receivers.

Sender and receiver information (sender cost centre, receiver cost centre, and so on) appears in the Controlling (CO) document.

Distribution
The original cost element (that is, the primary cost element) is retained.

Sender and receiver information (for example, the identities of the sender and receiver cost centre) is documented using line items in the CO document.

A given cycle can contain a number of segments. A segment consists of the following elements:

• Sender objects whose values to be allocated are computed using the same rules 
• Receiver objects whose allocation bases are computed using the same rules
• Information about the sender and the receiver is documented in the Controlling document
• The original cost element is retained in the receiver cost center. 

The sender-receiver relationship is defined in a cycle and the followings will be defined in the cycles:

• Cost centers or cost center groups 
• Cost elements or cost element groups

Tags#
SAP Actual cost booking
Cost Centre Accounting
Cost Centre Assessment
Cost Centre Budgeting
Cost Centre Distribution
SAP Cost Centre

Internal Order Overview

Internal Order

“Internal orders” are normally used to plan, collect, and settle the costs of internal jobs and tasks.

The SAP system enables you to monitor your internal orders throughout their entire life-cycle; from initial creation, through the planning and posting of all the actual costs, to the final settlement and archiving. 

SAP has provided following tools of analysis in the SAP Controlling:

• Cost centers: Where cost is incurred 
• Cost elements: Which cost is incurred 
• Internal Order: Purpose of spending 

The combination of these 3 axes provides the financial data with the needed level of details.


Internal orders can be used to

• Monitor the costs of short-term measures 
• Monitor the costs and revenues related to a specific service/activity 
• Monitor ongoing costs 

Internal Order Types

Order types provide the principle functionalities and codification rules for the individual orders. Given below is the further information on the two types of internal orders available in SAP:

Statistical Internal Orders: 

Statistical internal orders are used to collect cost for reporting purposes. Cost collected in a statistical internal cannot be allocated to other cost objects. Object used to monitor costs and, in some instances, revenues for an organization. You use the statistical order to evaluate costs which cannot be itemized in detail in cost element or cost center accounting.

Real Internal Orders: 

Every posting on a cost element is posted into only one “real” CO analytical object. This means that the charge could be re-allocated / transferred to another CO object afterwards.

Transaction Code: KO01

Settlement

An internal order is usually used as an interim collector of costs and an aid to the planning, monitoring, and controlling processes needed. When the job has been completed, you settle the costs to one or more receivers (cost center, fixed asset, profitability segment, and so on).

Only Real Internal Order can be settled and there is no need to settle Statistical Internal Order.

To be able to settle an order, you must have saved a settlement rule in each of the senders. This settlement rule determines where the costs are to be settled to. You can achieve this in two ways:

Settlement to One Receiver

You use this basic form of order settlement to completely settle the costs collected on the internal order. This is either to a cost center, or a G/L account under a settlement cost element. The system generates the appropriate settlement rule from the information contained in the internal order master data.

Comprehensive Settlement

Definition of a comprehensive settlement rule gives you more settlement possibilities, for example, you can: 

o   Settle costs to a wide range of receivers (project, SO, profitability segment, and so on).

o   Specify how the costs are to be distributed between receivers.

Tags#
Internal Order Settlement, Real Internal Order, SAP Internal Order, Statistical Internal Order, 

Activity Type overview

Activity Types

Activity types classify the activities produced in the cost centers within a controlling area.

Use

To plan and allocate the activities, the system records quantities that are measured in activity units. Activity quantities are valuated using a price (allocation price).

In Overhead Cost Controlling, costs based on the activity quantity of an activity type are posted separately in fixed and variable portions. When you divide the activities of a cost center into activity types, you should consider whether the costs can be allocated effectively to the activity types.

In an internal activity allocation, the quantity of the activity, such as a number of consulting hours, is entered into the SAP system (manually or automatically). The system calculates the associated cost based on the activity price and generates a debit to the receiver and a credit to the sender for both the quantity and costs. The internal activity allocation is carried out using secondary cost elements, which are stored as default types in the activity type master data.

You can restrict the use of the activity type to certain types of cost centers by entering the allowed cost center categories in the activity type master record. You can enter up to eight allowed cost center categories, or leave the assignments "unrestricted" by entering an asterisk ( * ).

An Activity type master contains following fields:

Name

Enter the name of the Activity type

Description

Enter the description of the Activity type

Activity Unit

Enter the unit of measure in which the activity will be managed. This is very important field and can’t be changed easily once various assignments are done. Hence, it is important to decide the appropriate unit of measure for each Activity type

Cost Centre Categories

Categories maintained under this field control the cost centre against which rate for activity types can be maintained (these categories are assigned in the cost centre master data) 

Activity Type Category

Enter the appropriate category. This Indicator determines the method of activity quantity planning and activity allocation.

Following options are available for activity type category

Activity type category 1 (Manual entry, manual allocation)
Activity type category 2 (Indirect calculation, indirect allocation)
Activity type category 3 (Manual entry, indirect allocation)
Activity type category 4 (Manual entry, no allocation)

Allocation Cost Element

Given below is the list of sample Activity Types that can be used:

Activity Type Code	Description	Unit of Measure
1000	Power	KWH
1100	Fuel	KG/LTR
1200	Labour	HR
1400	Depreciation	HR
1500	Machine Setup	HR

Transaction Code : KL01

Tags#
Activity Type Categories, Activity Type Master, Cost Centre Categories, SAP Activity Type, 

Cost Elements

Cost Elements

Cost Elements play a very important role in the reconciliation/alignment of costs and postings between Financial Accounting (FI) and Management Accounting/ Controlling (CO). 

There are two types of cost elements such as Primary Cost Elements, Secondary Cost Elements and Revenue Cost Elements all which have a specific purpose. The category set for a Cost Element at the time of creation will determine the transactions that can utilize the cost element.

Due to the integrated nature of SAP Systems there is a requirement to create expense accounts in Financial Accounting with corresponding primary cost elements in Controlling. Cost elements capture costs incurred within a particular accounting period. This ensures that expenses in Financial Accounting and primary costs in Management Accounting can be reconciled. Cost Elements are closely related to the general ledger accounts used in FI-GL.

The SAP terminology defines two different categories of Analytical Accounts (Cost Elements) as below:

o   The Primary Cost Elements

o   The Secondary Cost Elements

Primary Cost Elements:

The codification and description for “primary cost elements” is same as the General Ledger accounts.

Primary cost elements can be automatically created when we have a new G/L account in the CoA. Or we also have an option to keep the cost element creation manual (refer Chart of Accounts)

All P&L accounts will be created as “primary cost elements” in 3 categories:

o   Cost elements

o   Revenue element

o   Sales Deduction

No Primary Cost Element can be created with creating G/L Account in Finance module.

“Primary costs elements” are grouped under a hierarchy for reporting purposes; it enables to have a more operational view than the sequential sorted view of the Financial Accounting

This grouping will be managed with master data: cost element groups. It doesn’t require any customizing

All primary cost elements will be updated by FI posting during:

o   Invoice entries

o   Depreciation calculation

o   Etc.

We will not have any manual posting on “primary cost elements” in CO Module. So, the balance of primary cost elements will be always the same with FI balance.

If any G/L account is not created as a “primary cost element”, postings on this account will not be seen in CO module, neither in Cost Center Accounting, nor in Profit Center Accounting.

If any G/L account is created as a “primary cost element”, it will ask a CO object at the time of the posting in FI module. If we don’t enter a CO object, system will not save this data entry in order to keep FI and CO balance 100% same.

CO objects can be the followings:

o   Cost center

o   Project

o   Process Orders

o   Internal Orders

o   Service Orders

o   Etc.

In order to support our overhead reporting requirement, all expense accounts will work with “cost center” information.

Sometimes we might need to post expenses directly to the jobs (service orders or projects/WBS). In that case, 2 CO objects will be used: service order or WBS and cost center. Cost center will have the “statistical posting” just to support overhead reporting.

Secondary Cost Elements

For analytical purpose, the Controlling has additional accounts “secondary cost elements”, which are not defined in the Financial Accounting (FI module). These accounts are used to trace internal flows of allocation within the Controlling.

“Secondary cost elements” do not correspond to any G/L account in Financial Accounting, thus they are only used in Cost Controlling (CO modules).

“Secondary costs elements” can be grouped for reporting purpose. Cost element groups are considered another master data of CO module. Some of the cost element groups will be common for all entities, and each entity will have a flexibility to create their own groups according to their needs.

Standard “Secondary cost element” categories will be used in Core Design. Given below is the list of few categories for your ready reference:

Category 21 - Internal settlement: It is used for settlement from one CO object to another CO object.

Category 31 – Order/Project Result Analysis: It is used to calculate work in process for production orders, process orders and product cost collectors.

Category 41 – Overhead Rates: It is used for indirect allocations from cost center to cost objects

Category 42 – Assessment: It’s used for internal cost allocations between cost centers or different cost objects.

Category 43 - Internal Activity Allocation: Direct allocation from cost centers to Cost object

Transaction Code: 

Primary Cost Element : KA01
Secondary Cost Element: KA06



Tags#
Cost Element Categories, Primary Cost Element, SAP Cost Elements, SAP Primary Cost Element, SAP Secondary Cost Element, Secondary Cost Element, 

Vendor Master Data Overview

Vendor Master Data Overview

The Accounts Payable application component records and manages accounting data of all vendors.

Creating Vendor Master Data

The vendor master records are maintained in sub-ledger and are used in Financial Accounting and Materials Management. By storing vendor master data centrally and sharing it throughout whole organisation, it is only needed to enter it once. It gives an ability to prevent inconsistencies in master data by maintaining it centrally.

A vendor master record contains:

o   The General Data; containing the vendor’s name, address, language, region and phone numbers

o   Company Code Data; containing the reconciliation account, bank details, cash management information, payment methods and tax data

o   Purchasing data; containing his purchasing organisation data

The vendors are maintained with a unique number. any number of digits can be used and they can be assigned internally/externally. To create a master record, it is obligatory to specify an account group. The account group cannot be changed after the master record is created. 

The vendor account groups can be as given below:

Account Group	Definition	Number Range
ZD10	Vendors Group – Local Material	100001-139999
ZD20	Vendors Group – Subcontracting	140001-149999
ZD30	Vendors Group – Expenses	150001-159999
ZD40	Vendor Group – Services	160001-169999
ZD50	Vendors Group – Others	170001-179999
ZC10	Vendors Group - Capital Goods	200001-209999
ZI10	Vendors Group – Import Material	300001-309999
ZS10	Vendor Group – Stock Transfer	V1001 – V9999
ZO10	Vendors Group – One time	400001-409999
ZE10	Vendors Group – Employees	E00001-E99999

Editing & Blocking & Deleting Vendor Master Data

Editing

o   The account group cannot be edited

o   The account assignment cannot be edited

Blocking

A vendor account can be blocked and unblocked any time.

Deleting

Vendor accounts to be deleted are first marked for deletion.  No transaction figures should be stored for this vendor account. The account must be blocked for posting before it can be deleted.

Displaying Changes

The system logs all changes to vendor master records.  For each changed field, it stores the time of change, the user’s name, and the current and previous field contents.

Reconciliation Account

When any entry is posted to a subsidiary ledger, the system automatically posts the same data to the general ledger (see the following illustration). Each subsidiary ledger a reconciliation accounts in the general ledger. These reconciliation accounts ensure that the balance of G/L accounts is always matching with the sub ledger. This means that you can draw up balance sheets at any time without having to transfer totals from the sub ledgers to the general ledger. 

Transaction Code

Vendor Master Finance View : FK01
Vendor Master Purchasing View : MK01
Vendor Master centralised maintenance : XK01

Tags#

SAP Vendor Master, Vendor Account Groups, Vendor Reconciliation Account,