Fall 2020 Update – Units of Measure

Aligni allows you define your own units of measure (UoM) and unit conversions most appropriate to the context of your business. Recently, we have made a number of changes to the storage model and user interface associated with these UoM and unit conversions and wanted to summarize how these changes will affect you.

We encourage you and your colleagues to review our updated documentation to make sure you understand the terminology and operation of this subject within Aligni. We have also created a new Guide to Units of Measure that provides some additional information and examples.

All items in Aligni are created with an established UoM which defines how quantities of that item are interpreted on bills of material (BOMs) and in inventory.

With our latest update, we are introducing a new term (“Display Units”) to describe how quantities for an item may optionally be represented to users as a convenience. It is important to note that quantities shown in display units are still stored in the item’s native UoM in Aligni and are converted to display units “on demand”.

Inventory Listing

Inventory records will always be stored in the item’s UoM, but they may represent mixed packages of the same item. Aligni allows you to preserve the packaging unit by saving the original purchase unit as a display unit. When this is done, Aligni highlights the quantity and UoM. You can hover over the unit with your cursor to see this converted to the native unit of measure.

For consistency along the unit cost column, cost per unit on inventory listings is shown in reference to the item’s native unit of measure, allowing you to quickly compare the relative cost of two inventory units. Again, you can hover over this value to see this converted to cost per display unit.

Display Unit Indications

A new tooltip is now provided in many areas of Aligni when entering inventory quantities. When an inventory unit has a display unit specified, this tooltip will provide an approximate conversion for convenient reference but the “truth” is always stored in the item’s unit of measure.

When an inventory quantity is displayed on-screen in display units, the unit of measure is indicated in purple. In this case, the true unit of measure is displayed in a gray tooltip.


Purchasing may be done in any UoM that has a defined conversion to the native UoM of the item. Upon receipt into inventory, the quantity purchased will be converted to the item’s native UoM.

For example, consider an adhesive that is specified in mL (milliliter). The adhesive’s native UoM will be mL. If you purchase one 12-oz. bottle of this adhesive from a vendor, Aligni will require an appropriate conversion (1 12-oz. bottle = 354.882 mL) and will apply that when you receive inventory. Aligni will store the inventory as 354.882 mL, using the native UoM for the adhesive, and will set the display unit to 12-oz. bottle.

The display unit is a convenience may be changed at any time since it is only used for reference display conversion.

Build Allocations and Inventory Transfers

Quantities consumed for builds are always specified in the native UoM since that’s the quantity specified on the BOM. However, if the inventory unit has an alternate display unit defined, Aligni will show a tooltip with the converted quantity in the display UoM for convenience.

Changing an Item’s Unit of Measure

These updates have improved the consistency of our data model and will allow some additional flexibility and clarity. For example, in an upcoming update (soon!), it will be possible to change an item’s unit of measure with much lower impact on existing records than is currently possible.

Spring 2020 Update

Safety Stock Manager

Managing safety stock effectively is an important part of a comprehensive strategy to reduce “line down” risk and keep production running smoothly even with demand surges.

A new safety stock manager is now available to Enterprise organizations. This new approach replaces the simple reorder list functionality with a much richer set of tools. With the new safety stock manager, you can:

  • Define different item safety stock targets for warehouse.
  • Collaborate with your team on safety stock activity using the new discussion interface.
  • See past safety stock activity to help inform changes to range targets.
  • Snooze items to temporarily hide items.
  • Monitor safety stock status from the inventory dashboard.

We have a lot more planned for the safety stock manager. These new features should roll out later this year. For more information, please visit our guide on effectively managing safety stock.

Change Management Visual Updates

Change requests and change orders need to be quick and easy to write, review, and manipulate. They also need to communicate a lot of information quickly to be effective. To improve the efficiency of change management records, we reduced the number of tabs and made the presentation more dense. These changes should help your team collaborate more effectively on changes as your products evolve. Briefly, these changes include:

  • Tab Removal – All ECR and ECO information is now shown on a single page, reducing clicks and page loads.
  • Discussions – Improved visibility of the discussion as well as several visual improvements to make collaboration more efficient.
  • Part References – Part references are all shown in the details widget for ECR and ECO. These presentations are also more compact and faster to manipulate.

