Bryan Thompson - Oracle Consultant » General

Does Oracle provide approval capabilities?

bryan — Fri, 20 Feb 2009 03:19:46 +0000

Well, it depends. Generally speaking, Oracle provides capabilities to integrate approvals within your business process. However, depending on the module and transaction these capabilities can vary. As an Order to Cash expert, I want to bring some clarity to what the out-of-the-box approval capabilities are within the Quoting and Order Management modules, then go into some of the enhancements I’ve implemented in the past to improve the functionality in some of these areas.

Approvals in Quoting

You may have heard of Oracle’s Approval Management (AME) module. AME provides flexible, workflow-based approval capabilities and serves as a one-stop-shop for managing all fixed and dynamic approval hierarchies throughout Oracle EBS.

Lucky for you, the Quoting module is well integrated with AME functionality, allowing approval hierarchies to be dynamically built based on different types of transactional criteria such as operating unit, total quote amount, customer, etc. Base approval lists can be built manually or can be associated with SQL statements to dynamically generate hierarchies based on employee data. Quoting also provides security settings that allow skipping an approver in the hierarchy or bypassing the process entirely.

Needless to say, the tight integration between the Quoting and AME modules provides great out-of-the-box approval functionality that is likely to meet or exceed your business requirements.

Approvals in Order Management

I wish I could say the same about Order Management (OM). Unfortunately, there’s no out-of-the-box integration between OM and AME. Compared to Quoting, the approval capabilities are limited and inconsistent depending on what type of transaction you’re performing.

You’ve probably seen the Approver setups in the OM module by clicking on the “Approvals” button on the order type setup screen; however, these setups pertain only to Negotiations (OM’s version of quoting). The configuration gives the impression that approval lists can be built for Fulfillment type transactions (orders), but Oracle hasn’t implemented these capabilities into any of the generic OM workflows.

Another setback with Approver setups in OM is that they’re assigned and dedicated to a transaction type. This can cause issues if you have multiple facilities that each require their own set of approvers, but are under the same operating unit in Oracle and share the same set of order types. The only work-around for this is to create a separate set of transaction types for each facility, but this can get ugly. Additionally, the approval lists are fixed, sequential and do not provide any of the dynamic capabilities that are available in the AME module.

It gets worse for return transactions. The capabilities are limited to only allowing individual approvals and not approval hierarchies. The generic return workflows in OM refer to a profile option that allows storage for only one approver.

Approval Enhancements

As you can guess, most of the enhancements I’ve designed and implemented have been to compensate for the limited approval functionality in OM. Generally there are two approaches, each varying in complexity and produce different results.

As low-cost alternative with quick turnaround, I’ve provided enhancements to the seeded order and return workflows that incorporate the Approver setups in OM. I say “quick” because Oracle already provides the necessary nuts and bolts to easily “plug” in the approver functionality with minimal customization. Though the solution is low cost and quick, the functionality will still not provide all the capabilities of the AME module as I mentioned earlier. However, this may suit your business fine depending upon your requirements.

A fancier approach I’ve taken is to integrate OM with the Approvals AME module entirely. This way all the capabilities I spoke of earlier in the Quoting module are also made available to OM. From a technical standpoint it’s definitely more involved than the first enhancement I mentioned, but if your business requires the flexibility, it certainly can provide a great return on investment.

Setting Organization Context in Oracle R12

bryan — Wed, 04 Feb 2009 02:37:00 +0000

For those of you who are trying to set the organization context within your SQL sessions or custom programs, there’s a new API you must call in R12.

The previous way of setting organization context in 11i was to execute the following statement:

dbms_application_info.set_client_info(ORG_ID);

However, in R12, the new way of setting the organization context is as follows:

