glog.business Properties

glog.business.action.changeEquipmentGroupCompatibilityCheck

20B

This determines if the "Change Equipment Group" action should check the constraints for the order release, the location, and the itinerary leg. When enabled, OTM will check the constraints. This is off by default.

glog.business.action.shipment.rerateredrive.ignoreOperationalDates

19B

This property impacts redriving upstream and downstream shipments.

When true (the default), the Rerate and Redrive action will allow the upstream and downstream shipments the freedom to redrive regardless of the operational dates (they will be completely ignored).

When false, the action honors the Operational Late Delivery of upstream shipments and the Operational Early Pickup of downstream shipments (when redriving upstream or downstream shipments).

glog.business.autoassign.pushObjectDomain

The logic for auto assign rules impersonates the domain of the object being created, if it is available, when obtaining the list of auto assign rules to run. Values can be set to True or False.

Default: True

When False, any rules visible to the logged-in user will be used as opposed to the domain of the object. (Setting this property to False matches the functionality prior to version 5.5.)

glog.business.buildShipmentOnPrimaryLeg.sortItineraryBasedOnNumOfLegs

23A

When this property is set to true, the Build Buy Shipment on Primary Leg action will sort the itineraries based on the number of legs in ascending order, and return the first solution when a shipment is successfully built on the leg.

Default: false

glog.business.claim.CreateClaimLinesFromExtSys.className

glog.business.claim.UpdateClaimLinesToExtSys.className

These properties configure the client-created Java classes used to create claim lines in Oracle Transportation Management from an external system and update data from claim lines to an external system. If you want the Oracle Transportation Management claim interface to read from and write to a client-created external system, Java code can be written to interface with that system.

glog.business.conopt.ConoptCostCalculator.createArbStops

23C

This property determines whether the Container Optimization Cost Calculation logic will check via point stop arbitraries when determining whether an equipment group has a usable port-to-port rate for a specific source-destination location combination. The logic is needed to ensure, for the arbitraries scenario, that the Container Optimization logic does not select an equipment group without a usable rate. The default is true.
This property can be set to false if every equipment group in the arbitraries scenario will have a usable rate for every possible source-destination combination, in order to save run time.

glog.business.conopt.CONSchedule.numDaysLateTimeAfterEarlyTime

6.2.3

If there is no late delivery date on an order release, then Oracle Transportation Management takes the early date plus 60 days (the default of this property).

With this property, you may change this and make it longer to include more voyages.

For this logic to be called:

1. Parameter CONSIDER VOYAGE SCHEDULES IN CONTAINER OPT must be set to true.
   
   AND
2. The itinerary leg must have a via location (either via source or via destination).

glog.business.conopt.ConoptConverter.CheckOrderDates

6.3.5

Determines if OTM should skip the time window checks in container optimization. When set to false, the logic will skip the time window checks in container optimization and hence ignore the order release as well as order movement time windows in container optimization. The default is true.

glog.business.conopt.checkSamePIs

6.3.6

This property determines whether OTM checks commodities or packaged items when considering whether to allow mixing in a compartment depending on the Allow Commodity Mixing check box.

When this is true, OTM will check packaged items (PI) instead of commodities for mixing in the compartment.

When this is false, OTM will check the packaged item and not mix different packaged items.

The default is false.

glog.business.conopt.useOneConoptObjectiveInEquipmentAssigner

6.4.3

This property impacts the runtime performance of container optimization when called from Multistop. This is particularly useful when you enable multiple objectives in the container optimization logic configuration along with one or more 3D packing algorithms.

When false, all specified container optimization objectives will be used during equipment assignment stage of multistop logic.

When true, only the objective MAXIMIZE CONTAINER UTILIZATION  will be used.

The default is true.

glog.business.consolidation.bulkplan.batchCommitBulkPlanResult

6.2

Without this property, the process is:

1. For each shipment graph (related shipments) in the batch.
   1. Commit the shipments in the graph.
   2. Read the bulkplan result from the database.
   3. Update the bulkplan result information in memory - increments several counts, weights, volumes and statistics.
   4. Commit the changes to the database.

With this property, the process is as follows:

1. Read the bulkplan result from the database (before any batches are created). The information should be mostly empty.
2. For each shipment graph in the batch
   1. Commit the shipments in the graph
   2. Update the bulkplan result in memory (this step is still synchronized, but should be fairly quick as everything is in memory).
3. After all the batches are done committing, the bulkplan results are committed to the database.

Default: false

glog.business.consolidation.bulkplan.favorSameSWGConsolidation

6.4.3

If this property is set to true, OTM bulk plan logic will favor same Ship with Group based consolidation when the parameter MULTISTOP FAVOR SAME SHIP WITH GROUP is false (the default). It is not necessary to set this property to true if MULTISTOP FAVOR SAME SHIP WITH GROUP parameter is true. However note that, unlike the parameter, this property setting does not influence the Multistop logic.

glog.business.consolidation.bulkplan.filterOutFailedOrders

6.2

This enables bulk plan to filter out failed orders. Once the failed orders are removed, the normal bulk planning process is done starting from order bundling, itinerary selection and shipment building.

In order to recognize the failed orders, each order release is bundled individually and planned into shipments. If successful, then the orders are chosen to proceed to the next step. Otherwise, they are filtered out. This property controls whether to include this filtering logic. The default is false. By setting this to true, failed order filtering logic will be executed.

This works for most cases, but will have undesirable results if either schedule instances or consol shipments exist.

glog.business.consolidation.bulkplan.orderMaxTotalVolume

22A

This property specifies the maximum allowable total volume of an order. The default UOM (Unit of Measure) for volume in the planning domain is used as the UOM for this volume. An order will fail to plan if its total volume is more than this value.

The default value of this property is 1,000,000.

glog.business.consolidation.bulkplan.orderMaxTotalWeight

22A

This property specifies the maximum allowable total weight of an order. The default UOM (Unit of Measure) for weight in the planning domain is used as the UOM for this weight. An order will fail to plan if its total weight is more than this value.

The default value of this property is 10,000,000.

glog.business.consolidation.bulkplan.orderSortByDateType

6.2

This property specifies which date is used to sort the orders in order bundling.
0 = SORT_BY_EARLY_PICKUP_DATE
1 = SORT_BY_LATE_PICKUP_DATE
2 = SORT_BY_EARLY_DELIVERY_DATE
3 = SORT_BY_LATE_DELIVERY_DATE

glog.business.consolidation.bulkplan.persistOMTimeConstraints

21A

This allows you to set the time the time window (pick up and delivery time window) on the order movement so that the order movement bundle does not get broken due to drive result infeasibility.

When set to true, OTM will persist the time window constraint from the network routing process. The default is false.

See Network Routing and Order Movements.

glog.business.consolidation.bulkplan.relaxOrderBundlePickupWindow

6.2.4

When set to true, an order release with the date emphasis set to BOTH and a pickup window in the past can be unassigned.

glog.business.consolidation.bulkplan.removeDeconsolPoolShipments

The child nodes of all shipment graphs (related shipments) with deconsolidation pools will be deleted in bulk plan just before persisting to the database. Only the initial linehaul with the initial order pickups will be kept. For the case where orders go on linehauls into the pool, and pool drop shipments out, only the linehauls will be saved by bulkplan.

Default is off (false).

glog.business.consolidation.bulkplan.skipMultiStopFallbackDirect

When this property is False (the default), the bulk plan works as usual. When this property is True, the bulkplan will skip the logic that tries to consolidate the "fallback" shipments after the pool selection logic.

This step could take a lot of run time and not change the solution so with this property you can skip the step.

glog.business.consolidation.isNonOverlappingStopTimeWindowsRelaxed

23A

If this property is set to true and the time windows on a stop from multiple orders are not overlapping, OTM will not fail the time window compatibility check and no exception will be thrown. Instead, OTM will construct a relaxed time window using the union of all the time windows rather than an overlap of them.

This applies to the agent action Order Release Mod - Propagate Changes before or after editing a shipment, or any other time window related planning actions, such as Unassign Order.

Default: false

glog.business.consolidation.minimizeTimeGap

6.2

This property minimizes the time gaps between shipments in a shipment graph. .

When set to true, during the shipment graph consolidation phase of bulk plan, legs of an itinerary that are prior to the primary leg, will be redriven under a Hold As Late As Possible scenario. This will push the shipment to the latest possible time that can still end in time for the following leg.

The default is false.

glog.business.consolidation.multistop.allowPlanningRates

