KentW Limited

Now it happened and I couldn’t stop it – Windows 7 installed IE9 on my computer after a fresh install.

IE8 worked fine with Oracle R12 but what will IE9 bring?

Without going into details this is what I have to do to make it work:

• Allow Java to run (same as in IE8)
• Enable pop-ups (same as in IE8)
• Disable XSS filter (new)

Issues

After logging all is fine – your problems start when you click a link for the Java based forms.

This webpage wants to run the following add-on “Java(TM) SE Runtime Environment"

Click Allow and click the Java link again

Internet Explorer blocked a pop-up from

Click drop-down “Options for this Site” and click “Always Allow”:

click the Java link again:

Internet Explorer has modified this page to prevent cross-site scripting

This is caused by the "XSS Filter" but not to open your security to the whole world we need to add the URL to "Trusted Sites" similar as recommended for IE8:

Click Sites and click Add:

Then click close and click "Custom Level" to disable the XSS filter:

Click OK and retry the link to the Java form:

Sorted!

This post is an extension of the overview – read this first: Agile ERP Implementations

The Scrum methodology is a framework for developing high value products iteratively using self-regulating teams to improve synergy and effectiveness.

Scrum prescribes the following projects activities which are all related to a specific Sprint:

• Sprint Planning Meeting – scope and approach for the next Sprint or Increment
• Daily Scrum – short daily meeting to coordinate within the Sprint team
• Sprint Review Meeting – review of the current Sprint on Product Backlog
• Sprint Retrospective – review of how to improve the Sprint

Scrum does not however specify Pre- and Post-Game activities and does not prescribe the processes and techniques for building products.

An ERP implementation is a complex project where the implementation process will impact the Scrum methodology:

• Multiple Sprints in Parallel
• Interdependent and prerequisite Sprints
• Significant non-Sprint activities
• Coordination of internal; external or offshore project resources
• Management of third party product and service deliveries

To keep the spirit of the Scrum Guide each Sprint should be self-regulating to produce the next Increment whilst the Product Manager must ensure each Sprint is executed in the right sequence. Planning the Scrum project becomes focus on coordinating Sprints rather than planning the individual Sprint itself.

Pre-Game Phase

The Pre-Game planning is to ensure the following:

• Project Kick-off
• Creation of Product Backlog
• Creation of Sprint overview plan with expected number of Sprints and their dependencies and needed non-Sprint activities
• Creation of strategic working documents like Stakeholder and Risk Management strategies

In particular for ERP implementations there is a specific process that must be followed as ERP systems require a sequential setup process due to module and functionality dependencies.

Sprint Phase

The planning of the individual Sprint is very much given by the Scrum methodology with the Sprint Backlog and the addition of a few ERP specific processes:

• Scrum items:
  • Sprint Planning Meeting – scope and approach for the next Sprint or Increment
  • Daily Scrum – short daily meeting to coordinate within the Sprint team
  • Sprint Review Meeting – review of the current Sprint on Product Backlog
  • Sprint Retrospective – review of how to improve the Sprint
• ERP specific items:
  • Development Work – functional or  technical work to produce features according to Sprint Backlog
  • Acceptance and Sign-off – client approval of “done” features
  • Increment Delivery – apply new features to Gold environment

The Sprint Team will plan the Development Work within the team so no project plan will be made for the individual Sprint – however a generic plan can be made to communicate the expected process for each Sprint – for example:

All Sprints will start with a Sprint Planning Meeting to produce the Sprint Backlog based on selected features from the Product Backlog.  Next the Sprint will commence where Daily Scrum; Development Work and Feature Acceptance and Sign-off as on-going processes.

When the Sprint is complete the Increment is delivered and Sprint Review and Retrospective will take place.

Depending on the Development Work the Increment Delivery can be anything from setting up the Gold environment to deploying a new database.

So a multi-Sprint project could look like this:

The Scrum methodology states each Development Team organises their own Sprint. So the Product Owner concentrates on coordinating Sprints and other dependencies like Infrastructure.

