返信ありがとうございます！

「条件分岐処理プラグイン」の「自動行追加」を教えて頂きありがとうございます。
レコード追加の際に、自動で必要な行数を追加するところまで出来ました。
実は、日報の項目として、[ホイストの番号][製品]の他に[作業時刻]がありまして、
テーブル化すると作業時刻に「レコード登録時の時刻を初期値にする」が使えなくなる事に気が付きました。

テーブル化して行自動追加の場合
　ホイストNoを入力する必要は無いが、作業時刻は手入力になる

１ホイスト１レコードの場合
　作業時刻は「レコード登録時の時刻」を初期値にするので入力不要だが、ホイストNoが手入力になる

どちらかで担当へ打診してみます。
同時に、工場長さんからアドバイス頂いたように、ホイストNoの登録がそもそも本当に必要か！？は改めて問いたいと思います。

皆さま、多方面からアドバイス頂きありがとうございました。

そうですか！
「条件分岐処理プラグイン」には

DATE_FORMAT　と
ＮＯＷ　　　　　と いう関数があります

これを、自動入力の欄　計算式で使うと
自動入力されると思うのですが．．．
テーブルの中で試したことがないので
断定できませんが試してみる価値があると思います

現在時刻から時分を取得
DATE_FORMAT(NOW(),"H:i")

ご参考まで

追記－－－🙇ｽﾐﾏｾﾝ m(__)m
テーブルの中では使えないようです

作業時刻は手入力になる

小生、ふゆきさんご提案の「条件分岐処理プラグイン」は使っていない（使えない）ので、詳細は把握していませんが、
1.日報アプリに［作業開始］旨のボタンを設け、
2.そのボタン押下で、「しかるべきフィールドにNOW()を反映した行を自動追加する。」仕組みを入れ込む。
とすれば、キレイに（ほぼ自動で）繋がると思うのですが…

見当違いであればすみません。

ｽﾐﾏｾﾝm(__)m

一覧ボタン押下時に実行

という動作パターン　設定を試したのですが
やはり、テーブルの中では動作しないみたいです

カスタマインではテーブルの中でも動作するでしょうか？

カスタマインではテーブルの中でも動作するでしょうか？

gusuku COSTOMINEでは、対象行・セルを特定してゴニョゴニョするアクションが色々と用意されていますので、本件で言えば「最新行（追加された最終行）の［作業開始］欄一択でNOW()を放り込む」などは比較的容易にできるかと。

１．テーブルデータを取得し、
２．テーブル行数を取得する（これは標準機能でもイケそうです。）などして最新行を特定し、
３．所望のセルに”のみ”NOW()を放り込んだテーブルデータを上書きする。

というようなロジックになりますかね。

小生の場合、「テーブルの所望のセルにCOSTOMINEで生成したPDFを添付する」ということは実現済みです。

ちなみに

一覧ボタン

とは、標準機能で用意されているボタン（一覧画面でテーブルを開く▼ボタン）のことを指すのでしょうか。

CUSTOMINEでもこのボタン押下の検出はできないようです。
小生がイメージしたのは、「CUSTOMINEで生成したボタンをレコード詳細画面またはレコード編集画面のフォーム領域外に配置する。」です。

条件分岐処理プラグインでは
一覧表画面でしか釦を作成できません

なので、デフォルトの「保存」釦が

［作業開始］旨のボタンを設け

の代用させる形かと思いますが
テーブルの中で、ＮＯＷ関数は
どちらも動作しませんでした

条件分岐処理プラグインでは
一覧表画面でしか釦を作成できません
なので、デフォルトの「保存」釦が［作業開始］旨のボタンの代用させる形

諸々理解しました。

CUSTOMINEでは、「保存した直後に○○を実行する」みたいなアクションもありますので、別ボタンを設けなくても、見かけ上デフォルトの「保存」ボタンをトリガにすることはできるのですが…

何とか動作できるようにしてみたくなりますねぇ

ご提示の式

DATE_FORMAT(NOW(),"H:i")

って、テーブルの全行のターゲットセルに同じ式が入ったものと等価と理解してよいのでしょうか。