6.1

The usage of planning rates is contingent upon this property. If you need to use, you need to turn this property on. The default is off (false).

glog.business.consolidation.multistop.clusterInitialMergePercentage

21A

This property defines the percentage of direct shipments in the cluster that the cluster merge logic would attempt to merge. Valid values are 1-100. The default is 100.

See Bulk Plan Multi-stop Shipment Clustering Merge Algorithm.

glog.business.consolidation.multistop.clusterMergeClusterNumMultiplier

21A

This property sets a multiplier for candidate cluster centers. The default is 3.

Do not change unless directed by Oracle.

glog.business.consolidation.multistop.clusterMergeClusterSize

21A

This defines the maximum number of direct shipments that a cluster can contain. When the value is set to be less than or equal to 0, it means OTM will not enforce this constraint. The default is -1.

See Bulk Plan Multi-stop Shipment Clustering Merge Algorithm.

glog.business.consolidation.multistop.clusterMergeMaxiterationNum

21A

This property sets the maximum number of iterations for the cluster building and build multi-stop shipments for clusters process.

See Bulk Plan Multi-stop Shipment Clustering Merge Algorithm.

glog.business.consolidation.multistop.commodityBundlingCheckRequiredInMultistop

6.4.2

This property provides an option to allow commodity check in multistop even when the order bundle rule set does not include the commodity rule. This can be done by setting this property to true.

The default is false.

glog.business.consolidation.multistop.computeShipmentTimeWindowsInMultistop

6.4.2

To have flexible time windows on multistop shipments, you need to set this property to true in addition to setting the parameter COMPUTE SHIPMENT TIME WINDOWS to true. When this is true, multistop logic will spend more time driving the shipments.

glog.business.consolidation.multistop.doSavingsMergeAfterClusterMerge

21A

This property controls whether to run additional sequential savings consolidation for the resulting shipments of cluster merge. Values are true and false.

See Bulk Plan Multi-stop Shipment Clustering Merge Algorithm.

glog.business.consolidation.multistop.fallbackMergeAlgorithm

19B

In clustering merge, if shipments in a cluster could not be merged into one shipment, OTM will use the fallback merge algorithm to merge them again.The fallback merge algorithm is specified by this property. The values are '0' for CONCURRENT SAVING (the default) and '1' for SEQUENTIAL SAVING. If fallback merge algorithm fails, it will fall back to the original direct shipments.glog.business.consolidation.multistop.fallbackMergeAlgorithm.

glog.business.consolidation.multistop.priorityagressiveness

6.0

Use this property to control the influence of priority in multi-stop cost savings. Priorities are on order bases, order releases, and order movements and affect planning. Valid values are 0-100, 0 being no influence. The default is 50.

The value for this property is used in combination with the following parameters in order to increase the apparent savings gained by combining an order with orders of the same or higher priority.

WEIGHT FOR HIGH PRIORITY

WEIGHT FOR MEDIUM PRIORITY

WEIGHT FOR LOW PRIORITY

This savings, if high enough, can counteract the savings due to geography.

The higher the value of the property, the priority factor in combining orders onto shipments is increased. In general, the savings from greatest to least will be:

• high with high
• high with medium
• medium with medium
• high with low
• medium with low
• low with low

glog.business.consolidation.multistop.prioritysavingsalgorithm

6.0

This property determines the approach for calculating priority based savings:

1 - Average weighted priority approach. This is the average of the weighted priorities of the 2 individual shipments. This approach favors combining shipments that have higher priorities.

2 - Max of weighted priorities approach. This is determined as the highest weighted priority value between the two shipments. This also favors combining shipments that have higher priority.

3 - Absolute difference of weighted priorities. This approach favors combining shipments that have closer weighted priority values (i.e., high to high, low to low)

Default: 1

glog.business.consolidation.multistop.recreateshipmentorderbundle

6.4.2

Do not change this property unless directed by Support.

glog.business.consolidation.multistop.tWMipSequencerMaxTime

20C

This property sets the upper bound for time to spend on searching for the optimal solution when using MULTISTOP SEQUENCING ALGORITHM option "6.Time Window MIP". The default is 10 seconds (unit is seconds).

Note that when the upper bound is reached, but the solver hasn't gotten the optimal solution, OTM will get the current best feasible solution.

glog.business.consolidation.multistop.useTuplingLogic

19B

Do not change this property unless directed by Support.

glog.business.continuousMoves.passHOSStateDownstream

6.3.3

This property is used during the shipment graphing process.

When set to TRUE (default), hours of service data is passed from shipment to shipment for continuous moves.

When set to FALSE, hours of service information is not used during continuous moves calculations.

glog.business.continuousMoves.redriveOnlyIfDiffRateService

6.4.2

This property controls whether to redrive shipments while manually linking shipments into a continuous move shipment.

When the property is true, OTM will redrive only if the rate service changes.

When the property is false, OTM will redrive regardless of a rate service change. This is the pre-existing behavior.

Note: The parameter CM REDRIVE must be set to true so for OTM to go into the redrive and check the property. Otherwise, there will be no redrive.

The default is false.

glog.business.costFractionalDigits

glog.business.costFractionalFlags

This property controls default precision flags for typical currency totals:

glog.business.costFractionalFlags=<comma-delimited list of flags>

Flags may be:

• individual. Each currency value is rounded before it is added to subtotals.
• subtotal. Each subtotal (i.e. by currency) is rounded before it is added to the total.
• total. The final total cost is rounded.
• standardBasis. If standardBasis is not set and the caller does not specify a basis, the basis will be set to the last currency encountered.

The following property specifies ISO precision for each currency:

• glog.business.costFractionalDigits.<currency>=<number of digits>
• glog.business.costFractionalDigits=<default number of digits>

For example, the following two settings denote 2 digit precision as a default, but 0 digits for Japanese Yen:

• glog.business.costFractionalDigits=2
• glog.business.costFractionalDigits.JPY=0

glog.business.distance.oraclespatial.longlat.precision

6.3.6

This property enables you to configure longitude and latitude precision. External Distance Engine request passes all digits of Longitude and Latitude to Oracle Map Cloud Services Engine so that accurate distance is retrieved.

glog.business.driver.DriverPowerUnitEquipmentCacheManager.logCaches

6.3.2

This property is used to log the cache values of driver-power unit-equipment relationships that are defined in OTM. If this is set to true, the cache values will be logged in Fleet_assignment logs. The default is false.

glog.business.equipment.allowRotation

6.3.3

This property allows or prohibits rotation of a ship unit or item inside equipment.

If this is true then the ship unit or the item inside the equipment can be rotated.

If false (default), rotation is not allowed.

Note: This property does not impact load configuration.

In container optimization (Conopt), the logic parameters VOLUME METRIC and WEIGHT METRIC work as intended independently. However, when both VOLUME METRIC and WEIGHT METRIC are set to true, the previous behavior was that the application returned a random or a weight-based solution for the same cost.

This property is used to control this behavior. When set to true, Conopt results will be sorted based on the most utilized metric - either volume or weight - if both VOLUME METRIC and WEIGHT METRIC are true.
The default value of this property is true.
When set to false, the previous behavior will take effect.

glog.business.fleet.checkDriverTypeCompatibility

6.4.2

When set to true, the property helps improve the Optimize Driver Assignment action performance. The default is false.

There is an alternate approach to perform driver assignments faster. The Fleet aware bulk plan should be used to speed up the process. You can set up resource schedules to simulate driver resources. These resource schedules are the resources used by the fleet aware bulk plan. Then you can perform the resource optimization using the fleet aware bulk plan, form shipment strings, and assign best feasible resources to those strings as a part of bulk plan. You can take those shipment strings and perform the Optimize Driver Assignment action on those shipments given the set of drivers. Each shipment is evaluated with all available drivers which is still not optimal for some scenarios where only a set of drivers are feasible for certain shipments. Driver types can be set on both resource schedules and drivers to make the driver assignment more optimal. Only a subset of drivers is evaluated for each shipment in this case. For shipments, the driver type is derived from the resource schedule which is associated to the work assignment that contains that shipment. The driver resources with matching driver types as shipment are the only ones that are evaluated for assignment against that shipment. This driver type checks and evaluates fewer drivers for each shipment and improves the overall Optimize Driver Assignment performance. This property is used to enable the driver type compatibility check.

glog.business.fleetassignment.assignPowerUnitAfterRedrive

21A