The above example having 4 Increments would have a 4-5 months duration – so a fairly simple implementation.

Post-Game Phase

According to the Scrum methodology the Product Backlog is never complete but from an ERP project point of view there must be a go-live point and a point where external resources are released. The Product Backlog and then accumulate and a Phase 2 project can be initiated at a later stage.

An example of a Post-Game phase with a go-live and support phase and wind-down period:

This post is an extension of the overview – read this first: Agile ERP Implementations

Artefacts and project document flows vary by the size of a project so I would use this as a generic guide only.

The Scrum methodology states the following Artefacts are needed:

• Product Backlog – list of desired product features
• Sprint Backlog – list of product features to be developed in a specific Sprint
• Increment – a working product based on all Sprints completed to date

In addition to the Scrum methodology an ERP implementation may need additional Artefacts:

• Issue Backlog – list of issues or changes

Other working documents that may or may not be needed depending on the size of the project are:

• Setup documents – module configurations with specific setup sequences
• Interface documents – complex interface scenarios
• Data migration documents – complex data migration scenarios
• Test documents – test scripts to verify if a feature has been fulfilled
• User Procedures – end-user procedures and user guides
• Training documents – end-user training documents
• Cut-over document – complex go-live scenarios needing coordination of interfaces, data migration and people

Some working documents like the setup documents should be regarded as part of the Increment and final documentation where others is only relevant during the ERP project.

Some documents like user-guides and training documents for a feature could with some advantage be created during the Sprint developing that feature.

The working documents are normal documents for an ERP implementation so they will not be discussed further in this article.

The Scrum document workflow is as follows (disregarding working documents and project size considerations):

Keep in mind the above diagram indicates that multiple Sprints and Sprint Backlogs can exist at any one time whereas there is only one Product Backlog; Increment and Issue Backlog throughout a Scrum ERP implementation project.

Product Backlog

The Product Backlog is owned and maintained by the Product Owner throughout the whole Scrum project.

The Product Backlog in accordance to the Scrum methodology contains all features, functions, requirements, enhancements, and bug fixes. Well this would be rather impossible to manage in an ERP implementation as just the requirements may be in the hundreds and issues/bugs may run into thousands. To put all functions into the Product Backlog would not add any value as with an ERP system one would expect certain basic functions to exist like “Ability to create a journal”.

The Scrum methodology also states that the Product Backlog is dynamic and constantly changing – an approach that would be dangerous in a large scale ERP implementation. For an ERP implementation it is necessary to manage changes to requirements due to multiple stakeholders; costs; resources and dependencies. Change to the Product Backlog should be agreed in the steering committee to ensure any impacts are properly assessed.

The Product Backlog must be tailored to ERP Implementations so it becomes manageable and value added. The Product Backlog should only contain requirements specific to the business having the ERP implementation and the requirements must have an owner or a sponsor who is responsible for the desired need – ideally grouped by functional area and type of requirement like legal; business or non-functional.

Other qualifying items may be priority, cost and dependencies. Dependencies are necessary in ERP implementations as even if the Receivables module is the most important for the project you must implement the General Ledger first and before doing this you must define security and chart of accounts and so forth.

Suggested Product Backlog fields:

• Requirement – id; name and description of the feature
• Type – legal; regulatory; business or non-functional like performance and security
• Status – open or closed
• Owner – the person; stakeholder or department needing the requirement
• Functional Area – module area or discipline
• Dependency – referring id to a dependent feature
• Priority – must have, highly desirable,  nice to have
• Estimate – duration
• Sprint – id of assigned sprint

Other fields may be necessary depending on the size and needs of the project.

Sprint Backlog

A Sprint Backlog is owned by the Scrum Master and is created for each Sprint.

The Sprint Backlog is populated with selected Product Backlog features and then enriched with subtasks needed as part of the development ensuring that each feature/item is measurable down to 1-2 days. This detailed breakdown ensures easy tracking and removes the need for separate planning within a Sprint.

