SkySuite Wiki - User contributions [en-gb]

Substitution PlannedIndex

2021-09-20T15:35:22Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

{{Tips and tricks}}

To view, create and take action upon planned substitutions, go to the Reference Data main menu, on it you will see a sub-menu option for Substitutions and within that sub-menu, you will see the option for Planned Substitutions.

Depending on your access rights, you may see planned substitutions for just one or many airlines.

== '''Creating a new Planned Substitution''' ==
You can create a new planned substitution by clicking on the + (add) button on the toolbar above the data grid.

Again, depending on your access rights, you may be prompted to choose an airline; if you only have access rights for a single airline then you will not be prompted.

You will then be prompted to choose a product that will be substituted, you will need to click on the "Select Stock Item" button, a dialog will be presented to you - you can apply filters to find the item that is to be substituted/replaced (note: this may be a generic product).

Next, you will be prompted to specify a Substitution Method, the options are:

* Percentage Split
* Day Of Week Split
* Date Range Split
* Market Split

=== Percentage Split ===
So for example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and the reality is that flights will be loaded with one of 5x different red wine products, RW0037, RW0044, RW0052, RW0067 and RW0071; there will be an equal split across the five wine products, thus you could setup the planned substitution with 5x lines, one line for each of the real wines that will be loaded. As the split is equal, each line would have a loading of 20%.

'''NOTES:'''
* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if there were 3x products rather than 5x and it needs to be an even split, you would need to have 2x lines at 33.3% and one at 33.4%

* You can only specify one decimal place for a percentage split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== Day Of Week Split ===
So again, as an example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but you want your forecast to show replace that generic material with a real product and you want to show that if the flight takes off on:

* a Monday or a Saturday, then the flight will be loaded with item: RW0037.
* a Tuesday, then the flight will be loaded with item: RW0044
* a Wednesday, then the flight will be loaded with item: RW0067
* a Thursday, then the flight will be loaded with item: RW0071
* and if the flight departs on a Fridat or a Sunday, it will be item: RW0052 that's loaded

=== Date Range Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but during the month of September, flights will be loaded with item RW0037, during the month of October, flights will be loaded with RW0071 and during the month of November, RW0052 will be loaded.

'''NOTE:''' Dates should butt-up against one another and should not overlap. So in the example given, the first date range would for the initial date range would be 01-SEPT-20xx until the the 30-SEP-20xx where the generic product would be substituted for item: RW0037, whilst for the 2nd period where the generic material is replaced with item RW0071, the date range would be defined as starting on the 1-OCT-20xx and valid until the 31-OCT-20xx.

=== Market Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and you have multiple different markets defined, lets say the Markets setup are:

* Domestic (and lets suppose the airline is based in the USA)
* NAM-to-SAM (North America to South America)
* SAM-to-NAM (South America to North America)
* NAM-to-EUR(North America to Europe)
* EUR-to-NAM (Europe to North America)
* NAM-to-ME(North America to Middle East)
* ME-to-NAM (Middle East to North America)
* NAM-to-ASIA(North America to Asia)
* ME-to-ASIA (Asia to North America)
* NAM-to-AFRICA(North America to Africa)
* AFRICA-to-ASIA (Africa to North America)
* NAM-to-OCEANIA(North America to Austria, NZ & Pacific Islands - Fiji, Samoa etc)
* OCEANIA-to-ASIA (Austria, NZ & Pacific Islands - Fiji, Samoa etcto North America)
* Other

You could setup a split so that if loading was for a flight that had been matched to to the Domestic Market, 100% of the Generic Product would be replaced with item: RW0037. If however, the loading was for a flight which had been matched to the NAM-to-SAM maket, you could have a 4x way equal split across replacement items: RW0044, RW0052, RW0067 and RW0071. If the loading was for a flight matched to the NAM-to-ASIA market though, the split could be defined three ways with 60% replaced with RW0067, 30% with RW0052 and 10% with RW0071.

'''NOTES:'''
* This method relies upon the airline being set up with multiple markets.

* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if the substituion is to split the substitution across three different markets, you would need to have 2x lines at 33.3% and one at 33.4%.

* As above, you can only specify one decimal place for each split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== General Notes ===
* It is not possible to use a combination of splits, thus you can have a Day of Week split that is valid between Date-X and Date-Y.

* There is no approval process for planned substitutions, once activated, the substitution will take IMMEDIATE effect.

* It is not possible to specify a planned substitution for a specific station nor warehouse, the substitution will apply across all stations and all warehouses.

* Planned substitutions have no bearing (impact) on the requsitioning (DRP) process; planned substitutions only affect forecasting results (NWA); NWA data is used/referenced by both MRP and automatically-generated requisitions though.

* Planned substitutions only have an impact if the airline is configured with provision loadings that are matched to flights when a new forecast (NWA) is triggered, this criteria is not met not all airlines though. If NWA is managed by uploading NWA instructions via the portal, then setting up planned substitutions will not have any impact; to be clear - any planned substitutions that are defined will be redundant and will not be used when new NWA instructions are specified.

* If a planned substitution is no longer relevant, it can be deleted. Alternatively, if its merely that the percentage figures need to be adjusted/revised, such updates can be done via the portal.

* It is not possible to change the split-type once a planned substitution has been created, if the wrong split-type was specified, the substitution will need to be removed and re-created.

Substitution PlannedIndex

2021-09-20T15:31:11Z

Patrick:

{{Tips and tricks}}

To view, create and take action upon planned substitutions, go to the Reference Data main menu, on it you will see a sub-menu option for Substitutions and within that sub-menu, you will see the option for Planned Substitutions.

Depending on your access rights, you may see planned substitutions for just one or many airlines.

== '''Creating a new Planned Substitution''' ==
You can create a new planned substitution by clicking on the + (add) button on the toolbar above the data grid.

Again, depending on your access rights, you may be prompted to choose an airline; if you only have access rights for a single airline then you will not be prompted.

You will then be prompted to choose a product that will be substituted, you will need to click on the "Select Stock Item" button, a dialog will be presented to you - you can apply filters to find the item that is to be substituted/replaced (note: this may be a generic product).

Next, you will be prompted to specify a Substitution Method, the options are:

* Percentage Split
* Day Of Week Split
* Date Range Split
* Market Split

=== Percentage Split ===
So for example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and the reality is that flights will be loaded with one of 5x different red wine products, RW0037, RW0044, RW0052, RW0067 and RW0071; there will be an equal split across the five wine products, thus you could setup the planned substitution with 5x lines, one line for each of the real wines that will be loaded. As the split is equal, each line would have a loading of 20%.

'''NOTES:'''
* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if there were 3x products rather than 5x and it needs to be an even split, you would need to have 2x lines at 33.3% and one at 33.4%

* You can only specify one decimal place for a percentage split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== Day Of Week Split ===
So again, as an example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but you want your forecast to show replace that generic material with a real product and you want to show that if the flight takes off on:

* a Monday or a Saturday, then the flight will be loaded with item: RW0037.
* a Tuesday, then the flight will be loaded with item: RW0044
* a Wednesday, then the flight will be loaded with item: RW0067
* a Thursday, then the flight will be loaded with item: RW0071
* and if the flight departs on a Fridat or a Sunday, it will be item: RW0052 that's loaded

=== Date Range Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but during the month of September, flights will be loaded with item RW0037, during the month of October, flights will be loaded with RW0071 and during the month of November, RW0052 will be loaded.

'''NOTE:''' Dates should butt-up against one another and should not overlap. So in the example given, the first date range would for the initial date range would be 01-SEPT-20xx until the the 30-SEP-20xx where the generic product would be substituted for item: RW0037, whilst for the 2nd period where the generic material is replaced with item RW0071, the date range would be defined as starting on the 1-OCT-20xx and valid until the 31-OCT-20xx.

=== Market Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and you have multiple different markets defined, lets say the Markets setup are:

* Domestic (and lets suppose the airline is based in the USA)
* NAM-to-SAM (North America to South America)
* SAM-to-NAM (South America to North America)
* NAM-to-EUR(North America to Europe)
* EUR-to-NAM (Europe to North America)
* NAM-to-ME(North America to Middle East)
* ME-to-NAM (Middle East to North America)
* NAM-to-ASIA(North America to Asia)
* ME-to-ASIA (Asia to North America)
* NAM-to-AFRICA(North America to Africa)
* AFRICA-to-ASIA (Africa to North America)
* NAM-to-OCEANIA(North America to Austria, NZ & Pacific Islands - Fiji, Samoa etc)
* OCEANIA-to-ASIA (Austria, NZ & Pacific Islands - Fiji, Samoa etcto North America)
* Other

You could setup a split so that if loading was for a flight that had been matched to to the Domestic Market, 100% of the Generic Product would be replaced with item: RW0037. If however, the loading was for a flight which had been matched to the NAM-to-SAM maket, you could have a 4x way equal split across replacement items: RW0044, RW0052, RW0067 and RW0071. If the loading was for a flight matched to the NAM-to-ASIA market though, the split could be defined three ways with 60% replaced with RW0067, 30% with RW0052 and 10% with RW0071.

'''NOTES:'''
* This method relies upon the airline being set up with multiple markets.

* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if the substituion is to split the substitution across three different markets, you would need to have 2x lines at 33.3% and one at 33.4%.

* As above, you can only specify one decimal place for each split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== General Notes ===
* It is not possible to use a combination of splits, thus you can have a Day of Week split that is valid between Date-X and Date-Y.

* There is no approval process for planned substitutions, once activated, the substitution will take IMMEDIATE effect.

* It is not possible to specify a planned substitution for a specific station nor warehouse, the substitution will apply across all stations and all warehouses.

* Planned substitutions have no bearing (impact) on the requsitioning (DRP) process; planned substitutions only affect forecasting results (NWA); NWA data is used/referenced by both MRP and automatically-generated requisitions though.

* Planned substitutions only have an impact if the airline is configured with provision loadings that are matched to flights when a new forecast (NWA) is triggered, this criteria is not met not all airlines though. If NWA is managed by uploading NWA instructions via the portal, then setting up planned substitutions will not have any impact; to be clear - any planned substitutions that are defined will be redundant and will not be used when new NWA instructions are specified.

* If a planned substitution is no longer relevant, it can be deleted. Alternatively, if its merely that the percentage figures need to be adjusted/revised, such updates can be done via the portal.

* It is not possible to change the split-type once a planned substitution has been created, if the wrong split-type was specified, the substitution will need to be removed and re-created.

Substitution PlannedIndex

2021-09-20T15:29:46Z

Patrick:

{{Tips and tricks}}

To view, create and take action upon planned substitutions, go to the Reference Data main menu, on it you will see a sub-menu option for Substitutions and within that sub-menu, you will see the option for Planned Substitutions.

Depending on your access rights, you may see planned substitutions for just one or many airlines.

== '''Creating a new Planned Substitution''' ==
You can create a new planned substitution by clicking on the + (add) button on the toolbar above the data grid.

Again, depending on your access rights, you may be prompted to choose an airline; if you only have access rights for a single airline then you will not be prompted.

You will then be prompted to choose a product that will be substituted, you will need to click on the "Select Stock Item" button, a dialog will be presented to you - you can apply filters to find the item that is to be substituted/replaced (note: this may be a generic product).

Next, you will be prompted to specify a Substitution Method, the options are:

* Percentage Split
* Day Of Week Split
* Date Range Split
* Market Split

=== Percentage Split ===
So for example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and the reality is that flights will be loaded with one of 5x different red wine products, RW0037, RW0044, RW0052, RW0067 and RW0071; there will be an equal split across the five wine products, thus you could setup the planned substitution with 5x lines, one line for each of the real wines that will be loaded. As the split is equal, each line would have a loading of 20%.

'''NOTES:'''
* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if there were 3x products rather than 5x and it needs to be an even split, you would need to have 2x lines at 33.3% and one at 33.4%

* You can only specify one decimal place for a percentage split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== Day Of Week Split ===
So again, as an example, you have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but you want your forecast to show replace that generic material with a real product and you want to show that if the flight takes off on:

* a Monday or a Saturday, then the flight will be loaded with item: RW0037.
* a Tuesday, then the flight will be loaded with item: RW0044
* a Wednesday, then the flight will be loaded with item: RW0067
* a Thursday, then the flight will be loaded with item: RW0071
* and if the flight departs on a Fridat or a Sunday, it will be item: RW0052 that's loaded

=== Date Range Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions but during the month of September, flights will be loaded with item RW0037, during the month of October, flights will be loaded with RW0071 and during the month of November, RW0052 will be loaded.

'''NOTE:''' Dates should butt-up against one another and should not overlap. So in the example given, the first date range would for the initial date range would be 01-SEPT-20xx until the the 30-SEP-20xx where the generic product would be substituted for item: RW0037, whilst for the 2nd period where the generic material is replaced with item RW0071, the date range would be defined as starting on the 1-OCT-20xx and valid until the 31-OCT-20xx.

=== Maket Split ===
So, again, as an example, suppose we have a generic material, GENRED01 which is detailed in the bill of materials (BOM) loading instructions and you have multiple different markets defined, lets say the Markets setup are:

* Domestic (and lets suppose the airline is based in the USA)
* NAM-to-SAM (North America to South America)
* SAM-to-NAM (South America to North America)
* NAM-to-EUR(North America to Europe)
* EUR-to-NAM (Europe to North America)
* NAM-to-ME(North America to Middle East)
* ME-to-NAM (Middle East to North America)
* NAM-to-ASIA(North America to Asia)
* ME-to-ASIA (Asia to North America)
* NAM-to-AFRICA(North America to Africa)
* AFRICA-to-ASIA (Africa to North America)
* NAM-to-OCEANIA(North America to Austria, NZ & Pacific Islands - Fiji, Samoa etc)
* OCEANIA-to-ASIA (Austria, NZ & Pacific Islands - Fiji, Samoa etcto North America)
* Other

