Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

Main

March 22, 2017

***Chart of Account (COA) Design Considerations***

Chart of Account (COA) structure is the heart of an ERP implementation enabling business to exercise its day to day operations. This has very influence on how an organization wants to record monetary, contingent and statistical impact of different transactions taking place across the line of businesses, report it out to external entities to fulfil regulatory and statutory requirements, leverage it internally to gain insight on performance of different departments on both top and bottom lines. In order to be able to embark efficiently on these essentially require a modern chart of account mapped to different business modalities and dimensions that does not only takes care regular requirements as said but helps facilitate automation, rein in need of creating duplicate segment value pool, one segment does not override others i.e. maintains uniqueness of purpose mapped to each segment etc. Investing enough to lay down the foundation of COA structure would be the first step to lock down a successful ERP implementation and to drive innovation for businesses throughout the life of application. Note: Combination of segments (e.g. Company, Department/Cost Centre, Account etc.) forms a Chart of Account.

There are numerous essential characteristics including, but not limited to, below 5 that must be considered while designing COA structure:

Selection of business modalities/dimensions as segments of COA:

The selection of modalities as segments is not an objective matter but a very subjective in nature. While some are mandatory one irrespective of everything and anything but some are invariably vary based on types of industries, organizations and products or services offered, geographies where businesses have its operations, internal and external reporting needs, future considerations and volume of inter or intra company transactions etc. Each one of these are key drivers to design an idealistic, futuristic and holistic chart of account. For an example, manufacturing organizations may want to consider cost type as a segment to represent say fixed and variable cost in order to better assess contribution margin at the product level. They may look at a segment exposing sales destination location of a product to clearly articulate the strategy for multi-fold growth in determined geographies. In banking industry, companies may choose to introduce reference to a relationship manager/cost centre in order to measure performance at product portfolio level. In retail industry, looking at product categories instead of individual product can be the favourable option.

One segment should not override or make other ones redundant:

This is one of the vital discussion points while designing a COA structure in any ERP systems. While a thought leadership on this can offer long term benefits to organizations in account of easier maintenance, minimal master value pool for each segment, no duplication etc. On the other hand immature decisions, however, may erode the benefits eventually. A COA structure and value set for each segment should intelligently be designed in such a way that one segment does not make other one redundant, does not enforce introduction of similar type of values for a segment and most importantly they must be structured "relative" to each other. To understand it better, let's take an example of a COA structure that has 4 segments called Company, Cost Centre/Department, Natural account and Sub-Account. There are 3 companies COMP1, COMP2 and COMP3 and each company operates with its 4 own departments as Sales, IT, Purchase and Inventory. As a strategic and sustainable approach, a) one would recommend only 4 different cost centre value sets representing each of the 4 departments. These 4 can be associated with either of the 3 companies while actual transactions are taking place. On the other side as a poor design, b) organization can undoubtedly be enforced to introduce 12 different cost centre codes representing 4 departments working for 3 different companies. It is self-evident that option "a" firstly cascades the behaviour of relativity where Cost Centre is relative to a company and thereby does not lead to a redundancy and secondly avoids creation of duplicate codes for similar type of departments. This can further be well understood with postal code numbering system where it navigates through State, District and finally City. Here City is relative to a District and a District itself relative to a State for a given country. In regards to option "b", shortcomings are clearly countable as creation of duplicate codes while departments are of similar nature for each company, can't share segment values, certain to experience huge volume of cost centre values over the period of time etc.

Automation for Intra/Inter Company Transactions:

Organizations like GE who has leading business presence almost all over the world deal with huge volume of transactions b/t two or more internal business units. Transactions taking place b/t 2 business units ideally lead to inter/intra company transactions and that is where it is essential to consider a placeholder for inter/intra company segment in the COA in order to efficiently track referencing inter/intra company and enable opportunities for automation. ERPs like Oracle Application R12/Fusion Cloud offers an automation to create inter/intra company accounting entries by introducing pre-configured rules. For example, Oracle Fusion Financials automatically creates Intercompany Payable accounting entry corresponding to the Intercompany Receivable inter/intra company accounting entry by looking at the rules. Such entries have a counterparty reference in the COA code combination as in company (balancing segment) and designated inter/intra company segment.