Build Discussions

In many organizations, a build is on the books for several months as inventory is procured from sources with long lead times. A lot can happen in those months. It’s important to keep your team informed and current on the latest status.

Builds now have a discussion widget to improve collaboration and activity logging. For a lot of organizations, a build can be in progress for weeks or months. With discussions, your team can stop using messy emails and keep everything organized right where it matters. By watching the build using the eyeball icon at the top right of the page, collaborators will receive notifications when someone posts a comment.

The same discussion interface is used in Engineering Change Management and the Safety Stock Manager. We plan to expand this great new collaboration component to other records in Aligni soon!

Build Deviations Ledger

The new Deviations Ledger is our first major improvement to build deviations. The ledger provides an easier way to visualize and manage deviations for items on a build. In ledger format, the addition, removal, and substitution of items is more readable and clearly indicates the quantity of the item added or removed from the build.

Manufacturer Families

You may now define Manufacturer Families for a manufacturer and add attachments common to that part family in a single location. These common family attachments are then visible to all members of the family on their attachments page.

Family attachments are a great way to collect common information associated with a part family such as datasheets, specifications, regulatory compliance information, or performance data.

Other Improvements

Over the past few months, we’ve made loads of other improvements across all of Aligni including bug fixes, security improvements, performance improvements, and the implementation of a number of feature requests. We’re always excited to hear from you. If you’re interested in one of the features above or have something to suggest, please reach out!

Accounts and Organizations Restructuring

Accounts, Invitations, and Collaborators

As you know, several months ago, we updated our accounts to use unique email addresses as a credential for accessing Aligni. We have also merged several user accounts to allow those users to access multiple sites with which they collaborate. As part of this restructuring, you’ll notice a few things…

Organizations – Previously known as sites, we now refer to the owner of an item master (part database) as an organization. This is more aligned with modern conventions in the cloud software industry. As an account holder, you can now create multiple organizations and set them up as private or public.

Invitations – Previously, user accounts were created by the site administrator as part of the site management role. Now, user accounts may be created at any time by users and the association to an organization is handled as an invitation to collaborate. This distinction is important as it allows users to collaborate with multiple organizations.

Public Organizations

Since its introduction in 2006, Aligni has offered a free service for Open Source Hardware projects known as Open Aligni. We have merged this service with our standard (private) service to make it easier for account holders to manage and access multiple organizations and their item masters using a single account.

Public organizations are established as a way to share your projects and the data associated with them with the world. This is a great way to share your BOM, schematics, and other associated information with colleagues, customers, and hobbyists. For example…

  • Open Source Hardware – Makers and creators can share their designs with the world in an open, organized environment. Bill of Materials (BOMs), part data, revisions, design files, and change management information is all available in one place.
  • Evaluation Boards – Share your company’s evaluation board designs in a consistent presentation. You can include part alternates, supply chain information, and design documentation to make it easy for your customers to access and easy for your design team to maintain the information.
  • University Labs – Many universities have departmental labs or student stores. These labs can share their parts database, inventory, BOMs, and other project materials with students and the public.

New Terms of Use

In order to better represent the language used in defining accounts and organizations, we have a new Terms of Use Agreement. Please review this document. Continued use of the Aligni application and API indicates an agreement to these terms.

Future Directions

This restructuring lays the groundwork for a lot of new capability we’re working on. We’re really excited about what’s to come!

Fresh Paint – New Settings Layout

Today we rolled out a new layout and hierarchy for our organization and user account settings. More than just rolling on a fresh coat of paint, however, we revisited all settings and rebuilt the hierarchy to make things easier to find. We also made several interface improvements along the way.

Both organization and user account settings are available from the organization badge menu located at the top-left corner of every application page. Some organization settings may not be available to all collaborators depending on how your organization administrator configured permissions.

One Account, Multiple Organizations

We recently consolidated any accounts that shared the same email address. The new settings organization is another step in this process. Now, you may use a single Aligni account to access multiple organizations if you are a member of more than one. If you’re a collaborator with more than one organization, you’ll see a switcher in the badge menu as shown.

