Best Practices ERP Certification

Hi all,
I recently found out about this new certification course call Best Practices ERP. It is of shorter duration and lower fee compared to a Solution Academy.
Does anyone have any information about this course and how useful it will be? Hope to hear from you soon! =)

Hi
It makes sense to have the HCM system in the same system as rest of the components because
1) We are able to make use of the tight integration between various components, most importantly Payroll - Finance.
2) We can manage without tiresome ALE/interface development and management.
3) lesser hardware cost (probably)
It makes sense to have HCM in different systems because
1) because of different sequence of HRSP/LCP compared to other systems, we can have a separate strategy for HRSP application independent of other components. We can save a lot of effort in regression testing as only HR needs to be tested after patch application.
2) IN many countries there are strict data protection laws, and having HR in a separate system ensures that people from other functions do not have access to HR data even accidentally as they will not have user ids in the HR system.
Hope this is enough to get you started.

Similar Messages

CRM Best Practices V1.2007 with ERP HR Integration, C01 and C05

Hi,
working on Best Practices CRM V.1.2007 I now should proceed with Building Block C01 (CRM Organizational Model).
I want to use the CRM System integrated with a new installed ERP System and HR Integration.
Therefore I have to use the Building Block C05 (CRM Organizational Model with HR Integration) instead of C01 (CRM Orgnizational Model)
My Question: Is it allowed to proceed with C05 by doing the work direct from the SAP GUI Menu; afterwards I could confirm the steps in the Solution Builder for C01?
Regards, Andreas

Hi Andreas,
Yes, you could do that. But be aware that the other building blocks for master and transaction data replication should not be started unless you are done with the org model BB C01.
Regards,
Padma

Best practice to integrate the external(ERP or Database etc) eCommerce data in to CQ

Hi Guys,
I am refering to GEOMetrixx-Outdoors project for building eCommerce fucntionality in our project.
Currently we are integrating with an ERP system to fetch the Product details.
Now I need to store all the Product data from ERP system in to our CRX under etc/commerce/products/<myproject> folder structure.
Do I need to create a csv file structure as explained in the geometrixx-outdoors project and place it exactly the way they have mentioned in the documentation? By doing this the csvimporter will import the data in to CRX and creates the Sling:folder and nt:unstructured nodes in to CRX?
Please guide me which is this best practice to integrate the external eCommerce data in to CQ system to build eCommerce projects?
Are there any other best practices ?
Your help in this regard is really appreciated.
Thanks

Hi Kresten,
Thanks for your reply.
I went through the eCommerce framework link which you sent.
Can you get me few of the steps to utilise eCommerce framework to pull all the product information in to our CRX repository and also how to synchronise between the ERP system and CRX data. Is that we have a scheduling mechanism to pull the data from our ERP system and synch it with CRX repository?
Thanks

List of activities for setting up ERP 6.0 with Best Practices

Based on my understand if i were to plan for setting up an ERP 6.0 Landscape with Best Practices (Full Scope) i would consider the execution of following activities:
Prepare EHP4 Landscape
Install ERP 6.0 on DEV
Upgrade DEV to EHP4 SP06
Install SAP Best Practices v1.604
Activate Full Scope of Best Practices on DEV
Prepare QA (System Copy - DEV with BP Activated)
Prepare PRD (System Copy - DEV with BP Activated)
Register Landscape in Solution Manager
Customization on EHP4
Customize Best Practices Scenarios on DEV
Transport Changes to QA
Test Changes on QA
Transport Changes to PRD
Upgrade to EHP5
Upgrade DEV, QA and PRD to EHP5
Install HCM Localization on DEV, QA and PRD
Customization on EHP5
Customize HCM Best Practices Scenarios on DEV
Transport Changes to QA
Test Changes on QA
Transport Changes to PRD
Please advise if there is anything missing or incorrect.
Thanks.

