New Purchase Wizard

The Add a Purchase wizard is opened when you right-click in the Purchases window and select New Purchase..., when you select New Purchase... from the Tasks menu, or when you drag a Product into the Purchases window (not ON a purchase). The Wizard is designed to aid in the creation of a purchase record that correctly documents a purchased entitlement. You can also add a Purchase to an existing PO, where normally using the wizard prevents putting in a duplicate PO for a Purchase. To do this, open an existing Purchase Detail, expand the left hand pane, and right click in the Purchases pane to create a new purchase linked to the original PO.

The various screens in the Wizard are arranged to guide data entry in a logical progression. But if instead, you want to enter the information directly in the Purchase Details Window, you can click the wizard's "Finish" button at any point - then the Purchase Details window will open showing the data entered so far. You can complete data entry and correct any errors before saving the record. Depending on how you start the wizard, some information will be automatically populated, as in adding a purchase to a PO, or dragging in a Product.

Software Purchase Records

In order to support compliance and reconciliation reports for software licensing, the data fields representing entitlement rights must be complete and accurate. To support Liability, Overspend, and other financial widgets hosted by Key Reporter, purchase cost data must also be complete and accurately recorded.

Typically, much of the raw data needed by the Sassafras Server Platform for entitlement tracking is already available elsewhere in a dedicated procurement system. Often this data can be imported directly (as explained here) rather than being re-entered in the Purchase Wizard or Purchase Details window. But in any case, reading through this documentation may help in pointing out what data is important and how it is used. Often, the entitlement rights and dependencies for software purchases may not be adequately represented in procurement systems so it will always be prudent to double check the essential information:

A complete historical record of software purchases, upgrades, subscriptions, etc. will provide the basis for your Sassafras Server to compute the "current entitlement position" for each product – but it may be impractical and unnecessary to enter or import the entire historical record. If you already know how the maze of historical purchases for a product sums up to a bottom line, the wizard will let you create a "synthetic" record that asserts this number. The synthetic record serves as a baseline for calculating "current license position" when going forward with new purchases. In the synthetic case, you can invent your own PO# – or leave the field blank and let the final screen of the wizard make up a value.


Example

The simpler purchase types (e.g. Tech Support, Media Only, and Other) are self explanatory so this example will focus on recording a license entitlement for FileMaker Pro 11. Each screen shown below is dependent on the choice made in the previous screen, so when you enter a specific purchase, you may see a different sequence. Below we illustrate screens for an upgrade purchase as well as a subscription purchase.

Basic Information

Leave the PO # blank if you are creating a "synthetic" record to represent a baseline "current entitlement position" for a product.

The "Item Description" can be any information about the purchase that will be helpful for identification later.

Either a Unit Price or an Extended Cost value is required by the Purchasing Dashboard to compute amounts for "Overspend" and "Liability." Unit MSRP is for future reference only – it is not used to compute actual costs.

Various reports can be restricted to analyze purchases within separate cost centers when applicable. If you enter a Cost Center it will appear in the drop-down list for subsequent data entries.

Product selection

Entries from the prior screen are shown in the gray area at the top. In this screen, choose the Product (including major version identifier). Compliance, entitlement, liability, overspend, and other reports all depend on referencing the correct Product record from among those listed in your Products Window.

While the "Item Description" from the previous screen may seem adequate, a Product record must be referenced from the purchase in order to support reporting functions.

If right-click from a selected Product was used to bring up the Add Purchase wizard, the wizard will already have the Product filled in. But if the wizard was invoked from the task menu, use the search icon to fill in the correct product (or use drag and drop from the Products window).

Note: The search icon will bring up a window that alphabetically lists the items from your Products window – and then below a separation line, it will list additional "online" items found using the Product Recognition Service. If you can't find the correct Product using the find icon, leave the Product field blank. Later you can create a product record using the "New Product..." task.

License Metric

A software purchase is an entitlement to use the software subject to various Rights and Conditions. This screen lets you choose among several "Metrics" that broadly define these rights. Note: sometimes there may also be further conditions – e.g. a concurrent license may be restricted to a certain subset such as 'student lab computers'. Any such "Special Conditions" that modify the basic metric chosen here must be documented at the end of the wizard in the Purchase Details window.

Choose the Metric by which compliance is measured. Site, Node, Lease, and Concurrent are the most common choices for desktop software. Server software is often licensed with metrics measuring PVU or Core attributes on the host nodes.

Be careful to understand the details of your specific purchase - often the word "Site License" is used loosely when there are actually some limitations – some other metric, perhaps Node or Concurrent, might be more accurate.

