{"running":null,"status":"tracked","retry":null,"issue_id":"a89d1e38-b3b2-4341-9cd3-32813ad58ff2","workspace":{"path":"/Users/julian/.codex/worktrees/symphony/TEC-52","host":null},"attempts":{"current_retry_attempt":0,"restart_count":0},"issue_identifier":"TEC-52","last_error":null,"logs":{"codex_session_logs":[]},"recent_events":[],"tracked":{"priority":"Low","state":"Ready for Verify","title":"발주작성자와 구매담당자 필드 분리","url":"https://linear.app/tonextchapter/issue/TEC-52/발주작성자와-구매담당자-필드-분리","updated_at":"2026-04-08 09:10 UTC","detail":{"ready_for_verify":"### 2026-04-08\n\nself-review result summary\n현재 diff랑 주변 코드 같이 봤는데 이번 변경 범위에서 크게 걸리는 건 없었어요. `po-management`는 로컬 렌더가 `pdfjs` 런타임 에러로 막혀서 화면 클릭 검증 대신 API 응답으로 `ownerName` 필드가 내려오는 것까지 확인했어요.\n\nscreenshot\n없음 (po-management 로컬 렌더 불안정)\n\ntest urls\n\n* [http://localhost:3000/po-management](<http://localhost:3000/po-management>)\n* [http://localhost:3000/po-inquiry](<http://localhost:3000/po-inquiry>)\n\nverify focus\n\n* `/po-management` 번들 목록이나 다운로드에서 `발주작성자`가 `구매담당자`와 같이 보이는지 확인해 주세요.\n* `/po-management` 상세 항목에서 `구매담당자`를 바꾼 뒤 저장하면 해당 항목의 `buyerName`/`buyerTel`도 같이 바뀌는지 확인해 주세요.\n* `/po-inquiry` 목록과 다운로드에서 `발주작성자` 컬럼명이 노출되고 `구매담당자` 용어가 같이 맞춰졌는지 확인해 주세요.","agent_analysis":"### 요청 요약\n\n* `tblSourcingPO`에는 이미 `ownerName`(발주작성자)와 `sourcingManagerId`(구매담당자)가 따로 있는데, NCOS `po-management` 번들 화면에는 구매담당자만 보여서 둘이 같은 개념처럼 보이고 있어요.\n* 발주 생성 시점에는 `po-dashboard`에서 `ownerName = 작성자`, `sourcingManagerId = 작성자`로 같이 저장돼서, 이후 구매담당자가 바뀌는 케이스를 화면에서 구분하기 어렵습니다.\n\n### 기대 동작\n\n* `/po-management` 번들 목록과 다운로드에서 `발주작성자`를 별도 컬럼으로 보여주고, 기존 `구매담당자`는 그대로 유지합니다.\n* `/po-management` 상세 항목에서 `구매담당자`를 바꾸면 `sourcingManagerId`가 실제 저장되고, Retool과 같게 `buyerName`/`buyerTel`도 같이 맞춰집니다.\n* `/po-inquiry`도 같은 용어(`발주작성자`, `구매담당자`)로 맞추고, 현재 숨겨둔 `ownerName` 컬럼을 운영자가 볼 수 있게 정리합니다.\n\n### 관련 화면/경로\n\n* 화면: `/po-management`, `/po-inquiry`\n* 발주 생성: `web/src/app/api/nextcentury/screens/century/po-dashboard/commands/route.ts`, `web/src/server/services/nextcentury/century/century-po-dashboard.repo.server.ts`\n* 발주 관리 조회/수정: `web/src/app/api/nextcentury/screens/century/po-management/route.ts`, `web/src/server/services/nextcentury/century/century-po-management.service.ts`, `web/src/server/services/nextcentury/century/century-po-management.repo.server.ts`, `web/src/app/(pages)/(nextcentury)/(century)/po-management/ui/PoManagementPageClient.tsx`\n* 발주 조회: `web/src/lib/schema/nextcentury/century/po-inquiry.schema.ts`, `web/src/server/services/nextcentury/century/century-po-inquiry.repo.server.ts`, `web/src/app/(pages)/(nextcentury)/(century)/po-inquiry/ui/PoInquiryPageClient.tsx`\n\n### 재현 방법 또는 근거\n\n* `po-dashboard` 생성 경로가 새 PO insert 시 `ownerName = writerName`, `sourcingManagerId = writerId`로 같이 저장합니다.\n* `po-management` 번들 DTO/테이블은 `sourcingManagerId`만 내려서 구매담당자만 보입니다. `ownerName`은 번들 응답에 없습니다.\n* `po-inquiry`는 `ownerName`을 이미 조회하지만 `ALWAYS_HIDDEN_COLUMN_IDS`에 넣어 숨기고, 헤더도 `담당자`로만 표시합니다.\n* `po-management` 상세 항목 테이블은 `sourcingManagerId` 편집 UI가 있는데, 실제 저장용 `changesets`와 repo `bulkUpdateItems`는 `sourcingManagerId`를 처리하지 않아 변경 가능 요구사항이 완결돼 있지 않습니다.\n* Retool 원본 `saveSSBulkPOChangesets.js`는 구매담당자 변경 시 `buyerName`/`buyerTel`도 같이 갱신합니다.\n\n### 완료 조건\n\n* `po-management` 번들 목록/다운로드에 `발주작성자(ownerName)` 컬럼이 추가되고 `구매담당자`와 동시에 보입니다.\n* `po-inquiry`에서도 `ownerName`을 `발주작성자`로 노출하고 export 라벨을 같은 용어로 맞춥니다.\n* `po-management` 상세 항목에서 `구매담당자` 수정이 실제 저장되고, 관련 연락처 필드(`buyerName`, `buyerTel`)가 같이 동기화됩니다.\n* 기존 DB 컬럼 재사용으로 끝내고 DB migration 없이 마무리합니다.\n\n### 애매한 지점\n\n* `발주작성자`를 새 DB 컬럼으로 만들지, 기존 `tblSourcingPO.ownerName`을 그대로 쓸지 판단 포인트가 있었는데, 생성/복제/비용항목 추가 경로를 보면 이미 `ownerName`이 작성자 역할로 일관되게 들어가고 있어서 기존 컬럼 재사용이 가장 안전하다고 봤어요. 그래서 이번 수정은 DTO/UI 노출과 `구매담당자` 저장 경로 보완까지면 충분하다고 판단했어요. 다만 과거 데이터 중 `ownerName`이 비어 있거나 잘못 저장된 건이 운영에서 발견되면, 그때는 별도 DB 보정 작업만 후속으로 잡으시면 됩니다.","decision_needed":"* 없음","human_notes":"* 없음","human_review_entry":null,"ready_for_verify_test_urls":[],"release":"없음","review_updates":"### 2026-04-08\n\n* 이번 리뷰에서는 크게 손볼 건 없어서 그대로 마무리했어요.\n* 변경한 5개 파일은 `biome lint`로 다시 확인했고, `web` 타입체크도 같이 통과했어요.","rework_request":"* 없음","slack_request":"NCOS에서 현재는 발주자가 자동으로 해당 오더의 담당자로 설정되고 있어, 실제 발주 작성자와 이후 follow-up을 담당하는 구매담당자가 다른 경우 운영상 문제가 발생하고 있습니다.\n\n발주서에 다음과 같이 구분이 필요합니다:\n\n* `발주작성자`: 실제 발주 작성자, 자동 입력, 수정 불가\n* `구매담당자`: 변경 가능\n\n이 구분이 없으면 대체 발주 상황에서 시스템상 PO owner가 실제 구매담당자와 다르게 남아 filtering/pivoting 결과가 부정확해지고, follow-up 누락 위험과 데이터 라벨링 정확도 저하가 발생합니다.\n\n![image.png](https://uploads.linear.app/7c52ab50-7609-4512-9c46-3c8e24ee8e67/cb2004b2-31df-4a96-a930-54fb6bb0e1b5/43fd5328-7da6-4c00-b7ef-7594b5bee3bd?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoiLzdjNTJhYjUwLTc2MDktNDUxMi05YzQ2LTNjOGUyNGVlOGU2Ny9jYjIwMDRiMi0zMWRmLTRhOTYtYTkzMC01NGZiNmJiMGUxYjUvNDNmZDUzMjgtN2RhNi00YzAwLWI3ZWYtNzU5NGI1YmVlM2JkIiwiaWF0IjoxNzc1NDUyMzczLCJleHAiOjE3NzU0NTI2NzN9.cYfOHNKPZJr2NF8p1j9Wp1hQZ5ZojCai_8ctrwMGenI)\n\n![image.png](https://uploads.linear.app/7c52ab50-7609-4512-9c46-3c8e24ee8e67/88daa4a9-3437-4a6c-91a5-fff74f13e9a4/e696be67-dab5-4105-b8a2-a4408b486fc6?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoiLzdjNTJhYjUwLTc2MDktNDUxMi05YzQ2LTNjOGUyNGVlOGU2Ny84OGRhYTRhOS0zNDM3LTRhNmMtOTFhNS1mZmY3NGYxM2U5YTQvZTY5NmJlNjctZGFiNS00MTA1LWI4YTItYTQ0MDhiNDg2ZmM2IiwiaWF0IjoxNzc1NDUyMzczLCJleHAiOjE3NzU0NTI2NzN9.TDeIPCLDyLEi8ZPucJNtexF_sBuMlxjFhceGLVFiQ2Y)\n\n* 요청자: Weiwei Wang\n* 요청일: 2026-03-27\n* Slack 링크: [https://nextchapter-inc.slack.com/archives/C04EFJG5MA7/p1774420710290319?thread_ts=1774420710.290319&cid=C04EFJG5MA7](<https://nextchapter-inc.slack.com/archives/C04EFJG5MA7/p1774420710290319?thread_ts=1774420710.290319&cid=C04EFJG5MA7>)","verify_history":"### 2026-04-08 18:08\n\n* 리뷰에서 반영한 것: 이번 리뷰에서는 크게 손볼 건 없어서 그대로 마무리했어요. 변경한 5개 파일은 `biome lint`로 다시 확인했고, `web` 타입체크도 같이 통과했어요.\n* Ready for Verify: 현재 diff랑 주변 코드 같이 봤는데 이번 변경 범위에서 크게 걸리는 건 없었어요. `/po-management`는 로컬 `pdfjs` 런타임 에러 때문에 화면 클릭 검증 대신 API 응답으로 `ownerName` 필드 노출까지 확인했고, `/po-inquiry`는 화면에서 `발주작성자` 컬럼 노출을 확인했어요."}}}