きっかけ：静かなオフィス、荒ぶる全社会議の日 普段のオフィスは、正直がらんどう。固定席もないし、来客も少ない。「今日はどこ座ろうかな」くらいの、のどかな世界。 ところが全社会議の日。 リモート勤務のメンバーが一斉に出社し、開場と同時に始まる椅…

はじめに ちょっとDX事例からそれるけど、これはこれで現場の困った事例を挙げてみますね。 1. まず、現場で何が起きたのか ある月末のこと。 経理「今月の支払、だいたいこのくらいです」 社長「“だいたい”じゃなくて、来月の資金繰りを見たいんだよ」 経理…

「承認が遅いんです」は、だいたい誰のせいでもない ある日、業務部門からこんな話を聞きました。 「承認フローがとにかく遅くて…月末になると全部詰まるんですよね」 よくある話です。でもここで不思議なのが、 承認者がサボっているわけでもない フロー自…

ある日の雑談から始まった たまたま経理の女性と話す機会がありました。雑談の流れで、最近の業務効率化の話に。 「最近、何か頼まれて作ってるものあるんですか？」 すると、少し困った顔でこう返ってきました。 「経理主任から、仕入れ先から請求書のメー…

正直な出発点 予算と実績は、たぶん完全には合わない 予算表と実績データを扱っていると、最初からこう思ってました。 どうせ全部は合わない 部門も科目もズレる 最後は人が直す なので今回も、 きれいに一致させることは目標にしない という前提で始めまし…

とっかかり：品質問題は、ある日突然やってくる 品質問題は、いつも静かに始まる。 クレームが少し増える 手戻りが多くなる 「前はこんなミスなかったよね」が増える そして、たいていその少し前に、熟練者が一人、会社を去っている。 ある日、経営層から出…

はじめに：この一言がすべてだった DX案件が失敗する瞬間は、だいたい派手じゃない。 エラーも出ない。怒号も飛ばない。 ただ、ぽつりと置かれた一言で終わる。 今日の締め新システムだとたぶん終わらないです この言葉が出た瞬間、プロジェクトは静かに死ん…

今回はケーススタディで行ってみます。 登場人物 自分（IT部門 主任） 現場と経営の翻訳家。 無茶振りを受けるたびに「これは事故か？」を瞬時に判断してしまう癖がある。 上司（部長） IT知識ほぼゼロ。悪気なし。 だが「とりあえず聞いてみて」が多い。 社…

はじめに（導入） NetSuiteで支払請求書（Vendor Bill）を運用していると、こんな声、聞いたことありませんか？ 「承認依頼、来てたの気づかなかった」 「誰で止まってるのか分からない」 「結局Slackで催促してる」 うちの現場もまさにこれでした。承認フロ…

キャッシュアウト予測を出すと、必ずこの瞬間が来ます。 「……足りない」「全部は払えない」 今回は、NetSuite上の情報だけを使って“何を止めるか”をどう判断できるかを、実際に試したログとして整理します。 今回の実験テーマ 止める／止めないの判断軸 NetS…

支払承認フローを作ると、次に必ずこう聞かれます。 「これ、証跡として使えるの？」「監査のとき、何を見せればいい？」 今回は、NetSuiteに残る「支払承認ログ」を、監査対応で実際にどう使えるのかを実験してみました。 今回の実験テーマ 支払承認ログは…

支払承認フローを作った直後は、だいたいこう思います。 「これで勝ちだ」「もう勝手に払われることはない」 でも、運用を回し始めると“普通にすり抜ける”事故が起きます。 今回は、実際に起きやすい「承認フローすり抜けパターン」をNetSuiteで再現してみた…

支払予定日を入れ始めると、次に必ず出てくる要求があります。 「この支払、本当に今払っていい？」「誰がGO出したのか分からないのが怖い」 今回は、支払予定日を判断軸にした支払承認フローをNetSuiteで実際に作って、どう使えるかを試しました。 今回の実…

支払請求書（Vendor Bill）が増えてくると、金額よりも先にこう思うようになります。 「これ、いつ払うんだっけ？」「月末に払うやつと、来月でいいやつが混ざってる」 今回は、支払予定日（Due Date）を軸に支払請求書を管理すると、NetSuite上で何が変わる…

支払請求書（Vendor Bill）が増えてくると、必ずこうなります。 「1件ずつ支払ってられない」「月末にまとめて振り込みたい」 今回は、複数の支払請求書を1回の支払でまとめて処理すると、NetSuiteの中で何が起きるのかを、実際に試したログとして残します。…