You could setup a split so that if loading was for a flight that had been matched to to the Domestic Market, 100% of the Generic Product would be replaced with item: RW0037. If however, the loading was for a flight which had been matched to the NAM-to-SAM maket, you could have a 4x way equal split across replacement items: RW0044, RW0052, RW0067 and RW0071. If the loading was for a flight matched to the NAM-to-ASIA market though, the split could be defined three ways with 60% replaced with RW0067, 30% with RW0052 and 10% with RW0071.

'''NOTES:'''
* This method relies upon the airline being set up with multiple markets.

* If you attempt to activate the substitution and the sum of your split percentages does not add up to 100%, you will be informed by the portal and you will be unable to activate the substitution. So, for example, if the substituion is to split the substitution across three different markets, you would need to have 2x lines at 33.3% and one at 33.4%.

* As above, you can only specify one decimal place for each split; thus 33.3 is OK whilst 33.33333 would be rounded and stored as 33.3

=== General Notes ===
* It is not possible to use a combination of splits, thus you can have a Day of Week split that is valid between Date-X and Date-Y.

* There is no approval process for planned substitutions, once activated, the substitution will take IMMEDIATE effect.

* It is not possible to specify a planned substitution for a specific station nor warehouse, the substitution will apply across all stations and all warehouses.

* Planned substitutions have no bearing (impact) on the requsitioning (DRP) process; planned substitutions only affect forecasting results (NWA); NWA data is used/referenced by both MRP and automatically-generated requisitions though.

* Planned substitutions only have an impact if the airline is configured with provision loadings that are matched to flights when a new forecast (NWA) is triggered, this criteria is not met not all airlines though. If NWA is managed by uploading NWA instructions via the portal, then setting up planned substitutions will not have any impact; to be clear - any planned substitutions that are defined will be redundant and will not be used when new NWA instructions are specified.

* If a planned substitution is no longer relevant, it can be deleted. Alternatively, if its merely that the percentage figures need to be adjusted/revised, such updates can be done via the portal.

* It is not possible to change the split-type once a planned substitution has been created, if the wrong split-type was specified, the substitution will need to be removed and re-created.

StationReturn ActiveShipmentReversals

2021-09-03T06:43:09Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

__TOC__

For SAP-centric operations an option is available <U>to efficiently return item quantities to stock after they were pick-confirmed.</U><br />
This situation typically occurs when goods were picked and are ready to load but it is found that there is no space left in the shipping container. So the goods left behind need to be returned to stock.<br />To avoid having to pseudo-receive at destination and pseudo-return the item quantities from destination, the '''shipment reversal''' feature has been developped.

Shipment reversals are triggered in SAP: DELVRY05 files for receipt confirmation (referring to the respective Station Order) will create the reversals in SkyLog.

When all these reversals refer to a single Station Order, they get '''automatched to order''' by the system and there is no further action required by the SkyLog operator.

It may well be that there are multiple files posted via EDI for the same Station Order (e.g. one file for each line item to be reversed).

Details for automatched reversals can be found [[StationReturn_HistoricShipmentReversals|'''here''']].

This secction details the valid scenario where a '''reversal EDI contains items or item quantities belonging to multiple Station Orders''' (stemming from the same requisition). <br />In this case the SkyLog operator (the respective Station Provisiong Manager) will have to manually match the reversals to the different Station Orders.

<h1>Active Shipment Reversals</h1>

SkyLog raises an alert to you (the Station Provisioning Manager) when any Shipment Reversals posted by SAP have been receipt-confirmed by the warehouse.
You will then want

* to check what items/quantities have been reversed as it may impact your DRP planning
* to match those reversals to the respective Station Order as to make sure the Station is presented with the correct items/quantities for their order tracking and subsequent confirmation of receipt

To this end you will consult the Active Shipment Reversal page:

[[file:AcitveShipmentReversalList.png|1500px]]

The page shows all Reversals posted by SAP with pending action (-> matching to order) in SkyLog.

Use the 'drop-down' icon to pre-view what items come with the reversal:

[[file:AcitveShipmentReversalDrop.png|1200px]]

To access all detail of a pending shipment reversal use the 'pencil' icon:

[[file:AcitveShipmentReversalDetail.png|1500px]]

The detail page consists of header, details and - if any- pre-matched shipments for the reversal to be actioned.
Press the '''order matching''' button to proceed with the manual matching:

<h2>Match Reversal to (Station Order) shipment</h2>

After pressing the 'order matching' button in the reversal detail screen, you are presented with the unmatched reversal line information and a list of possible orders to match the line against:

[[file:AcitveShipmentReversalMatch.png|1200px]]

The Orders are hyperlinked, you can click on the Issue Number for direct order/shipment access and validation/search of item and item quantities:

[[file:AcitveShipmentReversalItemsearch.png|1000px]]
Tip: use the filter options to search for the item in question.

To complete the action: select the Reversals and the Issues to match, then '''save''' to continue (later) and finally '''match to order''' to finalize the match.

Once all reversed shipment lines are matched to orders and the actions are finalized, the reversal will no longer shown under 'active' reversals. It will then be visible under 'historic' reversals.

StationReturn HistoricShipmentReversals

2021-09-03T06:17:24Z

Patrick:

StationReturn ActiveShipmentReversals

2021-09-03T06:09:12Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

__TOC__

For SAP-centric operations an option is available <U>to efficiently return item quantities to stock after they were pick-confirmed.</U><br />
This situation typically occurs when goods were picked and are ready to load but it is found that there is no space left in the shipping container. So the goods left behind need to be returned to stock.<br />To avoid having to pseudo-receive at destination and pseudo-return the item quantities from destination, the '''shipment reversal''' feature has been developped.

Shipment reversals are triggered in SAP: DELVRY05 files for receipt confirmation (referring to the respective Station Order) will create the reversals in SkyLog.

When all these reversals refer to a single Station Order, they get '''automatched to order''' by the system and there is no further action required by the SkyLog operator.

It may well be that there are multiple files posted via EDI for the same Station Order (e.g. one file for each line item to be reversed).

Details for automatched reversals can be found [[StationReturn_HistoricShipmentReversals|'''here''']].

This secction details the valid scenario where a '''reversal EDI contains items or item quantities belonging to multiple Station Orders'''. <br />In this case the SkyLog operator (the respective Station Provisiong Manager) will have to manually match the reversals to the different Station Orders.

<h1>Active Shipment Reversals</h1>

SkyLog raises an alert to you (the Station Provisioning Manager) when any Shipment Reversals posted by SAP have been receipt-confirmed by the warehouse.
You will then want

* to check what items/quantities have been reversed as it may impact your DRP planning
* to match those reversals to the respective Station Order as to make sure the Station is presented with the correct items/quantities for their order tracking and subsequent confirmation of receipt

To this end you will consult the Active Shipment Reversal page:

[[file:AcitveShipmentReversalList.png|1500px]]

The page shows all Reversals posted by SAP with pending action (-> matching to order) in SkyLog.

Use the 'drop-down' icon to pre-view what items come with the reversal:

[[file:AcitveShipmentReversalDrop.png|1200px]]

To access all detail of a pending shipment reversal use the 'pencil' icon:

[[file:AcitveShipmentReversalDetail.png|1500px]]

The detail page consists of header, details and - if any- pre-matched shipments for the reversal to be actioned.
Press the '''order matching''' button to proceed with the manual matching:

<h2>Match Reversal to (Station Order) shipment</h2>

After pressing the 'order matching' button in the reversal detail screen, you are presented with the unmatched reversal line information and a list of possible orders to match the line against:

[[file:AcitveShipmentReversalMatch.png|1200px]]

The Orders are hyperlinked, you can click on the Issue Number for direct order/shipment access and validation/search of item and item quantities:

[[file:AcitveShipmentReversalItemsearch.png|1000px]]
Tip: use the filter options to search for the item in question.

To complete the action: select the Reversals and the Issues to match, then '''save''' to continue (later) and finally '''match to order''' to finalize the match.

Once all reversed shipment lines are matched to orders and the actions are finalized, the reversal will no longer shown under 'active' reversals. It will then be visible under 'historic' reversals.

StationReturn ActiveShipmentReversals

2021-09-02T14:13:11Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

For SAP-centric operations an option is available <U>to efficiently return item quantities to stock after they were pick-confirmed.</U><br />
This situation typically occurs when goods were picked and are ready to load but it is found that there is no space left in the shipping container. So the goods left behind need to be returned to stock.<br />To avoid having to pseudo-receive at destination and pseudo-return the item quantities from destination, the '''shipment reversal''' feature has been developped.

Shipment reversals are triggered in SAP: DELVRY05 files for receipt confirmation (referring to the respective Station Order) will create the reversals in SkyLog.

When all these reversals refer to a single Station Order, they get '''automatched to order''' by the system and there is no further action required by the SkyLog operator.

It may well be that there are multiple files posted via EDI for the same Station Order (e.g. one file for each line item to be reversed).

Details for automatched reversals can be found [[StationReturn_HistoricShipmentReversals|'''here''']].

This secction details the valid scenario where a '''reversal EDI contains items or item quantities belonging to multiple Station Orders'''. <br />In this case the SkyLog operator (the respective Station Provisiong Manager) will have to manually match the reversals to the different Station Orders.

<h1>Active Shipment Reversals</h1>

[[file:AcitveShipmentReversalList.png|1500px]]

This page shows all Reversals posted by SAP with pending action (-> matching to order) in SkyLog.

Use the 'drop-down' icon to pre-view what items come with the reversal:

[[file:AcitveShipmentReversalDrop.png|1500px]]

To access all detail of a pending shipment reversal use the 'pencil' icon:

[[file:AcitveShipmentReversalDetail.png|1500px]]

The detail page consists of header, details and - if any- pre-matched shipments for the reversal to be actioned.
Press the '''order matching''' button to proceed with the manual matching:

<h2>Match Reversal to (Station Order) shipment</h2>

After pressing the 'order matching' button in the reversal detail screen, you are presented with the unmatched reversal line information and a list of possible orders to match the line against:

[[file:AcitveShipmentReversalMatch.png|1500px]]

The Orders are hyperlinked, you can click on the Issue Number for direct order/shipment access and validation/search of item and item quantities:

[[file:AcitveShipmentReversalItemsearch.png|1000px]]
Tip: use the filter options to search for the item in question.

To complete the action: select the Reversals and the Issues to match, then '''save''' to continue (later) and finally '''match to order''' to finalize the match.

File:AcitveShipmentReversalMatch.png

2021-09-02T13:42:35Z

Patrick:

File:AcitveShipmentReversalList.png

2021-09-02T13:42:19Z

Patrick:

File:AcitveShipmentReversalItemsearch.png

2021-09-02T13:41:58Z

Patrick:

File:AcitveShipmentReversalDrop.png

2021-09-02T13:41:41Z

Patrick:

File:AcitveShipmentReversalDetail.png

2021-09-02T13:41:08Z

Patrick:

StationReturn ActiveShipmentReversals

2021-09-02T12:18:28Z

Patrick:

StationReturn ActiveShipmentReversals

2021-09-02T12:03:20Z

Patrick:

StationReturn HistoricShipmentReversals

2021-09-02T11:40:18Z

Patrick:

StationReturn HistoricShipmentReversals

2021-09-02T11:30:03Z

Patrick: Created page with "<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles> ‘’’Please use our http://wiki.skylogport..."

StationReturn UnderReceivedIndex

2021-09-02T06:00:44Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

__TOC__

A Station Return may have resulted in an exception for different reasons:

* the receiving warehouse or station (for Station-to-Station Returns) did '''not receive the expected quantity''' (expected = what was despatch-confirmed by the returning station)
-> a balance remains in-transit -> it needs to be resolved if that balance shall remain expected, written-off, or booked back to stock at the station of origin

* the receiving warehouse or station (for Station-to-Station Returns) did '''not receive the expected item''' at all (despite its despatch was confirmed by the returning station)
-> the entire item quantity remains in-transit -> resolution is needed if the item shall remain expected, written-off or booked back to stock at the station of origin

<h1>Review Station Return Exceptions</h1>

The list page shows you all Station Return Exceptions pending for resolution, depending on your SkyLog user role you will see:

- all exceptions (if you are the ''airline/SkylogistiX administrator'' or ''airline operator'') or‎<br />
- all exceptions for the return's origin stations where you are the ''Station Provisioning Manager''

[[file:ViewStnReturnExceptions.png|1500px]]

The respective Station Provisioning Manager will receive an alert message immediately when such an exception occurs.‎<br /> To allow for the time needed to investigate and resolve an exception it is very important that Station Return Exceptions are '''resolved urgently''', because:

* if the expected balance will arrive later or will never arrive, the MRP (where the return is destined to a warehouse) or DRP (destined to another station) calculation is compromised<br />
* if the expected balance was never shipped, the origin stations inventory figures need to be adjusted, for proper validations in the next count and for accurate month-end G/L postings
* if the expected balance was never shipped and <U>if the goods-ownership changes</U> for returns (aka RMA), this will impact the invoices/credit notes for the respective sales transaction

Use the <U>magnifying glass</U> to see all the details for the Station Return Exception: items (expected vs received quantities), shipments, external references, backorder logs:

[[file:ViewStnReturnExceptionsDetail.png|1500px]]

<h1>Resolve Station Return Exceptions</h1>

Use the <U>pencil button</U> to edit/resolve the Station Return Exception:

[[file:ResolveStnReturnExceptionsDetail.png|1500px]]

* filter to view items awaiting action/resolution
* set 'quantity still expected' and 'expected date'
* set the action you wish to take (-> remain pending resolution, complete the action, cancel the exception)
* then '''save''' to continue (later) or '''submit''' to finalize with the action/s taken

the difference between the 'outstanding quantity' and the 'still expected quantity' is written off from in-transit stock.<br />if you wish to return missing quantities to origin, you need to pseudo-receive the balance by the regular process (-> instruct the warehouse or receiving station to do so) and pseudo-issue it back to the origin (by a dummy requisition, making sure the warehouse picks the pseudo-received stock), then instruct the origin-station to pseudo-receipt-confirm.