This property is used with the Optimize Driver Assignment action to assign proper power units for the case where they are shared across drivers. Setting this to true will allow the same power unit to be assigned to both shipments. The default is false.

glog.business.fleetassignment.checkHomeStopPermForPrevShipLoad

21A

This determines the consideration of the previous shipment during driver assignment, if set to true. The default is false.

glog.business.fleetassignment.defaultEquipmentPoolRole

6.0

This property is used to restrict the fetching of equipment types with a location role. Default is "not defined" meaning that all roles are used.

glog.business.fleetassignment.driver.considerWorkAssignmentInDriverOptimization

6.4.2

Controls whether or not work assignments are considered when you run the Optimize Driver Assignment action. Default value of the property is false.

You should set this property to true to consider work assignments when you run the Optimize Driver Assignment action. That then assigns the same driver to all shipments in a particular work assignment.

This setting can also be made by setting the ASSIGN SAME DRIVER TO SHIPMENTS IN A WA parameter. If either the parameter or the property is set to true, the system sees the option as true.

glog.business.fleetassignment.optimization.minNodeExtentions

6.2

This property controls the number of shipments tried during the dispatch plan optimization (DPO) process. For example, we have 46 shipments in the DPO process. This property is set to 6 as default, when assigning drivers to these shipments, only the first 6 most profitable shipments are evaluated.

glog.business.GGraphBuilder.plotCMShipments

Used for controlling the building of shipment graphs (related shipments) for plotting continuous moves. Unless True, continuous moves will not be plotted.

This property is used to choose between the HERE V8 Matrix Synchronous and Asynchronous requests types that HERE provides.

The default value is set to true.

glog.business.HereRoutingBatch.matrixStatusTimeout=<# of minutes>

e.g. glog.business.HereRoutingBatch.matrixStatusTimeout=3

This property is used to poll the matrix status url i.e., it calls HERE V8 Matrix Asynchronous API to get the matrix status before the timeout happens. If the status is returned as completed, polling is stopped.

The default value is set to 1 minute, and maximum value as 5 minutes.

glog.business.invoice.line.vat.round

22B

This property determines whether the VAT should be rounded off at the invoice line item level. If the value is true, the VAT amount is rounded off at each line item level prior to summing up either to VAT code level or the total value. If the value is false, the VAT amount is not rounded.

Also see, glog.business.vatAggr.vatcode.costFractionalFlags and 
glog.business.vatAggr.invoiceOrVoucher.costFractionalFlags.

Default: true

glog.business.procurement.crtupload.createbids.batchsize

24A

This property specifies the count of rows processed in a single batch. If there are more than 1,000 rows in the spreadsheet, they are processed using multi-threading.

glog.business.ratedistance.checkExceptionMethod.useSync

22C

If the property is set to true after the cache is cleared, the loading and caching of the data with source and destination geo hierarchy as LOCATION will not be called multiple times if multiple users are trying to load at the same time.
When the property is set to false, the loading and caching of the data with source and destination geo hierarchy as LOCATION will be called multiple times if multiple users are trying to load at the same time.

Default: false.

glog.business.ratedistance.loadLocationHierarchyLocPairDistance.forceDBA

22C

If the property is set to true, the application will use the "DBA.ADMIN" user while loading the distance records with source and destination geo hierarchy as LOCATION irrespective of the logged-in user. This will allow the cache to have the same number of records no matter which user is loading the cache.

If the property is set to false, the application, while loading the distance records with source and destination geo hierarchy as LOCATION, will use the VPD of the logged-in user. This might result in the cache having an incorrect number of records.

Default: false.

glog.business.vatAggr.vatcode.costFractionalFlags

22B

This property is used to round off the VAT amount at the VAT code Level. 

If the property value is 'individual', the VAT amount is rounded off before adding it to the total. 

If the value is 'subtotal', VAT amounts of same currency type are grouped together and aggregated. Then the amount for each currency type is rounded off and aggregated.

If the value is 'total', the VAT amount is rounded off after aggregating all the vat amounts for a VAT code.

If no value is specified for the property, the application falls back to the standard precision flags (refer to glog.business.costFractionalFlags property).

Default: individual

glog.business.vatAggr.invoiceOrVoucher.costFractionalFlags

22B

This property is used to round off the VAT amount at the invoice/voucher level.  
This property can accept the values individual/subtotal/total.

If the value is 'individual', the VAT amount is rounded off before adding it to the total. 

If the value is 'subtotal', VAT amounts of same currency type are grouped together and aggregated. Then the amount for each currency type is rounded off and aggregated for an invoice or a voucher. 

If the value is 'total', the VAT amount is rounded off after aggregating all the VAT amounts of each line item or each vat code for invoice/voucher. 

If no value is specified for the property, the system falls back to the standard precision flags. 

Default: individual

glog.business.itinerary.maxSplitOptions

21A

Shipment building may create a huge number of shipment options and fill up memory in planning for scenarios with split order bundles and the following parameter settings:

    ALLOW DIFFERENT RATE RECORDS FOR SPLIT ORDERS = true

    MAX NUMBER OF RATE RECORDS FOR SPLIT ORDER > than the default of 3.

This property limits the maximum split options allowed. The default is 10000. If the number of split shipment options exceeds this value, the order planning will fail.

Note that setting this to a higher value might cause a memory problem.

If the threshold is exceeded, the Planning log will include information about the failure.

Also, the warning section of the Bulk Plan Performance tab will indicate that this failure has occurred in a bulk plan.

22A

When the number of leg options is more than the specified limit, only the first allowed number of leg options will be considered for shipment planning.

glog.business.itinerary.queryToLimitArbLegOptions

When True, and arbitraries are defined on the leg, the logic that builds leg options queries ahead attempting to limit arbitrary locations that do not have valid port or arbitrary rates. Normally, this should be left True, unless all options would have rates and should be tested. In that case, the query to look ahead at rates would not provide any benefit.

When this is True, rates for the arbitrary locations should be set up as follows:

1. For source via points alone, a rate must be from a location or a region-of-locations.
2. For destination via points alone, a rate must be to a location or a region-of-locations.
3. For source and destination via points together a rate must be either location to location or (region-of-locations) to (region-of-locations).

In addition, the leg with the arbitraries should have either only via point location or only via point location profiles.

glog.business.LNMBulkPlan.maxOrderReplanCount

19B

This indicates the maximum number of times the order can be reconsidered for planning in the same scenario bulk plan action. It is only used by scenario bulk plans that run periodic bulk plans run in a series. If the order fails in the current periodic bulk plan, it will be reconsidered in subsequent bulk plans as long as they are feasible for the period considered in that bulk plan and the re-plan count is less than or equal to the maximum re-plan count defined in the property. The default is 5.

glog.business.loadconfig.legClassificationLimitList

6.4.1

Determines if the order release ship unit's load configuration setup for a shipment is used. When this property has values set (can be a comma separated list of leg classification XIDs), OTM applies the order ship unit's load configuration setup only if the leg classification XID on the shipment's leg matches one of the values set on the property. Otherwise, OTM ignores the order release ship units load configuration setup for that shipment.

When no values are defined (default), OTM uses the order release ship unit load configuration setup always (backward compatible).

For example, the property value is "Customer_Delivery".
If the itinerary leg on the shipment being evaluated has a leg classification of "Customer Delivery", OTM will honor the load configuration setup on the order release ship unit since “Customer Delivery” is specified in the property. However, if the itinerary leg on another shipment being evaluated has a leg classification of "Pretransport", then OTM will ignore the load configuration setup on the order release ship unit altogether and try to obtain one through the load configuration rules.

Note: This property does not display in the properties servlet by default. It must be added manually.

glog.business.location.inactiveLocationSetting

19B

This allows you to configure OTM to prevent inactive locations from being used as intermediate locations when Network Routing is enabled, or as arbitrary via points (Port-of-Load or Port-of-Discharge) regardless of the Order Routing Method. Possible values are:

0: (default for clients that upgrade) inactive locations can be used as throughpoints/via points

1: (default for new clients) inactive locations cannot be used as throughpoints in  Network Routing nor as via points (Network Routing or Cost-based Routing)

glog.business.location.locationCapacityOptimizer.CalculateStopWaitUsingLCinBP

When set to False, this property checks location capacity after the service time calculation.

If True it changes the stop wait time inside service time calculation. Afterward it will not re-check the location capacity. When set to true, the service time calculations during the fleet aware bulk plan checks for feasible arrival/departure times at the stops in order to honor the location capacities defined on the stops. It might also add more wait time on the stops to achieve that.

