2026年5月12日火曜日

宿パターン修正

 https://schedule-nurse.blogspot.com/2026/05/q_6.html

仕様の解釈に誤りがありました。

日→宿→日は、正しくは、

日勤した後、宿直して(業務がなければ寝る)翌日日勤する、とのことです。なので、

1日目 |  2日目

(日宿)→日

が正しいシーケースになるとのことでした。従い、

下記のように、宿の前は日の✓を外します。





2026年5月11日月曜日

Q.購入したのに、サブスクリプションを購入しますか? が出てくる

 Q.登録したはずなのに、「サブスクリプションを購入しますか?」と出てくる

Ans.

スケジュールナースを使う場合には、登録したマイクロソフトアカウントになっている必要があります。

対処方法としては、

1)アカウントの課金を確認する(課金されているアカウントが登録したマイクロソフトアカウントです。)

https://schedule-nurse.blogspot.com/2026/04/q_10.html

2)1)状態であれば、間違いなく登録したアカウントになっています。その状態のままマイクロソフトアカウントのストアで、スケジュールナースを探しだし、そこから起動するのが確実です。



2026年5月10日日曜日

Q.2026年6月以降のカレンダが動かない

Q1 サブスクではなく買い切りです。

Q2CTRLきーを押しながらも反応しませんでした。

Q3再起動させても変わりませんでした。

先月と先々月作ったものを確認したのですが、2026年5月までは選択出来るのですが、

2026年6月から選択できませんでした。

使用している施設はxx病院です。

ヘルプから見れるビルド日時は2021年2月18日になっていました。


Ans.
xxさまが、お使いのエディションは、すでに廃止しており、カレンダが、2026年5月以降動きません。正規のライセンスをご購入頂いた全ての方には、既に移行手続きをお願いし、完了したところであります。

お持ちのエディションは、

■xx病院さま購入履歴がございません。
■ビルド日時(正規買い切り版は、自動更新です。現在のビルド日時は、2026年1月17日となっています。)

ことから、正規ライセンス品ではございません。

恐らくは、無償で提供していた時代の製品「許可なく」流用しているものと推察します。
従いまして、正規買い切り版への移行のご案内はいたしかねます。








2026年5月9日土曜日

ラベル設定法状況

 改善中途での状況です。instance24では、およそ150sec程度かかっており、LBまで1日では到達しません。未だ未だ改善が必要です。








2026年5月8日金曜日

月を跨いでの6連勤に注意

 入明休と入明入明休みが混在するパターンでは月を跨いでの6連勤に注意が必要です。

パターン1は、通常の2交代パターンです。 4連勤の後に入りで終わると、来月初日は明けとなり、必ず6連勤になってしまいます。

今回、日宿日パターンがあるので、宿の後さらに日が入る可能性があります。これは、パターン1に同じです。

また、入明入明休の場合は、さらに前の日から見る必要があります。

まとめると、次のような実装になると思います。



2026年5月7日木曜日

Q.入明休と入明入明休みの2パターンがある場合の記述の仕方

 Ans. 下のように状態遷移図を書いて考えます。


この結果、入りの後は、明けしかないことが分かります。また、明けの前は常に入りです。なので、この部分に関しては、2交代通常パターンを流用でOKです。

問題は、明けの後休みとなったり、再び入りとなる二つのパターンが存在することです。

明け後、(入りまたは休み)以外 を禁止にすることで対応出来ます。

入りまたは休みシフト集合を作ります。


また、パターンは2回までしか許容しないとのことなので、3回連続入りを禁止にすればOKです。

以上をまとめたのが次の記述となります。


テストは、適当に、予定を散りばめます。


解を確認して完了です。



2026年5月6日水曜日

Q.宿パターン

 Q.宿直に入る場合の基本パターンを日→宿→日→休にしたい。

Ans.

特殊なシフト「宿」を中心にして、その前後を考えます。すると、次のようなルールが浮かびます。


これを行制約として記述すれば、よいです。例えば、

宿の後は日は、(宿の後、日でない=✓マーク日)のは、禁止、

(宿の前、日でない=✓マーク日)のは、禁止

とします。
宿日休みは、日をブランクにしていますが、勿論、宿日と記述してもOKです。

これで、パターンのテストを行います。が、行制約として記述するだけでは、パターンが出現しないかもしれません。なので、予定として記述してみます。


これに対して、解は、


ちゃんと、日宿日休パターンになっています。

注意すべきは、今回設計したこのパターンは、ハード制約ということです。この制約をハードとすべきかソフトとすべきかは、勤務表ルールの設計者によります。