StationReturn UnderReceivedIndex

2021-09-01T10:14:35Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

__TOC__

A Station Return may have resulted in an exception for different reasons:

* the receiving warehouse or station (for Station-to-Station Returns) did not receive the expected quantity (quantity that was despatch was confirmed by the returning station)
-> a balance remains in transit and it needs to be resolved if that balance shall remain expected, written-off, or booked back to stock at the station of origin

* the receiving warehouse or station (for Station-to-Station Returns) did not receive not receive the expected item at all (despite despatch was confirmed by the returning station)
-> the entire item quantity remains in transit: resolution needed if it shall remain expected, written-off or booked back to stock at the station of origin

<h1>Review Station Return Exceptions</h1>

This list page shows you all Station return exceptions for resolution, depending on your SkyLog user role you will see:

- all exceptions (if you are the ''airline administrator'' or ''airline operator'') or‎<br />
- all exceptions for the return origin stations for which you are ''Station Provisioning Manager''

[[file:ViewStnReturnExceptions.png|1500px]]

The respective Station Provisioning Manager will receive an alert message immediately when such an exception occurs.‎<br /> To allow for the time needed to investigate and resolve the exception it is very important that station return exceptions are '''resolved urgently''', because:

* if the expected balance will arrive later or will never arrive, the MRP (where return is destined to warehouse) or DRP (destined to another station) is compromised<br />
* if the expected balance was never shipped, the origin stations inventory figures need to be adjusted, for promper validation of the next count and for accurate G/L postings
* if the expected balance was never shipped and if the goods-ownership changes for returns (aka RMA), this will impact the invoices/credit notes for the sales transaction

Use the magnifying glass to see all details for the Station Return Exception: items, received quantities, shipments, external references, backorder logs.

[[file:ViewStnReturnExceptionsDetail.png|1500px]]

<h1>Resolve Station Return Exceptions</h1>

Use the pencil button to edit/resolve the Station Return Exception:

[[file:ResolveStnReturnExceptionsDetail.png|1500px]]

* filter to view items needing action (resolution)
* set quantity expected still and expected date
* set the action you wish to take
* then '''save''' to continue later or '''submit'''

the difference between the quantity originally 'expected' and the 'quantity to be expected still' is then written off from transit stock.<br />if you wish to return missing quantities to origin you need to pseudo-receive the balance and pseudo-issue it to the origin, where again the receipt needs to be pseudo-confirmed.

StationReturn UnderReceivedIndex

2021-09-01T10:13:28Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

<pre style="color: red">/////////////////////////////////////'''SAVED, NOT FINISHED'''//////////////////////////////////////////</pre>

__TOC__

A Station Return may have resulted in an exception for different reasons:

* the receiving warehouse or station (for Station-to-Station Returns) did not receive the expected quantity (quantity that was despatch was confirmed by the returning station)
-> a balance remains in transit and it needs to be resolved if that balance shall remain expected, written-off, or booked back to stock at the station of origin

* the receiving warehouse or station (for Station-to-Station Returns) did not receive not receive the expected item at all (despite despatch was confirmed by the returning station)
-> the entire item quantity remains in transit: resolution needed if it shall remain expected, written-off or booked back to stock at the station of origin

<h1>Review Station Return Exceptions</h1>

This list page shows you all Station return exceptions for resolution, depending on your SkyLog user role you will see:

- all exceptions (if you are the ''airline administrator'' or ''airline operator'') or‎<br />
- all exceptions for the return origin stations for which you are ''Station Provisioning Manager''

[[file:ViewStnReturnExceptions.png|1500px]]

The respective Station Provisioning Manager will receive an alert message immediately when such an exception occurs.‎<br /> To allow for the time needed to investigate and resolve the exception it is very important that station return exceptions are '''resolved urgently''', because:

* if the expected balance will arrive later or will never arrive, the MRP (where return is destined to warehouse) or DRP (destined to another station) is compromised<br />
* if the expected balance was never shipped, the origin stations inventory figures need to be adjusted, for promper validation of the next count and for accurate G/L postings
* if the expected balance was never shipped and if the goods-ownership changes for returns (aka RMA), this will impact the invoices/credit notes for the sales transaction

Use the magnifying glass to see all details for the Station Return Exception: items, received quantities, shipments, external references, backorder logs.

[[file:ViewStnReturnExceptionsDetail.png|1500px]]

<h1>Resolve Station Return Exceptions</h1>

Use the pencil button to edit/resolve the Station Return Exception:

[[file:ResolveStnReturnExceptionsDetail.png|1500px]]

* filter to view items needing action (resolution)
* set quantity expected still and expected date
* set the action you wish to take
* then '''save''' to continue later or '''submit'''

the difference between the quantity originally 'expected' and the 'quantity to be expected still' is then written off from transit stock.<br />if you wish to return missing quantities to the origin station you need to pseudo-receive the balance and pseudo-issue it to the origin, where again the receipt needs to be pseudo-confirmed.

StationReturn ActiveShipmentReversals

2021-09-01T10:09:31Z

Patrick:

File:HistoricShipmentReversalMatched.png

2021-09-01T09:56:44Z

Patrick:

File:HistoricShipmentReversalList.png

2021-09-01T09:56:14Z

Patrick:

StationReturn ActiveShipmentReversals

2021-09-01T09:53:00Z

StationReturn UnderReceivedIndex

2021-08-31T14:22:48Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