一部支払をやると、次に必ずこう思います。 「金額、ちょっと間違えたな」「この支払請求書、消したいんだけど…」 今回は、 一部支払後に 支払請求書を削除するとどうなるか 金額を修正できるのか どこまで戻れて、どこから戻れないのか を 実際に試したログ…

支払請求書（Vendor Bill）から支払まで理解すると、次に必ず出てくるのがこのケースです。 「今回は全部は払わない」「月末だから一部だけ先に払う」 今回は 一部支払を実際にやってみて、 何が残るのか 何が確定するのか どこで詰みやすいのか を整理しま…

発注 → 入庫 → 返品 → ベンダークレジットここまで来て、発注サイドの最後に残るのがこの工程です。 「支払請求書を作ったあと、何をしたら“支払った扱い”になるのか？」 今回は、NetSuite日本語UI（支払請求書＝Vendor Bill）前提で、 支払請求書を作った状…

仕入先返品・返品クレジットまで一通り触ると、次に出てくるのがこの疑問です。 「で、どの仕入先が問題なんだっけ？」 今回は、 NetSuiteにすでにあるデータだけで 無理なカスタマイズをせず 実務で“使える切り口”として 返品が多い仕入先を見抜く方法を試…

仕入先返品を作ると、在庫は減ります。でも次に必ず出てくる疑問がこれです。 「で、お金はいつ戻った扱いになるの？」 今回は、 仕入先返品をしただけでは何も戻らない理由 お金が戻る“本当のトリガー” 実務で混乱しやすいポイント を 実験ログ形式で確認し…

入庫数量を間違えたとき、「入庫を削除できない」「会計が確定している」――そんな場面で登場するのが 仕入先返品 です。 今回は、 仕入先返品を実際に作ってみた 販売返品（返品請求書）と何が違うのか 在庫・会計・履歴がどう動くのか を 実験ログ形式でま…

発注書 → 入庫まで理解すると、次にほぼ確実に起きるのがこれです。 「あ、入庫数量入れ間違えた」「10来たと思ってたけど、実際は8だった」 今回は、 入庫数量を間違えたときにどうなるか どこまで修正できて、どこから戻れないかを実際に試しました。 今回…

前回の記事では、発注書は在庫を増やす“予定”でしかない、というところまで確認しました。 今回はその続きとして、 実際に入庫すると何が起きるのか 出荷と何が同じで、何が違うのか を 実際の操作ログで確認します。 今回のゴール 入庫の基本挙動を理解する…

これまでの記事では、受注・出荷・請求・返品と「数量が減っていく世界」を見てきました。 今回からはその逆、「数量が増えていく世界＝発注サイド」に入ります。 まずは基本中の基本、 発注書（Purchase Order）を実際に作ってみて 受注（Sales Order）と何…

返品が多い業務で重要なのは、「正しく処理すること」よりも 「同じ返品を繰り返さないこと」ですよね。 NetSuiteでは、返品請求書・返品理由・数量・金額といったデータが すでに全部揃っています。 今回は、 どのデータを見るべきか どう切り出すか 何が分…

これまでの記事で分かったことがあります。 返品は受注の進捗を戻さない 再出荷は同じ受注ではできない 実績を消す思想はない つまり、返品が頻発する業務で“普通の受注設計”をすると必ず破綻するということです。 今回は、 返品が前提の業務 現場が混乱しな…

前回の記事では、クレジットメモは受注を戻さないという点を確認しました。 ここで次の疑問が自然に出てきます。 「返品された商品を、もう一度同じ受注で出荷できる？」「新しい受注を作る必要がある？」 今回は、 返品済みの商品を そのまま再出荷してみて…

分割請求までできるようになると、次に必ず起きるのがこの場面です。 「請求書、間違えたから消したい」「金額だけ直したいんだけど、受注はどうなる？」 NetSuiteでは請求書と受注は別レコードですが、数量・金額は密接につながっています。 今回は実際に …

前回の記事では、NetSuiteで一部請求（分割請求）ができることを確認しました。 ここまで来ると、次に必ず出てくる疑問があります。 「先に一部請求したけど、出荷はどう扱われる？」「出荷を先にした場合と何が違う？」 今回は、 分割請求と出荷を組み合わ…

受注から請求書を作れるようになると、次に必ず出てくる要望がこれです。 「今回は半分だけ請求したい」「先に一部請求、残りは後日で」 NetSuiteで一部請求（分割請求）ができるのか？実際にやってみました。 今回やること（ゴール） 1つの受注から 一部だ…