> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cedarai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Stale Inventory Cleanup

> Automated cleanup system for ghost railcar records

## What This System Does

When railcars arrive at your facility, they're marked as "INBOUND" in the system. Sometimes these inbound records are created but the physical railcar never actually arrives - maybe the shipment was cancelled, rerouted, or there was a data entry error.

<Warning>
  Without cleanup, these "ghost" railcars would stay in your system forever, cluttering reports and making it harder to see your actual inventory.
</Warning>

This automated cleanup system identifies and removes these ghost records based on how long they've been inactive.

***

## How We Determine What's "Stale"

A piece of equipment is considered **stale** when it has been sitting in an INBOUND state with no recent activity. Activity includes:

<CardGroup cols={2}>
  <Card title="Waybill Updates" icon="file-invoice">
    When billing paperwork is updated
  </Card>

  <Card title="Consist Assignments" icon="train">
    When the equipment is added to a train or consist
  </Card>
</CardGroup>

<Info>
  If a railcar hasn't had either of these activities for a certain number of days, it's probably not actually at your facility.
</Info>

## Configurable Settings

<Note>
  These settings can be adjusted in **Settings > Profile > Rail** to control how the cleanup works.
</Note>

### System Control

<AccordionGroup>
  <Accordion title="Enable/Disable Cleanup" icon="toggle-on" defaultOpen>
    **Setting name:** `Enable Stale Inventory Cleanup`

    **What it controls:** Turns the entire stale inventory cleanup system on or off.

    <Warning>
      When disabled, stale equipment will remain in the system indefinitely. This may clutter your inventory reports.
    </Warning>

    **Options:**

    * ✅ **Enabled** - System runs on schedule
    * 🛑 **Disabled** - System is paused
  </Accordion>
</AccordionGroup>

### Default Settings

<Info>
  These defaults apply to all carriers unless you set up carrier-specific overrides below.
</Info>

<AccordionGroup>
  <Accordion title="Default Stale Threshold (in days)" icon="calendar">
    **Setting name:** `default_stale_days`

    **What it controls:** How many days of inactivity before equipment is considered stale.

    <Tip>
      If set to 30 days, any equipment that hasn't been updated or added to a train in the last 30 days will be flagged for deletion.
    </Tip>

    **Business consideration:**

    * ⬆️ **Higher number** = More conservative, fewer deletions, but more clutter
    * ⬇️ **Lower number** = More aggressive cleanup, but risk of deleting legitimate equipment
  </Accordion>

  <Accordion title="Default Daily Deletion Limit" icon="gauge-max">
    **Setting name:** `default_daily_velocity`

    **What it controls:** The maximum number of stale equipment that can be automatically deleted per carrier in a single day.

    <Tip>
      If set to 50, and 200 pieces of equipment are flagged as stale for Union Pacific, only 50 will be deleted today. The remaining 150 will trigger alerts for manual review.
    </Tip>

    <Warning>
      This is a **safety mechanism**. If there's a system error or data issue that incorrectly flags many items as stale, this limit prevents mass deletion disasters.
    </Warning>

    **Business consideration:**

    * ⬆️ **Higher number** = Faster cleanup, but higher risk if something goes wrong
    * ⬇️ **Lower number** = Safer, but cleanup takes longer for large volumes
  </Accordion>
</AccordionGroup>

### Carrier-Specific Overrides

<Info>
  Override default settings for individual carriers. Only configure carriers that need different settings.
</Info>

<AccordionGroup>
  <Accordion title="How to Set Up Carrier Overrides" icon="building">
    **Setting name:** `Stale Inventory Cleanup Overrides`

    **What it controls:** Custom settings for your carrier that override the defaults.

    **How it works:** When you configure these settings, they apply to your current carrier (identified by your carrier code). Each carrier can have their own custom thresholds and limits that override the system defaults.

    **You can optionally set:**

    * Custom stale threshold (in days) - overrides `default_stale_days`
    * Custom daily deletion limit - overrides `default_daily_velocity`

    **Why this exists:** Different carriers have different operating patterns:

    * 🚂 **Short-line railroads** might need longer grace periods (45+ days)
    * 🏭 **High-volume Class II carriers** might want faster cleanup (15 days)
    * 🔒 **Carriers with complex operations** might need lower velocity limits for safety

    <Tip>
      If you don't set carrier-specific overrides, the default settings will be used for your carrier.
    </Tip>
  </Accordion>
