Тут в процессе бурного обсуждения одной проблемы родилась небольшая идейка.
Задача: представлять пользователю только новые поступления.

Размышления: Есесьно, что хочется делать это не руками, а автоматом. Первое, что приходит на ум, это использовать пакатные задания Администратора и заливать в какую-то базу NEW только новые поступления. Но вот незадача. Он работает только с целой базой. Тогда может быть что-то подобное можно было сделать с глобальной корректировкой. Теотетически попробовать можно, но опять же в конечном итоге человеческий фактор не исключается. А ведь именно его исключить и хочется. Тогда почему-то провелась параллель с реляционными VIEW, которые позволяют показывать пользователю только часть таблиц, а не все полностью.
Мозг подумал-подумал да и решил предложить такой вариант дополнения к системе. Оформляется обычная база данных (почти обычная), но в качестве mst используется какая-то другая база. Причем все записи предварительно проходят через АЛКОД (с) by АСК. Код конечно же на языке форматирования и по функционалу - это обычный ФЛК. Если результат 0, то запись попадает в базу-надстройку. Если 1 - запись недоступна и вообще не видна. Если 2 - запись попадает, но ее корректировка не возможна. Хотя с 2 будут проблемы я подразумеваю. По этому этот пункт можно выкинуть вообще.

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

Ваше мнение?

Проблема мной также поднималась, но с "другого бока". Я предлагал когда-то сделать некий файл условий, который бы отбирал записи на показ результатов поиска, т.е. скрытый запрос "И".
Было у меня в жизни условие не показывать в результатах поиска записи, где нет экземпляров, т.е. что были списаны, но библиотекари знают, что докомплектование должно быть, но заказа нет. Т.е. такие записи в базе присутствуют, но показывать их в результате поиска не стоит, т.е. сделать условие на формат brief.
Я тогда предлагал сделать параметр в ini файл (или добавить в блоки секции search) дополнтельный запрос, который бы умножался логически с запросом пользователя.
В противном случае мне просто пришлось переделать файл fst (что собственно и было сделано, не дождавшись).
Проблему показа новой литературы можно решить именно таким способом, т.е. "умножением запроса пользователя на скрытый запрос". А скрытый запрос отвечает за конкретную функцию. Например, провести поиск ТОЛЬКО среди заглавий журналов (т.е. сделать динамический список выписанных журналов и поиск по нему).
Хотя на Web такие фичи реализовать не сложно. Другое дело - АРМ Каталогизатор или Читатель.
Относительно логики использования АЛКОДа, тут вообще идеи безграничны, т.к. в АЛКОД можно зашить любую информацию и, дешифруя ее, получать любые свойства показа документа. Хотя, честно можно сказать, что если АЛКОД получается в автомаическом режиме, то этот алгоритм можно спокойно перенести в сам формат просмотра.

Ну я тоже сначала подумал сделать дубли всех режимов поиска с усечением ненужных. Но в этом случае нужно создавать копии всех словарей в базе и при этом еще и создавать словарь заново КАЖДЫЙ ДЕНЬ. Это еще ничего если база меленькая, а если база большая, то размер словаря сильно увеличивается и сохранение документа будет идти в 1.5-2 раза медленнее.
Не проще ли сделать фильтр для записей в окне просмотра (там где BRIEF). Тут фильтр именно на попадание записи в список нужен, а не фильтр на BRIEF.
Сложного в этом ничего нет. Сделать так же, как сортировка в этом списке, но назвать ФИЛЬТР. Запарамерировать его в INI и все. Если не нужно кому-то показывать все записи, то фильтр пусть устанавливается автоматом без возможности изменения.

Ну и я про тоже "гутарил".

Задача совершенно не надумана, а ее реализация очень пригодилась бы всем
Идея автоформирования БД новых поступлений здесь впервые была высказана, как обычно, мной :) Но способ ее реализации, как обычно, я не предложил :)
Если ничего не путаю, то его, как обычно, предложил уважаемый Александр Сергеевич
Уважаемый Александр Сергеевич! Опять привожу цитату из Вас:

"вполне возможно создать условие, которое будет выдавать на корректировку все записи, созданные в течение последних, например 5-ти дней.
(if v907^a>f(rsum(&uf('3'),'-5'),1,0) then ... fi/)
и прописать их для корректировки, либо вводить при корректировке в качестве переменной %1"

Или это не то? А если это то — видимо, годится не только для корректировки? Нужно еще добавить автоудаление записей, созданных, например, более двух месяцев назад

Жаль, что так ничего и не слышно...