STOCK & INVENTORY — DUAL-LOGIC MATERIAL VISIBILITY

Two parallel systems answering two different questions: “What do we have right now?” and “What will we have in the future?” — the live inventory and the dynamic projection forecast, running side by side as a built-in double-check mechanism.

February 2026 • Solen Kablo • Living Document

1. WHAT STOCK & INVENTORY DOES

The Stock & Inventory module answers the two most fundamental questions in any manufacturing operation:

1. “What do we have right now?” — Answered by Ürün Stok (finished/semi-finished goods) and Hammadde Stok (raw materials). These pages show the live, physical state of the factory’s inventory at t=0. Every basket of drawn copper wire (X-coded), every reel of tinned wire (Y-coded), every kilogram of raw plastic — all visible with real-time weights, statuses, allocations, and full production traceability.
2. “What will we have in the future?” — Answered by Projeksiyon (Stock Projection). This page shows a week-by-week forecast across 8 material categories (copper, tin, plastic, catalyst, dye, antirodent, reels, palettes), calculating how much material will be consumed by planned work cards (MINUS) versus how much is arriving through purchase orders (PLUS), producing a running cumulative balance that reveals shortages weeks before they become critical.

These two systems run on fundamentally different data sources:

2. THE DATA FLOW

2.1 Projeksiyon Data Flow

Projeksiyon computes its weekly forecast from two independent data sources, combined in the ProjeksiyonService (804 lines):

MINUS Side: Work Card Material Requirements

Each work card carries a material_details JSON that specifies exactly what raw materials it will consume. The service maps machine types to material categories:

All work cards except CANCELLED are included — even completed ones, because Projeksiyon tracks the full plan history. On the incoming side, when an order is delivered, the service switches from expected_date/quantity to delivered_date/delivered_quantity, so the projection dynamically reflects actual delivery timing and amounts.

PLUS Side: Material Order Incoming

Each material order has a material_type, quantity, and expected_date. For delivered orders, the system uses delivered_date and delivered_quantity instead. Material names are resolved from the supplier’s material catalog when available. All orders except CANCELLED are included.

Cumulative Calculation

The service generates all weeks from the earliest data point (which may be in a previous year) through the last visible week. It calculates weekly = plus - minus and maintains a running cumulative for each of the 8 material categories. For the user’s view window (default 10 weeks), it also tracks sub-material cumulatives (e.g., individual plastic types like “HFX 500P” within the Plastic category) for hidden shortage detection.

2.2 Live Inventory Data Flow

The live inventory pages read directly from physical inventory tables:

Ürün Stok fetches 7 parallel API calls (one per production step: Kabatel, Kalaylama, İncetel, Buncher, Extruder, E-Beam, Aktarma), while Hammadde Stok fetches all materials in a single call and groups them client-side into 8 categories.

3. THE DATABASE LAYER

The Stock module relies on two primary tables for live inventory, plus two external tables (from other modules) that feed the Projeksiyon calculation.

3.1 half_product_stock (20 columns) — Semi-Finished & Finished Products

Every basket, reel, or coil produced by any machine is recorded here. Each entry has a deterministic QR code (X1 for Kabatel, Y1 for Kalaylama, Z1 for İncetel, T1 for Buncher, U1 for Extruder, G1 for E-Beam).

Composite indexes: (production_step, status) for step-based filtering, (product_code, status) for product-based grouping. 4 foreign keys link to orders, production outputs, sessions, and work cards.

3.2 materials (from Hammadde module)

The raw material inventory table (documented in the Hammadde module). Hammadde Stok reads this table directly via GET /api/materials/list. Each row represents a physical lot of raw material with QR code, weight, supplier, lot number, and status. 8 material types: raw_copper, raw_tin, raw_plastic, raw_catalyst, raw_dye, raw_antirodent, raw_palette, raw_reel.

3.3 External Tables Feeding Projeksiyon

4. THE BACKEND ARCHITECTURE

4.1 Route Files

4.2 The Projeksiyon Service (804 lines)

The computational heart of the module. ProjeksiyonService orchestrates the entire projection calculation:

4.3 API Contract — Projeksiyon Endpoints (4)

4.4 API Contract — Half Product Endpoints (6)

5. THE FRONTEND

5.1 Page Structure

Total frontend: 4,865 lines across 3 pages. Projeksiyon alone accounts for 68% of the code.

5.2 Shared Patterns

• No WebSocket: All three pages use REST API polling or one-time fetches. No real-time subscriptions.
• Turkish locale: All pages wrap in ConfigProvider locale={trTR} with dayjs timezone conversion to Europe/Istanbul.
• No ProTable: Unlike other modules, the stock pages use plain Ant Design Table components (except HammaddeSiparis which is in the Hammadde module).
• Client-side grouping: Both Ürün Stok and Hammadde Stok fetch data and group it client-side (by product_code and material_name respectively).

5.3 Projeksiyon — Frontend Highlights

At 3,323 lines, Projeksiyon is one of the largest React components in the ERP. It has two tabs:

Tab 1 — Table View: A dynamic table with week rows and 8 material columns. Each material column shows incoming (green ↑), consumption (red ↓), and cumulative balance (color-coded Tag). Columns are expandable: clicking a material header reveals individual sub-material columns (e.g., “Filmaşin” under Copper, “HFX 500P” under Plastic). Non-expanded materials collapse to 20px color bars with traffic-light indicators. Week navigation shifts the 10-week window via offset parameter. A summary row shows final cumulatives.

Tab 2 — Charts View: Three interchangeable chart types powered by ReactECharts:

1. Line Chart: Smooth cumulative lines with area fill. Overview mode (all materials) or detail mode (1–3 selected materials showing sub-material stacked bars + cumulative overlay).
2. Heatmap: Weeks (x) vs materials/sub-materials (y), colored red-to-green with per-material normalization. Custom HTML axis tooltips show shortage start/increase info.
3. Radar Chart: Merged mode (4 weeks overlapping) or individual mode (paginated spiders). Normalized 0–100 scale with 50 = zero line. Rich text labels colored by sign.

Hidden Shortage Detection: The most sophisticated feature. If the aggregate Copper cumulative is positive but the sub-material “Filmaşin 8mm” is negative, the cell gets a red border on a green background with a warning tooltip. This appears across all three chart types.

5.4 Ürün Stok — Frontend Highlights