であれば、
・NOW()関数はテーブル外に配置したダミーフィールド（仮にAとします。）に今の日時を入力するだけに使用し、
・これまたテーブル外に配置したテーブル行数を入れるフィールド（仮にBとします。）を用意して、
・何らかの方法で行に連番を振ることができたとして、（ココがが新たな課題となりますが…）
・ターゲット列に「もし自身の行がB値（＝最終行番号）だったらA値を表示し、そうでなければ自身のセル値を再表示する。」旨の式を一律書く。

というのはいかがでしょうか。

自動計算が走り出すときのトリガ条件（状態遷移）が、例えば「編集画面を開いたとき」なのであれば、見かけ上詳細画面の鉛筆アイコンを代用とできるのでは？との見立てです。

Seal777さん
夜遅くまでコメント返信ありがとうございました。

結論から申し上げますと
この頁に記載されていた（証拠画像 添付）
https://kintone.tis2010.jp/docs/plugins/branchprocess/ja/

DATE_FORMAT(NOW(),"H:i")

がNGでした．．．

但し、ＮＯＷだけで動作させると、どんな条件を付けても
テーブルの中では全ての行が、現在時刻となり諦めました。

Seal777さんのいう通り
もっと、条件の工夫を すれば上手くいくかもしれませんが
今回のアプリでは、時刻ﾌｨｰﾙﾄﾞのﾃﾞﾌｫﾙﾄ初期値設定で
目的を達成する事を確認できた為、ﾃﾞﾌｫﾙﾄの利用が最善と
考えております。

あ～、見落としました

DATE_FORMAT関数を入力すると、指定した形式で日付を文字列にすることが出来ます。

だからだったんですね、
ﾌｨｰﾙﾄﾞの属性を間違えていました　ｽﾐﾏｾﾝ m(__)m

色々と検証頂きまして大変ありがとうございます。
先ほど内容を確認させて頂いたのですが、私の理解不足があり、解決策が見えておらず…
すみませんが、いまの私の理解を添付致しますので、誤理解している点を教えてください！
何度も手を動かして検証して頂いたようで、大変感謝しております！

ちょっと教えてください。

ライン毎のホイストって、制御盤のボタンか何かでほぼ一斉スタート・一斉停止ですよね？
でもって、日報は作業者⇔”ライン”の関係性ですよね？

そもそも論になるかと思いますが、ホイスト毎に別々の時間フィールドを持たせる意味は何なんでしょうか。

稼働時間を積算していって、ホイストのメンテ時期を知りたい…みたいなことでしょうか。

作りたいのは”作業者（もしくはライン）の日報”ですよね？
であれば、（ホイストはほぼ一斉スタート・一斉停止という前提ですが、）テーブル外に時間フィールド１つを配置で済んでしまうような気がします。

ｽﾐﾏｾﾝm(__)m

最初の相談の中に、「時刻」がなかったので
pluginを利用して、必要数のテーブルを準備する
という提案をしましたが、「時刻」がある以上
この提案は撤回させてください

理由＝「数値」と「時刻」の入力を比べた時
　　　圧倒的に「時刻」を自動入力させた方が良い
　　　と考え

更に「製品情報」はテーブルの中のほうが
　　　圧倒的に 良いと思います

【時刻のﾃﾞﾌｫﾙﾄ初期値であれば、ﾃｰﾌﾞﾙの中でも動作】

なので、ﾎｲｽﾄ№の自動入力（＝ﾃｰﾌﾞﾙの準備）提案
は撤回させていただきました

もちろん、Seal777 さんの普段利用している
plugin...カスタマインで実証してみて、両立できるのであれば
カスタマインの利用をお勧めします
（自分はカスタマインの利用できません 　ｻﾞﾝﾈﾝ m(__)m　）

理由＝「数値」と「時刻」の入力を比べた時
　　　圧倒的に「時刻」を自動入力させた方が良い

理解しました。
確かに、時刻を手入力する方が面倒なので、
どちらかを選択するなら返信頂いたような判断になると思います。
ありがとうございます！

そもそも論になるかと思いますが、ホイスト毎に別々の時間フィールドを持たせる意味は何なんでしょうか。