Default: false.

This property is used to plan group of orders whose sum of an item count (total equipment reference unit) exceeds the maximum capacity usage for a day.

When set to true, this property checks the location capacity in drive during the first run of bulk plan.

Default: false.

glog.business.location.locationCapacityOptimizer.locationCapacityLoadingTimeWindow

This is the duration on each side of the early pickup or late delivery if one of them is not specified. The location capacity information of the locations is loaded once up front for the time window thus determined. Duration in Number of Days.

Default: 14

glog.business.location.locationCapacityOptimizer.maxNumShipmentStartTimes

22A

This controls to  limit the number of shipment start time options and avoid OutOfMemoryError. This specifies the maximum total number of start time options which will be evaluated  for each shipment in the Location Capacity Optimizer. The default value is 5,000.

At the beginning of Location Capacity Optimization, the number of start times for a shipment can be estimated by driving time span with time step. If its estimated number of start times exceeds the specified limit,  Location  Capacity Optimization logic will be entirely skipped.

This property is used to correctly calculate the Location Capacity Planning Window. When set to true, this property correctly calculates the Location Capacity Planning Window if an Early Pickup date (EPD) is not provided, and a Late Delivery date (LDD) is provided on all the order releases.

By default, this property is set to false.

glog.business.machinelearning.accessanalytics.user

21A

User credential for directly accessing the analytics HDOWNER database from an OTM action.

Default: DBA.ADMIN

glog.business.machinelearning.loadtoanalytics.batchsize

21A

The batch size used in the action Load Data into Analytics. Shipments are pushed in batches with this size limit.

Default: 100000

glog.business.machinelearning.minEventsInShipment

22B

The minimum number of events on a shipment that are required in order for the shipment to qualify for training using the event-based ETA prediction model.

Default: 2

glog.business.machinelearning.minShipmentDistance

22B

The minimum shipment distance (km) between the source and destination locations that is required for the shipment to qualify for training  using the event-based ETA prediction model.

Default: 1

The number of folds for cross-validation used for AutoML Hyper Parameter tuning. Increasing this value increases run time an may lower performance. The recommendation is to leave this at the default value of 3.

Default: 3

Min: 2

Max: 5

glog.business.machinelearning.prediction.batchresultslimit

This property determines the batch size limit used to show prediction results on a page.

Default: 50

glog.business.machinelearning.process.getStatusTopicInvocationMaxRetryCount

21A

Once the training rest call is initiated on a ML scenario, the training starts at the ML services end. To get the status and results of the training process, another REST call getLearningResult need to be initiated. This property will define the maximum number of times the get results call can be initiated.  

Default: 20

glog.business.machinelearning.process.getStatusTopicInvocationTimeGap

21A

Once the training rest call is initiated on a ML scenario, the training starts at the ML services end. To get the status and results of the training process, another REST call getLearningResult need to be initiated. This property will define the time gap between each get result call that is being initiated.

Default: 120

glog.business.machinelearning.process.maxShipmentsAllowedInPrediction

21A

Maximum number of Shipments considered for Prediction

Default: 10000

glog.business.machinelearning.rest.requestBaseUrl

21A

Contains the URL to the machine learning service for all Logistics Machine Learning actions.

glog.business.machinelearning.rest.mlRestUserName

21A

Contains the User name for the connection to the machine learning service for all Logistics Machine Learning actions. As entered in the OTM wallet.

glog.business.machinelearning.rest.mlRestPassword

21A

Contains the Password for the connection to the Oracle Machine Learning Cloud Service for all Logistics Machine Learning actions. As entered in the OTM wallet.

glog.business.machinelearning.scenarioShipmentInsertBatchSize

This property determines the number of Scenario Shipment that can be inserted in a batch.

Default: 1000

glog.business.machinelearning.updateProjectWorkflowDuringTraining

21C

When set to true, the machine learning training process updates the project workflow with the advanced filters in the IoT side using a REST call. Set this property to true if you are migrating machine learning projects from 21A.

By default the property value is set to false and the project workflow is not updated during the training process.

Default = false

This property controls Network Routing logic which checks carrier capacity when routing orders. The default value is true. When the property is true, Network Routing logic will not route orders onto legs when there is no available carrier capacity on those legs. This logic is useful especially in a multi-pass bulk plan, where the first pass might use up the carrier capacity on certain legs, and the second pass should not route additional orders on those legs. When the property is false, Network Routing logic will be allowed to route orders onto legs when there is no available capacity. 

Note: There are scenarios where Network Routing logic may route orders onto legs with no available carrier capacity, even if the property is set to true, particularly when orders do not have overlapping pickup windows, and capacity is available for some of these windows and not others.

glog.business.networkrouting.disbundleFailedBundleInDynamicClustering

22A

This property is set to "true" by default.  Setting this property to "false" will disable disbundling of failed order movement bundles in Dynamic Clustering.

glog.business.networkrouting.flexCommodityCodeForRatingNetwork

6.4.1

This property specifies the value of the flexible commodity qualifier code to be used during network creation.

Default = 70.0.

glog.business.networkrouting.flexCommodityQualGidForRatingNetwork

6.4.1

This property specifies the value of the flexible commodity qualifier GID to be used during network creation.

Default = NMFC_CLASS.

This property helps to manage planning performance when using Network Routing.  Planning logic uses the NetworkLegRateCache in order to save time when determining rating costs for order routing decisions. The default value of this property is set to "false". However, this cache is automatically cleared when rate records or related data are changed, to keep the cached data up-to-date.  This property, if set to "true", prevents the automatic clearing of the NetworkLegRateCache when rate data is changed.  This setting can be convenient while rate data is being updated frequently.  However, if the cache is not cleared, the data can become out-of-date. So it is up to the user to manually clear this cache in a timely and convenient way.

glog.business.consolidation.isNonOverlappingStopTimeWindowsRelaxed

22C

When the property is set to true, ORDER RELEASE - MOD - PROPAGATE CHANGES, ORDER RELEASE - MOD – EDIT SHIPMENT and all other planning actions such as unassign, redrive etc that loads shipments, if order (order movements) being pickup or dropped off at a location do not have overlap time windows, the system will not fail the time window compatibility check and will not throw an exception. Instead, the system will construct a relaxed time window using the union of all time windows.

Default : false

glog.business.omd.isPropagateLineChanges

6.3.5

This controls if changes on order release lines are propagated to the ship unit when using the OMD automation agent actions 'Order Release - Mod - Edit Shipment' or 'Order Release - Mod - Propagate Changes'.  

The default of TRUE propagates all changes on the order release lines to the ship unit. Set this to FALSE if you do not want the changes propagated. It is strongly recommended that you always set this to TRUE.

glog.business.omd.isRemoveZeroQuantityOrderLines

18C

This determines if an order release line with a quantity of zero will be kept or deleted if using order release modification actions. This only applies to line based orders, PREPACK, ONE TO ONE and AUTO CALC. It does not apply to ship unit based orders, such as SHIP UNITS or SHIP UNIT LINES.

When this is set to true (default), the order release line with 0 quantity will be removed from the database, and the corresponding ship unit lines (and ship unit if contains no other lines) and shipment ship unit lines (and shipment ship units if contains no other lines) will be removed.

When set to false, the order release line with 0 quantity will be kept, but corresponding ship unit lines (and ship unit if contains no other lines)  and shipment ship unit lines (and shipment ship units if contains no other lines) will be removed.

The actions Order Release - Mod - Edit Shipment and Order Release - Mod - Propagate Changes both honor this property.

glog.business.orderActions.unassign.redriveShipmentWithOptimalStartTime

18.1-5

When unassigning an order release, OTM redrives the remaining shipment with original shipment's start time that is being unassigned (default is false, existing default behavior). When set to true, OTM will redrive the shipments using the optimal start time in the unassign process.

For example, you have three orders releases with early pick up dates of the 19th, 20th and 21st. When planning these, the shipment is planned with a start time on the 21st. If you unassign the last one (early pick up date of the 21st), the resulting shipment is still planned with a start time on the 21st. When true, the shipment will be updated from the original start time (the 21st) to the next latest early pick up date on the remaining order releases (the 20th).

