판매, 재고 이동, 구매, 입고, 예외 및 대조를 하나의 통제된 업무 흐름으로 연결합니다. 제공할 내용: 사업 및 재고 모델, 현재 기록과 문제, 제약 조건 및 통제. 예상 결과: 기록, 수식, 역할, 알림 및 테스트 사례를 갖춘 실용적인 재고 관리 프로세스.
1
맥락 추가
텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.
2
프롬프트
채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다
제공된 사업 사실을 바탕으로 주문, 재고 및 보충 추적 프로세스를 설계하세요.
SKU, 위치, 채널, 주문, 공급업체, 리드 타임, 반품, 번들, 단위 및 서비스 목표:
[business]
시스템/파일, 필드, 타임스탬프, 담당, 건수, 불일치, 품절, 지연 및 품질 문제:
[records]
검토, 수요/리드 타임 증거, 안전 재고 정책, 권한, 예산, 감사, 접근 권한, 연동 및 규모:
[controls]
시트나 도구를 권고하기 전에 재고 이벤트 모델을 정의하세요. 관련 있는 경우에만 보유 재고, 가용 재고, 할당됨, 피킹됨, 배송됨, 반품 후 검사 대기, 파손됨, 입고 주문됨, 입고 확인됨, 입고 완료 및 조정됨을 구분하세요. 하나의 신뢰할 수 있는 정보 원천과 안정적인 SKU/위치/주문/구매 주문 ID를 선택하세요. 누락된 단위, 공급업체 신뢰도, 수요, 리드 타임, 재주문점, 안전 재고 또는 가용 재고를 추론하지 마세요. 불일치를 숨기려고 음수 재고나 수동 덮어쓰기를 사용하지 마세요.
주문부터 이행까지의 흐름과 보충 업무 흐름을 트리거, 입력, 조치, 기록 변경, 담당자, 타임스탬프, 증거, 예외, 승인 및 SLA와 함께 연결하세요. 해당하는 경우 표/필드, 상태 값, 유효성 검사, 단위를 포함한 계산, 알림 논리, 검토 주기, 순환 실사, 반품, 취소, 부분 배송, 미납 주문, 번들, 공급업체 변경 및 감사 이력을 명시하세요. 제공된 정책이나 증거가 뒷받침할 때만 재주문 수식을 권고하고, 그렇지 않으면 필요한 데이터와 임시 수동 검토를 제시하세요. 역할/접근 권한 매트릭스, 대조, 분모를 포함한 대시보드 정의, 구현 단계, 마이그레이션 및 정상/경계/실패 테스트 사례를 포함하세요.
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.
입력에서 결과까지
적용 예시
구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요
실제 입력
사업 및 재고 모델
매장 겸 창고 한 곳에서 SKU 42개를 취급하는 소규모 도자기 가게입니다. 판매 채널은 POS와 온라인 매장이며, 온라인 주문은 결제 시 재고를 예약하고 다음 영업일에 배송합니다. 제품 단위는 'pieces'입니다. 선물 세트 BND-01은 MUG-BLU 2개와 TEA-WHT 1개로 구성됩니다. 공급업체는 두 곳이며 통상 제시하는 리드 타임은 각각 달력일 기준 7일과 14일이지만 신뢰도 이력은 없습니다. 반품은 검사 후에만 재고로 되돌리고 파손된 제품은 가용 재고로 되돌리지 않습니다. 서비스 목표는 가용 수량이 없을 때 온라인 주문을 받지 않는 것입니다.
현재 기록과 문제
POS는 매일 CSV를 내보냅니다. 온라인 매장은 order ID, SKU, quantity, paid/cancelled/refunded timestamps가 있는 주문을 내보냅니다. 스프레드시트에는 SKU와 실사 후 덮어쓰는 'stock' 열 하나만 있습니다. PO는 이메일에 있고 입고 기록에는 PO 참조가 없습니다. 지난달 온라인 주문 3건이 실물 부족으로 취소되었습니다. 제품 5개의 SKU 레이블이 일치하지 않습니다. 소유자가 구매를 승인하고 매장 직원이 피킹/입고를 담당하며 장부 담당자가 매주 대조합니다.
제약 조건 및 통제
이번 분기에는 Google Sheets로 시작하며 연동 예산은 없습니다. 매일 15분 검토, 매주 대조, 매월 순환 실사를 합니다. 소유자는 안전 재고나 재주문 서비스 수준을 정하지 않았습니다. 6개월간 일별 판매 데이터를 내보낼 수 있으나 공급업체 약속일은 이메일에만 있습니다. $500를 초과하는 구매에는 소유자의 승인이 필요합니다. 매장 직원은 PO 초안을 작성할 수 있지만 발송할 수 없습니다. 고객 정보를 보호하며 재고 시트에는 이름/주소를 포함하지 않습니다.
예시 출력
신뢰할 수 있는 정보 원천: 추가 전용 Inventory Events 표 하나와 SKU 마스터입니다. 현재의 덮어쓰기식 stock 열은 이력이 아니라 마이그레이션 스냅샷으로 삼습니다. ID는 canonical SKU, Location=STORE, order ID, PO ID, event ID입니다. 운영 시작 전에 다섯 개 별칭을 표준화합니다. 단위는 pieces입니다.
핵심 필드: 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이며 고객 신원은 포함하지 않습니다. POs—PO ID/supplier/SKU/qty/unit cost/draft/approved/sent/promised/received status. Returns—reference/SKU/qty/inspection outcome. 오류를 삭제하지 말고 취소 또는 수정 이벤트를 추가합니다.
상태/계산: 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는 별도로 보고하고 Available에 절대 포함하지 않습니다. Bundle availability BND-01 = min(floor(available MUG-BLU/2), available TEA-WHT)입니다. 번들 주문 결제 시 구성품을 할당하고 취소 시 해제합니다. Available이 0 미만이 될 경우 온라인 주문 접수를 차단하거나 수동 검토합니다. 시트는 온라인 매장 결제를 강제할 수 없으므로 이는 운영 통제이자 연동 공백으로 남습니다.
매일: POS/주문 이벤트를 가져오고 SKU/주문 고유성을 검증하며 미결 할당을 대조하고 예외를 확인합니다. 매장 직원이 PO 초안을 작성하고 소유자가 승인해 발송합니다. $500 초과 시 승인이 필수이며 정책이 바뀌지 않는 한 그 이하도 소유자가 통제합니다. 입고 시 PO/실제 수량/날짜를 기록하고 불일치는 덮어쓰지 않고 Exception으로 보냅니다. 반품은 검사할 때까지 pending 상태로 둡니다. 장부 담당자는 매주 계산된 On hand를 원본 내보내기와 대조하고 차이를 기록하며, 매월 실사에서는 사유가 있는 승인된 조정을 만듭니다.
재주문: 재주문점을 지어내지 마세요. Phase 1 대시보드는 6개월 수요, 현재 Available/Inbound 및 이메일의 약속일을 사용해 소유자 검토를 표시합니다. 신뢰도를 파악하도록 실제 PO 발송일/입고일을 수집합니다. 이후 소유자가 리드 타임/안전 재고 정책을 선택합니다. 테스트에는 판매, 예약/취소, 부분 배송, 중복 가져오기, 알 수 없는 SKU, 번들 소진, 파손 반품, PO 부분 입고, >$500 승인 및 실사 차이가 포함됩니다. 마이그레이션에는 실물 실사, 별칭 맵, 미결 주문/PO 수집 및 서명된 기초 스냅샷이 필요합니다.
효과가 있는 이유
1
이벤트 모델은 하나의 모호한 재고 수치에 실물, 할당, 파손 및 입고 예정 수량이 섞이는 일을 막습니다
2
대조 및 감사 증거는 예외를 드러내고 수동 편집이 기록을 몰래 다시 쓰는 일을 막습니다
결과 확인
재고 상태, 이벤트, 단위, ID, 신뢰할 수 있는 정보 원천 및 기록 담당이 명확한가요?
재주문 논리, 가용 재고 계산 및 알림이 제공된 정책과 데이터로 뒷받침되나요?
프로세스가 대조, 승인, 접근 권한, 예외 및 경계 사례 테스트를 포함하나요?
안심하고 사용하세요
자주 묻는 질문
이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변
“주문·재고·보충 추적 프로세스 설계하기”를 사용하기 전에 무엇을 준비해야 하나요?
“주문·재고·보충 추적 프로세스 설계하기”를 사용하려면 사업 및 재고 모델, 현재 기록과 문제, 제약 조건 및 통제를 준비하세요. 확인할 수 있는 정보로만 자리 표시자를 바꾸세요. 세부 사항을 모른다면 모델에 추론을 맡기지 말고 그 불확실성을 명시적으로 남겨 두세요.
“주문·재고·보충 추적 프로세스 설계하기” 결과는 언제 아직 사용할 준비가 되지 않은 상태인가요?
제공된 증거로 명시된 결과물인 ‘기록, 수식, 역할, 알림 및 테스트 사례를 갖춘 실용적인 재고 관리 프로세스’를 아직 만들어 내지 못했거나, 해결되지 않은 가정, 누락된 승인 또는 지어낸 세부 사항에 의존한다면 결과를 사용할 준비가 되지 않은 것입니다. 점검 항목을 공개 기준으로 삼고, 근거 없는 결과물을 다듬는 대신 원본 입력을 수정하거나 권한 있는 검토자를 지정하세요.
“주문·재고·보충 추적 프로세스 설계하기”에 대해 테스트 기록이 있는 AI 도구는 무엇인가요?
2026-08-28 기준으로 “주문·재고·보충 추적 프로세스 설계하기”의 공개 테스트 기록에는 ChatGPT가 포함되어 있습니다. 이는 실행 기록이 있다는 뜻일 뿐, 이후 제품 버전과의 호환성이나 동일한 결과를 보장하지 않습니다. 다른 도구나 버전을 사용할 때는 모든 제약 조건을 명시한 채 사용 전에 결과 점검 항목을 다시 확인하세요.