Issue relevant for the Sprint may be added from the Issue Backlog.

Issues encountered during the Sprint should be added to the Sprint Backlog as a subtask and if not resolved during the Sprint or if outside the Sprint scope – the issue should be added to the Issue Backlog.

Suggested Sprint Backlog fields:

• Development Item – id; name and approach of feature/subtask/issue
• Type – feature; subtask or issue
• Reference – requirement id or related development item id
• Status – open; setup; developed; tested; accepted or cancelled
• Assigned – assigned Sprint team member
• Estimate – duration (if estimate is >2 days additional subtasks are needed)

For a successful Sprint – all or most of the development items should have accepted hence a Sprint item do not have a priority.

When the Sprint is complete the Product Backlog is updated from the Sprint Backlog which then cease to exist.

Increment

The Increment is owned by the Product Owner throughout the whole Scrum project.

The Increment is the accumulated working product of the latest Sprint. In an ERP implementation this is a new base-lined instance of an environment – normally called gold. When a new configuration or development has been successfully tested and accepted – it is applied to the gold environment and then backed. The new gold environment is now ready for go-live or the next Sprint.

A type typical ERP implementation Sprint could be done as follows:

The Sprint environment is the clone of the gold environment where development; changes and test are being made. As the Sprint environment contains dirty data -  the base-lined changes must be re-applied to the Gold Environment. The Gold backup is needed in case something goes wrong during the base-line setup.

The environment is maintained by the infrastructure team on an on-going basis and is therefore outside the Agile ERP implementation methodology.

Issue Backlog

The Issue Backlog is owned by the Product Owner throughout the whole Scrum project but can be maintained by the Product Owner and the Scrum Master(s).

The Issue Backlog is an ERP implementation specific need due to the high number of issues; changes and bugs normally occurring in an ERP project. Many issues are also be cross-functional and could be outside the scope of the current Sprint and hence should be tracked outside the Sprint.

If the ERP implementation scope is only one or two modules then this Issue Backlog could be avoided by including the issues in the Product Backlog.

Suggested Issue Backlog fields:

• Issue Item – id; name and problem description
• Reference – related requirement id
• Status – open or closed
• Priority – critical, important,  cosmetic
• Estimate – duration
• Approach Id – id of assigned Sprint Backlog or Product Backlog item

Any issue can be selected for a Sprint Backlog or converted into a Product Backlog item if it’s a new feature.

By applying Agile development and project management methods we can improve overall customer satisfaction by increasing customer interaction throughout the project without sacrificing scope control and quality.

The Agile methodology helps the customer to gradually understand and accept the new system whilst providing constructive feedback and suggestions to the implementation team throughout the project.

This article will focus mainly on the high-level phases of Agile.

A later article will discuss the detailed project management and the resource management side of Agile.

More reading:

• Agile ERP Implementations – The Team
• Agile ERP Implementations – Artefacts
• Agile ERP Implementations – Planning

Agile Development

The term Agile originates from Agile Software Development which is a software engineering methodology that focuses on interactive development and regular working releases.

The Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The above makes sense not only in a software development but also in ERP implementations. In order to ensure the Agile manifesto applies to an implementation we need to apply an Agile project management method.

Agile Project Management

There are several Agile project management methods but let’s have a closer look at Scrum as an example. There are many flavours of Scrum as it was originally made for product development but from a high level we can say there is three phases in a Scrum project lifecycle:

· Pre-game Phase – project initiation with requirements and high-level planning

· Development Phase – multiple development cycles (Sprint’s) delivering working product releases

· Post-game Phase – project go-live with deployment and documentation delivery

Pre-game Phase

In this phase the business and non-functional requirements are put into a prioritised list of features called the Product Backlog - essentially forming the project scope and high-level project plan.

The Product Backlog should only define what is needed:

So no huge scope or requirements document but merely a list of customer needs. In my experience this makes sense as it is impossible to define all requirements up-front – even for an out of the box solution especially when the make of the future system is unknown.

