Коллеги, подскажите как правильнее с точки зрения избегания возможных будущих проблем, описать возможность работы с контрактом с клиентом.

Речь об учетной системе, если что.

По сути у меня выбор между тремя вариантами:
- Состояние контракта. Т.е., упрощая - Работает/Не работает.
- Период действия контракта. Даты начала и окончания.
- И то, и другое.

При этом в системе есть понятие "Рабочий день", который может отличаться от астрономической даты. Т.е. если "рабочий день", допустим, 01.01.2015, а актуальная дата 20.01.2015, то действия в системе отражаются 20-м числом.
Но, есть нюанс, который меня смущает - во-первых контракт с внешним клиентом, то есть клиент понятия не имеет о "рабочих днях" нашей системы. С его точки зрения дата начала действия наступила - его контракт уже действует. И наоборот - наступила (астрономически) дата окончания - в системе, как мне кажется, нельзя регистрировать действия по клиенту, даже если "рабочий день" в периоде действия контракта. Возможно что я и не прав со вторым утверждением, не берусь судить.

Дополнительную путаницу вносит то, что есть тестовые инстансы, на которых "рабочие дни" вообще никогда не совпадают с астрономическими.

Чем не нравится только состояние - его придется переключать вручную.
Нельзя заранее задать дату начала, чтобы при ее наступлении (тут доп.вопрос - "рабочий день" или астрономический должен наступить?) система сама уже понимала, что контракт рабочий. То же с датой окончания.

Чем не нравится только период - проблемы с работой на тестовых инстансах.

И то, и другое - никак не могу понять как все-таки учитывать и "рабочие дни", и астрономические. Сделать состояние функциональным типом и вычислять его в зависимости от "рабочих дней" + учитывать астрономические?

Наверняка есть на эту тему есть какие-то статьи, но я не знаю.
Ткните в какую сторону рыть.

Косноязычно объяснил, прошу прощения.
"Рабочий день" никакого отношения к табелю или календарям не имеет.
Это, условно, дата которой регистрируются операции в системе.
Т.е. стоит сейчас рабочий день 01.09.2015 - учетные документы в системе регистрируются именно этой датой, независимо от астрономической.
Давайте я лучше назову это операционным днем.

Кот Матроскин474,
Имхо "Дата начала" и "дата окончания" явно лучше, чем состояние. Проблемы с тестовыми инстансами мне кажутся несколько надуманными.
А считать в этом случае по "операционным дням" системы или по астрономическим?

Был на практике случай когда из-за проведения технических работ в выходные поставили в системе "операционный день" на следующий понедельник (так надо было).
В случае использования только перода для определения актуальности контракта, может оказаться так, что контракт с датой окончания "в понедельник" будет нерабочим если сравнение производить с "операционным днем" системы. И если система в этом случае производит какие-то действия, то она их произведет нелегитимно, в общем-то. Ведь астрономическая-то дата еще только суббота!

C тестовыми инстансами такая же проблема, но она будет возникать гораздо чаще, т.к. там даты операционных дней почти всегда с астрономическими расходятся.

Кот МатроскинЭто вопрос к бизнес-аналитику Вашей системы :) "Что такое операционный день и как надо считать срок действия договоров?"
Некому его задать, к сожалению.
Кот МатроскинЧто касается Вашего примера - похоже что у Вас на "операционный день" навешаны противоречивые функции. Если может быть описанная Вами ситуация "Операционный день нужен N, а считать действие договора нужно по M" - то, вероятно, нужны 2 разные сущности.
Ммм... Какие?
Кот Матроскинхотя вообще не очень понятно - если все действия в системе будут помечены понедельником - то что такого "нелигитимного" с договором система может сделать в субботу?
Например, система может отправить уведомление клиенту, что его договор уже не работает. С точки зрения клиента это, как минимум, странно. За окном ведь суббота и договор еще сегодня и завтра в силе.

guest_20040621Не может. Никакой разницы, как устанавливается дата регистрации - по умолчанию или явно. В любом случае она должна сравниваться с конечной датой жизненного цикла сущности.
Как же "не может"?!
Вы же сами пишете, что "Никакой разницы, как устанавливается дата регистрации" и что "она должна сравниваться с конечной датой жизненного цикла сущности".
Ну вот и получается, что "дата регистрации" в системе установлена послезавтра, а конечная дата ЖЦ тоже послезавтра. Ergo система решит, что сущность мертва, несмотря на то, что за окном не послезавтра, а сегодня.

ViPRos,
посмотрите все сообщения темы.

Я уже писал, что "рабочий день" это моя оговорка и правильнее писать "операционный день".

Извините, что всех запутал.
Никакого отношения к календарю эти дни не имеют.

guest_20040621У вас есть машина времени, которая может переносить документы из "послезавтра" в "сегодня"? :) Но даже на этот случай всё корректно: последний день жизненного цикла ничем не отличается от других.
У нас есть причины иногда операционный день в системе устанавливать в будущее, в т.ч. и в послезавтра.
А поскольку система, в основном, оперирует операционным днем, извините за каламбур, то и будет думать, что контракт уже не действует, т.к. "послезавтра". Хотя, на самом деле, "сегодня".

В итоге, решил последовать советам Кота и по месту решать на какую дату смотреть - либо операционного дня, либо астрономическую.
Ваше замечание об одностороннем расторжении договора мне тоже понравилось, так что состояние оставлю, но без переключения его автоматически в зависимости от дат.