Parameter Name | Data Item | Data Type | Req/Opt | I/O/Both |
szBranch | MCU | char | NONE | NONE |
An alphanumeric code that identifies a separate entity within a business for which you want to track costs. For example, a business unit
might be a warehouse location, job, project, work center, branch, or plant.
You can assign a business unit to a document, entity, or person for
purposes of responsibility reporting. For example, the system provides reports of open accounts payable and accounts receivable by
business unit to track equipment by responsible department.
Business unit security might prevent you from viewing information about business units
for which you have no authority.
|
mnShortItemNumber | ITM | MATH_NUMERIC | NONE | NONE |
An inventory item number. The system provides three separate item numbers plus an extensive cross-reference capability to other item
numbers (see data item XRT) to accommodate substitute item numbers, replacements, bar codes, customer numbers, supplier numbers, and
so forth. The item numbers are as follows:
o Item Number (short) - An eight-digit, computer-assigned item number
o 2nd Item Number - The
25-digit, free-form, user defined alphanumeric item number
o 3rd Item Number - Another 25-digit, free-form, user defined alphanumeric item
number |
cStockingType | STKT | char | NONE | NONE |
A user defined code (41/I) that indicates how you stock an item, for example, as finished goods or as raw materials. The following stocking
types are hard-coded and you should not change them:
0 Phantom item
B Bulk floor stock
C Configured item
E Emergency/corrective
maintenance
F Feature
K Kit parent item
N Nonstock
The first character of Description 2 in the user defined code table indicates if the item
is purchased (P) or manufactured (M). |
cIssueTypeCode | ITC | char | NONE | NONE |
A code that indicates how the system issues each component in the bill of material from stock. In Shop Floor Management, it indicates how
the system issues a part to a work order. Valid values are:
I Manual issue
F Floor stock (there is no issue)
B Backflush (when the part is
reported as complete)
P Preflush (when the parts list is generated)
U Super backflush (at the pay-point operation)
S Sub-contract item (send
to supplier)
Blank Shippable end item
You can issue a component in more than one way within a specific branch/plant by using different
codes on the bill of material and the work order parts list. The bill of material code overrides the branch/plant value. |
cPlanningCode | MPST | char | NONE | NONE |
A code that indicates how Master Production Schedule (MPS), Material Requirements Planning (MRP), or Distribution Requirements
Planning (DRP) processes this item. Valid codes are:
0 Not Planned by MPS, MRP, or DRP
1 Planned by MPS or DRP
2 Planned by MRP
3 Planned by MRP with additional independent forecast
4 Planned by MPS, Parent in Planning Bill
5 Planned by MPS, Component in
Planning Bill
These codes are hard coded. |
mnPlanningFence | MTF1 | MATH_NUMERIC | NONE | NONE |
The number of days that the system uses in conjunction with the time fence rule to determine how the forecast is used. Enter the number of
days after the start date when the time fence rule changes from the first rule to the second rule.
For example, if the time fence rule is S (customer
demand before the time fence, forecast after the time fence), the generation start date is 01/03/05,and the planning time fence is 3 days, the
system plans using customer demand through 01/06/05. Beginning on 01/07/05, the system plans using the forecast.
Note that:
o The
system does not count the generation start date; that is, the day after the generation start date is day 1.
o For manufactured items, the system
counts working days, as defined in the Shop Floor Calendar.
o For purchased items, the system counts calendar days. |
mnFreezeFence | MTF2 | MATH_NUMERIC | NONE | NONE |
The number of days from the generation start date within which the system does not generate action messages.
For example, if the
generation start date is 01/03/05, and the freeze time fence is 3 days, the planning system does not generate messages with required dates that are
less than or equal to 01/06/05.
Note:
o The system does not count the generation start date; that is, the day after the generation start date is
day 1.
o For manufactured items, the system counts working days, as defined in the shop floor calendar.
o For purchased items, the system
counts calendar days.
|
mnMessageDisplayFence | MTF3 | MATH_NUMERIC | NONE | NONE |
The number of days after the generation start date within which the system should display order messages.
For example, if the generation
start date is 01/01/05, and the message time fence is 30 days, the system displays messages with dates less than or equal to 01/31/05. The
system does not display messages with dates of 02/01/05 or later. However, the planning horizon for orders continues past this date and is
reflected in available to promise totals.
Note that:
o The system does not count the generation start date; that is, the day after the generation
start date is day 1.
o For manufactured items, the system counts working days, as defined in the Shop Floor Calendar.
o For purchased
items, the system counts calendar days. |
mnTimeFence | MTF4 | MATH_NUMERIC | NONE | NONE |
Manufacturing time fence 4 - Future use. |
cPlanningFenceRule | MPSP | char | NONE | NONE |
A code (system 34, table TF) that the system uses in conjunction with the Planning Time Fence Days field to determine how forecast
demand or actual customer demand is used.
For example:
S tells the system to plan using customer demand before the time fence and forecast
after the time fence
F tells the system to plan using forecast before the time fence and forecast plus customer demand after the time fence
If
you enter 5 in the Planning Time Fence Days field and S in this field, then the system uses only customer demand for the regeneration for the
first 5 days. After 5 days, the system uses the forecast for the regeneration.
Valid codes are:
C Customer demand before, greater of forecast
or customer demand after
F Forecast before, forecast plus customer demand after
G Greater of forecast or customer demand before,
forecast after
S Customer demand before, forecast after
1 Zero before, forecast after
3 Zero before, forecast plus customer demand after |
cFixedVariableLeadtime | MRPP | char | NONE | NONE |
A code that determines whether the system uses fixed or variable leadtimes.
This code works in conjunction with the value from either the
Level Leadtime field or the Leadtime Per Unit field. Valid codes are:
F Fixed leadtime - The system calculates work order start dates using the
value from the Leadtime Level field.
V Variable leadtime - The system calculates work order start dates using the value from the Leadtime
Per Unit field. |
mnLeadtimeLevel | LTLV | MATH_NUMERIC | NONE | NONE |
A value that represents the leadtime for an item at its assigned level in the production process, as defined on Plant Manufacturing Data.
The system uses this value to calculate the start dates for work orders using fixed leadtimes.
Level leadtime is different for purchased and
manufactured items:
Purchased - The number of calendar days required for the item to arrive at your branch/plant after the supplier receives your
purchase order.
Manufactured - The number of workdays required to complete the fabrication or assembly of an item after all the
components are available.
You can enter level leadtime manually on Manufacturing Values Entry, or you can use the Leadtime Rollup program to
calculate it. To calculate level leadtime using the Leadtime Rollup program, you must first enter a quantity in the Manufacturing Leadtime Quantity
field in the Item Branch table (F4102). |
mnLeadtimeMfg | LTMF | MATH_NUMERIC | NONE | NONE |
The total number of days required to build an item from its lowest level components to the final assembly. This value is the total of the level
leadtimes for all manufactured items, plus the highest manufacturing leadtime for all its components.
If all components are purchased, the
manufacturing leadtime equals the item's level leadtime. Purchased item leadtimes are not included in the calculation of manufacturing
leadtimes.
You can enter the manufacturing leadtime manually or you can have the system calculate it when you run the Leadtime Rollup program. |
mnLeadtimeCumulative | LTCM | MATH_NUMERIC | NONE | NONE |
The total number of days required to build an item from its lowest level components to the final assembly. The system calculates the value
differently for manufactured and purchased items.
Manufactured - The total of all level leadtimes for all manufactured items,plus the highest
cumulative leadtime of all its components.
Purchased - The item's level leadtime. Purchased item leadtimes are included in the calculation of
cumulative leadtimes.
You can enter this value manually or you can have the system calculate it when you run the Leadtime Rollup program. |
mnLeadtimePerUnit | LTPU | MATH_NUMERIC | NONE | NONE |
The total number of hours required to build one unit as specified on the routing. This value is factored by the time basis code.
You can enter
this value manually or you can have the system calculate it when you run the Leadtime Rollup program. The system overwrites this value
when you run the Leadtime Rollup program.
The system uses this field to calculate start dates for work orders when you use variable leadtimes. |
mnMFGLeadtimeQty | MLQ | MATH_NUMERIC | NONE | NONE |
The quantity that determines the leadtime level for a manufactured item. Each of the routing steps for the item are extended by this quantity.
For the system to calculate the leadtime level, the quantity in this field must be a value other than zero. |
mnShrinkFactor | SRNK | MATH_NUMERIC | NONE | NONE |
A fixed quantity or percentage that the system uses to determine inventory shrinkage for an item. The system increases the planned order
quantity by this amount in MPS/MRP/DRP generation. The shrink factor method you specify for the item determines whether the shrink factor
is a percentage or a fixed quantity.
If you are entering a percentage, enter 5% as 5.00 and 50% as 50.00. |
cShrinkFactorMethod | SRKF | char | NONE | NONE |
A value that determines whether the shrink factor you enter for this item is a percentage or a fixed quantity. Valid values are:
%
Percentage of order or requested quantity
F Fixed amount to be added to quantity |
cOrderPolicyCode | OPC | char | NONE | NONE |
A code that specifies the rules for inventory reordering in the Requirements Planning and Procurement systems. Valid values are:
0
Reorder
point (Not planned by MPS/MRP/DRP)
1
Lot-for-lot or as required
2
Fixed order quantity
3
Economic order quantity (EOQ)
4
Periods of
supply
5
Rate scheduled item
Note: These values are hard-coded.
|
mnOrderPolicyValue | OPV | MATH_NUMERIC | NONE | NONE |
A value that the system uses in conjunction with the order policy code to represent one of the following:
o When you select order policy
code 2 (fixed order quantity), this value represents the fixed order quantity.
o When you select order policy 4 (periods of supply), this value
represents the number of days of net requirements that the system uses to determine order size.
o When you select order policy code 5 (rate
scheduled item), this value represents the desired inventory level. When the ending available quantity is less than the desired inventory level,
then the system issues an "increase rate to" message. When the ending available quantity is greater than the desired inventory level, then
the system issues a "decrease rate to" message.
|
mnAccountingCostQuantity | ACQ | MATH_NUMERIC | NONE | NONE |
An amount that the system uses in the Cost Rollup program to determine the allocation of setup costs. The system totals the setup costs
and divides the sum by this quantity to determine a unit setup cost. The default is 1. |
cTimeBasisCode | TIMB | char | NONE | NONE |
A user defined code (30/TB) that indicates how machine or labor hours are expressed for a product. Time basis codes identify the time
basis or rate to be used for machine or labor hours entered for every routing step. For example, 25 hours per 1,000 pieces or 15 hours per
10,000 pieces. You can maintain the time basis codes in Time Basis Codes.
The system uses the values in the Description-2 field on the User
Defined Codes form for costing and scheduling calculations. The description is what the code represents, but is not used in calculations. |
mnMoveHours | MOVD | MATH_NUMERIC | NONE | NONE |
The planned hours that are required to move the order from this operation to the next operation in the same work center.
If the Routing
Master values are blank, the system retrieves the default value from the work order routing. However, the system uses these values only for
backscheduling variable leadtime items. |
mnQueueHours | QUED | MATH_NUMERIC | NONE | NONE |
The total hours that an order is expected to be in queue at work centers and moving between work centers.
The system stores this value in
the Item Branch table (F4102). You can calculate this value using the Leadtime Rollup program or you can enter it manually. When you run the
Leadtime Rollup program, the system overrides manual entries and populates the table with calculated values. |
mnStandardSetupHours | SETL | MATH_NUMERIC | NONE | NONE |
The standard setup hours that you expect to incur in the normal completion of this item. This value is not affected by crew size. |
cErrorIndicator | ERRC | char | NONE | NONE |
This error code indicates if any errors occurred during the creation of the Trip Document Detail (F4914) records by the Delivery Document
Set Server program (XT4914). |
mnPlannerNumber | ANPL | MATH_NUMERIC | NONE | NONE |
The address number of the material planner for this item. |
mnLowLevelCode | LLX | MATH_NUMERIC | NONE | NONE |
This identifies the lowest level in any bill of material at which a particular component may appear.. |
cSuppressErrorMessage | EV01 | char | NONE | NONE |
An option that specifies the type of processing for an event.
|
szErrorMessageID | DTAI | char | NONE | NONE |
A code that identifies and defines a unit of information. It is an alphanumeric code up to 8 characters long that does not allow blanks or
special characters such as %, &, or +. You create new data items using system codes 55-59. You cannot change the alias.
|
cNetChangeFlag | MRPC | char | NONE | NONE |
This flag is turned on when this item has had some kind of activity that would affect one of the different planning parameters that would
impact the Requirements Plan. |
idF4102Pointer | GENLNG | ID | NONE | NONE |
General purpose ID variable. |
szLineType | LNTY | char | NONE | NONE |
A code that controls how the system processes lines on a transaction. It controls the systems with which the transaction interfaces, such as
General Ledger, Job Cost, Accounts Payable, Accounts Receivable, and Inventory Management. It also specifies the conditions under
which a line prints on reports, and it is included in calculations. Codes include the following:
S
Stock item
J
Job cost
N
Nonstock item
F
Freight
T
Text information
M
Miscellaneous charges and credits
W
Work order |
mnSafetyStock | SAFE | MATH_NUMERIC | NONE | NONE |
The quantity of stock kept on hand to cover high-side variations in demand. |
cLotStatusCode | LOTS | char | NONE | NONE |
A user defined code (41/L) that indicates the status of the lot. If you leave this field blank, it indicates that the lot is approved. All other codes
indicate that the lot is on hold.
You can assign a different status code to each location in which a lot resides on Item/Location Information or
Location Lot Status Change. |
cAbcCode | ABCS | char | NONE | NONE |
A code that specifies this item's ABC ranking by sales amount.
Valid values are:
A Assign this item to the first (largest) amount ranking
B
Assign this item to the second (intermediate) amount ranking
C Assign this item to the third (smallest) amount ranking
D Do not include this
item when you run ABC Analysis There are three types of ABC analysis-sales, margin, and on-hand value. Within each type of analysis, you
can have three groups-A, B, and C.
The ABC Code fields contain a percentage that tells the system how to define the A, B, and C groups for
categorizing items during ABC analysis. Each group measures a total within the type of analysis.
For all groups, the system compares the
appropriate sales, margin, or on-hand value totals of a single item to the appropriate total for all items and calculates the value of each item. An
item's value is its percentage of the appropriate total. The system then arranges the values of all items from highest to lowest value and
accumulates the percentages. What happens next depends on the group:
A group: If an item's value causes the accumulated total to exceed the
A accumulated percentage, the system assigns the item to the B group.
B group: When the accumulated total reaches the percentage you
entered for items in the A group, it continues adding values until it reaches the percentage you entered for items in the B group. The system
assigns all items whose value falls between the A and B percentages to the B group.
C group: The C group consists of items whose
accumulated value exceeds the B percentage. The percentage that you usually enter for the C group is .999. |
cAllocateByLot | CMGL | char | NONE | NONE |
A code that indicates the method that the system uses to commit lot items from inventory. Valid codes are:
1 The normal commitment
method for inventory. The system commits inventory from the primary location and then from secondary locations.
The system commits
inventory from the locations with the most inventory before committing inventory from locations with the least. The system commits backorders to
the primary location.
2 The inventory commitment method by lot number. The system commits inventory by lot number, starting with the
lowest lot number and committing orders to available lots.
3 The inventory commitment method by lot expiration date. The system commits
inventory from the locations with the earliest expiration date first. The system considers only locations with expiration dates greater than or equal
to the sales order or parts list requested date. |
szMasterPlanning | PRP5 | char | NONE | NONE |
A user defined code (41/P5) that indicates the landed cost rule for an item.
The landed cost rule determines purchasing costs that exceed
the actual price of an item, such as broker fees or commissions. You set up landed cost rules on the Landed Cost Revisions form. |
mnBuyer | BUYR | MATH_NUMERIC | NONE | NONE |
The address number of the person responsible for setting up and maintaining the correct stocking levels for the item. |
cPotencyControl | OT1Y | char | NONE | NONE |
A code that indicates whether you control the item by potency. |
mnStandardPotency | STDP | MATH_NUMERIC | NONE | NONE |
The percentage of active ingredients normally found in an item. |
cLotExpDateCalcMeth | LECM | char | OPT | NONE |
A code that indicates which method the system uses for calculating the expiration date for a lot. Valid values are:
1
On-hand date + shelf life
days
2
Based on date + shelf life days
3
Least expiration date of active components
|
cActiveIngredientFlag | AING | char | OPT | NONE |
A code that indicates whether an item is an active component of a parent item. When the item is an active component, the system can
calculate a parent item's expiration date by comparing all component expiration dates and choosing the earliest date. Valid values
are:
Blank
The item is not an active component of a parent item.
1
The item is an active component of a parent item. |
cCrossDockFlagYN | XDCK | char | OPT | NONE |
A code that associates items or order lines with cross-dock processing. This code might indicate whether an item or an order line is eligible
for cross-docking, whether it was cross-docked, or whether it needs to be cross-docked. When it is assigned to an item or item-branch, this
code indicates that the item or the item in the branch/plant is eligible for cross-docking. When it is assigned to an order line, this code
indicates that the order line needs to be cross docked. Valid values are:
1
Yes, cross-docking is on
0 (blank)
No, cross-docking is off
|