The original Scrum methodology states that anyone on the project can update the Product Backlog with new requirements and any defects or issues encountered. On an ERP project – where the team is huge and defects and/or issues can run into the 100s – I would refrain from this approach and rather treat the Product Backlog as being under change control to avoid scope creep. The defects and issues could be places in a separate Issue Backlog or similar.

Development Phase

This phase contains multiple development cycles – each called a Sprint. Each Sprint delivers a product release with new features as defined in the Sprint Backlog, which is a subset of features from the Product Backlog and any previous defects or issues to be resolved from the Issue Backlog:

Each Sprint contains analysis; design; build; test and delivery.

Each ERP Sprint would encompass:

· Sprint Backlog – subset of Product Backlog features

· Application Design – configuration planning

· Configuration – cloning if needed; configure and unit test items in Sprint Backlog

· User Acceptance Test – user test and acceptance of items in Sprint Backlog

Multiple Sprint cycles can operate in parallel if they are delivering independent features. For example can customisations be considered as an independent Sprint cycle.

The number of Sprint’s will vary depending on project size and complexity. But for example a minor project could be arranged like this:

1. Core features – chart of accounts; ledgers and user security

2. Basic features – sub-ledger transactions; posting; reporting and journals

3. Advanced features – intercompany, multicurrency and consolidation

4. Development -customisations; interfaces and data migration

Where Sprint 4 could be run in parallel with Sprint 3 if the customisation is independent of these features.

So a small implementation is around 4-5 sprints.

Each Sprint cycle duration would be around 3-4 weeks.

In accordance to the Scrum methodology each Sprint requires the user to test and accept the delivered features. So the Scrum methodology provides a rolling User Acceptance Test (UAT) ensuring a more balanced approach to acceptance and project completion.

The user also incrementally learns about the system and can therefore better provide constructive feedback for both the current as well as the next Sprint cycle.

Commercially this is also good approach as each Sprint is having an UAT the payment milestones would naturally match the Sprint cycles.

Post-game Phase

This phase deploys the last Sprint release into production and the documentation is delivered.

This is similar to a normal implementation project where the last tested configuration is deployed.

The documentation can be generated automatically or manually as on a normal ERP implementation as part of each UAT:

The benefit of Agile/Scrum is that the go-live leap should be smaller as the UAT has been a progressive experience rather than a big bang.

The Phased Implementation – Looking Back

Still to this day the normal way of implementing ERP systems is to use the phased implementation model with a known method like Oracle Application Implementation Method (AIM); Oracle Unified Method (OUM) or similar.

The typical waterfall phases are:

· Analysis

· Design

· Build

· Transition

· Production

Several environments are delivered from design to production with the final test being the User Acceptance Test (UAT) for final signoff before going live.

The phased implementation models are characterised by complicated project plans and documentation flows. It is often unclear what is a deliverable and what is a work product and how this tie in with the commercial contract.

Anyone who has been a part of a large phased implementation knows the following symptoms:

· Requirements are missed

· Loads of paper being produced

· Deadlines are missed

· Communication failures

· Payment disputes

· Fear of going live

Some newer implementation methods are leaning towards being agile – like the Oracle Business Accelerator (OBA) which speeds up the delivery of the first working instance but the remaining phases are still similar to AIM.

This post is an extension of the overview – read this first: Agile ERP Implementations

In this post we will focus on the implementation team.

The standard Scrum method has an organisational structure as follows:

• Scrum Team – Everybody on the project
  • Product Owner – Project Manager
    • Development Team – Individual Sprint team
      • Scrum Master – Team leader and facilitator
      • Team Member – Professional developer

In addition to this an ERP implementation project may need cross-departmental and multi-project coordination:

• Steering Committee – Cross-departmental coordination
• Programme Manager – Cross-project coordination

Organisation Chart:

Scrum Team

The Scrum Team is a self-organising cross-functional project team responsible for delivering a product.

With an ERP implementation the product would be a working implementation live in production.

