TMS / EDI / EDI 204

EDI 204

1. 기본 정보

항목	내용
작성자	이샘미
최초 작성일	2025-12-29
최종 변경일	2025-12-29

2. 요약 및 산출물

요약

EDI 204 정보를 다운로드하고, 해당 데이터를 기반으로 승인 또는 거부 처리 후 EDI 990을 전송합니다. 또한, TMS에서 Work Order를 생성하기 위해 데이터를 수정할 수 있으며, 관련 문서를 PDF 형태로 생성할 수 있습니다.

주요 산출물

배치 작업
배치 작업을 통해 EDI 204 정보가 포함된 JSON 파일을 다운로드하고, 해당 데이터를 DynamoDB에 저장합니다.
EDI 204 목록 조회 API
```
GET edi/204
```
EDI 204 개별 데이터 조회 API
```
GET edi/204/{wo_number}/{ts}
```
EDI 204 수정 API
```
PATCH edi/204/{wo_number}/{ts}
```
EDI 204 승인 API
```
PATCH edi/204/{wo_number}/{ts}/accept
```
EDI 204 거부 API
```
PATCH edi/204/{wo_number}/{ts}/decline
```
EDI 204 문서 생성 API
```
GET edi/204/{wo_number}/{ts}/pdf
```

3. 타당성

기존 방식 대신 EDI 204를 통해 Delivery Order를 수신하고, 이를 기반으로 Work Order를 생성할 수 있습니다.

4. 기술 설명

Workflow

graph TB
  A[EDI 204 Received]
  A --> B[원본 EDI 기반 주요 데이터 추출]

  B --> C[데이터 구조화]

  C --> D[DynamoDB 저장]

  D --> E{데이터 수정 필요?}

  E -->|Yes| F[필드 수정]
  F --> G[데이터 업데이트]
  E -->|No| H[EDI 204 검토]

  G --> H

  H --> I{결정}

  I -->|Decline| J[상태 변경 거부]
  I -->|Accept| K[상태 변경 수용]

  J --> L[EDI 990 Decline 송신]

  K --> M{updated_flag}

  M -->|N| N1[신규 Work Order 생성]
  M -->|U| N2[기존 Work Order 업데이트]
  M -->|C| N3[기존 Work Order 취소]

  N1 --> O[EDI 990 Accept 송신]
  N2 --> O
  N3 --> O

EDI 210 영향

EDI 204의 처리 흐름에 따라 EDI 210 Workflow에 영향이 미칩니다. 자세한 내용은 EDI 210 페이지를 참고해주세요.

DynamoDB 설계

이름	설명	비고
wo_number	EDI 204의 고유 식별자	Partition Key
ts	데이터 생성 기준 Unix timestamp	Local Sort Key, `SenderIndex`의 Sort Key
billto	Customer 정보
div	Division 정보
wo_no	TMS의 Work Order 번호
freedays	Freedays 수
freedays_type	Freedays 유형
remarks	메모
po_locatgion	주문 위치
dliv_location	배송 위치
rtn_location	반납 위치
ssl	선사 코드
size	컨테이너 크기
type	컨테이너 타입
unit	단위
sender	송신자 정보	`SenderIndex`의 Partition Key
file_name	SFTP에서 수신한 파일명
status	`EdiStatusEnum`으로 표현된 EDI 204 상태
edi_info	수신된 EDI 정보
created_date	데이터 생성 일시
updated_date	데이터 수정 일시
updated_by	데이터 수정자
update_flag	`wo_number`에 대한 Transaction 상태 코드

EDI 204 목록 조회 시, SenderIndex를 사용하여 필터링을 진행합니다.

배치 작업

배치 작업을 통해 사전에 합의된 SFTP 서버 정보에 기반하여 파일명이 204로 시작하는 JSON 파일을 다운로드합니다.
수신된 파일 정보는 별도의 가공 없이 edi_info에 그대로 저장하며, 해당 내용을 기반으로 TMS에서 Work Order를 생성할 수 있도록 필요한 주요 데이터를 추출하여 DynamoDB에 저장합니다.

EDI 204 Status Changes

배치 작업으로 수신된 EDI 204를 DynamoDB에 저장할 때, status를 PENDING으로 설정합니다.
검토 후 승인 또는 거부를 결정하며, 승인 시 ACCEPT, 거부 시 DECLINE 상태로 변경됩니다.

EDI 204 목록 조회를 위한 Query

요구사항에 따르면 Division과 Sender별로 EDI 204 목록을 확인할 수 있습니다. 이를 위해 DynamoDB EDI 204 테이블에 SenderIndex를 설정하였습니다. 해당 PK는 데이터가 계속 누적되므로, DynamoDB의 특성에 맞춰 아래와 같이 구현하였습니다.

DynamoDB Query 결과 용량 제한

DynamoDB Query의 결과는 최대 1MB로 제한되며, 이 용량을 넘어서는 경우 자동으로 Pagination이 발생합니다.

EDI 204 목록 조회 일부

filtered_204 = []
last_key = None

while True:
    query_kwargs = {
        'IndexName': 'SenderIndex',
        'KeyConditionExpression': (
            Key('sender').eq(sender)
            & Key('ts').between(start_ns, end_ns)
        ),
        'FilterExpression': Attr('div').eq(div_instance.seq),
        'ScanIndexForward': False
    }

    if last_key:
        query_kwargs['ExclusiveStartKey'] = last_key

    response = dynamo_204.query(**query_kwargs)
    filtered_204.extend(response.get('Items', []))

    last_key = response.get('LastEvaluatedKey')
    if not last_key:
        break

EDI 204 개별 데이터 수정

배치 작업을 통해 EDI 204 데이터를 DynamoDB에 저장하기 전에, TMS에서 Work Order를 생성할 수 있도록 주요 데이터를 추출합니다. 다만 추출되지 않았거나 업무상 수정이 필요한 경우에는, 필요한 데이터 항목에 한해 수정할 수 있습니다.

Flag 기반 EDI 204 승인 처리

EDI 204는 동일한 woNumber를 기준으로 서로 다른 updateFlag 값을 가진 데이터가 여러 번 전송될 수 있습니다.
updateFlag 값에 따라 승인 시 처리 방식이 달라집니다.
EDI 204의 updateFlag는 N, U, C 세 가지 유형으로 구분됩니다.

UpdateFlag	의미	처리 내용
`N` (New)	신규	새로운 Work Order를 생성합니다.
`U` (Update)	수정	기존에 생성된 Work Order를 조회한 후, 전달받은 최신 정보로 내용을 업데이트합니다.
`C` (Cancel)	취소	기존에 생성된 Work Order에 AP/AR 정보가 없는 경우, 해당 Work Order의 `deleted` 값을 True로 변경합니다.

Work Order를 통한 EDI 204 검색 방법

EDI 204 승인으로 새로운 Work Order가 생성될 경우, ref_no 필드에 EDI의 woNumber 값을 설정합니다.
이를 기준으로 Work Order의 wo_no와 ref_no를 사용하여 DynamoDB에서 관련 EDI 204를 검색할 수 있습니다.

5. 위험성 평가

현재 TMS에서는 ref_no 필드를 수정할 수 있습니다. ref_no가 변경될 경우, EDI 204를 통해 생성된 Work Order임에도 불구하고 관련 EDI 204 데이터를 찾지 못할 수 있습니다.

이 문제를 방지하기 위해, 향후 EDI를 통해 생성된 Work Order를 구분할 수 있는 별도의 식별 필드를 도입하고, 해당 경우에는 ref_no 수정이 불가능하도록 제한한다면 보다 안정적인 운영이 가능할 것으로 판단됩니다.

🧩 추가 정보

-