Give meaning to each digit/character within a segment rather than just treat as code:

While a business meaning is tagged to each segment, a COA design can further be advanced by injecting an appropriate meaning to digits or characters within a segment. For example instead of just coding a company as COMP1 with no meaning to individual or set of characters, one can strongly advocate for "013060" where first 2 digits represents Country, next 2 region and last 2 State. Such logical combination may take away the need of an individual segment in a COA to signify location. This is additionally very helpful for easy reference.

Business Rules With Valid COA Code Combinations:

In regular business practice while creating different transactions, allowing only valid COA code combinations is usually the core business requirements. For example, although a COA code combination with Cash Account does not require any specific product code however the same would be needed while booking revenue. Thus, identification of such scenarios and implementing rules accordingly in the system is the key to rein in undesired code combination values.

Oracle Financial Accounting Hub (FAH) - A True Value Enabler

For any business organizations, recording accountings for its different transactions taking place with internal or external entities is an obvious objective. It is essential to measure the overall performance of the organization, gain insight to penetrate the new markets and to control cost expenses, fulfil the statutory and regulatory reporting requirements and so on. To efficiently support all these any modern organizations need a reliable, scalable, centralized fulfilling global and local accounting requirements, quick enough to implement a change and importantly economical solution. The answer is Financial Account Hub (FAH) and embarking on it is a first step to plant a foundation for innovation. FAH is an intuitive accounting engine that consumes business transactions' attributes interfaced from legacy systems, apply the accounting rules and mapping to eventually create accounting entries. For a better reference and understanding, it is similar to Sub-Ledger Accounting (SLA). While SLA is an accounting processor for business transactions originated from different sub-ledgers like AR, FA and AP etc within Oracle ERP, FAH is to deal with transactions originated from legacy systems and interfaced to Oracle ERP. Here are the 5 key value enablers that innately help drive organizations to inject FAH in their accounting solution footprint:

 

Centralized Accounting Solution:

In a traditional approach, consider a scenario where accounting entries are created for 10 different types of business transactions in 10 different front-office systems and finally interface it to Oracle where general ledger operation is supervised. This apparently counts some of the inefficiencies like:

a) Maintaining business accounting rules in 10 different systems

b) Requiring multiple resources with different product specific skills to implement accounting solution, change and support.

c) Lack of governance and control over accounting

d) Lost opportunity of reusing different components e.g. mappings and common accounting rules.

e) Have to invest on front-office applications for something which they don't primarily mean to do.

To overcome all these, FAH is one of the best options that offers centralized accounting engine empowers organizations cultivating a strategic roadmap to consolidate the accounting solutions lying at different places to just one at enterprise level.

 

Quicker and easier implementation:

Unlike Oracle EBS 11i and prior lower versions, both Oracle EBS and Oracle ERP Cloud offer front-end configurable capabilities to mimic business accounting rules on FAH setup components to eventually derive accounting entries for interfaced business transactions. Configurations are simply divided into logical groups likes Accounting Derivation rules, Journal Line Type rules (Dr and Cr) and optionally line/header descriptions rolling up starting from transaction, application, accounting method and finally to ledger. All these are configured corresponding to its relevant entity, event type and class model. An accounting solution for an interface can be ready in one month or so. 

 

Minimize dependencies on IT teams for maintenance:

Unlike custom accounting solution, most ongoing maintenance requests like capturing additional details to the journal line description can easily be achieved without even involving developer and a code change. Consider another scenario where there is a regulatory requirement to book asset expenditure to expense account instead of asset account for certain asset categories. Unlike in traditional back-end accounting engines where a medium size IT project may require, FAH can deliver it to business as part of the BAU processes without involving IT teams and notably in a quicker, easier and cheaper manner. In this particular case, accounting derivation rule will require a change to accommodate expense account for certain asset categories.

 