As with any normal business you may have several parallel on-going projects however these would have their own Scrum Teams. Coordination between projects may require a programme manager or similar.

As ERP implementation projects mostly are cross-departmental the scope of the Scrum should be controlled by a Steering Committee. This is not stated as part of the Scrum methodology but the Scrum methodology is made for product development where most products are developed within one department – hence no need for this kind of coordination.

Product Owner

The Product Owner is responsible for delivery of the product on time and budget. The product owner owns and maintains the product backlog. In an ERP Implementation the product owner may have to answer to a steering committee to ensure cross-departmental interests are met.

The Product Owner will also manage any agreed change to the product backlog and may maintain a project wide issue log.

The Product Owner has the power to cancel a Sprint if it is overrunning or hitting unexpected difficulties.

Development Team

The Development Team is responsible for delivering a Sprint producing a working product or a new feature.

The Development Team is tailored to the individual Sprint and is not static throughout the whole Scrum project.

Multiple Development Teams can work in parallel – each producing a Sprint. However care must be taken to ensure features are not dependent between parallel Sprints.

Each Development Team should be kept to a minimum ideally less than 8 people.

A typical development team for a basic General Ledger setup Sprint could be:

• Scrum Master
• Client Accountant
• Client Chief Accountant
• External General Ledger Consultant
• External Developer

This may vary based on module and project size but if the team becomes too big for a Sprint – it is better to split the Sprint into smaller pieces.

Smaller teams are more efficient and communicate better which is the basic idea behind the Scrum methodology.

Scrum Master

The Scrum Master is the development team leader responsible for facilitating and monitoring the Sprint.

The Scrum Master will ensure the Scrum methodology is followed by all development team members.

The Scrum Master owns and maintains the Sprint backlog and reports progress back to the Product Owner.

Any issues or impediments are resolved within the Development Team or escalated to the Product Owner.

Team Member

The Team Member is a professional responsible for developing the product with the help of the other team members.

All team members are equal and are all developers with the sole focus of producing the product or feature in accordance to the Sprint backlog.

Any issues identified are reported to the Scrum Master.

By applying Agile development and project management methods we can improve overall customer satisfaction by increasing customer interaction throughout the project without sacrificing scope control and quality.

The Agile methodology helps the customer to gradually understand and accept the new system whilst providing constructive feedback and suggestions to the implementation team throughout the project.

This article will focus mainly on the high-level phases of Agile. A later article will discuss the detailed project management and the resource management side of Agile.

Agile Development

The term Agile originates from Agile Software Development which is a software engineering methodology that focuses on interactive development and regular working releases.

The Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The above makes sense not only in a software development but also in ERP implementations. In order to ensure the Agile manifesto applies to an implementation we need to apply an Agile project management method.

Agile Project Management

There are several Agile project management methods but let’s have a closer look at Scrum as an example. There are many flavours of Scrum as it was originally made for product development but from a high level we can say there is three phases in a Scrum project lifecycle:

· Pre-game Phase – project initiation with requirements and high-level planning

· Development Phase – multiple development cycles (Sprint’s) delivering working product releases

· Post-game Phase – project go-live with deployment and documentation delivery

Pre-game Phase

In this phase the business and non-functional requirements are put into a prioritised list of features called the Product Backlog - essentially forming the project scope and high-level project plan.

The Product Backlog should only define what is needed:

So no huge scope or requirements document but merely a list of customer needs. In my experience this makes sense as it is impossible to define all requirements up-front – even for an out of the box solution especially when the make of the future system is unknown.

The original Scrum methodology states that anyone on the project can update the Product Backlog with new requirements and any defects or issues encountered. On an ERP project – where the team is huge and defects and/or issues can run into the 100s – I would refrain from this approach and rather treat the Product Backlog as being under change control to avoid scope creep. The defects and issues could be places in a separate Issue Backlog or similar.

Development Phase

