| Oracle® Retail Allocation Operations Guide Release 13.2.9 E72187-01 |
|
 Previous |
 Next |
This chapter of the operations guide is intended for administrators who provide support and monitor the running system.
The content in this chapter is not procedural, but is meant to provide descriptive overviews of the key system parameters.
This chapter consists of the following sections:
|
Note: For information about Oracle Single Sign-On and Oracle Retail Allocation 13.2.3.1, please see the latest Oracle Retail Allocation Installation Guide. |
For information about requirements for Oracle Retail Allocation's database server, application server, client PC, and web browser, see the Oracle Retail Allocation Installation Guide.
Oracle Retail Allocation-related exceptions are handled through AllocException. AllocException is located in the following package:
com.retek.alloc.utils
The following types of exceptions are wrapped by AllocException:
Errors are logged to the error log file, error_messages.log. For information about error logging, see the section Logging later in this chapter.
The Item Source Default setting determines the default search type used on the Item Search page. This parameter is specified in the Allocation.properties file. The valid values are:
For example:
item_source_default = W
|
Note: The system only allows for one default to be set. |
A backend system administrator defines configurations for Oracle Retail Allocation in the Allocation.properties file. The key system parameters contained in this file are described in this chapter. When retailers install Oracle Retail Allocation into an environment, they must update some of these values to their applicable settings. Properties files can be edited through a text editor.
The Oracle Retail Allocation Installation Guide contains step-by-step instructions as to how to configure some of the environment-related values in the Allocation.properties file.
The fashion_item_loc_ranging_validation_logic property setting allows the user to define the following:
If the allocation will take place for a fashion item only if the ranging as well as item/location status checks for a style/color item are satisfied at the parent item level as well as all the child items (current behavior).
If the allocation will take place for a fashion item as long as the parent item and at least one of the child items are ranged and have a valid item/location status. The child items which are not ranged or do not have a valid item/location relationship will not be considered while allocating goods.
This defines the connection driver that the application uses to connect to the database. This only changes if you are using a non-Oracle database.
For example:
driver=oracle.jdbc.driver.OracleDriver
The TDM Enabled setting is only utilized internally by Oracle Retail. Retailers should have this value set to false.
For example:
tdmEnabled=false #### for Alloc 11.1 TDM url=jdbc:oracle:thin:@mspdev18.retek.int:1521:alctdm02 username=alcdev111tdm datasource=rms11
When Oracle Retail Allocation is packaged and shipped, included is the database driver used, the URL for the application, and the username. For example:
#### for Alloc 11.1 TDM url=jdbc:oracle:thin:@mspdev18.retek.int:1521:alctdm02username=alcdev111tdmdatasource=rms11
Logging files should be set up to valid directories, so that you can generate logs regarding errors and messages. For more information about the connection pool, see the passage, Minimum and Maximum Pool Size to Maintain in this chapter and see the passage Pooling in Technical Architecture.
The example below shows the default Oracle Retail settings:
For example:
# Log file for connection pool: one for Windows, and another for UNIX unix.pool.log=/u01/webadmin/oc4j_envs/oc4j904_alc11/j2ee/home/log/alc11dev-connection_pool.log # Log file for Error messages: one for Windows, and another for UNIX windows.error.log=c:\\develop\\alloc11.1\\log\\error_messages.log unix.error.log=/u01/webadmin/oc4j_envs/oc4j904_alc11/j2ee/home/log/alc11dev-error_messages.log windows.pool.log=c:\\develop\\alloc11.1\\log\\connection_pool.log
This setting defines the location of the file where the retailer would like the log file written.
For example:
logpath=C:/logs/log.txt
This setting defines the lowest level logs to be written to the log file. The following list represents the log priority levels in ascending order:
UNKNOWN
FATAL
ERROR
WARN
VALIDATION
INFO
DEBUG
For example:
loggerLevel=ERROR
This setting defines if the retailer would like to be emailed upon the logging of a message. The valid values are 'true' and 'false'. By default this setting is set to false due to high volume of emails that could be received.
For example:
loggerEmailEnabled=false
Default Log Email Address Recipient
This setting defines the default email address of the account that receives emails of a log when email logging is enabled.
|
Note: If the loggerEmailEnabled setting is false, this should be set to null. |
For example:
defaultEmailAddress=someone@oracle.com
Default Log Email Address Sender
This setting defines the default email address of the account that sends the emails of a log when email logging is enabled.
|
Note: If the loggerEmailEnabled setting is false, this should be set to null. |
For example:
loggerEmailFromAddress=someone@oracle.com
This setting defines the log e-mail's subject.
|
Note: If the loggerEmailEnabled setting is false, this should be set to null. |
For example:
loggerEmailSubject=Allocation Alert Message
This setting determines the log level that emails should be sent out for. This setting is secondary to the loggerLevel setting. This setting uses the same log hierarchy as defined in loggerLevel.
For example:
loggerEmailLevel=ERROR
This setting informs the logger if the Unix syslogging is enabled. The valid values are 'true' and 'false'. This setting is false, if not running on an Unix environment.
For example:
loggerSyslogEnabled=false
This setting informs the logger of the Unix syslog host's IP address.
|
Note: If the loggerSyslogEnabled setting is false, this should be set to null. |
For example:
loggerSyslogHost=10.10.10.10
This setting determines the log level that should be recorded by the Unix syslog. This setting is secondary to the loggerLevel setting. This setting uses the same log hierarchy as defined in loggerLevel.
For example:
loggerSyslogLevel=ERROR
This setting defines the maximum size in bytes that the log file can reach before it is rolled over.
For example:
loggerMaxFileSize=100000000000000
Number of Rolled Over Log Files
This setting defines the maximum number of log files that the system should keep.
For example:
loggerMaxBackupIndex=100
This setting defines if the logger should write to the log file in its own thread. The valid values are 'true' and 'false'.
For example:
loggerAsynchMode=true
This setting defines the default-logging format for the logging system. All of the Log4j patterns are supported in addition to the following:
h: Localhost name
i: Database username
u: Database url
a: Application name
k: Exception message
d: Date/Timestamp
p: Severity
c: Location
For example:
log4jLayout=%n#### <Date / Time: %d{dd MMM yyyy HH:mm:ss,SSS}><Severity Level: %-5p><Host Name: %h><DB User: %i><DB URL: %u><Location: %c><Message: %k>%n
Redirect System.out and System.err
This settings defines whether the logger should redirect all System.out.* and System.err.* statements to the log file. The valid values are 'true' and 'false'.
|
Note: This setting affects the entire Java Virtual Machine. |
For example:
loggerCloseStdOutAndErr=false
Debugging parameters may be set to write dat files to a file and show the application the parameters sent to the algorithm. In a production environment, this setting should be set to false.
For example:
# DEBUG mode on/off switch for application logging. This prints out the dat file # DEBUG mode on/off switch for application logging. This prints to the console a commented #version of the alloc2Param that is sent #to the algorithm. debugCalcParms=false IS_DEBUG_MODE=false
This value can be set to true if you want to view all of the SQL statements that are being executed by the system. The majority of the time, this value should be false.
For example:
#Trace? #SQL Trace Level trace=false
#traceLevel=1 traceLevel=8 #traceLevel=12 #traceLevel=4
The pool size pertains to the number of available database connections that you intend to keep available in the pool. A system administrator is encouraged to adjust these values per configuration to match the retailer's anticipated number of users. The default values are intended to be a starting point. For more information, see the passage Pooling in Technical Architecture.
For example:
# Minimum and maximum pool size to maintain pool.max=10 pool.sqltrace=FALSE pool.implicitCache=TRUE pool.min=5
The calculation queue polling interval determines the frequency that the queue table is queried for requested algorithm calculations for allocations that need to be calculated. By default, the calculation queue is polled once every five seconds. Also, the calculation input mode on/off switch should be set to true if you need to view the dat files returned from the algorithm. You also determine the file location to send the dat files.
For example:
calculation queue polling interval in ms. # calculation input mode on/off switch for writing .dat files calculationQueuePollingInterval=5000
logCalcInput=false # Log file for Error messages: one for Windows, and another for UNIX windows.calcInputLogDirectory=c:\\calculation_dat_files unix.calcInputLogDirectory=/files0/alloc10/calculation_dat_files
This setting defines the display language for the user interface. The translated properties files are identified by the ISO language code for each language and country. The language/country combination specified in Language to be Loaded must match the properties files naming convention. For additional details see the Internationalization section later in this chapter.
The default is:
language=en country=US
Item location warning may be set to tell the application to check for possible invalid item/location combinations where the status of the location is closed, inactive or deleted. If it is closed, inactive or deleted, Oracle Retail Allocation displays a warning message telling the user that some of the item/location combinations are invalid. You can then view the invalid combinations and rectify the situation accordingly.
For example:
#itemLocWarn item_loc_warn=true
The type of Oracle Retail Allocation product purchased can be set as full or lite. If the lite version has been purchased, the user does not have access to the following functionality: complex groups, weeks from today, and 'what if' allocations.
For example:
#Type of allocation. #allocType=LITE allocType=FULL_VERSION
The system administrator establishes this value to inform the system what that end of the weekday is. Sunday is equal to 1, and Saturday is equal to 7. Note that this day must be identical to that set up in the merchandising system (such as RMS).
For example:
end_of_week_day=1
During a purchase order creation from a 'what if' allocation, the system uses a default number of days before the release date on the allocation as the not before date on the purchase order. Oracle Retail Allocation does not know the start ship date. Thus, this value has been added behind the scenes. The start ship date is derived from x days before the release date set in Oracle Retail Allocation. This number is pre-set to '3' days before the release date and can be changed by the system administrator.
For example:
days_before_release_date=3
When a user creates a bulk purchase order (PO) during a 'what if' scenario, the PO is cut to this designated warehouse. The retailer should make sure that this bulk warehouse is associated with a valid warehouse in the merchandising system (such as RMS). The default value is intended to be a starting point.
For example:
# bulk_wh indicator bulk_wh=1
This security feature is to prevent a user from walking away from the application and leaving an allocation in progress. After this value (in minutes) of inactivity, Oracle Retail Allocation returns the user to the home page and unlocks the specific allocation that he or she was working on. The system is then available for the use of anyone with security access. This value is set at 30 minutes and should by in sync with the session timeout based on the server.
For example:
unLock.minutes=30
This security feature sets the maximum time in seconds that a physical connection can remain idle in a connection cache. When the Inactivity Timeout expires, the underlying physical connection is closed. The property in allocation.properties file is: conn.inactivity.timeout.
For example:
conn.inactivity.timeout=604800
This security feature sets the maximum time (in seconds) that a connection can remain unused before the connection is closed and returned to the cache. The default value is 0 (no timeout in effect). The property in allocation.properties file is: conn.abandoned.timeout.
For example:
conn.abandoned.timeout= 900
Oracle Retail Allocation utilizes Bayesian forecasting in its Plan Re-project Rule. The sensitivity factor is described below and is pre-set at .3. A system administrator can change the setting anywhere from zero and one.
For example:
plan_sensitivity=.3
A higher sensitivity setting makes the forecast more reactive to actual sales, and a lower setting makes the forecast less reactive to sales.
Description of Bayesian Sensitivity
Oracle Retail Allocation's Plan Re-project Rule utilizes a Bayesian method to re-project the future dates of the plan. The rule takes sales history and compares it with the plan to create a forecast. This forecasting algorithm thus merges a retailer's sales plans with any available historical sales in a Bayesian fashion (that is, the algorithm uses new information to update or revise an existing set of probabilities). A retailer would use this rule mid-season to allocate products based on actual sales results to date and planned sales.
Bayesian forecasting assumes that the shape sales takes is known, but the scale is uncertain. In Bayesian forecasting, when no sales history is available, the sales forecast figures are equal to the sales plan figures because there is no reason to mistrust the sales plan. As point-of-sale data becomes available, the forecast is adjusted and the scale becomes a weighted average between the initial plan's scale and the scale reflected by known sales history. Confidence in the sales plan is controlled by the amount of sales data on hand and a Bayesian sensitivity constant (which, as mentioned earlier, the system administrator can set from zero to one). Unlike standard time series forecasting, which requires only sales history to produce a forecast, Bayesian forecasting requires a sales plan and sales history (if available). As sales information arrives during the first few weeks of the season, the model generates a forecast by merging the information contained in the sales plan with the information contained in the initial sales data. These forecast updates can be critical to a company's success.
For more information, see the section Plan Re-project Algorithm in Allocation Calculations.
The system administrator initially establishes the default order and settings of the application's columns. When a user customizes his or her windows, the result is saved and continues to appear in that configuration until changed again. The default user ID (for flexible columns) is 1, which means that the user sees the column arrangement that Oracle Retail has designed.
For example:
default_user=1
The automatic group updates setting allows control over whether or not the system automatically updates location groups every time the user enters a worksheet allocation. Note that if a front end user selects the "never update" check box, automatic updates do not occur even if the system administrator has set the automatic value update in the properties file.
For example:
auto_update_groups=true
If Oracle Retail Allocation is run in a language other than English, this value must be true. The value ensures correct population of all LOV field values.
For example:
lov_on_change=false
Oracle Retail Allocation allows you the ability to respect or ignore the order setting in RMS purchase orders when calculating the stock on hand for an allocation. This is an option because some allocators require visibility to all goods on order to effectively manage their warehouse and store inventories, regardless of the ordering status.
For example:
#when calculating stock on hand #where ORDHEAD.INCLUDE_ON_ORDER_IND='N' all_orders=true #false will not recognize order quantities on orders
This value determines whether or not the system uses the estimated future cost calculation based on the in store date, release date, and transportation time in conjunction with the ALC_FREIGHT_COST table.
For example:
enable_freight_cost=true
This setting allows you to set pack ranging/validation option for Non Sellable Staple Packs. The valid values are 'true' and 'false'. By default this setting is set to true.
If the value is true, ranging and validation occurs at the pack level. It is expected that all components within the pack will share the same item/location status.
If the value is false, ranging and validation occurs at the component level. All components must be ranged and all components are expected to have the same valid item/location status.
For example:
staple_pack_range=false
|
Note: This attribute for Non Sellable Staple Packs is not applicable to Pack Distribution mode. For Pack Distribution mode, item ranging and validation always occurs at the pack level. |
This properties file setting is only applicable if the retailer is utilizing the Oracle Retail Price Management (RPM) application. If the retailer does not have RPM, this value needs to be set to false. The system allows the retailer to choose whether it wants the future retail price displayed on the details screen. If a retailer uses future retail pricing to determine the future value of an allocation, this parameter should be set to 'true'.
If a retailer creates or approves allocations without factoring in future retail pricing, the retailer should set this parameter to 'false'.
For example:
enable_future_retail=false
This properties file setting is only applicable if the retailer is utilizing the RPM application. If the retailer does not have RPM, this value needs to be set to false. Enabling this setting in the properties file takes default promotions associated with orders and automatically associates them with the allocation.
For example:
enable_promotions=false
Using this parameter, the retailer has the option to disallow allocations that cross legal entities. Legal entities are the locations in an organization grouped together due to legal requirements. Legal entities can be defined by brand, geography, country or some other grouping defined by the retailer. Issues in crossing legal entities can arise related to changes in cost and retail pricing, ownership, bookkeeping, and so on.
If you select 'Y', allocations cannot cross legal entities. Oracle Retail Allocation validates whether a warehouse/location combination is valid before processing. If a warehouse/location combination is not part of the same legal entity, the combination is skipped for processing. The system moves to the next combination.
Note: When a retailer selects 'Y', the system allows the user to select invalid combinations. The system does not process these when calculating need.
If you select 'N', allocations can cross legal entities.
Parameter:
# Indicates whether or not the user can cross legal entities # 'N' indicates Allocation can cross legal entities enforce_MLE=N # 'Y' indicates Allocations can not cross legal entities
|
Note: The Oracle Retail enterprise does not support the population of the ALC_SHIPPING_SCHEDULE. This effort must be a part of the retailer's implementation of the application. |
This parameter determines first whether or not the system allows allocations to be created from a warehouse to a warehouse. Secondly, this parameter determines the data sources for the MLD path. The valid values are shown below along with a description for each. For more information about MLD, see the section Multi-level Distribution (MLD) in Functional Design.
0 = Non-MLD The system continues to utilize the default warehouse value on the store table as its supply chain information.
1 = MLD using the TRANSIT_TIMES table Retailers leverage the TRANSIT_TIMES table data that is maintained within RMS.
2 = MLD using the ALC_SHIPPING_SCHEDULE table The Oracle Retail Allocation-owned table, ALC_SHIPPING_SCHEDULE, allows the retailer to have a single view of a shipping schedule that is more detailed than the RMS-owned TRANSIT_TIMES table.
Include Mid Tier on Hand Default
This value determines whether or not to include mid tier stock on hand check box on the Select Rules Screen is checked or unchecked. Valid values are true and false.
For example:
multi_level_distribution=true include_mid_tier_soh=true
Allow Flexible Import Warehouse Paths
This value determines whether or not flexible warehouse paths settings are enabled.
For example:
allow_flexible_import_warehouse_paths=true
Enable MLD Tier Deletion
This properties file determines whether or not you have the ability to delete an entire tier of allocations from within the MLD Tier Screen. Values are True or False. False equates to the delete check box column's not appearing in the MLD Tier Screen. True equates to the presence of the tier deletion.
For example:
enable_mld_tier_deletion=true
Break Pack Enforced
This property file setting determines if break pack functionality is enabled or disabled.
For example:
break_pack_enforced=Y
This properties file setting determines the Include lead time check box default setting on the Select Rules page in Oracle Retail Allocation. Valid values are Y or N.
For example:
include_leadtime_need=N
This properties file setting determines the Presentation minimums and Quantity limit check box default setting on the Select Rules page in Allocation.
For example:
default_presentation_minimum=true
This properties file setting gives the retailer the ability to determine the default value for the store or PO calculation multiple. Valid values are pallet, case, inner, and each.
For example:
store_calc_multiple=IN
This allows the retailer to define the status of item location relationships that you would like to exclude from the product sourced allocation. In the Oracle Retail Merchandising System the possible item location statuses include Active, Inactive, Discontinued, Deleted or NULL.
For example:
location_exception_reasons_product_sourced=C D I NULL
This allows the retailer to define the status of item location relationships that you would like to exclude from 'what if' allocations. In the Oracle Retail Merchandising System, the possible item location statuses include Active, Inactive, Discontinued, Deleted or NULL.
For example:
location_exception_reasons_what_if= C D I NULL
The import warehouses properties file setting must be set for all MLD retailers. The value defines the warehouse(s) that serves as the tier 1 level in the MLD path. These should be the retailers import warehouses. All tier 1 warehouses must be listed. These warehouses are used in all MLD item sourced allocations and Item Source Tier What If allocations.
For example:
import_warehouses=66,67
This setting determines the warehouse to use as the import based purchase order to location. Valid values are any warehouse numbers within RMS. The warehouse entered should be designated as the primary import warehouse. This value is only valid if the 'Allow flexible import warehouse paths' value is Y.
For example:
default_what_if_import_warehouse=1111111112
This setting enables the retailer to determine whether the What If Summary screen should default to 'Create PO' or 'Update PO' view. The values entered are numerical, 1 for create, and 2 for update.
For example:
what_if_summary_default_action=1
This properties setting is used during the 'what if' calculation process and the 'What if' summary purchase order (PO) creation process. The setting determines whether or not the system should use future expected inventory or current stock on hand (SOH) at the warehouses during the calculation of quantities for PO creation and PO update. Valid values are the following:
'True' The selection of the Include Supply Chain On Hand check box for an item source location based 'what if' allocation determines whether or not the expected inventory and current available inventory in the supply chain are accounted for in the 'what if' allocation.
'False' The selection of the Include Supply Chain On Hand check box for an item source location based 'what if' allocation accounts only for the current available inventory.
For more information about 'what if' functionality, see the Oracle Retail Allocation User Guide and the section, 'What if', in Functional Design.
This is only be utilized by Oracle Retail. All customers should have this value set to false.
For example:
enable_conn_pool_monitor=false
This setting enables you to specify whether or not you want size profile validation to occur when selecting the calculate button. If this value is set to false, the validation occurs as part of the off line calculation process.
For example:
enable_size_profile_validation=true
|
Note: In cascade mode only, the size profile is bypassed and not used for calculating the allocation for fashion items. Using size profile restricts the size distribution of a hierarchy level across multiple locations. |
This setting enables the retailer to specify whether you want the default LOV display to be IDs or descriptions.
For example:
lov_layout_first_value=id\
Indicates whether Oracle Retail Service Layer (RSL) for Oracle Retail Pricing Management (RPM) is running on an IBM application server. The valid values are 'true' and 'false'.
For example:
rsl_rpm_ibm_server=false
|
Note: The parameter below is only valid for those retailers who have selected the value '2' in the property parameter, 'Supply chain path setting (distribution_level)', described earlier. |
For example:
alc_shipping_schedule_path_levels=D,I
The parameter defines the hierarchy level on which the system queries the ALC_SHIPPING_SCHEDULE table. The levels selected must include all the path levels at which the retailer defines its supply chain. Each level added has a performance impact. Therefore, it is recommended that the retailer use one or two levels to maintain their shipping schedules. This parameter is necessary to ensure acceptable levels of performance during product searches. Note that a retailer can enter multiple levels separated by a comma. The first value represents the primary level of the hierarchy that is queried, and the ensuing values represent exceptions in other hierarchies. For example, if a retailer selected 'D,I', the system queries the table first on a department level and then searches for item exceptions. The valid values are the following:
D = department
C = class
S = subclass
I = item
This configurable setting allows the retailer to determine whether they want to use the sister store need whenever the need is calculated as zero or only when no need records exist for each location. The property in allocation.properties file is: sister_store_null. The valid values are 'true' and 'false'.
For example:
sister_store_null = true sister_store_null = false
The system uses the sister store's need when the records don't exist for a store's need.
The system uses the sister store's need when the records don't exist for a store and when there are existing records and their need equals zero.
This property allows the retailer to choose whether he wants to correct the user-entered value on the Allocation Details page to the minimum supplier pack size. The user can decide if he wants the correction to the minimum supplier pack size or not. The valid values are 'true' and 'false'.
For example:
round_fashion_on_alloc_details_apply = true round_fashion_on_alloc_details_apply = false
The default value of round_fashion_on_alloc_details_apply is set to true.
This setting allows the retailer to determine whether they want to view the lowest merchandise hierarchy data available for the plan or forecast. The property in allocation.properties is: ruleVisibility. The valid values are '1' and '2.' '1' is for plan, and '2' is for forecast.
For example:
ruleVisibility = 1 ruleVisibility = 2
This configurable setting allows the retailer to set the size of the connection cache when the cache is initially created or reinitialized. When this property is set to a value greater than 0, that many connections are pre-created and are ready for use. The property in allocation.properties is: pool.initial.
For example:
pool.initial = 3
RPM validates the user data sent by Allocation before authenticating the user. This setting allows the retailer to send valid user data to RPM. The property in allocation.properties is: rpm_secure_user.
For example:
rpm_secure_user = User Name
Used to set the oracle SQL trace level.
Trace levels are used to define the type of information in the trace file. There are a number of different trace levels, which generate different logging information.
Levels of trace
1 – Standard SQL trace number, no wait events, or bind variables.
4 – Bind variables only
8 – Wait events only
12 – Bind Variables and Wait Events
This is the location IN list threshold value. It builds IN lists for queries when the list of values is below this value. If this value is not set, all values must be queried and filtered manually in the application to increase performance.
Default date format used within the application. The Formats may also be set per language, in the appropriate text properties file.
Used to configure whether the seconday description of the item should be displayed or not in the LOV popup. This information is available in the RMS Item Master data.
True - Display secondary description of the item in LOV popup.
False - Do not display the secondary description of the item in LOV popup.
Used to specify the source tier query level items of what if item's which is configured with any one of the following levels.D=department, C=class, S=subclass or I=item.
Used to indicate if Future Available inventory must be used while performing the What If Allocations calculations.
True - Use the future SOH
False - Use the current SOH only
Specify the levels at which the size profile validation must be done for a fashion item.
Valid values are STYLE, SUB-CLASS, CLASS, DEPT
|
Note: More than one value can be specified using comma as the delimiter. |
Indicates if the Oracle Retail Service Layer (RSL) for RMS is on. This is used to send "What-If" POs in the "Worksheet" status back to RMS.
Used to configure the technique used to distribute Quantity Limits within a location Group.
True = This means values entered against Group in QL are copied to the stores in the group.
False = This means values entered against Group in QL are spread to the stores in the group.
The JNDI settings are contained in the file jndi_providers.xml. Oracle Retail Allocation uses this file as part of its RSL-based integration with RPM. The JNDI providers file contains the RSL server information for the Oracle Retail application that Oracle Retail Allocation calls. When the retailer deploys Oracle Retail Allocation, this file must be configured to point to the application server where RSL for RPM resides, which provides future retail pricing information. For the steps to configure this file, see the Oracle Retail Allocation Installation Guide.
Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market. Allocation has been internationalized to support multiple languages.
This section describes configuration settings and features of the software that ensure that the base application can handle multiple languages.
Translation is the process of interpreting and adapting text from one language into another. Although the code itself is not translated, components of the application that are translated include the following:
Graphical user interface (GUI)
Error messages
The following components are not translated:
Documentation (Online Help, Release Notes, Installation Guide, User Guide, Operations Guide)
Batch programs and messages
Log files
Configuration tools
Reports
Demonstration data
Training Materials
The user interface for Allocation has been translated from U.S. English into the following languages:
Chinese (Simplified)
Chinese (Traditional)
Croatian
Dutch
French
German
Greek
Hungarian
Italian
Japanese
Korean
Polish
Portuguese (Brazilian)
Russian
Spanish
Swedish
Turkish
The user's preferred language and country must be specified for the USER_ID on the ALC_USERS table in the LANGUAGE and COUNTRY columns. The two-letter ISO language and country codes must match the same language/country code combinations as specified in the allocation.properties file.
The Java compiler and other Java tools can only process files which contain Latin-1 and/or Unicode-encoded (\udddd notation) characters. The JDK native2ascii tool converts files which contain other character encodings into files containing Latin-1 and/or Unicode-encoded characters. The translated properties files are all shipped in the Unicode-encoded (\udddd notation).
The translated properties files are identified by the ISO language code for each language and country. The following files are provided in Allocation:
allocation_text_de_DE.properties
allocation_text_es_ES.properties
allocation_text_fr_FR.properties
allocation_text_it_IT.properties
allocation_text_ja_JP.properties
allocation_text_ko_KR.properties
allocation_text_pt_BR.properties
allocation_text_ru_RU.properties
allocation_text_zh_CN.properties
allocation_text_zh_TW.properties
allocation_text_el_EL.properties
allocation_text_hr_HR.properties
allocation_text_nl_NL.properties
allocation_text_sv_SE.properties
allocation_text_tr_TR.properties
allocation_text_hu_HU.properties
allocation_text_pl_PL.properties
To provide a user-friendly date format that is understood by the users, a number of date formats are available.
The date tag handles the display and selection of dates from the calendar widget. The date tag passes the appropriate date format from the user in the session. (Note that date formats are defined in each language text properties file, allowing for the appropriate date format based on that particular language. The default date format still resides on the allocation.properties file, and should be accessed through the AllocTextPropertiesFactory.)
