Free Sap Training



             


Saturday, January 31, 2009

Relational Database Management System in SAP

Basically SAP, an enterprise application is made up of programs together with the data used and formed by programs. The data are organized in a meaningful way within the database, making it easy for the programs to access and find the data necessary to do something useful like run a financial report or create a sales order. Both the programs as well as data exist in the same database in the case of an SAP component or products such as ECC. Normally each and every component has its own database a production system landscape composed of SAP ECC, SAP Business Warehouse (BW), and SAP Customer Relationship Management (CRM) consists of three production databases.

Database Structure:

Essentially database is an electronic filing system that houses a collection of information organized in such a way that allows a computer program to find preferred pieces of data in a rapid way. A database is composed of tables, columns (called fields), and rows (called records or data). The fundamental structure of a database is same as the Microsoft Excel spreadsheet wherein columns (fields) store row after row of records (data). The difference between a database and a spreadsheet is simply the databases that contain multiple tables are connected to one another through relationships.

Database structure is an alternative technical term that does not need to concern with you, but are important nonetheless. Structures are triggered and are very well defined in the ABAP/4 Data Dictionary and have only temporary data. The database plays a key role in each SAP system, as it houses all the data that are used by that SAP component or product specifically. Numerous brands of databases exist, making it easier for an IT shop to opt for a database vendor with which they are almost well-known. Moreover, it is imperative to note that not all database vendors and versions are supported by SAP. Rather it tends to stick with the market leaders, over the years adding and removing support for certain vendors.

Primary Key

Database tables in an Relational Database Management System (RDBMS) are obligatory to hold a unique field that distinguishes one particular record separately from others found in the database. This unique field is called a primary key and is composed of one or more fields that make each and every record in a database as a unique one.

Foreign Key

Use the primary key field in one table for linking it with another. The common link field in the other table is usually not the primary key in the other table: and is known as a foreign key.

Database Concepts:

The SAP system contains lots of types of constructs along with structures inside the R/3 Data Dictionary (DDIC). The majority of these constructs tend to be very technical.

Transparent Tables:

SAP uses another concept called transparent tables, which are SAP database tables that contain only data at runtime. When a table is activated in the ABAP/4 Data Dictionary, a transparent table is created automatically in the database. This transparent table encloses the same name as your database table contained in the ABAP/4 Dictionary. Each of its fields contains the same names as their database counterparts though the sequence of the fields might get varied. This unstable field sequence makes it possible to insert new fields into the table without having to convert it, all of which pays a way for more rapid access to data during runtime.

Ron Victor is a SEO copywriter for www.simplysap.com
He written many articles in various topics.For more information visit www.simplysap.com
Contact him at ron.seocopywriter@gmail.com

Labels: , , , , , , , ,

Tuesday, January 27, 2009

Risks to Your ERP SAP Implementation

Inadequate AS IS documentation

Consider that you are the implementation Project Manager for a consulting firm and you have a client who has selected an ERP(Enterprise Resource Planning) system. The project manager and the team started gathering requirements from end users through focus groups, workshops, sessions with SMEs, etc. After obtaining all the details from end users you can easily conclude that you have all the necessary information and requirements to successfully implement the to be software system erroneously. During UAT (Users Acceptance Testing) you can find out that the system does not meet all the end user’s expectations as well as the participants of UAT are unable to authorize your implemented solution previously.

Requirements not scrubbed

Instead of focusing on what the requirement should process, it should focus only on the function that the system will perform. Government organizations implementing an ERP (Enterprise Resource Planning) solution document requirement are maintained frequently in web of spreadsheets that makes it difficult to:

1. Track a requirement,

2. Modify the requirement while communicating the changes to the affected parties,

3. Assigning requirement ownership,

4. Create an RTM,

5. Manage the lifecycle of the requirement.

The ERP implementation partner is also tasked with interpreting the requirements from spreadsheets and it discerns how these requirements will be implemented during realization and verifies that the requirements have been met during testing process. Moreover, the implementation partner of ERP (Enterprise Resource Planning) for the sake of meeting deadlines rushes through the blueprint phase does not scour the requirement and makes blind attempt for executing the requirement even when the requirement is not feasible, necessary or consistent with the functionality of the ERP(Enterprise Resource Planning) application.

Vendor software problems

The process of testing or maintaining the SAP software will give you errors, and so the needed enhancements, or bugs within your software cannot be addressed with your existing project team and so these errors, bugs, and needed enhancements do not instigate from having customized or implemented SAP erroneously but are rather triggered due to a deficiency with the vendor software. Impact occurred to your business could be manifested in different manners such as client/end user dissatisfaction, inability to roll out specific planned system functionality, financial losses, and unstable system based upon the severity of the problem. These vendor software problems can also get unresolved for prolonged periods. Furthermore, lack of controls, participation from the SAP client as well as audit trails can cause the software vendor problems to erroneously become closed when in fact they were never resolved.

No Scope Verification

Controversial relationships between the client and implementation partner stem from the fact that the client feels that the implemented ERP(Enterprise Resource Planning) solution does not cater to their business needs depending on the documented scope, and the end users cannot perform all these tasks that were implemented within the legacy systems without difficulty. And when the client report defects, short comings and bugs against the ERP system were not a part of the scope or documented via a requirement and so the problem is compounded. When the ERP integration partner labels the end users reported defects and problems as enhancements mutually rather than problems with the implemented ERP solution the relationship between the implementation partner and the client takes revolve for the worse.

Ron Victor is a SEO copywriter for SAP Jobs Search, He written many articles in various topics. For more information visit SAP Articles, Contact him at ron.seocopywriter@gmail.com

Labels: , , , , , , , ,

Wednesday, January 14, 2009

SAP Business One Integration highlights

SAP B1 has multiple tools to enable integration with your legacy system, eCommerce, etc. In this small article we would like to give you highlights on SAP Business One SDK integrations. These integrations require Microsoft Visual Studio.net C# or VB programming skills. Typical SAP BO integration would move customer orders to SAP B1 Sale Orders

• Staging Table. You need to move your eCommerce transactions to staging table, preferably in MS SQL Server, where SAP BO is hosted. Use stored procedure, if required you can do heterogeneous queries to pull transactions from Oracle, IBM Lotus Notes Domino or another db platform

• SAP BO SDK Loop. You should open connection to SAP BO company via SDK. We will not give you code sample here, we expect intermediate SDK coding experience. When connection is established – you read your staging table and create Sales Orders one by one – or alternatively you create one Sales Order and add items one-by-one

• Flagging Imported Transactions. In staging table you should either delete imported transaction or flag them as being imported, your choice

• AR Invoice. We do not recommend you to add invoice in integration. The reason is simple – invoice is not stored in the batch – it should be posted – and we do not recommend you to review posted invoices – in order to reverse them you will need to enter credit memos, which will create a mess in your data entry

• Other Integrations. SAP Business One SDK allows you to create, modify and manipulate virtually all SAP B1 objects, in this article we showed you Sales Orders, you can also update or add customers, vendors, etc.

Please feel free to call us on SAP Business One integration scenarios: 1-866-528-0577, 1-630-961-5918, help@albaspectrum.com or skype: albaspectrum

Andrew Karasev, Alba Spectrum Group, serving SAP Business One customers in USA nationwide from Chicago and Houston, in Brazil from our call center in Sao Paulo. We also serve Microsoft Dynamics GP US nationwide and support all the types of customization, reporting, software development, integration, data conversion from our Manila software factory.

http://www.albaspectrum.com
http://www.enterlogix.com.br

Labels: , , , , ,