mo_global.init(’AR’);
mo_global.set_policy_context(’S',ORG_ID);

The â€˜S’ parameter indicates a single organization context. Replace ORG_ID with the ID of the operating unit you wish to use. You can also set a context for multiple operating units by setting the security profile. This is done by executing the following statement:

mo_global.set_org_access(NULL,SECURITY_PROFILE_ID,’ASO’);

Replace SECURITY_PROFILE_ID with the ID of the appropriate security profile. ‘ASO’ represents the application short name associated with the responsibility you’ll be using.

Process Transformation & Change Management

bryan — Fri, 19 Sep 2008 01:09:14 +0000

Whether you’re implementing a new system or simply changing office procedures, there are five core steps to successfully transforming your business process and implementing change.

Step 1 – Bringing Awareness

To effectively bring awareness, the objective is to influence the business users’:

Thinking – Helping them to understand the main objectives and the changes that may be needed to meet these objectives.
Feelings – Associating the concept of change with positive feelings. Communicating the overall change effort as a fun and interesting project, using all influences possible to prevent users assuming change is a negative.
Actions – Keeping people engaged and actively participating in the change effort. Though you cannot control one’s actions directly, your influence on their feelings has an impact on their actions.

Step 2 – Understanding Change and Committing

This phase deals with helping users to understand the specific changes that are coming and the reality of these changes. It’s important to enforce these changes through positive influence without causing any sharp resistance from the users. Effective listening and communication skills to ensure these changes are understood by all. During this phase, you must guide the user community through the decision making process on key business changes while setting expectations on the results and impacts of these decisions.

Step 3 – Preparation

Once the changes are defined and processes around these changes are established, business users that are impacted need preparation in the form of competency building, skill set training, and self-confidence. Through the preparation process there will be training sessions, proof of concepts, process testing, etc. This is all necessary to ensure that the business can operate in the new environment and that all details are reviewed, issues are exposed, and issues are resolved.

Step 4 – Launch

Once the business community is fully prepared and testing of the new process confirms satisfactory results, it’s time to bring the new process alive. Prior to enabling the new process, the project and user communities must be fully confident and ready for the launch and the short-term support required. As the new process lives, adaptations may be needed to address the immediate issues and process short comings.

Step 5 – Discipline and Enforcement

After brining alive the new process, the next step is to make sure the establish procedures are being followed by the user community. This is accomplished through positive recognition when a user excels at their new role while also holding users accountable by upper management when procedures are not followed. Emphasis should be placed on following the new process throughout the process transformation lifecycle.

Cutting Implementation Costs by Leveraging Your Internal IT Resources

bryan — Thu, 05 Jun 2008 02:27:56 +0000

Consultants – can’t live with them, can’t live without them. Majority of today’s software implementations require the need for outside consultants for their technology and industry expertise, but the costs of outside consulting can be a hard pill for top executives to swallow. Engaging consulting experts is a necessary evil in ensuring a successful implementation of your ERP system; however, by outsourcing the design process and leveraging your internal IT resources for testing and implementation, you can effectively utilize the strengths of both factions while lowering your outside consulting costs.

But doing this isn’t as simple as saying good bye to your consultants once process design is complete. Extra steps must be taken by project management to ensure that your internal IT staff are connected and engaged throughout gap analysis, requirements gathering, and process design. If your IT organization is to “take the ball and run”, it’s extremely important that they understand the design and can speak for it long after the consultants have left.

In addition to keeping your resources engaged, they must also be trained or have the experience necessary in carrying out the implementation. An investment in training will better prepare your staff for the implementation activities, while also leading to decreased consulting costs further along the project timeline (not to mention minimizing needs for consulting in future projects). So be ready to supplement some of your cost savings in consulting with additional funding towards training.

Also be ready to conduct a focused knowledge transfer session once gap analysis and process design is complete. It’s obvious that your internal resources will need all the knowledge and know-how to implement the solutions proposed by your outside consultants, so it’s important to execute a formal knowledge transfer session that involves transition of all documentation and related materials. Project metrics should be established that measures the progress and success of the knowledge transfer activities.

By following all these points, you place your IT organization in a position to implement your ERP system independently without extensive involvement of any outside consulting. Keep in mind that while this approach will most definitely minimize the need for any consulting involvement during implementation, it doesn’t eliminate the need. Therefore, it’s important to have a go forward plan established the keeps the lines of communication open between your IT organization and the consultants.

Outsourcing design and insourcing implementation efforts is a model that many businesses, and even some consulting organizations, have embraced. Lexerd Group, an IT consulting firm based in the east coast United States, is one of the first to offer services that are centered on the “outsourcing/insourcing” model. Lexerd Group’s Proof of Concept service offers their clients software expertise, requirements gathering, gap analysis, and solution design, followed by a specialized transition session which transfers process blueprints and a go-forward implementation strategy to their clients.

Read more about Lexerd Group’s unique Proof of Concept consulting services at http://www.lexerdgroup.com/proof-of-concept.

Download Oracle AIM (Applications Implementation Methodology) Software

bryan — Tue, 06 May 2008 14:17:42 +0000

Oracle’s Application Implementation Methodology is the “industry standard” for Oracle project management and implementation strategy. The main feature of the AIM software is the documentation templates that are available. I typically do not use all available templates, but there a few key documents such as the BR100, MD50, etc. that are handy.

Most Oracle consulting firms do not use AIM as is, but use it as a basis in coming up with their own implementation methodology. Either way, it’s a great tool to keep handy.

Click here to download the entire AIM package.

If you happen to need an AIM document template but don’t necessarily need the entire package, you can select a template for download below.

There’s More to Outsourcing than Just Cutting Costs

bryan — Mon, 21 Jan 2008 23:08:05 +0000

These days it’s standard practice for American based companies implementing software systems to send technical development overseas to countries like India, Singapore, and China. If you walk around the corner of your office, you may find a small offshore team crammed into a cubical gathering and reviewing technical requirements to be distributed to resources located on the other side of the world. In almost all cases, the outsourcing model is adopted in an effort to cut down on development costs. On the surface it makes sense – why pay a US based contractor the high salary when an offshore resource can perform the same work for a fraction of the cost? Several years ago, many IT executives considered this question to be a no-brainer and would have immediately adopted the offshore model. But while all their concentration was focused on cutting costs, project managers neglected other important variables in the offshore equation, and

as a result there have been few successes and far too many failures in adopting the outsourcing model within the IT industry. If you’re an executive evaluating the cost benefits of the offshore model, there are other factors to take into consideration.

For starters, you must evaluate the skills and expertise that is required from the technical resources that are needed. Generally speaking, most offshore developers I’ve worked with have an outstanding technical background. They know and understand database architecture, coding standards and syntax, and have an expertise in the many software tools that are necessary to get the job done. Irrespective of citizenship or other factors, these skill sets alone are great for development work on small, independent software systems where there are minimal dependencies. Some examples of an independent software environment could be:

A small to mid-size business running a custom-built, homegrown system.
A standalone software system used to collect and report on transactions specific to a department and/or sub-division.

If your software system fits this profile, than an offshore resource could most certainly meet your needs.

Where additional precaution is needed is in the implementation of a company-wide ERP system. When doing any kind of customizing to an enterprise software application, it’s critical that the technical resources you seek not only have sound technical skill sets, but also a strong functional understanding of the application. The technical resource at minimum should know:

How the application module was designed to work out-of-the-box.
The inter-dependencies of the modules. In other words, how a particular module fits into the entire application framework.
The adverse affects of changing module design based on these inter-dependencies.

Now I’m willing to admit that it’s unrealistic to expect a technical guru to write complex code all while he or she is reciting the user documentation, but general functional knowledge is a definite requirement to ensure that you’re project staff and offshore resources can communicate on the same wavelength.

I’ve observed that the services provided by an offshore outfit are usually sound from a technical standpoint. However, from a functional standpoint, the level of expertise is up for debate. When first introduced to the model, many experts (including myself) had the expectation that the technical resources provided would have some degree of functional knowledge of the respective system. This expectation often led to a major misunderstanding of what an offshore outfit is able to offer. What was thought to be a team of techno-functional resources turned out to be a team of highly skilled coders with less than desirable knowledge of the application.

Anyone who has worked in the ERP world knows that communication is key to running an effective software implementation project. If this line of communication breaks, a rippling effect is sent throughout the entire team – placing the quality of work and the success of the project at risk. If the project staff and the outsourcing group do not have the same collective understanding of the functional requirements, a severe breakdown in communication between these groups occurs and results in technical objects not being delivered according to the communicated (or understood) specification. I like to call this the Techno-Functional Gap, and without a doubt, it is the main reason why the outsourcing model has failed.

Before making the decision to go offshore, it’s extremely import to consider how the techno-functional gap will be bridged among your project staff and the offshore resources. Ultimately what you want to avoid is a purely functional consultant with no technical background writing design specifications for an offshore programmer without any functional knowledge of the application. Both resources may have their respective strengths, but if a common understanding cannot be met, there’s an increased risk of the requirements being poorly communicated by your staff or misunderstood by the outsourcing group.

An easy way to measure this risk is to first evaluate the skill sets of your current staff. Depending on how weak or strong the technical background of your staff is determines the kind of functional background that’s needed from your offshore resources. By building a skill set matrix which rates your staff’s functional and technical strengths, your organizational needs become more clear. So for example:

	Module	Functional Rating	Technical Rating
Resource #1	Finance	9 – Strong	7 – Above Average
Resource #2	Sales	10 – Strong	1 – Poor

In the above chart I took two example project resources: one from the sales team and one from the finance team. I then attempted to rate each of their functional and technical skill sets on a scale of 1 to 10, where 10 indicates strong knowledge and 1 represents little to none.

Looking at this chart, we see our finance resource has a very strong functional background with above-average technical skills. Therefore, we may be able to settle for an offshore resource with minimal functional skill sets. On the other hand, we see that our sales consultant has a strong functional background, but has no technical experience. With no technical background, we must be cautious in our choice of offshore developers to pair up with our sales resource. For this resource, it would be wise to find a developer that has average to strong functional knowledge of the system.

This is a very basic example, but it shows how effective this technique can be in ensuring that the project staff is paired up with the appropriate outsourcing resources.

For complicated or critical custom components that will be vital to your business process, I would suggest pairing up resources that have overlapping techno-functional skills. Matching resources with overlapping skill sets will ensure a seamless communication of requirements and effective coordination in testing the complexities of the customization. Simply put, for high-risk technical objects, it’s better to over-communicate than to under-communicate.

In addition to skill set pairing, I would also make sure that a collaborative work environment is put in place so that the project team and outsourcing groups can seamlessly share, distribute, and organize project deliverables amongst each other.

In the past, I’ve seen many clients allow the outsourcing partner to take full responsibility in managing and versioning all deliverables, from documentation to technical objects, as way a way to reduce overhead and take advantage of the cost effective labor. However, like the skill set gap, the collaboration gap creates another disconnect between the developers and the project staff. This led to the internal team having several issues with:

Assessing documentation and other deliverables.

Identifying the state of the test environments and knowing which instance had the code ready for testing.
Identifying code versions and knowing which version of the code they were testing.

These uncertainties usually led to the project team managing their own versions of the documentation and code. Then, as you would suspect, this led to confusion among both groups as to who had the latest version.

Remember, having an offshore group isn’t just about assigning technical development to a separate group sitting at a 14 hour plan ride away; it’s about assigning the project team and the outsourcing group joint responsibility to meet the requirements outlined by the business. It’s a collaborative effort – and being this is a collaborative effort, it’s important to provide the work environment necessary for both groups to work as a single, integrated unit.

It’s important to ensure that some kind of tool or shared network space is in place so that all information associated with the offshore efforts is easily accessible to your staff and the outsourcing partner. There are many tools out there to help streamline the collaborative process. From my past experience, Microsoft SharePoint has proven to be a great tool that allows you to organize your deliverables by team, milestone, etc. through an easy to use web interface. The application allows you to grant access to members of the project so that documents are controlled both from a rights and versioning standpoint. Now I’m only using SharePoint as an example and I’m not trying to sell you the application. However, whatever tool you choose to implement, it’s important that everyone from the team has access to this collaborative workspace and follows all organizational and versioning policies instituted within the team.

So far I’ve discussed the importance of establishing open communication and a collaborative work environment between your staff and the outsourcing partner to minimize the immediate risks, which are misinterpreted requirements and poorly designed custom objects leading to failures within the project and exposed risks to the business if implemented. But in addition to the immediate risks, the long term (or post project) risks also need to be evaluated. Remember, in most cases, the point of bringing on an outsourcing partner is to utilize their resources for the short-term. Once the implementation project is completed, the idea is to relieve the offshore resources and allow your internal project staff to continue supporting the system.

However, if clear communication and group collaboration is not in place, then you may want to extend that contract with your outsourcing partner for much longer than you originally anticipated. If you’re internal staff is not up-to-speed with the work performed by the offshore team, than your group will not be able to effectively support any customizations to the system without the involvement of the outsourcing partner. Too many times in my career have I seen outsourcing contracts extended not because delays to the project schedule, but because the client was not prepared to take on the responsibilities of supporting and maintaining the system.

So in addition to communication and collaboration, a knowledge transfer plan needs to be in place to ensure that your staff is given the information and tools necessary to continue supporting the work delivered by your offshore resources. Do not make this effort secondary to all other activities that may appear to take higher priority. This should be a dedicated phase within your project schedule and should be accounted for in the budget. The less time you set aside for knowledge transfer, the more time you will most likely need to sign up for offshore support. Also keep in mind that the more integrated your project team and the outsourcing partner become, the less time it should take to transfer knowledge. On the flip side, if the work of the outsourcing group was performed independently with no interaction with your staff, then knowledge transfer will most likely be a nightmare.

Like anything in business, it’s not just about cutting costs, but being able to cut costs without sacrificing the quality of work or exposing your organization to potential risk. Outsourcing can be a working, efficient component of your ERP project team so long as the appropriate offshore resources are paired with your staff, the lines of communication are open, and an environment is provided to promote group collaboration. When evaluating your offshore options, make sure to take all these factors into consideration. You may find that the cost risk or the overhead in building an integrated environment may far exceed hiring some permanent hands. Most importantly, it’s important that your IT organization practices what you preach. In other words, do not expect to bring your business into an integrated EPR system environment if your project organization cannot operate as an integrated entity itself.

IE 7 and IBM Password Manager Software Conflicts with JInitiator

bryan — Thu, 23 Aug 2007 21:52:06 +0000

I recently bought a Lenovo IBM ThinkPad T61 notebook pre-installed with Windows XP SP2, Internet Explorer 7, Office 2007, and all the other IBM software bells and whistles. So far I’ve been quite happy with my purchase, however, I was disappointed to find several issues with IE and IBM factory software that caused my Internet Explorer session to crash when attempting to launch Oracle JInitiator. Upon clicking an apps link I get the infamous “Internet Explorer has encountered a problem and needs to close” error.

What good is a new laptop if I can’t use the tools to do my job!

Fortunately, after hours of tweaking, I was able to narrow down the root cause to two main issues:

Internet Explorer 7 Quick Tabs Conflict

The new Quick Tabs introduced in IE 7 do not play well with many Java-based applications – one of them being JInitiator. After my IE sessions continued to crash, I began randomly playing with the IE view settings and found that disabling the Quick Tabs bar solved the problem. To disable Quick Tabs, open an Internet Explorer 7 session and navigate to View > Quick Tabs.

After disabling Quick Tabs, close your browser session and start a new one. Assuming this is your only software conflict, this should do the trick. Unlessâ€¦

ThinkPad Security Solution Conflict

Lenovo offers the ThinkVantage Productivity Center with all their notebooks. One of the neat features of the Productivity Center is the Client Security Solution. Not only does this solution allow

you to store passwords to all your applications and websites safely and securely, but it auto-logs into the apps for you too. Couple this with the new finger print reader and you have an amazingly effective, yet secure, password manager.

Unfortunately, an IE 7 add-on that the Client Security Solution uses to capture and store Internet based login information conflicts with JInitiator. The only apparent fix for this is to disable the Password Manager feature of the Client Security Solution entirely.

To do this, click the big blue ThinkVantage button on your notebook – the Productivity Center menu will appear.

Next, hover over ThinkVantage Technologies, then select Client Security Solution – the solution menu window will appear. Click the Password Manager and you should see a screen like this:

Clicking the “Disable” button will shutdown the manager.

Next, we need to disable the IE 7 add-ons that were installed by the Client Security Solution. To do this, open an IE 7 session and navigate to Tools > Manage Add-ons > Enable or Disable Add-ons. The Manage Add-ons window will appear.

In the manager you will notice two Lenovo-based add-ons:

CPwmIEBrowserHelper Object
ThinkVantage Password Manager

Select each of these add-ons and click the “Disable” radio button below so that both add-ons show up under the “Disabled” list as such:

Once you’ve finished, click OK, close all of your applications, and restart your notebook. After you log back into Windows, open an Internet Explorer session and try logging back into Oracle Apps. Again, assuming there are no other software conflicts with JInitiator, this should do the trick.

It’s unfortunate that all the features of IE 7 and ThinkVantage can’t be fully utilized, but like all initial software release, these kind of bugs usually happen and eventually get resolved through patches, upgrades, etc. Maybe Windows, Oracle and IBM can collectively provide a fix so that all three applications can play nicely together.

Did I just write that?

Need Free Access to an Oracle Vision Instance?

bryan — Wed, 18 Jul 2007 01:54:33 +0000

Solution Beacon, a technology resource provider and certified Oracle partner, provides free public access to Oracle 11i and R12 instances. To request access, simply fill out the registration forms below. An email will be sent with your login information.

Solution Beacon 11.5.10.2 Registration Form

Solution Beacon Release 12 Registration Form

AppsHosting, a provider of managed hosting solutions and disaster recovery services, also provides free Oracle Vision access. Click the registration form below and an email will be sent with your account information.

AppsHosting 11.5.10.2 Registration Form

Enjoy!

Letting Your Business Process Drive Financial Reporting

bryan — Fri, 09 Mar 2007 18:19:46 +0000

Establishing an integrated business process is one thing – tailoring this process so that the financial results make sense to the organization is another.

There’s no doubt that one of the most difficult aspects of implementing a system is crafting an efficient, integrated process that works with the business, all while making sure this process can produce the financial reporting that is key to the accounting organization and top-management. Many times we find ourselves in a situation where we find a process that works, but because the system cannot post the detailed financial transactions needed, we’re forced to revisit our design. Unfortunately this situation can lead us into a routine of:

1.) Making customizations or adjustments to the business process so thatâ€¦
2.) Detailed financial transactions can be posted to the general ledger so thatâ€¦
3.) Financial reporting can be driven directly from a central set of books so thatâ€¦
4.) Finance is happy.

