System Options

SYSTEM

• Table’s Owner: RMS

  • What it means: The database “folder” (schema) where the app’s tables live.
  • Scenario: If IT needs to run a report directly on the database, they look in the RMS schema.

• Normal or 454 calendar: 454

  • What it means: You’re using the retail 4-5-4 calendar. Each quarter has 3 “months” with 4 weeks, then 5 weeks, then 4 weeks.
  • Scenario: Your weekly and monthly sales reports line up with 4-5-4 weeks rather than standard calendar months, so comparisons (year-over-year) are fair by number of weeks.

• Corporate HQ Country: US

  • What it means: The company’s main country.
  • Scenario: Default country formats, tax assumptions, and addresses follow US standards unless a specific location overrides them.

• Primary Currency: USD

  • What it means: Your home currency for financials and reporting.
  • Scenario: A UK store sells in GBP, but corporate results and stock ledger roll up in USD using exchange rates.

• Consolidated Exchange Rate

  • What it means: Use one consistent set of exchange rates for all modules.
  • Scenario: Planning, purchasing, and the ledger all convert EUR to USD using the same rate, so totals match across systems.

• Language: English

  • What it means: The default language of the user interface and seeded descriptions.
  • Scenario: Screen labels, error messages, and default text are in English.

• Historical Exchange Rates to Display: 5

  • What it means: Show the last 5 rate changes in the currency screen.
  • Scenario: A finance user reviewing EUR/USD can quickly see the previous 5 entries to spot trends.

• Image Path: [redacted]

  • What it means: Where the system looks for product photos.
  • Scenario: When you open an item, RMS fetches its picture from this location. If wrong, images won’t show.

• Default Item Image

  • What it means: The “fallback” picture for items without their own image.
  • Scenario: If a new SKU has no photo yet, users see a standard “no image available” graphic.

• Publish RIB Objects: Deltas Only

  • What it means: When sending data to other systems via RIB, send only what changed (not the full record).
  • Scenario: If only the item’s cost changed, downstream systems get a small “change-only” message—faster and lighter on integrations.

FINANCIALS

• Stock Ledger Retail Tax Inclusive

  • What it means: Your retail prices in the stock ledger are assumed to include tax.
  • Scenario A: Inclusive (ON). A $10 shelf price already includes sales tax; ledger values reflect that.
  • Scenario B: Exclusive (OFF). A $10 shelf price is before tax; tax is added at sale, and the ledger tracks retail excluding tax.

• Use Budgeted Shrinkage for Ending Inventory

  • What it means: When calculating ending inventory, the ledger can include a planned shrink amount (losses from theft, damage, etc.).
  • Scenario: You expect 1% shrink monthly. If on, the ledger reduces ending inventory by that budgeted 1% even before the physical count.

• Close Month With Open Counts

  • What it means: Allows you to close the accounting month even if some store counts aren’t completed.
  • Scenario: It’s month-end, 2 stores haven’t finished counts. If this is ON, finance can still close the period and reconcile differences next month.

• Cost Method: Average Cost

  • What it means: Inventory cost is tracked as a moving average of what you paid over time.
  • Scenario: You buy 10 units at $8 and later 10 at $12. Average cost becomes $10. When you sell, the cost of goods uses $10, not the oldest or newest cost.

• G/L Rollup Level: Department

  • What it means: When posting to the general ledger, results are grouped at the Department level.
  • Scenario: Sales, markdowns, and inventory changes hit the GL summarized by departments (e.g., Men’s Apparel, Footwear) instead of subclass or class. Simpler ledger, less detail.

• Margin Impact History Records

  • What it means: Track events that change margin over time (like price changes, cost updates, markdowns).
  • Scenario: You drop a price from $20 to $15. The system records this and you can later see how it affected margin trends.

• Maximum Cumulative Markon

  • What it means: A ceiling on total markup from cost to retail across all markups.
  • Scenario: Policy says retail should not exceed cost by more than 80% cumulatively. If someone tries to increase price beyond that, the system can block or warn.

• Minimum Cumulative Markon

  • What it means: A floor on total markup from cost to retail.
  • Scenario: To protect margin, you require at least 40% markup. If someone tries to set a retail that gives only 20%, the system flags it.

• Start of Half Month: 2

  • What it means: Defines how “half-month” splits are calculated for reporting or proration.
  • Scenario: If “2” means the second week of a 4-5-4 period marks the split, accruals or allocations that use half-month logic will cut there. Your organization’s definition drives this setting.

• Stock Ledger Time Interval: Week

  • What it means: The stock ledger summarizes activity by week.
  • Scenario: Inventory, cost, and margin movements roll up in weekly buckets (aligned to your 4-5-4 weeks). If set to Month, they’d roll up monthly.

Putting it together with a simple day-in-the-life example

• A buyer raises a cost on a T-shirt from $8 to $9. With Average Cost, the system blends this into the existing stock’s cost. Margin Impact History records the change so finance can see its effect later.
• The pricing team lowers the retail from $20 to $18. With Minimum/Maximum Cumulative Markon rules, the system checks the new markup is within allowed bounds before saving.
• At week’s end, the Stock Ledger posts activity by week. Because the ledger is Retail Tax Inclusive, the retail values already include tax.
• Corporate reports roll up in USD using Consolidated Exchange Rates, so a Canadian store’s CAD sales are converted consistently.
• Integration messages to downstream apps send only what changed (Deltas Only), keeping traffic light and fast.

ELC Inclusive on Pricing and Acquisition Cost :