Hi,
I'm on a project with similar requirements. I follow this order in steps that you describe:
Install ERP 6.0 on DEV
Upgrade DEV to EHP4 SP06
Install SAP Best Practices v1.604 on DEV
Install QA
Install SAP Best Practices v1.604 on QUA
Install PRD
Install SAP Best Practices v1.604 on PRD
Activate Full Scope of Best Practices on DEV
Register Landscape in Solution Manager
Upgrade DEV, QA and PRD to EHP5
Install HCM Localization on DEV, QA and PRD
Customize Best Practices Scenarios on DEV
Transport Changes to QA
Test Changes on QA
Transport Changes to PRD
I hope that this will be useful for you
Best regards.
Alejandro Cepeda.

Install The ERP SAP Best Practices Baseline Package (VE)

Hello
We would like to install The ERP SAP Best Practices Baseline Package (VE)
And reviewing the Quick Guide to Installing the SAP Best Practices Baseline Package (VE), included in the SAP NOTE 1171816, in the list of components installed we need SAP ERP 6.0 with EhP3 with support package stack 1, but we received the installation disc of the Ehp4, and this version is not supported for the Baseline Package (VE).
We are unable to find the installation the disc, or the media list for this solution (SAP ECC 6.0 EhP3).
Can somebody tell me where can i find this?
The information in the service.sap.com/instguides is about installing EhP4.
We are using Windows 2008 EE with MS-SQL 2005.
Thanks for your Help

Hello Sunny,
I hava setup MOPZ, and uploaded the correct packages to the SAINT transaction, but it gives me a warning, i need to include the following files to my upgrade queue:
EA-APPL, 603       SAPK-603DHINEAAPPL   (SP Level: 0001)
FINBASIS, 603      SAPK-60301INFINBASIS (SP Level: 0001)
EA-PS, 603           SAPK-603DHINEAPS     (SP Level: 0001)
SEM-BW, 603        SAPK-60301INSEMBW    (SP Level: 0001)
I downloaded the packagesfrom SWDC but still is missing EA-PS, 603 SAPK-603DHINEAPS the file i downloaded was CSN0120061532_0028760.PAT
In the SAP Note 1083533
"If you receive the warning stating that additional Support
Packages (level 0001) must be included in the installation of
Enhancement Package 3, check the Support Package level of the
relevant component. You can ignore the warning in the following
cases:
All components (Release 600) except EA-HR 600: Support Package
level 0011
EA-HR 600: Support Package level 0026
- Note the following: In the case of a higher Support Package
level (at least Support Package level 0012 or Support Package
level 0026 for EA-HR), you must NOT ignore this warning."
My SP level is 11 for all components and EA-HR is lvl 22, should i ignore this?
Kind Regards

Best Practice for setting systems up in SMSY

Good afternoon - I want to cleanup our SMSY information and I am looking for some best practice advice on this. We started with an ERP 6.0 dual-stack system. So I created a logical component Z_ECC under "SAP ERP" --> "SAP ECC Server" and I assigned all of my various instances (Dev, QA, Train, Prod) to this logical component. We then applied Enhancement Package 4 to these systems. I see under logical components there is an entry for "SAP ERP ENHANCE PACKAGE". Now that we are on EhP4, should I create a different logical component for my ERP 6.0 EhP4 systems? I see in logical components under "SAP ERP ENHANCE PACKAGE" there are entries for the different products that can be updated to EhP4, such as "ABAP Technology for ERP EHP4", "Central Applications", ... "Utilities/Waste&Recycl./Telco". If I am supposed to change the logical component to something based on EhP4, which should I choose?
The reason that this is important is that when I go to Maintenance Optimizer, I need to ensure that my version information is correct so that I am presented with all of the available patches for the parts that I have installed.
My Solution Manager system is 7.01 SPS 26. The ERP systems are ECC 6.0 EhP4 SPS 7.
Any assistance is appreciated!
Regards,
Blair Towe

