Connect sales, stock movements, purchasing, receiving, exceptions, and reconciliation into one controlled workflow. 제공할 내용: Business and inventory model, Current records and problems, Constraints and controls. 예상 결과: A practical inventory-control process with records, formulas, roles, alerts, and test cases.
1
맥락 추가
텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.
2
프롬프트
채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다
Design an order, inventory, and replenishment tracking process from the supplied business facts.
SKUs, locations, channels, orders, suppliers, lead times, returns, bundles, units, and service targets:
[business]
Systems/files, fields, timestamps, ownership, counts, discrepancies, stockouts, delays, and quality issues:
[records]
Review, demand/lead-time evidence, safety-stock policy, authority, budget, audit, access, integrations, and scale:
[controls]
Define the inventory event model before recommending a sheet or tool. Distinguish on hand, available, allocated, picked, shipped, returned-pending-inspection, damaged, inbound ordered, inbound confirmed, received, and adjusted only where relevant. Choose one source of truth and stable SKU/location/order/purchase-order IDs. Never infer missing units, supplier reliability, demand, lead time, reorder point, safety stock, or available stock. Do not use negative inventory or manual overwrite to hide discrepancies.
Map order-to-fulfillment and replenishment workflows with trigger, input, action, record change, owner, timestamp, evidence, exception, approval, and SLA. Specify tables/fields, status values, validation, calculations with units, alert logic, review cadence, cycle counts, returns, cancellations, partial shipments, backorders, bundles, supplier changes, and audit history as applicable. Recommend reorder formulas only from supplied policy/evidence; otherwise show required data and a temporary manual review. Include role/access matrix, reconciliation, dashboard definitions with denominators, implementation phases, migration, and normal/edge/failure test cases.
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.
입력에서 결과까지
적용 예시
구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요
실제 입력
Business and inventory model
Small ceramics shop with 42 SKUs at one store/stockroom. Sales channels: POS and online store; online orders reserve stock at checkout and ship next business day. Products use units 'pieces'; gift set BND-01 contains 2 MUG-BLU + 1 TEA-WHT. Two suppliers, typical stated lead times 7 and 14 calendar days but no reliability history. Returns are inspected before restock; damaged pieces never return to available. Service goal: avoid accepting online orders without available pieces.
Current records and problems
POS exports daily CSV; online store exports orders with order ID, SKU, quantity, paid/cancelled/refunded timestamps. Spreadsheet has SKU and one 'stock' column overwritten after counts. Purchase orders live in email; receiving has no PO reference. Last month three online orders were cancelled after physical shortage. SKU labels differ for five products. Owner approves purchases; store associate picks/receives; bookkeeper reconciles weekly.
Constraints and controls
Start in Google Sheets; no integration budget this quarter. Daily 15-minute review, weekly reconciliation, monthly cycle count. Owner has not set safety stock or reorder service level. Six months of daily sales can be exported; supplier promised dates available only in emails. Purchase over $500 needs owner approval; associate may draft POs but not send. Protect customer details; inventory sheet should not contain names/addresses.
예시 출력
Source of truth: one append-only Inventory Events table plus SKU master; the current overwritten stock column becomes a migration snapshot, not history. IDs: canonical SKU, Location=STORE, order ID, PO ID, event ID. Normalize five aliases before go-live. Units are pieces.
Core fields: Events—event ID/time/type/SKU/qty signed/location/reference ID/source/status/entered by/evidence/approved by/correction-of. Orders—order ID/channel/status/SKU/qty/reserved/picked/shipped timestamps, no customer identity. POs—PO ID/supplier/SKU/qty/unit cost/draft/approved/sent/promised/received status. Returns—reference/SKU/qty/inspection outcome. Never delete an error; add reversing/correcting event.
States/calculation: On hand = opening + received + approved restock returns − shipped/POS sold − damaged ± approved adjustments. Allocated = paid open online units not cancelled/shipped. Available = On hand − Allocated. Inbound is reported separately and never included in Available. Bundle availability BND-01 = min(floor(available MUG-BLU/2), available TEA-WHT); allocate/release components when bundle order is paid/cancelled. Block/manual-review online acceptance when Available would go below zero; the sheet cannot enforce storefront checkout, so this remains an operational control and integration gap.
Daily: import POS/order events, validate SKU/order uniqueness, reconcile open allocations, inspect exceptions. Associate drafts PO; owner approves/sends, mandatory if >$500 and still owner-controlled below that unless policy changes. Receiving records PO/actual qty/date; mismatches go Exception, not overwrite. Returns remain pending until inspection. Weekly bookkeeper reconciles computed on-hand with source exports and logs variances; monthly count creates approved adjustments with reason.
Reorder: do not invent points. Phase 1 dashboard flags owner review using six-month demand, current available/inbound, emailed promised dates; collect actual PO sent/received dates for reliability. Owner later chooses lead-time/safety-stock policy. Tests: sale, reservation/cancel, partial ship, duplicate import, unknown SKU, bundle depletion, damaged return, partial PO receipt, >$500 approval, count variance. Migration requires physical count, alias map, open order/PO capture, and signed opening snapshot.
효과가 있는 이유
1
An event model prevents one ambiguous stock number from mixing physical, committed, damaged, and inbound units
2
Reconciliation and audit evidence make exceptions visible instead of letting manual edits silently rewrite history
결과 확인
Are inventory states, events, units, IDs, source of truth, and record ownership unambiguous
Are reorder logic, available-stock calculations, and alerts supported by supplied policy and data
Does the process cover reconciliation, approvals, access, exceptions, and edge-case tests
안심하고 사용하세요
자주 묻는 질문
이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변
What should I prepare before using “Design an order, inventory, and replenishment tracking process”?
For “Design an order, inventory, and replenishment tracking process,” prepare Business and inventory model, Current records and problems, and Constraints and controls. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.
When is the “Design an order, inventory, and replenishment tracking process” result not ready to use?
The result is not ready if it does not yet deliver the stated outcome—A practical inventory-control process with records, formulas, roles, alerts, and test cases—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.
Which AI tools have recorded tests for “Design an order, inventory, and replenishment tracking process”?
The published test record for “Design an order, inventory, and replenishment tracking process” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.
ChatGPT
