SAP 운송 요청: 운송장(TR)을 수입 및 수출하는 방법

⚡ 스마트 요약

SAP 전송 요청은 개발 시스템에서 이루어진 모든 변경 사항을 QA 및 프로덕션 환경으로 이동할 수 있는 컨테이너로 패키징합니다. 표준 흐름은 생성 → 릴리스(내보내기) → 가져오기 → STMS 및 SE01을 통한 로그 및 반환 코드 확인입니다.

  • 📦 TR을 컨테이너로 취급하세요: 모든 TR은 하나 이상의 작업을 포함하며, 작업은 상위 TR의 일부로만 전송됩니다.
  • 🔖 명명 패턴을 알아두세요: 케이 (예: DEVK900030)은 고정되어 있으며 관리자에 의해 절대 수정되지 않습니다.
  • 🗂️ 적합한 유형을 선택하세요: 워크벤치 요청은 클라이언트 간 저장소 객체를 전달하고, 사용자 정의 요청은 클라이언트별 설정을 전달합니다.
  • 🚚 내보내기용 릴리스, STMS 가져오기: TR을 릴리스하면 내보내기가 시작되고, STMS 또는 SE01 가져오기 큐를 통해 QAS 및 PRD 환경으로 이동합니다.
  • 🤖 로그 분류에 AI를 활용하세요: AI 비서는 TR 로그를 설명하고, 반환 코드 0/4/8/12+를 분류하며, 수입이 실패할 경우 다음 단계를 권장합니다.

SAP 전송 요청 구조

운송 요청이란 무엇입니까?

A 전송 요청(TR) 변경 요청이라고도 하는 이 문서는 프로젝트에 적용된 변경 사항들을 모아놓은 컨테이너 또는 모음입니다. SAP 개발 시스템에는 변경 유형, 전송 목적, 요청 범주 및 변경 사항이 적용될 대상 시스템이 기록됩니다.

각 TR에는 하나 이상의 변경 작업이 포함되어 있습니다. 작업 TR은 이동 가능한 변경 사항의 최소 단위입니다. TR은 그 안에 있는 모든 작업이 완료, 릴리스 또는 삭제된 후에만 릴리스할 수 있습니다. TR을 폴더로, 작업을 그 안에 있는 파일로 생각하면 이해하기 쉽습니다.

태스크는 단일 사용자가 수정한 객체들의 목록입니다. 각 태스크는 정확히 한 명의 사용자에게 할당되지만, 하나의 TR(Transfer Request)에는 여러 사용자의 태스크가 포함될 수 있습니다. 태스크는 단독으로 전송될 수 없으며, 항상 TR의 일부로 전송됩니다.

전송 요청 명명 규칙

전송 요청은 관리자가 수정할 수 없는 고정된 패턴을 사용합니다.

<SID>K<Number>
  • SID — 시스템 ID (예: DEV).
  • K — 고정된 키워드/글자.
  • 번호 — 900001부터 시작하는 순열입니다.

예: DEVK900030해당 TR 내의 작업들은 동일한 규칙을 따르며, 순차적으로 번호가 매겨집니다. DEVK900031, DEVK900032, 등등.

SAP 전송 요청 구조

전송 요청의 소유자는 누구입니까?

  • 프로젝트 관리자 또는 지정된 책임자는 작업 요청서(TR)를 작성하고 각 프로젝트 구성원에게 그 안에서 작업을 할당합니다.
  • TR 소유자는 TR에 기록된 모든 변경 사항을 관리하며, 소유자만이 TR 자체를 릴리스할 수 있습니다.
  • 프로젝트에 배정된 각 구성원은 자신의 작업 부분이 완료되면 직접 작업을 공개할 수 있습니다.

운송 요청 소유권

전송 요청 유형

워크벤치 요청 — 저장소 객체와 클라이언트 간 사용자 정의 객체를 포함합니다. 이러한 TR은 변경 사항을 담고 있습니다. ABAP 워크벤치 프로그램, 함수 모듈, 사전 객체 및 화면과 같은 객체.

요청 맞춤화 — 클라이언트별 사용자 정의 객체를 포함합니다. 이러한 전송 요청(TR)은 사용자가 사용자 정의 설정을 수행할 때 자동으로 기록되며, 전송 계층(정의된 경우)에 따라 대상 시스템이 자동으로 할당됩니다.

SE01 — 운송 관리 도구 (확장 보기)

SE01 운송 관리 도구 확장 보기

변경 요청 생성

