コンテンツにスキップ
J2 ドキュメント（社内）

J2 のしくみと機能の地図

一言で： J2 は「2つの入口（ポータル）」と「1つの受付（API ゲートウェイ）」、その裏で分担して働く「16の部門（サービス）」でできています。データはバイヤー・サプライヤー・カタログモールで分けて保管され、AWS 上で動いています。このページは、技術者でない方が「J2 はどこで、どう動いているか」を説明できるようになるためのものです。

1. 全体の形

Section titled “1. 全体の形”
flowchart TB
    subgraph U["利用者"]
        B["バイヤー企業の社員"]
        S["サプライヤー企業の担当者"]
        P["ジーニー（プロバイダー）"]
    end
    subgraph FE["2つの入口"]
        BP["バイヤーポータル"]
        SP["サプライヤーポータル<br/>プロバイダー管理・モール管理"]
    end
    GW["受付（API ゲートウェイ）<br/>ログイン確認・不正な入力の遮断・記録"]
    subgraph SV["16の部門（サービス）"]
        direction LR
        S1["購買<br/>見積・発注・承認・支払"]
        S2["サプライヤー<br/>受注・納品"]
        S3["カタログモール"]
        S4["マスタ・会社・ユーザー"]
        S5["共通の道具<br/>ファイル・メール・通知<br/>レポート・定期処理・検索"]
    end
    subgraph DB["保管庫（データベース）"]
        D1["バイヤーのデータ"]
        D2["サプライヤーのデータ"]
        D3["カタログモールのデータ"]
        D4["共通マスタ"]
    end
    B --> BP
    S --> SP
    P --> SP
    BP --> GW
    SP --> GW
    GW --> SV
    S1 --> D1
    S4 --> D1
    S2 --> D2
    S3 --> D3
    S5 --> D4

覚えておくこと：

  • 入口は2つ。 バイヤー企業は「バイヤーポータル」、サプライヤー企業とジーニー側は「サプライヤーポータル」側の画面を使います。URL の先頭（j2. と bizhiway.）で見分けられます。→ 利用者と3つのポータル
  • 受付は1つ。 画面からの操作はすべて API ゲートウェイを通ります。ここでログイン状態の確認と、不正な入力の遮断、通信の記録を行います。
  • 中は分担制。 「購買」「サプライヤー」「カタログモール」「マスタ」「共通の道具」といった単位で、独立したサービスが分担して処理します。ある部分の不具合や保守が、他の部分に波及しにくい作りです。
  • データは分けて保管。 バイヤー企業のデータ、サプライヤー企業のデータ、カタログモールのデータは別々の保管庫にあります。さらに SSOL 系統と DAIKO 系統では保管庫そのものが別です。→ SSOL 系統と DAIKO 系統

たとえば「発注する」ボタンを押したとき、裏では次のように動きます。

sequenceDiagram
    participant U as 利用者の画面
    participant G as 受付（API ゲートウェイ）
    participant S as 担当の部門（購買サービス）
    participant D as 保管庫（バイヤーのデータ）
    U->>G: 「発注する」を押す
    G->>G: ログイン状態を確認・不正な入力を遮断・通信を記録
    G->>S: 購買サービスへ渡す
    S->>D: 発注データを保存
    D-->>S: 保存完了
    S-->>G: 結果
    G-->>U: 「発注しました」と表示

2. どこで動いているか

Section titled “2. どこで動いているか”
項目内容
場所AWS（Amazon が提供するクラウド）。サービス群は Kubernetes（サービスを自動で配置・再起動する仕組み）の上で動く
リージョン東京。大阪にも環境があり、テスト用途と災害対策のどちらの位置づけかは担当者に確認（両方の記述がある）
ファイル添付ファイル（見積書・契約書など）は AWS S3 に保管
環境開発・テスト・ステージング・本番など10環境。→ 環境一覧
系統SSOL 系統（.jienie.com）と DAIKO 系統（.jienie.jp）の2系統を、同じ製品で並行運用

3. ログインとセキュリティ

Section titled “3. ログインとセキュリティ”
仕組み利用者から見えること
ID・パスワードでログインバイヤーポータルは「会社グループコード + ユーザーID + パスワード」、サプライヤーポータルは「ユーザーID + パスワード」
SSO（シングルサインオン）会社の ID 基盤でログインしたい顧客向けに SAML（企業向けの標準的な認証連携方式）の SSO を用意。会社ごとの設定で、全顧客が使うわけではない
ログインの種類標準・Lion（特定顧客向け）・サプライヤー・プロバイダーの4種類の入口がある
セッションログイン状態は一定時間で切れ、自動で延長される。長時間放置すると再ログインが必要
記録誰が・いつ・何をしたかは操作履歴として残る。外部連携の通信はログ確認画面で見られる。→ 操作履歴・監査証跡
削除しないデータは「削除」しても実際には消えず、削除済みの印が付くだけ。過去の記録は追跡できる

