[SAP ABAP] 판매 오더 결재 프로그램

송의찬·2024년 6월 3일

ABAP 탐험

목록 보기

5/6

필자는 REPORT 프로그램의 주 목적이 데이터를 비교 분석 하기 위함이라고 생각한다. 따라서 필자는 다양한 검색 조건 설정을 통해 사용자 별 다양한 정보를 검색할 수 있도록 만들었다. 해당 프로그램에서는 판매오더 생성일자, 판매 오더 코드, 결재 상태 등등을 통해 데이터를 확인하도록 했다.
개발 서버에서는 데이터 양이 많지 않기 때문에 최대 검색 수 조건 필드가 필요하지 않다. 하지만 운영서버에 넘어가게 된다면 얼마나 많은 데이터가 존재하는지 파악하기 힘들다. 특히, 판매 오더의 경우에는 고객의 예약과 관련된 데이터이기 때문에 DB에 많은 값들이 저장될 수 있다. 때문에 최대 검색 수를 지정할 수 있도록 만들어, 데이터 확인에 용이하도록 구현했다.

EXCUTE 버튼을 클릭하면 조건에 따른 값을 조회할 수 있다. 해당 화면에서는 판매 오더의 결재 상태를 보여준다.
REPORT 화면에서는 액션이 이루어질 때 곧바로 실행되기에 AT SELECTION-SCREEN에서 SY-UCOMM 코드 값에 따라 진행되도록 설계했다.
하나의 행을 선택하고 판매 오더 품목 조회 버튼을 누르면 CALL TRANSACTION을 통해 판매오더 M PROGRAM으로 이동한다. 해당 행의 값을 SAP MEMORY를 활용해 SET 해주고, M PROGRAM에서 GET한 후 SEARCH 액션까지 진행된다.
해당 프로그램에서 진행하지 않고, M PROGRAM으로 넘겨주는 이유는 프로그램은 각각의 목적성에 맞게 구현해야 한다는 필자의 생각 때문이다. 판매오더 결재 상태 조회 프로그램과 판매 오더 CRUD 프로그램은 서로 다른 목적성을 가지고 있다.
판매 오더 결재를 진행하기 위해서는 하나의 행을 선택하고 판매 오더 결재 버튼을 누르게 된다. 판매 오더 결재 상태는 각각 미결, 결재요청, 결재 중, 결재 승인, 결재 반려로 구성된다. 해당 값에 따라 판매 오더 결재 SCREEN을 다르게 구현했다. 앞서 말한 것처럼 목적성에 맞게 활용하는 것이 사용자 만족도를 높이는 좋은 방법이라고 생각하기 때문이다.

해당 화면에서는 SEARCH HELP를 프로그램에서 만들어, 사번 입력시 현재 재직중인 사원만 선택할 수 있게 만들었고, 아직 미결 상태이기 때문에 결재 요청만 이루어질 수 있다. 1차 결재자 및 2차 결재자는 초기 지정된 값으로 설정되어 있고, 변경은 불가하다.

결재 요청 상태에서는 실제 승인 및 반려가 이루어져야 한다. 때문에 CLASS METHOD를 사용해서 ALV에 결재 및 결재 반려 버튼이 생성되도록 설정했다.
하나의 행을 선택하고 사번을 입력하면 결재가 이루어 진다. 2차 결재는 1차 결재가 이루어진 후 가능하고, 이미 1차 결재에서 반려가 되면 2차 결재는 진행되지 않는다. 또한 지정된 결재자와 입력한 사번을 비교해 대리 여부를 판별해 저장된다.

승인 및 반려가 이루어진 판매오더는 수정될 수 없기 때문에, 결재 버튼이 보이지 않는다. 이전에 이루어진 정보만 확인할 수 있다. 만일 해당 화면에서 정보 수정이 가능해진다면, 데이터 품질이 저하 될 뿐더러 해당 데이터를 참조해서 작업을 하고 있는 사용자는 잘못된 데이터를 보는 큰 문제가 발생할 수 있기 때문이다.

수기로 작성하는 작업 과정을 효율적으로 전달하기 위해 결재 프로그램을 개발하며 생각보다 훨~~~씬 더 어려운 작업이라는 것을 깨달았다. 결재 절차, 데이터 보관, 효율적인 처리 등 많은 부분을 생각해야 하고, 한번에 모두 결재가 되지 않도록 만들어야 한다.
이번 프로그램에서는 상태 값에 맞게 버튼을 활성화/비활성화 하는 작업을 진행했다. 화면 구성은 필수적인 것만 보여주면 된다고 판단했기 때문이다. 예를 들어, 결재가 모두 이루어졌다면 정보 확인 목적일뿐, 정보 수정이 이루어지면 안되기 때문이다. 앞으로 개발을 진행할 때도 사용자에 맞게, 목적에 맞게, 흐름에 맞게 개발하려고 노력해야겠다.
결론적으로!! 모든 버튼, 화면 구성에는 이유가 있다!!!!