---
title: タイムログ
description: "#### スカイプランナーのデータ構造 タイムログに入る前に、Skyplanne…"
url: "https://skyplanner.ai/ja/docs/%e3%82%bf%e3%82%a4%e3%83%a0%e3%83%ad%e3%82%b0/"
updated: "2025-10-07"
category: 統合
tags:
  - API
  - 統合
---

# タイムログ

#### スカイプランナーのデータ構造

タイムログに入る前に、Skyplannerのデータ構造とその仕組みについて少し説明しましょう。これらはすべて後ほど説明します。

Skyplannerに注文/作業指示/仕事のデータを統合している場合、少なくともこれらのAPIエンドポイントを使用している可能性が高いです：

- フェーザー・オーダー
- フェザー順序列
- フェイザー・ジョブズ

事実上、これらのエンドポイントに挿入されたデータは、スカイプランナーのUIでこのように表現されます：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-25-1024x714.png)
**図1.** オーダー（フェイザーオーダー）

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-26-1024x715.png)
**図2.** 注文項目 (phaser-order-rows (赤)), プロセスステップ (phaser-jobs (緑))

Skyplannerにオーダーを挿入した後、**それらを**Production Schedulingモジュールに**エクスポート**します（これはUIまたは/phaser-orders/export-endpointから行うことができます）：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-27-1024x596.png)
**図3.** UIからエクスポートする

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-28-1024x597.png)
**図4.** 生産スケジューリングでエクスポートされた注文

オーダーをエクスポートする際、Skyplannerはオーダーデータを1つのデータベーステーブルから別のテーブルへ効果的にコピーします。そのため、例えば/phaser-orders-endpointで何かを変更した場合、Production Schedulingで更新するためにデータを再度エクスポートする必要があります。これは、プロダクションスケジューリングウィンドウに表示されるオーダーにアクセスするために、異なるAPIエンドポイントを使用しなければならないことも意味します！

変更された」エンドポイントは次のようになる：

- /phaser-orders → /orders
- /phaser-order-rows → /order-rows
- /フェイザージョブズ → /ジョブズ

なぜなら、/timelogs -エンドポイントを使ってプロダクション・イベントなどを記録する場合**、Production Scheduling -エンドポイントにある関連エンティティを使用しなければならないから**です！

例えば、新しいタイムログをPOSTするには、**production_planning_job_idが**必要です（もう一度言いますが、production_planning_jobsは/jobs -endpointからアクセスされるエンティティです）：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-29.png)
**図5.** タイムログPOSTリクエスト

必要なproduction_planning_job_idは、/phaser-jobs -endpointから見つけることができます：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-30.png)
**図6.**PhaserジョブのGETリクエスト (赤はphaser_job_id。**タイムログでは使用しないで**ください)

または/job -endpointから：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-31.png)
**図7.** /ジョブGETリクエスト

#### REST-APIを使ったタイムログの作成

APIを通してSkyplannerにタイムログを作成する場合、UIと同じルールとシステムを使用します。そのため、APIで使用する前に、UIでシステムがどのように機能するのかを理解しておくとよいでしょう。

##### タイムログの基本

Skyplannerには4つのタイムログイベントタイプがあります：

- シフト開始
- 休止中
- 続き
- シフト・エンド

Shift_begin-eventは、ジョブが初めて開始されるときに送られる。 **各ジョブに対して1つ以上のshift_beginイベントを送信しないでください！**

Paused-eventはジョブを一時停止する。

Continued-eventは一時中断していた仕事を再開する。

Shift_endで終了。 **各ジョブに対して1つ以上のshift_endイベントを送信しないこと！**

タイムログに必要なデータ：

- パーソンID
  - people-endpointから見つけることができる。
  - user_idとは異なる！
- 計画ワークステーションID
  - 作業を行うワークステーション
  - workstations-endpointから見つけることができる。
- 日時
  - イベントが行われた時点
  - フォーマット2024-01-01 10:30:11

Skyplannerのタイムログと、使用している外部システムのタイムログを紐付けるには、**external_id**フィールドを使用します。例えば、Skyplannerから特定のタイムログを見つけるために、このidを使ってGETリクエストを行うことができます。

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-32-1024x438.png)
**図8.** タイムログの外部ID

#### 仕事を始める

APIにこのようなPOSTリクエストを送ることで、ジョブを開始することができる：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-33.png)
**図9.** シフト_開始タイムログ

タイムログのPOSTデータを設定する際、**workshift_idを**0、**timelog_finalizedを** **trueに**設定する。

#### ジョブの一時停止

以下のようなPOSTリクエストを送信して、ジョブを一時停止する：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-34.png)
**図10.** タイムログの一時停止

一時停止タイプのタイムログでは、**金額と** **faulty_amountを**設定することができる。また、タイムログの**タイプと** **date_timeにも**注意してください。

#### 仕事の継続

ここでは、一時停止したタイムログを継続する方法を説明します：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-35.png)
**図11.** タイムログの続き

shift_endイベントによって終了したジョブを継続しようとすると、エラーが発生することに注意してください。

#### 仕事の終了

以下は、shift_end timelogによるジョブの終了方法である：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-36.png)
**図12.** シフト終了タイムログ

shift_end-eventsでは、paused-eventsと同様に**amountと** **faulty_amountの**値を指定することができます。実行されていないジョブに対してshift_end-eventを実行しようとすると、エラーが発生することに注意してください。

#### タイムログの更新

以下のように、/timelogs-endpointにPUTリクエストを送ることで、タイムログデータを更新することができます：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-37.png)
**図13.** タイムログの編集

更新を行うには、**beginTimelogと** **endTimelogの**両方のデータがセットされている必要があります。Skyplannerのタイムログはこのように保存されます：それぞれの "full"（開始と終了の両方を持つタイムログ）タイムログ（例：shift_begin/continued & paused/shift_end）には、開始と終了のための個別のエンティティがあります。

endTimelogの**begin_idと**endTimelogの**begin_idは**対になっている。上の例では、beginTimelogのid値は1なので、endTimelogの**begin_id**値は1になります。

また、**person_idと** **endTimelogの**値は、変更しない場合でも、更新リクエストのたびに指定する必要があります。

#### タイムログの代替方法

APIを使用して求人にログインする別の方法をいくつか紹介します。

##### ログフル

タイムログの開始と終了の両方を1回のリクエストで送信したい場合は、**/timelogs/log-full**-endpointを次のように使用します：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-38.png)
**図14.** ログフル・リクエスト

最初の "amount "値は**故障金額を**表し、2番目の "amount "値は**金額を**表す。このリクエストは、beginlogとendlogエンティティを1つのリクエストで作成する。

##### クイックログ

「クイックログ "は1回のリクエストでジョブを完了させ、完了した商品の量を注文アイテムに設定された値と一致させます。クイックログは**/timelogs/quick-log**-endpointを使って行われます：

![](https://skyplanner.ai/wp-content/uploads/2025/03/image-39.png)
**図15.** クイックログ

ここでは、**production_planning_job_id**、**planned_workstation_id**、**person_idのみを**指定すればよいことに注意してください。時間と金額の値は自動的に入力されます。また、quicklogされたジョブは常にshift_end-eventで完了するため、quicklog後にそれ以上のログを記録することはできないことに注意してください！