Part 1 - Rules, Integration, and Definitions of Functionality

 

Microsoft Word Compatibility for Contract Authoring and Negotiations In Ariba Contract Management, Assembled Documents are considered any Microsoft Word Document with an Outline View. Often these documents have references to the Clause Library, but not always.


This Knowledge Nugget is meant as a generic guide to the overall workings of the tool, and can be referenced for 9r1, as well as 10s2 and beyond. This document is being authored in the 10s2 timeframe, and as a result, the functionality and support levels in this document are subject to change. For example, Ariba might need to de-support an old version of Word, or add additional support for a new version. The intent of this document is to educate, and provide a set of “rules” which will help eliminate confusion that sometimes arises when dealing with something as complex as Ariba’s integration with Microsoft Word. This document is not meant to replace existing product documentation either from Ariba or from Microsoft, and this document assumes the reader is already familiar with all of the functions described.

 

Rules for Working with Microsoft Word in Ariba Contract Management

 

Here are a set of rules to help clarify things. To fully understand why these rules are in place, it is helpful to read the entire Knowledge Nugget. However, as the document gets technical in places, these are meant as a sort of cheat-sheet to the concepts set forth in the rest of the AKN. An “Author,” for the purposes of this document, is considered any user in Ariba Contract Management who updates, assembles, or generates an Assembled Document in Ariba.

 

Rule 1:
All Authors who touch a given document in a workspace (internal users) must use the same version of Microsoft Word.

 

Rule 2:
All Authors must have a higher version (or equal) of Microsoft Word than any external Suppliers/Customers participating in Negotiation Tasks. If all contract authors / users in Ariba Contract Management are using the latest supported version of Microsoft Word – currently Microsoft Word 2007 – no problems should occur for them, as they can successfully detect changes from Microsoft Word 2000, 2002, 2003, and 2007.

 

Rule 3:

The Clause Library and Templates must be built (and maintained) with a lower/equal version of Word than the version of Word used by an end user to create workspaces. This means that if you do a deployment on 2003, and then move ALL your users to 2007, you’ll be fine, and you will not need to modify the clause library.

 

Rule 4:
You must be deployed using the same version of Word as what all of your users are using. This is to say that if you as a customer of Ariba have standardized on 2003, you cannot be deployed by an Ariba Deployment Professional with 2007.

 

Rule 5:
Because of the API differences between 2003 and 2007 of Word, it is not supported to have two versions of Word on the same client machine.

 

How Ariba Integrates With Microsoft Word

 

Frequently, people make assumptions about how the Ariba integration works which can cause confusion and a set of expectations that might be misleading. This is meant as a primer on how Ariba functions with Microsoft Word. Additionally the language in this document is meant to explain, not to exactly describe the individual API calls. For example, though it isn’t technically correct to say “Ariba asks Microsoft,” those words are used to provide a more narrative description of the integration.

 

The first thing to understand about how Ariba works with Microsoft Word is that Ariba cannot open, or read Microsoft Documents itself. Ariba does not (and cannot) run Microsoft on the “server.” In technical terms, this means that Ariba retains no knowledge whatsoever about the binary Microsoft file itself. Ariba doesn’t “know” what version of Microsoft the document was created in, or its contents. The entire lifecycle of Ariba’s Microsoft Word integration is carried out using Microsoft supported API calls, on the client desktop, and mirrored in Ariba through versions.

 

For example, if you open a simple Microsoft Word file (with Desktop File Synch enabled), Ariba performs the following steps:

  1. Ariba asks the Client (desktop) to open Microsoft Word (whatever version the Client happens to have).
  2. Ariba checks to see if there is a copy of that document in the Client’s Desktop Vault, by looking in the location Ariba expects.
  3. Ariba asks the Client to provide it the time stamp for that document. If it matches the one currently on the server, Ariba asks the Client to open that file locally in Word.
  4. If the document isn’t found, or if it is an old version, Ariba sends the most recent version of that document (sometimes called the Server Copy) to the Client (copies it to the Desktop Vault, makes a note of the time stamp) and then has the Client open that document in Word (locally).
  5. Any changes that are made in the document are done completely on the Client/desktop side, and saved in the Desktop Vault Location.
  6. Ariba notices the time stamp has changed, and then updates its server copy with the current file.

 