7 Collapse panels (Kabatel, Kalaylama, İncetel, Buncher, Extruder, E-Beam, Aktarma), each with a color-coded icon and 3 header stats (Total kg, Sipariş kg, Serbest kg). Items grouped by product_code at level 2, individual QR-coded items at level 3. Features: edit modal (weight, allocation, notes), delete with confirmation, and a bonded test viewer that fetches test results from the Lab module for any item with a production_output_id.

5.5 Hammadde Stok — Frontend Highlights

8 Collapse panels (Bakır, Kalay, Plastik, Katalizör, Boya, Antirodent, Palet, Makara). Structurally mirrors Ürün Stok but for raw materials. Units adapt: kg for most materials, “adet” for palettes and reels. Conditional weight coloring: remaining weight shown in red below 20% of original, yellow below 95% of original. Single API call fetches all materials; client-side grouping by material_type.

5.6 Permission System

All three pages share the canStok route guard from access.ts. Button-level permissions are defined in the manifest but not currently enforced in the page components — the route-level guard is the active access control.

6. THE SUBMODULES

The Stock module has three submodules, ordered by complexity:

6.1 — Projeksiyon (Stock Projection)

6.1.1 — Purpose and Business Context

Projeksiyon answers the most forward-looking question in the factory: “Week by week, will we have enough of each raw material, or will we run short?” It is a read-only, computed view that blends two data streams — material consumption from production plans (work cards) and material arrivals from purchase orders — into a single, navigable weekly forecast spanning up to 5 years in either direction.

This is not a dashboard with pre-calculated snapshots. Every time the page loads, the backend queries ALL non-cancelled work cards and ALL non-cancelled material orders, computes a running cumulative balance across every week since the earliest data point, and returns the result for the user’s 10-week view window. The projection is always fresh — no caching, no stored state, no stale data.

The page serves two audiences: the purchasing team (who need to know when to order more material) and the production planners (who need to know if upcoming work cards will cause a shortage). At 3,323 lines of frontend code and 804 lines of backend service, it is one of the largest and most complex components in the Stock module.

6.1.2 — The Two Data Streams

Every piece of data in Projeksiyon comes from one of two sources:

6.1.3 — The Cumulative Calculation Engine

The core of Projeksiyon lives in ProjeksiyonService.get_projeksiyon(). The calculation is not a simple “show this week’s plus and minus” — it is a full historical running total:

1. Find earliest data: get_earliest_data_week_offset() scans both work cards (MIN(sevkiyat_week)) and material orders (MIN(expected_date), MIN(delivered_date)) to find the very first week that has any data. This might be in a previous year (e.g., 2025 orders still affect 2026 projection).
2. Generate ALL weeks: From the earliest data week through the last week in the user’s view (e.g., if earliest data is 2025-W40 and the user is viewing 2026-W05 to W14, the system generates weeks from W40 through W14 — 27 weeks of computation for a 10-week view).
3. Fetch requirements and incoming for ALL weeks: Two bulk queries: one for work cards grouped by sevkiyat_week, one for material orders mapped to their respective weeks.
4. Walk through every week in order: For each week, compute weekly = plus - minus per material category, and add it to the running cumulative total. Also track sub-material cumulatives (e.g., “Filmaşin 8mm” within Copper).
5. Capture pre-view state: Before processing the first week in the user’s view window, snapshot the current cumulative state into pre_view_sub_material_cumulatives. This is critical for the frontend’s hidden shortage detection.
6. Return only view weeks: Of all the weeks processed, only the 10 weeks the user is actually viewing are included in the response. But their cumulative values include ALL historical data.

6.1.4 — Detail Consolidation

Both get_requirements_by_week() and get_incoming_by_week() produce not only aggregate totals per category but also detailed breakdowns by specific material name. For example, an Extruder work card might consume 200 kg of “HFX 500P” and 150 kg of “HFFR 302” — both are “plastic” but tracked individually.

After processing all cards/orders, the service consolidates duplicate names within each week. If two Extruder cards in the same week both consume “HFX 500P”, their quantities are merged into a single detail entry. This consolidation runs across all 8 detail arrays (copper_details, tin_details, plastic_details, catalyst_details, dye_details, antirodent_details, makara_details, palette_details).

6.1.5 — API Endpoints

6.1.6 — Frontend Architecture (3,323 Lines)

The Projeksiyon page is a single React component with two tabs: Projeksiyon (table view) and Grafikler (charts view). Both tabs consume the same API response.

State Management

6.1.7 — Tab 1: The Projection Table

The table is the primary interface. It displays 10 weeks as rows and 8 material categories as columns. The table is NOT an Ant Design ProTable — it is a plain Table with heavily customized column rendering.

Column Structure

Each material column renders three pieces of information per cell:

• Incoming (PLUS): Green upward arrow with the amount of material arriving that week
• Consumption (MINUS): Red downward arrow with the amount of material being consumed
• Cumulative: A color-coded Tag showing the running total. Green if positive (surplus), red if negative (shortage), grey if zero.

Expandable Sub-Material Columns

This is one of the most distinctive features. Each material column header has a small expand arrow. Clicking it reveals individual sub-material columns nested under the parent. For example, expanding “Plastik” might reveal columns for “HFX 500P”, “HFFR 302”, and “XLPE” — each showing their own plus/minus/cumulative within that week.

Sub-material names are discovered from the API response’s detail arrays and persisted in knownSubMaterials so they survive week navigation. When a column is NOT expanded, it collapses to a 20px-wide color bar with a traffic-light indicator (green dot = all positive, red dot = any negative cumulative, yellow dot = mixed). This compact view lets users see all 8 materials at once without horizontal scrolling.

Week Navigation

Left/right arrows shift the 10-week window by 10 weeks at a time (via weekOffset state). A calendar icon resets to the current week (offset = 0). The API enforces limits of −260 to +260 (5 years each direction). Each navigation triggers a new API call; the backend recalculates from scratch.

Summary Row

The last row of the table shows the final cumulative for each material across the entire view window. It serves as the “bottom line” — after all incoming and consumption for these 10 weeks, this is where each material stands.

6.1.8 — Hidden Shortage Detection

This is the most sophisticated feature in the entire Stock module. The problem it solves:

How it works:

1. The backend tracks sub_material_cumulatives as a dictionary keyed by category_materialName (e.g., plastic_HFX 500P). This is updated for EVERY week (not just the view window).
2. Each week in the response carries its own sub_material_cumulatives snapshot.
3. The frontend checks: if the parent category cumulative is ≥ 0 but ANY sub-material within that category has a negative cumulative, this is a hidden shortage.
4. Visual indicator: the cell gets a red border on a green background with a warning tooltip listing which specific sub-materials are in deficit.