Note: A change in order time window or use of a different planning parameter set could sometimes cause time windows at a stop not to overlap, thus, affecting the bundling logic. However, with this property any issue with time infeasibility or wrong time can be avoided during unassigning an order. For example, consider a shipment with two stops and two orders as follows:
Order 1: pickup time window is 11/01-11/03 and delivery time window is 11/02-11/04
Order 2: pickup time window is 11/02-11/03 and delivery time window is 11/02-11/04
When you create a shipment for these two orders, the shipment start time will be 11/2.
If this property is set to false, after unassigning  order 2, the shipment will still have the start time on 11/02.
If the property is set to true, after unassigning  order 2, the shipment will start on 11/01.

glog.business.order.ignoreCarrierCapacityWhenMoveOrdersToShipment

When true, carrier capacity is ignored in the Move Orders To Shipment and Move Order Movement To Shipment actions. It is equivalent to ignoring carrier capacity in the ignore criteria input screen for this action.

glog.business.order.ignoreOrderMovementConstraints

6.2.4

When true, order movement constraints, such as service provider, transport mode etc will be ignored for shipment actions. The constraints from order release, if any, will still be used.

Default: false

glog.business.order.packing.allowMixedTHUWithAllSameItems

18D

This impacts grouping of mixed freight ship units. This property needs to be added and set to true to allow same items to go in mixed transport handling units (THU). The default is false.

glog.business.order.packing.considerSameTiOrSameHiLikeItems

22A

When this property is set to true, Like item checking is relaxed so lines with different Packaged Item

GIDs are considered "Like", if:

• Packaged Item Type is same and

• either Ti (Quantity per layer) or Hi (number of layers) is same  

Default: false

glog.business.order.packing.allowRemnantToSplit

21A

If set to false, remnants will not split onto different ship unit during order ship unit building.

Default: true

To minimize splitting with ship unit building and ship unit repacking, set the glog.business.order.packing.allowRemnantToSplit property to false and set the glog.business.shipment.repacking.useCostBasedConoptParameters property to true. Then select logic configuration type of SUBLD CONTAINER OPTIMIZATION and select the parameter SUBLD COST-BASED CONOPT ALGORITHM,  and select the parameter value "5: Column Generation with Quick Pack and Single Container MIP".

glog.business.order.packing.THUTiHiNormalizedCapacity

21A

This property is set as the normalized capacity for every transport handling unit (THU) when formulating TiHi capacity. You should not change this value unless you run into rounding issues in ship unit building and are instructed by OTM support.

The default is 1000.

glog.business.order.prevalidateInUnassignOrderMovements

6.3.2

Controls whether OTM needs to check reuse equipment while unassigning order movements.

Default is false which means: do not pre-validate while unassigning order movements.

When this property is set to true, a new buy order movement will be created in the current domain, which is the same domain as that for newly created shipments.  When the property is false, new buy order movements will be created in the domain of the related order release. 

By default, the property is false.

glog.business.orderbase.shipmentLinker.activeTable

6.4.1

This controls whether to add SHIPMENT_S_EQUIPMENT_JOIN to the Virtual Private Database (VPD) active table list.
Without the property, OTM defaults to SHIPMENT_S_EQUIPMENT_JOIN, and nothing changes for existing clients.

To avoid the problem of retrieving wrong data from another domain, set the property as follows:

glog.business.orderbase.shipmentLinker.activeTable = NONE.

glog.business.planningstreams.dataMaskingDefinitionID

20A

This property identifies the Data Masking Definition ID to be used when exporting planning data. The default and only possible value is BASIC. If this value is removed, then the Apply Data Masking check box on the Export Planning Data page will not work.

glog.business.planningstreams.dataobjects.includerankinmanifest

20A

Controls whether to include the rank in the manifest.xml file when exporting planning data. Exported objects are sorted by rank.

Default: true

glog.business.planningstreams.dataobjects.includenumobjectsinmanifest

20A

Controls whether to include the number of objects in the manifest.xml file when exporting planning data.

Default: true

glog.business.planningstreams.exportimportcachesize

20A

This property defines the total number of records, across all object types, that can be stored in cache at one time when exporting or importing planning data.

Default: 2000

glog.business.rate.extRatingAndDistanceWebservice.readResponse.useDOMAPI

6.4.2

Reserved for internal use. Do not change unless directed by OTM Support.

glog.business.rate.ratedistance.failRateOnInvalidDistance

6.3.7

If the shipment distance calculation fails (when distance is not available between the locations provided in the shipment), rating of the shipment will be done based on the value of this property.

If false, (the default), and the shipment distance calculation fails, OTM will still rate the shipment.

If true and the shipment distance calculation fails, then OTM throws an exception and will not rate the shipment.

glog.business.rate.rateEngine.rateFactor.useStepFuncForAccCostCalc

19B

If you configure this value to true, the system will consider the next level rate factor cost as an accessorial cost. Otherwise it will calculate the exact cost for the rate factor and use it as an accessorial cost.

For example: If you configure a rate factor value as 1.5 and the rate factor rule details are as follows:

Cost Increase is 1 USD, factor increase 1. This means for 1 unit the rate factor cost increases by 1 USD.

For Rate Factor 1, the cost will be 1 USD.

For Rate Factor 2, the cost will be 2 USD.

If the property is true:

Since the actual rate factor value (i.e., 1.5) is between 1 and 2, it will take the ceil value of 2 (rounding up from a  fractional value to the next integer) of the rate factor, and uses its associated cost of 2 USD as an accessorial cost.

If this property is false it will calculate the exact rate factor value using the rate factor increase and cost increase values. In this example, it will return 1.5 USD as an accessorial cost.

Default: False

This property specifies whether to take the currency unit defined in the rate offering or the currency unit defined in the rate cost while evaluating a rate cost.

When you set the property value to true, the application uses the currency unit defined in the rate offering and converts the cost accordingly.

If you set the property value to false, the application skips the currency unit defined in the rate offering and uses the currency unit defined in the rate cost.

Default: true

glog.business.rate.rateengine.allowIndividualCostMinAndMax

22B

If the property is true:
For rate costs having the charge multiplier option 'Collect Costs Separately', the application honors minimum and maximum charges for individual cost. For rate costs having the multiplier option 'Add Individual Multiplier Values', minimum and maximum charges are not applied on aggregated cost but minimum and maximum charges are honored on the individual costs and these costs are added.

If the property is false:
For rate costs having the charge multiplier option 'Collect Costs Separately', minimum and maximum charges are not honored. For rate costs having the multiplier option 'Add Individual Multiplier Values', minimum and maximum charges are applied on aggregated cost.

For example:
Suppose an order release has three order lines ORL1, ORL2, ORL3 of weights 1000 LB, 2000 LB, and 3000 LB respectively.
Rate cost is defined to charge 1 USD per 10 LB of order line weight. Minimum Charge is defined as 120 USD and maximum charge is defined as 270 USD.
The rate costs calculated for each of the order line would be:
ORL1 - 100 USD
ORL2 - 200 USD
ORL3 - 300 USD

If the property is set to true and the rate geo cost has the multiplier option 'Collect Costs Separately', then the cost would be as follows:
ORL1 - 120 USD (as minimum charge is specified as 120 USD and the charge for ORL1 100 USD < 120 USD)
ORL2 - 200 USD
ORL3 - 270 USD (as maximum charge is specified as 270 USD and the charge for ORL3 300 USD > 270 USD)

If the property is set to true and the rate geo cost has the multiplier option 'Add Individual Multipliers', then the cost would be as follows:
ORL1 - 120 USD (as minimum charge is specified as 120 USD and the charge for ORL1 100 USD < 120 USD)
ORL2 - 200 USD
ORL3 - 270 USD (as maximum charge is specified as 270 USD and the charge for ORL3 300 USD > 270 USD)
Aggregated cost is 120 USD + 200 USD + 270 USD = 590 USD. Individual charges are subjected to minimum and maximum charges and then aggregated.

This is to make sure that the aggregated cost remains the same with different charge multiplier options.

If the property is set to false and the rate geo cost has the charge multiplier option 'Collect Costs Separately', then the cost would be as follows:
ORL1 - 100 USD
ORL2 - 200 USD
ORL3 - 300 USD
 

If the property is set to false and the rate geo cost has the multiplier option 'Add Individual Multipliers', then the cost would be as follows:
ORL1 - 100 USD (as minimum charge is specified as 120 USD and the charge for ORL1 100 USD < 120 USD)
ORL2 - 200 USD
ORL3 - 300 USD (as maximum charge is specified as 270 USD and the charge for ORL3 300 USD > 270 USD)
Aggregated cost is 100 USD + 200 USD + 300 USD = 600, USD but the aggregated cost is subjected to minimum and maximum charges. 600 USD is more than the minimum charge but exceeds the maximum charge 270 USD. So, the cost is set to the maximum charge of 270 USD.

