Normal #10769
静波導入(玉城用)
Description
今回のまとめ
発端: paymentsテーブルにreceipt_id=162(reservation_id=37, r0710, amount=-44580円, memo="OTA差分調整:事前カード決済")という、身に覚えのないマイナス金額のレコードが見つかった。
調査:
ログ(fuel/mydocs/tamaki/本番ログ/2026-07-17.php)から、sitecontrollercollaboration.phpのupdateAccountingDataFromSiteController()が呼ぶUtil_Payments::insertDifferentialScPayment()(第5リリースで追加)が自動生成したレコードだと特定。
この関数は「既存SC支払い合計(sc_flg=1)」と「work_check_in.total_accommodation_charge - discount_total_accommodation_charge」を比較し、差があれば補正payを作る仕組み。
比較対象のtotal_accommodation_charge/discount_total_accommodation_chargeはOTA連携で毎回上書きされる値であり、手動修正は保護されないことも確認(Util_TemairazuDataConversion::checkin()が無条件SETしているため)。
一連の会計更新フロー(SC売上再作成→差分計上→⑰現地払い残高再計算)を追った結果、Util_Reservation::recalcDiscountFromSalesAndPayments()がdiscount_total_accommodation_chargeのみをsales実績で再計算し、total_accommodation_chargeを更新していないという不整合を発見。これによりtotal_accommodation_chargeが古い値のまま残り、次回のSCバッチ実行時に本来不要な「OTA差分調整」payが誤って作成される経路があることが分かった。
対応: fuel/app/classes/util/reservation.phpのrecalcDiscountFromSalesAndPayments()を修正し、discount_total_accommodation_chargeと同じUPDATEでtotal_accommodation_chargeもsales実績値($sales_total)でセットするよう変更。コミットa8c8a7c36(未push、ローカルmasterがorigin/masterより1コミット先行)。
未確認事項: 元のreceipt_id=162自体が実際にこの不整合経路で生成されたのか(r0710予約37のpayments/salesの実データ)は、DBを直接見ないと断定できない。必要であれば確認用SQLを用意する。
Subtasks
Related issues
Updated by 