‘’’Please use our [[http://wiki.skylogportal.com/index.php?title=Tips_and_Tricks '''Tips and Tricks''']] page for understanding how the SkySuite portal works and how to navigate faster and easier.’’’

<pre style="color: red">/////////////////////////////////////'''SAVED, NOT FINISHED'''//////////////////////////////////////////</pre>

__TOC__

A Station Return may have resulted in an exception for different reasons:

* the receiving warehouse or station (for Station-to-Station Returns) did not receive the expected quantity (quantity that was despatch was confirmed by the returning station)
-> a balance remains in transit and it needs to be resolved if that balance shall remain expected, written-off, or booked back to stock at the station of origin

* the receiving warehouse or station (for Station-to-Station Returns) did not receive not receive the expected item at all (despite despatch was confirmed by the returning station)
-> the entire item quantity remains in transit: resolution needed if it shall remain expected, written-off or booked back to stock at the station of origin

<h1>Review Station Return Exceptions</h1>

This list page shows you all Station return exceptions for resolution, depending on your SkyLog user role you will see:

- all exceptions (if you are the ''airline administrator'' or ''airline operator'') or‎<br />
- all exceptions for the return origin stations for which you are ''Station Provisioning Manager''

[[file:ViewStnReturnExceptions.png|1500px]]

The respective Station Provisioning Manager will receive an alert message immediately when such an exception occurs.‎<br /> To allow for the time needed to investigate and resolve the exception it is very important that station return exceptions are '''resolved urgently''', because:

* if the expected balance will arrive later or will never arrive, the MRP (where return is destined to warehouse) or DRP (destined to another station) is compromised<br />
* if the expected balance was never shipped, the origin stations inventory figures need to be adjusted, for promper validation of the next count and for accurate G/L postings
* if the expected balance was never shipped and if the goods-ownership changes for returns (aka RMA), this will impact the invoices/credit notes for the sales transaction

Use the magnifying glass to see all details for the Station Return Exception: items, received quantities, shipments, external references, backorder logs.

[[file:ViewStnReturnExceptionsDetail.png|1500px]]

<h1>Resolve Station Return Exceptions</h1>

Use the pencil button to edit/resolve the Station Return Exception:

[[file:ResolveStnReturnExceptionsDetail.png|1500px]]

* filter to view items needing action (resolution)
* set quantity expected still and expected date
* set the action you wish to take
* then '''save''' to continue later or '''submit'''

the difference between the quantity originally expected and the quantity to be expected still is then written off<br />if you wish to return missing quantities to the origin station you need to receive the balance and proceed with the '''shipment reversal''' function as described in the next chapter.

<h1>Shipment Reversals</h1>

<h2>Historic</h2>

<h2>Actual</h2>

File:ResolveStnReturnExceptionsDetail.png

2021-08-31T14:12:42Z

Patrick:

File:ViewStnReturnExceptionsDetail.png

2021-08-31T14:08:37Z

Patrick: Patrick uploaded a new version of File:ViewStnReturnExceptionsDetail.png

File:ViewStnReturnExceptionsDetail.png

2021-08-31T14:05:54Z

Patrick: Patrick uploaded a new version of File:ViewStnReturnExceptionsDetail.png

File:ViewStnReturnExceptionsDetail.png

2021-08-31T13:59:34Z

Patrick:

StationReturn UnderReceivedIndex

2021-08-31T06:59:57Z

Patrick:

StationReturn UnderReceivedIndex

2021-08-30T16:37:48Z

File:ViewStnReturnExceptions.png

2021-08-30T16:03:40Z

Patrick:

Station StationItems

2021-08-30T15:51:59Z

Patrick: Redirected page to Station Index#Stock Items .2F Par Levels

#REDIRECT [[Station_Index#Stock_Items_.2F_Par_Levels]]

Requisition Approve

2021-08-27T12:30:55Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,AIRLINEADMIN,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

Please use our '''[[Tips and Tricks]]''' page for understanding how the SkySuite portal works and how to navigate faster and easier.

__TOC__

Once a station has submitted a Requisition
* which they manually created, or
* which they reviewed after automatic generation
as the station provisioning manager you will receive an alert message asking you to validate the requistion for approval.‎<br />

The Requistion Approval pages allow you perform this validation: to check, possibly edit and finally '''approve or reject''' a requisition.‎<br />
If approved, station replenishment orders will be generated for the warehouse/s (Delivery Order) and/or to supplier/s (direct Purchase Order / Call-Off).

<h1>Requisitions awaiting Approval</h1>

use this menu trail to access the list of requisitions to be approved for the stations assigned to you:

[[File:Menutrailapprreq.png]]

----

[[File:Req2apprview.png]]

The list shows not only requistions in status 'awaiting approval'; but all editable requisistions past the review stage before their completion‎<br />(for SAP centric clients some requistion data remain editable post approval).

Use the '''filter and sort options''' to find the Requisition you need to approve.‎<br />You can use the drop down ([[file:Dropdown2.png]]) to quickly check the stock items in the Requisition.

To '''edit''' the requistion detail and eventually proceed with requistion approval/rejection, click the pencil icon [[file:20200527 Edit.png]].

<h1>Validation of a Requisition for Approval</h1>

Within the Requisition you will see ''non-editable'' '''header information''':‎<br />
requisiton number (unique ID), origin (how the requistion was created), weights/volumes (for 'approved' it updates automatically) and station comments.‎<br />The 'requested date' and 'preferred transport mode' can or need ''to be edited''.

[[File:Req2apprheader.png|1000px|]]

* '''Required Date''' - The date the order needs to arrive at the station<br />
* '''Preferred Transport Mode''' - Depending on 'station item' config there may be >1 MOT, SkyLog changes the mode automatically based on the 'required date'<br />
* '''Comment''' - you can add on to the station comment<br />
* '''Client Order Note''' - optional field for client referencing or other comments

In the '''detail section''' the order line items are list (this guide explains requisitions with status 'awaiting approval', the columns shown on the grid vary for manual Requisitions and for SAP-centric accounts):

[[File:Req2apprdetail.png|1500px|]]

This sample screen is for an <U>automatic</U> generated requisition for a <U>non-SAP centric</U> account:<br />

* '''item code, description & stock unit''' - core stock item data (click on the item code hyperlink to see the stock item summary)<br />
* '''quantity suggested''' - the quantity required to meet demand and secure sufficient coverage into the next replenishment cycle; this is calculated by automatic requisitions only<br />
use the drop down ([[file:Dropdown2.png]]) on the left from the item code to see how this quantity is calculated<br />
* '''quantity requested''' - the quantity the station places the order for<br />
* '''quantity approved''' - the quantity that you approve to process the order<br />
* '''direct delivery''' - station item setting for how to replenish. 'no' => supply from warehouse (holding xy free stock); 'yes' => place purchase order with supplier<br />
* '''Preferred Transport Mode''' - MOT for the line item (depending on the 'required date' the line item must arrive at the station to avoid stock-out, may differ from header date)<br />
* '''ship days''' - the duration assigned to the respective mode of transport (MOT), this is set in the station defaults for the corresponding station item<br />
* '''quantity in transit''' - any shipments for the line item destined to the station (click on the number hyperlink to see transit shipment details)<br />
* '''Preferred Transport Mode''' - MOT for the order line item (can be different than in header)<br />
* '''Source override''' - option to change the default setting for the source warehouse (applicable only where multiple warehouses can supply the station item)<br />
* '''Comment''' - observations made by the system (can be overwritten by station and station provisioning manager)<br />
* '''item required date''' - the date the order line must arrive at the station to prevent falling below safety stock level; calculated by automatic requisitions only<br />

<b>NOTE:</b> If the requisition was created automatically, if you expand a row on the requisition, you will see a section titled: "Explain Forecast" - in that section, you will see a label "Expected Date of Delivery After This One (End of Forecast Period)". A date may or may not be presented against it; if no date is displayed, you may see "Unknown" - this means that SkyLog has been unable to accurately determine a value (date) due to the configuration of the station par level; SkyLog cannot accurately determine a future expected delivery date if <b>"How is the item to be Requisitioned"</b> is set to either <i>Manual</i> or <i>Event</i>.

Other grid columns are shown for requisitions generated <U>manually</U> and for <U>SAP centric</U> accounts (see example under next chapter 'loading groups'):

* '''item code, description & stock unit''' - core stock item data (click on the item code hyperlink to see the stock item summary)<br />
use the drop down ([[file:Dropdown2.png]]) on the left to access additional line information (stock out date & quantity, ship days, order line weight/volume)<br />
* '''last counted inventory''' - the quantity the station reported with their last stock report<br />
* '''target float level''' - the quantity the station is expected to have in their production area (SAP centric accouts only)<br />
* '''target backup level''' - the quantity the station is expected to have in their warehouse (SAP centric accouts only)<br />
* '''target float and backup level''' - the total quantity the station is expected to have (SAP centric accouts only)<br />
* '''net consumption forecast till next delivery''' - the expected demand to cover by the present requisition (taken from external item demand forecast)<br />
* '''average consumption''' - the expected demand to cover by the present requisition (calculated by historical demand)<br />

Typically you will compare 'quantities requested' with 'quantities suggested' and where these differ, investigate further (station comment? stock availability? use of container capacity?).<br />
Any negative quantity values indicate excess-inventory that needs to be returned from the station, however, this scenario can be prevented in the [[Station_Index#Stations_creation|'''Station settings''']]. ('default negative to zero').<br />
Before approving an item line in column, check for eventual outstanding orders in the backorder logs.<br />Items can be added manually to the requisition. However, for substitutions the process is automatic, provided that the required settings have been captured. Refer to [[Substitution_UnplannedIndex#Requisitions|'''impact of Substitions in Requisitions.''']]<br /> As opposed to the process when dealing with queries at approval of inventory counts, here there are '''no query loops'''. Eventually you will need to '''approve or reject''' the entire requisition.<br /> For the validation process use the command buttons:<br />

{| class="wikitable" style="width:90%"
|-
! Button
! Function
|-
![[file:countpendingapprovalbuttonsback.png|30px]]
|Back -> leave the page without storing your work (-> status remains 'awaiting approval')
|-
![[file:countpendingapprovalbuttonssafencontinue.png|80px]]
|Save your updates made to the page and continue working on the page (-> status remains 'awaiting approval')
|-
![[file:countpendingapprovalbuttonssafenexit.png|80px]]
|Save your updates made to the page and leave the page to continue later (-> status remains 'awaiting approval')
|-
![[file:Req2apprsetall.png|80px]]
|Set all 'quantities approved' equal to 'quantities requested', mind this will only update the amout of lines on display => get all items on the page to set all quantities for the entire order (-> status remains 'awaiting approval')
|-
![[file:Req2apprclearall.png|80px]]
|Set all 'quantities approved' to 0, please mind this will only update the amout of lines on display => get all items on the page to clear all quantities approved for the entire order (-> status remains 'awaiting approval')
|-
![[file:Req2appshowdiff.png|80px]]
|Filter the order lines to show only line items where 'quantity reqeusted' differs from 'quantity suggested' (-> status remains 'awaiting approval')
|-
![[file:Req2appsetallReqDte.png|80px]]
|Copy header 'required date' to all order line items (-> status remains 'awaiting approval')
|-
![[file:Req2appsetallMOT.png|80px]]
|Copy header 'transport mode' to all order line items (-> status remains 'awaiting approval')
|-
![[file:Req2appREJECT.png|50px]]
|Irreversably Reject the requisition (-> status will change to 'rejected')
|-
![[file:Req2appAPPROVE.png|60px]]
|Irreversably Approve the requisition (-> status will change to 'complete'; for SAP-centric accounts status for change to 'awaiting schedule')
|-
![[file:Req2apprPICK.png|80px]]
|capture pick instructions for the Delivery Order posting destined to the source warehouse (-> status remains 'awaiting approval')
|-
![[file:Req2apprLG.png|80px]]
|Loading Groups function, see next chapter (-> status remains 'awaiting approval')
|-
|}

When an approval contains an item where the 'quantity approved' is > 'quantity suggested', a '''final warning''' is displayed for you to acknowledge this decsion.

<h2>Loading Groups</h2>

Depending on [[Airline_Index#How_to_create_.2F_update_the_Attributes_for_an_Airline|'''the Airline configuration''']] you can optionally create/add/edit '''loading groups''', with this function you assign the order line items to specific transportation units (Pallets, Containers).<br />Note the different grid columns for SAP-centric accounts:

[[File:Req2apprdetailSAP.png|1500px|]]

When working with loading groups, after clicking "add/edit loading groups" you can assign the various order line items to pre-defined loading groups:

[[file:Req2appLGroups.png|1600px]]

[[file:Req2appLGroupsAssignItems.png|1200x]]

File:Req2appLGroupsAssignItems.png

2021-08-27T12:29:37Z

Patrick:

File:Req2appLGroups.png

2021-08-27T12:23:36Z

Patrick:

Requisition Approve

2021-08-25T06:37:42Z

Patrick:

Requisition Approve

2021-08-24T13:27:13Z

Patrick:

<roles>SLXGLOBALADMIN,SLXLOCALADMIN,AIRLINEANALYTICS,AIRLINEADMIN,SLXOPERATIONAL,AIRLINEADMIN,AIRLINEOPS,AIRLINEMANAG,AIRLINEFIELD</roles>

Please use our '''[[Tips and Tricks]]''' page for understanding how the SkySuite portal works and how to navigate faster and easier.

__TOC__

Once a station has submitted a Requisition
* which they manually created, or
* which they reviewed after automatic generation
as the station provisioning manager you will receive an alert message asking you to validate the requistion for approval.‎<br />

The Requistion Approval pages allow you perform this validation: to check, possibly edit and finally '''approve or reject''' a requisition.‎<br />
If approved, station replenishment orders will be generated for the warehouse/s (Delivery Order) and/or to supplier/s (direct Purchase Order / Call-Off).

<h1>Requisitions awaiting Approval</h1>

use this menu trail to access the list of requisitions to be approved for the stations assigned to you:

[[File:Menutrailapprreq.png]]

----

[[File:Req2apprview.png]]

The list shows not only requistions in status 'awaiting approval'; but all editable requisistions past the review stage before their completion‎<br />(for SAP centric clients some requistion data remain editable post approval).

Use the '''filter and sort options''' to find the Requisition you need to approve.‎<br />You can use the drop down ([[file:Dropdown2.png]]) to quickly check the stock items in the Requisition.

To '''edit''' the requistion detail and eventually proceed with requistion approval/rejection, click the pencil icon [[file:20200527 Edit.png]].

<h1>Validation of a Requisition for Approval</h1>

Within the Requisition you will see ''non-editable'' '''header information''':‎<br />
requisiton number (unique ID), origin (how the requistion was created), weights/volumes (for 'approved' it updates automatically) and station comments.‎<br />The 'requested date' and 'preferred transport mode' can or need ''to be edited''.

[[File:Req2apprheader.png|1000px|]]

* '''Required Date''' - The date the order needs to arrive at the station<br />
* '''Preferred Transport Mode''' - Depending on 'station item' config there may be >1 MOT, SkyLog changes the mode automatically based on the 'required date'<br />
* '''Comment''' - you can add on to the station comment<br />
* '''Client Order Note''' - optional field for client referencing or other comments

In the '''detail section''' the order line items are list (this guide explains requisitions with status 'awaiting approval', the columns shown on the grid vary for manual Requisitions and for SAP-centric accounts):

[[File:Req2apprdetail.png|1500px|]]

This sample screen is for an <U>automatic</U> generated requisition for a <U>non-SAP centric</U> account:<br />

* '''item code, description & stock unit''' - core stock item data (click on the item code hyperlink to see the stock item summary)<br />
* '''quantity suggested''' - the quantity required to meet demand and secure sufficient coverage into the next replenishment cycle; this is calculated by automatic requisitions only<br />
use the drop down ([[file:Dropdown2.png]]) on the left from the item code to see how this quantity is calculated<br />
* '''quantity requested''' - the quantity the station places the order for<br />
* '''quantity approved''' - the quantity that you approve to process the order<br />
* '''direct delivery''' - station item setting for how to replenish. 'no' => supply from warehouse (holding xy free stock); 'yes' => place purchase order with supplier<br />
* '''Preferred Transport Mode''' - MOT for the line item (depending on the 'required date' the line item must arrive at the station to avoid stock-out, may differ from header date)<br />
* '''ship days''' - the duration assigned to the respective mode of transport (MOT), this is set in the station defaults for the corresponding station item<br />
* '''quantity in transit''' - any shipments for the line item destined to the station (click on the number hyperlink to see transit shipment details)<br />
* '''Preferred Transport Mode''' - MOT for the order line item (can be different than in header)<br />
* '''Source override''' - option to change the default setting for the source warehouse (applicable only where multiple warehouses can supply the station item)<br />
* '''Comment''' - observations made by the system (can be overwritten by station and station provisioning manager)<br />
* '''item required date''' -the date the order line must arrive at the station to prevent falling below safety stock level; calculated by automatic requisitions only<br />

other grid columns are shown for requisitions generated <U>manually</U> and for <U>SAP centric</U> accounts (see example under next chapter 'loading groups'):

* '''item code, description & stock unit''' - core stock item data (click on the item code hyperlink to see the stock item summary)<br />
use the drop down ([[file:Dropdown2.png]]) on the left to access additional line information (stock out date & quantity, ship days, order line weight/volume)<br />
* '''last counted inventory''' - the quantity the station reported with their last stock report<br />
* '''target float level''' - the quantity the station is expected to have in their production area (SAP centric accouts only)<br />
* '''target backup level''' - the quantity the station is expected to have in their warehouse (SAP centric accouts only)<br />
* '''target float and backup level''' - the total quantity the station is expected to have (SAP centric accouts only)<br />
* '''net consumption forecast till next delivery''' - the expected demand to cover by the present requisition (taken from external item demand forecast)<br />
* '''average consumption''' - the expected demand to cover by the present requisition (calculated by historical demand)<br />

Typically you will compare 'quantities requested' with 'quantities suggested' and where these differ, investigate further (station comment? stock availability? use of container capacity?).<br />
Any negative quantity values indicate excess-inventory that needs to be returned from the station, however, this scenario can be prevented in the [[Station_Index#Stations_creation|'''Station settings''']]. ('default negative to zero').<br />
Before approving an item line in column, check for eventual outstanding orders in the backorder logs.<br />If needed, items can be added manually to the requisition. However, for substitutions the process is automatic, provided that the required settings have been captured. Refer to [[Substitution_UnplannedIndex#Requisitions|'''impact of Substitions in Requisitions.''']]<br /> As opposed to the process when dealing with queries at approval of inventory counts, here there are '''no query loops'''. Eventually you will need to '''approve or reject''' the entire requisition.<br /> For the validation process use the command buttons:<br />

{| class="wikitable" style="width:90%"
|-
! Button
! Function
|-
![[file:countpendingapprovalbuttonsback.png|30px]]
|Back -> leave the page without storing your work (-> status remains 'awaiting approval')
|-
![[file:countpendingapprovalbuttonssafencontinue.png|80px]]
|Save your updates made to the page and continue working on the page (-> status remains 'awaiting approval')
|-
![[file:countpendingapprovalbuttonssafenexit.png|80px]]
|Save your updates made to the page and leave the page to continue later (-> status remains 'awaiting approval')
|-
![[file:Req2apprsetall.png|80px]]
|Set all 'quantities approved' equal to 'quantities requested', mind this will only update the amout of lines on display => get all items on the page to set all quantities for the entire order (-> status remains 'awaiting approval')
|-
![[file:Req2apprclearall.png|80px]]
|Set all 'quantities approved' to 0, please mind this will only update the amout of lines on display => get all items on the page to clear all quantities approved for the entire order (-> status remains 'awaiting approval')
|-
![[file:Req2appshowdiff.png|80px]]
|Filter the order lines to show only line items where 'quantity reqeusted' differs from 'quantity suggested' (-> status remains 'awaiting approval')
|-
![[file:Req2appsetallReqDte.png|80px]]
|Copy header 'required date' to all order line items (-> status remains 'awaiting approval')
|-
![[file:Req2appsetallMOT.png|80px]]
|Copy header 'transport mode' to all order line items (-> status remains 'awaiting approval')
|-
![[file:Req2appREJECT.png|50px]]
|Irreversably Reject the requisition (-> status will change to 'rejected')
|-
![[file:Req2appAPPROVE.png|60px]]
|Irreversably Approve the requisition (-> status will change to 'complete'; for SAP-centric accounts status for change to 'awaiting schedule')
|-
![[file:Req2apprPICK.png|80px]]
|capture pick instructions for the Delivery Order posting destined to the source warehouse (-> status remains 'awaiting approval')
|-
![[file:Req2apprLG.png|80px]]
|Loading Groups function, see next chapter (-> status remains 'awaiting approval')
|-
|}

When an approval contains an item where the 'quantity approved' is > 'quantity suggested', a '''final warning''' is displayed for you to acknowledge this decsion.

<h2>Loading Groups</h2>

Depending on [[Airline_Index#How_to_create_.2F_update_the_Attributes_for_an_Airline|'''the Airline configuration''']] you can optionally create/add/edit '''loading groups''', with this function you assign the order line items to specific transportation units (Pallets, Containers).<br />Note the different grid columns for SAP entric accounts:

[[File:Req2apprdetailSAP.png|1500px|]]

File:Req2apprLG.png

2021-08-24T13:15:50Z

Patrick:

File:Req2apprPICK.png

2021-08-24T13:13:23Z

Patrick:

File:Req2appAPPROVE.png

2021-08-24T12:53:11Z

Patrick:

File:Req2appREJECT.png

2021-08-24T12:48:11Z

Patrick:

File:Req2appsetallReqDte.png

2021-08-24T12:45:38Z

Patrick:

File:Req2appsetallMOT.png

2021-08-24T12:42:51Z

Patrick:

File:Req2appshowdiff.png

2021-08-24T12:39:26Z

Patrick:

File:Req2apprclearall.png

2021-08-24T12:36:38Z

Patrick:

File:Req2apprsetall.png

2021-08-24T12:34:30Z

Patrick:

Requisition Approve

2021-08-24T12:19:53Z

Patrick:

Requisition Approve

2021-08-24T07:54:58Z

Patrick:

File:Req2apprdetailSAP.png

2021-08-24T07:50:15Z

Patrick:

Requisition Approve

2021-08-23T20:16:44Z

Patrick: