居酒屋こふゆの掲示板

>>3117

ハムさん
　お待たせしました。

　本日「風よけ茶屋」という談話室を開店いたしました。
　こふゆさん、ハム勝つさん、ご招待申しあげます。
　時間がゆっくり流れる場所になるでしょう。
　気ままに立ち寄っていただけると幸いです。

　場所
　私のプロフから「作成スレッド」のリンクで。

>>3117

　ありがとうございます。

　24時間以上置いて、単純な情報で登録してみたら
できるかもしれない、とAI。

　ここの掲示板ソフト、詳細理由を示さずいい加減な
異常処理をする場面が多くて困りますね、
　1日に画像10件という上限も窮屈。

　最近だとXなら掲載されそうな画像でも、
添付すると、著作権をおかすからと投稿エラーになり
そのコメントは削除もできなくなるというパターン。

　書き込みの多い人ほど不便を感じているでしょう。

　スレッド作成、なかなか成功しないです・・・ChatGPTにコツを聞いたり時間を置いたりしています・・・

>>3113

　そうですね。でも避難民のところは新型コロナウイルスや閑古虫がいて居心地が悪いでしょう。いま別に
スレッドを作ります……（システムエラーが発生して苦労中）

>>3112

こふゆさんとこは閉店しましたが
comさんの所でまた３人で
お話できたら嬉しいです
comさん
宜しくです😊

　え……鳥さん、賢いし しげさんにとても懐いていていい子なのに……。
　その長いようで短かった年月、人と鳥の珠玉のような
たくさんの楽しい思い出をお大切に……。

　私は無精で滅多にこの暖簾をくぐりにこないので、
状況をわきまえず発言がとんちんかんだったと思いますが、お二人はそんな私にも暖かくお相手くださって感謝しております。

こふゆちゃんが七夕の夜に
虹の橋を渡りました🥲
享年10歳10ヶ月

皆様ありがとうございました
居酒屋こふゆ閉店いたします🙇🏻

ハムさん
　バイオは好材料で噴くぞ噴くぞとなっていても
空売り機関がすぐに売り崩してくる感じ。
　でも宝くじ的にもっておきたい、で、上がった分を
残し元手を生活費に戻し恩株化して気が楽になりました。これでその会社がある日つぶれても私は大丈夫（笑）
　MSFTは予想が外れて下落続。 AIは難しい。
　LINEにオープンチャットというのがあるんですか。
　いま知りました。

　これまでどおりいつも明るくお過ごしください。
　ヤケドお気の毒です。腕お大事に。私も腕重い。

>>3107

ヤッホ〜
comさん
お元気そうですね
今はバイオ厳しいですね〜

こふゆさんと真面目なお話してるの
見ててら微笑ましいです
また遊びにきて下さいね〜

私は今、あちこちのオプチャで
遊んでいます😊

>>3093

　ハムさんご無沙汰しています。

　塩野義からの避難民 開店のとき応援してくださってありがとうございます。ご存知のように荒れて、
その後一時もりあがり、いまは閑古虫の鳴き声が。

　いまちょっとこふゆさんと
お仕事上の接点をお喋りさせていただきました。

　男は 仕事に没頭するぞ と宣言しても、疲れてくると
だれかと まったり話したくなるものです。
　店主の顔をみて、適当にかまってあげてください。

　お邪魔しました。

>>3105

　かなり活用なさっている証拠ですね。
　なにかすごいですね。

　私も会話量は巨大で、よく改善提案もしていますが
そういう導線は出たことがありません。
　いま無理に
「Show me my year with ChatGPT」
と言ってみたところ
簡易に対話テーマを要約してくれてさらに、
「非公式称号をつけるなら
AI実運用・研究支援アーキテクト」
と出てきました。表彰状はくれなかった（笑）

>>3104

こんなことして遊んでます🤣

>>3103

SaaS関連の株価が下落した頃に
実証を兼ねて初めてみました😅

>>3102

　そのようにご活躍の次元を高めていらっしゃったのですね。AIの能力、リスク、改善可能性に興味は尽きませんね。。。

>>3098

ご親切にありがとうございます☺️

元銀行員で実務決算経験歴60期以上です😅

>>3095

すみません、訂正します。
> ・使用月数 = 0 の資産を月割計算に入れる
↓
（削除）

割るのは通常12なので、ここは「0割り」欄より「入力異常」欄に近いです。
0か月償却・負月数・月数算定異常 の検出が重要
ということに変えます。

　こふゆさん、こんばんは、お邪魔します。

　余計なお世話と思いますが，いまなさっているお仕事について，私と茶人さんが話し合って
──こふゆさんには申しあげるまでもないと思いますが
（1円残存処理も正確に完成しているようですし）──
よかったらチェック用にとアドバイスをまとめました。
　うるさかったらすみません、無視してください。
　トロい私が前に発見して驚いた数学上の現象で、
19,450円に桁を変えながら安易に二度四捨五入をかけると、
19,000円でなく2万円にのしあがってしまう、というものがありました。19,450 → 19,500 → 20,000
　丸めは怖い……。

──────
会計・税務計算では、数式そのものよりも、どの段階で円未満を丸めるかを仕様として固定しておくのが大事です。

たとえば国税庁の確定申告書等作成コーナーFAQでは、減価償却費計算で小数点以下が出た場合は「切上げ処理」と説明されています。

