As far as training goes, the best training class for this topic is our Ariba Contract Compliance training. This class discusses the Contract Request (if you do not have Contract Workspaces) or Contract Terms (if you do) document, the options available, and how to push pricing into Procurement.
This class is next being taught in Alpharetta, GA on April 15th-16th by the fabulous Elizabeth Harris. For more information, you can email our training coordinator Lauren Walker (email@example.com) and she can fill you in on the details.
But just to give you a general overview...
Ariba supports both release and non-release contracts. A release contract will allow you to create line items inside the Contract Request/Terms that can be pushed into Procurement. These line items could come from a Sourcing event as well. These items will act very similarly to regular catalog items once you get them to Procurement.
A non-release contract can be set to allow invoicing and/or receiving against it, but not orders. It has the ability to capture materials/goods, fixed fee costs, and expenses. You can also set up Milestones - something like "receive project plan from consulting team" - which have a verifier (somebody who will verify that the work was done) and serve as a receipt of a particular deliverable.
VS, Training is always important, but I have some additional thoughts as well.
If you are setting up a contract that will be leveraged with purchase orders, it is typically best to ensure that the supplier will be well aware of your companies invoice payment procedures and such before the first PO is cut. Examples of things that should be transparent to suppliers includes; invoice reconciliation and matching processes (e.g. 2-way or 3-way match), precision at which invoices must match the PO lines, accounting variances, quantity variances, and the list goes on. One method to share these details with supplier is to include the terms and conditions as a note on all purchase orders. I have also seen instances where "speedy payment instructions" are referenced on POs.
There are other elements to consider in an Ariba model as well, such as electronic invoice capabilities, tax and shipping treatment and invoice approval schemes.
Finally, you way want to entertain exception processes as well. Examples include scenarios where a PO is never sent to the supplier. Rather, suppliers can punch-in from the Ariba SN to your Ariba instance and create an invoice directly against the ACC contract. This method is nice when items are variable / indefinite in nature – like utilities, after the fact services, telecom and the like.
I find that invoicing against contract (non-release contract) is very useful where you have a third party PO system, contingency work or where there is a high volume, low value, indefinite qty being invoiced.
The biggest problems that I have run into is that since there is no PO, the invoice needs to be approved and the degree of validation on an eInvoice means that A/P has more validation exceptions to deal with than with PO invoices.
I would also like to recommend you setting your contract items as generated subscriptions. For the end user they will look like any other catalog item. There are differences between catalog items and contract items, but in general it doesn't matter to the end user.
You can also set up the contract item with accounting information and other useful details that will reduce invoice exceptions in the end.
That way the items on the PO are the contract items. If you then use PO Flip on the ASN, the invoices will default to the items on the PO which are the contract itmes.
OTOH, if the vendor refuses to comply with matching what was ordered, you have a non-ariba issue that contracting won't solve.