스카이플래너 데이터 구조 #
타임로그에 대해 자세히 알아보기 전에 Skyplanner의 데이터 구조와 내부 작동 방식에 대해 잠시 살펴볼 필요가 있습니다. 이 모든 내용은 나중에 설명하겠습니다.
주문/작업지시/작업 데이터를 Skyplanner에 통합했다면 최소한 이러한 API 엔드포인트를 사용했을 가능성이 높습니다:
- 페이저 주문
- 페이저-순서-행
- 페이저 작업
실제로 이러한 엔드포인트에 삽입된 데이터는 다음과 같이 Skyplanner UI에 표시됩니다:
Skyplanner에 주문을 삽입한 후에는 해당 주문을 생산 스케줄링 모듈로 내보내야 합니다(UI 또는 /phaser-orders/export-endpoint를 통해 수행할 수 있음):
주문을 내보낼 때 Skyplanner는 한 데이터베이스 테이블에서 다른 데이터베이스 테이블로 주문 데이터를 효과적으로 복사합니다. 따라서 예를 들어 /phaser-orders -엔드포인트를 통해 무언가를 변경하는 경우, 생산 스케줄링에서 업데이트하려면 데이터를 다시 내보내야 합니다. 이는 또한 생산 스케줄링 창에 표시되는 주문에 액세스하려면 다른 API 엔드포인트를 사용해야 한다는 의미이기도 합니다!
“변경된” 엔드포인트는 다음과 같습니다:
- /단계별 주문 → /주문
- /phaser-order-rows → /order-rows
- /페이저 작업 → /jobs
timelogs -엔드포인트를 사용하여 프로덕션 이벤트 등을 기록할 때는 프로덕션 스케줄링 -엔드포인트에 있는 관련 엔터티를 사용해야 하므로 이 점을 알아두는 것이 중요합니다 !
예를 들어, 새 타임로그를 게시하려면 production_planning_job_id (다시 말하자면 /jobs -엔드포인트에서 액세스하는 엔티티입니다)가 필요합니다:
phaser-jobs -endpoint 중 하나에서 필요한 production_planning_job_id를 찾을 수 있습니다:
또는 /job -엔드포인트에서:
REST-API를 사용하여 타임로그 만들기 #
API를 통해 스카이플래너에 타임로그를 작성하는 것은 UI에 있는 것과 동일한 규칙과 시스템을 사용합니다. 따라서 API를 통해 사용하기 전에 UI의 시스템 작동 방식을 숙지하는 것이 도움이 될 수 있습니다.
타임로그 기본 사항 #
스카이플래너에는 네 가지 타임로그 이벤트 유형이 있습니다:
- shift_begin
- 일시 중지됨
- 계속
- shift_end
Shift_begin-event는 작업이 처음 시작될 때 전송됩니다. 각 작업에 대해 두 개 이상의 shift_begin 이벤트를 보내지 마세요!
일시 중지 – 이벤트가 작업을 일시 중지합니다.
계속-이벤트는 일시 중지된 작업을 재개합니다.
Shift_end를 누르면 작업이 완료됩니다. 각 작업에 대해 두 개 이상의 shift_end 이벤트를 보내지 마세요!
타임로그에 필요한 데이터입니다:
- person_id
- people-endpoint에서 찾을 수 있습니다.
- user_id와 동일하지 않습니다!
- 계획된_워크스테이션_ID
- 작업 중인 워크스테이션
- 워크스테이션-엔드포인트에서 찾을 수 있습니다.
- 날짜_시간
- 이벤트가 완료된 시점
- 형식 2024-01-01 10:30:11
사용 중인 외부 시스템의 어떤 스카이플래너 타임로그가 타임로그에 연결되는지 지정하려면 external_id 필드를 사용하면 됩니다. 예를 들어 이 ID를 사용하여 GET 요청을 하면 Skyplanner에서 특정 타임로그를 찾을 수 있습니다.
작업 시작 #
이와 같은 POST 요청을 API에 전송하여 작업을 시작할 수 있습니다:
타임로그에 대한 POST 데이터를 설정할 때 workshift_id를 0으로 설정하고 timelog_finalized를 true로 설정합니다.
작업 일시 중지하기 #
다음과 같이 POST 요청을 보내 작업을 일시 중지합니다:
일시 중지된 유형의 타임로그에서는 양과 오류 금액을 설정할 수 있습니다. 타임로그 유형과 날짜_시간도 참고하세요.
작업 계속하기 #
일시 중지된 타임로그를 계속하는 방법은 다음과 같습니다:
shift_end 이벤트에 의해 종료된 작업을 계속 진행하려고 하면 오류가 발생한다는 점에 유의하세요.
작업 종료 #
다음은 shift_end 타임로그로 작업을 종료하는 방법입니다:
shift_end-events에서는 paused-events에서와 마찬가지로 amount 및 faulty_amount 값을 지정할 수 있습니다. 실행 중이 아닌 작업에 shift_end-event를 수행하려고 하면 오류가 발생합니다.
타임로그 업데이트 #
타임로그 데이터를 업데이트하려면 다음과 같이 /timelogs-endpoint에 PUT 요청을 보내면 됩니다:
업데이트를 수행하려면 startTimelog와 endTimelog 데이터가 모두 설정되어 있어야 합니다. 스카이플래너의 타임로그는 다음과 같이 저장됩니다. 각 “전체”(시작과 끝이 모두 있는 타임로그(예: shift_begin/continued & paused/shift_end) 타임로그에는 시작과 끝을 위한 별도의 엔티티가 있습니다.
이들은 endlog에서 발견되는 begin_id 값으로 쌍을 이룹니다. 위의 예에서 startTimelog의 id 값은 1이며, 따라서 endTimelog의 start_id 값은 1입니다.
또한 변경하지 않더라도 업데이트 요청을 할 때마다 person_id 및 endTimelog 값을 제공해야 합니다.
타임로그를 수행하는 다른 방법 #
다음은 API를 사용하여 작업에 로그인할 수 있는 몇 가지 다른 방법입니다.
Logfull #
시작 및 종료 타임로그를 모두 단일 요청으로 보내려면 다음과 같이 /timelogs/log-full -endpoint를 사용하면 됩니다:
여기서 금액이 전송되는 방식에 유의하세요. 첫 번째 ‘금액’ 값은 오류 금액을, 두 번째 값은 금액을 나타냅니다. 이 요청은 시작로그와 종료로그 엔티티를 하나의 요청에 생성합니다.
퀵로그 #
작업에 “퀵로깅”을 적용하면 한 번의 요청으로 작업을 완료하고 완료된 제품 수량을 주문 항목에 설정된 값과 일치하도록 설정합니다. 퀵로깅은 /timelogs/quick-log -엔드포인트를 사용하여 수행됩니다:
여기에는 프로덕션_계획_작업_ID, 계획된_워크스테이션_ID , 사람_ID만 입력하면 됩니다. 시간과 금액 값은 자동으로 채워집니다. 또한 퀵로그된 작업은 항상 shift_end-event로 완료되므로 퀵로그 이후에는 더 이상 로깅할 수 없습니다!