Legacy Settings

The legacy settings interface is still available through the end of March. If you have any questions, comments, or concerns about settings, please reach out to support@aligni.com.

More to Come!

This has been an important step to updating and modernizing our account structure and sets us up for some nice new features we plan to deploy over the next couple months. Stay tuned!

Two Approaches to Managing Alternate Parts


I have a part (actually multiple parts) that can be made by 2 different manufacturers: in-house and an outside source. Parts from both sources are functionally identical and treated as interchangeable in assemblies. What is the best way to handle this? Is it possible to have a part with multiple manufacturers? Could I create two parts and have Aligni treat them as interchangeable?
– H.D. at Overwatch Imaging


The short answer is to use Aligni’s Part Alternates feature. Here’s a bit more detail…

You’ll get the most out of Aligni if you maintain your database to be consistent with Aligni’s Manufacturer / Vendor relationships model. In summary:

  • Every item (part) has a unique Aligni P/N (SKU)
  • Each item has a single manufacturer
  • Each item’s manufacturer P/N is unique to that manufacturer
  • Each manufacturer has one or more vendors

In this post, we consider two distinct situations in the current case because the two situations justify different treatment within Aligni:

  1. Two commodity parts are manufactured by two different manufacturers that are functionally equivalent. An example of this would be electronic resistors.
  2. One part is specified but is manufactured by two different service providers. An example of this would be a machined part built-to-spec by a machine house.
Part Alternates are shown and managed on the details tab of the Part page. This part in our online demo database is a good example with three part alternates defined.

First Case: Different Manufacturers

In the first case, let’s consider two electronic resistors that are manufactured by two different manufacturers. In the electronics industry, these are commodity parts that are available from many sources. They are sometimes colloquially referred to as “jelly bean” parts and are often considered “generic”. However, on our Part Alternates documentation page, we caution against configuring these parts in Aligni as generic.

So per our suggestion, these two parts would get separate Aligni part records, each associated with its respective manufacturer. You would then associate the parts to each other using Aligni’s Part Alternates. You have two options for this association:

  • Equivalent – This means that two parts are suitable for any installation. They have identical parameters and differ only by manufacturer.
  • Alternate – This means that two parts are similar, but substitution requires consideration.

At this point, the choice becomes industry or application specific — your organization will need to decide to what level “functionally identical” may be interpreted. For example, components intended for spaceborne instruments may be functionally identical to others for terrestrial applications, but may require special consideration for use in space.

Second Case: Generic Manufacturers

Let’s consider a different class of part, machined parts, and suggest one possible way to set things up for that scenario. Here, you’re the designer of the part and you provide drawings, schematics, and other specifications about how the part will be constructed. You provide this information to a machine shop and they build the part to your specifications.

To best fit the Aligni relationships model, we’ll create a manufacturer called Generic Machined and we may have multiple vendors (machine shops) associated with this manufacturer. With the relationships defined this way, RFQs and POs entered in Aligni can be routed correctly to your machine shop vendors when you have parts for this Generic Machined manufacturer.

When setup this way, there really is no need to use Aligni’s Part Alternates feature. In fact, it cannot be used since there is only one part in consideration.

Inventory, SKUs, and Nuance

The astute reader will recognize an important nuance in the results achieved by the two approaches above. Notably, in the first approach, we end up with two Aligni parts (SKUs) that will be inventoried separately whereas, in the second approach, we have two vendors for the same Aligni part and therefore only one SKU.

In the first case, we decided that it was important to keep the items separated. This is open to debate, but we feel that it is not good practice to use generics in this situation. Here are some reasons to consider:

  • Buyers should not be making engineering decisions. While the specifications may be identical to a buyer’s eye, an engineer may think differently. The results of an incorrect application can range from benign to havoc in the final product: loss of performance, field failures, reduced lifetime, expensive rework, or scrapped material.
  • Separate parts should be lifecycle managed separately. Two manufacturers operate differently and likely have very different schedules for obsolescence or other lifecycle events such as engineering change notifications. As separate parts, these can be monitored more easily and reliably.
  • Partner communication is more precise. When generics are used, there can be some ambiguity when communicating a BOM to manufacturing partners. Since parts and packaging is typically marked with the manufacturer’s information it makes sense to have BOMs reflect these markings.
  • Traceability. With two separate part records, everything from RFQ to purchasing to builds and inventory is tracked more accurately. If you ever need to review or audit for usage, you’ll know exactly which parts were used for which assemblies.

