ERP5

ERP5はPythonで書かれたウェブアプリケーション型のERPでオープンソースライセンスで配布されている。 ERP5は現実のビジネスを実際のとおりにコンピュータで表現するためのユニファイドビジネスモデルと呼ばれる設計思想の下で実装されているドキュメント指向のERPである。 ERP5の開発は、ソフトウェア企業Nexediを中心に行われている。バージョン番号を使ったリリースは形骸化しているので、ユニットテストの結果からエラーの少ない版をみつけることができる。ERP5を動かすために必要なソフトウェアは全てオープンソースライセンスの下で入手できる。 ユニファイドビジネスモデルはERP5の基になっている設計思想である。ユニファイドビジネスモデルには現実のビジネスを抽象化するための5つの要素があり、これがERP5の「5」の由来である。ERP5でシステムを構築する場合にはそのシステムに登場するものがユニファイドビジネスモデルのどの要素にあてはまるかを考える必要がある。その5つの要素とは以下のものである。 リソース 与えたり、与えられたりできるものであり、そしてそのようなものを概念として一般化したもののことである。商品カタログ上の概念として表わされるものがリソースである。例えば、スーパーのチラシ上のみかん、マッサージ、法律相談、日本円である。 アイテム リソースが具体化されて、個別に認識されるようになったもののことである。例えば、私がいま右手に握っている一つのみかん、記番号がA000145Gの千円札、個体識別番号1180300768の牛肉はアイテムである。 ノード リソースやアイテムを所有したり格納したりできるものである。例えば、人、組織、土地、建物、勘定科目である。 パス 特定または不特定のノード間の決まり事を表わすものである。例えば、売買契約、取引価格、納期、変換コードなどである。 ムーブメント パスが具体化したものであり、リソースまたはアイテムのノード間の具体的な移動を表わすものである。例えば、商品の発送、マッサージの提供、仕訳である。 ユニファイドビジネスモデルは事実を実際にあるとおりに抽象化するので、ユニファイドビジネスモデルに基づいたシステムは事実に基づいたシステムとなる。そのため、例えばシステムの都合で実際には一つの製品を二つの異なる製品としてデータベースに登録するようなことはユニファイドビジネスモデルに反している。 ERP5は以下のZODBとMariaDBの両方を同時に使う。 Python用のオブジェクトデータベースである。ユーザが入力した全てのデータはERP5のユニファイドビジネスモデルで表わされるデータとなり、PythonのクラスのインスタンスとしてZODBに直接保存される。オブジェクトデータベースにはテーブルという概念はないので、データのクラス定義を変更してもデータベース上でそのための定義変更操作は必要ない。 利用可能なZODBのストレージとして、ファイルシステム上の一つのファイルに全てを保存するZODB標準のFileStorageと、ERP5用に開発されたネットワーク分散ストレージNEOがある。 ZODBには検索機能と集計機能がない。これを補うために、オープンソースの関係データベース管理システムであるMariaDBを使っている。ZODBに保存された情報はただちに自動的に検索や集計に必要な部分だけ抽出されてMariaDBに保存される。ZODBに保存されたデータをMariaDBで検索するときに必要になるクエリーはERP5の検索機能が自動的に生成するため、ERP5開発者は最適化を行いたい場合を除いてSQL文を書く必要はない。 ユーザが入力した全てのデータはZODBに保存されるのでZODBは必ずバックアップする必要がある。MariaDBのデータは失なわれてもZODBから復元できる。 ERP5はZope2の方向性を受け継いだThrough-The-Web development(ウェブブラウザ越しの開発)プラットホームである。Zope2のウェブブラウザ越しの開発機能にERP5の独自機能が加えられている。ERP5を使ってERPを作る開発者はERP5にウェブブラウザでアクセスし、そこでERP5自身を開発できる。 ERP5開発者はウェブブラウザ越しで入力フォームの作成、Pythonクラスの定義、既存クラスへのコーディング無しのメンバー変数追加、ユニットテストの開発と実行、Gitに変更をコミットすることなどあらゆる開発を行うことができる。加えて、この動的な開発の結果はERP5を動かしているクラスタの全ノードに直ちに自動的に反映される。 ERP5はデータを分類するためのカテゴリー機能を持っている。一つのデータに対して異なる文脈ごとに異なる分類ができるようになっている。 例えば、ある会社(ノード)がある取引(ムーブメント)において代金の支払者であると分類し、次にある売買契約(パス)においてはこの会社が品物の出荷元であると分類する。このように分類すると、ERP5の検索機能を使ってこの会社が支払者になっている取引をみつけたり、この会社が商品の出荷元になっている売買契約をみつけることができる。 このようにERP5はカテゴリー機能を使って一つの組織や人、ものが異なる複数の側面を同時に持っているという状況をコンピュータ上に表現している。現実で単一の存在はコンピュータ上でも単一の存在として表現できる。この機能によってERP5はERPに求められる「複数の活動を単一のシステムで統合する」ことができるようになっている。 ERP5は最初の入力と与えられたルールに基づいて次に生じると想定されるデータを予測し、また予め与えられた例外時の処理方法に基づいて例外を処理するシミュレーションシステムを構築するための機能を持っている。 シミュレーションを使って予測したデータを実際にデータベース上に作成することができ、もし結果として事実が予測と合致しない場合には、事実をデータに反映し、その更新されたデータに基づいてその時点から先のデータを再度予測することができる。さらに、事実が予測に反した場合にそれが予測に反したことであったことを記録に残すことができる。シミュレーションは、例えば製造業の会社が受注してから行う部材の調達、製造、出荷、請求、支払などの一連の処理を定型化するのに使うことができる。 ERP5はZope2由来のワークフローシステムを持っている。どんなデータも一つまたは複数のワークフローで管理できる。ワークフローの状態を使ってそのデータの正当性を示すことになっているため、データの入力値チェックはユーザの入力時ではなく、ワークフローの状態を内容が正当であることを示す状態に遷移させるときに行う。 ERP5はユニファイドビジネスモデルとカテゴリーで表現された複数の事実に基づいた動的に変化するセキュリティーを構築できる機能を持っている。 ERP5はユーザインタフェースとユーザ入力データの両方において多言語化対応している。同じ一つのユーザインタフェースを言語を切り替えて表示することができ、一つのコンテンツを複数の言語で書くことができる。例えば、組織データの組織名を日本語と英語と中国語の3言語で書くことができる。さらにこのように多言語化されたデータをどの言語でも検索できる。ERP5を多言語化させる作業はウェブブラウザ越しに行える。 販売価格や割引率、請求書のまとめ方など、様々な機能がユーザが入力したデータに従って動作するため、ユーザが入力したデータがある実運用環境の動作をテストするためには実運用環境のデータが全て必要になる。そのため、ERP5はライブテスト機能を持っている。 ライブテストは実運用環境上でユニットテストやファンクショナルテストを実行する機能である。ライブテストを使うと実運用環境が想定通りの動作を行うことを確認することができる。 ^ ERP5 git repository ^ Release Information ^ Unit Tests ^ ERP5 Stack ^ Unified Business Model ^ Data Model is not equal to Index Model ^ ERP5 Stack buildout.cfg ^ SQL Catalog Structure ^ How to add a table with custom fields to the SQL catalog ^ What is The CMFActivity Tool ^ How To Search Using portal_catalog ^ Dynamic Classes ^ Movementで使うCategoryたち ^ ERP5 Simulation ^ How To Use And Define Workflows ^ ERP5 Security ^ ERP5 Localisation ^ testContentTranslation.py ^ How To Create Unit Tests 公式ウェブサイト 表示 編集