Top 10 SAP TCodes that appear most in SAP menu tree
After developing http://tcodes.ofsap.com, which is based on SAP ECC 6.0, I tried some ‘search’ activities about SAP transaction codes to kill time at my office (I hope my boss won’t read this blog).
I found some trivia that I’d like to share. As Wikipedia said, trivia is “knowledge that is nice to have but not essential”, you might think it’s silly and not important. It’s fine by me.
I found that several SAP tcodes appear at several nodes of SAP menu tree, for example FBL1N appears 4 times on SAP menu tree:
SAP Menu⇒Accounting⇒Financial Accounting⇒Accounts Payable⇒Account⇒Display/Change Line Items
SAP Menu⇒Accounting⇒Real Estate Management⇒Real estate general contract⇒Postings⇒Vendor menu⇒Account⇒Display/Change Line Items
SAP Menu⇒Accounting⇒Flexible Real Estate Management⇒Accounting⇒Reporting⇒Vendor Line Items
SAP Menu⇒Accounting⇒Flexible Real Estate Management⇒Information System⇒Accounting⇒Vendor Line Items
PA30 tcode, beside at SAP Menu⇒Human Resources⇒Personnel Management⇒Administration⇒HR Master Data⇒Maintain, also appears 34 times at other nodes of SAP menu tree.
So, I run a query on tcodes.ofsap.com database and found the top 10 SAP transaction codes that appear most in SAP menu tree as follow:
MM03 tcode appears 117 times on SAP menu tree
S_ALR_87000881 tcode appears 111 times on SAP menu tree
MM02 tcode appears 85 times on SAP menu tree
MC93 tcode appears 75 times on SAP menu tree
MC94 tcode appears 75 times on SAP menu tree
MC95 tcode appears 75 times on SAP menu tree
PC00_M99_DKON tcode appears 66 times on SAP menu tree
PU03 tcode appears 65 times on SAP menu tree
XK03 tcode appears 65 times on SAP menu tree
PC00_M99_DLGA20 tcode appears 64 times on SAP menu tree
Are you familiar with the above SAP tcodes? I am familiar only with some of them, such as MM03 and MM02, but I don’t know that they exist on that many places at SAP menu.
Do you have other SAP trivia? Please share with us, just login (register) from the menu on the left and submit it as an article. Or, if you don’t want to bother writing an article, just leave a comment on the box below.
Monday, 21 November 2011
LSMW - Create Purchase Requisition (PR)
SAP Study Materials Store
LSMW (Legacy System Migration Workbench), from its name, is a tool in SAP ERP that allows us to do the migration data from Non-SAP system to SAP system. It’s usually used in the Go-live preparation phase of SAP implementation project to create multiple records of SAP master data or transaction data (such as material master, vendor master , customer master, purchasing document, etc), without entering them one by one.
With LSMW, SAP can read an input file, for example a .txt file, which contains multiple records with some columns, and then convert them into SAP data. Of course, we had to define the format of the input file and the conversion rule first before we run the LSMW tool. The contents of the input file can be the master or transaction data form legacy system that needs to be migrated to SAP system.
LSMW can be used not only for data migration, but it also can be used in the production phase of SAP implementation for various needs, such as to create or update master data or transaction data which are not efficient if we do it one by one. Although SAP has provided “mass change” functionalities such as MM17, MEMASSRQ, MEMASSPO tcodes, with LSMW, we have more flexibility in terms of fields that can be changed.
We can use LSMW to do various SAP transactions as it has four object types and import methods, which are:
Standard batch/direct input
Batch input recording
Business Object Method (BAPI)
Intermediate Document (IDOC)
The first two methods can be run without any ABAP programming knowledge, so it can be created by anyone who understand the specific transaction well including the functional analyst, or even end-users. But, the first two methods can be enhanced, if needed, with a simple ABAP logic, because SAP has provided the functionalities. The next two methods needs ABAP programming.
In this example, I will show how to use LSMW to create Purchase Requisition (PR) documents from a set of input files. I will use the Standard batch/direct input method because it requires no ABAP programming, and unlike Batch Input Recording method, it can be used to create multiple records in a purchasing document.
With Batch input recording, which you can think like macro recording in MS office, it’s difficult to create a document with multiple records because there might be different count of the records in each document in the input files, while we must determined it in the recording process when we create the LSMW program.
In this example I will generate LSMW program for creating PR documents which can have multiples items with single account assignment “cost center”.
You can download the screenshots of step by step guide how to use LSMW to create PR documents with multiple items here. You can learn the concept behind it and apply it to your own needs. If you have any comments, opinion, or questions, you can post it in the “comment” section below.
LSMW (Legacy System Migration Workbench), from its name, is a tool in SAP ERP that allows us to do the migration data from Non-SAP system to SAP system. It’s usually used in the Go-live preparation phase of SAP implementation project to create multiple records of SAP master data or transaction data (such as material master, vendor master , customer master, purchasing document, etc), without entering them one by one.
With LSMW, SAP can read an input file, for example a .txt file, which contains multiple records with some columns, and then convert them into SAP data. Of course, we had to define the format of the input file and the conversion rule first before we run the LSMW tool. The contents of the input file can be the master or transaction data form legacy system that needs to be migrated to SAP system.
LSMW can be used not only for data migration, but it also can be used in the production phase of SAP implementation for various needs, such as to create or update master data or transaction data which are not efficient if we do it one by one. Although SAP has provided “mass change” functionalities such as MM17, MEMASSRQ, MEMASSPO tcodes, with LSMW, we have more flexibility in terms of fields that can be changed.
We can use LSMW to do various SAP transactions as it has four object types and import methods, which are:
Standard batch/direct input
Batch input recording
Business Object Method (BAPI)
Intermediate Document (IDOC)
The first two methods can be run without any ABAP programming knowledge, so it can be created by anyone who understand the specific transaction well including the functional analyst, or even end-users. But, the first two methods can be enhanced, if needed, with a simple ABAP logic, because SAP has provided the functionalities. The next two methods needs ABAP programming.
In this example, I will show how to use LSMW to create Purchase Requisition (PR) documents from a set of input files. I will use the Standard batch/direct input method because it requires no ABAP programming, and unlike Batch Input Recording method, it can be used to create multiple records in a purchasing document.
With Batch input recording, which you can think like macro recording in MS office, it’s difficult to create a document with multiple records because there might be different count of the records in each document in the input files, while we must determined it in the recording process when we create the LSMW program.
In this example I will generate LSMW program for creating PR documents which can have multiples items with single account assignment “cost center”.
You can download the screenshots of step by step guide how to use LSMW to create PR documents with multiple items here. You can learn the concept behind it and apply it to your own needs. If you have any comments, opinion, or questions, you can post it in the “comment” section below.
A Guide to SAP's SME Software Products
SAP Study Materials Store
a guest post by: Chris Thorman, Senior Marketing Manager of Software Advice (www.SoftwareAdvice.com)
This post comes from Software Advice CEO Don Fornes, a web site that reviews manufacturing software systems.
Throughout its existence, SAP has been known as an enterprise-class applications vendor – one that sells only to really big companies. At the same time, SAP has attempted – through marketing, channels and development – to move “down market” into the realm of small and mid-size enterprises (SMEs). Today, that strategy has resulted in a portfolio of software solutions that might need some explaining. I’ll give it a try.
Before we dig into the SAP portfolio, it’s important to understand a few things about the SME market:
There exists a range of SMEs and one-size does not fit all. A $750 million SME has very different needs than a $10 million SME.
The smaller the SME, the less likely they are to adopt complex technology. When they do get into technology, they typically like Microsoft platforms (e.g. .Net, SQL Server).
SMEs were the first to adopt software as a service (SaaS), and that model continues to gain traction within the SME market. Any SME strategy must include a SaaS strategy.
The implications of those three points for SAP were that SAP could not just “re-package” its core SAP Business Suite – the “big company product” formerly known as R/3 – and call it an SME strategy. SAP actually tried this throughout the 1990s, but in 2002 they started on a new path toward specific solutions designed just for the SME market.
SAP products by size of business, as measured by employee count
By far the biggest differentiator between the various SAP solutions is the size of organization for which they are designed. Of course, SAP Business Suite is designed for large organizations – those with thousands or tens of thousands of employees and likely hundreds or thousands of ERP users.
All-in-One, with its preconfigured industry solutions, is able to go further down market to serve organizations in the 500+ employee range – the high-end of the SME market.
ByDesign is targeting organizations in the 100 to 500 employee range. Over time, as ByDesign matures functionally and becomes more scalable, we expect increasingly larger organizations to adopt the ByDesign SaaS model. So, in our diagram we indicate this as moving up-market.
Finally, Business One is clearly targeted at the low-end of the SME market. It’s simplicity is a fit for organizations with fewer than 100 employees, but at least ten.
SAP Products by Application Functionality
From a functional standpoint, there is a wide variation in the capabilities of the various SAP products. Business Suite, again, is extremely full-featured. So too is Business All-in-One. Business ByDesign is not as fully featured as its on-premise siblings, but SAP is investing rapidly in developing more functionality. Finally, Business One remains a fairly simple applications suite; its primary capability is core accounting, complemented by hundreds of add-on modules offered by a network of roughly 1,200 reseller partners.
SAP Products by Industry Coverage
SAP has long prided itself on offering very specific functionality for a wide range of industries. Business Suite, of course, has very deep coverage across most major industries. Business All-in-One inherits this deep industry functionality, since it shares the same code base.
Business ByDesign and Business One offer narrower coverage of industries, since they are newer solutions. SAP is still extending the core horizontal functionality of these solutions (e.g. CRM, SCM) and will, over time, extend the vertical industry functionality.
In the case of Business One, SAP offers a very robust set of developer tools, which allow third-party reseller partners to extend the solution to meet the needs of specific industries. Over time, we expect SAP to incorporate these add-on modules into the core Business One codebase. Microsoft has executed a similar strategy with its Microsoft Dynamics products.
Software Deployment Options
Traditionally, SAP solutions were installed on-premise; that is, the software was installed locally at each of a customer’s facilities. From an architectural standpoint, there is software to be installed on a server (i.e. the core application functionality and the database), as well as on the client machine (i.e. each user’s computer). Some SAP applications are web-based, meaning that all software is installed on the server, while users access the application via a web browser. Regardless, any software would be installed and maintained at the customer’s facilities.
Through a network of reseller and hosting partners, SAP began to offer hosted versions of its solutions in the late 1990s and continues to offer these solutions today. Business All-in-One, specifically, is offered in both an on-premise and hosted model. Business One, however, is only offered as an on-premise solution, meaning that all software is installed at the customer’s facility.
Business ByDesign is a clear departure from SAP’s traditional on-premise model. Business ByDesign is a pure web-based solution, offered on-demand. That is, all of the software is hosted at an SAP data center and every user accesses the system through a web browser over the Internet.
Pricing and Cost of Ownership
Pricing for Business Suite and Business-All-in-One is a traditional mix of package licenses and named-user licenses. That means that a buyer will pay a certain amount to purchase the applications they need, as well as a separate license for each user who will access the system. The later licenses will vary in price based on whether a user is a power user or an infrequent user accessing reports, etc. Finally, the buyer will have to purchase a maintenance contract (typically 15% to 20% of the original license price), which will entitle them to customer support and upgrades.
While Business Suite implementations are often seven-figure investments, we believe that a Business All-in-One implementation can cost as little as $350,000, including software and services. Of course, most implementations become more complex due to customization and integration, so many will cost substantially more than $350,000. Since Business All-in-One is available on a hosted basis, SAP also offers – through its partners – subscription pricing.
SAP Business One follows a similar pricing model but costs far less. Again, the cost depends on various factors, including the number of users and the type of access each user will need. We believe that Business One implementations range from $25,000 to $250,000. The variation will be driven in large part by the number of third-party add-on modules that are purchased and how much customization and integration is performed by the channel partner.
Business ByDesign offers the most unique pricing amongst the various SAP products. A pure subscription model, Business ByDesign costs $149/user/month. There is, however, a minimum licensing requirement of 25 users, which brings the total monthly minimum subscription to $3,725 per month.
To compare Business ByDesign pricing to the other SAP solutions on an apples-to-apples basis, we can compute a net present value (NPV) of $27,416 (assuming a ten-year life for software and a 6% discount rate). Of course, that is just the lowest-level price. A company with 300 users could expect to pay the equivalent of a six-figure, up-front investment (say, ~$200,000).
Business ByDesign, by design (pun intended), is not meant to be customized intensively. Therefore, buyers can expect to invest far less in customization and integration, assuming they can make the out-of-the-box version work for their business.
a guest post by: Chris Thorman, Senior Marketing Manager of Software Advice (www.SoftwareAdvice.com)
This post comes from Software Advice CEO Don Fornes, a web site that reviews manufacturing software systems.
Throughout its existence, SAP has been known as an enterprise-class applications vendor – one that sells only to really big companies. At the same time, SAP has attempted – through marketing, channels and development – to move “down market” into the realm of small and mid-size enterprises (SMEs). Today, that strategy has resulted in a portfolio of software solutions that might need some explaining. I’ll give it a try.
Before we dig into the SAP portfolio, it’s important to understand a few things about the SME market:
There exists a range of SMEs and one-size does not fit all. A $750 million SME has very different needs than a $10 million SME.
The smaller the SME, the less likely they are to adopt complex technology. When they do get into technology, they typically like Microsoft platforms (e.g. .Net, SQL Server).
SMEs were the first to adopt software as a service (SaaS), and that model continues to gain traction within the SME market. Any SME strategy must include a SaaS strategy.
The implications of those three points for SAP were that SAP could not just “re-package” its core SAP Business Suite – the “big company product” formerly known as R/3 – and call it an SME strategy. SAP actually tried this throughout the 1990s, but in 2002 they started on a new path toward specific solutions designed just for the SME market.
SAP products by size of business, as measured by employee count
By far the biggest differentiator between the various SAP solutions is the size of organization for which they are designed. Of course, SAP Business Suite is designed for large organizations – those with thousands or tens of thousands of employees and likely hundreds or thousands of ERP users.
All-in-One, with its preconfigured industry solutions, is able to go further down market to serve organizations in the 500+ employee range – the high-end of the SME market.
ByDesign is targeting organizations in the 100 to 500 employee range. Over time, as ByDesign matures functionally and becomes more scalable, we expect increasingly larger organizations to adopt the ByDesign SaaS model. So, in our diagram we indicate this as moving up-market.
Finally, Business One is clearly targeted at the low-end of the SME market. It’s simplicity is a fit for organizations with fewer than 100 employees, but at least ten.
SAP Products by Application Functionality
From a functional standpoint, there is a wide variation in the capabilities of the various SAP products. Business Suite, again, is extremely full-featured. So too is Business All-in-One. Business ByDesign is not as fully featured as its on-premise siblings, but SAP is investing rapidly in developing more functionality. Finally, Business One remains a fairly simple applications suite; its primary capability is core accounting, complemented by hundreds of add-on modules offered by a network of roughly 1,200 reseller partners.
SAP Products by Industry Coverage
SAP has long prided itself on offering very specific functionality for a wide range of industries. Business Suite, of course, has very deep coverage across most major industries. Business All-in-One inherits this deep industry functionality, since it shares the same code base.
Business ByDesign and Business One offer narrower coverage of industries, since they are newer solutions. SAP is still extending the core horizontal functionality of these solutions (e.g. CRM, SCM) and will, over time, extend the vertical industry functionality.
In the case of Business One, SAP offers a very robust set of developer tools, which allow third-party reseller partners to extend the solution to meet the needs of specific industries. Over time, we expect SAP to incorporate these add-on modules into the core Business One codebase. Microsoft has executed a similar strategy with its Microsoft Dynamics products.
Software Deployment Options
Traditionally, SAP solutions were installed on-premise; that is, the software was installed locally at each of a customer’s facilities. From an architectural standpoint, there is software to be installed on a server (i.e. the core application functionality and the database), as well as on the client machine (i.e. each user’s computer). Some SAP applications are web-based, meaning that all software is installed on the server, while users access the application via a web browser. Regardless, any software would be installed and maintained at the customer’s facilities.
Through a network of reseller and hosting partners, SAP began to offer hosted versions of its solutions in the late 1990s and continues to offer these solutions today. Business All-in-One, specifically, is offered in both an on-premise and hosted model. Business One, however, is only offered as an on-premise solution, meaning that all software is installed at the customer’s facility.
Business ByDesign is a clear departure from SAP’s traditional on-premise model. Business ByDesign is a pure web-based solution, offered on-demand. That is, all of the software is hosted at an SAP data center and every user accesses the system through a web browser over the Internet.
Pricing and Cost of Ownership
Pricing for Business Suite and Business-All-in-One is a traditional mix of package licenses and named-user licenses. That means that a buyer will pay a certain amount to purchase the applications they need, as well as a separate license for each user who will access the system. The later licenses will vary in price based on whether a user is a power user or an infrequent user accessing reports, etc. Finally, the buyer will have to purchase a maintenance contract (typically 15% to 20% of the original license price), which will entitle them to customer support and upgrades.
While Business Suite implementations are often seven-figure investments, we believe that a Business All-in-One implementation can cost as little as $350,000, including software and services. Of course, most implementations become more complex due to customization and integration, so many will cost substantially more than $350,000. Since Business All-in-One is available on a hosted basis, SAP also offers – through its partners – subscription pricing.
SAP Business One follows a similar pricing model but costs far less. Again, the cost depends on various factors, including the number of users and the type of access each user will need. We believe that Business One implementations range from $25,000 to $250,000. The variation will be driven in large part by the number of third-party add-on modules that are purchased and how much customization and integration is performed by the channel partner.
Business ByDesign offers the most unique pricing amongst the various SAP products. A pure subscription model, Business ByDesign costs $149/user/month. There is, however, a minimum licensing requirement of 25 users, which brings the total monthly minimum subscription to $3,725 per month.
To compare Business ByDesign pricing to the other SAP solutions on an apples-to-apples basis, we can compute a net present value (NPV) of $27,416 (assuming a ten-year life for software and a 6% discount rate). Of course, that is just the lowest-level price. A company with 300 users could expect to pay the equivalent of a six-figure, up-front investment (say, ~$200,000).
Business ByDesign, by design (pun intended), is not meant to be customized intensively. Therefore, buyers can expect to invest far less in customization and integration, assuming they can make the out-of-the-box version work for their business.
fico material
A few days ago, I've found a very interesting URL link. I am sure it will be very useful for SAP learners, so I would like to share it with all of you. The link will take you to an SAP IDES login page. With a certain user id and password (and they're free), you can access an SAP IDES client and can do whatever the administrator gives you the authorization for. As far as I try, I can perform transactions, maintain master data, configuration (SPRO) on that client. It really helps to learn SAP on IDES system. If you don't have your own SAP IDES system, you will like this link.
The owner of this SAP IDES system is Consolut, a consulting company. It's an SAP Services Partner which located in Germany and Switzerland. It has about 180 clients.
To get an access to the Consolut's SAP IDES system you can perform these steps:
(disclaimer: these steps are valid at the time I write this post, and may be changed by Consolut at any time they want)
If you don't have a user id, you can request one by doing these steps:
Go to http://www.ides.consolut.eu/user_request
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/zuser_req
Fill the form on that page like the below image
The above image is © SAP AG 2010. All rights reserved
Click the "execute" button on the above form, then it will show an information window like the below image.
The above image is © SAP AG 2010. All rights reserved
Click the OK button. You will receive an email that tells you that your request will be processed within 2 business days. But, from my experience, they will process it on the same day.
After the registering process, you will receive an email that tells your User ID. You need to request the password daily, because they will change it every day at 00:01 AM CET (I think it's not a big deal for the free access they give us).
If you've already had a user ID, you need to request the password daily by doing these following steps:
Go to http://www.ides.consolut.eu/user
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/zwebgui
Fill the form on that page like the below image.
The above image is © SAP AG 2010. All rights reserved
You will receive an email that inform the password which can be used until 12:00 PM CET.
Go to http://www.ides.consolut.eu/
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/webgui
Fill your user ID and password on the below form.
The above image is © SAP AG 2010. All rights reserved
Click "Log On" button. Then you can do whatever you want on the SAP IDES system. Be responsible there, we don't want they close the free access because someone messes up with their system.
If you have any other links that provide free online SAP IDES access please share them with us.
Please also share your experience in using those services.
Have a nice learning process.
The owner of this SAP IDES system is Consolut, a consulting company. It's an SAP Services Partner which located in Germany and Switzerland. It has about 180 clients.
To get an access to the Consolut's SAP IDES system you can perform these steps:
(disclaimer: these steps are valid at the time I write this post, and may be changed by Consolut at any time they want)
If you don't have a user id, you can request one by doing these steps:
Go to http://www.ides.consolut.eu/user_request
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/zuser_req
Fill the form on that page like the below image
The above image is © SAP AG 2010. All rights reserved
Click the "execute" button on the above form, then it will show an information window like the below image.
The above image is © SAP AG 2010. All rights reserved
Click the OK button. You will receive an email that tells you that your request will be processed within 2 business days. But, from my experience, they will process it on the same day.
After the registering process, you will receive an email that tells your User ID. You need to request the password daily, because they will change it every day at 00:01 AM CET (I think it's not a big deal for the free access they give us).
If you've already had a user ID, you need to request the password daily by doing these following steps:
Go to http://www.ides.consolut.eu/user
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/zwebgui
Fill the form on that page like the below image.
The above image is © SAP AG 2010. All rights reserved
You will receive an email that inform the password which can be used until 12:00 PM CET.
Go to http://www.ides.consolut.eu/
It will redirect you to http://www.ides.consolut.eu/sap/bc/gui/sap/its/webgui
Fill your user ID and password on the below form.
The above image is © SAP AG 2010. All rights reserved
Click "Log On" button. Then you can do whatever you want on the SAP IDES system. Be responsible there, we don't want they close the free access because someone messes up with their system.
If you have any other links that provide free online SAP IDES access please share them with us.
Please also share your experience in using those services.
Have a nice learning process.
interview questions sap fico module 556
What is SAP ERP?
What’s SAP?
SAP AG is a German software company which is known as the market leader in Enterprise Resources Planning (ERP) software products. Its global market share in ERP software products was estimated as 27.5 percent in 2007, far surpassing the second-ranked competitor (Oracle) at 13.9 percent. Approximately, SAP has 75,000 customers which are various companies that spread in 120 countries.
It’s the largest software company in Europe and the third largest software company in the world after Microsoft and Oracle. Microsoft and Oracle have various software products other than ERP application that SAP don’t.
SAP History
SAP was founded in 1972 in Mannheim, Baden-W’rttemberg by five former IBM engineers: Dietmar Hopp, Hans-Werner Hector, Hasso Plattner, Klaus Tschira, and Claus Wellenreuther. Originally, SAP means Systemanalyse und Programmentwicklung (in english: Systems analysis and program development). Then they changed the acronym to Systeme, Anwendungen und Produkte in der Datenverarbeitung (in english: Systems, Applications and Products in Data Processing).
In 1976, the company became a GmbH (Gesellschaft mit beschr’nkter Haftung) company (in USA known as limited liability company, LLC). In 1977, its headquarter was moved to Walldorf. In August 1988, it became an AG (Aktiengesellschaft) company (in USA known as public company).
The first SAP software was known as R/1. It was launched in 1972. ‘R’ means ‘Real-time Data Processing’. R/1 was a financial accounting system. In 1979, it was replaced by R/2. SAP R/2 was a mainframe based business application software suite. On July 6, 1992, SAP launched R/3. It was a client-server version software that was manageable on multiple platforms and operating systems, such as Microsoft Windows or UNIX.
’3′ in R/3 means ’3-tiered’ as it is a client/server based application. It utilizes a 3-tiered model:
Presentation layer, or client, which interfaces with the user.
Application layer which houses all the business-specific logic.
Database layer which records and stores all the information about the system, including transactional and configuration data.
SAP R/3 is has some functional modules that can be applied in almost all departments in a company. The most widely used modules are Financials and Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales & Distribution (SD), Production Planning (PP), Plant Maintenance (PM), etc. The overview of each module will be explained in the next article. Each module is used for specific business processes in a company and can be linked if applicable as they are stored in the same database.
What’s SAP?
SAP AG is a German software company which is known as the market leader in Enterprise Resources Planning (ERP) software products. Its global market share in ERP software products was estimated as 27.5 percent in 2007, far surpassing the second-ranked competitor (Oracle) at 13.9 percent. Approximately, SAP has 75,000 customers which are various companies that spread in 120 countries.
It’s the largest software company in Europe and the third largest software company in the world after Microsoft and Oracle. Microsoft and Oracle have various software products other than ERP application that SAP don’t.
SAP History
SAP was founded in 1972 in Mannheim, Baden-W’rttemberg by five former IBM engineers: Dietmar Hopp, Hans-Werner Hector, Hasso Plattner, Klaus Tschira, and Claus Wellenreuther. Originally, SAP means Systemanalyse und Programmentwicklung (in english: Systems analysis and program development). Then they changed the acronym to Systeme, Anwendungen und Produkte in der Datenverarbeitung (in english: Systems, Applications and Products in Data Processing).
In 1976, the company became a GmbH (Gesellschaft mit beschr’nkter Haftung) company (in USA known as limited liability company, LLC). In 1977, its headquarter was moved to Walldorf. In August 1988, it became an AG (Aktiengesellschaft) company (in USA known as public company).
The first SAP software was known as R/1. It was launched in 1972. ‘R’ means ‘Real-time Data Processing’. R/1 was a financial accounting system. In 1979, it was replaced by R/2. SAP R/2 was a mainframe based business application software suite. On July 6, 1992, SAP launched R/3. It was a client-server version software that was manageable on multiple platforms and operating systems, such as Microsoft Windows or UNIX.
’3′ in R/3 means ’3-tiered’ as it is a client/server based application. It utilizes a 3-tiered model:
Presentation layer, or client, which interfaces with the user.
Application layer which houses all the business-specific logic.
Database layer which records and stores all the information about the system, including transactional and configuration data.
SAP R/3 is has some functional modules that can be applied in almost all departments in a company. The most widely used modules are Financials and Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales & Distribution (SD), Production Planning (PP), Plant Maintenance (PM), etc. The overview of each module will be explained in the next article. Each module is used for specific business processes in a company and can be linked if applicable as they are stored in the same database.
FI Configuration-07: Posting Periods
SAP Study Materials Store
In the previous article we have defined fiscal year variant that determines the beginning and end of fiscal year; the number of "normal" and “special” posting periods; and the posting period length. For every company code, we must assign a fiscal year variant to it.
Now, we will explain about the posting period. What exactly is posting period? Posting period is a period within a fiscal year, such as a particular month, for which SAP transaction figures are updated. Every SAP transaction that is posted is assigned to a particular posting period. The transaction figures are then updated for this period.
By dividing a fiscal year into some posting periods, we can restrict that at a point of time we can only post to a certain periods, so we can do the closing process. After performing a closing procedure at the end of a certain period, we can then restrict that we can not post to the previous period, so (as usually required by management and law) the figure of our financial statement at the end of that period stays the same, does not change since then.
Usually we will open the current posting period (such as the current month) and will close all other periods. At the beginning of the next month, we need to close the previous posting period and open the current month as allowed posting period.
We open a period by entering a range into the posting period variant which includes this period. We can have as many periods open as we desired, depends on our accounting requirement. To make posting periods maintenance easier, SAP uses the variant concept. We can make a posting periods variant that can be used by several company codes, so we only have to open and close the posting periods once for all the company codes that use the same posting periods variant.
We can do this in SAP configuration at the following menu path on SPRO t-code: Accounting - Financial accounting - General ledger - Environment - Current settings - Open and close posting periods (for SAP 4.7.c version), or the following menu path: Financial Accounting (New) – Financial Accounting Global Setting (New) – Ledger – Fiscal Year and Posting Periods – Posting Periods – Open and Close Posting Periods (for SAP ECC 6.0 version).
The above image is © SAP AG 2010. All rights reserved
Because usually the procedure of financial closing takes some times to make sure all the financial information is accurate or to make adjustments, during that time we need some special periods (as defined in fiscal year variant) may also be opened. By doing so, we still can post to those special periods although the normal period has been closed and the next normal period has been opened. We can restrict that only certain group of users that can post to the special periods (usually the accountants).
We can do it because SAP gives two period ranges that can be opened at the same time and an authorization group that can be assigned to the first range. Only users that belong to this authorization group can post to the periods in the first range.
The users must have the authorization for the authorization object F_BKPF_BUP (accounting document: authorization for posting periods) with the same value in the field “authorization group” as in the posting period table. This object can be added to a user by SAP basis administrator in a company.
We can set that posting periods for different account types are handled differently. For example, we can allow postings on customer account (“D”) while postings on vendor accounts (“K”) / Asset accounts (“A”) / G/L account (“S”) are not allowed for a certain period.
The account type “+” is the minimum entry in the posting period variant. In the posting periods variant configuration, the account type “+” must be opened for all periods which are supposed to be opened for any other account type. SAP checks this first every accounting document. If the posting date of the document (at the header level) is out of the open posting periods for this “+” account type in the configuration then the document can’t be posted.
At the line item level of documents, SAP checks the account type of the posting key to verify that the period is open for the assigned account type.
The account range always contains G/L accounts. By entering certain reconciliation accounts behind sub ledger account types, these sub ledger accounts can be treated differently than accounts which have a different reconciliation account.
SAP determines the posting periods and fiscal year based on the posting date entered in the accounting documents.
You can download video training of How to Define Variants for Open Posting Periods, Assign Variants to Company Code, and Open and Close Posting Periods.
In the previous article we have defined fiscal year variant that determines the beginning and end of fiscal year; the number of "normal" and “special” posting periods; and the posting period length. For every company code, we must assign a fiscal year variant to it.
Now, we will explain about the posting period. What exactly is posting period? Posting period is a period within a fiscal year, such as a particular month, for which SAP transaction figures are updated. Every SAP transaction that is posted is assigned to a particular posting period. The transaction figures are then updated for this period.
By dividing a fiscal year into some posting periods, we can restrict that at a point of time we can only post to a certain periods, so we can do the closing process. After performing a closing procedure at the end of a certain period, we can then restrict that we can not post to the previous period, so (as usually required by management and law) the figure of our financial statement at the end of that period stays the same, does not change since then.
Usually we will open the current posting period (such as the current month) and will close all other periods. At the beginning of the next month, we need to close the previous posting period and open the current month as allowed posting period.
We open a period by entering a range into the posting period variant which includes this period. We can have as many periods open as we desired, depends on our accounting requirement. To make posting periods maintenance easier, SAP uses the variant concept. We can make a posting periods variant that can be used by several company codes, so we only have to open and close the posting periods once for all the company codes that use the same posting periods variant.
We can do this in SAP configuration at the following menu path on SPRO t-code: Accounting - Financial accounting - General ledger - Environment - Current settings - Open and close posting periods (for SAP 4.7.c version), or the following menu path: Financial Accounting (New) – Financial Accounting Global Setting (New) – Ledger – Fiscal Year and Posting Periods – Posting Periods – Open and Close Posting Periods (for SAP ECC 6.0 version).
The above image is © SAP AG 2010. All rights reserved
Because usually the procedure of financial closing takes some times to make sure all the financial information is accurate or to make adjustments, during that time we need some special periods (as defined in fiscal year variant) may also be opened. By doing so, we still can post to those special periods although the normal period has been closed and the next normal period has been opened. We can restrict that only certain group of users that can post to the special periods (usually the accountants).
We can do it because SAP gives two period ranges that can be opened at the same time and an authorization group that can be assigned to the first range. Only users that belong to this authorization group can post to the periods in the first range.
The users must have the authorization for the authorization object F_BKPF_BUP (accounting document: authorization for posting periods) with the same value in the field “authorization group” as in the posting period table. This object can be added to a user by SAP basis administrator in a company.
We can set that posting periods for different account types are handled differently. For example, we can allow postings on customer account (“D”) while postings on vendor accounts (“K”) / Asset accounts (“A”) / G/L account (“S”) are not allowed for a certain period.
The account type “+” is the minimum entry in the posting period variant. In the posting periods variant configuration, the account type “+” must be opened for all periods which are supposed to be opened for any other account type. SAP checks this first every accounting document. If the posting date of the document (at the header level) is out of the open posting periods for this “+” account type in the configuration then the document can’t be posted.
At the line item level of documents, SAP checks the account type of the posting key to verify that the period is open for the assigned account type.
The account range always contains G/L accounts. By entering certain reconciliation accounts behind sub ledger account types, these sub ledger accounts can be treated differently than accounts which have a different reconciliation account.
SAP determines the posting periods and fiscal year based on the posting date entered in the accounting documents.
You can download video training of How to Define Variants for Open Posting Periods, Assign Variants to Company Code, and Open and Close Posting Periods.
sap
SAP Enterprise Structure - A Case Study (part 10): Assign Plant to Company Code
This is the part 10 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Assign Plant to Company Code
For the business scenario we've explained before on part 1, we will assign:
A001 and A002 plant to ABCD company code
E001 plant to EFGH company code.
We assign plant to company code with OX18 t-code or from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Assignment - Logistics-General - Assign plant to company code.
.. Read More ..
Posted by Rizki at 13.4.11 1 comments
Labels: Enterprise-Structure
8.3.11
SAP Enterprise Structure - A Case Study (part 9): Define Division
This is the part 9 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Division
For the business scenario we will define two divisions:
A1 for starter pack product.
A2 for handset product.
We define division from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Logistics - General - Define, copy, delete, check division.
.. Read More ..
Posted by Rizki at 8.3.11 4 comments
Labels: Enterprise-Structure
14.2.11
SAP Enterprise Structure - A Case Study (part 8): Define Valuation Level
This is the part 8 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Valuation Level
We define valuation level with OX14 t-code or form the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Logistics - General - Define Valuation Level.
If we’ve never defined this before, the “Valuation Level” screen will be editable, but in this example it is not editable because it has been defined before. Defining the valuation level in Configuring is a fundamental setting, and is very difficult to reverse.
In the next article, I will explain about how to Define Division.
Notes:
You can read the full contents of the SAP enterprise structure - a case study as soon as you buy the e-book at: SAP Study Materials Store
.. Read More ..
Posted by Rizki at 14.2.11 0 comments
Labels: Enterprise-Structure
4.1.11
SAP Enterprise Structure - A Case Study (part 7): Define Plant
This is the part 7 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Plant
For the business scenario, we will create the following plants:
A001 for the west region of the ABCD company
A002 for the east region of the ABCD company
E001 for the office and warehouse of the EFGH company
There are two options to create company code:
Copy from other plant (or from SAP standard plant)
Create from the scratch
The advantage of copying from existing plant is SAP will also copy the existing plant-specific parameters, such as Consumption-Based Planning plant parameters, which include purchasing processing time, MRP Controller, etc. Then we can change certain data in the relevant application if necessary. This is much less time-consuming than creating a new plant.
But in this book we will create plant from the scratch so we have to define other parameters need in other relevant configuration process manually.
.. Read More ..
Posted by Rizki at 4.1.11 0 comments
Labels: Enterprise-Structure
15.11.10
SAP Enterprise Structure - A Case Study (part 6): Enterprise Structure concept in Logistics
This is the part 6 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Logistics
Plant
A plant is the place of production, or branch of a company, or simply a collection of several locations of material stocks in close physical proximity.
A plant is represented by a client-unique 4-digit alpha-numeric.
A plant is assigned to one company code.
One company code can have more than one plant.
SAP recommends that to get complete functionality of the SAP ERP system, the country of plant is the same with the country of the company code. We should create a company code for each country where the plant is located.
Plant is used in Material Management (MM), Production Planning (PP), Sales and Distribution (SD), and Plant Maintenance (PM) module.
Division
Division is a way to group materials or services. A wide range of materials or services can be divided into divisions.
Division is a field in the material master data (it can be input/edited on “Basic Data 1” view by MM01/MM02 t-code). That’s why a certain material can be assigned to one division only. Usually, for sales material, we set the division field as a mandatory field in the material master data. A certain material can also not be assigned to any division, for example a non-sales material that we don’t need to categorized into a specific division.
In Sales and Distribution module, division combined with other organization units (sales organization and distribution channel) will define the sales area. We can have sales area specific master data, such as material, customer, and pricing master data.
Division is used in determining business area from logistics transaction in MM and SD module. We will explain this on Assign Business Area to Plant/Valuation Area and Division section.
Valuation Level
Valuation level is the organizational level at which material is valuated. The value of valuated materials in SAP ERP is recorded in company code’s General Ledger account, usually under the inventory account.
In a client, there are two possible organizational level at which material is valuated:
Plant.
When stock is valuated at plant level, we can valuate a certain material in different plants at different prices. Valuation must be at this level in the following cases:
If we want to use the application component Production Planning (PP) or Costing
If our system is a SAP Retail system
Company Code.
When stock is valuated at company code level, the valuation price of a certain material is the same in all of a company's plants (that is, in a company code).
SAP recommends that we set material valuation at Plant level. Defining the valuation level in Configuring is a fundamental setting, and is very difficult to reverse.
.. Read More ..
Posted by Rizki at 15.11.10 1 comments
Labels: Enterprise-Structure
20.9.10
SAP Enterprise Structure - A Case Study (part 5): Assign Company Code to Company and Define Business Area
This is the part 5 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Assign Company Code to Company
After creating company and company codes, we need to assign the company codes to the company.
For our business scenario, we need to assign ABCD and EFGH company codes to ABCD company.
We can do it from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Assignment - Financial Accounting - Assign Company Code to Company.
.. Read More ..
Posted by Rizki at 20.9.10 1 comments
Labels: Enterprise-Structure
6.9.10
SAP Enterprise Structure - A Case Study (part 4): Define Company Code
This is the part 4 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Define Company Code
There are two options to create company code:
Copy from other company code (or from SAP standard company code)
Create from the scratch
SAP recommends that we copy a company code from an existing company code. The advantage is SAP will also copy the existing company code-specific parameters. Then we can change certain data in the relevant application if necessary. This is much less time-consuming than creating a new company code.
But in this book we will create company code from the scratch so we have to define other parameters need in other relevant configuration process manually.
For our business scenario, we need to define two company codes:
ABCD for ABCD Telecommunication company
EFGH for EFGH Telecommunication company
The information that we need to maintain the company are:
Company code
Name
Address, including country
Language key
Local currency
We create company code from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Financial Accounting - Edit, Copy, Delete, Check Company Code.
.. Read More ..
Posted by Rizki at 6.9.10 3 comments
Labels: Enterprise-Structure
23.8.10
SAP Enterprise Structure - A Case Study (Part 3): Define Company
This is the part 3 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Define Company
All company codes for a company must work with the same operational chart of accounts and fiscal year. The currencies used can be different.
The information that we need to maintain the company are:
Company ID
Name
Address, including country
Language key
Local currency
For our scenario, we will create one company (ABCD). We can create company from the following menu path of SPRO t-code:
IMG - Enterprise Structure - Definition - Financial Accounting - Define Company
.. Read More ..
Posted by Rizki at 23.8.10 1 comments
Labels: Enterprise-Structure
2.8.10
SAP Enterprise Structure - A Case Study (Part 2): Enterprise Structure Concept in FICO
This is the part 2 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Company Code
A Company Code is an organizational unit that represents an independent and legal accounting entity, for example, a company within a corporate group. Financial reports such as Balance sheets and Profit and Loss statements, required by law, are created at company code level.
In SAP, a company code is represented by a unique 4-digit alpha-numeric for a specific client. It is the central organizational element of Financial Accounting. At least there is one company code in a client. We can set up several company codes in one client in order to manage various separate legal entities simultaneously, each with their own balanced set of financial books.
With SAP FI module, we can generate the financial reports of a company code. A company code's financial reports can be used for external purpose, such as for external auditors, shareholders/stock exchange commission, tax office, etc.
.. Read More ..
Posted by Rizki at 2.8.10 1 comments
Labels: Enterprise-Structure
16.7.10
SAP Enterprise Structure - A Case Study (part 1)
This post is the first one of a series of articles that I am planning to write about SAP Enterprise Structure in the Material Management (MM) module's point of view. Due to its integration with other modules, I will also explain about some Enterprise Structure organizational units in Financial Accounting (FI) and Sales & Distribution (SD) modules.
Actually, I have published this series of posts as an e-book that is sold at SAP Study Materials Store. From now on, I am planning to write the e-book contents on this blog so you can read them for free. But I will write them in a series of post on this blog (could be 20 posts). If you haven't registered to our feed, you can do it now, so you'll be notified every time I post the new article on this blog:
In a reader
or, please enter your email address:
Alternatively, you can read the full contents as soon as you buy the e-book at:
SAP Study Materials Store, or
Amazon Kindle Store
Case Study Business Scenario
ABCD is a telecommunication company. It sells intangible telecommunication services, such as voices, sms, and data usage to the end-customers. The services can be consumed by the end-customers through the handset and starter pack (RUIM/sim card) inserted in it. The ABCD company has two branches: west region (which also the Head Office/HO) and east region.
.. Read More ..
Posted by Rizki at 16.7.10 6 comments
Labels: Enterprise-Structure
17.5.10
SAP Enterprise Structure - Purchasing Organization Concept
Purchasing Organization is an organizational unit in Purchasing of MM module.
Purchasing Organization is an organization unit that has responsibility to company’s purchasing activities, such as create Request For Quotations (RFQ), Contract, Purchase Order (PO), etc. aIt negotiates purchasing conditions (price, discount, term of payment, etc) with vendors. A Purchasing Organization is represented by a client-unique 4-digit alpha-numeric.
A purchasing organization must be assigned to one (in the case of plant-specific purchasing) or more plants.
One plant can have one or more Purchasing Organizations.
A purchasing organization can be assigned to one company code (in the case of company-specific purchasing).
A purchasing organization can’t be assigned to more than one company code. If we want the purchasing organization serves more than one company code, we must not assign the purchasing organization to any company code. But, we assign the purchasing organization to plants that it’s responsible for. Since each plant is assigned to a company code, SAP system will determine the company code from the plant. Since the company code is on the header level of the purchasing documents and the plant is on item level, we need to input the company code for each purchasing document.
A company code can have one or more purchasing organizations.
.. Read More ..
Posted by Rizki at 17.5.10 0 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
5.4.10
E-Book: SAP Enterprise Structure Concept and Configuration Guide
E-book: SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) Concept and Configuration Guide
SAP enterprise structure is organizational structure that represents an enterprise in SAP R/3 system. It consists of some organizational units which, for legal reasons or for other specific business-related reasons or purposes, are grouped together. Organizational units include legal company entities, sales offices, profit centers, etc. Organizational units handle specific business functions.
Organizational units may be assigned to a single module (such as a sales organization assigned to Sales and Distribution (SD) module, or to several modules (such as a plant assigned to Materials Management (MM) and Production Planning (PP) module).
SAP ERP system can represent a complex enterprise structure. Its flexibility can integrate the structure of an enterprise by linking its organizational unit. Enterprise structure design is a fundamental process in a SAP implementation project. The design is mainly determined by the business scenarios performed in an enterprise. Once the design is determined, it will affect many things such as how to perform a transaction and generate reports on SAP system. Although it’s possible, it requires great effort to change the enterprise structure. So , we must ensure that the enterprise structure designed in the SAP implementation project can accommodate all business scenarios and enterprise’s requirements for current and future situation.
The SAP Enterprise Structure is a fundamental setting and needs a comprehensive understanding of the business processes and their integration. We have to work with other departments and SAP modules, such as Accounting department (FI module), and Sales department (Sales and Distribution module).
I have written a pdf e-book that explains in details about the SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) Concept and Configuration Guide. Just like other articles on my SAP Study Materials blog, I wrote the e-book in a simple-to-understand way, so you can learn it easily. You don't need to have extensive SAP knowledge and experience to be able to configure the SAP Enterprise Structure, as the e-book start explaining each step with the basic concept behind it. After understanding the concept, the e-book will show the step-by-step configuration with the screen shots.
You can buy the e-book for USD 25.00 19.95 at: Buy Now
.. Read More ..
Posted by Rizki at 5.4.10 0 comments
Labels: Enterprise-Structure, SAP-Books
7.9.09
SAP SD Enterprise Structure & Master Data
SAP SD Enterprise Structure
Enterprise structure or Organizational structure in SAP is a structure of SAP organizational units that reflects the structure of the business in the real world. There are various SAP organizational units that can be mapped to business structure based on the real world business requirements such as: Client, Company Code, Plant, Storage Location, Sales Organization, Distribution Channel, Division, Sales Office, Sales Group, Sales Person, Shipping Point, Loading Point, etc.
We must set the enterprise structure correctly in the first place. The change of it usually requires a great effort and very time consuming. To set it up correctly we must have a comprehensive knowledge about the business processes and how to map it to SAP configuration.
A specific organizational unit is defined by a specific function or module in SAP. Company code is defined by FI module. Plant is defined by Logistics function. Storage Location and Purchasing Organization are defined by MM module.
In SD module we have to define Sales Organization, Distribution Channel, and Division. We have an option whether to use Sales Office, Sales Group, and Sales Person or not.
.. Read More ..
Posted by Rizki at 7.9.09 2 comments
Labels: Enterprise-Structure, SD
10.1.08
MM Configuration: Assign Purchasing Organization to Company Code and Plants
Step by step SAP Material Management (MM) Configuration: Assign Purchasing Organization to Company Code and Plant
Purchasing Organization is an organization unit that has responsibility to company’s purchasing requirements. It negotiates purchasing conditions (price, discount, and other things) with vendors.
We can assign Purchasing Organization to a company code if we want a Company-specific purchasing. The purchasing organization may procure only for this company code. Then, we assign only plants of the company code concerned to the purchasing organization.
You can read our previous post to understand more about Purchasing Organization in SAP Enterprise Structure.
In this example we will assign “GC00” Purchasing Organization to “GC00” company code and to “GC01” plant. We can do this in a SAP R/3 client with T-code: SPRO. SAP step-by-step Screen shots of How to assign a Purchasing Organization to company code and plants are:
.. Read More ..
Posted by Rizki at 10.1.08 1 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
30.12.07
MM Configuration: Maintain Purchasing Organization
Step by step SAP Material Management (MM) Configuration: Maintain Purchasing Organization
Purchasing Organization is an organization unit that has responsibility to company’s purchasing requirements. It negotiates purchasing conditions (price, discount, and other things) with vendors. You can read our previous post to understand more about Purchasing Organization in SAP Enterprise Structure.
We can define Purchasing Organization in a SAP R/3 client with T-code: SPRO.
SAP step-by-step Screen shots of How to maintain a Purchasing Organization are:
.. Read More ..
Posted by Rizki at 30.12.07 0 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
MM Configuration: Maintain Storage Location
Step by step SAP Material Management (MM) Configuration: Maintain Storage Location
A Storage Location is a storage area comprising warehouses in close proximity.
A Storage Location is represented by a plant-unique 4-digit alpha-numeric.
Material stocks can be differentiated, on a quantity basis, within one plant according to storage location.
Storage locations are always created for a plant.
It is possible to store material data specific to a storage location, such as storage bin.
Physical inventories are carried out at storage location level.
.. Read More ..
This is the part 10 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Assign Plant to Company Code
For the business scenario we've explained before on part 1, we will assign:
A001 and A002 plant to ABCD company code
E001 plant to EFGH company code.
We assign plant to company code with OX18 t-code or from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Assignment - Logistics-General - Assign plant to company code.
.. Read More ..
Posted by Rizki at 13.4.11 1 comments
Labels: Enterprise-Structure
8.3.11
SAP Enterprise Structure - A Case Study (part 9): Define Division
This is the part 9 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Division
For the business scenario we will define two divisions:
A1 for starter pack product.
A2 for handset product.
We define division from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Logistics - General - Define, copy, delete, check division.
.. Read More ..
Posted by Rizki at 8.3.11 4 comments
Labels: Enterprise-Structure
14.2.11
SAP Enterprise Structure - A Case Study (part 8): Define Valuation Level
This is the part 8 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Valuation Level
We define valuation level with OX14 t-code or form the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Logistics - General - Define Valuation Level.
If we’ve never defined this before, the “Valuation Level” screen will be editable, but in this example it is not editable because it has been defined before. Defining the valuation level in Configuring is a fundamental setting, and is very difficult to reverse.
In the next article, I will explain about how to Define Division.
Notes:
You can read the full contents of the SAP enterprise structure - a case study as soon as you buy the e-book at: SAP Study Materials Store
.. Read More ..
Posted by Rizki at 14.2.11 0 comments
Labels: Enterprise-Structure
4.1.11
SAP Enterprise Structure - A Case Study (part 7): Define Plant
This is the part 7 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Define Plant
For the business scenario, we will create the following plants:
A001 for the west region of the ABCD company
A002 for the east region of the ABCD company
E001 for the office and warehouse of the EFGH company
There are two options to create company code:
Copy from other plant (or from SAP standard plant)
Create from the scratch
The advantage of copying from existing plant is SAP will also copy the existing plant-specific parameters, such as Consumption-Based Planning plant parameters, which include purchasing processing time, MRP Controller, etc. Then we can change certain data in the relevant application if necessary. This is much less time-consuming than creating a new plant.
But in this book we will create plant from the scratch so we have to define other parameters need in other relevant configuration process manually.
.. Read More ..
Posted by Rizki at 4.1.11 0 comments
Labels: Enterprise-Structure
15.11.10
SAP Enterprise Structure - A Case Study (part 6): Enterprise Structure concept in Logistics
This is the part 6 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Logistics
Plant
A plant is the place of production, or branch of a company, or simply a collection of several locations of material stocks in close physical proximity.
A plant is represented by a client-unique 4-digit alpha-numeric.
A plant is assigned to one company code.
One company code can have more than one plant.
SAP recommends that to get complete functionality of the SAP ERP system, the country of plant is the same with the country of the company code. We should create a company code for each country where the plant is located.
Plant is used in Material Management (MM), Production Planning (PP), Sales and Distribution (SD), and Plant Maintenance (PM) module.
Division
Division is a way to group materials or services. A wide range of materials or services can be divided into divisions.
Division is a field in the material master data (it can be input/edited on “Basic Data 1” view by MM01/MM02 t-code). That’s why a certain material can be assigned to one division only. Usually, for sales material, we set the division field as a mandatory field in the material master data. A certain material can also not be assigned to any division, for example a non-sales material that we don’t need to categorized into a specific division.
In Sales and Distribution module, division combined with other organization units (sales organization and distribution channel) will define the sales area. We can have sales area specific master data, such as material, customer, and pricing master data.
Division is used in determining business area from logistics transaction in MM and SD module. We will explain this on Assign Business Area to Plant/Valuation Area and Division section.
Valuation Level
Valuation level is the organizational level at which material is valuated. The value of valuated materials in SAP ERP is recorded in company code’s General Ledger account, usually under the inventory account.
In a client, there are two possible organizational level at which material is valuated:
Plant.
When stock is valuated at plant level, we can valuate a certain material in different plants at different prices. Valuation must be at this level in the following cases:
If we want to use the application component Production Planning (PP) or Costing
If our system is a SAP Retail system
Company Code.
When stock is valuated at company code level, the valuation price of a certain material is the same in all of a company's plants (that is, in a company code).
SAP recommends that we set material valuation at Plant level. Defining the valuation level in Configuring is a fundamental setting, and is very difficult to reverse.
.. Read More ..
Posted by Rizki at 15.11.10 1 comments
Labels: Enterprise-Structure
20.9.10
SAP Enterprise Structure - A Case Study (part 5): Assign Company Code to Company and Define Business Area
This is the part 5 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Assign Company Code to Company
After creating company and company codes, we need to assign the company codes to the company.
For our business scenario, we need to assign ABCD and EFGH company codes to ABCD company.
We can do it from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Assignment - Financial Accounting - Assign Company Code to Company.
.. Read More ..
Posted by Rizki at 20.9.10 1 comments
Labels: Enterprise-Structure
6.9.10
SAP Enterprise Structure - A Case Study (part 4): Define Company Code
This is the part 4 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Define Company Code
There are two options to create company code:
Copy from other company code (or from SAP standard company code)
Create from the scratch
SAP recommends that we copy a company code from an existing company code. The advantage is SAP will also copy the existing company code-specific parameters. Then we can change certain data in the relevant application if necessary. This is much less time-consuming than creating a new company code.
But in this book we will create company code from the scratch so we have to define other parameters need in other relevant configuration process manually.
For our business scenario, we need to define two company codes:
ABCD for ABCD Telecommunication company
EFGH for EFGH Telecommunication company
The information that we need to maintain the company are:
Company code
Name
Address, including country
Language key
Local currency
We create company code from the following menu path of “SPRO” t-code: IMG - Enterprise Structure - Definition - Financial Accounting - Edit, Copy, Delete, Check Company Code.
.. Read More ..
Posted by Rizki at 6.9.10 3 comments
Labels: Enterprise-Structure
23.8.10
SAP Enterprise Structure - A Case Study (Part 3): Define Company
This is the part 3 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Define Company
All company codes for a company must work with the same operational chart of accounts and fiscal year. The currencies used can be different.
The information that we need to maintain the company are:
Company ID
Name
Address, including country
Language key
Local currency
For our scenario, we will create one company (ABCD). We can create company from the following menu path of SPRO t-code:
IMG - Enterprise Structure - Definition - Financial Accounting - Define Company
.. Read More ..
Posted by Rizki at 23.8.10 1 comments
Labels: Enterprise-Structure
2.8.10
SAP Enterprise Structure - A Case Study (Part 2): Enterprise Structure Concept in FICO
This is the part 2 of the series of articles about SAP Enterprise Structure - A Case Study. Read part 1 here.
Enterprise Structure concept in Financial Accounting
Company Code
A Company Code is an organizational unit that represents an independent and legal accounting entity, for example, a company within a corporate group. Financial reports such as Balance sheets and Profit and Loss statements, required by law, are created at company code level.
In SAP, a company code is represented by a unique 4-digit alpha-numeric for a specific client. It is the central organizational element of Financial Accounting. At least there is one company code in a client. We can set up several company codes in one client in order to manage various separate legal entities simultaneously, each with their own balanced set of financial books.
With SAP FI module, we can generate the financial reports of a company code. A company code's financial reports can be used for external purpose, such as for external auditors, shareholders/stock exchange commission, tax office, etc.
.. Read More ..
Posted by Rizki at 2.8.10 1 comments
Labels: Enterprise-Structure
16.7.10
SAP Enterprise Structure - A Case Study (part 1)
This post is the first one of a series of articles that I am planning to write about SAP Enterprise Structure in the Material Management (MM) module's point of view. Due to its integration with other modules, I will also explain about some Enterprise Structure organizational units in Financial Accounting (FI) and Sales & Distribution (SD) modules.
Actually, I have published this series of posts as an e-book that is sold at SAP Study Materials Store. From now on, I am planning to write the e-book contents on this blog so you can read them for free. But I will write them in a series of post on this blog (could be 20 posts). If you haven't registered to our feed, you can do it now, so you'll be notified every time I post the new article on this blog:
In a reader
or, please enter your email address:
Alternatively, you can read the full contents as soon as you buy the e-book at:
SAP Study Materials Store, or
Amazon Kindle Store
Case Study Business Scenario
ABCD is a telecommunication company. It sells intangible telecommunication services, such as voices, sms, and data usage to the end-customers. The services can be consumed by the end-customers through the handset and starter pack (RUIM/sim card) inserted in it. The ABCD company has two branches: west region (which also the Head Office/HO) and east region.
.. Read More ..
Posted by Rizki at 16.7.10 6 comments
Labels: Enterprise-Structure
17.5.10
SAP Enterprise Structure - Purchasing Organization Concept
Purchasing Organization is an organizational unit in Purchasing of MM module.
Purchasing Organization is an organization unit that has responsibility to company’s purchasing activities, such as create Request For Quotations (RFQ), Contract, Purchase Order (PO), etc. aIt negotiates purchasing conditions (price, discount, term of payment, etc) with vendors. A Purchasing Organization is represented by a client-unique 4-digit alpha-numeric.
A purchasing organization must be assigned to one (in the case of plant-specific purchasing) or more plants.
One plant can have one or more Purchasing Organizations.
A purchasing organization can be assigned to one company code (in the case of company-specific purchasing).
A purchasing organization can’t be assigned to more than one company code. If we want the purchasing organization serves more than one company code, we must not assign the purchasing organization to any company code. But, we assign the purchasing organization to plants that it’s responsible for. Since each plant is assigned to a company code, SAP system will determine the company code from the plant. Since the company code is on the header level of the purchasing documents and the plant is on item level, we need to input the company code for each purchasing document.
A company code can have one or more purchasing organizations.
.. Read More ..
Posted by Rizki at 17.5.10 0 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
5.4.10
E-Book: SAP Enterprise Structure Concept and Configuration Guide
E-book: SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) Concept and Configuration Guide
SAP enterprise structure is organizational structure that represents an enterprise in SAP R/3 system. It consists of some organizational units which, for legal reasons or for other specific business-related reasons or purposes, are grouped together. Organizational units include legal company entities, sales offices, profit centers, etc. Organizational units handle specific business functions.
Organizational units may be assigned to a single module (such as a sales organization assigned to Sales and Distribution (SD) module, or to several modules (such as a plant assigned to Materials Management (MM) and Production Planning (PP) module).
SAP ERP system can represent a complex enterprise structure. Its flexibility can integrate the structure of an enterprise by linking its organizational unit. Enterprise structure design is a fundamental process in a SAP implementation project. The design is mainly determined by the business scenarios performed in an enterprise. Once the design is determined, it will affect many things such as how to perform a transaction and generate reports on SAP system. Although it’s possible, it requires great effort to change the enterprise structure. So , we must ensure that the enterprise structure designed in the SAP implementation project can accommodate all business scenarios and enterprise’s requirements for current and future situation.
The SAP Enterprise Structure is a fundamental setting and needs a comprehensive understanding of the business processes and their integration. We have to work with other departments and SAP modules, such as Accounting department (FI module), and Sales department (Sales and Distribution module).
I have written a pdf e-book that explains in details about the SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) Concept and Configuration Guide. Just like other articles on my SAP Study Materials blog, I wrote the e-book in a simple-to-understand way, so you can learn it easily. You don't need to have extensive SAP knowledge and experience to be able to configure the SAP Enterprise Structure, as the e-book start explaining each step with the basic concept behind it. After understanding the concept, the e-book will show the step-by-step configuration with the screen shots.
You can buy the e-book for USD 25.00 19.95 at: Buy Now
.. Read More ..
Posted by Rizki at 5.4.10 0 comments
Labels: Enterprise-Structure, SAP-Books
7.9.09
SAP SD Enterprise Structure & Master Data
SAP SD Enterprise Structure
Enterprise structure or Organizational structure in SAP is a structure of SAP organizational units that reflects the structure of the business in the real world. There are various SAP organizational units that can be mapped to business structure based on the real world business requirements such as: Client, Company Code, Plant, Storage Location, Sales Organization, Distribution Channel, Division, Sales Office, Sales Group, Sales Person, Shipping Point, Loading Point, etc.
We must set the enterprise structure correctly in the first place. The change of it usually requires a great effort and very time consuming. To set it up correctly we must have a comprehensive knowledge about the business processes and how to map it to SAP configuration.
A specific organizational unit is defined by a specific function or module in SAP. Company code is defined by FI module. Plant is defined by Logistics function. Storage Location and Purchasing Organization are defined by MM module.
In SD module we have to define Sales Organization, Distribution Channel, and Division. We have an option whether to use Sales Office, Sales Group, and Sales Person or not.
.. Read More ..
Posted by Rizki at 7.9.09 2 comments
Labels: Enterprise-Structure, SD
10.1.08
MM Configuration: Assign Purchasing Organization to Company Code and Plants
Step by step SAP Material Management (MM) Configuration: Assign Purchasing Organization to Company Code and Plant
Purchasing Organization is an organization unit that has responsibility to company’s purchasing requirements. It negotiates purchasing conditions (price, discount, and other things) with vendors.
We can assign Purchasing Organization to a company code if we want a Company-specific purchasing. The purchasing organization may procure only for this company code. Then, we assign only plants of the company code concerned to the purchasing organization.
You can read our previous post to understand more about Purchasing Organization in SAP Enterprise Structure.
In this example we will assign “GC00” Purchasing Organization to “GC00” company code and to “GC01” plant. We can do this in a SAP R/3 client with T-code: SPRO. SAP step-by-step Screen shots of How to assign a Purchasing Organization to company code and plants are:
.. Read More ..
Posted by Rizki at 10.1.08 1 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
30.12.07
MM Configuration: Maintain Purchasing Organization
Step by step SAP Material Management (MM) Configuration: Maintain Purchasing Organization
Purchasing Organization is an organization unit that has responsibility to company’s purchasing requirements. It negotiates purchasing conditions (price, discount, and other things) with vendors. You can read our previous post to understand more about Purchasing Organization in SAP Enterprise Structure.
We can define Purchasing Organization in a SAP R/3 client with T-code: SPRO.
SAP step-by-step Screen shots of How to maintain a Purchasing Organization are:
.. Read More ..
Posted by Rizki at 30.12.07 0 comments
Labels: Enterprise-Structure, MM, MM--Purchasing
MM Configuration: Maintain Storage Location
Step by step SAP Material Management (MM) Configuration: Maintain Storage Location
A Storage Location is a storage area comprising warehouses in close proximity.
A Storage Location is represented by a plant-unique 4-digit alpha-numeric.
Material stocks can be differentiated, on a quantity basis, within one plant according to storage location.
Storage locations are always created for a plant.
It is possible to store material data specific to a storage location, such as storage bin.
Physical inventories are carried out at storage location level.
.. Read More ..
Subscribe to:
Posts (Atom)