ログイン方法とアカウントの申請先は アカウントとロール にまとめています。

4. 機能の地図 — 中心の流れと5つの周辺機能

Section titled “4. 機能の地図 — 中心の流れと5つの周辺機能”

J2 の中心は「見積 → 発注 → 納品 → 検収 → 支払締め」の購買の流れです。その周りに、役割の違う5つの機能のまとまりがあります。

flowchart TB
    CORE["📋 中心：購買の流れ<br/>見積・発注・承認・検収・支払締め"]
    CM["🛒 カタログモール<br/>カタログから選んで買う"]
    PO["🔗 外部カタログ連携（PunchOut＝パンチアウト）<br/>外部サイトで選んだ商品を J2 の注文に"]
    SUP["🏭 サプライヤーポータル<br/>見積回答・受注・納品"]
    RC["📊 Report Center<br/>実績の集計・出力"]
    SC["⏰ 定期処理（スケジュール）<br/>通知・同期・締め処理の自動実行"]
    CORE <-->|"発注 ↔ 受注"| SUP
    CORE -->|"カタログから購入"| CM
    CM -->|"外部サイトと接続"| PO
    CORE -.->|"実績データ"| RC
    CM -.->|"注文データ"| RC
    SC -.->|"自動処理"| CORE
    SC -.->|"自動処理"| CM
    SC -.->|"自動処理"| SUP
機能のまとまり何をするか主に使う人詳しく
カタログモール価格が決まった商品をカタログから選んで注文する。モールサプライヤーが出品し、モールマスターが審査する申請者、モールサプライヤー、モールマスターカタログモール 概要
外部カタログ連携（PunchOut）ミスミ・モノタロウなど外部のカタログサイトで商品を選び、そのまま J2 の注文に取り込む。業界標準の cXML という約束事で接続申請者PunchOut 概要
サプライヤーポータルサプライヤー側の見積回答・受注確認・納期回答・納品。バイヤーの発注が、サプライヤーには受注として届くサプライヤーの担当者サプライヤーの受注・納品
Report Center（レポート機能）購買・支払・サプライヤー実績を集計し、Excel 等に出力する。読み取り専用で、データを変更することはない購買担当者、経理、管理者Report Center
定期処理（スケジュール）メール通知、外部システムとのデータ同期（SFTP、会計システム連携など）、締め処理、後片付けを決まった時刻に自動で行うジーニー側・会社管理者Schedule サブシステム

これらに加えて、在庫管理（入庫・出庫・棚卸）が購買の流れにつながっています。

5. 「共通の道具」の役割

Section titled “5. 「共通の道具」の役割”

画面の裏で、複数の機能から共通で使われる仕組みです。問い合わせ対応で名前が出ることがあります。

道具役割利用者への影響
メール承認依頼・見積依頼・受注などの通知メールを送る「メールが届かない」の問い合わせはここが起点
通知ポータル内の通知欄に表示する
ファイル添付ファイルのアップロード・ダウンロードサイズや形式の制限はここで決まる
検索カタログモール商品の全文検索。外部カタログとの横断検索もここ検索結果に出ない商品の問い合わせはここが起点
レポートReport Center の集計処理
定期処理上記の自動実行夜間バッチの結果が翌朝反映される、など

6. よくある質問

Section titled “6. よくある質問”

Q. バイヤーポータルとサプライヤーポータルはなぜ分かれているのか。 使う人・見せてよい情報・画面の作りが大きく違うためです。裏側の受付（API ゲートウェイ）とサービスは共通で、同じ取引データを違う視点で見ています。

Q. 「サービスが落ちた」と聞いたら、全部止まるのか。 分担制なので、止まった部分だけが使えなくなることが多いです。どの機能に影響しているかを確認して、担当者に伝えてください。

Q. お客様ごとにプログラムが違うのか。 基本は同じプログラムで、会社ごとの設定（機能の有効／無効、承認ルートなど）で見え方が変わります。ただし Lion 向けには専用の変種があります。→ SSOL 系統と DAIKO 系統

Q. 削除したデータは戻せるのか。 実際には消えていないため、技術担当が復元できる場合があります。まず担当者に相談してください。

関連ページ

Section titled “関連ページ”