1. shopNC b2b2c モールを使用していますが、コードの操作プロセスがまだ完全に理解できません。
2. 次に、単一の商品に対する手数料を返す機能を作成する必要があります。Baidu にアクセスして情報を探しましたが、関連する情報が見つかりませんでした。
3. ここでマスターにアイデアを尋ねたり、学ぶための関連資料を勧めたりすることができます。
4. この機能についてはまだ理解が浅いので、より包括的なサポートが得られることを願っています。
shopNC について聞いたことはありませんが、キャッシュバックについていくつかのアイデアを提供できます。
キャッシュバック: ユーザーが注文を完了すると、一定額の現金が返されます。 キャッシュバックは 1 レベルのキャッシュバックまたは複数レベルのキャッシュバックです。
第 1 レベルのリベート: つまり、製品の価格は 100 元であり、この時点でのキャッシュバック率は 10% であり、ユーザー A がこの製品の購入を推奨します。は:
B 注文する ---> B 100 元支払う ---> B 商品を受け取る ---> 注文を完了する ---> でキャッシュバック関数を入力します。今回は、10元をBに渡すかAに渡すかは関係ありません。ただし、B または A のいずれか 1 人に対してのみです。
同じ購入プロセス。 Bが注文を完了すると、10元の一部はBに、一部はAに返還されます。 A と B がどれだけ返されるかについては、比率が存在するはずです。例: 7:3 の場合、B は 7 元、A は 3 元を取得します。
第 2 レベルのリベートと同じ。ただし、通常はレイヤーの数が決まっています: 3 レイヤー以下の場合は、製品がピラミッド型になるように注意してください。 上記のアイデアにより、プログラムは比較的簡単に実装できます。キャッシュバック機能は、ユーザーが支払いを完了した後、またはユーザーが注文を完了したときにトリガーできます。注文完了後にトリガーすることをお勧めします。
疑似コードで表すと:
....注文完了後、戻る関数を呼び出します
上記は疑似コードです。実際には、特に複数のキャッシュバックがある場合、計算エラーを防ぐために慎重に制御する必要があります。
私はやったことがないので、これに基づいてしか説明できません リベートはマーケティングツールなので、対応するSKU製品のマーケティング戦略を策定します もちろん、この戦略は販売者によって策定され、戦略の策定には多くの労力が必要です。たとえば、注文不正を防ぐためにリベート額の比率を制限するための厳密なロジック。これは手数料リベートであるため、リベート個人情報パラメータを商品詳細ページの URL とショッピング カートに送信する商品パラメータに含める必要があります。注文が生成されると、製品情報とリベート情報が送信されます。その際、製品を確認し、その製品にリベートがあるかどうかを確認する必要があります。確認が完了したら、関連するリベート情報を確認します。はデータベースに保存されます (このデータ テーブル フィールドは、製品 ID、製品の現在の価格、リベート受信者情報、リベート金額、マーケティング戦略 ID、ステータスである必要があります)。ユーザーの返金アクションは、注文の生成から注文の最終ステータスまで反映されるため、注文が完了し、トランザクションが成功したときにリベート動作が確立される必要があります (リベートステータスが成功に変換されます) リベート担当者のリベート 金額は毎月決済されます (スケジュールされたタスク、リベート情報は計算が遅いためキューに入れられます)、すべての計算データはリベート担当者が表示できるように販売者にフィードバックされます。決済日の開始時に、リベート担当者は販売者から転送を取得します。資金 (これには、資金が販売者の口座に直接送金されるか、ユーザーがチェックアウト中にリベート資金を一時口座に入れているかなど、非常に詳細なプロセスが必要になる場合があります)
shopNC について聞いたことはありませんが、キャッシュバックについていくつかのアイデアを提供できます。
キャッシュバック: ユーザーが注文を完了すると、一定額の現金が返されます。
キャッシュバックは 1 レベルのキャッシュバックまたは複数レベルのキャッシュバックです。
第 1 レベルのリベート:
つまり、製品の価格は 100 元であり、この時点でのキャッシュバック率は 10% であり、ユーザー A がこの製品の購入を推奨します。は:
B 注文する ---> B 100 元支払う ---> B 商品を受け取る ---> 注文を完了する ---> でキャッシュバック関数を入力します。今回は、10元をBに渡すかAに渡すかは関係ありません。ただし、B または A のいずれか 1 人に対してのみです。
第 2 レベルのリベート:同じ購入プロセス。 Bが注文を完了すると、10元の一部はBに、一部はAに返還されます。 A と B がどれだけ返されるかについては、比率が存在するはずです。例: 7:3 の場合、B は 7 元、A は 3 元を取得します。
複数レベルのリベート:第 2 レベルのリベートと同じ。ただし、通常はレイヤーの数が決まっています: 3 レイヤー以下の場合は、製品がピラミッド型になるように注意してください。
ユーザーは支払いを終えたばかりで、注文やその他のアクションをキャンセルする可能性があるためです。上記のアイデアにより、プログラムは比較的簡単に実装できます。キャッシュバック機能は、ユーザーが支払いを完了した後、またはユーザーが注文を完了したときにトリガーできます。注文完了後にトリガーすることをお勧めします。
疑似コードで表すと:
....注文完了後、戻る関数を呼び出します
上記は疑似コードです。実際には、特に複数のキャッシュバックがある場合、計算エラーを防ぐために慎重に制御する必要があります。
私はやったことがないので、これに基づいてしか説明できません
リベートは実際には巨大なモジュール システムです。これは私の個人的な理解にすぎません。リベートはマーケティングツールなので、対応するSKU製品のマーケティング戦略を策定します もちろん、この戦略は販売者によって策定され、戦略の策定には多くの労力が必要です。たとえば、注文不正を防ぐためにリベート額の比率を制限するための厳密なロジック。これは手数料リベートであるため、リベート個人情報パラメータを商品詳細ページの URL とショッピング カートに送信する商品パラメータに含める必要があります。注文が生成されると、製品情報とリベート情報が送信されます。その際、製品を確認し、その製品にリベートがあるかどうかを確認する必要があります。確認が完了したら、関連するリベート情報を確認します。はデータベースに保存されます (このデータ テーブル フィールドは、製品 ID、製品の現在の価格、リベート受信者情報、リベート金額、マーケティング戦略 ID、ステータスである必要があります)。ユーザーの返金アクションは、注文の生成から注文の最終ステータスまで反映されるため、注文が完了し、トランザクションが成功したときにリベート動作が確立される必要があります (リベートステータスが成功に変換されます)
リベート担当者のリベート 金額は毎月決済されます (スケジュールされたタスク、リベート情報は計算が遅いためキューに入れられます)、すべての計算データはリベート担当者が表示できるように販売者にフィードバックされます。
決済日の開始時に、リベート担当者は販売者から転送を取得します。資金 (これには、資金が販売者の口座に直接送金されるか、ユーザーがチェックアウト中にリベート資金を一時口座に入れているかなど、非常に詳細なプロセスが必要になる場合があります)