On a past project I was involved with a client who, in order to differentiate the accounting between their internal and external sales, wanted their users to manually classify sales orders based on the criteria of the sale. For example, if a sale was made internally within the organization for product that was to be used for experimentation, display, or routing, a classification would be entered by the user to label it as an internal order. If the sale was to a direct client, then the transaction would be classified as an external sale. By classifying their sales, finance would be able to drive their accounting to produce the internal and external reporting needed to support the business.

This requirement isn’t out of the ordinary – and neither is the approach. Many clients, like this one in particular, go about implementing an approach that relies on the users performing an additional decision step in order to capture or generate the necessary financial information. There’s no doubt that this process can work, but you’ve just put your financial reporting directly into the hands of your

users. In this case, placing a decision point at the time of order entry can be very susceptible to errors because of the high volumes of transactions. As the risk of user error increases, so does the risk of corrupting your financial data.

On another engagement I worked with a client who wanted to be able to reflect revenue recognition directly from the general ledger based on the shipment terms established with their customers. So for example, if terms were established with the customer that agreed to transfer the ownership of the delivered goods when the shipment arrived at the end location, an additional step in the process would performed by the user to trigger the revenue recognition transactions when the shipment reached its destination. Likewise, if terms were established to transfer ownership when the goods were made available to the client, meaning that the goods are packaged and ready for pick up by the carrier, then the interface step could possibly be performed well before any shipment activity occurred.