Hello Blair,
In this case you have to assign products EHP 4 for ERP 6 and SAP ERP 6 for your system in SMSY.
You will then have 2 entries in SMSY, one under each product, the main instance for EHP 4 for ERP 6 must be central applications and the one for SAP ERP 6 is SAP ECC SERVER.
This way your system should be correctly configured to use the MOPZ.
Unfortunately I'm not aware of a guide explaining these details.
Some times the System Landscape guide at service.sap.com/diagnostics can be very useful. See also note 987835.
Hope it can help.
Regards,
Daniel.
Edited by: Daniel Nicol on May 24, 2011 10:36 PM

Basic Strategy / Best Practices for System Monitoring with Solution Manager

I am very new to SAP and the Basis group at my company. I will be working on a project to identify the best practices of System and Service level monitoring using Solution Manager. I have read a good amount about SAP Solution Manager and the concept of monitoring but need to begin mapping out a monitoring strategy.
We currently utilize the RZ20 transaction and basic CCMS monitors such as watching for update errors, availability, short dumps, etc.. What else should be monitored in order to proactively find possible issues. Are there any best practices you all have found when implimenting Monitoring for new solutions added to the SAP landscape.... what are common things we would want to monitor over say ERP, CRM, SRM, etc?
Thanks in advance for any comments or suggestions!

Hi Mike,
Did you try the following link ?
If not, it may be useful to some extent:
http://service.sap.com/bestpractices
---> Cross-Industry Packages ---> Best Practices for Solution Management
You have quite a few documents there - those on BPM may also cover Solution Monitoring aspects.
Best regards,
Srini
Edited by: Srinivasan Radhakrishnan on Jul 7, 2008 7:02 PM

SAP CRM V1.2007 Best Practice

Hello,
we are preparing the installation of a new CRM 2007 system and we want to have a good demo system.
We are considering too options;
. SAP CRM IDES
. SAP CRM Best Practice
knwoing that we have an ERP 6.0 IDES system we want to connect to.
The Best Practice seems to have a lot of preconfigured scenarios that will not be available in the IDES system (known as the "SAP all in one").
How can we start the automatic installation of the scenarios (with solution builder) connecting to the ERP IDES system?
Reading the BP Quick guide, it is mentioned that in order to have the full BP installation we need to have a ERP system with another Best Practice package.
Will the pre customized IDES data in ERP be recognized in CRM?
In other words, is the IDES master data, transactional data and organizational structure the same as the Best Practice package one?
Thanks a lot in advance for your help
Benoit

Thanks a lot for your answer Padma Guda,
The difficult bit in this evaluation is that we don't know exactly the
difference between the IDES and the Best Practice. That is to say,
what is the advantage to have a CRM Best Practice connected to an ERP
IDES as opposed to a CRM IDES system connected to a ERP IDES system?
As I mentioned, we already have an ERP IDES installed as back end system.
I believe that if we decide to use the ERP IDES as the ERP back end, we will loose some of the advantage of having an ERP Best practice connected to an CRM best practice e.g. Sales area already mapped and known by the CRM system, ERP master data already available in CRM, transactional data already mapped, pricing data already mapped etc.
Is that righ? Or do we have to do an initial load of ERP in all cases?

Best practice Error " no fiscal year "

In best practice Report CR " GL Statment " After updating the data base and entering the parameters , It pops to me error " no fiscal year variant specified " though i run the same query in the ERP with the same parameters and it runs !
And am using Crystal Reports 2008 , version 12.1.0.892 . This Report in SAP BEST PRACTICE

Did you configure the additional data sources and the BP package itself as described in the BI QUick guide and the Add additional data sources document included in the package?
Regards,
Stratos

Best practice for invoice posting inSRM

Dear expert,
what is the best practice for posting an invoice? Is it in SRM system or MM system? In SRM, the system allows one to use approval procedure for invoice posting; wheras in MM, one cannot use the apporval procedure to post an invoice. similar is the case, in SRM-SUS and MM-SUS scenario?
I would appreciate if you can feedback on the industry practice.
thanks and regards,
Ranjan

