84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
1.我用的是shopNC b2b2c商城,还是一个新手,没能比较全面的理解代码的运作流程。
2.现在需要做一个商品单品返佣金的功能,我去百度查找资料,没能找到相关的信息。
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、ステータスである必要があります)。ユーザーの返金アクションは、注文の生成から注文の最終ステータスまで反映されるため、注文が完了し、トランザクションが成功したときにリベート動作が確立される必要があります (リベートステータスが成功に変換されます)
リベート担当者のリベート 金額は毎月決済されます (スケジュールされたタスク、リベート情報は計算が遅いためキューに入れられます)、すべての計算データはリベート担当者が表示できるように販売者にフィードバックされます。
決済日の開始時に、リベート担当者は販売者から転送を取得します。資金 (これには、資金が販売者の口座に直接送金されるか、ユーザーがチェックアウト中にリベート資金を一時口座に入れているかなど、非常に詳細なプロセスが必要になる場合があります)