Default: false

This property is used for impersonating the domain administrator while loading domain-level rating caches rather than loading only user-specific data in the caches. When this property is set to true, the application loads the rate caches such as rate attributes, rate offering types, rate quality factors, global accessorials, default accessorials, item accessorials, special services, dimensional factors, rate unit break profiles, and tiered rating time period definitions by impersonating domain administrator. If the property is set to false, only user-specific data is loaded which would not be loaded properly if there are vpd restrictions for users of the same domain.

Default: false.

glog.business.rate.rateEngine.validateBaseRateGeoActiveEffExpDate

23B

This property is used to validate whether the base rate records are active and if they are not expired.

Set the property value to true to enable the validation. If the value is set to false, the application doesn't enable the validation.

Default: false.

This property is used to specify which table to add as the active table for the VPD when searching for rates by lane.

Default: HNAME_SET_MEMBER.

See Rate Preferences and Active Tables.

This property is used for enabling or disabling the addition of an active table to the VPD when searching for the rates by lane and by zone. The default is true. When false, no active table will be added.

See Rate Preferences and Active Tables.

glog.business.rate.ratefinder.preferredRatesByLane.activeTable

6.4.2

This property is used to specify which table to add as the active table for the VPD when searching for preferred rates by lane. The default is RATE_PREFERENCE. The default is the table that was used previously (before this property was added). You can specify any other table to be used as the active table. E.g. HNAME_SET_MEMBER.

See Rate Preferences and Active Tables.

glog.business.rate.ratefinder.preferredRatesByLane.useActiveTable

6.4.2

This property is used for enabling or disabling the addition of an active table to the VPD when searching for preferred rates by lane. The default is true. When false, no active table will be added.

See Rate Preferences and Active Tables.

glog.business.rate.ratefinder.preferredRatesByZone.activeTable

6.4.2

This property is used to specify which table to add as the active table for the VPD when searching for preferred rates by zone. The default is RATE_PREFERENCE. The default is the table that was used previously (before this property was added). You can specify any other table to be used as active table. E.g. HNAME_SET_MEMBER.

See Rate Preferences and Active Tables.

glog.business.rate.ratefinder.preferredRatesByZone.useActiveTable

6.4.2

This property is used for enabling or disabling the addition of an active table to the VPD when searching for preferred rates by zone. The default is true. When false, no active table will be added.

See Rate Preferences and Active Tables.

This property is used to specify which table to add as the active table for the VPD when searching for rates by zone.

Default: HNAME_SET_MEMBER.

See Rate Preferences and Active Tables.

glog.business.rate.rateservice.backtrackDrive

6.0

When set to true, adjust number of days specified by this parameter NUM OF DAYS TO BACKTRACK DRIVE ahead of the previous drive start time to begin a new drive if no solution found in the previous drive, until we find a solution or reach the order early pickup time.

glog.business.rate.sshipunit.considerZeroShipUnitCountAsOne

22A

While rating a shipment whose rate is based on the ship unit count, when the ship unit count is specified as '0' (zero) in the order release

• if this property is set to true, the ship unit count is considered as '1' (one).

• if this property is set to false, the ship unit count is considered as '0' (zero).

The default value of the property is "true".

glog.business.rateservicescheduling.depressDepot

The property is used to ignore depot stops for rate services that only work for two stop shipments (e.g. day duration).

It also controls how the Depot Applicable setting on the rate offering is considered. When this property is true and the rate offering has Depot Applicable set to false the drive logic will not consider depots when driving the shipment.

The default value of the property is "true".

glog.business.rateservicescheduling.prevalidateStopTimes

6.4.1

Pre-validation is performed on the earliest and latest possible arrival times of a shipment stop. This pre-validation determines if there is a feasible drive solution for the shipment. If not, the drive attempt is not performed.

This property can allow a drive attempt even when it is known that a feasible drive will not be found.

When set to false, the pre-validation step will be skipped for all rate service drive attempts for all shipments. This will allow an infeasible drive solution to be found and potentially saved for the shipment. The default is true.

For example, this may be useful when processing a shipment actual. If processing the shipment actual results in stop time changes that require downstream shipments to be re-driven, the re-drive due to the pre-validation that was being performed should not be skipped. Skipping the re-drive prevents updating the downstream shipments with adjusted stop times. These should be adjusted to reflect the actual events even when they are not feasible.

glog.business.releaseGroundSchedule.redriveDownstreamShipment

23A

If this property is set to true, downstream shipments are loaded and re-driven during releasing ground schedule. Otherwise, downstream shipments are not loaded and not re-driven.

Default: true

glog.business.rule.rate.RateOfferingVolumeRule.skipIfShipmentActualsPresent

glog.business.rule.rate.RateOfferingWeightRule.skipIfShipmentActualsPresent

When True, OTM will skip the weight and volume constraint checks if the shipment has actuals assigned to it: so, if the order does not have a BOL_ACTUALS status of BOL_ACTUALS_NOT_ENTERED (then OTM considers actuals are assigned to the shipment).

If false, the rule is always checked.

glog.business.secondarycharge.ruleType.stop.considerDebriefsForScCharge

This property specifies whether to consider the debrief records while creating the secondary charge shipments for shipment stop.

When the property value is set to true and the secondary charge Rule Type is Shipment Stop and Quantity Type is Picked Up or Received, the actual planned or received ship units are considered while creating the secondary charge shipment. 

If the property is set to false and even though actual picked up and received ship units are present at the stop, only the planned picked up or received ship units of the first and last stops are considered while creating the secondary charge shipment.

Default: false 

glog.business.secondarycharge.shipUnitDwellTimeCalc.truncateDates

6.3.4

This property calculates dwell time for secondary charge shipments. Before calculating the dwell time, this property defines whether to truncate the departure and arrival time or not. When this property value is set to 'true', the departure and arrival time truncates to 12 A.M. For example, 08-04-2014 09:20:25 will be truncated to 08-04-2014 00:000:00) and then calculates the dwell time. If the property is set to 'false', the time is not truncated and the exact difference between departure time and arrival time is calculated as dwell time.

The default value for this property is 'true'.

glog.business.serviceprovider.redriveShipments

6.4.2

If using the parameter "PLAN SHIPMENTS WITH CARRIER COMMITMENT", this property allows you to prevent service provider assignment logic from redriving the shipment graphs of multi-leg shipments. This redrive does not work well with the parameter "Hold as Late as Possible" set, because it drives some shipments early.

The default is true.

The redrive can be avoided by setting this to false.

When false, and the redrive is avoided, a problem may arise when first leg shipments are subject to service provider commitments among carriers with different first leg transit times. For example, if service provider assignment switches a first leg shipment to a service provider with a longer transit time than the original service provider, and does not redrive, then the first leg shipment may end before the second leg shipment begins. (This is the situation that the redrive is designed to prevent.)

glog.business.serviceprovider.retender.skipServProv

22B

Unable to re-tender a shipment when one of the service provider in the flow is set to not allow tender. When you retender the shipment, the system evaluates all rates/carriers and does not remove carriers that cannot tender.

While retendering, the system will now skip the service provider if the 'Allow Tender' check box is not selected for that service provider. Use this property to either enable or disable this logic. Set this property to true while re-tendering a shipment, the system skips the service provider that does not allow tendering and goes to the next available service provider.

If you want to use the old behavior you have to set this property value as false.

Default: true

glog.business.session.useMatrixServiceToGenerateRushHours

20C

Set this property to true to use the HERE route matrix host for which the URL is specified in the here.route.matrix.host property.

Both of these properties are required to use the HERE route matrix host.

The default is false which means the Generate Rush Hours action will use the property of here.route.host.

glog.business.shipGroup.action.createShipGroup.disableInputUI

21C

Use this property to enable or disable the screen for the Create Shipment Group action which displays the criteria based on which the shipment groups will be generated.

The default value is false.

When the property is false, the action will not display the criteria screen and creates a shipment group based on the selected shipments and the information you provide.

When the property is true, the action displays the criteria screen based on which the shipments groups are generated.

glog.business.shipgroup.addRemoveShipment.reAssociateSecCharge

23B

This property is used to control the re-association of secondary charge shipments for the web actions Add Shipments to Group, Add Partial Shipments to Group, Remove Shipments from Group, and Remove Partial Shipments from Group.