This phase contains multiple development cycles – each called a Sprint. Each Sprint delivers a product release with new features as defined in the Sprint Backlog, which is a subset of features from the Product Backlog and any previous defects or issues to be resolved from the Issue Backlog:

Each Sprint contains analysis; design; build; test and delivery.

Each ERP Sprint would encompass:

· Sprint Backlog – subset of Product Backlog features

· Application Design – configuration planning

· Configuration – cloning if needed; configure and unit test items in Sprint Backlog

· User Acceptance Test – user test and acceptance of items in Sprint Backlog

Multiple Sprint cycles can operate in parallel if they are delivering independent features. For example can customisations be considered as an independent Sprint cycle.

The number of Sprint’s will vary depending on project size and complexity. But for example a minor project could be arranged like this:

1. Core features – chart of accounts; ledgers and user security

2. Basic features – sub-ledger transactions; posting; reporting and journals

3. Advanced features – intercompany, multicurrency and consolidation

4. Development -customisations; interfaces and data migration

Where Sprint 4 could be run in parallel with Sprint 3 if the customisation is independent of these features.

So a small implementation is around 4-5 sprints.

Each Sprint cycle duration would be around 3-4 weeks.

In accordance to the Scrum methodology each Sprint requires the user to test and accept the delivered features. So the Scrum methodology provides a rolling User Acceptance Test (UAT) ensuring a more balanced approach to acceptance and project completion.

The user also incrementally learns about the system and can therefore better provide constructive feedback for both the current as well as the next Sprint cycle.

Commercially this is also good approach as each Sprint is having an UAT the payment milestones would naturally match the Sprint cycles.

Post-game Phase

This phase deploys the last Sprint release into production and the documentation is delivered.

This is similar to a normal implementation project where the last tested configuration is deployed.

The documentation can be generated automatically or manually as on a normal ERP implementation as part of each UAT:

The benefit of Agile/Scrum is that the go-live leap should be smaller as the UAT has been a progressive experience rather than a big bang.

The Phased Implementation – Looking Back

Still to this day the normal way of implementing ERP systems is to use the phased implementation model with a known method like Oracle Application Implementation Method (AIM); Oracle Unified Method (OUM) or similar.

The typical waterfall phases are:

· Analysis

· Design

· Build

· Transition

· Production

Several environments are delivered from design to production with the final test being the User Acceptance Test (UAT) for final signoff before going live.

The phased implementation models are characterised by complicated project plans and documentation flows. It is often unclear what is a deliverable and what is a work product and how this tie in with the commercial contract.

Anyone who has been a part of a large phased implementation knows the following symptoms:

· Requirements are missed

· Loads of paper being produced

· Deadlines are missed

· Communication failures

· Payment disputes

· Fear of going live

Some newer implementation methods are leaning towards being agile – like the Oracle Business Accelerator (OBA) which speeds up the delivery of the first working instance but the remaining phases are still similar to AIM.

When making your R12 server available on-line you need to protect your FND user password.

This assumes that you have ONLY opened port 8000 for APPS login access.

For any other access I can only recommend to use VPN as a full OEL and RDBMS lock down is very complex.

I used the following script (use at your own risk):

begin
    /* lock ALL seeded accounts first */
    update fnd_user set end_date=sysdate;
    commit;
    /* then unlock the necessary ones */
    update fnd_user set end_date=null where user_name in (
        ‘ANONYMOUS’,
        ‘APPSMGR’,
        ‘AUTOINSTALL’,
        ‘CONCURRENT MANAGER’,
        ‘FEEDER SYSTEM’,
        ‘GUEST’, /* NEVER touch this account as this enables APPS login */
        ‘INITIAL SETUP’,
        ‘ORACLE’, /* my demo account */ 
        ‘SYSADMIN’
    );
    commit;
    /* set password – but NOT for GUEST */
    fnd_user_pkg.updateuser(‘ANONYMOUS’,null,’password’);
    fnd_user_pkg.updateuser(‘APPSMGR’,null,’password’);
    fnd_user_pkg.updateuser(‘AUTOINSTALL’,null,’password’);
    fnd_user_pkg.updateuser(‘CONCURRENT MANAGER’,null,’password’);
    fnd_user_pkg.updateuser(‘FEEDER SYSTEM’,null,’password’);
    fnd_user_pkg.updateuser(‘INITIAL SETUP’,null,’password’);
    fnd_user_pkg.updateuser(‘SYSADMIN’,null,’password’);
    fnd_user_pkg.updateuser(‘ORACLE’,null,’password’);
    commit;