Ranjan,
As a SAP customer we use invoice entry in ERP using MIRO and FB60 as these are the most efficient for our busines.
1. Invoice entry using MIRO tcode is faster as it can be done with minimal use of the mouse. Invoice entry is slower in SRM as browser response and interactions with the backed ERP system slows the systems reponse to the user input. Repeated use of a mouse in the SRM browser is detrimental to fast input.
2. Not all types of invoices can be handled in SRM e.g. Invoice without PO.
3. We process approx 20,000 invoices per month with multiple input operators, SRM could not handle that sort of load.
4. SRM is really a procurement application and although invoice entry is included it is probably more for users who wish to use SRM in a stand alone scenario. We use extended classic so all our financial transactions take place in the ERP backend.
Your choice also depends upon the number and quality of the invoices you plan to process, and the need for the operators to be trained on one or two systems.
Hope these personal observations assist with your decision
Regards
Allen

Best practice in migrating to a production system

Dear experts,
Which is the best practice to follow during an implementation project to organize development, quality and production environment?
In my case, considering that SRM is connected to the back-end development system, what should be done to connect SRM to back-end quality environment:
- connect the same SRM server to back-end quality environment, even if in this case the old data remain in SRM or
- connect another SRM server to back-end quality environment?
thanks,

Hello Gaia,
If yo have 3 landscape, backend connection should be like this.
SRM DEV   - ERP DEV
SRM QAS   - ERP QAS
SRM PRD - ERP PRD
If you have 2 landscape.
SRM(client 100) - ERP DEV
SRM(client 200) - ERP QAS
SRM PRD         - ERP PRD
Regards,
Masa

Best Practices for File Organization/Project Explorer

