| Oracle® Retail Enterprise Inventory Cloud Service User Guide Release 22.1.301.0 F58716-01 |
|
 Previous |
 Next |
| Oracle® Retail Enterprise Inventory Cloud Service User Guide Release 22.1.301.0 F58716-01 |
|
Previous |
Next |
Within the system, several features apply through the application across multiple functional areas. These features include the ways items are scanned and processed as well as how the feature worked based on the type of item and status of the item.
This chapter covers all aspects of item. The following topics are covered:
The system supports a variety of items, ranging from items for which no inventory is tracked (from non-inventory items and consignment and concession items) to items for which special calculations are needed, such as variable weight or UPC-E items. These items are, most of the time, used in a grocery environment.
The following are supported item barcode types:
VPN
SKU
GS1
Type 2/VPLU (A, B, C, D, E, F, G, H, I, J, K, L)
UPC #
The system also has the concept of the GS1 databar. This is an industry standard databar based on the old EAN128 format. It can contain a variety of data such as serial numbers, price, weight, and much more. Oracle has incorporated logic into the barcode tool to allow the scan of these databars and use of the embedded data for quantity, and price.
The system provides a benefit that any of these item types can be entered in any field in the dialogue and it will find the master item information.
Sometimes the vendor product number is the easiest way to look up an item. The system will return an item or list of items based on the VPN. This functionality is available in all areas of the application where users can enter or scan an item in the mobile application.
If a VPN is scanned in the DSD dialogue and two suppliers use the same VPN, SIOCS will select the item number associated to the supplier on the transaction.
Barcodes of fresh items in grocers often contain different elements beyond just the UPC.
Type - 2 supported formats contain a prefix, UPC, price, and check digit. Based on these elements, the system will extract the UPC and price, and calculate the weight based on the price.
This calculated weight will be used to increase the scanned quantity. The standard process in the system for stock counts, receiving, or shipping is to increase the quantity by one. With this functionality, the quantity will be updated with the weight of the item:
The Mobile application recognizes Type 2 items and de-construct it in price/item.
Quantity is calculated by using the embedded price.
Update the quantity entry field with the calculated quantity from the barcode.
The following table lists the supported Type 2 formats:
Table 8-1 Supported Type 2 Formats
| Format | Description | Prefix Length | Begin Item Digit | Begin Price Digit | Check Digit | Length |
|---|---|---|---|---|---|---|
|
A |
1-4-6-1 |
1 |
2 |
6 |
0 |
12 |
|
B |
1-5-5-1 |
1 |
2 |
7 |
0 |
12 |
|
C |
1-4-6-1 |
1 |
2 |
7 |
6 |
12 |
|
D |
1-5-5-1 |
1 |
2 |
8 |
7 |
12 |
|
E |
2-4-5-1 |
2 |
2 |
8 |
7 |
12 |
|
F |
2-4-5-1 |
2 |
3 |
7 |
0 |
12 |
|
G |
2-5-4-1 |
2 |
3 |
8 |
0 |
12 |
|
H |
2-5-4-1 |
2 |
3 |
8 |
0 |
13 |
|
I |
2-4-6-1 |
2 |
3 |
7 |
0 |
13 |
|
J |
2-4-6-1 |
2 |
3 |
8 |
0 |
13 |
|
K |
2-5-5-1 |
2 |
3 |
9 |
8 |
13 |
|
L |
1-6-5-1 |
1 |
2 |
8 |
7 |
13 |
Each type has a hard-coded algorithm.
Each column in the table is the start of the position in the string (0 means there is no position for it). The description explains the length of the value.
For example, format C 1-4-6-1 for item number 123456789012:
Prefix, position 1: 1
Item number, position 4: 2345
Check digit, position 6: 6
Price: 789012, or 7890.12
The weight is calculated by using the price from the label and dividing it by the current active price on file:
Two decimals are implied in the retrieved value from the barcode.
The currency for the price on the barcode is the currency of the store.
This price can be regular, promotion, or clearance.
The item's SUOM of the weight is implied.
Standard rounding is applied up to a maximum of three decimals
Example:
Item: 250010001500 is defined as format A; this means that the price is 000150 = $1.50.
The price on file for this item is $3.
The quantity is calculated as follows: 1.5/3 = 0.5.
The GS1 DataBar is a barcode symbol with embedded information. This information can be used in the store for sale and supply chain purposes. Information may include item, price, quantity, unique identification number, Country of Origin, Lot, Expiration, as well as many other fields.
The Retail Market is seeing an increase in the use of the GS1 DataBar. The system has a number of features to assist in the support of the GS1 DataBar.
The example, in the above figure, shows a 2D GS1 Databar.
The system can accommodate the GS1 DataBar. Throughout the mobile application, where there is an item entry field, the entry or scan is allowed where applicable of a GS1 DataBar. The item will be parsed from the DataBar and used on the transaction.
When entering or scanning a GS1 DataBar in the Scan bar of the mobile application, the system will parse out the item id, quantity and price and apply those to the transaction. The price is used to calculate the quantity of the item. Any other information other than Item ID, quantity and price, if present in the GS1 Databar, will be ignored.
The quantity will be parsed and applied to the transaction.
Example: 30 lbs. is in the GS1 DataBar, then 30 lbs. will be applied to the transaction.
The price will be used to calculate the quantity, if the quantity is not provided.
The same calculation will be used that is used for Type 2 items. The price from the barcode will be divided by the current price in the system to get the quantity.
Example: An apple is scanned which has a UOM of kg. The price in the barcode is $1.50. The price in the system is $3.00. The quantity will be derived by $1.50 divided by $3.0 to get .5 kg.
The system is able to provide additional visibility into the items that can be sold individually or as part of a simple or complex pack.
Features include the following:
SOH visibility to items sold individually or as part of a pack
Two indicators used to control the behavior:
Store Pack Inventory Indicator
SOH Inquiry at Pack Level Indicator
Indicators set in the Item Master application (Merchandising)
Item type in the system has been broken out and used to identify:
Simple Pack
Complex Pack
Simple Breakable Pack
Complex Breakable Pack
The system is able to provide an estimated quantity for the simple or complex pack when it is sold as both an individual component as well as in a pack.
To enable this feature for pack item, there are two indicators used to control the behavior. The Store Pack Inventory indicator tells the system when an item will only be sold and tracked as a pack. When this indicator is not checked, the item can be sold and tracked at the component level with a calculated option at the pack level.
The SOH Inquiry at Pack Level indicator is used to determine if an estimated stock on hand should be calculated for the pack when the item is sold at both component and pack level.
It is critical that the item master have these two indicators set up properly in order for the information to flow into the system properly.
The system can categorize the item by identifying whether the pack is breakable or not based on the indicators in merchandising. Breakable packs can be transacted similar to non-breakable packs, but inventory for a breakable pack will always be stored at the component level.
When a pack item is created in the external foundation system, a user can identify whether the pack is breakable or not by checking the Store Pack Inventory Indicator if the item is tracked and sold as a pack item only. The user will not need to check the indicator if the item is tracked and sold at both the pack and component level.
Next, determine if an estimated stock on hand should be calculated for a breakable pack. The SOH Inventory at Pack Level indicator is checked when an estimate should be calculated.
When the item flows into the system, additional processing will take place to correctly classify how the item will behave. Basically, there are four groupings of the pack that the system will identify as the information flows in. The system uses the type field of 15, 20, 25, and 30 to identify how the item needs to handle other types of processing, such as what displays on a stock count, and so on.
The following examples help illustrate how the calculations take place.
A company is called RKA Coffee House. The company sells various types of coffee and packages the coffee into different configurations as well as providing various gift packs.
Example 1: Simple Pack
Pack Item 500 Medium Roast Coffee 3pk contains:
| Item | Qty | UOM | SOL |
|---|---|---|---|
| 5001 Medium Roast Coffee | 3 | 8oz pkg | 1200 |
Identify the component SOH.
1200
Identify the number of components for the pack.
3
Divide the component SOH by the number needed for the pack.
1200/3 = 400
Display the pack item estimated SOH.
Pack Item 500 Medium Roast Coffee 3pk: SOH ~400
When you look up the component item, the SOH will display 1200 units. When the pack item is displayed, the SOH will display the number of packs that could potentially be sold to the customer. Since the component item could potentially be part of another pack configuration, this number is only an estimate. Therefore, the tilde ~ will be placed in front of the calculated SOH.
The next example is more complicated example. The coffee house wants to offer a sampler package in order for a customer to try different types of coffee. The coffee house will put one of each of their types of light and dark roast and two of medium roast coffee. Each of these coffee packages can also be sold individually. Additionally, there will be two of the coffee mugs with the RKA logo on the mug, added to the coffee sampler package.
Example 2: Complex Pack
Pack Item 700 Coffee Sampler contains:
| Item | Qty | UOM | SOL |
|---|---|---|---|
| 4001 Light Roast Coffee | 1 | 8oz pkg | 600 |
| 5001 Medium Roast Coffee | 2 | 8oz pkg | 1200 |
| 6001 Dark Roast Coffee | 1 | 8oz pkg | 500 |
| 7001 Medium Roast Coffee | 2 | each | 1200 |
Identify the component SOH.
Item 4001: 600Item 5001: 1200Item 6001: 500Item 7001: 1200
Identify the number of components for the pack.
Item 4001: 1Item 5001: 2Item 6001: 1Item 7001: 1
Divide the component SOH by the number needed for the pack.
Item 4001: 600/1 = 600Item 5001: 1200/2 = 600Item 6001: 500/1 = 500Item 7001: 1200/2 = 600
In order to make the Coffee Sampler, all the components and the correct quantity of components are needed. Therefore, take the lowest number calculated in this step.
Display the pack item estimated SOH.
Pack Item 700 Coffee Sampler SOH ~500
In the following example, there can be another pack item as part of the new gift pack.
Example 3: Complex Pack (Simple Pack, Complex Pack, and Individual Items)
Pack Item 750 Coffee Explorer Set contains:
| Item | Qty | UOM | SOL |
|---|---|---|---|
| 5001 Medium Roast Coffee | 2 | 8oz pkg | 1200 |
| 6001 Dark Roast Coffee | 1 | 8oz pkg | 500 |
| Pack Item 900 Passport/Slate/Woodbox Combo contains: | 1 | Pack | |
| 9001 Coffee Passport | 1 | Each | 1200 |
| 9002 Slate Serving Tray w/Chalk | 1 | Each | 600 |
| 9003 Wood Box with Stainless Steel Lid | 1 | Each | 800 |
| Pack Item 800 Set of 4 Ceramic Tasting Cups contains: | 1 | 4ct | |
| 8001 Ceramic Tasting Cups | 4 | 3oz cup | 1000 |
Identify the component SOH.
Item 5001: 1200Item 6001: 500Pack Item 900: Item 9001: 1200 Item 9002: 600 Item 9003: 800Pack Item 800: Item 8001: 1000
Identify the number of components for the pack.
Item 5001: 2Item 6001: 1Pack Item 900 (1): Item 9001: 1 Item 9002: 1 Item 9003: 1Pack Item 800 (1): Item 8001: 4
Divide the component SOH by the number needed for the pack.
Item 5001: 1200/2 = 600Item 6001: 500/1 = 500Pack Item 900 (~600): Item 9001: 1200/1 = 1200 Item 9002: 600/1 = 600 Item 9003: 800/1 = 800Pack Item 800 (~250): Item 8001: 1000/4 = 250In order to make the Coffee Explorer Set, all the components and the correct quantity of components are needed. Therefore, take the lowest number calculated in this step.
Display the pack item estimated SOH.
Pack Item 750 Coffee Explorer Set SOH ~250
The item lookup feature provides users with more visibility into the stock on hand for the packs and components of a pack through the Store Pack Inventory Indicator. If the indicator is checked, inventory will be held at the pack level and not broken down.
If the indicator is not checked, the system will break down the item to the components on the backend and all inventories will be held at the component level.
Additional information on the pack and components is available by pressing the Pack Info button and Component Info button depending on what level is being viewed.
Anywhere there is a SOH value on a screen, it may be estimated (~) if the SOH Inquiry Indicator is checked in merchandising. If the indicator is not checked, a Null value will display.
When using the shipping and receiving functions in the system, the backend processing of breaking down to the component item will be applied and the component items stock on hand will be updated for any breakable pack items.
When performing an inventory adjustment, the system will need to look to the component items' unavailable stock on hand to determine the available quantity that can be used for the adjustment.
You can sequence both simple and complex breakable packs and the components of those packs through flat file processing.
The transaction history contains the component or the pack item depending on where inventory was updated.
Features:
The Default UOM parameter is the UOM which is used until it is changed by you. This is done in the Mode Bar on the mobile application or within preferences on the desktop application. You can select between Standard UOM, Cases, and Transaction UOM. Changing the UOM will convert the quantity on the screen based upon the UOM. One exception is Stock Count Authorization, which is always in the standard UOM.
Standard UOM of Eaches: 'Each' items will be those items with UOMs that may include: units, ream, jar, pair, dozen, and so on. These cannot be broken apart into partials. Example: an each such as a shirt must remain a whole, and would have a UOM of units. You can only enter a quantity in positive whole numbers for the SUOM of Each item.
Cases: you can enter a decimal quantity for the case quantity, if the calculated quantity results in a whole number (cannot have a partial unit).
Example: Pack Size 12, Qty 1.5 Cases = 18 Units. This is acceptable as 18 is a whole number.
If the standard UOM is different than Eaches, you should have that unit of measure along with Cases as UOM options in the UOM drop down. Example: Kg and Cases:
Standard UOM other than Eaches: depending on the UOM you can enter a decimal value for the SUOM quantity.
The quantity will be restricted to a total of 4 digits and three decimal places if it is allowed to enter decimals for that specific unit of measure.
Cases: you can enter a decimal quantity for the case quantity.
Example: Pack Size 3, Qty 1.5 Cases = 4.5 LBS. This is acceptable as 4.5 LBS is feasible.
|
Note: Inventory can hold decimal values for those items that have a standard UOM other than units that allow for decimals. |
The following UOM rules are applied throughout the customer order, transfer shipping and transfer receiving dialogs wherever it refers to the UOM:
Customer Orders
Customer Order Deliveries
Customer Order Picks
Customer Order Reverse Picks
Transfer Shipments
Transfer Receipts
Transaction Unit of Measure will only be applicable in Customer Orders and Shipping and Receiving (of a customer order) where a transaction unit of measure exists. It will most likely be the Selling UOM.
In all areas where a transaction UOM is not applicable, the system uses the standard unit of measure, even though the Unit of Measure mode may be set to transaction UOM.
You can select between the Transaction UOM (that is, Lbs, Units, and so on), Standard UOM (that is, Lbs, Units, and so on) and Cases.
In the event that the Transaction UOM on the Customer Order /Fulfillment order is not recognized or cannot be converted in the system, then it will not be used, and only the Standard UOM and Cases will be used with the system defaulting to the Standard UOM.
When switching the UOM for the quantities on the screen, it will convert from Transaction UOM to Standard UOM and vice versa as well as from Standard UOM to then cases.
Stock on hand updates to the database are always made in the standard unit of measure, as that is what is held in the database.
All communication with external systems will have the quantity in the standard UOM with exception of the interface with the POS and Customer Order management systems. The POS can communicate in Sales UOM, and a customer order system could communicate in addition a transaction UOM. The Inventory system converts these UOM as needed.
The Pack Size represents the quantity of that item within a Case. The Pack Size is set up in merchandising when adding the supplier to the item. Merchandising terminology is Case Size (that is, Case Size in merchandising = Pack Size in the system). Within the system, the Pack Size for the primary supplier is used (if the supplier is unknown), otherwise it uses the pack size for the supplier that is being used (Returns /).
When referring to the Default Case Size, this is the Case size defined on the item master which is the item's primary supplier Pack size.
The Pack Size is not the number of component items within a Pack Item, rather the number of items within a case (box). Pack Size is used for all types of Items and Packs. If enabled in the Inventory system, users can override the pack size for all items and packs.
Many screens within the mobile application allow a user to enter an item quantity in both units and cases. When entering an item quantity in cases, the user can change the Pack Size of the case. The Pack Size is displayed only when the UOM is set to 'Cases'.
The pack size cannot be changed from 1 if the UOM is set to the Standard UOM.
When selecting cases, the Pack Size can be displayed or changed to a decimal value and allows decimals for any Standard UOM other than Eaches.
Example:
Item is kg and has a case size of 15.
If the UOM is set to kg, the quantity can have a decimal (15.5 kg), but the pack size can only be 1 (1 kg).
If the UOM is set to case, but the SUOM = kg, the pack size can be set to a decimal value. Example: case of 15.5kg.
How the Quantity field changes when the Pack Size changes depends on when the 'quantity' and 'pack size' fields are changed. Changing the pack size only will not change the quantity of standard unit of measure. Changing the quantity of Cases will change the quantity of standard unit of measure if the pack size is greater than 1.
Example 1:
UOM system parameter set to 'Cases':
Access a 'saved' return with a return quantity of 10 for Item A with Standard UOM as 'Units' and a pack size of 1. Note that UOM is Cases. If you set the UOM to 'Standard UOM', the return quantity will also be 10.
Set the UOM to 'Cases' and change pack size to 2. Note that the quantity field has changed to 5. The system calculates the new quantity for Cases based on the new pack size of 2.
Set the UOM to 'Standard UOM' and the quantity will still be 10 when displayed in units. The total quantity for units does not change since only the pack size was changed.
Set the UOM to 'Cases' and change the quantity of Cases from 5 to 10 (pack size still = 2). Now Set the UOM to 'Standard UOM' and the quantity will be 20. Units quantity was recalculated based on the new 'Cases' quantity with pack size = 2.
The pack size will be stored on the transaction.
You may have entered various pack sizes and the system will store the last pack size entered on the transaction.
Example 2:
Receive Item A, 10 Cases, Pack Size 10 (100 Units), then receive Item A 10 Cases Pack Size 5 (50 units). This equates to receiving 150 Units with a Pack Size of 5 (30 Cases).
|
Note: Warehouse deliveries are an exception and the Pack Size is not editable for items that exist on the ASN, as it is the Pack Size from the ASN. Unexpected items the Pack Size will be editable per the configuration. |
|
Note: Pack size is displayed on the count/recount detail screen, but is not editable. |
Consistent Scanning also addresses applying quantities from scans based upon the UOM.
For Each or Unit items, the barcode quantity will be added to the quantity on the screen in the mode of the unit of measure on the UI. In other words, the system will take the quantity from the barcode and just add that to the quantity in whatever UOM is displayed on the screen.
For Standard UOM, the quantity from the barcode is added to the quantity on the screen in the standard UOM.
Example: 3 units on the UI. The barcode is scanned for 1 unit; therefore the quantity on the UI is incremented to 4 units.
For Cases, the quantity from the barcode is added to the quantity on the screen in cases.
Example: 10 cases on the screen. Barcode is scanned for 4, now the quantity on the UI increments to 14 cases.
For items that are not Each type items, such as pounds, kilograms, meters, and so on, the barcode quantity will be added to the quantity on the screen in the Standard Unit of Measure Mode. So it assumes the quantity is in the standard UOM.
For Standard UOM, the quantity from the barcode is added to the quantity on the screen in the standard UOM.
This is the same as the preceding example for Each items.
For Cases, the quantity is added to the Standard UOM mode and then converted back to cases.
Example: 1.8 cases on the UI; this is equivalent to 18 pounds, as 10 pounds equal one case for this item. The barcode scan is for 4 pounds. The new quantity will equal 22 pounds, which will be converted back to 2.2 cases for the UI.
There are five different statuses for an item: Active, Inactive, Temporary/Auto-Stockable (Q-Status), Discontinued, and Deleted. Depending on the status of an item, certain functions may not be allowed. When an item is currently not ranged to a store, the item may be assigned a temporary active status if the system is configured to allow you to range an item. The system will treat the item as though it were in an active status with no functional restrictions.
System Parameters
Allow Non-Ranged Items
Values: Yes/No
Default: Yes
Topic: Admin
Editable: Yes
Yes: The store is allowed to add a non-ranged item to a transaction
No: The store is not allowed to add a non-ranged item to a transaction
Temporary/Auto-Stockable (Q-Status)
Before an item can be used by a store in the system, the item needs to be ranged. Ranging an item depends on two factors, the item host system (for example, Merchandising) and whether the system allows the ranging of items. If the system parameter 'Allow Non-Ranged Items' is enabled, the system allows the store to add non-ranged items to transactions.
When the system temporarily ranges an item, the item is assigned the status of 'Q.' This status is treated as though it is an active item. The item is ranged and set to Active status when Merchandising sends the item/location relationship. This will happen after the transaction that ranges the item in the system is completed. There can be a delay, or it could never happen if the transaction is never approved.
Discontinued
When an item is discontinued, the item cannot be ordered from a supplier, but it can be transferred from a warehouse or store. Discontinued items can appear on stock counts and it is possible to ship to a finisher.
Inactive
When an item is inactive, the item cannot be transferred in from a warehouse or store if the receiving location is inactive or deleted for the item. All other transfers are acceptable.
Inactive items are not allowed for Finishers.
If the item in an inactive status is on a delivery (DSD/Warehouse Delivery), the item may be received or the item may be added to the delivery. An inactive item may be received on a transfer, but cannot be transferred to another store when it is inactive at the destination store.
Deleted
When an item is deleted, the item cannot be ordered from a supplier. Deleted items cannot be transferred out from a warehouse or store if the item status in the receiving location is deleted. All other transfers are acceptable.
Deleted items are not allowed for Finishers.
If the item in a deleted status is on a delivery (DSD/Warehouse Delivery), the item may be received or the item may be added to the delivery. A deleted item may be received on a transfer, but cannot be transferred to another store when it is deleted at the destination store.
An item can be set up as inventory or non-inventory holding.
If an item's non-inventory indicator is set as 'No', then the item's inventory is tracked in the store. At the completion time of the transaction, the inventory of the item is updated depending on what has happened in the transaction for the item. In some cases, for example with notional packs, the components will be updated.
If the non-inventory indicator is set as 'Yes' for an item, then the item's inventory is not tracked in the store. However, the item is allowed to be added to most transactions (except in Inventory adjustments and Stock Counts). You will be able to enter/update quantity on inventory related transactions like shipping and receiving, just like an inventory enabled item. All the processing rules and validations that apply to inventoried items would apply for non-inventoried items except that the validations done on quantity against stock on hand will be ignored. The transactions can be completed and at the end of the transaction, no update will be made to the inventory of the item. The stock on hand will always be null for these items.
The Store Inventory system can be configured to prevent non-inventory items from being published. This can help in cases where the consuming system does not have appropriate functionality to manage such items.
An example of a non-inventory item managed by the store could be shopping bags. In most cases the retailer will want to order them, have them shipped to the store, but no inventory tracked for them.
Consignment and concession items can be interfaced as inventory or non-inventory holding items to the Store Inventory system at the location level. In essence a consignment or concession item can function now as a regular item that hold inventory or not.
Shipping consignment or concession items to another store should only be done if the supplier at the other store is the same supplier. This particular check is not performed in the Store Inventory system and any discrepancies are handled by RMFCS. If the consignment or concession item is not inventory, the Store Inventory system does allow the shipping of this item to another location as well, however RMFCS is not setup to manage this type of a transaction, and as such the recommendation is to not publish non-inventory tem transaction or leverage business process to exclude these items from shipping transactions.
The Store Inventory system supports tracking RFID items. An item can have an RFID indicator that tells item lookup that this item could have RFID zone setup. When RFID information is integrated into the Store Inventory system, the retailer has the option to also integrate zone information. This allows a user to lookup an item and know exactly where that item is located.
In addition to tracking RFID items, and updating the stock on hand quantity, the Store Inventory system also allows for stock counts and sales updates.
Stock counts will overlay the stock on hand position with the counted RFID value.
Sales updates will decrement stock on hand.
The system provides the capability to track items by unique identification numbers (UIN). If you use unique identification numbers, these numbers are displayed and tracked in a number of functional areas in the application, including deliveries, transfers, returns, and stock counts. You can also look up items by UIN.
To ensure accuracy and keep track of the UIN items, UIN items have states that can shift when they are added to different transactions. A full audit trail by user allows for close tracking on what has transpired with those items.
Features
UINs can be of two types:
Serial Number
Serial numbers are unique identifiers for individual instances of an item, typically attached to items by the manufacturer. During receiving, the serial numbers must be scanned and associated with items.
Auto-Generate SN (AGSN)
AGSNs are serial numbers generated by the system that you can use to identify each instance of an item.
When an item is set up in the Merchandising system, you enter a description for the item. The long description of the item is displayed in the desktop application. In mobile, either short or long description is displayed based on the parameter setting.
Oracle's merchandising system now publishes Item descriptions independently of item and the Store Inventory system subscribes to that message. The Item description message may contain translated information for the descriptions associated to an item as well as secondary descriptions. If configured, the Item description displayed in the desktop and mobile application can be in the user's preferred language independent from the store location language, provided translation is available for that language.