변경 요청은 두 가지 방법으로 생성할 수 있습니다.

  • Automatic — 사용자가 객체를 생성하거나 수정하거나, 사용자 지정 설정을 수행할 때 SAP 사용자에게 새 요청을 생성할지 또는 기존 요청에 변경 사항을 첨부할지 묻는 대화 상자를 표시합니다.
  • Manual — 전송 관리 도구(SE01 또는 SE09)를 열고 필요한 속성을 사용하여 요청을 생성한 다음 전송할 객체를 삽입합니다.

다음에서 변경 요청을 작성하세요. SAP

전송 요청(내보내기 프로세스)을 릴리스합니다.

  • SE01에서 TR 이름(또는 작업 이름) 위에 커서를 놓고 클릭합니다. 해제 아이콘(트럭 아이콘).
  • SAP 릴리스된 TR 레코드를 정의된 모든 대상 시스템의 가져오기 대기열에 자동으로 추가합니다. TMS.
  • 요청을 릴리스하고 가져오면 Basis 팀에서 나중에 검토할 수 있는 내보내기 및 가져오기 로그가 자동으로 생성됩니다.

다음에서 운송 요청 릴리스 SAP

가져오기 프로세스

TR을 가져오면 변경 사항이 대상 시스템(일반적으로 QAS, 그 다음 PRD)으로 이동합니다.

  • TR을 릴리스하면 지원 자동으로 QA 또는 프로덕션 환경으로 승격시키려면 명시적인 가져오기 단계가 필요합니다.
  • 수출이 완료되면, SAP 해당 내용을 작성합니다 공동 파일 데이터 파일 운영체제 수준의 공통 전송 디렉터리에 항목을 추가합니다. 수입 Buffer (OS 화면) / 가져오기 대기열 (SAP 대상 시스템의 애플리케이션 뷰입니다.
  • 가져오려면 거래를 여세요. STMS → 가져오기 버튼을 누르거나 선택하세요. 개요 → 수입.
  • STMS는 현재 전송 도메인에 있는 모든 시스템과 각 가져오기 큐에 대기 중인 요청 수 및 상태를 나열합니다.

가져오기 대기열 — 공통 디렉터리에 있으며 대상 시스템으로 가져올 준비가 된 TR 목록입니다. SAP 애플리케이션에서는 이를 가져오기 큐(Import Queue)라고 부르고, 운영체제 수준에서는 가져오기(Import)라고 부릅니다. Buffer.

STMS의 가져오기 프로세스

수입현황

가져오기 대기열의 마지막 열에는 표준 상태 아이콘이 표시됩니다. 이 아이콘은 "가져오기 준비 완료", "경고와 함께 가져오기 완료", "가져오기 성공", "가져오기 중 오류 발생"과 같은 상태를 나타냅니다.

가져오기 상태 아이콘

Cofile과 Data 파일이 운영 체제에 존재하더라도 요청이 가져오기 대기열에 자동으로 추가되지 않으면, TR 이름을 알고 있는 경우 수동으로 추가할 수 있습니다. 경로는 다음과 같습니다. STMS → 가져오기 대기열 → 추가 기능 → 기타 요청 → 추가.

가져오기 대기열에 요청을 수동으로 추가합니다.

수입 내역

시스템에 저장된 이전 가져오기 내역은 다음을 통해 모두 확인할 수 있습니다. STMS → 가져오기 개요 → 가져오기 내역이력에는 각 TR이 언제, 누구에 의해, 그리고 어떤 반환 코드로 가져와졌는지 나와 있어 감사 및 사고 조사에 유용합니다.

운송 수입 내역

운송 기록 및 반환 Codes

전송이 실행된 후 Basis 관리자는 모든 데이터가 올바르게 전송되었는지 확인해야 합니다. SAP 두 가지 로그 유형을 표시합니다. SE01 → 이동 → 운송 기록:

  • 액션 로그 — 실행된 작업 목록(내보내기, 테스트 가져오기, 가져오기, 배포 등)을 표시합니다.
  • 전송 로그 — 각 단계에서 생성된 전송 로그 파일의 내용을 기록합니다.

로그에서 가장 중요한 정보는 다음과 같습니다. 반환 코드:

반환 코드 의미
0 수출입 거래가 성공적으로 완료되었습니다.
4 경고는 발령되었지만 모든 물품은 무사히 운송되었습니다.
8 경고가 발령되었고, 최소 한 개의 물품이 운송에 실패했습니다.
12 이상 심각한 오류가 발생했습니다. 이 오류는 대개 요청 자체와는 무관한 문제입니다(시스템 수준 문제, 역할 누락, 네트워크 오류).

키 SAP 운송 T-코드

아래 표는 전송 요청 작업 시 사용하게 될 가능성이 높은 모든 트랜잭션 코드를 요약한 것입니다.

T 코드 목적
SE01 운송 관리 도구 - 전체 검색 및 릴리스 기능을 갖춘 확장 보기
SE09 운송 관리 도구 — 사용자의 요청 및 작업을 사용자 중심의 관점에서 보여줍니다.
SE10 운송 관리 도구 - 사용자, 상태 또는 날짜 범위별 개요.
STMS 운송 관리 시스템 - 개요, 수입, 유통.
STMS_IMPORT 시스템의 가져오기 대기열에 직접 접근할 수 있습니다.
SE03 전송 관리 도구 - 시스템 변경 옵션, 삭제, 복구.

운송 요청 처리 모범 사례

다음과 같은 습관을 따르면 TR 파이프라인을 깔끔하고 감사 가능하게 유지할 수 있습니다.

  • 논리적 변경 1건당 하나의 TR: 관련 있는 객체들을 함께 묶되, 관련 없는 기능 영역들을 혼합하지 않도록 하십시오.
  • Descript요청 텍스트: 간략한 텍스트 입력란에 티켓 번호, 업무 사유 및 대상 시스템을 기록하십시오.
  • TR을 릴리스하기 전에 릴리스 작업을 수행하십시오. TR은 그 안에 있는 모든 작업이 해제되거나 삭제된 후에만 해제될 수 있습니다.
  • 제품 출시 전 QAS에서 테스트하십시오. 항상 QAS로 가져와서 검증한 후에만 PRD로 가져오십시오.
  • 반품 코드를 확인하십시오: 반환 코드 4보다 높은 모든 코드는 결함으로 간주하여 조사한 후 다음 단계로 진행하십시오.
  • 가져오기 순서를 유지하세요: 순서에 따른 오류를 방지하기 위해 TR을 출시된 순서대로 가져옵니다.

자주 묻는 질문

TR(작업 컨테이너)은 시스템 간을 이동하는 컨테이너입니다. 태스크는 해당 TR 내에서 사용자가 담당하는 작업의 일부를 나타냅니다. 태스크는 단독으로 이동할 수 없으며, 상위 TR과 함께 이동합니다.

워크벤치 요청에는 프로그램, 함수 모듈, 사전 구조와 같은 클라이언트 간 저장소 객체가 포함됩니다. 커스터마이징 요청에는 SPRO 및 기타 커스터마이징 트랜잭션을 통해 구성된 클라이언트별 구성 값이 포함됩니다.

아니요. TR이 릴리스되면 해당 내용은 고정됩니다. 추가 변경 사항은 새로운 TR로 패키징해야 합니다. SE01은 상태가 이미 "릴리스됨"인 TR에 객체를 추가할 수 없습니다.

반환 코드 8은 경고가 발생했으며 하나 이상의 객체 전송에 실패했음을 의미합니다. 전송 로그를 열어 실패한 객체를 찾고, 근본 원인을 수정한 후 요청을 다시 가져오십시오.

코파일은 전송 내용과 종속성을 설명하는 제어 파일이고, 데이터 파일은 실제 객체 페이로드를 저장합니다. 두 파일 모두 전송 요청이 릴리스될 때 운영 체제 수준의 공유 전송 디렉터리에 기록됩니다.

STMS에서 가져오기 대기열을 열고 대상 TR을 선택한 다음 요청 → 가져오기를 선택합니다. 순서에 주의해야 합니다. 나중에 가져온 TR이 이전에 가져오지 않은 요청의 객체에 의존하는 경우 순서가 맞지 않으면 가져오기가 실패할 수 있습니다.

AI 어시스턴트는 운송 로그를 분석하고, 반환 코드를 분류하고, 고장 발생 품목을 찾아내고, 다음 조사 단계를 제안합니다. 또한 품목 중복을 기반으로 승격 전에 TR 순서 충돌을 예측합니다.

예. AI 비서에게 TR 객체 목록과 간단한 텍스트를 입력하면 영향을 받는 모듈, 위험 요소 및 롤백 메모가 포함된 사람이 읽기 쉬운 변경 요약을 생성하여 배포 티켓에 바로 사용할 수 있도록 합니다.

이 게시물을 요약하면 다음과 같습니다.