2層ERPとSAP Business One：仕組み

みなさんこんにちは！



今回は、ERPシステムのトピックに戻ることにしました。 SAP製品ラインには、多国籍企業から中小企業まで、さまざまな規模の企業向けのさまざまな製品があります。 組み合わせもあります-企業が複数のタイプのERPを一度に使用する場合、本社および支社用。 このような場合は2レベルERPと呼ばれ、SAP Business Oneは「軽量」システムとして優れています。 この記事では、詳細と統合の詳細について説明します。



しかし、最初に、2つのレベルのERPとは何かという質問に答えましょう。













「2レベルERP」という用語は多くの人によく知られています。 2レベルのERPシステムの概念は、子会社または支店のレポートおよびビジネスアプリケーションの統一された標準を必要とする企業で使用されます。 小規模ビジネスユニットでは、多くの理由で、他のビジネスプロセス、従業員の適応の難しさ、展開に時間がかかるなど、大きなERPを使用するのは現実的ではありません。 そして、ここにスタッフトレーニングのための時間を追加すると、システムを維持するためのコストがかかりますが、それだけで40のブランチに一度に「大きな」ソリューションを実装する必要があります。 比較のために、「小さな」ソリューションを数週間で実装できます。



2レベルのERPは、大企業だけでなく、「本社=>支店」という関係を持つ今日でも適用可能です。 この戦略は、サプライヤ、ディストリビュータ、ディーラー、およびサービス組織と協力するときに実行可能です。



欧州のクライアントの例は、スペインのハイネケンです。 彼らには、注文、在庫移動、支払い請求書に関する600の流通業者とスペインのハイネケン間のデータ交換を確立し、すべてのプロセスを自動化する方法がありました。 その結果、同社はSAP Business Oneに基づくソリューションの開発を決定しました。

Heinekein Spainは、モノのインターネットを使用したシナリオを考え出しました。ビールタップに組み込まれている30万以上のセンサーからデータを収集します。 会社は、単一の情報システムからビール消費に関する情報を受け取ります。 その結果、ハイネケンは、販売チャネルをより適切に管理し、販売チェーンを最適化し、パフォーマンスを改善する方法を実現しました。 また、ビールの消費に関するデータをリアルタイムで受信し始めました。「タップするたびに」と言う人もいるかもしれません。







2レベルのERPシステムでは、すべてが完璧というわけではありません。 さまざまなシステムを統合するときにどのような問題が発生する可能性があるかを見てみましょう。



なぜ支店や子会社にERPシステムを導入するのですか？ もちろん、大企業や大企業では、ビジネスプロセスに関する透過的な分析やレポートを受け取りたいと考えています。 さらに、このような問題はしばしば発生します。各支店では、地元の専門家にとって便利な独自のソリューションを導入し、その結果、システムとサービスの「動物園」が会社に現れます。 そしてもちろん、それらはさまざまな理由で親ERPと互換性がない場合があります。たとえば、閉じたAPIを使用したソリューションの使用が原因です。 この場合、単一のレポート、またはビジネスプロセスの自動化を期待することはできません。



SAPには何がありますか？ さまざまなタスクと目標に対応するERPシステムのラインナップがあります。 複雑なビジネスプロセスを持つ企業の場合、「重量級」が必要です。ここでは、S / 4HANA、ECC、またはR / 3を選択します。 組織にとって、SAP Business Oneはよりシンプルまたは小規模です。 同時に、B1は大規模なSAPソリューション（S / 4HANA、Hybris、Ariba、Customer Checkout、Concur、モバイルアプリケーション、さらには政府サービスなど）と簡単に統合できます。







統合サービスの開発のためのSAP Business Oneの機会は何ですか？

• SAP Business One SDK / DI-APIによる統合のための.Net開発
• サービス層を介した統合のための.Net開発（SAP HANAのSAP Business Oneバージョンで使用可能）
• 統合フレームワーク

機能、ターゲットオーディエンス、スコープを表に示します。





次の記事では、統合フレームワークについて詳しく説明します。

統合フレームワーク

SAP Business One Integration Framework（B1iF）は、バージョン8.8以降のSAP Business One ERPシステムで使用できます。 SAP HANAまたはMS SQLデータベースにインストールできます。 B1iFの主なタスクは、外部（SAPおよび非SAP）システムからデータを送受信することです。 統合スクリプトパッケージは、Integration Framework内で構築されます。 スクリプトロジックはビジネスプロセスに基づいています。エラー管理、競合、トランザクション（およびその実行順序）、実行保証、監視、デバッグ、および管理はB1iFで実行されます。







