Ariba Contract Management allows for editing and negotiating Microsoft Word documents. It has the following rules for compatibility with different Word versions: 1. All internal users editing a document must use the same Word version. 2. Users must use an equal or newer version than any external suppliers/customers participating in negotiations. 3. The clause library and templates must be built with an equal or older version than what end users use to create workspaces. 4. The deployment version of Word must match what all users are using. Mixing versions can cause issues. The document discusses how Ariba integrates with Word by using Microsoft APIs on the client side, without directly opening or editing Word files

1. Contract Management
Ariba Knowledge Nuggets
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.
ARIBA, INC.
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: T
he 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.

2. 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

3. 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.
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.

4. Dealing with Different Versions of Microsoft Word
One difficulty of working with Microsoft Word comes when dealing with multiple versions of Word. This means versions of
Microsoft itself, not versions of an individual document. Two such issues are:
• Microsoft has no way to determine the version of Word used to create a given document. For example, it is not
possible to open up a document and tell that it was originally created in Word 97, or Word 2003.
• When Ariba integrates with Microsoft, it can only ask “What version are you?” to the Client, NOT the document. So
when a Client with Microsoft Word 2007 opens a document which was (for example) originally created with 2003, and
Ariba asks “what version are you?” the answer comes back as 2007.
The result of restrictions like these is that it matters very much that you do not “mix” versions of Microsoft Word when
working on a document.
Microsoft Word Version Compatibility for Internal Users of Ariba Contract Management
Because of the number of versions, and the complexity of the integration, it is difficult to list out every possible scenario,
and explain whether or not it is supported. One of the best ways to explain compatibility issues is with analogies. The
following analogies have been useful in explaining Microsoft Word Compatibility:
• Climbing a “Version Ladder”
• Hub and Spoke Isolation
Climbing a “Version Ladder”
Imagine a given Microsoft Word Document as a ladder, with each rung of the ladder being a different version.
Microsoft Word 2000 is on the lowest rung, 2002 is on the second rung, 2003 is on the third, and Microsoft Word
2007 is on the top rung. You can only “stand” on one rung at a time, and you can only climb.
For example, if you create a document using Microsoft Word 2002, and then open it (generate it) using Microsoft
Word 2007, you have climbed from the second rung to the fourth rung. You can never descend the ladder. So this
means that once a document has been assembled, or generated with a given version, you can never go back to
an older version.
This means that if you have deployed all your clauses, templates, and documents in Microsoft Word 2003, and
everyone upgrades at the same time to Word 2007, no issues will occur, because you are always climbing the
version ladder. However, if User A creates a document using Microsoft Word 2003, and User B (who has Microsoft
Word 2007) opens and generates that document, user B cannot touch it any more without experiencing likely
errors. Once touched by a 2007 user, a document cannot be returned to 2003 “status”. You must always climb for
a given document, never descend.
Hub and Spoke Isolation
Microsoft Word compatibility can also be thought of as a “hub and spoke” scenario. The Assembled Documents in
the Workspace Template and the clause library are the hub and all need to be on the same version and that
version needs to be the lowest version of anyone who will use these specific clauses and templates to create
workspaces. Each workspace is at the end of a spoke. As long as the hub (clauses and templates) is at the same
or lower version than each spoke, there won’t be any problems. As long as each spoke is the same version,
people can work on others’ workspaces. However, there can be no “mix and match” across spokes.
This scenario is useful to describe how it might be possible to have an error free deployment where your entire
sales team is using Microsoft Word 2007, and your Procurement Team is using Microsoft Word 2003. As long as
no clauses are shared, and no user interacts with both sales and procurement workspaces, they are always on
different “spokes” and are thus isolated from each other.