In subsequent screens you will specify whether this purchase is dependent on a prior purchase (e.g. an upgrade) and whether the licensing rights will expire (e.g. a subscription).

Dependency

The purchase of entitlements for a specific product version may depend on owning entitlements for a prior version or entitlements for some other product.

An Original purchase simply supports some new entitlement count without any dependence on prior purchases.

A Dependent purchase depends on a prior purchase of some other entitlement. The purchase may be an upgrade, an addendum to an existing entitlement (e.g. subscription renewal), or a product exchange (e.g. "competitive upgrade").

Note: a Dependent purchase must be supported by a sufficient number of entitlements from previous purchases to support the new purchased quantity. You will specify the kind of dependency in the next screen and then the specify which supporting product(s) were previously purchased.

In the case of a subscription, a renewal can often be recorded either as an Original purchase or as Dependent – the start and end dates of the old and new lease periods will prevent any doubling up of the entitlement total in either case. If in fact the new Lease purchase does specify that it depends on prior entitlements (perhaps with a lower price), then of course specify it as Dependent.

Dependency Type

For a purchase marked "Dependent" in the previous screen, you must choose from the four common cases listed.

When a purchase is classified as an Upgrade from an older version, typically the new version entitlement allows usage of either the new or old version under the new license (i.e. the upgrade entitlement includes "backward coverage") – but of course this does not increase the total number of entitlements!

The dates for a License Renewal will be entered in a subsequent screen.

Unlike a software subscription where the software usage right completely expires on a specified date, a Future Upgrades right entitles a perpetual license right for whatever version is current at the end of the Upgrades period.

A Future Upgrades entitlement is often sold as part of a maintenance plan that includes tech support. Also a new product purchase often includes a future upgrade right for some limited period of time. When included with an initial purchase, you may have to represent the entitlement with two separate items on the same PO: an Original purchase record and a Future Upgrades record.

Upgrade from Prior Product(s)

As an example, suppose FileMaker Pro 14 Win is being purchased as an upgrade to an existing entitlement. In this screen, the eligible prior product version(s) must be specified. Note: there is no requirement that entitlements for the prior version(s) were procured in a single purchase but there must be a sufficient number (in this example, at least 150) to support the upgrade entitlements. Without a sufficient number, some of the newly purchased upgrades would be unsupported and therefore not yield a valid entitlement.

Often, a product Upgrade purchase can be supported by more than one older version with no difference in price. In this example, prior entitlements for either Filemaker Pro 12 or FileMaker Pro 11 will suffice.

An upgrade to version 14 from the more recent FileMaker Pro 13 might also be available, but with a more restrictive entitlement dependency, the cost would presumably be less. Such a purchase would be recorded in a completely separate purchase record.

Purchase Term

In this screen, the top gray area shows an example purchase of "FileMaker Pro 14, License Metric: Node, Original purchase", and at the bottom, the Subscription choice displays fields for entering dates.

The End Date must be specified - this is the date on which the entitlement expires. If the Start Date is left blank, the subscription is presumed to start on the date of the purchase.

If the subscription purchase had been entered as a Renewal (instead of Original), a similar screen would show a single date entry field for the revised License Term expiration.

Finish

This final page in the wizard gives you an opportunity to review the details of your purchase before going to the Purchase Details Window. Data entries can be corrected on this screen and the Back button will let you review previous screens and perhaps pick a different path through the wizard. The Finish button will exit the wizard and show all the fields of the resulting purchase record.

If you left the PO# field blank, you must either type something in before saving, or use the “Generate a PO#” button to let the server create a unique reference.

Purchase Details Window

Clicking Finish from any wizard screen will bring up the purchase record ready to be saved. Additional information can be entered or values changed. Other panes in the Purchase Details Window (not revealed in the example screen shot below) will let you record install codes, embed (or reference) original purchase documents, record special notes, and examine dependencies (if any). Note: using the wizard to step your way through creation of a purchase record is purely a convenience. The same result can be achieved by immediately jumping out of the wizard using the Finish button and then entering all field values into the Purchase Details window, or by importing a csv file that represents purchase data.

Further details for this purchase can be summarized here. The actual pdf files issued for the purchase can be attached or referenced by url in the documents panel of this window.

This is an example of a synthetic purchase. The PO# was created by “Generate PO #” from a final wizard screen - but you could change that to your own identifier (using the small disclosure triangle at the top-left of this screen).

If this entitlement has an expiration date, make sure it is recorded here. The bell icon can then be used to set a reminder at a specified time before expiration.

Special Conditions that refine basic license Metric are recorded here.