By incorporating this additional step into the process, the client would be able to successfully post the revenue recognition transactions, but like the first case, they are also relying heavily on the users to perform this step. Timing of when this step is performed is also an issue because of the various possibilities of when product ownership can be transferred, thus, you’re also dependent on this activity being accurate in accordance with the shipping terms.

As you can see from these examples, generating financial transactions to drive reporting tends to be the common approach. For the finance organization, success tends to be defined by creating a set of books, or if you will, a central data source, that can provide the quarterly, annual, and on-demand reporting needed to measure the organization’s financial success. Most organizations are willing to make sacrifices in other business processes or put in hefty customizations to meet this goal. And while they’re conscious of the amount of overhead added to these processes, they view it as a sacrifice in the ultimate goal of obtaining a detailed set of books.

In consulting there’s a fundamental rule I like to follow:

When possible, do not modify a working business process to meet reporting requirements.

Why mess up a good thing? Rather than looking first to modify or customize the process to generate detailed financial transactions, look at the transactional data you have at hand.

Let’s take a step back and look at the first case I mentioned. The client was looking to add a step in the order entry process to classify the types of sales transactions. If we went about this process without the classification step and entered two sales orders, the first being an external order, the second being an internal, how could we distinguish these two orders? If we look at the customer data – the first order would be placed with a client considered to be outside of the organization, the second would be placed with another branch or location of the company. So essentially, by looking at the customer, we can distinguish between an internal and external sale without classifying the sale.