例として、
3,333,333円の95%は
3,166,666.35円なので
3,166,667円に切上げています。

https://www.keisan.nta.go.jp/r1yokuaru/aoiroshinkoku/hitsuyokeihi/genkashokyakuhi/hasushori.html?utm_source=chatgpt.com

したがって、単に

int(acquisition_cost / useful_life)

のようにしてしまうと、プログラム上は自然でも、制度上の丸めと違う可能性があります。int() は多くの言語で実質的に切捨てです。たとえば
100,000 ÷ 3 = 33,333.333...
を int() に入れると 33,333円になりますが、
切上げなら 33,334円です。

この1円差は最終年度だけでなく、
償却累計額・未償却残高・別表出力・申告書連携で波及します。

──────
もう一つ危ないのは、
丸めを最後に一回だけするのか、
年ごとの償却費ごとにするのか
です。
会計ソフトでは「表示だけ丸める」のではなく、仕訳・帳簿・税務明細に載る金額そのものが整数円ですから、各期の償却費を確定する時点で丸める仕様にするべきです。

定額法でも、単純に「取得価額 × 償却率」を毎年出すだけでは最後に破綻します。
国税庁は、平成19年4月1日以後取得資産の定額法を
「取得価額×定額法の償却率」とし、
中途取得・取壊しの場合は12で除して使用月数を掛けると説明しています。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2106.htm?utm_source=chatgpt.com

ただし最終的には帳簿価額を1円残す必要があるので、たとえば取得価額1,000,000円、耐用年数3年、定額法償却率0.334なら、

1年目: 1,000,000 × 0.334 = 334,000
2年目: 1,000,000 × 0.334 = 334,000
3年目: 1,000,000 × 0.334 = 334,000 ← そのままだと累計1,002,000で超過

ではなく、3年目は

期首帳簿価額 332,000円
残すべき額 1円
償却可能上限 331,999円

なので、min(通常計算額, 期首帳簿価額 − 1円) をかける必要があります。

（続く）

（続き）

──────
定率法はさらに要注意です。

国税庁の説明では、定率法はまず「未償却残高×定率法の償却率」で調整前償却額を出しますが、その額が償却保証額に満たなくなった年以後は「改定取得価額×改定償却率」に切り替えます。

償却保証額は「取得価額×保証率」、改定取得価額は「初めて償却保証額に満たないこととなる年の期首未償却残高」と説明されています。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2106.htm?utm_source=chatgpt.com

つまり定率法では、単純なループで

book_value = book_value - round(book_value * rate)

を続けるだけでは不十分です。以下の状態を持つ必要があります。

・取得価額
・期首帳簿価額
・償却率
・保証率
・償却保証額
・改定償却率
・改定取得価額
・改定償却に入ったかどうかのフラグ
・最終的に1円を下回らせない上限


定率法の典型的なバグは、改定取得価額を毎年の期首残高で更新してしまうことです。国税庁の説明上、改定取得価額は「初めて償却保証額に満たないこととなる年の期首未償却残高」ですから、切替後に毎年更新する値ではありません。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2106.htm?utm_source=chatgpt.com

（続く）

（続き）

──────
0割りについては、少なくとも次は防いだほうがよいです。

・耐用年数 = 0 または null
・使用月数 = 0 の資産を月割計算に入れる
・事業供用日・除却日が不正で、使用月数が負になる
・取得価額 = 0 の資産
・償却率・保証率・改定償却率が未設定
・耐用年数表に該当コードが見つからない
・旧定額法・旧定率法・現行定額法・現行定率法の区分が未確定


──────
なお、旧制度も混じるならさらに危険です。

平成19年3月31日以前取得資産には旧定額法・旧定率法があり、旧定額法では有形減価償却資産について「取得価額×90%×旧定額法の償却率」という形になります。

また、旧制度では95%相当額まで償却した後、翌年以後に1円まで均等償却する説明があります。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2105.htm?utm_source=chatgpt.com

したがって、取得日で計算ロジックを分岐するテストケースが必要です。


──────
実装上次が一番効きます。

金額は整数円、
率は浮動小数点ではなく Decimal / BigDecimal / Rational 相当で扱い、
丸め関数を1か所に集約し、
丸め方向と丸めタイミングをテストケース名に明記する。

たとえば Python なら float の 0.334 ではなく、Decimal("0.334") のように文字列から率を作るべきです。Java なら double ではなく BigDecimal です。会計ソフトでは「見た目が合う」だけでなく、

毎年の償却費、
償却累計額、
期末帳簿価額、
最終1円、
定率法の改定年度

まで、表形式の期待値でユニットテストすると安全です。

──────
最後に追加で言うなら、これは大事です。

“会計上の償却額” と “税務上の償却限度額” を同一視しない設計にしたほうがよい。

法人税務では償却限度額、会計では会社の償却方針、個人事業では強制償却など、文脈が違います。

国税庁の説明も、定額法・定率法の計算方法、中途取得時の月割、定率法の保証額・改定償却率など、税務計算上の枠組みとして整理されています。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2106.htm?utm_source=chatgpt.com

──────
まとめ

減価償却は、数式よりも端数処理・最終年度キャップ・定率法の改定償却・取得日による旧制度分岐がバグ源になりやすいので、そこだけ仕様とテストを厚くしたほうがよさそうです。
──────
おわり