Understanding Locations in SC Navigator


SC Navigator refers to locations as geographic points, defined by geocoordinates. These locations can have several functions in your supply chain, however. Understanding how SC Navigator uses locations is key to creating an efficient and functional model.

When you produce a data template as a spreadsheet, you'll see several sheets and attributes referring to "Location" data of one kind or another.

Defining Locations by name, geocoordinates and location type

Locations are geographic points in space that represent your Suppliers, Facilities (Resources), and Customers. Each location is named in Location Definition and geocoded in Location Data. Once defined in these two sheets, you can refer to locations by name as shorthand for the corresponding geocoordinates. Finally, to give them meaning in your model, you can define them as location types-- Suppliers, Facilities (Resources), or Customers.

Sharing geocoordinates for multiple names or location types

These location types are defined elsewhere, such as Customer Definition, Resource Definition, and Supplier Definition. You can then assign the appropriate location name to each item named. This does not function to group the items together, but to allow them to "share" a location whose geocoordinates you have already defined.

For example, you may have a Supplier producing Tea in London, and a Customer ordering Shortbread in London. The fact that they are both in London is incidental and doesn't necessarily mean that they will intersect in your network. However, you can assign them both the location "London" and the model will know the coordinates to assign each one while you've only entered coordinates for London once.

Depending on the scope of your network, it may or may not be useful to "share" a location among several customers or other entities in your data. Below you can find an example of another approach.

Grouping Locations

It may be more suitable for you to define the locations in your network one by one. Using the example above, you could then define a location in Location Definition "London_TeaSupplier" and a location "London_BiscuitCustomer" and give the exact geocoordinates for each separately in Location Data. With this approach, the location name is specific to one entity and not a group of unrelated entities in the same physical location. You may end up repeating the same (or very similar) geocoordinates in Location Definition, but you will save the step of connecting a physical location to a location type.

However, in this case, it is still useful to create groups of locations to simplify transport (and other) data by telling the model the function of a set of locations. For example, if you have chosen to enter your locations each uniquely, "London_TeaSupplier" and "London_BiscuitCustomer" could each be grouped in the appropriate location type – as Customers and Suppliers (and so on). The groups will be defined in another sheet. That tells your model which part of your network they belong to (e.g. primary transport) and can programmatically create transport lanes from each Customer to each Warehouse, etc. and compare them to find the best solution.

This kind of grouping creates a subset of locations based on their function, but not their physical location. So you could include “Birmingham_BiscuitCustomer” and “London_BiscuitCustomer” in the same group because they are the same location type – here, Customers. Each location will already be given geocoordinates in Location Definition.