end;
/
exit;

Note: Do NOT to touch the GUEST user.

Want to access your R12 installation from a client site?

No problem – pick up the R12 installation described earlier and install the hard disk in a HTPC!

For the purpose I bought a Acer AspireRevo R3700 with the following relevant specifications:

• Processor Intel® Atom D525 processor 1.8GHz
• Memory 2GB DDR3 800MHz
• Graphics NVIDIA ION graphics solution
• Networking Gigabit Ethernet, Wake-on-LAN ready and WLAN: 802.11b/g/n

Replace the built-in harddisk with the R12 harddisk and boot the machine.

The machine can be accessed from your network using Putty or Xming.

The only problem experienced was to fix the Realtek LAN networking.

A Linux driver is needed for the network card Realtek R8168.

Unpack the file and follow the instructions in the readme file.

Don’t forget to open port 8000 in your firewall and lock down your FND USER passwords.

Conclusion

Performance is good and rather improved thanks to the internal SATA connection which is much faster than using an external USB 2.0 connection.

The dual core Intel Atom D525 netbook CPU seems unimpressed with the R12 technical stack and performs well.

Running one Java client and a concurrent manager report does not stress the CPU.

The R12 system with a single user logged on tops out around 1.7Gb RAM so the built-in 2Gb RAM is plenty.

Note the hyper threading shows as additional CPU’s:

How many segments in my Chart of Accounts (COA) are needed for my business?

There are many considerations and this article will only focus on the number of segments rather than the segment values which will be handled in a later post.

Some of the considerations are:

• Oracle System requirements
• Legal reporting requirements
• Financial management reporting needs
• Globalisation needs (some countries have special requirements)
• Consolidation needs (some segments may have to be used globally)
• Security needs

Oracle System Requirements

Oracle E-Business suite requires the following segments:

• Balancing
• Natural Account
• Cost Center (for Fixed Assets)

Optionally you can also have:

• Intercompany
• Management (for security)
• Secondary Tracking (for extra year-end tracking)

Usage details can be found in the General Ledger Implementation Guide.

All other requirements vary so below is a few do’s and don’ts:

Do’s

The User Guide details the Oracle requirements for a segment however in addition to that I recommend this:

• Keep it simple – your users will have to type it in a lot of times
• Focus on financial reporting requirements and needs
• Identify segments likely to be consolidated and make global usage rules for these
• Have same number of segments globally (to ease documentation and customisations)
• Have same segment names globally (to ease documentation and customisations)

Don’ts

Could be a very long list but I’ll keep it to the typical errors I have seen in implementations:

• Have too many segments (impacts usability and performance)
• Use of subledger reporting segments like:
  • Product or Item (sales reporting in the GL)
  • Customer (sales reporting in the GL)
  • Project (project accounting in the GL)
• Dual purpose segments (like one segment for both product and department)
• Think you can change the COA after go-live: you cannot

Subledger reporting segments are often driven by the requirement for global reporting on subledger data where the use of the GL and consolidations could provide this.

However implications are huge ranging from simple performance problems to feeble attempts to maintain a customer hierarchy in the GL.

Keep in mind the GL is for financial reporting and not for subledger reporting.

By putting subledger reporting in the GL you will also implicit impose limitations of the GL on your subledger which can cause unintended problems like need for custom segment validation and worst case will limit your business as your subledger reporting needs cannot be accomplished in the GL.

