ネクストエンジンのマニュアルを探すときは、画面名ではなく、まず作業を「受注・ステータス」「在庫」「商品ページ」「アプリ・外部連携」に分けるのが近道です。さらに、利用中のモールやカート、倉庫、追加アプリが関係するかを確認すると、自分の環境に合う手順を選びやすくなります。
先の日付の配達希望注文は「印刷日待ち」で通常出荷と分けられます。在庫連携には時間差があるため、セール時の売り越し対策では確保在庫の区分が必要です。商品更新は受注・在庫連携とは別に対応可否を確認し、標準機能で足りない処理はアプリやAPIの条件まで確認して判断します。
ネクストエンジンのマニュアルを探す前に、業務と連携先を切り分ける
ネクストエンジンの公式マニュアルを探す入口URLと、ログイン後に画面別マニュアルへ進む具体的な導線は、ここで確認できる資料には含まれていません。したがって、特定のURLやメニュー名を断定するのではなく、公式サイトのサポート、FAQ、マニュアル案内から対象を絞る考え方を先に整理します。
手順を探す前に、次の順番で対象を切り分けます。
- 何の業務かを決める。受注処理、在庫管理、商品ページ更新、倉庫・配送・決済連携などに分けます。
- どの注文・商品・在庫を扱うかを決める。通常出荷か、入金待ち・在庫待ち・将来出荷待ちなどの例外かを整理します。
- どの連携先が関係するかを確認する。モール・カート、倉庫、決済サービス、追加アプリを特定します。
- 標準機能か追加機能かを分ける。本体の設定で完結するのか、アプリ、CSV、API、連携先側の設定が必要なのかを確認します。
「在庫を更新したい」のように目的だけで検索すると、在庫管理本体の説明と、特定モールや倉庫の連携手順が混ざりやすくなります。先に対象業務と連携先を決めておくと、同じような名称の手順を選び間違えにくくなります。
標準機能の確認と、アプリ・連携先別の確認を分ける
標準機能のマニュアルは、ネクストエンジン本体で受注・在庫・商品情報をどう扱うかを確認するために使います。一方、モール・カート・倉庫・決済サービスとの接続では、相手側の認証情報、データ項目、同期方法、反映頻度などが別に定められます。
そのため、ネクストエンジンで受注や在庫を扱える連携先でも、商品登録・ページ更新まで対応するとは限りません。連携一覧を見るときは、サービス名だけでなく、受注・在庫・商品登録のどの機能に対応しているかを分けて確認してください。
また、「連携できる」と「自動で処理できる」は同じ意味ではありません。APIによる自動連携、CSVの取り込み・出力、ボタン操作、手動登録では、必要な設定と担当者の作業が異なります。本体の処理を確認した後、対象の連携先やアプリの説明でデータの向き、実行方法、頻度、費用を確認するのが基本です。
受注処理とステータス管理で、通常出荷と例外注文を分ける
ネクストエンジンの受注ステータスは、注文を単に並べ替えるためではなく、出荷してよい注文と、まだ判断・確認が必要な注文を分けるために使います。受注を取り込んだ後、通常出荷へ進めるものと、担当者の確認、入金、在庫、発売日、配達希望日を待つものを区別できれば、誤出荷や確認漏れを防ぎやすくなります。
代表的な状態は次のように考えます。
- 確認待ち：住所や注文内容など、担当者の判断が必要な注文
- 引当待ち：注文に割り当てる在庫が確保できていない注文
- 入金待ち：支払い・与信の確認が終わっていない注文
- 発売日待ち：未発売の商品を含み、発売まで出荷できない注文
- 印刷日待ち：配達希望日に合わせた出荷日まで保留する注文
- 印刷待ち：出荷準備へ進める注文
日常業務では、通常の出荷対象だけを作業画面に残し、保留理由がある注文は理由に応じたステータスで管理します。ステータス名だけを増やすのではなく、「誰が」「何を確認したら」「どの状態へ移すか」まで決めることが重要です。
先の日付の配達希望注文は「印刷日待ち」で管理する
母の日、父の日、クリスマスなど、配達希望日が通常の出荷日よりかなり先の注文は、通常の出荷準備に混ぜると早く発送してしまうおそれがあります。この場合は、配達希望日に合わせた出荷日まで「印刷日待ち」で保留し、出荷準備へ進める「印刷待ち」と分けて管理します。
「印刷日待ち」は、注文を受け付けない状態にするものではありません。受注情報を保持したまま、納品書などの印刷や出荷作業へ進めるタイミングを分けるための状態です。担当者は配達希望日だけでなく、いつ印刷・出荷へ移すのかも運用ルールにします。
日付に応じた自動登録機能を使う場合は、利用中の環境で対象となる日付項目や設定条件を確認してください。将来日付の注文を検索するときも、通常出荷の一覧と同じ条件で扱わず、「印刷日待ち」に入っているかを確認します。詳しい利用場面は、配達希望日が先の注文を「印刷日待ち」で管理する解説でも紹介されています。
在庫連携と売り越し時の運用では、確保在庫の区分を先に決める
在庫連携を使っていても、売り越しを完全に防げるとは限りません。ネクストエンジンの基本説明では在庫更新は5分間隔とされていますが、連携先によって例外があり、Yahoo!ショッピングについては約10分間隔と説明されています。モール側の注文受信や反映にも時間がかかるため、セールなどで短時間に注文が集中すると、同じ在庫を複数店舗が同時に受け付ける可能性があります。
売り越し対策は、在庫連携を止めることではなく、注文集中を想定して「どの在庫を、どの用途に、どの店舗へ出すか」を先に決めることです。特に少量在庫や人気商品では、通常販売分とセール用の確保分を混同しない管理が必要になります。
確保在庫を運用する場合は、対象SKUとバリエーション、数量、用途、保管・引当する拠点、使う条件と担当者、販売期間、未使用分を通常販売へ戻す方法を管理します。在庫を確保しただけで売り越しが解消するわけではないため、実際の注文への割り当て、残った在庫の扱い、店舗へ再公開するタイミングまで設計します。
セール確保分・イベント持ち出し分は、拠点管理で分ける選択肢がある
セール確保分、卸向け、実店舗の取り置き、イベントへの持ち出し分など、通常販売とは用途が異なる在庫は、拠点管理で区分する方法があります。注文に割り当てた拠点の在庫を減らし、別の拠点の在庫を直接減らさない考え方により、通常販売用と一時確保分を分けて管理できます。
拠点を作るだけでなく、対象商品と数量、販売期間、引当の優先順、終了後に通常販売へ戻す担当者を明確にします。複数拠点を1店舗へひも付ける場合は、在庫が単純合算されるとは限らないため、連携される在庫の考え方も確認してください。
イベント持ち出し分を受注伝票で確保する旧来の運用例もありますが、現在の環境で同じ手順が使えるとは限りません。まずは拠点管理で区分できるかを検討し、受注伝票を使う必要がある場合だけ、現行の対象条件と影響範囲を確認します。
引当を調整する前に、現行の対象伝票・操作条件を確認する
売り越し発生後に確保していた在庫を実際の注文へ割り当てる運用では、受注伝票の手起票や引当振替処理が関係する場合があります。ただし、過去の運用紹介にあるダミー伝票の作成方法や「引当振替処理」という名称だけを根拠に、現在の画面操作をそのまま再現するのは危険です。
現行マニュアルでは、少なくとも次の点を確認してください。
- 手起票できる受注伝票の対象条件と必須項目
- 伝票作成によって在庫が引き当てられる時点
- 引当を振り替えられる元伝票・先伝票の条件
- 振替後の受注数、引当数、フリー在庫の変化
- 残った確保分を解除・キャンセルする方法
- 在庫連携先へ再反映されるタイミングと影響
これらの現行手順は、提供資料内では確認できません。そのため、ダミー伝票の具体的な入力値や操作順を現行マニュアルとして断定しません。旧事例を参考にする場合も、利用中の環境に対応する公式マニュアルで対象伝票と実行条件を確認し、テスト用商品や少量在庫で影響を検証してから運用へ組み込んでください。過去の運用例は、SALE前の売り越し対策に関する解説で確認できますが、2017年の事例を現行手順として扱わないことが重要です。
商品ページの登録・予約更新は、対応チャネルと対象項目を確認する
ネクストエンジンの商品管理では、既存店舗の商品データを取り込み、対応するEC店舗向けに名称、説明、カテゴリなどを変換して登録・更新できます。発売開始やセール切り替えのように作業時刻を合わせたい場合は、指定日時のアップロード予約を利用する考え方があります。
予約更新では、更新対象を店舗・商品・ページ単位で指定できます。特定店舗だけのセール表示を切り替える、対象商品だけ説明文を変更する、商品ページに共通文言を追加するといった使い分けが可能です。ただし、実際に更新できる項目は連携先の仕様に左右されます。
商品登録・更新は、受注や在庫の連携とは別の機能軸です。連携先の一覧で受注・在庫に対応していても、商品登録やページ更新まで利用できるとは限りません。バリエーション、画像、オプション、カテゴリなども、モールやカートごとの制限を確認してから予約対象に含めます。予約機能の利用例は、店舗別ページの予約アップロードに関する公式ブログにも掲載されています。
受注・在庫連携の対応可否と、商品更新の対応可否は別に見る
モール・カートの対応可否は、少なくとも次の3軸に分けて確認します。
| 確認軸 | 確認する内容 |
|---|---|
| 受注 | 注文を取り込み、ステータスや出荷情報を扱えるか |
| 在庫 | 在庫数を連携し、販売先へ反映できるか |
| 商品 | 商品登録、ページ更新、画像・バリエーションなどを扱えるか |
受注と在庫に対応していても、商品登録は対象外という連携先があります。逆に、商品登録に対応していても、登録できる項目や画像の扱いに制限がある場合があります。
確認するときは、対応表の記号だけで判断せず、利用する店舗・商品形式・項目まで絞り込みます。対象商品がバリエーション商品なのか、画像やオプションを更新するのか、既存ページの一部だけを変更するのかによって、必要な手順が変わるためです。
アプリ・外部連携を使う場合は、本体・アプリ・接続先の役割を分けて確認する
標準機能で処理できない業務は、CSV、API、専用アプリ、倉庫・決済サービスとの連携で補える場合があります。倉庫への出荷指示と配送番号の取り込み、決済結果の受注反映、POSとの在庫連携、基幹システムへのデータ出力などが例です。
ただし、連携先が掲載されていることは、すべてのデータが双方向に自動同期されることを意味しません。次の項目を、ネクストエンジン本体、追加アプリ、接続先サービスに分けて確認します。
- どのデータを受け渡すか
- データの方向は一方向か双方向か
- API、CSV、ボタン操作のどれを使うか
- 実行頻度と反映までの時間
- エラー時に再処理できるか
- 本体料金とは別にアプリ料金や接続先の契約費用があるか
この切り分けをしないと、「連携できる」という説明から、受注から出荷までが完全に自動化されると誤解しやすくなります。まず業務上の完成形を決め、その処理を本体・アプリ・接続先のどこが担当するかを確認してください。
TēPsなどの追加ツールは、追加したい処理を具体化してから選ぶ
TēPsのような追加ツールは、条件に応じた伝票更新、通知、外部データ連携などのワークフローをノーコードで作る選択肢です。年末商戦のように注文数や問い合わせが増える時期でも、条件が明確な処理を自動化し、担当者が判断すべき注文を別に残す設計に使えます。
導入前は、次の順に追加したい処理を具体化します。
- 対象を決める。受注伝票、商品、在庫、出荷情報など、何を処理するかを明確にする。
- 条件を決める。店舗、商品、配送方法、決済状態、注文内容など、どの条件で分岐するかを整理する。
- 実行時点を決める。注文取り込み時、入金確認後、出荷前など、いつ動かすかを決める。
- 必要なデータを確認する。アプリが対象項目を取得・更新できるかを確認する。
- 費用と契約を分けて確認する。アプリ料金だけでなく、モール、倉庫、決済サービス側の契約費用も確認する。
本体の標準設定で実現できる処理なら、追加ツールを増やさないほうが運用を管理しやすい場合があります。一方、複数サービスをまたぐ条件分岐や通知など、本体だけでは不足する処理にはアプリやAPIが適しています。
自動化しても、人が判断する例外処理は残す
自動化では、設定を変更するだけでなく、担当者がどこで判断するかまで運用フローを見直します。確認待ち、在庫待ち、入金待ち、住所不備、ギフト、同梱、返品・交換などは、条件を誤ると自動処理によって出荷まで進んでしまうおそれがあります。
まず、通常注文を自動で進める条件と、確認対象へ振り分ける条件を分けます。次に、例外注文が入るステータス、担当者、確認期限、確認後の移動先を決めます。自動化の対象を増やすほど、例外を止める場所を明確にすることが重要です。
設定変更後は、通常注文だけでなく例外注文も使って確認します。在庫不足、未入金、先の日付指定、住所不備の注文が意図したステータスに入り、通知や出荷指示が誤って実行されないかを確認します。自動化の目的は人の判断をすべてなくすことではなく、定型処理を減らして、判断が必要な注文へ担当者が集中できる状態を作ることです。関連する考え方は、設定と運用フローの見直しによる自動化事例でも紹介されています。
まとめ
ネクストエンジンのマニュアルを探すときは、まず作業を受注・在庫・商品・連携に分け、利用中のモール、カート、倉庫、アプリを特定します。受注ステータスでは、通常出荷と確認待ち・在庫待ち・将来出荷待ちを分け、先の日付の配達希望注文は「印刷日待ち」で管理します。
在庫連携には時間差があるため、セール時は売り越しを前提に確保在庫の用途や拠点を決めます。拠点管理で区分できる範囲と、受注伝票を使った引当調整の現行手順は分けて確認してください。商品ページの登録・予約更新は、受注・在庫連携とは別に、チャネルと対象項目の対応可否を見ます。
標準機能で不足する処理は、アプリやAPIで補えます。ただし、追加ツールの機能・実行方法・費用だけでなく、例外注文を人が確認する運用まで整理してから導入することが、安定したネットショップ運営につながります。