すみません。実務上の具体的な必要性については詳しく聞いておらず、何となく、製造現場でよくあるトレーサビリティ用だとぼんやりと理解していました。
が、仰る通り、さほど役に立たないかも？という気もします。
そもそもの要否をもっと掘り下げるべきでしたね…。
実務の解像度が荒いまま仕組み側で何とかしようという状態になっており反省しきりです。
コメントありがとうございます。

返信ありがとうございます！

ラインごとに使う番号は決まっていますが、一意には決まらず…
以下のようなイメージです。

ラインA　ホイスト10台あり、1番から10番を順に使う。全部終わったら1に戻る
ラインB　ホイスト13台あり、1番から13番を順に使う。全部終わったら1に戻る
ラインC　ホイスト6台あり、1番から6番を順に使う。全部終わったら1に戻る
…

ホイストの全体像をよく知らず、条件反射的に書き込みしてしまってすみません。

複数ホイスト／１ラインの構成なのですね。

以下、少し詳しくご教示ください。

全部終わったら1に戻る

とは、

ホイストNo. vs. ホイストS/Nは始業時に割り当てられ（始業時の状態で一意に決まり）、ライン稼働中はその並びが入れ替わることはなく、終業時に１番のホイストが基点に戻る（基点に戻す）。

という理解でよろしいでしょうか。

であれば、
1. 「ラインNo.⇔ライン構成設備」アプリを「ライン毎のホイストS/Nの並び」みたいな作りにし、
2. 日報アプリを始業時（日報記載時）に１番のS/Nをキーにしてホイスト並びを持ってくるような作りにする。
とすれば、前出のアプリ構成で、かつ、１番のホイストS/Nを取得するだけで全てを繋げられるかと。

※（御社のご事情もありますので、強くオススメするものではありませんが、）設備個々を特定できるもの（例 型番やS/N）をキーにした管理にすれば、別にホイストNo.を割り当てるなどといったことも不要にできる。
※設備のS/N管理にすれば、終業時にホイストの並びを既定に戻すことも不要（とできるかもしれません）。
※ホイストS/Nの取得には、RFタグ／QRコードリーダー／バーコードリーダーなどを使えば、より簡単に入力できる。
ということも付け加えておきます。

ご参考になれば幸いです。

すみません。
前投稿の訂正と補足です。

※設備のS/N管理にすれば、終業時にホイストの並びを既定に戻すことも不要（とできるかもしれません）。

↓

※設備のS/N管理にすれば、終業時に１番の位置を基点に戻すことも不要とできる（かもしれません）。
　「ラインが動き出す直前に基点位置のS/N”だけ”を取得（並びは別アプリにおまかせ）」する運用ですので、休憩などでラインストップした後の再開時、基点のS/N”だけ”を入れてやることで、詳細な運行記録に繋げるといったこともできると思います。

1. 「ラインNo.⇔ライン構成設備」アプリを「ライン毎のホイストS/Nの並び」みたいな作りにし、

こちらのアプリの構成がイメージできていないのですが、設備ごとのシリアル番号を使用する順で登録しておくようなアプリのイメージでしょうか。
確かに、シリアル番号で管理出来れば、改めてこちらで別の番号を付与するような必要もないのかも知れません。
コメントありがとうございます。
参考にさせて頂きます！

設備ごとのシリアル番号を使用する順で登録しておくようなアプリのイメージでしょうか。

その通りです。（イメージ図添付します。）

返信ありがとうございます。

・製品とホイスト番号を紐づける必要がある理由
・昼勤・夜勤でホイストを番号1の物に戻す理由(勤務毎にホイスト自体を手で回して戻している？)

ここの深堀りが足りていないことに気が付きました…。なぜ必要か回答できないので、必要性を現場担当へ確認してみます。

・現状のホイスト番号はドロップダウンからの手入力でしょうか
・使うホイストがずれたりして連番がイレギュラーで飛ぶことは全くないでしょうか

作成中のアプリでは数値フィールドの手入力にしています。
イレギュラー時の運用は、A4縦の紙の日報を使っていて、各行にあらかじめ1から13まで繰り返すように番号が印刷されています。イレギュラーでずれたりした場合は、その番号の行に斜線を引いて使っているようです。

詳細が分かりましたらまたコメントさせて頂きます。ありがとうございました。