Company Stores checkbox	Customer Stores checkbox	Pricing basis used	Acquisition cost basis	COGS impacted by ELC	Typical use case	Simple scenario	Pros	Cons
ON	OFF	ELC for Company Stores; Vendor cost for Customer Stores	ELC for Company Stores; Vendor cost for Customer Stores	Company Stores only	Retail-first organizations prioritizing owned-store accuracy	PO cost $8 + $2 freight/duty = ELC $10; Company Store retail set from $10; franchise priced per policy	Accurate retail margins and inventory valuation in owned stores	Wholesale/franchise margins may ignore logistics costs
OFF	ON	Vendor cost for Company Stores; ELC for Customer Stores	Vendor cost for Company Stores; ELC for Customer Stores	Customer Stores only	Wholesale/franchise-focused businesses	ELC $10; ship to franchise at $12; COGS $10; margin $2 on shipment	Accurate wholesale/franchise margins	Retail channel may underprice if freight/duty are material
ON	ON	ELC for both	ELC for both	Both	Consistent true cost across all channels	ELC $10; Company Store retail $16 (60% markup); Customer Store wholesale $12; COGS $10 in both	Consistency; accurate margins and valuation	Retail may rise; more frequent landed cost true-ups
OFF	OFF	Vendor cost for both	Vendor cost for both	Neither	Negligible freight/duty or costs handled outside RMS	Retail derived off $8 vendor cost; freight later via GL adjustments	Simpler operations; fewer cost adjustments	Risk of underpricing and misstated inventory/COGS if logistics costs are meaningful

Notes:

• ELC = Estimated Landed Cost (vendor cost + freight + duty + fees).
• When ELC is enabled for a store type, both pricing and acquisition cost use ELC as the cost basis. Landed cost true-ups may adjust inventory/COGS when final charges arrive.

Foundation Data:

Section	Term	Definition	Valid Values (typical)	Example
Foundation	Department / Class / Subclass	Three levels to organize products: Department (big group), Class (smaller group), Subclass (most specific).	Free-text codes/names per company standards	Department=Grocery, Class=Beverages, Subclass=Soft Drinks
Foundation	Automatically Generate IDs (unchecked)	If unchecked, you type the codes; system won’t auto-generate them.	Checked / Unchecked	Unchecked → You set Department code “GROC” manually
Foundation	Domain Level: Subclass	Rules/reports apply at the most detailed level (Subclass).	Department, Class, Subclass	Choose Subclass to control pricing at “Soft Drinks” vs “Juices”
Supplier	Automatically Generate IDs (unchecked)	You assign supplier codes yourself.	Checked / Unchecked	Unchecked → Create supplier “COCA01” manually
Supplier	Bracket Costing (checked)	Unit cost drops when buying more (price breaks).	Checked / Unchecked	1–99 units = $10; 100+ units = $9
Item	Grocery Items (checked)	Marks items as grocery so grocery rules (barcode/tax/shelf-life) apply.	Checked / Unchecked	Checked → Milk, cereal, soda flagged as grocery
Item	Auto Approve Child Items (checked)	Variations (sizes/flavors) get auto-approved—no extra step.	Checked / Unchecked	Creating “Soda 500ml” and “Soda 1L” auto-approves both
Item	EAN13 Prefix: 123456	Starting digits for generating EAN-13 barcodes.	Numeric string (commonly 6–9 digits depending on setup)	Prefix 123456 → EAN generated like 1234560000013
Item	Default Packing Method: Flat	Default way items are packed; Flat = simple pack (no special nesting).	Flat, Each, Case, Inner, Layer, Pallet (varies by setup)	Flat → Item ordered/stored in straightforward packs
Cost	Minimum Between Create and Effective: 1 Day	New cost must start at least 1 day after you set it to avoid same-day confusion.	Integer days (e.g., 0–30)	Create cost on Jan 1; effective no earlier than Jan 2
Cost	Retention of Cost Events: 7 Days	Keep cost change history for this many days.	Integer days (e.g., 1–365+)	You can review a cost change made 5 days ago
Rounding	Order Rounding Level: Case	Orders round to full cases rather than eaches, matching supplier packs.	Each, Inner, Case, Layer, Pallet	Need 13 each; case size 12 → system orders 2 cases (24 each)
Rounding	Inner	“Inner pack” unit (smallest pack inside a case).	Numeric pack size defined per item	1 inner = 6 each
Rounding	Case	A box of units.	Numeric pack size defined per item	1 case = 12 each
Rounding	Layer	One horizontal layer of cases on a pallet.	Derived from case count per layer	1 layer = 10 cases
Rounding	Pallet	Full stack of layers for bulk shipping.	Derived from layers per pallet	1 pallet = 5 layers = 50 cases
Rounding	50.00% (for Inner/Case/Layer/Pallet)	Balanced rounding preference—no pack level is strongly favored over another.	0%–100% weights per level (configured per policy)	All set to 50% → system can choose most practical pack size without strong bias

• Functional > Functionality Used in the Application

  • Contract: Enables contract purchasing features (e.g., PO against contracts, contract pricing/terms).
  • Estimated Landed Cost: Turns on ELC/Landed Cost calculation so RMS carries estimated freight, duty, and other charges through item/location costs and POs.
  • Organizational Units: Enables OU structures for financial/approval segregation and reporting.
  • OTB: Activates Open-to-Buy integration and controls so merchandising planning can reserve/validate budgets.