This was a simple example, but hopefully you get the idea. By looking at the transactional data elements, we were able to derive from that the information needed to report on internal/external sales without having to modify the process. Granted, we are still dependent upon the user to classify the customer as an internal or external entity, but then this leads to the next rule I like to follow:

If additional information needs to be captured, capture it at a point where the least amount of transactional activity occurs.

In this case, the volume of setting up a new customer in the system is far less than the client’s sales order volume, so it’s less prone to human error. Additionally, since the volumes are low, more controls can be put in place to ensure a label is placed on a customer indicating internal or external without slowing down the business.

Now let’s revisit the revenue recognition case. In this example, the client was looking to post financial transactions to reflect revenue recognition based on the terms of shipment by adding a user-initiated interface step. Again, this is a very high-risk approach because your dependent upon the user getting it right every time to reflect accurate revenue recognition.

If we stay in the mind-set of “matching our books to our reporting”, another solution could be to customize this process so that it interfaces to the general ledger automatically based on the captured shipping terms and the status of the corresponding shipment. This definitely could be a more reliable solution since you’ve removed the human element out of it, but this also violates another rule I like to follow:

If you are generating transactions based on the criteria of other transactions – chances are that you do not need these transactions.

What does this mean? If you are generating transactional data for reporting that is based on the criteria of already existing information, why create more transactions that in the end will replicate the same information? I’ve just upset many accountants by saying this, because what I’m saying from a reporting prospective is that there isn’t a need to post detailed financial transactions to your general ledger based on transactional information, but instead the transactional data can be referred to in your financial reports. By keeping a general, more broader set of books and referring to the transactional data for details, you’ve accomplished your end-goal of generating a detailed financial reporting, all while leaving your process intact.