</AccordionGroup>

## Safety Mechanisms

<Info>
  The system has multiple safeguards to prevent accidental data loss.
</Info>

<AccordionGroup>
  <Accordion title="Daily Velocity Limits" icon="gauge">
    Only a limited number of deletions happen per day, per carrier.

    Any deletions beyond this threshold are:

    * ✋ **Not performed** - equipment stays in system
    * 📝 **Logged** - warnings written to system logs
    * 📊 **Tracked** - metrics recorded for investigation
  </Accordion>

  <Accordion title="Transload Protection" icon="shield-halved">
    Equipment in **active transload operations** will **NEVER** be deleted, regardless of age.

    <Tip>
      **What's a transload?** Transferring cargo from one railcar to another (or to a truck). These operations can take time, so equipment must remain in the system even if it looks inactive.
    </Tip>
  </Accordion>

  <Accordion title="State Protection" icon="lock">
    Only **INBOUND** equipment is eligible for cleanup.

    **Protected states:**

    * 🚂 OUTBOUND - leaving your facility
    * 🟢 ONLINE - in active use
    * 🗑️ Already deleted
  </Accordion>
</AccordionGroup>

## What Actually Gets Deleted

<Warning>
  For a piece of equipment to be deleted, **ALL** of these conditions must be true:
</Warning>

<Steps>
  <Step title="Status is INBOUND">
    Equipment must be in an inbound state
  </Step>

  <Step title="No Recent Activity">
    No activity (waybill updates or consist assignments) for longer than the stale threshold
  </Step>

  <Step title="Not Deleted">
    Equipment is not already marked as deleted
  </Step>

  <Step title="No Active Transload">
    Not part of an active transload operation
  </Step>

  <Step title="Within Velocity Limit">
    Carrier hasn't exceeded its daily deletion limit
  </Step>
</Steps>

<Info>
  If any of these conditions is false, the equipment stays in the system.
</Info>

## Monitoring & Alerts

The system tracks key metrics for monitoring:

<CardGroup cols={2}>
  <Card title="Deletions" icon="trash-can">
    Tracks how many items were successfully deleted per carrier per run.
  </Card>

  <Card title="Over-Velocity Items" icon="triangle-exclamation">
    Tracks how many items were flagged as stale but NOT deleted because they exceeded the daily velocity limit.
  </Card>
</CardGroup>

<Warning>
  **If you see high over-velocity numbers:** This could indicate:

  * 📋 A legitimate backlog that needs attention
  * ⚠️ A data quality issue causing false positives
  * 🔧 System problems incorrectly flagging equipment
</Warning>

## Example Scenario

<Tabs>
  <Tab title="Scenario">
    **Settings:**

    * 📅 Default stale threshold: 30 days
    * 🎯 Default daily velocity: 50 deletions

    **Situation:**
    Union Pacific has 200 railcars that haven't been updated in 35 days.
  </Tab>

  <Tab title="What Happens">
    <Steps>
      <Step title="Flagged as Stale">
        All 200 are flagged as stale (35 days > 30 day threshold)
      </Step>

      <Step title="Velocity Limit Applied">
        Only 50 are actually deleted (velocity limit)
      </Step>

      <Step title="Remaining Stay">
        The remaining 150 stay in the system
      </Step>

      <Step title="Warning Logged">
        A warning is logged about the 150 over-velocity items
      </Step>

      <Step title="Metrics Recorded">
        System metrics are recorded:

        * ✅ deletions = 50
        * ⚠️ overVelocity = 150
      </Step>
    </Steps>
  </Tab>

  <Tab title="Next Steps">
    <Warning>
      Operations team should investigate why 150+ railcars are stale.
    </Warning>

    **Possible causes:**

    * 📊 Data quality issue?
    * 🔧 Process problem?
    * 📦 Real backlog?
  </Tab>