The second case is a good example of a legitimate and unambiguous use of generics. In this case, the generic manufacturer is an abstract concept used to fit operational behaviors to the Aligni relationship model but without compromising efficiency or clarity. If the two machine shops can genuinely create parts that are form, fit, and function compatible, then their outputs can be mixed in inventory and they should fall under the same SKU.

Fall 2017 Update

As the leaves fall from the trees and the Aligni team gets excited about binging on Halloween candy and season two of Stranger Things, we reflect on the past several months and some of the features we’ve released and haven’t yet shared.

Partner View

Partner View allows our Enterprise customers to define part classes and provides partner accounts gated, read-only access to only the part class they are allowed.

Thanks to Formlabs for sponsoring the development of this feature through our Bespoke Support!

Bulk Inventory Import

Create multiple inventory units at once using our bulk inventory import tool. While very convenient for initial migration from other software, this importer can come in handy to long-time Aligni users as well.

Buyer Notes on PO

When working with purchases, you can now keep item-specific notes that aren’t intended for vendor consumption. Buyer notes are handy for internal communication when multiple buyers author POs or for other general reminders and placeholder notes.

New Part Display Style – Popovers

With the new %{popover} part display style tag, you can add quick popup information to part indices and part lists.

Equipment Comparisons

Compare equipment configurations the same way you can compare assembly part lists. Our handy drill-down interface makes it easy to drill down through the changes in the equipment hierarchy.

Thanks to Ventana Medical Systems for sponsoring the continued development of Aligni’s configuration management features through our Bespoke Support!

Allocation Shortage Report

Earlier this year we rolled out a design update to the allocation shortage report. Since then, we’ve made a number of additional improvements to make navigation better and provide more information on the same page.

  • Purchase indicators for arriving inventory (blue indicators) show you when purchased inventory is due to arrive before the build date.
  • Purchase indicators for future arrivals (red indicators) show you that purchased inventory is due to arrive after the build date. You should then try to expedite the order or reschedule the build.
  • Export items as CSV because, well, we just can’t seem to kill this format or the countless spreadsheet addictions they enable.
  • Build status indicators at the top of the page change as you hover over the build columns and you can stick specific builds to the header as desired.
  • Continued Performance Improvements

Build Updates
Also earlier this year, we gave builds a refresh with incremental reserve capability. A number of follow-on improvements include:
Auto Allocate reduces page load time by not rendering all the parts on a build unless you need to see them. For users with hundreds of items on a build, this gets a bit old.
Auto Reserve greatly reduces data entry time by automatically reserving items on a build according to your chosen strategy.
Export items as CSV because, for some people, if they could use Facebook inside Excel, they probably would.

Tell a Story with Aligni ECM

The essence of product lifecycle management (PLM) is to engage with the life of your product throughout its entire lifecycle – from conceptualization to development, from prototype to production, through maintenance, and ultimately obsolescence. Engineering change management (ECM) is the documentation process that tells this story. It’s hard enough for one person to build one product and remember all the twists and turns that brought them through today.

This month, we’re rolling out Aligni’s new ECM feature. Aligni’s ECM has been developed to provide a simple, easy-to-use workflow, a clean interface, and the integration you’d expect to other Aligni pages making ECM documentation easy to find for your parts and assemblies. ECM at the enterprise service level includes approval workflow for role-based management of the change process.

With ECM, you can create engineering change requests (ECR), link them to engineering change orders (ECO), then link the ECO to a part revision to fully track the proposal, discussion, evaluation, and implementation of requested changes.