• Default Values for Units of Measure

  • Standard UOM: EA
    • Default each as the base selling/stocking UOM for items unless overridden.
  • Dimension UOM: IN
    • Default dimensional measure for length/width/height on items, packs, shipments.
  • Weight UOM: LBS
    • Default weight measure for items, cases, and shipments.
  • Unit of Purchase: Case / Standard Unit of Measure
    • Default vendor purchase UOM. If “Case,” PO lines default to case packs; if “Standard UOM,” they default to the base UOM (EA) unless a vendor-item record specifies differently.

• Item Identifier Generation Rule

  • Check Digit with modulus 1 and positional weights
    • RMS can auto-generate item IDs and validate with a check-digit algorithm. Your configuration indicates:
      • Algorithm: Mod 1 check digit
      • Weights by position: Weight 8=1, 7=2, 6=3, 5=4, 4=5, 3=8, 2=4, 1=2
    • How it works: multiply each digit by its positional weight, sum, then compute sum mod 11 to produce/validate the check digit. This reduces data-entry errors on internal item numbers or barcodes configured to use this rule.

What this implies operationally

• Master data: New item creation will default to EA/IN/LBS and purchase in Case or Standard UOM as set; vendor-item records or packs can override.
• PO and costing: With ELC enabled, PO costs and item/location costs may include estimated charges; integrations to financials and SIOCS/SIM typically expect these fields populated.
• Planning: OTB enablement means some ordering or approvals might check budget availability.
• Governance: If you plan to change any of these options, validate in a lower environment; some flags (ELC, OTB) affect batch jobs, cost calculations, and data integration. Changes often require cache refresh or app restart to take effect consistently.

Inventory:

Replenishment

• Default Size Profile
  What it does: Sets default size proportions when sending units by size.
  Example: Your T-shirt size curve is S:20%, M:40%, L:30%, XL:10%. If the system decides to send 100 units to Store A, it proposes S=20, M=40, L=30, XL=10 (rounded to packs if needed). If there’s no store-specific sales history yet, it uses this default profile.

• Use Size Profile on Presentation Stock
  What it does: Applies size proportions to presentation minimums.
  Example: Store A needs 8 units on the wall for presentation. With size profile on, it aims for S=2, M=3, L=2, XL=1 rather than all 8 in one size. If it’s off by a unit due to rounding, it adjusts the closest sizes.

• WH / Cross Link Stock Category
  What it does: Chooses which warehouse inventory pool can fulfill store orders.
  Example: The DC has stock categories: “Forward” and “CrossDock.” If this setting points to “CrossDock,” then store orders sourced on arrival (flow-through) will only use inventory marked as CrossDock. If only Forward stock is available, the order won’t allocate from it.

• Use Location Activity Schedule
  What it does: Honors store calendars (closed days, inventory counts).
  Example: Store B is closed Mondays and has inventory count on Wednesday. If the system would normally propose a delivery on Wednesday, it pushes the arrival to the next valid day (e.g., Thursday) so the store isn’t scheduled to receive during count.

• Use Location Delivery Schedule
  What it does: Uses store delivery slots/cutoffs to set order dates.
  Example: Store C receives only Tue/Thu. You run replenishment on Monday. The system plans arrival for Tuesday (next valid slot). If you miss the Monday cut-off time, it plans for Thursday instead. Orders won’t land on non-delivery days.

• Reject Store Orders
  What it does: Stops orders that violate rules.
  Example: An item isn’t ranged to Store D or is flagged “Not Orderable.” Without this rule, the system might create a partial/bad order. With rejection on, it blocks the order and raises an exception in a worklist for review.

• Distribution Rule: Proration
  What it does: Splits limited stock fairly based on demand.
  Example: You have only 300 units available, but the stores’ calculated needs total 600 (A=300, B=200, C=100). Proration gives A=150, B=100, C=50—each gets 50% of their need, rather than A getting everything.

• Order Not After: 0 Days
  What it does: Prevents creating orders that should have arrived in the past.
  Example: Today is the 10th. An order is calculated that would need to arrive on the 9th. With “0 Days,” the system won’t backdate; it schedules the next feasible arrival (e.g., the 11th) based on delivery schedules.

• Worksheet PO Cleanup Delay: 7 Days
  What it does: Auto-cleans draft POs that sit too long.
  Example: A buyer creates a draft PO worksheet on the 1st and never submits it. On the 8th, the system auto-deletes/archives it so the worksheet list doesn’t fill with stale drafts.

• Outside Customer Order Lead Time: 30 Days
  What it does: Uses 30 days lead time when specific lead time is unknown for special orders/external orders.
  Example: A marketplace order requires the DC to source from a vendor with no item-loc lead time set. The system uses 30 days as the default, so the earliest promised arrival date is current date + 30 days.

• Max Weeks of Supply: (blank)
  What it does: Caps how much stock the system will hold. Blank means no global cap.
  Example: If blank, an item with a long lead time might get a large buy. If you set 8 weeks, and the need calculation suggests 12 weeks, the system caps to 8 weeks to avoid overstock.

• Maximum Scaling Iterations: 600
  What it does: Limits how many times the algorithm tries to fit constraints (packs/min/max/supply).
  Example: When balancing case-pack constraints across many stores, the system iterates adjustments. If it can’t find a “perfect” fit by 600 tries, it stops with the best feasible distribution—preventing endless loops.

• Warehouse Store Assignment Type: All
  What it does: Controls which stores a warehouse can serve.
  Example: With “All,” the DC can replenish any ranged store. If you changed it to “Assigned Only,” the DC would only serve stores explicitly assigned—useful when multiple DCs cover different regions.

