現在、Magentoは、再注文の形式でのみ注文の変更をサポートしています。これは、複雑な注文プロセスとデータベース構造による可能性があります。ただし、多くの場合、顧客のクレジットカードデータが保存されていないか、請求または返金できない場合は、再注文はオプションではありません。
私は、アイテムの追加または削除、数量の変更、割引の適用などのために注文を編集可能にしないという決定に興味があります。
また、この機能がないことを回避する拡張機能についても聞きたいです。私が試したもの、例えばTrue Edit Ordersは、構成可能な製品に直面したとき、ちょっと変わったものでした。
回答:
答えはあなたの質問にあり、これはMagentoでもそうであり、他のeコマースや会計ソフトウェアの多くでもそうだと思います。
商取引と会計では通常、編集は物事を行う方法ではなく、編集効果を達成するために、特定のアカウントのクレジットまたはデビット残高は、値を加算または減算する新しい行を追加することで変更されます。これはバグではなく、アカウンティングは何らかの結果を達成するために必要なアクションの数ではなく、アクションに基づいて結果を計算することを意味するため、機能です。各編集は、残高を計算し、アーカイブして、何度も何度も計算または表示する可能性を提供するために保存する必要があるアクションです。
だからMagentoでは、ほとんどすべての商人がそれを手に入れないので、最初は奇妙で不必要に思えますが、注文全体は編集できません。あなたのeストアを維持するのが難しくなるという事実は、物事を適切に行うことの副作用にすぎません。
さらに考えてみると、すべての注文兄弟（住所、商品、配送と支払い方法、割引の適用）を変更しても、合計が変更されると同じ問題が発生します。ccデータ、返金などがない場合、クライアントからのアクションが必要なため、支払いをキャプチャできません。eコマースでは、支払いを確認した時点でクライアントの注意のみがあり、その後に発生するすべてのことは、両当事者からの注意が必要です。
そのため、店舗のIRLで何らかの注文を行っている場合でも、注文を確定するために同じアクションを追加および減算するプロセスが実行されます（レジまたは私たちの頭の中で）支払いプロセス後に変更する必要がある場合、注文は破棄され、新しいアクション（支払い、割引、ボーナス、アイテムなど）を記録するために新しいアクションが作成されます。IRLでこれをよりシームレスに可能にするのは、クライアントが通常、変更を確認して支払いとすべての詳細を承認することであり、それは関係が抽象化されている脳の原因で少し速く発生することです。
順序を編集不可にする理由は、複雑さではなくデータの一貫性です。たとえば、注文後に製品を変更したり、カタログから削除することもできます。したがって、注文した製品の変更は意味がありません。顧客と彼の詳細についても同じです。
もちろん、そのようなことを考慮してインテリジェントに追跡できますが、この場合、各エンティティは変更履歴を保存する必要があるため、全体のレベルの複雑さが必要になります（例：注文時の価格、顧客グループ顧客は等にいた）。
クレジットカードの詳細に関しては、このデータを保存することは「いいえ」です。部分的なキャプチャ、支払いを後でキャプチャするための承認、または返金などは、Magentoで可能であり、支払いモジュールの実装に完全に依存しています。