会計年度試算表が算出できるなら、月次試算表も簡単にいけるはずということで、元のクラスに追記。


public static function getTrialBalanceByMonth(string $dateStr): array|bool
{
  try {
    if (! self::isExistCutoffDate($dateStr)) {
      throw new \Exception($dateStr.' is not cutoff date ');
    }

    $sqlstring = str_replace(':QUERYTYPE', '締日', self::$sqlstring);
    $sqlstring = str_replace(':WPARAM1', 'where 締日 < ? ', $sqlstring);
    $sqlstring = str_replace(':WPARAM2', 'where 締日 <= ? ', $sqlstring);
    $sqlstring = str_replace(':WPARAM3', '?::date as 締日,', $sqlstring);
    $sqlstring = str_replace(':WPARAM4', 'where 締日 = ? ', $sqlstring);
    $sqlstring = str_replace(':WPARAM5', 'where 締日 = ? ', $sqlstring);

    Log::debug($sqlstring);

    return DB::select($sqlstring, [$dateStr, $dateStr, $dateStr, $dateStr, $dateStr]);
  } catch (\Exception $e) {
    Log::error($e->getMessage());
    return false;
  }
}

テストに


public function test_get_trial_balance_by_month(): void
{
  $response = KaikeiWorkModel::getTrialBalanceByMonth('2100/12/31');
  $this->assertFalse($response);

  $response = KaikeiWorkModel::getTrialBalanceByMonth('2024/12/31');
  $this->assertTrue(is_array($response));
  if (is_array($response)) {
    echo $response[0]->締日;
  }
}

これで何となく上手くいっているように見えたし、B/S科目については問題が無かったのですが、P/L科目について、このアプローチでは、まず上手くいかない事がわかりました。
月次試算表のP/L科目は、会計年度期首を０とし、当月の頭は、期首から前月末までの累計、月末は当月を含む期首からの累計とならないとダメなのですが、できあがった状態は、P/Lが正に当月だけの状態を（数値としてそれは正しいのですが）表しているだけで。
その理由を探すと、試算表の元になっている

private static $sqlstring="

--前略

cte_zenki_touki
as(
select distinct :WPARAM3
科目コード,
case when 要素名 in('収益', '費用') then 0 else 前残 end as 前残,
case when 要素名 in('収益', '費用') then 当期残 -前残 else 当期残 end as 残高
from cte_zenki
join kaikei.view_勘定科目補助科目 kk on 科目コード = kk.勘定科目コード
full outer join cte_touki using( 科目コード)

--後略

の部分が問題なののです。

これは困った状況で、

大元となるkaikei.trans_仕訳明細には、貸借、科目、金額があるのみ
その金額が、勘定科目を増加させるのか減少させるのかを加味したkaikei.view_仕訳_明細_増減を作成
その増減の総体を合計することで、勘定の残高を算出しよう

という考え方自体が月次の試算表でのP/L科目の前残や、当残では使い物にならないということです。
しかしながら、上記の考え方で、月次試算表P/L科目以外はちゃんと機能しているということは捨てがたいし、kaikei.trans_仕訳明細のデータの持ち方を変えるのは一から作り直すに等しい作業になってしまいます。
現状の、kaikei.trans_仕訳明細のデータの持ち方のシンプルさは、例えば利用しているソフトと作成中の会計ソフトの主客が逆になった場合生きるだろうし、B/S科目とP/L科目で、kaikei.trans_仕訳明細の持ち方や、kaikei.view_仕訳_明細_増減の定義をどう変えれば良いのかも思い浮かばない状態です。締日基準で純粋に見れば、試算表の算出結果それ自体は誤りを含んでいる訳ではないのだし。

ここで単一SQLの微調整で何とかしようという考え方を放棄することになりました。