Investment Buy

• Look Ahead: 7 Days
  What it does: Evaluates benefits of buying ahead over the next 7 days.
  Example: A promo starts in 5 days. With a 7-day look-ahead, the system considers the upcoming uplift and may recommend an extra buy now to be ready.

• Annual Cost of Money: (blank) %
  What it does: Carrying cost rate for holding inventory. Blank often defaults to 0% or a system default.
  Example: If set to 12%, the model penalizes holding inventory longer, so marginal buys that tie up cash for weeks must produce enough margin to beat 12% annualized cost. If blank/0%, the system is more likely to approve extra inventory.

• Storage Type: Warehouse
  What it does: Applies warehouse storage costs to the ROI math.
  Example: Extra units purchased for an event will sit in the DC. The system uses the warehouse cost tables (not store backroom) to compute carry/storage costs.

• Target ROI: 20%
  What it does: Minimum profitability threshold for an investment buy.
  Example: If an investment buy calculates at 18% ROI, the recommendation is rejected; at 24%, it’s approved.

Warehouse Storage

• Cost Measure: Pallet
  What it does: Storage cost is tracked per pallet.
  Example: If 1 pallet holds 40 cases, and you store 3 pallets of extra goods for a week, the storage cost uses “3 pallets × weekly cost.”

• Cost UOM: (blank)
  What it does: The UOM label (e.g., PLT). If blank, costing may not compute or convert correctly.
  Example: Populate as “PLT” so the system knows 1 PLT = X cases or cubic volume if conversions are configured.

• Weekly Cost: 4.0000 USD
  What it does: Cost per pallet per week.
  Example: Storing 10 pallets for 2 weeks adds 10 × 2 × $4 = $80 to the investment buy cost.

Outside Storage

• Cost Measure / Cost UOM / Weekly Cost: (blank)
  What it does: Cost model for offsite/3PL storage. Blank means it won’t be factored.
  Example: If you sometimes overflow to a 3PL at $8 per pallet-week, set Cost Measure=Pallet, UOM=PLT, Weekly Cost=$8. Otherwise, the model understates total holding cost and may over-recommend buys.

Pulling it together: a quick scenario

• Item: Seasonal hoodie, sized.
• Default Size Profile: XS 10%, S 25%, M 35%, L 20%, XL 10%.
• Store delivery schedule: Tue/Thu.
• Today: Monday.
• DC available: 500 units; total store need: 800 units.

What happens:

• Use Location Delivery Schedule: Orders are planned to arrive Tuesday (the next delivery day).
• Order Not After: 0 Days ensures nothing is scheduled in the past.
• Distribution Rule: Proration allocates 500/800 = 62.5% of each store’s need.
• Use Size Profile on Presentation Stock: If Store A’s presentation min is 10, it splits by size curve, e.g., XS=1, S=3, M=4, L=2, XL=1.
• Warehouse Store Assignment Type: All allows this DC to serve all ranged stores.
• Investment Buy Look Ahead: 7 Days sees a weekend promo within 7 days; if finance provides Annual Cost of Money (say 12%) and Warehouse Storage cost ($4/pallet/week), the system calculates whether buying extra now meets Target ROI of 20%. If yes, it recommends an extra buy; if not, it doesn’t.
• Maximum Scaling Iterations: 600 ensures the allocator converges even with pack-size constraints.
• Worksheet PO Cleanup Delay: 7 Days will delete any draft worksheet POs not submitted within a week, keeping things clean.

Shipment

• Allow Shipping / Receiving at Stores: —
  What it is: Manual ship/receive actions directly in store screens.
  Example: If this is disabled but auto-ship/receive is enabled, stores won’t click “Ship” or “Receive” themselves; the system will auto-post those events from integration or scheduled jobs. Useful when handheld/WMS drives confirmations, not store users.

• Allow Auto Shipping / Receiving at Stores: checked
  What it is: System automatically marks store shipments and receipts as shipped/received when matching data arrives (e.g., ASN, handheld, or scheduled auto).
  Example: DC ships a transfer to Store A; when the EDI/ASNs or integration confirms, Store A’s receipt is auto-posted—no manual receiving step. Benefit: reduces store labor and missed receipts.

• Allow Auto Shipping / Receiving at Warehouses: checked
  What it is: Similar automation but for the DC.
  Example: When the DC waves a load and WMS confirms load departure/arrival, RMS auto-updates shipment/receipt status without a user in RMS clicking anything.

• Allow Duplicate Receiving: unchecked
  What it is: Prevents receiving the same shipment twice.
  Example: If Store A accidentally tries to receive a shipment that’s already fully received, the system blocks it. Good for data integrity and preventing overages.

• Receive Pack Component: —
  What it is: Whether receiving can be done at component (inner) level for packs.
  Example: If a “10-pack of socks” is the ship unit, enabling this lets stores receive 10 singles if they break packs. If disabled, they must receive by the full pack. This is blank here, so either not enabled or controlled elsewhere.

• Wrong Store Receipt Exception Handling: checked
  What it is: Creates an exception if a store receives a shipment intended for another location.
  Example: Shipment destined for Store B is mistakenly received by Store C. The system flags an exception so inventory and financial corrections can be made (e.g., reverse, re-transfer).

• Close Open Shipments: 180 Days
  What it is: Auto-closes lingering open shipments after 180 days.
  Example: If a shipment remains “shipped” but never received due to missing confirmations, the system closes it on day 181. Helps clean up old, stuck documents.

Transfers and RTVs