This detection works across all three visualization modes (table, line chart, heatmap, radar). In the radar chart, hidden shortages are indicated by a special rich-text label style that combines green text with a red indicator.

6.1.9 — Tab 2: Charts View

The charts tab provides three interchangeable visualization types, all powered by ReactECharts (echarts-for-react). All share the same data from projeksiyonData and respond to the same week navigation and material filter controls.

Material Filter Pills

A row of clickable pills at the top allows filtering by material. Three modes:

• Tümü (All): No filter selected. Charts show aggregate cumulative lines for all materials. No sub-material breakdown.
• 1–3 materials selected (Detail Mode): Charts switch to showing sub-material stacked bars for consumption and incoming, with cumulative overlay lines per sub-material. This is where the hidden shortage detection becomes most visible.
• 4+ materials: Not allowed. The UI enforces a maximum of 3 selections by deselecting the oldest when a 4th is clicked. This prevents chart overcrowding.

Chart Type 1: Line Chart

Smooth cumulative lines with gradient area fill. In overview mode, each material gets its own line (copper=orange, tin=cyan, plastic=purple, etc.). A dashed red zero-line marks the shortage threshold. In detail mode, sub-materials get stacked bar charts for consumption (negative, red) and incoming (positive, green), with individual cumulative overlay lines.

The tooltip is extensively customized: it shows the week label, date range, sections for “KÜMÜLATİF” (cumulative), “KULLANILAN (Bu Hafta)” (consumption), “İHTİYAÇ (Eksik)” (shortages), and “GELEN (Bu Hafta)” (incoming). Shortages use a 2-column grid layout when there are more than 6 items.

Chart Type 2: Heatmap

A grid with weeks on the x-axis and materials/sub-materials on the y-axis. Each cell is colored on a red-to-green gradient based on cumulative value. The coloring uses per-material normalization — each material row is normalized independently so a +5000 kg copper surplus and a +50 adet palette surplus both appear equally green.

Custom HTML axis tooltips appear on hover over material labels. These tooltips show detailed shortage information: which weeks this material first goes negative, whether the shortage is increasing or decreasing, and which specific sub-materials are affected. Shortage information is pre-calculated and stored in heatmapShortageInfoRef for efficient event handling.

Chart Type 3: Radar Chart

Operates in two modes:

• Merged mode: Last 4 weeks overlapping on a single radar. Each week gets a different color (grey, amber, purple, cyan). Materials are positioned around the perimeter with rich-text labels showing the material name and cumulative value, colored green/red by sign. A dashed circle at the 50 mark represents the zero line (scale is normalized 0–100).
• Individual mode: Paginated display showing 4 weeks per page as separate spider diagrams side by side. Each has its own radar with the week label below. Left/right arrows paginate through weeks.

In both modes, hidden shortages are visualized using a special label format: the material name appears with an amber/warning color and the value shows green with a red warning indicator.

6.1.10 — Dashboard Statistics Cards

Above the charts, 4 statistic cards provide a quick summary:

• Toplam Gelen (Total Incoming): Sum of all PLUS across all materials and weeks
• Toplam İhtiyaç (Total Consumption): Sum of all MINUS across all materials and weeks
• Net Bakiye (Net Balance): Total incoming minus total consumption. Green if positive, red if negative.
• Stok Sağlığı (Health Score): A percentage calculated as (totalPlus / totalMinus) × 50, capped at 0–100. Rendered as a Progress bar. Below 50% = red, 50–80% = yellow, above 80% = green.

6.1.11 — Extruder Material Extraction Logic

The most complex material mapping is for Extruder work cards. A single Extruder card can consume multiple materials simultaneously because cable extrusion involves layered coatings:

1. Insulation materials (insulation_materials[]): Each entry has material_name (plastic type), plastic_kg, catalyst_name, catalyst_kg, and dyes[] array with dye_name and dye_kg.
2. Sheath materials (sheath_materials[]): Same structure as insulation but also includes antirodent_name and antirodent_kg (only the outer sheath can have rodent repellent).

The service walks through both arrays, extracting individual material names and quantities. This means a single Extruder work card can produce detail entries for 3–4 different plastics, 2 catalysts, 2 dyes, and 1 antirodent — all mapped to their respective category detail arrays and consolidated if the same material name appears in multiple cards for the same week.

6.1.12 — Week Key System

All temporal data in Projeksiyon uses ISO week keys in the format YYYY-WNN (e.g., “2026-W12”). The service provides utility functions:

• get_week_key(date): Converts a Python date to its ISO week key
• week_key_to_offset(week_key): Converts a week key to an integer offset from H01 of the current year. Used to compare weeks across year boundaries (e.g., 2025-W52 = offset −1 from 2026-W01).
• generate_weeks(num_weeks, offset): Produces week metadata including week_key, week_label (H01–H52), date range in Turkish (e.g., “06-12 Oca”), and ISO start/end dates.

The week labels displayed in the UI use HNN format (e.g., H01, H12, H52) with Turkish month abbreviations in the date range (Oca, Şub, Mar, Nis, May, Haz, Tem, Ağu, Eyl, Eki, Kas, Ara).

6.1.13 — What Changes the Projection

Since the projection is computed on-the-fly, any change to its source data immediately affects the output:

6.1.14 — Permission Model

Projeksiyon uses the canStok route guard from access.ts. The permission manifest defines 4 buttons: access_page, view_projections, create_projection, edit_projection. However, since Projeksiyon is entirely read-only (no CRUD operations), the create and edit permissions are vestigial — there is nothing to create or edit. The effective access control is simply whether the user can access the Stock pages.

6.1.15 — What This Submodule Does NOT Do

• It does not store any data — no dedicated database table exists
• It does not support CRUD — the projection is computed, not edited
• It does not use WebSocket — data is fetched once per page load or navigation
• It does not cache results — every request computes from scratch
• It does not account for current physical stock — it only tracks planned consumption vs. planned/actual arrivals
• It does not send alerts — shortage detection is visual only (the /summary endpoint exists but is not consumed by any notification system)
• It does not track kangal (coilless cable packaging) — kangal uses plastic packaging which is not a tracked raw material

6.2 — Hammadde Stok (Raw Material Stock)

6.2.1 — Purpose and Business Context

Hammadde Stok answers the question “What raw materials do we physically have in the warehouse right now, and how much of each is still available?”

This page exists because of a specific business need: the Hammadde module already has Hammaddeler Listesi (Materials List) — a flat, 14-column admin table that shows every individual material record with photos, WebSocket real-time updates, bilingual search, and granular edit forms. But Hammaddeler Listesi is a record-level view. A stock manager doesn’t want to scroll through 500 individual QR-coded entries to answer “how many kilograms of HFX 500P plastic do we have?” They need an aggregated category-level view that groups materials by type and name, shows totals, and highlights what’s available vs. what’s in use.

The data that populates this page comes from two upstream flows:

• Hammadde Girişi (Material Entry) creates the records — every time raw material arrives at the factory, an operator scans it through one of four entry archetypes (copper, tin, lot-based, count-based), and it enters the materials table with status = 'received' and remaining_weight = weight.
• Üretim (Production) consumes the records — when Production modules (especially Kabatel Çekme / wire drawing) use a raw material, they select it by QR code and deduct from its remaining_weight. A 1,000 kg copper rod (A1) that goes through wire drawing comes back as 980 kg. Production also changes status: received → in_use (material is currently on a machine) → consumed (fully depleted). This is exactly what the “Kalan” (Remaining) column and the conditional coloring (yellow/red) are designed to show.

So Hammadde Stok sits at the intersection: Hammadde Girişi fills it, Production drains it, and this page visualizes the current balance. It reads directly from the materials table (owned by the Hammadde module) via the shared /api/materials/list endpoint — it has no backend routes of its own. All grouping and aggregation happens client-side.

The page is implemented as a single React component (HammaddeStok) in src/pages/Stok/HammaddeStok/index.tsx (676 lines), using Ant Design’s Collapse with nested Table components, wrapped in a ConfigProvider with Turkish locale (trTR).

6.2.2 — CRUD Flow

Read (Primary Operation):

1. Page loads → useEffect([], []) triggers fetchMaterials() on mount
2. Single GET /api/materials/list call fetches ALL raw materials as a flat array, regardless of type
3. Response passes through processAndGroupMaterials() which: filters by material_type into 8 buckets, groups within each bucket by material_name, calculates aggregate totals (total, reserved, available), and stores everything in the sectionData state object
4. User clicks a Collapse panel to see the grouped table for that category
5. User clicks the expand arrow on a group row to see individual lots with QR codes, weights, supplier, dates, and status
6. User can click the “Yenile” (Refresh) button in the page header to re-fetch all data at any time

Update (Edit Modal):

1. Click the EditOutlined icon on any individual item row (Level 3)
2. Modal opens with title “Düzenle: {QR_CODE}” (e.g., “Düzenle: A7”)
3. Form pre-fills from the selected item’s current values via form.setFieldsValue()
4. Two fields available (see 6.2.10 for full details):
   • remaining_weight — InputNumber, min=0, step=0.1. Hidden for palette/reel types
   • status — Select dropdown with 5 options
5. On submit: PUT /api/materials/update/{id} with the form values
6. On success: message.success('Güncellendi') → modal closes → form resets → fetchMaterials() refetches all data
7. On failure: message.error('Güncellenemedi')

Delete (Hard Delete with Confirmation):

1. Click the DeleteOutlined icon (styled with color: '#ff4d4f') on any individual item row
2. Modal.confirm() opens with title “Silme Onayı”, content “{QR_CODE} kodlu malzemeyi silmek istediğinize emin misiniz?”, a red “Sil” (Delete) button, and an “İptal” (Cancel) button
3. On confirm: DELETE /api/materials/{id}/hard-delete — this is a permanent, irreversible deletion. The material record and all associated material_photos records are removed from the database
4. On success: message.success('Silindi') → fetchMaterials() refetches
5. On failure: message.error('Silinemedi')

Create: Not available on this page. Material creation happens exclusively through the Hammadde Girişi (Material Entry) page in the Hammadde module. This page only provides read, update, and delete operations.

6.2.3 — Data Source and API

Hammadde Stok consumes three API endpoints, all owned by the Hammadde module (material_routes.py), not the Stock module:

The API response is a flat array — no server-side grouping, filtering, or pagination. The frontend receives every material regardless of type and handles all grouping logic client-side. This means the entire raw material inventory loads in a single request.

6.2.4 — State Management Architecture

The component manages 5 pieces of state:

• allMaterials (RawMaterial[]) — the raw API response, stored for potential re-processing
• loading (boolean) — true during the fetchMaterials() call, drives the “Yenile” button spinner and the loading indicator inside each panel
• sectionData (Record<string, SectionData>) — the core data structure, keyed by material type. Each entry holds: groups (array of MaterialGroupSummary), loading, expandedKeys (which group rows are expanded), and totalItems (count of individual materials in this category). Initialized with all 8 category keys and empty defaults.
• activePanels (string[]) — which Collapse panels are open. Passed to Collapse via activeKey.
• editModalVisible + editingItem — controls the edit modal visibility and which material is being edited

The SectionData structure preserves expandedKeys across data refetches. When the user edits or deletes a material and the page refetches, the processAndGroupMaterials() function reads the previous expandedKeys via sectionData[cat.key]?.expandedKeys || [] and carries them into the new state. This means open group rows stay open after an update — the user does not lose their scroll position or expanded state.

6.2.5 — The 8 Material Category Panels

The page renders an Ant Design Collapse component with 8 panels, one per material category. The categories are defined in a constant MATERIAL_CATEGORIES array, each with a key, label (Turkish name), icon (Ant Design icon component), and color. The categories match the Hammadde Girişi page’s card colors exactly:

The categories and their visual identity are shared with Hammadde Girişi — a user sees the same colors and icons across both modules for consistency.

6.2.6 — Panel Header: Inline Statistics Dashboard

Each panel header is not just a label — it is a mini dashboard visible even when collapsed. From left to right it shows: the color-coded category icon, the category name, a record count tag (e.g., “47 kayıt”), and three aggregate statistics pushed to the right:

• Toplam (Total): Sum of remaining_weight for kg-based materials (falls back to weight if remaining is null), sum of weight (count) for palette/reel. Turkish locale formatting (e.g., “12.456,3 kg”).
• Kullanımda (In Use): Blue tag. Sum from items where status === 'in_use' — materials currently on a production machine.
• Serbest (Available): Green tag. Sum from items where status === 'received' or 'available' — materials ready for production to consume.

The getCategoryTotals() function computes these by iterating all groups and summing total_quantity, reserved_quantity, and available_quantity. Unit is “adet” for palette/reel, “kg” for everything else.

6.2.7 — Three-Level Table Hierarchy

The page implements a three-level drill-down that lets users navigate from high-level category totals down to individual lot details:

Level 1 — Category Panel (Collapse): The 8 Collapse panels themselves. Each panel header shows category name + icon + aggregate statistics. Opening a panel reveals the Level 2 table. Multiple panels can be open simultaneously — the activePanels state is an array of keys.

Level 2 — Material Name Group Table: Inside each panel, materials are grouped by material_name. For example, under “Plastik”, you see groups: “HFX 500P”, “HFFR 302”, “XLPE 2003”, “PVC 70”. Each group row shows: Malzeme Adı (bold name + lot count, e.g., “HFX 500P (12 lot)”), Toplam (aggregate weight/quantity), Kullanımda (blue tag, in-use total), Serbest (green tag, available total). If a material has no name, it falls into “{Category} (İsimsiz)”.

Level 3 — Individual Lots (Expanded Row): Expanding a group row reveals the individual material entries. The detail table shows 7–8 columns:

6.2.8 — Conditional Weight Coloring

The “Kalan” (Remaining) column is one of the most operationally important visual features on this page. It uses conditional coloring to provide instant visual feedback about material consumption levels. The logic computes two boolean flags for each row:

• isReduced = currentWeight < originalWeight * 0.95 — the material has been partially consumed (more than 5% used)
• isLow = currentWeight < originalWeight * 0.2 — the material is critically low (less than 20% remaining)

The rendering rules:

• Normal (no color, normal weight): remaining_weight ≥ 95% of original — material is barely touched or freshly entered
• Yellow (#faad14) + bold (fontWeight: 600): remaining_weight < 95% but ≥ 20% of original — partially consumed, draw attention
• Red (#ff4d4f) + bold (fontWeight: 600): remaining_weight < 20% of original — critically low, needs reorder

Concrete example: A 1,000 kg copper wire rod (QR: A1) shows normal text until it drops below 950 kg. At 949 kg it turns yellow. At 199 kg it turns red. The currentWeight is computed as remaining_weight ?? weight ?? 0 for backward compatibility with older records that don’t have remaining_weight set.

For palette and reel materials, this column is completely absent from the table — not hidden, but conditionally excluded from the columns array using a spread with empty array: ...(!isPaletteOrReel ? [{ ... }] : []). Counted items don’t have a remaining weight concept — they are either available or consumed as whole units.

6.2.9 — Unit Adaptation: kg vs adet

The page dynamically adapts its behavior based on whether a material is measured by weight or counted as discrete pieces. This distinction affects five different places in the UI:

1. Panel header statistics: Show “kg” or “adet” after aggregate numbers
2. Group table columns: Unit suffix on Toplam, Kullanımda, Serbest values
3. Detail table column title: “Ölçülen” (Measured) for kg types vs “Miktar” (Quantity) for adet types
4. Detail table “Kalan” column: Completely hidden for palette/reel
5. Edit modal: The “Kalan Ağırlık (kg)” field is hidden for palette/reel types

The determination is made by checking materialType === 'raw_palette' || materialType === 'raw_reel'. These are the only two count-based categories — all six others use kg. For quantity calculations in the grouping logic, palette/reel materials read from item.weight (which stores the count), while kg-based materials read from item.remaining_weight ?? item.weight.

6.2.10 — Client-Side Grouping Logic

The processAndGroupMaterials() function is the core data transformation engine. It takes the flat API response and produces the hierarchical sectionData structure. The function runs in four stages:

1. Category filter: For each of the 8 categories, filter materials.filter(m => m.material_type === cat.key)
2. Name grouping: Within each category, build a Record<string, RawMaterial[]> keyed by material_name. If material_name is null/empty, the key becomes “{label} (İsimsiz)” (e.g., “Bakır (İsimsiz)”)
3. Group aggregation: For each group, create a MaterialGroupSummary object:
   • total_quantity: Sum of remaining_weight ?? weight ?? 0 for kg types, or weight ?? 0 for adet types, across ALL items regardless of status
   • reserved_quantity: Sum from items where status === 'in_use'
   • available_quantity: Sum from items where status === 'received' || status === 'available'
   • Items with other statuses (consumed, rejected) are counted in total_quantity but not in reserved or available — they effectively represent consumed or discarded stock
4. State preservation: Carry forward the previous expandedKeys from the existing sectionData, so open group rows remain open after a data refresh

6.2.11 — The Edit Modal

The edit modal is deliberately minimal — a single variant, unlike Hammaddeler Listesi’s three variants (copper/tin, lot-based, palette/reel). It provides only two fields:

• Kalan Ağırlık (Remaining Weight): A numeric input pre-filled with the material’s current remaining_weight. This is the field Production affects when consuming material, and this modal lets a stock manager manually correct it if the system value drifts from physical reality. Hidden for palette/reel since those are whole units.
• Durum (Status): Dropdown with 5 options: Teslim Alındı (received), Mevcut (available), Kullanımda (in_use), Tükendi (consumed), Reddedildi (rejected). This lets a manager manually override the lifecycle state — e.g., marking a damaged material as rejected, or correcting a status that Production failed to update.

Unlike Hammaddeler Listesi, this modal does not allow editing QR codes, lot numbers, supplier names, or photos. Those belong to the Hammadde module’s full edit flow. This modal is strictly for stock-level corrections: “how much is actually left?” and “what state is it really in?”

6.2.12 — Loading and Empty States

The page handles two empty-data scenarios:

• Loading state: While data is being fetched, each panel shows a spinner with “Yükleniyor...”. The “Yenile” (Refresh) button in the page header also shows a loading state.
• Empty category: If a category has no materials (e.g., no antirodent currently in stock), the panel shows “Bu kategoride stok bulunamadı” (No stock found in this category).

6.2.13 — Timezone Handling

All dates from the API are stored as UTC in the database. The frontend converts them to Turkey timezone for display using dayjs with the utc and timezone plugins:

• The timezone constant is defined at module level: const TURKEY_TZ = 'Europe/Istanbul'
• Date rendering: dayjs.utc(date).tz(TURKEY_TZ).format('DD.MM.YY')
• This ensures a material entered at 23:30 UTC on January 15 shows as January 16 in the Turkish display (UTC+3), correctly reflecting the local date of entry

6.2.14 — Connection to Other Modules

Hammadde Stok does not exist in isolation — it is essentially a read-only window into data that is created, modified, and consumed by other modules. Understanding those connections is key to understanding this page:

Upstream: Who fills the inventory?

• Hammadde Girişi (Material Entry) — the sole creator. Every single row visible on this page was created through one of the four entry archetypes in Hammadde Girişi. When a copper wire rod arrives, an operator weighs it, scans photos, assigns QR code A{n}, and it enters the materials table with status = 'received' and remaining_weight = weight. That record immediately becomes visible here under the “Bakır” panel. Hammadde Stok cannot create, only view.
• Hammadde Sipariş (Material Orders) — the reason materials arrive in the first place. When a purchase order is fulfilled and materials are delivered, the entry operator can link the material to the order group code (R1, R2, etc.). This traceability exists in the data but is not displayed on this page — it’s visible on Hammaddeler Listesi’s “Sipariş No” column instead.
• Tedarikçi Yönetimi (Supplier Management) — defines the supplier names that appear in the detail rows. The supplier association is set at entry time and is read-only here.

Downstream: Who drains the inventory?

• Üretim / Production (especially Kabatel Çekme) — the primary consumer. When Production starts a work card, it selects raw materials by QR code. For wire drawing (Kabatel Çekme), an operator picks a copper rod (e.g., A7) and feeds it into the machine. Production then updates the material record: status changes from received/available to in_use, and remaining_weight decreases as material is consumed. When the rod is fully used, status becomes consumed. This is the entire reason the “Kalan” column exists with its yellow/red coloring — it visualizes how much Production has consumed. Similarly, plastic granules, tin, catalysts, and dyes are consumed by their respective production steps (extrusion, tinning, etc.).
• Lab (indirect) — Lab tests may result in a material being rejected, which changes its status and effectively removes it from the “Serbest” (Available) count on this page.

Sibling views over the same data:

• Hammaddeler Listesi (in Hammadde module) — reads from the exact same /api/materials/list endpoint. It is the full-power admin view: 14 columns, lazy-loaded photos, WebSocket real-time sync, bilingual search, three edit form variants, QR label printing, 12 granular permissions. This page is the record-level view; Hammadde Stok is the stock-level view. Together they cover different user needs over identical data.
• Projeksiyon (in Stock module) — also uses material data, but for a completely different purpose. Projeksiyon computes what the stock will be in future weeks by combining current inventory + incoming orders − production requirements. Hammadde Stok shows what the stock is right now. They are complementary: one is a live snapshot, the other is a weekly forecast.

6.2.15 — Permission Model

The page uses the canStok route guard from access.ts for page-level access. The permission manifest in permissionManifest.ts defines 5 buttons for this page:

• access_page — can access the Hammadde Stok page
• view_table — can see the category tables
• view_details — can expand groups to see individual lots
• edit_stock — can open the edit modal
• adjust_quantity — can modify remaining weight values

However, unlike Hammaddeler Listesi which enforces permissions at the button level (e.g., disabling the print button without print_qr permission), this page does not enforce button-level checks in the frontend. The edit and delete buttons are always rendered for any user who has page access. Permission enforcement happens at the API level only.

6.2.16 — What This Submodule Does NOT Do

• It does not have its own backend routes — it consumes the Hammadde module’s material_routes.py endpoints
• It does not support material creation — that happens exclusively in Hammadde Girişi
• It does not use WebSocket for real-time updates — data is fetched once on mount and refreshed manually or after edit/delete operations. Compare with Hammaddeler Listesi which subscribes to materials and all WebSocket rooms
• It does not have server-side filtering or pagination — all 8-way category filtering, name-based grouping, and quantity aggregation is client-side
• It does not show material photos — no delivery or test photos are displayed. These are only visible in Hammaddeler Listesi
• It does not show order linkage — the “Sipariş No” (order group code) column exists in Hammaddeler Listesi but not here
• It does not support printing — no QR label reprint functionality. That is in Hammaddeler Listesi
• It does not have a client-side search bar — browsing is done by expanding category panels and group rows
• It does not track consumption history — it shows the current snapshot only, not a timeline of weight changes
• It does not have soft-delete — the delete operation uses /hard-delete, permanently removing the record

6.3 — Ürün Stok (Product Stock)

Live inventory of semi-finished and finished products, organized by production step — the output side of the factory floor.

6.3.1 — Purpose and Business Context

Ürün Stok answers the question: "What did the factory produce and where is it now?"

While Hammadde Stok tracks raw inputs waiting to be consumed, Ürün Stok tracks the outputs: every basket and reel that came off a production machine. Each item in this page was physically created during a Production Session — an operator ran a machine, recorded baskets of output, printed QR labels, and those baskets landed here. The page exists because:

• Üretim Listesi (Production List) creates these items — when a production session records output baskets, each basket is simultaneously written to production_outputs and half_product_stock. This page is the read-only window into that accumulated inventory.
• Üretim Geçmişi (Production History) shows the same items from a session-centric perspective (which session produced what). Ürün Stok shows them from a stock-centric perspective (how much of each product code exists right now, regardless of which session made it).
• Order Module determines allocation — when a work card is opened for an order, baskets produced within the order's required quantity are marked ORDER. Any excess production becomes STOCK (free inventory). This allocation split is a core business concept visible in every group row.
• Lab Module (Test Yönetimi) bonds quality tests to specific production outputs. Ürün Stok lets stock managers view bonded test results directly from each item — the test icon on each row opens a modal showing test interval, name, standard number, and pass/fail status fetched from the Lab system.
• Source QR Traceability — each item stores source_qr_codes, a JSON array of input QR codes consumed to produce it. This chain (A1 copper → X1 kabatel → Y1 kalaylama → ...) is the factory's traceability backbone.

6.3.2 — CRUD Flow

Create: This page does not create items. Half-product stock records are exclusively created by the Production module during active production sessions. When an operator records a basket output, the backend writes to both production_outputs and half_product_stock tables simultaneously. There is no "Add" button on this page.

Read: On mount, the component fires 7 parallel API requests — one for each production step (Kabatel, Kalaylama, İncetel, Buncher, Extruder, E-Beam, Aktarma). Each request hits GET /api/stock/half-products/by-step/{step}?status_filter=available. The backend queries the half_product_stock table filtered by production_step and status, joins with production_sessions to get operator name, and returns sorted results (newest first). The frontend then groups by product_code, calculates per-group totals, and builds the Collapse panel hierarchy.

Update: Per-item edit via modal. Clicking the edit icon opens a form with three fields: remaining_weight_kg (required, InputNumber with min=0 and step=0.1), allocation (Select: ORDER or STOCK), and notes (TextArea). Submits PUT /api/stock/half-products/{id}. The backend whitelists only remaining_weight_kg, status, and notes for update (note: allocation is sent from frontend but the backend's allowed_fields list does not include it — potential inconsistency). After success, full data refresh.

Delete: Confirmation modal with item QR code displayed. Calls DELETE /api/stock/half-products/{id}. The backend performs a cascading delete: (1) finds the linked ProductionOutput via production_output_id or fallback output_code matching and deletes it, (2) checks if the deleted item's QR number was the highest in its prefix sequence (e.g., X150 is the highest X-prefix) — if so, decrements HalfProductSequence.last_number to allow reuse, (3) deletes the stock record itself. This cascade ensures that deleting from stock doesn't leave orphaned production output records or broken QR sequences.

6.3.3 — Data Source and API Architecture

Unlike Hammadde Stok which borrows a single endpoint from the Hammadde module, Ürün Stok has its own dedicated backend at api/stock/half_product_routes.py with 6 endpoints:

Additionally, the bonded tests feature calls GET /api/production/test-requests/bonded-tests/output/{output_id} from the Production module's test_integration_routes.py. This cross-module call fetches Lab tests bonded to a specific production output, grouped by test interval (üretim_başı, her_sepet_sonu, üretim_sonu).

6.3.4 — Database Schema: half_product_stock Table

This is the dedicated table for this submodule — unlike Hammadde Stok which reads from the Hammadde module's materials table, Ürün Stok has its own table managed by models/half_product_stock.py.

Key relationships in the ORM: order (Order), production_output (ProductionOutput), session (ProductionSession), work_card (WorkCardDB). Composite indexes on (production_step, status) and (product_code, status) optimize the primary query pattern.

The companion model HalfProductSequence (table half_product_sequences) tracks the last-used number for each prefix: {'X': 150} means X150 was the last Kabatel output. The prefix-to-machine mapping: kabatel_cekme → X, kalaylama → Y, incetel → Z, buncher → T, extruder → U, ebeam → G.

6.3.5 — State Management Architecture

The component uses 8 state variables:

• loading (boolean) — global loading flag during the parallel fetch of all 7 steps
• sectionData (Record<string, SectionData>) — the main data store. Initialized with all 7 production step keys, each containing: groups (ProductGroupSummary[]), loading, expandedKeys, totalItems, and grandTotals (total/siparis/serbest). This is the heart of the page.
• activePanels (string[]) — which Collapse panels are currently open
• editModalVisible + editingItem — edit modal state
• testsModalVisible + testsLoading + selectedTests + selectedOutputCode — bonded tests modal state

Data flow: fetchAllData() fires 7 parallel request() calls via Promise.all(). Each response is grouped by product_code on the client, with per-group allocation split (ORDER kg vs STOCK kg) and per-step grand totals calculated. The grouped results replace the entire sectionData state, preserving expandedKeys from the previous state so row expansions survive a refresh.

6.3.6 — The 7 Production Step Panels

The page uses an Ant Design Collapse component with 7 panels, one for each production step. Unlike Hammadde Stok's 8 material categories (static names like "Bakır", "PVC"), these panels follow the cable manufacturing pipeline:

Each panel has a distinctive icon and color. The icon set uses Ant Design icons: ScissorOutlined (Kabatel), FireOutlined (Kalaylama), CompressOutlined (İncetel), ApartmentOutlined (Buncher), BuildOutlined (Extruder), ThunderboltOutlined (E-Beam), SwapOutlined (Aktarma).

6.3.7 — Panel Header: Three-Column Statistics

Each panel header displays three right-aligned stat columns showing the allocation split:

• Toplam (Total) — grand total kg of all available items in this production step
• Sipariş (Order) — total kg allocated to customer orders (green tag)
• Serbest (Free) — total kg of excess production / free stock (orange tag)

The item count is also displayed as a tag next to the step label. When a step has no data, the stat columns remain visible but at reduced opacity, maintaining layout consistency across all panels.

6.3.8 — Two-Level Table Hierarchy

Inside each panel, data is displayed in a two-level hierarchy (compared to Hammadde Stok's three levels):

Level 1 — Group Row (by product_code): Each row represents all baskets of a specific product code within this production step. Shows:

• Ürün Kodu (Product Code) with item count
• Toplam (Total kg) — sum of all remaining weights
• Sipariş (Order kg) — sum of ORDER-allocated items (green tag)
• Serbest (Free kg) — sum of STOCK-allocated items (orange tag)

Clicking the expand icon reveals...

Level 2 — Individual Items: Each row is a single basket/reel with its full detail. Columns:

6.3.9 — The Allocation System: ORDER vs STOCK

This is a key concept that Ürün Stok exposes but does not control. The allocation is determined at production time, not at stock viewing time:

• When a production session runs against a work card, the backend tracks cumulative production against the order's required quantity.
• Every basket produced while cumulative output is below the required quantity is marked ORDER and linked to the order_id.
• Once cumulative output exceeds the required quantity, subsequent baskets are marked STOCK with null order_id.

Ürün Stok displays this allocation split at every level: per-item (tag), per-group (two separate kg columns), and per-step (panel header stats). This gives stock managers immediate visibility into how much inventory is committed to orders versus how much is free for new orders or general use.

6.3.10 — Bonded Tests Modal: Lab Connection

Items that have a production_output_id (virtually all items created through normal production flow) show an experiment icon in their row. Clicking it opens a modal that fetches /api/production/test-requests/bonded-tests/output/{output_id} and displays all quality tests bonded to that specific production output.

The response groups tests by interval:

• Üretim Başı (Production Start) — tests run at the beginning of a session
• Her Sepet Sonu (Every Basket End) — per-basket tests, the most granular
• Üretim Sonu (Production End) — end-of-session validation tests

Each test row shows: test ID (purple tag), test name, standard number (if any), interval label, and status with color-coded icon (green check for passed, red X for failed, yellow clock for pending). The data comes from the Lab module's test request system — this is a cross-module read that bridges Stock and Quality Control.

6.3.11 — Source QR Traceability

The source_qr_codes field stores a JSON array of QR codes that were consumed to produce this item. The frontend parses this JSON and displays the first 2 codes with an ellipsis if there are more. For example:

• A Kabatel basket X5 might show source ["A1", "A3"] — the raw copper lots it consumed
• A Kalaylama reel Y12 might show source ["X5", "X6"] — the Kabatel outputs it consumed

This creates a full material chain: raw copper (A-prefix) → kabatel wire (X-prefix) → tinned wire (Y-prefix) → fine wire (Z-prefix) → bundled wire (T-prefix) → insulated cable (U-prefix) → cross-linked cable (G-prefix). Each link is stored in source_qr_codes, making any basket traceable back to its raw material origin.

6.3.12 — Client-Side Grouping Logic

After the 7 parallel API responses arrive, fetchAllData() processes each step's data:

1. Iterate over items, group into a Record<string, HalfProductStock[]> map by product_code (or "Unknown" fallback)
2. For each group, calculate total_kg, siparis_kg (ORDER allocation), and serbest_kg (STOCK allocation) by summing remaining_weight_kg
3. Accumulate grand totals per step
4. Sort groups alphabetically by product code
5. Build the SectionData object, preserving existing expandedKeys so that expanded rows survive a data refresh

Compared to Hammadde Stok's processAndGroupMaterials() function which groups by category then by material name (3 levels), Ürün Stok groups only by product_code within each step panel (2 levels), because the step panel itself acts as the top-level grouping.

6.3.13 — The Edit Modal

The edit modal allows modification of three fields: remaining_weight_kg (required numeric input with 0.1 step), allocation (ORDER/STOCK dropdown), and notes (free-text area). Compared to Hammadde Stok's 2-field modal (weight + status), this adds the allocation field. On submit, form values are sent to PUT /api/stock/half-products/{id}, then all data is refreshed.

Note: The backend's allowed_fields whitelist for the PUT endpoint is ['remaining_weight_kg', 'status', 'notes'] — it does not include allocation. The frontend sends allocation in the payload, but the backend silently ignores it. This means allocation is effectively read-only from this page, only changeable at production time.

6.3.14 — Loading and Empty States

During the parallel fetch, each panel's content area shows a centered Spin spinner with "Yükleniyor..." text. After loading completes, panels with no items for that production step display Ant Design's Empty component with the message "Bu kategoride stok bulunamadı".

6.3.15 — Timezone Handling

Identical pattern to Hammadde Stok: dayjs with utc and timezone plugins. All produced_at timestamps are stored UTC in the database and converted to Europe/Istanbul timezone on the frontend using dayjs.utc(date).tz(TURKEY_TZ).format('DD.MM.YY HH:mm').

6.3.16 — Connection to Other Modules

Ürün Stok is the most interconnected of the three Stock submodules. It touches every major module:

• Production → Üretim Listesi (upstream writer): Every record in half_product_stock was created during a production session. The session_id and production_output_id columns directly link back to the Production module's data. The backend even joins with ProductionSession to return operator names.
• Production → Üretim Geçmişi (parallel view): Production History shows the same production outputs but organized by session and time. Ürün Stok reorganizes the same underlying data by product code and step, providing an inventory-centric rather than session-centric view.
• Production → Downstream consumption: When the next production step consumes a basket (e.g., Kalaylama consumes X-coded Kabatel output), the basket's remaining_weight_kg decreases, status changes to in_use or consumed, and consumed_at is filled. These items stop appearing on this page because the default filter is status_filter=available.
• Order Module (allocation source): The allocation (ORDER/STOCK) and order_id are set at production time based on cumulative output vs. order requirements. The work_card_id column traces each basket to its originating work card from the Order module.
• Lab Module → Test Yönetimi (quality bridge): The bonded tests modal fetches test results from the Lab's test_integration_routes.py. Tests are bonded to production outputs by the Lab system during or after production. Ürün Stok is the only Stock submodule that directly reads Lab data.
• Hammadde Module (source material): The source_qr_codes field contains references to raw material QR codes (A-prefix for copper, etc.) from the Hammadde module. While Ürün Stok doesn't query the materials table, the traceability chain connects the two modules at the data level.

6.3.17 — What This Submodule Does NOT Do

• It does not create inventory — that happens exclusively in the Production module during active sessions.
• It does not show consumed or shipped items — the default filter status_filter=available hides completed lifecycle items.
• It does not have a search bar — navigation is done by expanding step panels and group rows.
• It does not support bulk operations — no multi-select, no batch allocation change, no batch delete.
• It does not actually modify allocation — while the edit modal presents an allocation dropdown, the backend silently ignores it (not in allowed_fields).
• It does not use WebSocket or real-time updates — data is fetched on mount and manually via the Refresh button.
• It does not display the initial_weight_kg — only remaining_weight_kg is shown, so there is no consumption percentage visualization (unlike Hammadde Stok's color-coded weight column).
• It does not have conditional weight coloring — unlike Hammadde Stok which colors weights yellow/red based on consumption ratio, this page shows all weights in plain text.
• It does not include the aktarma step in the backend's ProductionStep enum or MACHINE_TO_PREFIX mapping — the frontend defines 7 steps but the backend enum only has 6, suggesting Aktarma is a newer addition.

7. CONCLUSION

7.1 What This Document Covered

This deep dive analyzed the Stock & Inventory module across three submodules, each with a fundamentally different data strategy:

7.2 Architectural Principles

Three design principles define this module and distinguish it from the rest of the ERP system:

7.3 The Numbers

* Projeksiyon has zero persistent storage. Hammadde Stok has zero own endpoints. The only write-capable endpoints belong to Ürün Stok (PUT + DELETE), and even those modify a table populated entirely by another module.

7.4 How Stock Reads the Factory

At first glance, Stock appears to be a passive, read-only module — it reads from everywhere and writes almost nowhere. But this is misleading. Ürün Stok plays a critical upstream role in the production planning loop: the Order module’s work card calculator engine queries available product stock (items with STOCK allocation and available status) and deducts free inventory before generating new work cards. This is precisely why the allocation (ORDER vs STOCK) and status (available, in_use, consumed, reserved) fields exist — not just for display, but as input data that determines how much new production is actually needed.

This creates a circular dependency, not a linear pipeline:

The entire ERP system operates as this loop. There is no true “starting module” — every module depends on data from another, which in turn depends on a third, which circles back. Stock sits at a critical junction in this loop: it receives data from Production and Hammadde, but it also feeds back into Order by providing the available inventory that shapes how many work cards get generated. If Ürün Stok shows 50 kg of free Kabatel wire, the calculator subtracts that before distributing production tasks. Without accurate stock data, the factory either overproduces (wasting resources) or underproduces (missing delivery dates).

This also means Stock is the first module to break when upstream data is inconsistent. If a material order’s delivered_date is wrong, Projeksiyon’s forecast shifts. If Production doesn’t update remaining_weight_kg, Hammadde Stok shows stale weights. If a production output is deleted outside of Ürün Stok, orphaned stock records appear. Stock doesn’t just display data — it exposes the integrity of the entire system.

7.5 Final Word