So we are finally getting SCC at my organization to manage our LabVIEW development, and that is good!
Now, we are starting in on discussions about how we should organize our files on disk and how we should use the Project Explorer. When I started here about 3 years ago, I wasn't very familiar with the project explorer, so I read the article at http://zone.ni.com/devzone/cda/tut/p/id/7197. Two of the main things I took away from that article are:
1. Organize Files in a logical manner on disk. Whatever that is, it is not a flat file structure.
2. The top level VI should be separate from other source code. Preferably, it should reside in the application folder.
Push Back Against These Recommendations
Before I was hired, most, if not all LabVIEW development was done utilizing a flat file structure and the top level VI lived with the source code. Since we didn't have a proper SCC, each individual organized files as he saw fit. So I started using the Project Explorer (not even its use is totally accepted right now) and I began follow recommendations 1 and 2 above. I didn't always follow #1 very strictly, but I have been working towards it, and I have always followed #2 religiously.
Since we are starting these discussions on how we should organize files on disk I'm starting to get some push back to following these two recommendations.
The arguments I get in favor of using a flat file structure is that you always know where every file is; including the top-level VI. It is also argued that it is a lot of effort to organize and search for VIs when they all reside in different folders. I think the fear is that by getting "clever" and organizing our files in such a manner we'll make things complicated and we will somehow shoot ourselves in the foot.
The argument I get against separating the top level VI from the rest of the source code is that it:
(a) Won't be clear where it is (like it is buried within hundreds of VIs). However, it is argued, you can just put a "!" in front of the file name and then it is always the at top of the flat file structure.
(b) An extension of argument of (a) is that things either look or seem messy when VIs (including top level VI) don't live in a sub-folder and are just hanging out with the Project Explorer file.
(c) I think there may be some fear of breaking the VI by moving it and altering the dependencies for the VI.
Convincing Others its Good to Follow These Recommendations
So, if I want to follow NI's recommendations, I need to come up with reasons we should follow these recommendations. Also, I should state that I care about following these recommendations because its what NI recommends. They've been around the block a few times and I'm sure there are good reasons why these are best practices. However, I don't think I've given a very compelling case for why these recommendations should be followed.
So I'll tell you all what I think good reasons are for these recommendations and perhaps I can get some feedback or additional support? If I'm crazy for wanting to follow these recommendations maybe someone can point out why I'm crazy.
(a) Arguments for Following Both
I. I passed the CLAD a couple of weeks ago, and I have started studying for the CLD. Part of the CLD is following both of these recommendations (see page 6 of http://ftp.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf). While this isn't a reason in and of itself, it suggests that if it important when being certified it is important in practice!
II. If we hire new developers that are familiar with LabVIEW, they will most likely be familiar with these recommendations, especially if they are certified. That will lead to increased productivity out of the door because they won't have to learn our special way of doing things.
(b) Arguments for Organized File Structure
I. Unused VIs are easier to identify and remove. Right now we never remove VIs because we don't know if they are used or not. This leads to a lot of VI bloat.
II. It is hard to know what a specific VIs function is in a flat file structure by looking at the name.
(c) Arguments for Separating Top Level VI from Source Code
I. Placing the top level VI is an intuitive place for this VI. As long as the top level VI is the only VI in the application folder there is no mistake it is the top level VI, especially once you open it. This makes it easy for new developers to find the top level VI. I'd argue it isn't very intuitive for new developers to know that a VI in the source code folder that is prefaced with a "!" is the top level VI.
Summary
So that is what I think so far. Is there anything else I am missing to support following those two recommendations or am I just being inflexible?
Thanks!

zenthoef,
As a CLA, I have struggled with file structure over the years. Here are my recommendations:
1. Put the top level VI and the project in the top-level folder. This makes it very clear where to begin.
2. Put the remaining user interface VIs in a separate folder. Again, it makes it very clear what the functionality of these VIs are.
3. If you are using object, put each object in a separate folder. Place the family of objects in one folder, with each object in a subfolder.
4. Keep the remaining VIs either in a single folder. This can contain a small number of subfolder if your project is large, but too many folders makes it hard to figure out where your VIs are. For example, you might have a DAQ subfolder, an Analysis subfolder, and a Report subfolder. But if you had a Test1 folder, a Test2 folder, and you had a VI that was used by both tests, where would it go? Keep it simple.
5. You inferred that it is hard to figure out what a VI does by its name. That implies that 1) you need better names, and 2) your VIs are too complicated. A VI should do a single function which can be adequately described by its name. That VI might be something like Analyze Data.vi, which would contain a bunch more subVIs (like Get 1st Harmonics.vi), but each VI would contain a single function. You wouldn't save the data to a report in the Analyze Data.vi, for example.
The most compelling reason for following these suggestions is that it is easier to figure out what the code is doing after you haven't looked at it for a while. Once you have an application that is working and bug free, you shouldn't have to touch the code until you want to add features. If that is even 6 months later, you will probably have forgotten how the code works. As a consultant, I have had to update other people's code, and just figuring how where to start can be a challenge.
Tom Brass
Certified LabVIEW Architect
Saint Bernard Engineering, Inc.
www.saintbernardengineering.com
Tom Brass
Certified LabVIEW Architect
Saint Bernard Engineering, Inc.
www.saintbernardengineering.com

Best Practice for Plan for Every Part (PFEP) Database/Dashboard?

Hello All-
I was wondering if anyone had experience with implementing / developing a Plan for Every Part (PFEP) Database in SAP. My company is looking to migrate its existing PFEP solution (Custom developed Excel/Access system) into SAP. If you are unfamiliar, a PFEP is a dashboard view of a part/material that provides various business groups with dedicated views to data from Material Masters, Info Records, and Vendor Master Records and combines it with historical/forecasting information. The goal is to provide a single source to all the part/material settings for a given part.
Is there a Best Practice PFEP in SAP? Or if this is something that most companies custom develop in ERP or BI?
Thanks in advance.
-Ron