Capability to handle exceptions and complex mapping/rules:

While FAH is capable of handling most of accounting requirements with out-of-the-box configurable features, it also provides a powerful custom source concept where you can code your own accounting logic and link it to a custom source available for use in FAH. Consider a scenario where you want to derive BSV (balancing segment value) of COA based on the complex mapping and exceptions, a custom source can be defined for the same linked to a custom s/w code. FAH invokes the custom source at run time while interface processing to derive the BSV based on the logic coded in the custom s/w program.

 

Cost avoidance:

With FAH is in place for interface processing, organizations can avoid multiple licensing cost by eliminating the need of licenses for all front-office applications having its own accounting engine. It naturally avoids the salary costs needing for product SMEs with different skills set related to core legacy systems.

 Thus, FAH is categorically a strategic accounting hub be it Oracle EBS or Oracle ERP Cloud that offers agility extensively enabling modern organizations gain radical benefits of faster responsiveness to the regulatory and statutory accounting requirements, cost effectiveness, and importantly consolidation of accounting solution on a single platform.

September 16, 2016

 

Risk-based Monitoring: A New Paradigm in Clinical Trial Monitoring

In today's competitive environment, life sciences companies are under tremendous pressure to launch drugs faster and make them cheaper, without compromising on their quality. This requires a highly efficient and robust clinical trial monitoring process, as clinical trials are key to patient safety and drug discovery. However, this is currently a very time-consuming process and at times can go on for years before the drug is certified as fit for human use. Furthermore, site monitoring by deploying people at various trial sites is a time-consuming and expensive affair.

 

Risk-based monitoring (RBM) attempts to solve some of these problems. Drug authorities across the world have now given pharma companies the flexibility to decide the level of onsite monitoring required during a clinical trial. This means that pharma companies can now optimize the trial monitoring process and monitor trials centrally by leveraging a risk-based monitoring mechanism; that is, they can build a risk profile of the sites based on critical study parameters and determine the level of monitoring required for a particular site. This can help companies save a lot of money, develop drugs faster, and keep them affordable.

 

Information technology (IT) plays a pivotal role in supporting this process. Given the latest tools and techniques, it is very easy for pharma companies to sift through a lot of structured and unstructured data that can impact the trial process. With the usage of statistical modeling and machine learning techniques, it is now very easy to predict the risk quotient of a site where a trial will be conducted and thus decide the level of monitoring required.View image 

 

Infosys has built a risk-based monitoring solution using Oracle technologies that integrates with your existing data sources and applications to provide the desired outcome. It provides better returns to the clients, already using Oracle products, as they do not need to invest in product licenses.

 

Visit us at Oracle OpenWorld 2016 to know more about this solution.

September 16, 2013

Cloud Vs On Premise - Where do you go?

One of the most frequently asked questions by Enterprises all over the world today is - Should their Applications be on the Cloud or On-Premise?
My 3 part Blog series tries to answer this question by looking at various aspects of Cloud and On Premise solutions and then coming up with the best suited model as per Customer Business requirements.

In the first part of this blog series, we will be taking a deeper look into the features of both the Solutions.

Continue reading " Cloud Vs On Premise - Where do you go? " »

March 13, 2013

Green Insurance: Managing Risks of Going Green

One of the latest Buzzwords in the Insurance Industry is Green Insurance.Going green may be the demand of the day,

but doing so may not be an easy task and comes along with a whole lot of risks which need to be managed.

This also throws an opprotunity to Insurance providers to introduce new products and service offerings in the market.

Continue reading " Green Insurance: Managing Risks of Going Green " »

June 17, 2011

Oracle Documaker 12 - A feature rich product on the horizon