2つのシステムを統合するシナリオを開発するには、プログラミングのスキルは必要ありません。

プロセスシーケンスは、プラットフォームの組み込みグラフィックデザイナーを使用して設定されます。 B1iF BizFlow Atomsの組み込み機能ユニットは、値のマッピング、コールのセットアップ（SAP Business One、SAP ERP、HTTP、SQL、ファイルシステムなど）、XSLT変換に使用されます。 データマッピングは、組み込み（または外部）XMLエディターのXSLT変換を使用して実行されます。 デバッグツールを使用すると、構造化された視覚的な形式で個々のプロセスシーケンスを開発できます。







統合プラットフォームで実行される統合スクリプトは、スクリプトパッケージと呼ばれます。 システム間の全体的なデータ交換に必要なものはすべて、スクリプトパッケージに含まれています。

スクリプトパッケージには、1つ以上のスクリプトステップが含まれます。 スクリプトステップは、インバウンドフェーズ、処理フェーズ、アウトバウンドフェーズを含む特定の統合フローです。







第1フェーズでは、統合プラットフォームが着信メッセージを受信し、それをXML形式に変換します。 処理段階では、メッセージが変換および処理され、受信者が識別され、メッセージパラメーターが比較されます。 出力段階で、統合プラットフォームはメッセージを受信者のERPシステム形式に変換し、メッセージを送信します。



スクリプトステップを設計するプロセスでは、主なパラメーターを設定する必要があります。ステップの開始方法、システムが相互作用する方法、統合プラットフォームがメッセージを処理する方法、さらにステップがあるかどうか（外部システムの呼び出しなど）。



スクリプトの手順は次のとおりです。



1.同期（要求/応答）：

-送信者は、ステップの実行を開始するリクエストを形成します

-処理結果は応答として送信者に返されます





2.非同期（送信者から受信者へ）：

-タイマー、イベント、または呼び出しによってトリガー

-データは送信システムから送信され、いつでも処理され、変換され、受信者に送信されます





インバウンドチャネルは、送信プラットフォームのタイプと、統合プラットフォームが受信データを受信するために使用できるインターフェース（API）を記述します。 受信チャネルとして、HTTP、ファイル、空のメッセージ（Void（タイマー））、Webサービス、SAP Business One、SAP ERPを使用できます。



発信チャネルは、受信システムのタイプと、データ転送のために統合プラットフォームで使用されるインターフェース（API）を記述します。 送信チャネルとして、HTTP、ファイル、空のメッセージ（無効、同期ステップのみ）、Webサービス、データベース、SAP Business OneおよびSAP ERPを選択できます。



処理段階ではグラフィックツールが使用されます。 主な設計要素はアトムです。 アトムは順番に配置され、外部システム（SQLデータベースや電子メールなど）を呼び出すために使用されます。 各アトムは着信メッセージを受信し、特定のタスクを実行し、メッセージを次のアトムに渡します。







統合ステップ間でデータを転送するために、内部キュー処理メカニズムが使用されます。 したがって、統合手順はスクリプトパッケージに結合できます。



統合シナリオ開発の例





ビジネスでは、プロセスに関するデータへのリアルタイムアクセスと、手作業の自動化が必要です。 プロセスの自動化は、企業がワークロードを最適化し、情報を送信する際のエラーのリスクを減らすのに役立ちます。 サプライヤーのシステムまたは特定のタイプのビジネスとの統合により、これらのリスクが排除されます。



顧客とサプライヤという2つのシステムの統合の簡単で実用的な例を見てみましょう。 両社はSAP Business Oneで働いており、チェックアウトプロセスを自動化したいと考えています。 この例では、会社1の「購入注文」が会社2に転送され、そこで「販売注文」ドキュメントが生成されます。 会社2は、会社1への注文の形成を確認します。







統合シナリオは、会社1で「発注書」ドキュメントを作成することで起動できます。シナリオには2つの統合手順があります。

• 最初のステップで、アトムB1オブジェクト呼び出しを使用して、会社2で「販売注文」ドキュメントが生成されます。
• 呼び出しステップアトムは、2番目のステップにバインドするために使用されます
• 2番目のステップでは、会社1のユーザーに、作成された「販売注文」ドキュメントのステータスが通知されます。

