Alicia

投稿の際は下記の情報をお書き添えください。
-------------------------------------------
WordPress のバージョン:(例 6.8.2)
Welcart のバージョン:(例 2.11.20)
PHP のバージョン:(例 8.2)
Welcart専用の拡張プラグインとバージョン:(例 DL Seller 3.5.8、SKU Select 1.4.7)
ご利用の親テーマとバージョン :(例 Welcart Basic 1.8.7)
ご利用の子テーマとバージョン :(例 Welcart Beldad 1.5.5)
利用している決済モジュール:
症状を確認したブラウザ:
サーバー【重要】:(会社名、サービス名)
--------------------------------------------

フォーラムへの返信

15件の投稿を表示中 - 16 - 30件目 (全184件中)
  • 投稿者
    投稿
  • Alicia
    参加者

    Welcart Shop システム設定 > システム設定タブ の末尾より変更できます。

    返信先: 会員登録スパムの改善方法 #103152
    Alicia
    参加者

    usces_filter_member_checkに関するトピック

    ではなくて、こちら
    不正な会員登録に関するトピックです。

    返信先: 会員登録スパムの改善方法 #103150
    Alicia
    参加者

    FJO 様

    こんにちは。

    不正アクセスによる新規会員登録にバリデーションチェックを追加するパッチは、もう試されましたか?

    プラグインの readme ファイルに重要事項が記載されていますのでよく読んでお使いください。
    既に フィルターフック usces_filter_member_check を使用している場合には、特にご注意ください。
    過去のトピックにも挙がっていますので、ご確認ください。

    Alicia
    参加者

    satou 様

    ご検討結果のご報告ありがとうございました。

    質問を投げっぱなしにされる投稿者も多い中、フォーラムの運営に協力的な方もいらっしゃるということが救いです。Welcart の益々の発展に期待しましょう。

    Alicia
    参加者

    satou 様

     こんにちは。横から失礼します。
     
     これ悩ましいですよね。私も数年前に挑んで、断念した経験があります。記憶があやふやな部分もありますので参考になるかどうか。

     このプラグインは、ご存じの通り SKU の単価をオプションの有無で変動させるものです。単価を変動させた後、数量を掛けてカートの中の1行の合計金額を求める仕様です。お調べになったように、受注データには変動後の単価しか保存されなかったと思います。よって、マルチプライスによってオプション料による価格変動があった受注データは、不可逆となり、個々のオプション料は後から拾うことができません。つまり、受注データには、受注時の個々のオプション料は、持っていないということですね。
     $post_id や $sku などから、現在のオプション料は取得できますが、仰るとおり将来に向けて金額変更があったり、オプション構成が変わらない保証がないのでそこから取るのは危険ですし、受注データからオプション料が抜き出せない以上、どうしようもないと判断しました。

     ですので、残念ながら今お考えのものは難しいのではないかと思います。(できるといった回答が他の方から得られればいいのですが。)

     当時、私が採った方法ですが、オプション1、オプション2からなる2軸の単価変動は、「やらない」と決めました。これをすると、セレクト値に、(+〇〇〇円)を追加するという方法が使えなくなるからです。
    2軸にせず、1軸に統合して、セレクト値にオプション料を併記する方法に統一しました。結局これが単純明快なのかと。
    各オプションのセレクト値の文字列の長さや数によっては、確かに見にくくなりますが、カートやPDF、購入履歴など様々な場所でオプション料が表示できなくなるよりはマシというトレードオフの結果と諦めました。

     その代わり、見にくくなるデメリットを減らすために、オプションのキーとセレクト値は極力簡潔にするよう努めました。
    私の場合、SKUごとに適用できるオプションが少しずつ差異が生じたために、共通オプションが多量になってしまいかなり見にくくなってしまいました。
     また、オプションによって配送方法を制御しなければならなかったり、管理が大変になってしまったための対策として、共通オプションのキーの先頭8文字をコード化して、制御しやすくしてみました。フロントサイドでは、そのコードがやかましくなったので、フロンドに出るものは、フィルターフックで先頭8文字を消去して表示しました。
     このようにオプションの文字列に必要なデータを含ませることで、受注データとしても保存し、バックで活用しつつフロントで要らないところでは隠す処理をすることにしました。

    (例)
     2軸構成 (これでは、セレクト値にオプション料を併記しづらい。)
     オプション1 サイズ ⇒ S M L
     オプション2 数量  ⇒ 10 20 30

    (別途、商品詳細ページにオプション価格表を提示することはできるが、各種PDF、受注リスト、取引履歴などは、オプション料を併記するのは困難。)

              ↓

     1軸構成に変更 (セレクト値にオプション料を含ませれば、少ないカスタマイズでもデータを持たすことができます。隠したい場所では、文字列操作で消します。セレクト値も、後ろから何文字か消すとか、特定の文字をセパレータにしてそこから消去とかでも実現できますよね。) 

    [option_code]+オプション名 サイズ/数量

    (セレクト値)
    S/10 +100円
    S/20 +120円
    S/30 +130円
    M/10 +200円
    M/20 +220円
    M/30 +230円
    L/10 +310円
    L/20 +330円
    L/30 +350円

    (セレクト値が表記できるところには、もれなく全てオプション料が併記できます。しかし、2軸に比べるとやはり見にくいのと、セレクト値の組み合わせが多くなると、どこかで限界があるでしょうね。)

    この方法ならオプション料が変更になっても、過去の受注データは変わりませんので心配ないと思います。
    その代わり、文字列操作のために、多くのフィルターフックを用いました。フックがなかった部分は、中の方に無理を言って作っていただきました。

    同じ、ユーザビリティを低下させないという目的ですが、私はこの方法を採用しました。
    請求明細で金額の内訳がないのは、内容にもよりますがあまり好ましくないでしょうね。後で苦情になったり、問い合わせに対応するのも億劫ですし。

    ご参考になりましたら幸いです。
    皆さんはどうされてますでしょうか。私はコードを書くのは素人なので難しいことは分かりません。
    jsを使うとか、たぶんもっと良い方法があると思います。

    私の当時の記憶ですので、今は状況が変わっているかもしれません。
    ご質問の内容は、中の方からのご回答を待たれた方が確実かと思います。ご注意ください。

    • この返信は6ヶ月前にAliciaが編集しました。
    Alicia
    参加者

    bstore 様

    こんにちは。

    同時に複数の支払方法は選択できませんが、同時購入したいというわけでもなさそうですよね。

     デフォルトでは、「使用する」に設定した支払方法が選択肢に出てきますが、私の場合、特定のSKUコード(ショップ全体でユニークとなるようにSKUコードを設定しています。)が、カート内に1つでも存在すれば、指定した複数の支払方法を消去する方法で制御しています。これができるということは、特定のSKUがカート内に1つでもあれば、特定の支払方法のみを選択肢として残して提示できるということになるかと思います。

    SKU単位なので、商品ごとよりも細かな指定ができます。
    他にも、カート内の商品合計金額がいくら以上とか、特定のSKUがカート内にない場合とか、色々条件はつけられます。SKUコードの先頭3文字がABCだったら、この支払方法を削除するとか、柔軟に対応できますね。
     同時に何種類かカートに入ったとして、支払方法がどんどん削られていき、最終的には、支払方法がすべて無くなってしまいます。そうならないように、別のカートでお買い物をして頂くようにメッセージを表示させます。

    フィルターフックは、usces_fiter_the_payment_method を用いています。

    配送方法も同じような要領で、SKUごとに制御できています。ご参考まで。

    Alicia
    参加者

    furuta 様 kurita 様

    プラグイン「クロネコ代金後払いサービス」につきましては、ver.2.1.10 にてヤマトの管理画面で半角カナに変換されて転送されているのを確認できました。

    迅速にご対応いただきまして、ありがとうございます。

    Alicia
    参加者

    furuta 様 kurita 様

    お世話になっております。
    プラグイン「クロネコ代金後払いサービス」ver.2.1.10 にて、ご対応いただきましてありがとうございます。

    【 1段階目のフィルター 】につきまして

    消費税区分が「税込」の場合 55,000 超で unset() となるのを確認できました。

    ただ、消費税区分が「税別」の場合、食品等を扱っておられる事業者様の場合、例えばカート内がすべて8%の場合は、実質 54,000 超で unset() となってしまうため、ここは注意が必要かと思います。

     今後のことを考慮しますと、税率が変更になったり複数税率の多段階構成自体が変更になっても対応できるようにするためには、消費税額を上乗せした税込み金額にすべて統一した上で、55,000 超で unset() にされた方が良いかもしれません。
     ヤマト側の取説や仕様書にも、「税別50,000円」など、表記ゆれが存在し非常に分かりづらい点が複数確認できたため、去年末に確認を取り今後マニュアルなどの訂正、統一をして行く運びという回答を得ております。

    【 2段階目のフィルター 】につきまして
    こちら、最初の投稿に私の誤解がありましたので訂正しお詫びします。
    元々は、自分で usces_filter_delivery_check を用いて 55,000 のフィルターを作っていたのですが、この件とは別に、Welcart 本体に設けられていたフィルターの文言を調整したい箇所があったため、丸ごと書き換えておりました。
    その際、 $mes = ''; と初期化してから丸ごと書き直したため、wcex_kuroneko_atobarai から出されている $mes ごと消してしまっていたようです。
    今回の、プラグイン「クロネコ代金後払いサービス」ver.2.1.10 にて、改めてコードの修正箇所を確認したところ、そもそも
    Welcart Shop クレジット決済設定 > 「クロネコ代金後払い」 > 「手数料」 にて上限額を正しく 「55,000 円」と設定できていた場合には、決済代金総額 55,000円のフィルターとして機能していたようですね。 こちら、上述の $mes の初期化が原因で、機能しておりませんでした。

    ヤマト側の「時々、Welcart 利用のケースで単一の加盟店だけで、55,000円を超える決済金額でオーソリ申請がくる」というのは、Welcart の設定で上限額を正しく 55,000 以下に設定できていない事業者がいるということになるのでしょうね。
     いずれにしましても、Welcart 側では、2段階目のフィルターが存在しなかったのではなく、事業者側が正しく上限を 55,000 以下に設定することを前提とした設計だったのではないかと想像しました。
     今回のアップデートで、事業者側が正しく設定しなかった場合であっても、強制的にヤマト側の規約上限55,000 以下となるフィルター(2.5段階目という表現が適しているかもしれません。)が追加されましたので、これを超えるオーソリ申請は皆無になると思います。ありがとうございました。

     私も、他にどのような Welcart専用プラグイン が $mes を追加してくるのか全容を把握していないため、 usces_filter_delivery_check で $mes を初期化した後で、丸ごと書き換えるのをやめて、
    $mes .=で追加だけに留めることに変更しました。

    いつも、迅速にご対応いただきまして感謝いたします。ありがとうございました。

    Alicia
    参加者

    furuta 様

    ご回答ありがとうございました。
    公式のデモも非対応でしたか。
    WCEX SKU Select を開いてみたら私の力量ではパンドラだったらしく、公式で既に対応しているテーマがあったら流されてみたいと思ってしまいました。
     今回、このカスタマイズのついでにSKU項目を10個拡張するなどやってみたのですが、WCEX SKU Select や WCEX Google Shopping を有効化すると上手くいかなかったので、まだまだ技術の底上げが必要なんだと思います。
     公式テーマでされているところまでは一応できましたので、この先はお楽しみに取っておきたいと思います。お気遣いありがとうございます。それにしても、かなり前から同様のカスタマイズをされている方がいるようですので、一定数のニーズはあるようですね。$product[‘_sku’]には、[‘size’][‘weight’][‘pict_id’]などシステム予約されてるようですので将来的にどうなっていくのか楽しみです。

    Alicia
    参加者

    furuta 様

    いつもお世話になっております。

    以前、

    親テーマであれば、Welcart Mode と Welcart Panetteria が、子テーマであれば、Welcart Beldad とWelcart VOLL が SKU画像表示に対応しています。

    と仰っている件で、その後新しい公式テーマがいくつか発表されていますが、SKU画像表示に対応されてますでしょうか?

    また、これら対応テーマのデモサイトを拝見しましたが、WCEX SKU Select を適用した商品詳細ページを見つけることができませんでした。探しようが悪いのかもしれないのですが、もしあるようでしたらページを教えていただけませんか。

    wc_item_single.php は、カスタマイズできたのですが、wc_sku_select.php の ajax で苦戦しております。もし対応している公式テーマがあるようでしたらご案内いただけないでしょうか。

    よろしくお願いいたします。

    ——————————————-
    テスト環境
    WordPress のバージョン:6.6.2
    Welcart のバージョン:2.11.10
    PHP のバージョン:8.1.29
    Welcart専用の拡張プラグインとバージョン:
    WCEX SKU Select 1.4.7
    ご利用の親テーマとバージョン : (TCD) EGO.1.15
    ご利用の子テーマとバージョン : EGO.Child 1.15
    症状を確認したブラウザ: Chrome (Win)
    サーバー【重要】:シンクラウド株式会社 シン・レンタルサーバー ベーシック
    ——————————————–

    Alicia
    参加者

    koike-r 様

    こんにちは。
    ???なクライアント様ですね。

    公式ではないので控えていましたが、ご高齢の方に限らずそもそも「領収書の意味」を知らない事業者の方が多いのも事実です。

    また、ヤマト側がいう「売上確定」という用語も、ヤマト側が精算処理を行う上での事業所側へ課した条件と捉えるのが適当で、Welcart 様公式が仰っているように、事業者が発行する領収書の発行の有無とは一切関係がありません。

    ヤマト側は、「クロネコWEBコレクト」での「売上確定」は、その形態によりそれぞれ異なっております。
    クレジットカード払い・・・出荷情報登録
    コンビニ(オンライン)払い・・・コンビニ店頭でのご入金(出荷情報登録は任意)
    キャリア払い/ID(PayPay)払い・・・与信承認を確認後「売上確定」処理(出荷情報登録は任意)

    です。Welcart では、コンビニとキャリア払いは対応しませんが、クレジットカード払いとID(PayPay)払いでは、クロネコヤマト配送とそれ以外で「売上確定」にするための操作が若干異なる程度で、基本的にはステータスを「発送済み」にすることで、ヤマト側の条件を満たす作りになっているように思います。Welcart で作成可能な領収書PDFは、条件となっていません。

     そもそも、クレジット払いは信用取引ですから、お客様から直接領収することはありませんので、領収書を発行することは有り得ません。ましてや、発送のタイミングでカード会社から受領することも有り得ませんから、受領していないタイミングで領収書なんて発行してはいけないものです。
     Welcart で発行できる領収書の日付は、便宜上受注日となってしまいますが、これは、クレジット払いの場合、本当の受領日はシステム側で情報をもっていないために、あくまで便宜上の領収日となっているのかと思います。
     法的に領収書に記載されるべき日付とは、まさにお客様から代金を事業者が受け取った日です。
    クレジット払いは信用取引ですので、受領日は未来の不確定日です。発送のタイミングでは、入金予定日しかわかりません。代金の受領を証明する受取証書=領収書は、本来発行すべきではないものです。

     クレジットカード払いに限らず、銀行振込に関しても現金等を受領するのは、カード会社や銀行ですので、領収書の発行主体でもありません。よってこれらの場合の領収書の発行は、法的にも義務ではありません。税務上も領収書なんてなくても、支払いの事実を証明できる代用書類(預金通帳など)があれば、問題ありません。

     ただ、そうはいうものの、理解のないお客様から領収書を求められることはしばしばありますので、「サービス」として発行する事業者は多いと思います。実体は無知から生まれる無駄な仕事です。この場合は、Welcart では領収書を発行できますので、お客様に対応してあげたいのであれば、任意で発行するだけのものとなります。但し、クレジット払いの場合は、領収書の但し書きに、その旨書かないと印紙税の対象となってしまう場合がありますから、従業員への教育も必要になります。

    私は、ECにおいて現金で受領することは絶対にありませんので、EC販売では領収書は一切発行していません。理由は「不要だから」です。

    昨今は、インボイスの関係で納品書だけは必要なときがあります。納品書なら発送段階でも紙で(信書にならないように注意が必要です)同封できますしね。

    当店では、カスタムオーダーフィールドに、

    「納品書PDF」をラジオボタンで ・不要・必要 (【商品発送のご連絡】メールに添付)

    を追加しています。紙での発行は、原則いたしません。

    他の事業所様では、どのようにされてますでしょうかね。気になります。
    ご参考になれば幸いです。

    Alicia
    参加者

    furuta 様 kurita 様

    お世話になっております。1点確認させてください。
    バグトラッカーを拝見しました。
    2段階目のフィルターだけの追加修正ということになってますが、Welcart基本設定が「税込」の場合、1段階目のフィルターは、55,000円ではなく50,000円でunset()されてないでしょうか?

    Alicia
    参加者

    furuta 様

    こちらこそ、いつもお世話になっておりましてありがとうございます。
    こちらに関してましては、私のAPI仕様書の読み込みが甘いところもあり、推測も入り込んでおります。申し訳ありませんが、お時間頂戴できましたらありがたいです。よろしくお願いいたします。

    Alicia
    参加者

    furuta 様

    いつもすみません。
    ご確認のためのお時間を頂戴し誠にありがとうございました。
    急ぎません。次回以降の修正の時にでも織り込んでいただけると幸いです。よろしくお願いいたします。

    Alicia
    参加者

    こちらにお心当たりはありませんか?

    会員ページに別の会員情報が表示されるのはなぜですか?

15件の投稿を表示中 - 16 - 30件目 (全184件中)