In very rare cases combined purpose segments can be justified but the values must be mutual exclusive as any overlapping will cause problems and is in fact a need for an additional segment.

An Example

Most mid to large scale business could have a structure like this:

• Company (Balancing)
• Department (Cost Center)
• Account (Natural Account)
• Analysis 1
• Analysis 2
• Intercompany (same segment values as Company)

Company, Department and Account segments are self explanatory.

Company and Account is for legal reporting.

Account, Department, Analysis 1 and 2 is used to support management reporting requirements.

Note there is a dual purpose for the Account segment in both legal and management reporting and sometimes this is remedied by adding a separate sub-account segment for the sole purpose of management reporting.

The intercompany segment is used for tracking the source of an intercompany transaction.

Keep the analysis segments to a finite number of values so if any subledger information is to be contained within these use summary levels like product line, customer group and similar as these values are unlikely to change over time.

Technical and performance

Two tables are the focus for performance:

• GL_CODE_COMBINATIONS – stores unique segment values as a single unique value combination id: CCID
• GL_BALANCES – stores summarised GL journals for each CCID

GL_CODE_COMBINATIONS

The content of this table expands for every new segment value combination entered per COA:

So looking at the example above – if we have the following segments and number of segment values:

I’ve often been thinking it could be useful to have a script that could create a directory structure for me based on a text file and a simple windows batch script.

Well here it is…

The default input file name is dirs.txt:

;Comment
0 Project Name
1   Project Management
2     Plan
2     Issues
2     Resources
1   Deliverables
2     Configuration
3       Architecture
3       BR100s
3       MD50s
2     Development
3       MD70s
3       Source Code
2     Interfaces
3       Interface Strategy
2     Data Conversion
3       Data Conversion Strategy
2     Testing
3       Test Strategy
3       Test Script
;Comment again
1   Info
2     News
2     Contacts
2     Tools
2     This is a long dir name

The digit is the directory level – without this it is impossible to create a structure with a simple windows batch script.

The main script is makedirs.cmd:

@echo off
rem makedirs.cmd syntax:
rem %1 = target dir. default = current dir .
rem %2 = name of dir file. default = dirs.txt
setlocal ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
:ARG1
  set targetdir=.
  if not "%1" == "" set targetdir=%1
  if not exist %targetdir% goto NODIR
:ARG2
  set dirfile=dirs.txt
  if not "%2" == "" set dirfile=%2
  if not exist %dirfile% goto NOFILE
:MAIN
  set sourcedir=%cd%
  echo Creating dirs in %targetdir%
  for /f "eol=; tokens=1* delims= " %%i in (%dirfile%) do call makedir %%i "%%j"
goto XIT
:NODIR
  echo Directory %targetdir% does not exist
goto XIT
:NOFILE
  echo File %dirfile% does not exist
goto XIT
:XIT
  echo Done…

This script does not need any parameters if the input file is "dirs.txt" and the target directory is current dir. See rem lines above for syntax.

The makedirs.cmd calls makedir.cmd which creates a single dir:

@echo off
rem makedir.cmd syntax:
rem %1 = level
rem %2 = dirname
set level=%1
set dirname=%~2
if "%level%"=="0" goto LEVEL0
if not "%dirpath0%"=="" goto LEVELX
  rem special case where no 0 level line defined
  set dirpath0=%targetdir%
  rem done – now continue as normal
goto LEVELX
:LEVELX
  set /a above=%level%-1
  set dirpath=!dirpath%above%!
  set dirpath%level%=%dirpath%\%dirname%
  rem echo mkdir "!dirpath%level%!"
  mkdir "!dirpath%level%!"
goto XIT
:NOLEVEL0
  rem no level 0 line defined so use current dir as top
  set dirpath0=.
goto XIT
:LEVEL0
  rem level 0 line defined so set top as current plus dirname
  set dirpath0=%targetdir%\%dirname%
  rem echo mkdir "%dirpath0%"
  mkdir "%dirpath0%"
goto XIT
:XIT

This script is not meant to be used on its own.