• Department Level Transfer: —
  What it is: Restricts transfers to within departments (often used for financial segregation).
  Example: If enabled, you couldn’t transfer a beauty item with an apparel item on the same transfer. Blank here suggests your system doesn’t enforce department-level partitioning.

• Increase Transfer Quantity After Approval: —
  What it is: Whether you can raise quantities after a transfer is approved.
  Example: If disabled, once a transfer is approved for 100 units, you cannot increase to 120 without re-approval. Blank here likely means not allowed or controlled by role.

• Auto Close Unshipped / Partially Shipped Transfers: checked
  What it is: Closes transfers that were never shipped or only partially shipped after a system-defined window.
  Example: A transfer for 200 units ships only 10 and then stalls. After the window, the system auto-closes the remaining open portion to prevent perpetual open docs.

• Transfer Price to Exceed From Loc WAC: checked
  What it is: Allows transfer out price to be higher than the sending location’s Weighted Average Cost (WAC).
  Example: If From-Store WAC is $9 but transfer price policy is $10 (for intercompany or retail basis), this setting allows it. Useful for margin/IC accounting scenarios.

• Auto Close Transfers to Warehouses: unchecked

• Auto Close Transfers to Stores: unchecked
  What it is: Whether receipts automatically close transfers to those destination types once received.
  Example: Unchecked means operations may require a manual closure/validation or rely on a different auto-close rule. Combined with the earlier “Auto Close Unshipped/Partially Shipped,” you’re prioritizing cleanup of stuck documents while leaving normal flows to close based on receipt and policy.

• Intercompany Transfer Basis: Transfer Entity
  What it is: Sets how intercompany (between legal entities) transfer prices are calculated.
  Example: “Transfer Entity” typically means use the defined intercompany pricing for the entities involved (not WAC or retail). This impacts P&L on each legal entity.

• RTV / RAC Transfer: blank
  What it is: A policy toggle to treat Return-to-Vendor (RTV) or Return-after-Claim (RAC) as transfer documents within your network before vendor return.
  Example: Blank suggests RTVs are handled in their dedicated RTV process, not as standard transfers to a returns DC.

• RTV Unit Cost Source: Average Cost
  What it is: Cost basis used when valuing units in an RTV.
  Example: If Store returns 50 units to Vendor, the financial value uses Average Cost at the returning location, not last receipt or standard cost. Ensures consistent inventory valuation.

• RTV Not After Date Lead Time: 1 Days
  What it is: The system won’t create RTVs with an “effective not after” date earlier than today + 1 day.
  Example: Today is the 10th; earliest acceptable “not after” is the 11th. Prevents outdated RTV documents.

Markdown Location for Retail Difference

What it is: Where to book markdowns if transfer price differs from retail, by route:

• Store to Store: Sending Location
• Store to Warehouse: Sending Location
• Warehouse to Store: Sending Location
• Warehouse to Warehouse: Sending Location

Example: A transfer causes a retail difference (e.g., sending location retail $12, receiving $10). With “Sending Location,” the markdown or retail difference impact is recognized at the sender. This simplifies accounting and prevents double-counting across locations.

Stock Order Auto Close Days

• Store to Store: 2 Days
• Store to Warehouse: 2 Days
• Warehouse to Store: 14 Days
• Warehouse to Warehouse: 14 Days

What it is: How many days after expected receipt the system auto-closes open stock orders if confirmations don’t arrive.
Examples:

• Store→Store: If expected on Monday and not received by Wednesday (+2 days), the order auto-closes. Fast cleanup for store-to-store documents.
• Warehouse→Store: Allows up to 14 days before auto-close, acknowledging DC-to-store deliveries may have longer transit or confirmation cycles.

Transfer Receipt Treatment

• Overages/Shortage for Store to Store: Receiving Location
• Overages for Non Store to Store: Receiving Location
• Shortage for Non Store to Store: Receiving Location

What it is: Which location absorbs inventory discrepancies at receipt.
Examples:

• Store→Store over/short: Receiving store takes the hit. If sending store shipped 100 but receiving store counts 98, the -2 shortage books to the receiver; investigations can follow.
• DC→Store (Non Store to Store) overage: If PO/transfer said 100 and the store counts 103, the receiving store books +3.
• DC→Store shortage: If 97 received, the receiving store books -3.
  Why it matters: Centralizes discrepancy accountability with the receiving site, which typically performs the final physical count.

End-to-end scenarios

Scenario 1: DC ships to Store, auto processes

• Settings in play: Auto Shipping/Receiving at Stores and Warehouses (checked), Close Open Shipments 180 days, Transfer Receipt Treatment to Receiving.
• Flow:
  1. DC ships 120 units to Store A; WMS posts shipment.
  2. Store A receives 118 units (short 2); RMS auto-posts receipt.
  3. Shortage of 2 is posted to Store A (receiving location).
  4. The transfer closes normally; if anything remained open due to missing messages, it would auto-close after 14 days (Warehouse→Store Stock Order Auto Close Days).

Scenario 2: Store-to-Store transfer with discrepancy

• Settings: Auto close un/partially shipped transfers (checked); Over/short for Store→Store to receiving.
• Flow:
  1. Store B sends 50 units to Store C.
  2. Store C receives 52 (overage 2); those +2 book to Store C.
  3. If the shipment never gets confirmed, the document auto-closes after 2 days (Store→Store auto close), preventing backlog.

Scenario 3: Wrong store receipt caught