While executing the above web actions if the property value is set to true, the system re-associates the secondary charge shipments. 

If the property value is set to false when executing the above web actions, the system doesn't re-associate the secondary charge shipments.

Default: true.

glog.business.shipgroup.findValidRules.forShipmentsWithNoItinerary

21A

When creating the shipment groups, at the end of a bulk plan or when searching for shipment groups for the action Add Shipment to Shipment Group, OTM tries to fetch the valid rules for the shipment. In order to consider fetching of these valid rules for shipments that does not have any itinerary (Handling Shipments, Secondary Charge Shipments, and SAW Shipments) set the property value to true.

Default: false

glog.business.shipment.action.createWAInput.sortByStartTime

22A

This property uses the start time of shipment and controls the sorting order of shipments, when you perform the Create Work Assignment action.

If the property is set to the values below:

      A - sorts the selected shipments in ascending order of start time

      D - sorts the selected shipments in descending order of start time

By default, if this property is not set to any value then the Create Work Assignment screen displays the order of shipment similar to the shipment order in the Shipment manager result screen.

glog.business.shipment.actions.rerateAndRecalculate.useDigiFrtRates

24A

If the shipment is currently planned with Digital Freight (DF) rate offering and this property is set to true, OTM considers DF rates for Rerate or Recalculate Shipment Cost shipment actions.
If this property is set to false, OTM does not consider the DF rates for Rerate or Recalculate Shipment Cost shipment actions.

glog.business.shipment.bypassVpdForShipmentRemoval

This property is used to ignore a shipment-based VPD profile when an action removes a shipment. If a shipment-based VPD profile is too narrowly defined, so that the shipment is actually not accessible when the associated ship units have been removed, then the VPD profile may actually prevent the shipment from being deleted. 

Setting this property to true will avoid this problem. The default is false. When false, any shipment-based VPD profile will be enforced when an action tries to remove a shipment. 

glog.business.shipment.alreadyFailedRateServiceCache

When calculating service time, this property configures Oracle Transportation Management to "remember" rate services that did not meet service time so that additional rates using that rate service will not be tested again.

glog.business.shipment.costFractionalDigits

This sets the decimal place precision when calculating shipment costs. You can enter zero or any positive integer  to define the precision.

For example, if you set this to 2, then Oracle Transportation Management will use 2 decimal places for all the shipment costs when adding them together. This prevents inaccurate calculations that may occur when adding decimals together as they appear in the database and then rounding or truncating them at the end of the calculation.

The default is null, which will use the numbers in the database exactly as they appear.

glog.business.shipment.deleteShipments.retainOrderMovements

6.0

Controls whether order movements are removed when shipments are deleted.

When this is false (the default), order movements on the deleted shipments will be removed, and the order release will be put in planned unscheduled status. If there are related downstream/upstream order movements or if the order release is split, you will be asked to set this property to True. If false, in a multi-leg scenario where an order is planned across multiple legs, you cannot not delete a shipment on one leg using the "Delete Shipment".

When the property is set to True, shipments and shipment ship units will be deleted, order movements on the deleted shipments will not be removed, and the order release will remain in planned final status. With the property set to true, the delete shipment function is essentially the same as querying all the order movements on that shipment and unassigning them.

If you plan order movements, you will probably want to set this to true. If you do not plan order movements, leave this as false.

glog.business.shipment.estimateServiceTime

Used for multi-leg planning where several leg options can be pruned using an estimated service time. Setting to On helps multi-leg logic run faster.

glog.business.shipment.ignoreStopSpecialServiceWhenCalcBobtailDeadhead

20A

This property is used to determine if a segment is bobtail or deadhead when using NFR stops and there is no shipment equipment for the segment. Set this to false to consider special services on the pickup or drop off stop when determining whether a segment is bobtail or deadhead. The default is true meaning special services are ignored when determining bobtail and deadhead on a segment.

When false, to determine whether a segment is deadhead or bobtail, OTM will look beyond whether there is a shipment equipment cover for the segment and look at special services for the stop to determine whether a segment is bobtail or deadhead.

For example, for the segment:

NFR --- PICKUPSTOP: if there is no shipment equipment going thru this segment, OTM will also look at the special service at PICKUPSTOP. If it is PICKLOADED, this segment will be considered bobtail, otherwise it will be considered deadhead.

For the segment:

DROPOFFSTOP --- NFR: if there is no shipment equipment cover for this segment, OTM will also look at the special service at DROPOFFSTOP. If it is DROPLOADED, this segment will be considered as bobtail, otherwise it will be considered deadhead.

glog.business.shipment.isZeroWeightVolumeShipmentUnloaded

20A

Indicates if the Loaded Distance on a shipment should be calculated as zero, "0", when you have a shipment with both the weight and the volume as zero. The default is false.

glog.business.shipment.legOptionOptimizer.maxNumItineraryOptions

19A

OTM can run out of memory due to the many combinations of rates, equipment, and legs. Each of these combinations is an "itinerary option". This property can guard against this. The default is 100000. For any order bundle, the bulk plan will not create more than this number of itinerary options. If this number of itinerary options is reached, the bulk plan will proceed normally, but it is possible that OTM will not find a least-cost solution.

Note: Even with this property, we do not recommend using Multi-modal Equipment Group Profile Sets on itinerary legs.

glog.business.shipment.maxAppendableShipments

6.2

The maximum number of results being returned by Find Appendable Shipments and being displayed in Append Shipment action.

glog.business.shipment.MaxNumberOfShipmentGroupsForSplitOrders

If the number of shipments is greater than the value set by this property, the shipments are grouped into the number of groups specified by the property.

However, it may not utilize the capacity of the cheapest carrier in some instances. In general, if the number of shipment groups, determined by this property, is increased it would give a better solution at the expense of run time and memory usage.

glog.business.shipment.maxNumViaPointCombinations

20B

This property determines the threshold for via point location combinations when the bulk plan is using an itinerary with lots of via point combinations. The default is 1000. It will fail an order bundle on this leg if there are too many via point combinations. If the threshold is exceeded, a warning will appear on the bulk plan results performance tab. Warnings will also appear in the logs and the diagnostics. For example, if there are 32 source via points, and 32 destination via points, then there would be 1024 possible combinations, which would exceed the threshold.  

This property addresses an unusual scenario wherein order releases each match to several "Pool-Crossdock" itineraries. If multiple order releases fit into a bundle, but cannot go on the same shipment due to time constraints (or other constraints not checked during bundling), and if the planning parameter ALLOW SMALL DIRECT ORDERS TO BE SPLITTABLE is not turned on, then enabling this property will avoid the possibility that an order release will incorrectly be planned onto multiple shipments. Setting the property to true will enable additional logic to prevent this problem.

The property is set to false by default.

glog.business.shipment.propagateEquipmentWeight

6.2.1

Use this property to propagate scale weights.

If this property is set to false (default), the copy just fills in the scale weight field. If this property is set to true, the ship unit line weight is changed and the shipment total weight is corrected.

This property controls whether to run additional logic to compute accurate order bundle time windows when maximum bundle sizes are larger than any equipment. This additional logic is executed only when Network Routing is used, and when the planning parameters ALLOW DIFFERENT RATE SERVICES FOR SPLIT ORDERS and COMPUTE SHIPMENT TIME WINDOW are set to true.The additional logic is executed when the property is set to true.

The property is set to false by default.

When the property is set to true, the application recalculates the shipment costs immediately after recording the shipment for tiered rating. This means if multiple shipments are being recorded, each shipment can get into different tiers. When set to false, this property recalculates shipment costs of all the shipments after they have been recorded.This means all the shipments will be in the same tier.

By default, this property is set to false.

glog.business.shipment.repacking.useCostBasedConoptParameters

21A

When true, you can select conopt optimization algorithms that are only available for cost based repacking used during non-cost based repacking.

To minimize splitting with ship unit building and ship unit repacking, set the glog.business.order.packing.allowRemnantToSplit property to false and set the glog.business.shipment.repacking.useCostBasedConoptParameters property to true. Then select logic configuration type of SUBLD CONTAINER OPTIMIZATION and select the parameter SUBLD COST-BASED CONOPT ALGORITHM,  and select the parameter value "5: Column Generation with Quick Pack and Single Container MIP".

By default, the property is set to false.

glog.business.shipment.totalPackageCount.multiplyByShipUnitCount

Default: False