Obviously, when Assembled Documents with clauses and document properties are involved, there are more steps, but the important thing to understand is that Ariba doesn’t actually know the content, or any content changes in the Word document. Ariba relies completely on Microsoft Word for updates, information, and changes. Put simply, the Client desktop tells Ariba everything. Now, before we go further with a discussion of nuances and issues with different versions, it is important to understand the reason behind Ariba’s design. It is technically possible to do everything on the server, and completely disassemble and merge all documents on the server, but because of the linkage with Word, it is impossible to get acceptable performance using that method. Ariba experimented with storing everything on the server years ago, and found quickly that it isn’t workable from a performance and ability perspective. Not only is it not feasible for Ariba to run Microsoft Office on its servers, doing so would make it extremely difficult to support multiple versions, or features.

 

Definitions of Functionality

Here are some clarifications to common misconceptions about what different features of Ariba’s integration with Microsoft Word actually do.

 

Edit an Assembled Document
Editing an Assembled Microsoft Word document makes you an “author” for the purposes of this document. Editing means any action which causes the document to need to be generated. Examples include substituting a clause from the clause library, deleting a clause, making an edit in Microsoft Word, or changing styles and formatting.

 

Generation
This is a simple term for the action of building an Assembled Microsoft Word Document from its clauses. For example, if you create a Contract Workspace with an Assembled Document which is a Main Agreement, it is Generated (by your client) as a part of the contract creation. You can control. Whether or not Contract Addendum Microsoft Word Assembled Documents are automatically generated upon creation of a Contract Workspace using the global parameter Application.ACM.GenerateContractAddendumOnCreateContract. Because Clauses in the Clause Library are modeled and stored as individual Word Documents themselves, they are considered “authored” documents as well.

 

DFS (Desktop File Synch)
Desktop File Synch (or DFS, as it is called) is an ActiveX control from Ariba which allows the Ariba system to “talk” to the Client machine. It is not, by itself, responsible for Word integration, it is instead just one of the tools used by the Ariba system to work with Microsoft Word. Do not confuse DFS with Microsoft Word integration. Microsoft Word integration uses DFS, but DFS does not necessarily mean Word integration.

 

Fully Synchronize
Fully Synchronize is a function that is very rarely used. It is an insurance policy of sorts to make sure that there is always an escape from an irretrievably mangled Microsoft Word document. Choosing this option on an Assembled Microsoft Word Contract Document means that you want to break all current ties in the document, and start from scratch with a new version. This will cause the document to ignore existing bookmarks, ignore clause library connections, and attempt to completely start over. This option is very rarely used, but it can be helpful to make sure that all is never lost. If you find yourself clicking this button, do so with caution.

 

Merge (through the Ariba UI)
Merge is one of the most poorly understood options in Ariba. This option simply calls a “Compare and Merge” in Microsoft Word and passes in two different documents (that you choose). This is NOT an Ariba internal function. This is done entirely in Microsoft Word. Ariba has no control whatsoever about what Microsoft Word sends back as the result from calling this. You can test what will happen when merging Document A with Document B by saving both to your desktop (outside Ariba), and performing a “Compare and Merge” from the Tools dropdown in Microsoft Word itself.

8-23-2011 8-39-54 AM.png

Cleansing a Document

Issues are very likely to occur throughout the system if a document you are working with was originally created in Microsoft Word 97 (or earlier) despite the current version of Microsoft Word that is used by the Contract Author. If you are working with legacy documents which have existed in your company since a much older version of Microsoft Word, it is required that you create those documents freshly in a newer version of Microsoft Word. The most effective way to “refresh” older content into a newer version of Microsoft Word is to copy all text into a text editor and paste from the text editor into the new version of Microsoft Word. This process removes risks associated with features not existing in older versions of Microsoft Word. This step can be performed easily as a part of the original.

 

Skipping this step almost always results in pain later, as strange errors can result.

 

Next: Part 2 - Versions and Compatibility

_________________________________________________________________

 

Beverly Dunn is a Customer Success Manager with Ariba. All customers are invited to join the private Customer Success group on Ariba Exchange, where you can access the Customer Success   Spotlights, Lunch 'n Learn Webinar calendar and replays, and the  Ariba  Knowledge Nuggets.