5. What about the Microsoft Word 2007 Compatibility pack?
When Microsoft released Word 2007, they changed the extension (.docx) and were forced to release a service pack for
older versions of Microsoft Word to be able to open those documents, since when Word 2003 was released there was no
such thing as a .docx file. It is important to realize several things about this:
• Opening a document in compatibility mode doesn’t have anything to do with the API’s called by Ariba. Just because a
document created in 2007 can be opened in 2003 doesn’t mean no issues will arise.
• Don’t make the mistake of thinking that a document with a .doc extension is not a 2007 document as far as the API’s
Ariba calls are concerned. If you have Word 2007 on your desktop, and you open a .doc file, Microsoft treats it as a
Microsoft Word 2007 document. When Ariba integrates with Microsoft, it can only ask “What version are you?” to the
Client, NOT the document. So when a Client with Microsoft Word 2007 opens a document which was (for example)
originally created with 2003, and Ariba asks “what version are you?” the answer comes back as 2007. In short, the
Compatibility pack doesn’t help (or hinder further) any of Microsoft’s incompatibility issues when it comes to
integration.
Supplier/Customer Offline Negotiation (Author Perspective)
The table below highlights what might happen when the contract owner (Ariba Contract Management Author) receives
edits and uploads them into a Negotiation Task and clicks Review Changes. In this circumstance if the Author is on a
same or higher version of Microsoft Word than that of the third party editor, no issues should occur. Note that most issues
occur when using Microsoft Word 2000, which is no longer supported by Microsoft. Green is meant to indicate that a
particular combination is supported, yellow indicates it is possible that the combination works, but not guaranteed. Orange
indicates that a combination is not supported.
*The following table represents the contract author’s view:
* = The Workbench Contract Author might not see supplier/reviewer edits in the merged document.
** = Compare and merge issue might exist between these versions of Microsoft Word. The differential between Microsoft Word 2002 and
2003 is not as severe as between Microsoft Word 2000 and 2002 or 2003.
Important: The above table assumes that all Ariba Contract Management users (Server document authors) are utilizing the same version
of Microsoft Word. This is a requirement.

6. Examples of Compatibility
The following examples are hypothetical situations meant to give more details about compatibility.
Example 1: Customer Deployed Entirely in Microsoft Word 2003
This scenario covers some background and some questions/answers about what happens in a scenario where a
customer is deployed completely in Microsoft Word 2003.
Background
• This customer has 5 users, all of which use Word 2003 exclusively.
• The entire deployment was done in Word 2003, meaning that all Ariba deployment professionals used
Microsoft Word 2003 exclusively.
• This customer has 100 clauses in the clause library.
• This customer has two Contract Workspace Templates, each of which has a single Assembled
• Document in it, which refers to some clauses in the Clause Library. The templates were (of course) written and
loaded using 2003.
• All Contract Creators (people who make workspaces) use 2003.
User Profiles
• User 1: Owns the Clause Library, edits all the clauses but never creates a Contract Workspace.
• User 2: Owns the Templates. Never edits any clauses. Never Creates a Workspace.
• User 3: Just creates workspaces (from those templates). Never touches the clauses (to edit) or edits any templates.
However, this user will substitute alternate clauses from the clause library.
• User 4: Edits both the Clause Library and templates. Never Creates a Contract Workspace.
• User 5: Edits Templates and Clauses and creates Workspaces including substitutions from the clause library.
Now, this customer upgrades some users to Microsoft Word 2007. Let’s walk through some different scenarios to illustrate
what will work and what will break.
Scenario 1a: If the customer upgrades all users to Microsoft Word 2007 simultaneously, there will be no
incompatibility issues. The clauses do not need to be modified or updated in the Clause Library, the Templates do
not need to be touched, and existing workspaces will work fine. In short, if you do a clean, simultaneous upgrade,
you do not need to make any special changes to any existing documents or templates in the system.
Scenario 1b: The customer upgrades just User 3 to Microsoft Word 2007. This means that only the user at the
“end of a spoke” has the highest version. This will work fine as long as that user doesn’t do any of the following:
• Promote to the Clause Library.
• Edit Templates
• Edit the Clause Library
• Modify any Workspaces made using Word 2003 (actually, this will work fine for the 2007 user, but will
break any other 2003 users who have to edit it after the 2007 user edits).
Scenario 2: User 3 (using Word 2003) creates a workspace and sends this to the supplier or the customer using
the Negotiation Task. The offline person (supplier or customer) is using Word 2007 and edits the document and
returns it in .doc format, so User 3 doesn’t know that it was edited in 2007. This scenario is supported, because
the Ariba system never “sees” 2007.
Scenario 3: User 3 (using Word 2003) creates a workspace and sends this to the supplier or the customer using
the Negotiation Task. The offline person (supplier or customer) is using Word 2007 and edits the document and
returns it in .docx format, so User 3 now knows that it was edited in 2007. User 3 will need to open and save the
document in .doc format before uploading the document to the Negotiation Task.

7. Microsoft Word 2010 Support
As of the creation of this document, Ariba does not offer support for Microsoft Word 2010. It is a
roadmap item, and we are planning it for a future release. You can, of course, upload “flat” Microsoft
Word 2010 documents (documents which are not assembled, do not have an Outline View, and aren’t
used in any of the integrations discussed in this document.