When False, the Shipment field Total Package Count will be calculated by summing the package count from each of the lines.

When True, each package count will be multiplied by the ship unit count during summation. Setting the property to True enables the original behavior.

glog.business.shipment.trackingEvent.disableAddTrackingEventButton

23A

This property controls the appearance of the Add Shipment Tracking Event button on the Shipment Tracking Events page after performing the View Shipment Tracking Events web action on the Buy Shipment Events Manager screen.

When you set the property to true, and view any Shipment Tracking Event, the Add Shipment Tracking Event button will not be displayed.

The button will only be displayed when the ACL Shipment Event - Update is enabled and the property is set to false. If any of these is not enabled, the button will not be displayed.

Default: false

glog.business.shipment.useLegacyUtilRecalc

20C

When you set this property to false and while saving a shipment into database (persisting a shipment) without using shipment actuals, you may see some improvement in performance (based on the volume of data) only when the parameter CHECK EQUIPMENT CAPACITY IN REFERENCE UNITS is set to false.

By default, the property is set to true.

glog.business.shipment.useShipmentPlanningParameterSet

6.2

If true, use the shipment's parameter set (if any) for shipment actions. Otherwise, use the default parameter set (for user or for domain).

Default: true

glog.business.shipment.useTimeWindowRateCheck

22A

Default: False When False, only the order's early pick up time is considered when finding applicable rates. This may result in the use of an expired rate for shipments on legs other than the first leg on a multi-leg scenario. When true, the system will be picking up the right rate for a second rate on a multi-leg scenario. Setting the property to true will invoke the new behavior.

glog.business.shipmentactual.loadGraphThroughOrderReleases

20C

When you set this property to true, order movement graph in shipment actual will be loaded through order releases which are related to the actual shipment. If there are no related order releases, OTM will still load order movement graph through shipment.

When this property is set to false, OTM will decide the best way to load order movement graph either through shipment or order releases or ship unit lines.

By default, this property is set to false.

glog.business.shipmentactual.LockShipmentsOnly

21C

If you want to lock only related shipments instead of locking all related shipments, order releases and order movements, you should set this property to true.

By default,  this property is set to false and the system locks all related shipments, order releases, and order movements.

glog.business.shipmentEquipment.dataPopulation

5.5 CU4

This property provides the ability to turn off shipment equipment data population. The generation of the Equipment Initial/Number is not affected by this property, although the Equipment Group, Equipment Type and Tare Weight fields will not be populated if the property is False.

Default: True

glog.business.shipmentUpdateSession.checkShipmentConflictWhenCommitting

6.2.9

This property addresses conflicts which may arise when a current shipment being committed has been updated by another process during the execution of the current process.

When the property value is 0, do not try to detect conflict at all. When the property value is 1, treat the conflict as error and throw an exception. When the property value is 2, ignore the conflict but log a warning.

Default: 0

glog.business.shipmentUpdateSession.ignoreRemoveException.ShipmentInvolvedParty

6.0

If true, and the ShipmentInvolvedParties to be removed, no longer exist in database, OTM will log the RemoveException. This will allow any actions in process to continue.

Default: False

glog.business.shipment.useSShipUnitEquipRefUnit

22A

When this feature is turned on and if the parameter CHECK EQUIPMENT CAPACITY IN REFERENCE UNITS is set to true:

• for all planning actions such as bulk plan, build shipment, merge shipment  that involved equipment packing or equipment change,  shipment ship unit equipment reference unit records will be created either derived from shipment ship unit’s order ship unit, or keep the shipment ship unit equipment reference unit when Fixed ERU Count on shipment ship unit is true.

• if Fixed ERU Count is true on shipment ship unit, the equipment reference units defined on this ship unit will be used during container optimization packing. If Fixed ERU count is false, equipment reference units are from order ship units are used during container optimization packing.

• if Fixed ERU Count is true,  the shipment ship units equipment reference unit records will be kept on planned or planned order movements along with its shipment ship unit.   If Fixed ERU Count is false, the shipment ship units equipment reference unit records will be removed from its shipment ship unit when order movement is unplanned

• the shipment equipment reference unit section query the shipment ship unit equipment reference unit record

When this property is turned off:

• the system will not:

  • persist the shipment ship unit equipment reference unit records

  • load the shipment ship unit equipment reference unit records

  • allow user to add or edit shipment ship unit equipment reference unit records in the Shipment Ship Unit manager

  • display the new Shipment Ship Unit Equipment Reference Units under the More section on the shipment view screen

• the Fixed ERU Count field on the shipment ship unit edit screen should be read only or hidden from the user (can i say, disabled)?

• the shipment equipment reference unit section does not query the shipment ship unit equipment reference unit record

• the recalc of ERU utilization should not look at the shipment ship unit equipment reference unit record

• ignores the shipment ship unit equipment reference unit  records through integration, i.e. don’t persist, don’t export

Default: false.

glog.business.shipment.validateEquipmentByTrueRating

21C

When the planning parameter VALIDATE EQUIPMENT BY RATES is set to true, setting property glog.business.shipment.validateEquipmentByTrueRating to true will direct the system to perform actual rating and consider all order constraints while finding the set of rate-valid pieces of equipment for the container optimization logic.

Default: false.

glog.business.shipmentactual.usePlanningParameterSetOnShipment

23A

When this property is set to true and a shipment ID is provided in shipment actual, the planning parameter set defined on the shipment will be used instead of the domain-level planning parameter set. 
But if a shipment ID is not provided, (for example when shipment actual is used to persist a new shipment), then the domain-level planning parameter set will be used even if the property is set to true.

Setting the property to false will result in shipment actual using the domain-level planning parameter set instead of the parameter set available on the shipment.

Default: false

glog.business.taxCalcPrecision

This property is used to specify the precision for tax calculation.

Default: 5

glog.business.TrailerBuild.IsConsolidation

This is used for Trailer Builds. If True, the Break Bulk Location ID from shipment group rule is used as the shipment group source location ID. Otherwise, it is used as the group destination location ID. The default is FALSE.

In other words, when the property is true, the shipments in the shipment group are consolidated in the group source location. Otherwise, they are deconsolidated (break bulk) in the group destination location.

glog.business.TrailerBuild.PerformRounding

glog.business.TrailerBuild.RoundingFactor

6.0

This enables Trailer Build to build the shipment groups using the rounded weight and/or volume to determine the maximum weight/volume that could fit on a shipment group (trailer).

While adding up the shipment weight and volume to get the shipment group total weight and volume, the weight and volume of each shipment are calculated as follows:

If PerformRounding is WEIGHT or BOTH:

  weight = (CEIL(weight/RoundingFactor))*RoundingFactor

If PerformRounding is VOLUME or BOTH:

  volume = (CEIL(volume/RoundingFactor))*RoundingFactor

If PerformRounding is NONE, no rounding for weight/volume.

(CEIL is ceiling. CEIL(argument) is the smallest integer that is not less than the argument. For example, CEIL(3.1)= 4, CEIL(3.9)= 4, CEIL(3)= 3).

Valid values for perform rounding are: NONE, WEIGHT, VOLUME, BOTH. The default is NONE.

Default for rounding factor is 1.

glog.business.unassignOrders.loadLimitedGraph

6.2.3

This controls how many shipments and order movements are brought into the Unassign Order Release logic. When true, the Unassign Order Release logic will bring in only the shipments that actually have the to-be-unassigned order releases and the order movements on those shipments.

Only these shipments will be re-driven. This is recommended only when you are sure that no other shipments need to be re-driven as the result of the Unassign Order Release action.

Default: false

glog.business.workAssignment.preAssignResourceToSingleShipmentsinWA

18

When set to true, work assignment formation logic will fetch a resource for single shipment earlier in the process, so OTM does not skip the single shipment opportunities that could go earlier in the day.

Default: false

glog.business.workAssignment.sortBasedOnShipmentCost

These properties are being replaced by  the Logic Configuration - Resource Scheduler parameter, RS SEQUENTIAL SAVINGS SORT METHOD, if you select option "1. Start time ascending", "2. Weight descending" or "4. Cost descending". They will be considered only when the logic configuration parameter is set to the default of "0. None". The properties will be considered in this priority (sortBasedOnShipmentStartTime has highest priority followed by sortBasedOnShipmentWeight, followed by sortBasedOnShipmentCost).  

glog.business.workAssignment.sortBasedOnShipmentStartTime

18

glog.business.workAssignment.sortBasedOnShipmentWeight

18