• Settings: Wrong Store Receipt Exception Handling (checked).
• Flow:
  1. Shipment for Store D is accidentally received by Store E.
  2. System raises an exception. Ops can reverse at E and re-direct to D or create a corrective transfer.

Scenario 4: RTV with Average Cost and date control

• Settings: RTV Unit Cost Source = Average Cost; RTV Not After Date Lead Time = 1 day.
• Flow:
  1. Store F prepares RTV of 40 units to Vendor V.
  2. The RTV document uses Store F’s average cost to value inventory.
  3. “Not After” date cannot be today; must be at least tomorrow to avoid stale paperwork.

Practical recommendations

• Keep auto ship/receive enabled if your WMS/handheld feeds are reliable; it saves labor.
• With discrepancies booked to receivers, equip stores with simple dispute workflows to request sender/DC investigations when variance exceeds a threshold.
• Review the 2-day vs 14-day auto close windows: 2 days is good for store-to-store; ensure it matches your typical delivery lag so you don’t close too aggressively.
• If you often break packs at stores, consider enabling “Receive Pack Component”; otherwise, require pack-level receipts to reduce counting complexity.
• Validate intercompany basis with Finance to ensure transfer pricing aligns with tax and margin requirements.
• Periodically review open shipments and transfers older than 30/60 days—180-day auto-close is a safety net, not an operational target.

Allocation

• Allocation Method: Prorate
  What it means: When there isn’t enough inventory to satisfy all demand, split available units proportionally across locations based on their need.
  Scenario: You have 480 units to distribute but total store need is 800. Prorate gives each store 60% of its need (480/800), so a store needing 200 gets 120; a store needing 80 gets 48.

• Default Order Type: Manual
  What it means: New allocations default to manual orders (created by a user) unless you change it to system-driven.
  Scenario: A planner creates an allocation for a new launch. The order defaults to Manual, so nothing is released until they review and submit.

• Default Up Charges to Allocations: checked
  What it means: Include extra costs (like freight, duties) when creating allocations.
  Scenario: You allocate 300 units, and the system attaches fuel surcharge and import duty so finance sees full landed cost, not just base item cost.

Sales

• History Level: Items Sold Only
  What it means: Use only actual sold items for sales history (ignore returns or other movements).
  Scenario: The system forecasts Store A’s demand from items it actually sold (e.g., 90 units last week), not counting returns-to-stock or internal transfers.

Stock Counts

• Auto Process Stock Counts: For Unit and Value
  What it means: After a count is entered, the system automatically posts unit variances and value impact.
  Scenario: Store counts 985 units but system expected 1,000. The -15 variance posts automatically and updates inventory value.

• Stock Count Lockout Period: 2 Days 
  What it means: Lock counting activity for two days around the scheduled count to avoid movements that confuse results.
  Scenario: A wall-to-wall count is set for Friday. From Thursday to Saturday, transfers/adjustments are restricted so the count is clean.

• Minimum Between Create and Count: 3 Days
  What it means: You must schedule the count at least three days after creating it.
  Scenario: You create a cycle count on Monday; earliest count date you can set is Thursday.

• Minimum Between Count and Variance: 2 Days 
  What it means: You can’t finalize variances until two days after the count (time to investigate).
  Scenario: Count on Tuesday; finalize variances no earlier than Thursday to allow recount checks.

Stock Count Reporting thresholds

• Cost Variance: 2% 
  What it means: If the total cost variance exceeds 2%, flag it for review.
  Scenario: Store’s counted value differs by 2.5% vs system; a report flags it for the inventory team.

• Retail Variance: 999.00% 
  What it means: Very high retail variance threshold to flag exceptions (often set lower in practice).
  Scenario: A large discrepancy crosses this threshold; a report highlights the store.

• Unit Variance: 2 
  What it means: Variance of two or more units is flagged.
  Scenario: Expected 50, found 47; -3 is flagged for follow-up.

Localization

• Default Tax Type: Sales and Use Tax
  What it means: This is the default tax model for transactions.
  Scenario: New items default to Sales and Use tax; pricing and invoicing apply standard sales tax unless overridden.

• Default VAT Region: blank
  What it means: No default VAT region set (common if operating primarily in non-VAT jurisdictions).
  Scenario: For a UK store, you’d configure VAT region explicitly at setup.

• Class Level Tax: unchecked
  What it means: Tax is not determined at class-level by default.
  Scenario: You set tax at item/location rather than by entire class.

• Enable NWP Processing: unchecked
  What it means: “New Way of Paying” or similar local processing is off.
  Scenario: Your environment sticks to standard invoice/payment flows.

Procurement – Deals

• Calculate Deal Negative Income: unchecked
  What it means: Don’t calculate negative income when deal mechanics would imply it (protects from oddities).
  Scenario: A retro allowance shouldn’t produce negative income lines; the system suppresses them.

• Backposted Deals affected by Unit/Cost Adjustments: checked
  What it means: If you fix units or costs later, applicable deals retroactively adjust.
  Scenario: You correct a receipt from 900 to 920 units. The backposted vendor allowance recalculates on 20 additional units.

• Deal Lead Time (to be active): 3 Days 
  What it means: A deal must be set up at least three days before it becomes active.
  Scenario: Today is Monday; the earliest activation is Thursday.

• Cost Level: Dead Net Cost (DNN)
  What it means: Use the fully netted cost after deals/allowances.
  Scenario: Base cost $12, allowance $2 → DNN cost is $10.

• Credit Memo Level: Set of Books B
  What it means: Credit memos post to accounting at the specified ledger/book.
  Scenario: Vendor debit/credit adjustments post to Set of Books B for financial reporting.