Every organization handles changes a bit differently – priorities vary from company to company and your approach to change documentation needs to reflect your company’s values and purpose. Configurable ECM parameters allow you to customize your site’s ECM to work perfectly with your workflow and internal process terminology.

Discussions and attachments are a vital part of the change process. ECM discussions include a feature where participants can register their position on a proposed change or implementation as undecided, thumbs up, or thumbs down. This is separate from the approval process so even sites without approval workflow gain some documentation benefit from ECM participation.

Aligni ECM records allow you to list related items and affected items. These links include specific revisions of parts so you can quickly see which ECO were rolled into a revision update. We mentioned previously that ECM can help tell the story of a part’s evolution. This story becomes clear in the part revision history where links to all contributing ECO and ECR are connected to their corresponding revision. All of your change documentation is just a click away!


For more information, please visit our Change Management documentation.

Aligni ECM Pricing and Availability

Aligni ECM is immediately available as part of all Large and Enterprise plans. Existing Medium plans are able to try out Aligni ECM for 60 days by emailing support. After the trial period, you will need to be on a Large or Enterprise plan to continue using ECM.

Minor API Update

An error in the API for subparts was recently brought to our attention. We will be deploying an update to the API over the weekend of June 24 / 25 but wanted to make you aware of the change. While we don’t believe anyone will be affected by this change, it is possible that some users quietly used the incorrect API data.

Before the change, the subpart tags in a part’s part listing used part_revision_id to incorrectly reference the PARENT’S part revision ID. You’ll note that this was already referenced in the revision tag.

The API update changes this so that the part_revision_id now correctly references the CHILD part revision.

Builds and Partial Reservations

We’re excited to deploy a new feature that will allow builds to have reservations specified on a per-item basis as opposed to the full-build reservations that are presently enforced.

Aligni’s builds help you manage the conversion of components into finished goods, reducing inventory of components as they are consumed into final assemblies. Currently, a build progresses through the stages as a whole. That is, every item on the build moves along with every other item through planning, allocation, reservation, and completion.

Historically, this meant that if you were waiting on one part to arrive, the whole build had to remain in allocation until that part could be reserved along with the other parts. Alternatively, some customers would reserve the partial build, but then cancel the reservation to re-reserve when the part arrived. Neither solution is ideal.

With partial reservations, you can now reserve (and unreserve) single items at a time while the build is active. Aligni will allow you to finalize the build at any time, but will alert you if the build is not yet “fully reserved” — that is, when reservations satisfy or exceed the allocated quantities.

We’ve deployed this new functionality to our Demo Site. Please try things out and become accustomed to the operation. This will go live on production sites starting February 6.

Reserving and Un-reserving Items

Builds-ProgressStatus@2xThe Parts tab for an allocated build is now a live-entry page (AJAX for you savvy web users). This means that when you enter a value in an entry and move to the next, Aligni will update the reserve quantity in real time. It will also update the progress bar at the top of the page to indicate how many items are allocated and how many are fully reserved. An item is considered fully reserved when the total reserved quantity is equal to or greater than the quantity originally allocated for the build. Since the entries are updated in real-time, there is no longer a Save button.

Progress Bar

A progress bar at the top of the build page and on the build manager provides a quick glimpse of the reservation status of the build. The green portion of the progress bar indicates the portion of the build that are allocated. The red portion of the progress bar indicates the portion of the build that has been reserved.


Notice of New TLS 1.2 Requirement

TLS 1.2 Requirement

Starting 30 November 2016, TLS 1.2 will be required for all browser and API connections to Aligni. While many of you may not know what this means, the good news is that you probably don’t have to. TLS 1.2 is a protocol standard for secure internet connections. TLS 1.2 is supported by all recent major browsers. You can find a support matrix by visiting this page. The older your browser (or the more Microsofty it is), the less likely it is to support TLS 1.2 so make sure you’re using something up to date!

Aligni Replicator

The TLS 1.2 requirement also affects all API access. You will need to make sure that your API development environment supports TLS 1.2. Aligni Replicator 1.1.4 supports this and can be downloaded here. If you’re not using Replicator 1.1.4 by 30 November 2016, you will not be able to synchronize your local database.