日報の数量をあとから直すと、集計表も変わる?|訂正の反映先を決める開発の考え方

日報の数量を直した。これで終わり、と思っていたら、事務所が持つExcelは前の数字のまま。反対に、集計表を自動更新したら、昨日会議で見た数字と今日の数字が違う。仕事の記録をつなぐときは、入力を一度にするだけでなく、後から訂正した一件をどこまで届けるかも考えたいところです。

社長は正しい数字を見たい。現場は気づいた間違いをすぐ直したい。事務所は、すでに出した表の説明が急に変わると困る。この三つは矛盾しているようで、記録の役割を分ければ両立を考えられます。今回は、日報や伝票から集計・帳票を作る仕組みを頼む前に、訂正の反映先を整理する方法を説明します。

「元を直せば全部正しくなる」とは限らない

一つの数量が、元の日報、工事別の一覧、月次集計、出力したExcelやPDFへ使われることがあります。元の記録を直せても、別ファイルへ出した数字までは自動で変わらない場合があります。一方、すべてを常に再計算する仕組みなら、以前に確認した結果まで変わることがあります。

必要なのは、全部連動させるか、全部手で直すかの二択ではありません。今の状況を見るための一覧と、ある時点で確認して渡した帳票を分けることです。同じ数量を使っていても、前者は最新の内容を見たい。後者は、誰がどの内容を確認して受け取ったかをたどれる必要があります。

画面に「更新しました」と出ても、訂正の仕事が終わったとは限りません。どの記録を直し、どの一覧に反映し、出力済みのファイルについて何をするか。開発を相談するときは、入力画面の保存だけでなく、その先まで一件として見ます。

建築の日報の例:最新の一覧と、会議へ出した表を分ける

以下の二つの場面は、仕組みを考えるための仮定例です。B.I.Yの顧客の運用や、導入で得られた成果を紹介するものではありません。

建築会社で、日報の取付数量をもとに現場別の作業量をまとめているとします。確認後、日報に「5本」と入れた箇所が実際は「6本」だったと分かりました。その一件は、日々見る作業量の一覧にも、先週の会議へ出したExcelにも使われています。

日報の確認者が根拠を確かめて数量を訂正したら、現在の作業量一覧は更新したいところです。ただ、会議へ渡したExcelを同じ名前で置き換えるだけでは、前に説明した合計がいくつだったか分からなくなります。社長が前回の数字と比較するときも、訂正による差なのか、新しい仕事が増えた差なのかを区別しにくくなります。

この場合は、元の日報の番号、訂正前後の数量、確認した人と時点を対応させ、最新の一覧へ反映します。会議用の表は、そのとき渡した版として残し、必要なら訂正版を別の版で作る方法が考えられます。全社の数字を固定するのではなく、最新を見る場所と、過去に渡した結果を残す場所を分けるわけです。

どちらの表にも、集計した期間と、どの時点の記録から作ったかが分かる目印を付けます。同じ期間でも、訂正前と訂正後では内容が違います。「最新」という名前だけに頼らず、版や作成日時で見分ける。担当者の記憶に戻らなくても、違った理由を説明できる形を検討します。

日報の数量だけで請求額や工事の評価が決まるとは限りません。ほかの判断に使っているなら、その担当者へ訂正を知らせ、何を見直すかを確認します。集計が変わったから、別の業務の確定内容も自動で変えてよい、とは決めないことが大切です。

卸の伝票の例:在庫を直しても、渡した納品書は別に見る

もう一つは卸業の仮定例です。出荷記録へ20個と入力し、在庫一覧と納品書を作りました。後から、実際に渡した数量は18個で、記録の入力を取り違えていたと分かったとします。これは新たな返品が起きた場面とは区別します。実際の出荷が変わったのか、記録が間違っていたのかで、残すべき情報が違うからです。

訂正の根拠を確認して出荷記録を直す場合、現在の在庫がどう変わるかを確かめます。同じ内容をもう一件の出荷として追加すれば、数量を重ねてしまうおそれがあります。元の出荷のどの明細を訂正するのかが分かり、訂正前後をたどれることが必要です。実際の在庫への反映方法は、自社の数え方と利用する仕組みで確認します。

一方、すでに相手へ渡した納品書は、社内の数量欄を直しただけでは相手の手元まで変わりません。担当者が内容を確認し、連絡や訂正版が必要かを決めます。社内には、最初に渡したものと、訂正後に渡したものを区別して残す方法があります。相手との確認方法や帳票の扱いは、自社の取引条件に沿って決めてください。

ここでは、「在庫一覧は反映済み、渡した納品書の対応は確認中」のように、反映先ごとの状態が分かると仕事を引き継ぎやすくなります。元の画面で訂正済みと出るだけでは、次の担当者が、相手への連絡も終わったと思うかもしれません。一か所の訂正と、その訂正を受けた後の仕事を分ける考え方です。