I think you will likely get a response in SAP ERP - Logistics Materials Management (SAP MM)
additionally you might want to do some searches based on SAP Lean Inventory, perhaps Kanban. I am assuming you are not using WM or EWM either?
Where I have seen PFEP incorporated into the supply chain strategy this typically requires not inconsiderable additions to the alternate UoM in MM dropping of automatic replenishment levels (reorder level) and rethinking aspects of the MRP plan so be prepared or significant additional data management work if you haven't already started on that. I believe Ryder logistics uses PFEP and theirSAP infrstructure is managed by IBM; might be an idea to try and find a linkedin resource from there. You may also find one of the ASUG supply chain,logistics, MM or WM sigs a good place to also ask questions and look for answers.

Need Best Practice for Migrating from Solaris to Linux

Hi Team,
We are migrating our Data Center from Solaris to Linux and our EBS 11i, database 10g (10.2.0.5) is 6TB. Please let us know the Best Practice to Migrate our EBS 11.5.10.2 from Solaris to Linux RHEL 5.
we require Database 10g (10.2.0.5) on Linux x86-64 RHEL 5 and Application EBS on Linux x86 RHEL 5. Please let us know for any details.
EBS version: 11.5.10.2
DB version: 10.2.0.5
We have checked the certifications in Oracle support.
Oracle EBS 11.5.10.2 is not certified with Linux x86-64 RHEL 5.
Oracle EBS 11.5.10.2 is certified on Linux x86 RHEL 5.
So we require Database 10g (10.2.0.5) on Linux x86-64 RHEL 5 and Application EBS on Linux x86 RHEL 5.
Thank You.

You can transportable tablespace for the database tier node.
https://blogs.oracle.com/stevenChan/entry/10gr2_xtts_ebs11i
https://blogs.oracle.com/stevenChan/entry/call_for_xtts_eap_participants
For the application tier node, please see:
https://blogs.oracle.com/stevenChan/entry/migrate_ebs_apptiers_linux
https://blogs.oracle.com/stevenChan/entry/migrating_oracle_applications_to_new_platforms
Thanks,
Hussein

In the Begining it's Flat Files - Best Practice for Getting Flat File Data

I probably should have posed this question here before I delved into writing Java to get data for reports, but better late than never.
Our ERP is written in COBOL. We have a third party ODBC which allows us to access data using a version of SQL. I have several Java sources compiled in my database that access the data and return something relevant. The Java sources are written in a procedural style rather than taking advantage of object oriented programming with attributes and methods.
Now that I am becoming more comfortable with the Java language, I would greatly appreciate any feedback as to best practices for incorporating Java into my database.
My guess is that it would be helpful to model the ERP "tables" with Java classes that would have attributes, which correspond to the fields, and methods to return the attributes in an appropriate way. Does that sound reasonable? If so, is there a way to automate the task of modeling the tables? If not reasonable, what would you recommend?
Thanks,
Gregory

Brother wrote:
I probably should have posed this question here before I delved into writing Java to get data for reports, but better late than never.
Our ERP is written in COBOL. We have a third party ODBC which allows us to access data using a version of SQL. I have several Java sources compiled in my database that access the data and return something relevant. The Java sources are written in a procedural style rather than taking advantage of object oriented programming with attributes and methods.
OO is a choice not a mandate. Using Java in a procedural way is certainly not ideal but given that it is existing code I would look more into whether is well written procedural code rather than looking at the lack of OO.
Now that I am becoming more comfortable with the Java language, I would greatly appreciate any feedback as to best practices for incorporating Java into my database.
My guess is that it would be helpful to model the ERP "tables" with Java classes that would have attributes, which correspond to the fields, and methods to return the attributes in an appropriate way. Does that sound reasonable? If so, is there a way to automate the task of modeling the tables? If not reasonable, what would you recommend?Normally you create a data model driven by business need. You then implement using whatever means seem expedient in terms of other business constraints to closely model that data model.
It is often the case that there is a strong correlation between data models and tables but certainly in my experience it is rare when there are not other needs driven by the data model (such as how foreign keys and link tables are implemented and used.)

Best Practices ERP Certification

Similar Messages

Maybe you are looking for