• Deal Type of Highest Priority: Promotional
  What it means: Promotional deals take precedence if multiple deals overlap.
  Scenario: If a scan-down and a base allowance collide, the promotional deal rules apply first.

• Deal Age of Highest Priority: Newest
  What it means: Newer deals override older ones when conflict exists.
  Scenario: A new promo published yesterday takes precedence over a last-month evergreen allowance.

Procurement – Purchase Orders

• Auto Close Orders With Partial Receipt: checked
  What it means: If only part is received and nothing else arrives within the window, the PO auto-closes.
  Scenario: PO for 1,000 units gets 980; after the close-delay window, the remaining 20 is closed.

• Reclass Items On Approved POs: checked
  What it means: If item classification changes, approved POs update accordingly.
  Scenario: An item moves from Class A to Class B; approved POs reflect the new class for reporting.

• Department Level PO: unchecked
  What it means: POs aren’t restricted to a single department.
  Scenario: A multi-department PO to a vendor is allowed.

• Override EDI Supplier Cost: checked
  What it means: System can override cost from EDI with your internal cost (if rules allow).
  Scenario: Vendor sent $11.90 via EDI; your approved cost is $11.70; the PO keeps $11.70.

• Copy Exchange Rate From Order: unchecked

• Use Order Exchange Rate From Order: unchecked
  What it means: Exchange rate behavior follows your financial settings instead of copying/locking from the order record.
  Scenario: The system uses the rate as of goods receipt per finance policy (example).

• Outside Customer Default Warehouse: Outside Customer Default Warehouse
  What it means: Default DC that services outside-customer orders.
  Scenario: Marketplace orders route by default to this DC if no other mapping exists.

• Order Approval Based On: Cost
  What it means: Approval thresholds/key checks use cost basis.
  Scenario: A high-cost PO triggers higher-level approval even if unit count is low.

• Approved PO Close Delay: 31 Days 
  What it means: Wait 31 days after approval for auto-close criteria to run if no activity.
  Scenario: A PO sits untouched; it’s auto-closed after 31 days.

• Partially Received PO Close Delay: 2 Days
  What it means: After a partial receipt, close the remaining open qty if nothing else arrives within 2 days.
  Scenario: 100 expected, 95 received. If 5 don’t arrive within 2 days, close the PO line.

• Expiry Date for Pre-Issued Order: 19 Days 
  What it means: Pre-issued POs expire in 19 days if not progressed.
  Scenario: A pre-issued PO from the 1st expires on the 20th without action.

• Latest Shipment: 4 Days 
  What it means: Latest acceptable ship window for an order relative to plan (often a tolerance).
  Scenario: Vendor shipping beyond 4 days late triggers exception workflow.

• Redistribution Factor: 4% 
  What it means: Limit or factor used when redistributing supply across locations.
  Scenario: DC can reallocate up to 4% of available stock from low-need stores to high-need stores during balancing.

• Generate Item/Supplier for Xorder: checked
  What it means: Auto-create item/supplier relationships when cross-orders are made.
  Scenario: During urgent buys, the system creates item-vendor link if missing so the order can proceed.

Procurement – Cost Adjustments

• WAC Recalculated During Adjustments: checked
  What it means: When costs are adjusted, weighted average cost updates accordingly.
  Scenario: You correct an invoice price; the item’s WAC recalculates to reflect the new cost.

• Receiver Cost Adjustment: FIFO
  What it means: Cost adjustments apply to the earliest receipts first.
  Scenario: You have three batches received. A cost correction hits the oldest batch first.

Procurement – Contracts

• Soft Contracts: unchecked
  What it means: Contracts are firm; the system doesn’t treat them as soft placeholders.
  Scenario: Orders must adhere to contract terms without flexible enforcement.

• Generate Order Prior To Ready Date: 6 Days
  What it means: The system can create orders up to 6 days before goods are ready.
  Scenario: Vendor promises ready date on the 20th; the system can create the PO on the 14th to secure capacity.

Consignment Orders and Invoices

• Level: Supplier/Department/Location
  What it means: Consignment is tracked at this combination level.
  Scenario: For supplier S, department D, at Store L, inventory stays supplier-owned until sold, then converts.

• Frequency: Weekly
  What it means: Consignment settlement frequency.
  Scenario: Every week, the system invoices the supplier for units sold from consignment stock.

Data Retention – History

• Item Sales: 23 Months
  Keep item sales history for 23 months.
  Scenario: Forecasting routines can look back nearly two years.

• Daily Sales Discount: 2 Months 
  Keep daily discount details for 2 months.

• Future Cost: 99 Days 
  Keep future cost records 99 days ahead.

• Pricing: 701 Days 
  Keep price history for ~701 days.

• Competitive Shop Lists: 1 Month 
  Keep competitor shop lists for 1 month.

• Competitive Pricing: 1 Month 
  Keep competitor price data for 1 month.

• Foundation Staging: 29 Days 
  Keep staging data for 29 days.

• NWPs: blank Years
  No explicit retention set for NWP; follows default/archive rules.

• Inactive Contracts: 2 Months 
  Keep inactive contracts for 2 months.

• Closed Deals: 3 Months 
  Keep closed deal records for 3 months.

• Rejected Cost Changes: 6 Days 
  Keep rejected cost changes for 6 days.

• Completed Orders: 9 Months 
  Keep completed PO documents for 9 months.

• Non-Stockholding Outside Customer Sales: 2 Days 
  Keep these records for 2 days.