統合シナリオを実行するには、会社のマスターデータコード1が必要です。このデータは「注文」に含まれておらず、統合プラットフォームに送信されません。 この情報を保存するには、グローバルテーブルを使用できます。 グローバルテーブルのパラメーターを設定するには、グローバルテーブルのタイプ（リレーション1のタイプ1 <-> 1、リレーション1のタイプ2 <-> N）、テーブルフィールドの長さ、および名前を決定する必要があります。







グローバルテーブルを作成したら、データを入力できます。







次に、統合ステップ1で、着信チャネルを定義します。

• チャネルタイプ-SAP Business One
• B1イベントの開始（文書「購入注文」の作成）
• 使用される識別子はオブジェクトID「購入注文」です（22）
• タイプObjectのDI-APIによるデータの受信

発信チャネルでは、空のメッセージ（void）を選択します。 受信者システムはありません：











メッセージ処理プロセスの構成に移りましょう。 原子の番号付けは、プロセスに追加された順序で実行されます。



変換アトム（atom1）はオプションです。 後で他のアトムで使用するために、起動条件と送信側システムに関する情報を保存できます。 会社1のCustomerCode値は、グローバルテーブルから読み込まれます。 ユーザーID値は、「購入注文」を作成する着信B1イベントのXML変換のT（トリガー）セクションから選択されます。

<Values> <xsl:variable name="MappingCardCode" select="document('/com.sap.b1i.vplatform.scenarios.design/vPac.xxx.B2BB1/vTbl.B1MappingCardCode.xml')"></xsl:variable> <xsl:variable name="Vendor" select="$msg/BOM/BO/Documents/row/CardCode"></xsl:variable> <xsl:variable name="Customer" select="$MappingCardCode/table/row[./col[2]=$Vendor]/col[1]"></xsl:variable> <CustomerCode> <xsl:value-of select="$Customer"></xsl:value-of> </CustomerCode> <B1User> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@Role='T']/Event/b1e:b1events/b1e:b1event/b1e:userid"></xsl:value-of> </B1User> </Values>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

B1 Objectアトム（atom2）を構成するとき、次のパラメーターを使用します。

• Sysid：統合プラットフォームでSAP Business Oneによって割り当てられたID
• B1ログイン：統合プラットフォームの設定から割り当てられます
• 方法：同期
• オブジェクト識別子：17（販売注文）
• キー名：DocEntry
• キー値：N / A（SAP Business Oneでドキュメントが作成されたときに自動的に入力されます）
• ペイロード：先行する変換アトムの名前

B1 Objectアトムの前に、以前の変換アトム（atom3）を使用します。 このアトムは、アトム2（B1オブジェクト）にロードするための情報を準備します。

[ドキュメント]セクションで、ドキュメント「Sales Order」のタイトルの値を決定する必要があります。

• 会社1の会社マスターデータコード（CardCode）
• ドキュメントの日付（DocDate）は、現在の日付と時刻を返す統合プラットフォームに組み込まれた日付と時刻の関数を呼び出すことで設定されます
• 出荷日（DocDueDate）はDocDateに基づいて計算されます

Document_Linesセクションは、販売注文ドキュメントの行を定義します。 必要な情報は、着信文書「発注書」のセクションS（送信者システムからのメッセージ、送信者メッセージ）から抽出されます。

 <Documents> <row> <xsl:variable name="date"> <xsl:call-template name="b1ilib.today"></xsl:call-template> </xsl:variable> <DocDate> <xsl:value-of select="$date"></xsl:value-of> </DocDate> <DocDueDate> <xsl:call-template name="b1ilib.date_plus"> <xsl:with-param name="date" select="$date"></xsl:with-param> <xsl:with-param name="x" select="20"></xsl:with-param> </xsl:call-template> </DocDueDate> <xsl:variable name="Customer" select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/CustomerCode"></xsl:variable> <CardCode> <xsl:value-of select="$Customer"></xsl:value-of> </CardCode> <NumAtCard> <xsl:value-of select="$msg/BOM/BO/Documents/row/DocNum"></xsl:value-of> </NumAtCard> </row> </Documents> <Document_Lines> <xsl:for-each select="$msg/BOM/BO/Document_Lines/row"> <row> <ItemCode> <xsl:value-of select="ItemCode"></xsl:value-of> </ItemCode> <Quantity> <xsl:value-of select="Quantity"></xsl:value-of> </Quantity> </row> </xsl:for-each> </Document_Lines> <xsl:include href="../../com.sap.b1i.system.lib/xsl/datetime.xsl"></xsl:include>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

終了アトム（atom0）は、原則として、受信システムに送信するためにデータを変換します。 このシナリオでは、空のメッセージ（void）が発信チャネルのタイプとして選択されます。 ただし、ログエントリを作成するには、このアトムを定義する必要があります。 この要素には、DIresultおよびDImsg属性が含まれます。 DImsg属性には、作成されたドキュメントのキー（スクリプトが正常に完了した場合）またはエラーメッセージ（実行が失敗した場合）が含まれている必要があります。

 <xsl:variable name="Status" select="$msgB1/@DIresult"></xsl:variable> <xsl:variable name="Entry" select="$msgB1/@DImsg"></xsl:variable> <Msg> <xsl:value-of select="concat('Message: ',$Status, ', DocEntry: ',$Entry)"></xsl:value-of> </Msg>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Atom4とatom5は2番目の統合ステップに属します。企業ユーザー1にメッセージを送信します。呼び出しアトム（呼び出しステップタイプ）は、前の変換アトムを意味しません。 それでも、最初のステップの場合のように、アトム4については、前の変換アトム（アトム5）を定義します。 atom5のパラメーターでは、呼び出されたアトムに送信されるデータを示します。 この場合、このデータには、DIresult属性（B1 Objectアトムの処理結果）およびSAP Business Oneユーザーコード（B1User）を持つ要素が含まれます。

 <B1Result> <Result> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom2']/@DIresult"></xsl:value-of> </Result> <B1User> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/B1User"></xsl:value-of> </B1User> </B1Result>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

呼び出しアトムに対して、パラメーターを設定します。

• 呼び出されたアトムの処理のタイプ（同期または非同期）
• 原子名と呼ばれる
• 入力パラメーターを持つアトム（変換の前のアトム）

2番目の統合ステップの形成に進みます。 文書作成プロセスの結果に応じて、会社のユーザー1に異なるメッセージを送信します。 これを行うには、分岐開始のタイプのアトムを使用します。







条件付きのアトムの場合、パスタイプの複数のアトムとそれ以外のタイプの1つのアトムのみを使用できます。 統合プラットフォームは、パスの実行時にのみ真の結果で動作します。 したがって、この場合、パスアトムの条件を設定するだけです。



/*[/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'.BIZ/B1Result/Result = 'success']



それ以外のアトムは、パスアトムの結果がfalseの場合にのみ機能します。 非分岐アトムは分岐を完了し、原子条件の結果を含みます。







B1メッセージのアトムのパラメーターでは、ユーザー情報と同様に件名とメッセージテキストを指定する必要があります



/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'.BIZ/B1Result/B1User







2番目の統合ステップの最後のアトムでは、分岐の完了を確認する必要があります。 これを行うには、統合プラットフォームに保存されているXSLテンプレートを使用できます。







スクリプトのアクティブ化と検証



統合プラットフォームは、スクリプト設定ウィンドウを開くときに統合スクリプトの整合性をチェックします。







この場合、検証は成功し、スクリプトの実行を開始できます。

サプライヤV22222から会社1のデータベースに「購入注文」を作成します。







ドキュメントの作成後、注文が正常に作成されたというユーザーB1iからの通知が表示されます。







会社2は、「購入注文」のデータと会社1のドキュメントの番号で「販売注文」を作成しました。







おわりに



結論として、私たちのクライアントであるデラバル社からのビデオを見ることをお勧めします。 同社は、親企業と大規模な支店（SAP ERP）、および小規模な子会社（SAP Business One）で2レベルのERP戦略を長年積極的に使用してきました。 このビデオでは、 DeLavalのビジネス統合ディレクターであるSteve Woodgateが、第2レベルのERPとしてSAP Business Oneを選択した理由と結果について説明しています。



SAP Business Oneの実装例は、当社のWebサイトでご覧いただけます。



ソリューション機能のレビュー付きビデオは、YouTubeチャンネルでのみ利用できるわけではありません。



次回の記事では、SAP Business One 9.3の新バージョンの機能について説明します。SAPBusiness One 9.3は、SAPとお客様の両方によって積極的にテストされています。 ちなみに、SAP Business Oneバージョン9.3の世界で最初の「生きている」顧客の1人は、ロシアのTelecom Exchangeの顧客でした。 クライアントのコメント付きのビデオはこちらでご覧いただけます： youtu.be/GTgm-nJddDI



読んでフィードバックしてくれてありがとう！