From a technology prospective, by tying your transactional data together to formulate your reports, you’ve downsized your reconciliation efforts and minimized the risk of a data mismatch occurring between your financial data and your actual transactions. Even more good news – you’ve just cut the amount of reoccurring transactions in half, and depending upon your transactional volume, this could mean less hardware to support your infrastructure.

Many technologists would argue that we’ve simply shifted the burden from the process consultants to the technical resources that develop these financial reports. Rather than having a single set of books to obtain the detailed financial data, the developer will instead have to scan across several information sources in the database. This is true to an extent, but while you’ve increased your report writing efforts, you’ve eliminated the need to modify or customize the business process to generate additional financial transactions. Instead of it being a two step approach of customizing your process and writing developing your reports, it now becomes a single step approach that goes directly to report development.

This strategy exemplifies the true benefit of having a relational database: being able to refer to different sources of information, making the relationships, and putting it all together so that it makes sense on paper. I believe many organizations continue the approach of maintaining separate, yet equivalent sets of information because it’s what we’ve been doing for decades. Never before had we been given the ability to have one integrated system where the information can be made available to us. For years many technologists have been dealing with the “quilt” of information systems and making sure that transactions in one system are accurate and accessible to the other. This mind set continues today despite the capabilities available to us in an integrated, relational database system. This “old school” approach has got to go!

