Managing Transactions
A transaction transfers licenses or inventory items to and from various “transaction pools”.
Examples
For instance you might have 25 licenses for a software product, Microsoft Word, in the On Hand pool and 60 in the In Use pool, meaning that you have 25 available to allocate, and 60 already allocated. After each transaction, ASM Core automatically recalculates the levels in each pool (that is the quantity of items).
Transactions can also be automated through requests.
ASM Core enables you to perform various transactions on inventory items and software products, such as ordering items, adding them to your CMDB once the order has been received, purchasing items (making them immediately available in the CMDB rather than ‘on order’ as is the case for an order transaction), reserving them for certain Users, or retiring items.
It is possible to perform many different types of transactions in order to manage assets. You can add transactions manually through the Transaction Details window on a software product or inventory. Transactions can also be created automatically through the Manage CMDB Task in the workflow palette. You can also allocate or reserve licenses and inventory items from a call, request or task.
An example of bulk inventory tracking would be if, say, configuration manager is told that there is a new office opening for 50 new employees in North Sydney.
The configuration manager needs to order new configuration items for the office such as computers, printers, keyboards, computer mice, and telephones. Because of the large number of peripheral items such as keyboards, it makes sense to manage them as a single Inventory, Keyboards – North Sydney Office, rather than 50 separate keyboard records. The configuration manager:
Adds a new order for 50 new keyboards to the Keyboard – North Sydney Office inventory record in ASM Core, and contacts the supplier to place the order.
Receives the full order and records the keyboards as being purchased and On Hand.
Out of the 50 keyboards in stock, allocates 10 keyboards to the IT team, reserves 10 for use by the Sales team, and changes the status of the remaining keyboards to On Hand – Unavailable (so that there are spares if needed).
Six months later, a member of the IT team leaves, transfers the person’s keyboard to a new employee.
After a year, returns two keyboards which are faulty and still under warranty to the supplier for repair or replacement, and records these as being On Hand – Unavailable.
Retires the allocated keyboards, in order to allocate the unused keyboards still in stock.
In an even simpler scenario, the configuration manager may simply purchase a quantity of items, allocate some or all of them, and at later stage, retire them.
About Transactions
Tracking items in transaction pools
As illustrated in the scenarios, each time you perform a transaction on an inventory or software product, you are in fact moving a number of items from one state or “pool” to another:
| Orders | Items your organization has ordered but not yet actually purchased, that is, ON ORDER |
|---|---|
Purchases | Items your organization has actually purchased, that is, PURCHASED, as well as the items that have been received from an order. The purchase pool is further broken down into the items which are: |
When viewing the Transactions window, these pools are accessed using the tabs or views on the window.
You can only perform transactions in the view relevant to the particular pool.
Partitioning Transactions
If you are using partitioning, transactions may be created in particular partitions. The transaction will be assigned to the partition of the CMDB item or person that the software license or inventory item is to be reserved or allocated to or for.
If CMDB items or people are not partitioned, the transaction will be assigned to the partition of the ASM Core entity from which the transaction is performed, that is, the call, request, or task where you are performing a transaction.
If the call, request, or task is not partitioned, the transaction will be assigned to the current working partition.
Integrating Transactions with IPK and Workflow Processes
Transactions are integrated with IPK and Workflow processes through the following:
CMDB Item and User fields: provide actions relating to Transactions such as allocate and reserve.
Transactions explorer option: enables you to view and manage transactions added to the call, request or task.
Transaction History explorer option: enables you to view a record of the transactions initiated from the call, request or task.