ミュートした投稿です。
私の場合は、プロセス管理を設定したワークフローアプリでは、カスタマインを活用して標準ではできない様々なカスタマイズを行っています。 実際に自社で活用している1例ですが、添付のようにステータス変更時のタイムスタンプを自動取得したり、自動取得のフィールドの説明として(?)マークに吹き出しのコメントを追
ご回答ありがとうございます。 契約先についてマスタを作ることも当初考えていました。 ただ、大規模案件が多く、同一企業から案件をもらうことも稀だったりします。 ルックアップを作っても、マスタが増えすぎると、標準仕様だとかえって検索しづらいと考えて手入力にしています。 (同一企業でも案件によって担当者
お問い合わせされていることに直結するものではございませんので、 その点お許しください。 ※直接的なお答えは、かなさん始めとしてご助言されていますので。 アプリの構成を拝見すると、ほとんどのフィールドに対し、 都度都度の入力が必要になるとお見受けします。 今後のことを考慮すると、 例えば、「契約先(発
<現在の取り組み> 社内でスモールスタートとして、各部署から「興味がある方」「新しいことに抵抗がない方」にアカウントを配布し、月に1度の勉強会を開催しています。これまでに2回開催しており、内容は以下の通りです。 1回目:kintoneとは(特徴や活用事例、画面の見方など) 2回目:アプリの作り方(ル
食品工場です。 kintoneはスタンダードコースです。 商品の製造時、材料投入のチェックをkintoneで行っています。 レシピ管理アプリ(さまざまなレシピを登録)と、材料投入チェックアプリがあり、材料投入チェックアプリでレシピ管理レシピの該当データを読み込むと、サブテーブルにその商品のレシピが
こんにちは。 これは、データモデリングの知識が必要な案件かもしれません。 元データの下記2種類のファイルには「カード番号」の様な共通のキーはありますか? ・各ETCカードの利用明細csv ・各ETCカードの利用金額と割引金額と請求額(利用金額ー割引金額)csv もし共通のキー項目があれば、以下の
こんにちは。 「従業員それぞれの保持資格と取得日を入れるアプリ」(仮に資格保持アプリ)を 1人1資格で1レコードにすれば、①は基本機能で可能です。 ②ですが、資格詳細アプリ側に「例」のようなデータをあらかじめ持っておいて、 資格保持アプリからのルックアップでまとめてデータをもってくれば 計算式や
こんにちは。 これは、RDBの「買い物モデルで」構築すると良いかもしれません。 買物モデルは、顧客マスタ、商品マスタ、買物履歴の3つのテーブルを使用します。 同じように、資格管理アプリも、従業員マスタ、資格マスタ、資格履歴アプリの3つで運用します。 (下図をご参照) 資格履歴アプリに、従業員番
こんばんわ!(日を跨いでしまった) > 弊社も同じような運用 ナカーマ! 現場主導がkintoneの価値だと思っています。その分ガバナンスに苦悩するのですが… また、当社も取引先マスタは基幹と連携しています。 実は元々基幹を主でkintoneにデータを渡していたのを、kintoneを主に
おはようございます。 >各部署で必要なアプリはそれぞれの担当者が作成しています。 弊社も同じような運用をしています。 >ルックアップの「関連付けるアプリ」は【顧客リスト】、 >[コピー元のフィールド]が「会社名」になっているケースがチラホラ。 弊社も同様に[コピー元のフィ