StationCount Review

From SkySuite Wiki
Jump to navigation Jump to search

This page is available to those in the planning/4PL operations team (station provisioning managers).

A count may be subject to review for two different reasons:

1) the count has one or more lines where the Query flag is set to yes (true)

2) the station count category is configured to send all submitted inventory counts for review regardless if there are any lines where the query flag is set as yes/true.


NOTE: the final column on the data grid shows the Query flag (which is a boolean - meaning true or false, yes or no, on or off) - you can choose to filter the data to only show lines where Query = Yes.

The data grid will offer the material code, material description, unit of measurement (UOM), the figure that the caterer reported as having in their stores (Column: Backup) and optionally the inventory that they have in their operating area (the "shop floor") - that is displayed in the 'Float' column.

The 'Closing Inventory' is the combined figure of Backup [Qty] + Float [Qty].

The Expected Closing Quantity is what Skylog believes that the station will have, this is based on the last approved count for the station and matierial and activity since that previous count (note: only approved counts are considered - so if there have been other counts conducted since the last approved count that might have been aborted/cancelled then they are NOT used in Skylog's considerations/calculations).

Skylog will consider activity as anything received, anything consumed and anything returned from the station. Receipts of the material at the station would include stations orders (shipped from a warehouse), direct purchase orders (if applicable) and anything that arrived at the station from a station-to-station transfer.

Returns would include station-to-transfer (e.g. where the station shipped inventory to another station) and also station-to-warehouse RMAs.

Consumption relies upon good forecast data - note that not all airlines generate BOM forecasts.

In a very simple example, suppose there is a material: ACME0001 which was last counted on the 1st of April (the count was approved), it is not the 1st of May - at the last count, the station had 200 PCE in its backup (stores) and 50 in its floating stock - so a total of 250 PCE. During the month of April 500 PCE were received, across two station orders. The station shipped 100 PCE to another station that was in danger of running of stock. The station loads 20 PCE per day, there is no recovery of the material (the material is disposable or is not offloaded at that station).

So, 250 from the previous count + 500 received = 750
750 minus 100 that was shipped in a station-to-station transfer = 650
There are 30x days in April, so with a consumption rate of 20 per day, that would 20 * 30 = 600

So in this scenario, the Expected Closing Count would be 50.


IMPORTANT: The Expected closing count figure can be a negative value - whilst it may not be physically possible for a station to have less than nothing of a material, technically it is possible. The configuration for a station holds a boolean flag labelled as "Enforce RMA Quantity". Briefly, if this is set as YES, then a caterer can not raise a Station-to-Station transfer or a Station-to-Warehouse RMA for a quantity greater than then last approved inventory figure; if this flag is set to NO though, no validation check is performed when a Station-to-XXX transaction is raised, thus the station can ship ANY amount. As a consequence of this, it can lead to a negative expected closing count figure - if as station provisioning manager you should see this, it is not a bug; we do not default to present a zero if the result of the calculation is a negative number, the portal will display the true result of the calculation and it is up to you, as a planner to investigate further if you feel that you need to - the reasoning being that by presenting a negative value, it is hoped that it will peak your interest and you may question the number displayed to you. A worked example of this happening is detailed on support ticket #15824 which you may wish to review if you have the necessary access rights.