</Tabs>

## Recommendations for Configuration

<Tabs>
  <Tab title="Conservative (Safer)" icon="shield-check">
    **Configuration:**

    ```yaml theme={null}
    default_stale_days: 45
    default_daily_velocity: 25
    ```

    **Best for:**

    * Getting started with the system
    * Organizations with less confidence in data quality
    * Risk-averse environments

    **Pros:**

    * ✅ Minimizes risk of accidental deletions
    * ✅ More time to catch data entry errors

    **Cons:**

    * ⚠️ Slower cleanup of stale records
    * ⚠️ More clutter in reports
  </Tab>

  <Tab title="Balanced (Recommended)" icon="scale-balanced">
    **Configuration:**

    ```yaml theme={null}
    default_stale_days: 30
    default_daily_velocity: 50
    ```

    ⭐ **This is our recommended starting point**

    **Best for:**

    * Most operations
    * Organizations with good data quality
    * Standard processing times

    **Pros:**

    * ✅ Good balance of safety and efficiency
    * ✅ Reasonable cleanup speed
    * ✅ Adequate protection against errors
  </Tab>

  <Tab title="Aggressive (Advanced)" icon="gauge-high">
    **Configuration:**

    ```yaml theme={null}
    default_stale_days: 15
    default_daily_velocity: 150
    ```

    ⚠️ **Advanced users only**

    **Best for:**

    * High-volume operations
    * Organizations with excellent data quality
    * Fast processing environments

    **Pros:**

    * ⚡ Fast cleanup of stale records
    * ⚡ Minimal clutter

    **Cons:**

    * ⚠️ Higher risk if data issues occur
    * ⚠️ Requires close monitoring initially
    * ⚠️ Less time to catch mistakes
  </Tab>
</Tabs>

## Questions to Consider When Configuring

<AccordionGroup>
  <Accordion title="How quickly do your inbound shipments typically get processed?" icon="clock">
    * ⚡ **Fast (1-5 days)** → Lower stale\_days acceptable
    * 🐌 **Slow (2-4 weeks)** → Higher stale\_days needed
  </Accordion>

  <Accordion title="How accurate is your inbound data entry?" icon="bullseye">
    * ✅ **Very accurate** → Can use higher velocity
    * ⚠️ **Occasional errors** → Keep velocity conservative
  </Accordion>

  <Accordion title="What's your tolerance for clutter vs. risk of deletion?" icon="scale-balanced">
    * 🧹 **Prefer clean reports** → Lower stale\_days, higher velocity
    * 🛡️ **Very risk-averse** → Higher stale\_days, lower velocity
  </Accordion>

  <Accordion title="Do different carriers have different processing patterns?" icon="building">
    * ✅ **Yes** → Set up carrier-specific overrides
    * ❌ **No** → Use defaults for everyone
  </Accordion>
</AccordionGroup>

## Getting Help

<Note>
  If you notice unexpected behavior, follow these steps:
</Note>

<Steps>
  <Step title="Check Metrics">
    Review system metrics for unusual patterns
  </Step>

  <Step title="Review Logs">
    Check system logs for warnings about over-velocity
  </Step>

  <Step title="Verify Settings">
    Confirm your configuration values in **Settings > Profile > Rail**
  </Step>

  <Step title="Contact Support">
    Reach out to the development team with specific carrier codes and date ranges
  </Step>
</Steps>

***

<Tip>
  **Quick Summary:** The Stale Inventory Cleanup system automatically removes "ghost" railcar records that have been inactive for too long, with built-in safety mechanisms to prevent accidental data loss. Configure it in **Settings > Profile > Rail** based on your operation's needs.
</Tip>