Data Retention – EDI Transactions

• EDI Revisions: 79 Days 
  Keep EDI revision logs for 79 days.

• EDI 852 Report Transmissions: 2 Days 
  Keep EDI 852 transmissions for 2 days.

Replenishment – Retention

• Attribute History: 9 Weeks 
  Keep attribute-based history (e.g., color/size) for 9 weeks.

• Worksheet Orders: 8 Days 
  Keep replen worksheet orders for 8 days.

• Investment Buy Results: 13 Days 
  Keep investment buy result snapshots for 13 days.

• Results: 31 Days 
  Keep general replen results for 31 days.

• Store Orders: 13 Days 
  Keep store order documents for 13 days.

• Scheduled Updates: 59 Days 
  Keep scheduled update info for 59 days.

• Store Ship Schedules: 4 Months 
  Keep store ship schedules for 4 months.

• Activity Schedules: 12 Months 
  Keep activity calendars for 12 months.

Inventory – Retention

• Transaction Data: 
  Keep inventory transaction logs for 119 days.

• Transfers: 4 Months
  Keep transfer documents for 4 months.

• MRT Transfers: 89 Days
  Keep multi-recipient transfer records 89 days.

• RTV Orders: 4 Months
  Keep RTV documents 4 months.

• Inventory Adjustments: 12 Months
  Keep adjustment records 12 months.

• Customer Orders: 1 Month 
  Keep customer order headers for 1 month.

• Outside Customer Order and Returns: 4 Months 
  Keep outside customer order/return documents 4 months.

RTM

• Simplified RTM: unchecked
  What it means: Full route-to-market complexity is enabled.
  Scenario: You use detailed RTM flows (channels, partners) rather than a simplified mode.

Allocate Shipment Level Allocations Using

• ASN
  What it means: Use Advance Ship Notice data to allocate at shipment level.
  Scenario: DC sends ASN with exact cases and lots; system uses that to allocate more precisely across stores.

Letter of Credit

• Type: Master
  What it means: Use Master LC type for import POs.
  Scenario: Multiple POs can draw against one master LC.

• Form Type: Long
  What it means: Use long-form LC documents.
  Scenario: Complex imports that need extended clauses use the long form.

• Title Pass Location: Canadian SPLC – Origin
  What it means: Title passes at origin per Canadian SPLC rules.
  Scenario: Risk transfers when goods leave the vendor’s dock; affects insurance and accounting.

• Expiration Days: 31 Days 
  What it means: LC expires 31 days after issue unless renewed.
  Scenario: If goods haven’t shipped before expiry, you must amend the LC.

HTS (Harmonized Tariff Schedule)

• Tracking Level: Country Of Manufacture
  What it means: Track HTS compliance per country of origin.
  Scenario: Same SKU from VN vs CN gets different duty rates.

• Update Items When Loading Data: checked

• Update Order/Items When Loading Data: checked
  What it means: When you load HTS data, automatically update item and order records.
  Scenario: New duty rate loads and the system applies it to pending import POs.

• Effective on Purchase Order: Not After Date
  What it means: HTS effectiveness is tied to PO’s not-after date.
  Scenario: If not-after is next month, that’s the effective date for duty rules.

• Required for Import Orders: checked
  What it means: Import POs require HTS data before approval.
  Scenario: You can’t approve an import PO until HTS classification is present.

Security – LOV Filtering

• Data Level Filtering Enabled: unchecked
  What it means: Lists of values are not filtered by data-level security in pickers.
  Scenario: Users might see broader LOVs; access is still controlled at transaction level.

Merchandise Hierarchy defaults

• Diff Group: Primary Dept
• Season: Primary Dept
• Ticket Type: Primary Dept
• UDA: Primary Dept
  What it means: Default drivers for attributes come from the Primary Department.
  Scenario: New items inherit diff groups and seasons from their primary department setup.

Organizational Hierarchy defaults

• Diff Group: Op Group
• Season: Op Group
• Ticket Type: Op Group
• UDA: Op Group
• Item List: Op Group
• Location List: Op Group
• Location Traits: Op Group
  What it means: Organizational defaults derive from the operating group.
  Scenario: Reports and LOVs default to the user’s operational group for these classifications.

Quick beginner scenarios tying it together

1. Short supply allocation

• You have 960 units arriving for a product; store needs total 1,600.
• Allocation Method Prorate splits 60% of each store’s need.
• Default Order Type Manual means planner reviews before release.
• Default Up Charges to Allocations attaches freight/duty so costs are complete.

2. Stock count and variance handling

• You create a cycle count today; soonest count date is 3 days from now.
• The store counts and shows a -4 unit variance (threshold is 2), and a cost variance of 2.3% (threshold 2%).
• Both are flagged; auto processing posts the adjustments. Lockout window prevents extra movements during the count.

3. PO lifecycle

• A vendor ships partially; you receive 480 of 500.
• After 2 days with no more receipts, the remaining 20 auto-closes.
• If the PO sat idle after approval for 31 days, it would also auto-close.

4. Deals and WAC

• A backposted allowance comes in; you correct a receipt quantity upward.
• Backposted Deals affected by Unit/Cost Adjustments updates the deal income.
• WAC recalculates; Receiver Cost Adjustment uses FIFO, so oldest receipt layers adjust first.

5. Imports and HTS

• An import PO is blocked because HTS is missing; Required for Import Orders enforces compliance.
• You load HTS updates; items and orders update automatically.
• LC is Master/Long with 31-day expiry and title passing at origin; finance and logistics plan accordingly.