When all is said and done, designing a process focused on streamlining the business and relying on the reports to derive the financial information from the resulting transactions is the most optimal approach. By following this methodology you’re guaranteed minimal disruption to the business and the most accurate financial reporting.

As a process consultant, I’ve had exposure to finance, but would not consider myself an expert in accounting. If you are an expert, I’d greatly appreciate any comments/feedback you may have!

Functionality Changes to Value Sets Introduced in 11i.ATG_PF.H Rollup 4

bryan — Mon, 15 Jan 2007 21:33:12 +0000

The latest Oracle Applications Technology rollup patch released in November 2006 introduces a multitude of fixes and enhancements to core ATG modules (FND, OAM, OWF, FWK, JTT, JTA, TXK, XDO, ECX, EC, AK, ALR, and UMX). The most notable, according to Metalink note 365228.1, are the enhancements to document attachments, Personalizations, and Workflow.

However, I discovered that after the application of Rollup 4 that the behavior of some of my custom value sets had changed. Any table-validated value sets that make any form field references, such as :BLOCK.FIELD, were no longer functional. This was quite a painful discovery for me as I had many value sets that were dependent upon this functionality.

According to several posts on Metalink, other clients had discovered this issue as well but on dates just prior to the release of 11i.ATG_PF.H Rollup 4. So this may have been caused by a one-off patch that was introduced earlier but later included in the Rollup 4 package.

The ability to use :BLOCK.FIELD references in table-validated value sets was removed by Oracle development because this feature isn’t consistent with the future direction of Oracle applications. Rumor has it that in the somewhat near future the application will be entirely HTML based and will be gradually introduced as Oracle works towards its full release of Fusion products. While their intentions to remove

this functionality were good (I guess), this doesn’t help people like me who have already delivered solutions using this functionality and now have to come up with another approach.

But thankfully there’s a work-around. Although :BLOCK.FIELD references cannot be used, the use of :$FLEX$.SEGMENT is still available. So instead of referring directly to the form field value, you can create another hidden flexfield segment that has a default type of “Field”. Then you can specify a default value of :BLOCK.FIELD. Once you’ve created the segment you can alter your value set criteria to refer to the :$FLEX$.SEGMENT which will have the :BLOCK.FIELD value defaulted.

Although it’s not as easy as making direct references to the form field itself, I’ve been able to successfully implement this work-around. The downside of course is that you’re using up more of those valuable descriptive flexfield segments. But it’s either that or the Oracle recommended approach….which is to refrain from using field references entirely.