反映先を三つに分けると、作る範囲が見える

一つ目は、今の状況を表示する一覧です。数量の訂正を確認した後、最新の一覧へ反映する候補になります。元の記録とつながっているか、反映される時点はいつか、更新されていないものを見分けられるかを確認します。

二つ目は、社内で確認を終えた集計です。責任者が一度確認した数字を、訂正のたびに黙って置き換えてよいかを決めます。訂正版を作り、確認者へ差を示す方法もあります。細かな変更すべてに承認を増やすのではなく、使い道と影響に応じて条件を選びます。

三つ目は、外へ渡した帳票やファイルです。以前に渡した内容を残し、訂正が必要なものを担当者へ知らせ、対応済みか分かるようにします。帳票の更新と、相手へ届いたことの確認は別の仕事です。システムから通知を出せても、それだけで対応完了と扱うかは会社で決めます。

訂正する人、根拠を確かめる人、反映先の対応を終える人は、同じとは限りません。社員を疑って記録を増やすためではなく、一人が休んでも残っている仕事を見つけるために分けます。単に操作した人を残すだけで足りるのか、確認者も必要か。どこまで記録するかは、数字の用途と訂正時の負担を合わせて選びます。

例えば社内のメモの言い回しを直すだけなら、全帳票を出し直す必要はないかもしれません。数量や対象案件が変わり、集計結果が変わる訂正は、影響先を確かめます。項目を直すたび全員へ知らせる設計では、通知に埋もれて大事な変更を見落としやすくなります。「何が変わったら、どこへ知らせるか」まで仕事の言葉で決めます。

試作品では、作った後の一件を訂正してみる

開発会社に「変更履歴が欲しい」とだけ伝えると、誰が操作したかの一覧はできても、訂正が集計や帳票へ戻るかは別に残ることがあります。まず一件を入力し、集計と帳票を出した後で、その数量を訂正する流れを試してください。

元の記録の訂正前後を確認できるか。最新の一覧に反映したことが分かるか。確認済みや出力済みの表をどう扱ったか。対応が残る反映先を次の担当者が見つけられるか。この四つを一続きで確かめると、履歴を残す機能と、訂正を届ける機能の違いが見えます。

今のExcelでも、元の記録の番号を集計表に残し、出力した版と訂正一覧を管理すれば足りる場合があります。まず今のソフトに、訂正履歴や帳票の版を扱う機能があるかも確かめます。複数の一覧や外部ソフトへ渡し、毎回別々に打ち直しているなら、連携や部分開発を比較する理由が具体的になります。

すべての反映先を最初から自動化する必要はありません。自社側で帳票を出し直す作業を残すなら、訂正の一覧から対象と担当を追えるようにする。自動で更新する範囲と、人が確認して終える範囲を、見積もりの前に分けます。既存ソフトとの接続可否、支援や改修に含む範囲・費用も個別に確認します。

今日、一つの数量から「どこへ渡したか」をたどる

最近訂正した日報や伝票を一つ選び、元の記録から数字を渡した表を矢印で結んでみてください。今見る一覧、確認済みの集計、外へ渡した帳票に分け、それぞれに訂正を反映する人を書きます。途中で分からなくなったところが、画面を作る前に確かめたい箇所です。

最初から全社の図を完成させなくても大丈夫です。一件について「入力は直せるが、出力したExcelを誰が直すか決まっていない」と言えれば、頼みたい仕事が具体的になります。相談用の見本は、顧客名や個人情報など不要な部分を伏せ、共有する範囲を確認してから用意します。

埼玉県川口市のB.I.Yでは、仕事のつながりを確かめ、必要な部分を作り、使い始めるときの説明や運用中の改善まで相談できる育てるシステム開発をご案内しています。開発から直接相談でき、顧問契約は前提ではありません。支援と改修の範囲・費用は契約ごとに確認します。

公式LINEへ、「日報や伝票を直しても、集計表に戻らない。訂正の反映先を相談したい」と一言お送りください。今の紙やExcelの一件から、どこまでつなぐか整理できます。

LINE Consultation

「うちの仕事も楽になる?」
そのひと言から、LINEでご相談ください。

何を頼めばいいか、決まっていなくても大丈夫です。5年間、顧問として紙やExcelを使う現場に向き合ってきたB.I.Yが、今の仕事を伺い、合う進め方を一緒に考えます。

たとえば、こんなメッセージで大丈夫です

「この記事の内容を、うちの仕事にも使えるか相談したいです。」

公式LINEで相談する 友だち追加 → トークでメッセージを送信 フォームで相談する LINEを使わない方はこちら

友だち追加のあと、困っている仕事をひと言送ってください。

何から始めるか相談したい方へ:顧問・ITサポート 作りたい仕組みがある方へ:システム開発