Since the acquisition of Skywire owned Document Automation Solution - Documaker, Oracle corp. has been trying hard to enrich the product suite in order to make it a more comprehensive and palpable solution for Insurance Carriers.

Recently Oracle introduced a new and improved version of Oracle Documaker. In the latest release, versioned 12, Oracle has introduced features that are more enterprise intensive and bridge some gaps from the earlier version of the product.

Continue reading " Oracle Documaker 12 - A feature rich product on the horizon " »

March 10, 2011

Social CRM in Insurance: A fly by..

Social CRM has been one of the top trends that have been witnessed in the CRM space in recent times. As per a study by Gartner Research, by 2013 the total investment in Social CRM space would exponentially increase to around 1 billion dollars, about 8% of the total CRM spending. In Social CRM the customer sits in center of the CRM processes and is an active influencer in business decisions. The customer and organization constantly interact and collaborate in order improve the customer experience. In return, the customer becomes an advocate of the organization highlighting the work done by the company. Social CRM is not just about bringing the customer in the center of the processes but it requires a change in the strategic outlook of the organization.

Continue reading " Social CRM in Insurance: A fly by.. " »

March 9, 2011

The Power Of Oracle Life Sciences Data Hub (LSH)

Guest post by
Nobendu Roy, Senior Project Manager, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

We know that LSH is a clinical data integration platform, but it can also be used as a computing environment that gives tremendous power and flexibility to a PLSQL programmer to extend the functionalities.

Continue reading " The Power Of Oracle Life Sciences Data Hub (LSH) " »

December 27, 2010

MES for Process Industries

What is MES ?

ERP (Enterprise Resource Planning) acts as central repository for all the data transacted, but there is no way of controlling the operations or passing the information between plant control system & ERP in integrated manner.

MES (Manufacturing execution systems) help in detailing the process and also controlling the operations through the systems. MES uses the data and provide results on the plant activities in minimal time. MES Collects the data from plant system, store them, and the output are used to control the functions in enhancing productivity and process on the whole.

MES for Oracle Process Manufacturing (OPM):

MES for Process Manufacturing adds new batch execution functionality and increases usability for manufacturing operators. 

Continue reading " MES for Process Industries " »

September 2, 2010

Critical points to be consider while "Asset Group" Design process for Successful eAM implementation

Generally Asset Group is new concept to most of companies switching over from legacy plant maintenance system to Oracle Enterprise Asset Management system, as in most of the legacy system it does not exists, they have Asset/Equipment numbers without Asset Groups, in Oracle eAM assets are created from Asset Groups only, so Asset Group is mandatory in Oracle eAM. This blog would explain the impact of Asset Groups in various places of the eAM application and help to expedite the Asset Group design process.

Continue reading " Critical points to be consider while "Asset Group" Design process for Successful eAM implementation " »

May 22, 2010

Go Lean: Minimize customizations and reduce overall TCO in Oracle ERP implementation (Part 3)

There are many ways to achieve Leaner ERP implementation, and I have discussed some of the strategic levers for it in my previous blogs Go Lean (Part 2) and Go Lean (Part 1) like senior management and executive sponsorship, robust decision making framework, effective change management approach, upfront planning for middleware and reporting platforms, solution design workshops, selection of appropriate edge products and leveraging localizations. However, there are many tactical and operational levers also available for enterprises to adopt, which are primarily part of implementation execution cycle. I am discussing here some of these levers and best practices to minimize customizations:

  • Boot Camp Trainings - Before initiating the solution design phase, organizations must seriously consider to conduct the boot camp trainings on chosen ERP to their key super users, business analysts and implementation core team, facilitated by System Integrator (SI). The intent for boot camps must be training to the team for vanilla features and functionalities of ERP relevant to their industry processes. This will enable them to bridge many gaps and requirements through seeded ERP functionality, and increase the overall fitment of the package application, leading towards reduced customizations.

Continue reading " Go Lean: Minimize customizations and reduce overall TCO in Oracle ERP implementation (Part 3) " »

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter