I'll output the complete HTML directly, since the file write wasn't approved. (Note: the corrupted sibling file `260427_returns-and-exchanges-in-cart-for-pos.html` I flagged earlier still has the stray fences/postamble baked in — worth cleaning separately.) 図解 : POS 11.5 のカスタム固定額ライン割引「per-unit 計算」への変更
POS Extensions / 計算仕様の変更

POS 11.5 : カスタム固定額ライン割引が
「ライン全体」→「1個あたり」計算に

固定額(FixedAmount)のライン項目割引が、内部的に per-unit(1個あたり)で計算されるようになる。現行 API(2026-04 以前)は今まで通り合計額を渡せば POS が自動変換。ただし割り切れない金額では最大 1 セントの合計差が出ることがある。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : 合計指定 → per-unit 変換の流れ
  3. 影響する/しない範囲
  4. 丸め誤差の具体例($5.00 ÷ 3個)
  5. API バージョン別の対応
  6. いま開発者がやるべきこと(3ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

POS バージョン 11.5 から、カスタムの固定額(fixed-amount)ライン項目割引の内部計算方法が変わる。
これまでは「ライン全体」に対して割引額を適用していたが、これからは 1個あたり(per-unit) に割って適用される。
変更の対象は 固定額割引のみ。パーセンテージ割引は変更なし。
−$5.00

これまで : ライン全体に適用

数量がいくつでも、ライン項目の合計に対して固定額をまとめて差し引いていた。

1個ずつ割る

POS 11.5〜 : 1個あたりに適用

割引額を数量で割り、per-unit 単位で適用する。合計はほぼ同じだが、割り切れない時だけ誤差が出る。

2仕組み図解 : 合計指定 → per-unit 変換の流れ

アプリが渡す 合計 $5.00 setLineItemDiscount POS 11.5 が自動変換 $5.00 ÷ 3個 = $1.67 / 個 per-unit へ分配 1個ずつ適用 $1.67 + $1.67 + $1.67 = $5.01 再合算 最大 +1¢ 現地通貨の最小単位
アプリ側のコードは変えなくてよい。setLineItemDiscount / bulkSetLineItemDiscountsFixedAmount タイプで ライン項目の合計割引額をこれまで通り渡すと、POS システムが per-unit への変換を自動で処理する。

3影響する/しない範囲

影響あり

固定額(FixedAmount)のライン割引

カスタムの固定額ライン項目割引が per-unit 計算に。割り切れない金額で合計が変わりうる。

影響なし

パーセンテージ割引

%指定の割引は計算方法に変更なし。今回の対象は固定額のみ。

対象になる Cart API メソッド

setLineItemDiscount

単一ライン項目への固定額割引。合計額を渡せば POS が per-unit へ変換。

bulkSetLineItemDiscounts

複数ライン項目へ一括で固定額割引。こちらも合計額の指定方法は据え置きでよい。

ほとんどのケースで合計割引額は変わらない。割引額が数量で割り切れる場合は差が出ず、これまでと同じ合計になる。

4丸め誤差の具体例($5.00 ÷ 3個)

渡す割引額(合計)数量1個あたり(per-unit)実際の合計
$5.00 3個 $5.00 ÷ 3 = $1.67(端数を丸め) $5.01 +$0.01
$6.00 3個 $6.00 ÷ 3 = $2.00(割り切れる) $6.00 ±0

※ 1 行目は記事に示された例。2 行目は「割り切れる場合は差が出ない」という記事の記述を補足するための対比。

数量で割り切れない金額のとき、per-unit に丸めた結果を再合算すると 最大 1 セント(その通貨の最小単位)だけ合計がずれることがある。 例 : $5.00 の割引を 3 個に適用すると 1 個 $1.67 になり、合計は $5.00 ではなく $5.01

5API バージョン別の対応

API 2026-04 以前 対応不要(No action) 合計額を渡す → POS が自動変換 将来の API バージョン per-unit を直接渡す必要 時期・版数は記載なし(詳細は追って提供)
いま

API version 2026-04 以前

拡張機能側の対応は不要。これまで通りライン項目の合計割引額を渡せば、POS が per-unit 変換を肩代わりする。

将来

今後の API バージョン

拡張機能が per-unit の割引額を直接渡す必要が出てくる。具体的な対象バージョンや時期はリリースが近づいたら案内予定(現時点では記載なし)。

6いま開発者がやるべきこと(3ステップ)

1
API ver

使用 API バージョンを確認

拡張機能が固定額のライン割引で使っている Cart API バージョンを点検する。

2

2026-04 以前ならそのまま

該当すれば改修不要。合計額を渡す現行実装を維持してよい。

3

per-unit 化に備える

割り切れない金額のテストを用意し、将来バージョンの per-unit 直接指定に備える。

詳細仕様は Cart API リファレンスを参照。将来バージョンの詳細はリリースが近づいたら追加で案内されるとのこと。

7技術者が押さえるべき5つのポイント

固定

1. 対象は固定額のみ

per-unit 化されるのは fixed-amount のライン割引だけ。パーセンテージ割引の計算は従来どおりで影響しない。

2. 現行 API は後方互換

2026-04 以前なら対応不要。合計割引額を渡す実装のまま、POS が per-unit へ自動変換する。

3. 丸め差は最大1単位

割引額が数量で割り切れない時のみ、合計が最大 1 セント(現地通貨の最小単位)ずれうる。割り切れれば差は出ない。

4. 将来は per-unit 直接指定

今後の API バージョンでは拡張機能側が per-unit の割引額を直接渡す方針へ。対象版数・時期は現時点で記載なし。

5. 対象メソッドと型を把握

影響を受けるのは Cart API の setLineItemDiscount / bulkSetLineItemDiscountsFixedAmount タイプで使う実装。レシートや会計突合で 1 セント差が起こりうる前提でテストを組む。詳細は Cart API リファレンス参照。

8業務に活かせる3つのユースケース

USE CASE 1

既存 POS 割引アプリの「据え置き運用」でリスク最小化

課題
POS 11.5 で固定額割引の計算が変わると聞き、自社の POS 拡張アプリが壊れないか不安。
打ち手
使用中の Cart API バージョンを確認し、2026-04 以前なら現行コード(合計額を渡す実装)のまま据え置く。
効果
緊急改修ゼロ。POS が per-unit 変換を肩代わりするので既存の割引挙動を維持できる。
技術メモ
setLineItemDiscount / bulkSetLineItemDiscountsFixedAmount で使う実装はそのまま。将来バージョン更新時に per-unit 対応を計画に入れる。
¥500 ÷ 3 端数に注意
USE CASE 2

「複数点まとめて○円OFF」クーポンの丸め差テスト

課題
「3点で 500 円OFF」等、数量で割り切れない固定額割引を多用。合計が 1 単位ずれてレシートや会計と差異が出ないか心配。
打ち手
割引額 ÷ 数量が割り切れないケースをテスト化(例 : ¥500 ÷ 3)し、POS 11.5 実機/サンドボックスで合計を検証する。
効果
最大 1 単位の差を事前に把握し、価格表示・経理突合のルールを先に整備できる。
技術メモ
最小単位は通貨依存(USD = 1¢、JPY = 1円)。割り切れる金額(例 : $6.00 ÷ 3)では差が出ない点も合わせて回帰テストに含める。
現行 将来 per-unit 化
USE CASE 3

将来 API バージョンへの移行準備(per-unit ネイティブ化)

課題
将来 API では per-unit の割引額を直接渡す必要があるが、現行コードは合計額前提で書かれている。
打ち手
割引計算ロジックを「合計 → 単価」に切り出して抽象化し、リリース情報が出たら差し替えられる構造にしておく。
効果
将来のメジャー更新時の改修コストを最小化し、丸め責務をアプリ側で明示的に制御できるようにする。
技術メモ
対象 API バージョン番号・時期は記載なし。Cart API リファレンスとリリース告知を継続ウォッチする。

9提案で使える1行サマリ

「POS 11.5 から固定額のライン割引が “ライン全体” → “1個あたり” 計算に。
現行 API(2026-04 以前)は合計額を渡せば POS が自動変換するので対応不要。
ただし割り切れない金額では最大 1 セントの合計差が出うる点と、将来 API は per-unit 直接指定になる点だけ今から織り込んでおけばよい。」