Всем привет!

Был регистр сведений с периодичностью в день, затем стал в секунду.

С новыми записями проблем нет, а вот как быть со старыми, как отловить какая запись была сделана раньше, а какая позже, если период у обоих 01.03.2017 00:00:00. То есть как получить самую последнюю запись...

Понимаю, тут может помочь момент времени, так и не хватило тямы нарисовать что-то стоящие...

Смог сравнить по моменту времени, пишет равно... видимо, старых записей, с периодом в день, записывались в один момент времени.

Есть какие идеи, как это победить ?

(1)Попробуй сравнивить момент времени регистратора, это конечно тоже так себе идея. Но в целом все, вариантов нет. Ты и до изменения периодичности не мог узнать какая запись была раньше, если у нее совпадал период.

(2) Так регистратор одинаковый для записей... но вравнил на всякий случай... равно)

Записи регистра делались в разный момент, но регистратор был один и тот же...

(3) вручную поставьте, то что нужно, да и всё. Ну понятно же, что вы каких-то странных вещей хотите.

невозможно записать две одинаковые записи в один момент времени

(5) да они походу разные у него

(6) ну, вот пусть и разбирается что к чему

(5) Я вроде и не писал что они одинаковые, они в один день сделаны. Регистр не подчинённый регистратору.

Это регистр статусов:
Измерение:
документ
пользователь
ресурс:
статус

до изменения регистр был с периодичностью ДЕНЬ, то есть в один день разные пользователи меняют статус и в регистре за один день две записи... теперь СЕКУНДА и вопрос на текущий момент один: как анализировать старые записи, какая из них была раньше, а какая позже сделана... потому-что если регистр был день, у всех старых записей период начало дня...

(0) "Был регистр сведений с периодичностью в день, затем стал в секунду." Я бы...
1. Не менял регистр,а завёл новый
2. Не имеет смысл смотреть старую информацию под новым углом
3. Самое главное - в сабже не сформулирована задача или техзадание для этого регистра. Если статусы связаны с работой документа, то можно часть данных прочитать в журнале регистрации.
..
"Фарш невозможно провернуть назад"

(8) а какой смысл определять кто из пользователей раньше сделал запись? Если есть острая необходимость это знать, то Пользователя надо было в ресурс пихать, или в реквизит

(9) Я с Вами согласен, но старые данные тоже нужны.

Просто раньше регистр был для определения статуса и он изредка работал не правильно и этого никто не замечал. Поняли это когда начали формировать отчёты на основании регистра.

А задача очень простая: приходные накладные, если переделка, то статус СТОП, если нормальный документ или привезли переделанный документ, то статус ОПЛАТА...

(9) За подсказку про журнал спасибо... расследуем)

(10) Ну накосячили)) Теперь хлебаем)

(13) + ещё и давно было... по идеи периодичность тоже должны была быть СЕКУНДА изначальна... но видимо, тогда был важен только последний статус...

(11) Что означает переделка? Зачем помнить, что было с документом по секундам? Важен окончательный статус. В подобных случаях неплохо использовать бизнес процессы по обработке документов.

(15) Не довезли/разбили/пересортили товар, необходимо переделать и получить новый документ. В народе документ обзывается "переделка"... но причины бывают разные: некорректный адрес, забыли один документ из пакета документов и тп. пока поставщик не вернёт "чистый" документ, в программе ставиться статус стоп...

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

(16) но если эту историю не вели? То какая разница чего они хотят? Надо забыть про это, перевернуть страницу и с сегодняшнего дня вести всё правильно.

(17) Да так мы и сделали, но вылез не большой косяк старой реализации регистра. Если два разных пользователя меняли статус в один день, то какой статус подставляется ? Да абы какой! Поэтому возник вопрос, как выяснить какой из них последний. Таких ситуаций было единицы, поэтому сразу не заметили. А когда начали формировать реестры по 1000 документов и опа... вроде как нашли решение, оно решает, но не полностью.

(18) если бы регистр был спроектирован правильно, то регистр был бы не периодическим, документ был бы измерением, статус ресурсом, а время изменения реквизитом.
где у вас что?

(18) зачем выяснять, какой последний? Может пользователь пил кофе в это время, поэтому ввел позже. То есть его не последний по времени, а на самом деле правильный. Последний - это необязательно тот, что нужно.

(19) не, туплю.. статус тоже в измерения, а время в ресурсы. получится регистр истории реквизита

Эпитафия: "МоментВремени в регистре сведений. Регистр не подчинённый регистратору."

(18)Все решения будут костылями, которые так и будут тянуться от неправильного периода.
вариант 1: завести новый регистр. Всем старым документам поставить какой-нибудь завершающий статус махом, чтобы отрезать.
вариант 2: посадить мартышку исправить вручную все двойные записи.

Лучше, конечно, вариант 1 с правильной пректировкой регистра, перекачкой информации и исправлением по варианту 2.

(пессимизм)
Фишка решения ТС в том, что изменяя периодичность, вероятность факта возникновения нескольких записей в одном периоде - изменяется... но не исключается.

В подобных случаях (16) я однажды сделал так: записать документ пользователь может только под своим именем. Так же можно сделать и со статусом. Кто последний тот и виноват. И не надо танцев с периодикой.

(25) Мимо темы

+(25) Вместо статуса используем типовой реквизит Проекты (это КА 1.1)

(26) Объясни

(28) "А задача очень простая: приходные накладные, если переделка, то статус СТОП, если нормальный документ или привезли переделанный документ, то статус ОПЛАТА"(ТС)

В один день две записи (ОПЛАТА и СТОП). Авторы этих записей известны. Вопрос темы : "Какой статус документа на конец дня или на начало следующего?"

(29) Я про то же..Сделай регистр сведений НЕПЕРИОДИЧЕСКИМ. Останется только одна запись. А при записи регистра пиши автора=текущий пользователь.

Нет смысла хранить историю действий. Важен только последний статус.

(30)У него сейчас не стоит проблема "как сделать". У него сейчас проблема - разобраться со старыми записями.

Ёпрст. Мимоходящий совсем тему не читал :)

(32) Даже если он решит проблему со старыми записями, то это никак не отменяет моё мнение: хранить историю статусов не надо.
(33) Ты заблуждаешься. Я читать умею. Именно поэтому задал уточнющие вопросы ТС.
...
Наша с тобой дискуссия перешла в философскую плоскость. Либо решать задачу так как сказали, либо предложить решение, которое больше отвечает здравому смыслу. Дело вкуса. Решать не нам , а ТС.

Имхо, нужна обработка, которая выявляет записи в одном периоде, получает структуру подчиненности документа, анализирует её и проставляет время в найденных записях, расставляя их по порядку.

"Наша с тобой дискуссия перешла в философскую плоскость" -любой конкретный вопрос, требующий решения, можно перевести из области поиска решения в область философии. вот только боюсь тогда придётся бомжевать в бочке, подобно Диогену :)

Философический вопрос: "Почему в конфигурациях есть документы, но нет документооборота?"

(36) Потому что это не предусмотрено в бухгалтерской отчетности.

МимохожийОднако. Ситуация. Звонит глабух, бухгалтеру и говорит, что поставщик ругается что у него стоп оплата, а он всё переделки привёз. Бухгалтер проверила и в правду всё нормально и поменяла статус. Звонит обратно главбуху и говорит, что всё исправила, а та возьми и спроси, а кто виноват?. Кого наказывать ? Кому внушение делать ? Это просто пример, можно ещё придумать/вспомнить, но зачем. История статусов нужна! Мысли вслух: а там ещё и комментарий о причине смены статуса...

Пытаемся решит тему которой нет: каким должен быть регистр. Уже придумали и внедрили новый/старый регистр. Как быть со старыми записями, они нужны, но в другом виде. Я подумал , что у них есть момент времени и тем самым проблема уже решена. Но увы...

(22) То есть у записей регистра без регистратора нет момента времени?

(38) ни у какого регистра нет момента времени. Это вы реально учудили, задавая вопрос.

(38) Я уже писал, что можно сделать:
1. Кто последний сохранил документ - тот и виноват. Для этого достаточно запретить менять чужой документ без смены автора на себя.
2. Комментарий можно писать в регистр сведений о статусах в реквизит записи.
3. Автора смены статуса также можно записывать в реквизит регистра сведений.
4. Для остальной и подробной информации достаточно обязать административно писать служебную записку и прикладывать к пакету документов.
..
На вопрос кто виноват программа не ответит никогда. Программа не думает.

(39) Мы друг друга, видимо, не понимаем... я не знал, а вы знали и думали, что я тоже знаю)

РегистрСведенийЗапись.<Имя регистра сведений>.МоментВремени (InformationRegisterRecord.<Имя регистра сведений>.PointInTime)
РегистрСведенийЗапись.<Имя регистра сведений> (InformationRegisterRecord.<Имя регистра сведений>)
МоментВремени (PointInTime)
Синтаксис:

МоментВремени()
Возвращаемое значение:

Тип: МоментВремени.

Описание:

Получает момент времени, соответствующий записи регистра. Применяется для регистров сведений, для которых в Конфигураторе установлен режим записи "Подчинение регистратору".

Доступность:

Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).

(41) ну это момент времени берется из регистратора. А у самого регистра ничего нет.

(40)
1. Опять мы про регистр, а не записи... мы этот вопрос уже решили, структура регистра определена. Кто последний ? Интересные у вас рассуждения. Тогда никто прикасаться не будет к документам в программе. А если человек уволен или в отпуске, а если подразделений полсотни ?
2,3. в (5) структура регистра...
4. ...удалить 1С и ездить на лошадях - прекрасные времена кстати :)

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

(41) потом, вы совершенно не в курсе, что такое момент времени. Момент времени - это не последнее время, а скорее первое.

(44) Объясните.

Если было записано 5 документов в одну секунду, то момент времени это в каком порядке эти документы были записаны в эту секунду... это в моём примитивном понимании

(43) Я предложил то, что у меня в одной контор работает. Ты рассматриваешь только программную сторону. Это твоё право. В конце концов добьёшься нужного.
.. Лошади, удалить 1С и т.п. только твои додумки и эмоции.
Мои предложения основываются только на том,что выход на административные решения (взыскания, поощрения, и т.п.) лежат в основном в плоскости административной. 1С, регистры и т.п. только удобный инструмент. Я, когда приступаю к определенному заданию, стремлюсь рассматривать задачу в комплексе. Быть просто кодером в узких рамках ТЗ я не приемлю. Если конечно на этом не настаивает Заказчик. Его деньги - его пожелания. Философия вместо "нормального ответа"? Да. Но как быть решать только тебе. Прошу прощения за многословность.

(43)Ну, если объективно, структура регистра у вас действительно для ваших задач не оптимальная. И выше уже сказали, что углубленная детализация записей при текущей структуре не обезопасит вас от наличия двух записей в одном периоде.

(46)Вы не правы. Есть моменты, когда историю хранить надо. Например, у меня история абсолютно всех действий должна храниться регламентно. И эти правила не моя организация устанавливает.

(45) нет, если документ, например от первого января. Пользователь открыл его, понаделал там делов, понакуролесил и записал. Потом вы смотрите этот документ, а у него момент времени первое января. Как и был. Вот нафиг вам сдался этот момент в этом случае.

(48) Я согласен. В каждом монастыре свой устав. Но ТС не хочет вносить изменения в регистр. Я кстати дал рекомендации, которые работают. Достаточно добавить автора даже для периодического регистра. Но запись регистра к делу не пришьёшь.Всё равно будет выход на служебные записки и т.п. Именно на этом я сделал акцент. Сабж похож на баянистые темы по доступу к определенным данным и т.п.

(48) хранение информации о статусе документа и хранение истории изменения этого статуса - это две разные задачи.
Решать их при помощи одного регистра -это, ИМХО, дебилизм, демонстрируемый автором ветки с упорством, достойным лучшего применения.
Решить задачу одним регистром конечно можно, но для этого придётся заводить отдельный суррогатный документ - что-то типа "Изменение статуса", который будет двигать наш регистр.
В таком случае появится возможность выстроить записи в регистре на временной оси по моменту времени. Причем никакими другими документами этот регистр двигаться не должен.
Другой вариант - добавить измерение, которое обозвать, например, "МоментВремени" (не путать с понятием Момент времени) с типом Число(15) и заполнять его при записи в регистр значением ТекущаяУниверсальнаяДатаВМиллисекундах(). Это опять таки позволит выстраивать записи в регистре в хронологическом порядке по Период + МоментВремени.

(45) Момент времени = Период + Ссылка.
С периодом всё понятно - это обязательное измерение периодического регистра.
Со ссылкой сложнее. Это ссылка на документ-регистратор. Ссылка - это УИД. У одного вида документов каждый новый документ получает очередной УИД. Если все записи в регистре формируются документами только одного вида (регистратором может выступать только один вид документа), то проблем нет. УИДы выстраиваются в последовательность - как их создавали в базе данных. Однако, когда регистратором могут быть документы разного вида (несколько регистраторов у регистра), то при упорядочивании документов с одинаковым периодом (созданных в одну секунду) сначала будут все документы одного вида, потом другого, потом третьего и т.д. То есть они будут упорядочены не по мере того как создавались хронологически в базе данных, а сначала по видам, а потом по  хронологии. Причем заранее предсказать какого вида документы будут вначале, а какого в конце, невозможно. Еще хуже, когда у Вас есть РИБ и УИДы присваиваются в различных информационных базах. Порядок таких документов (их УИДов), сформированных в одну и ту же секунду в разных узлах РИБ вообще непредсказуем.
То есть надо понимать, что упорядочивание по моменту времени в 1С это весьма условное понятие. И для данного конкретного случая вряд ли подходит.

(51) Очень много нужных/ненужных/лишних слов :)

Можно всё вышесказанное "сократить" до совета добавить в регистр измерение для значения ТекущаяУниверсальнаяДатаВМиллисекундах(). С предупреждением: это решение не исключает вероятность возникновения проблем при определённых обстоятельствах.

Я бы посоветовал историю изменений хранить в регистре (измерения: документ, точное время; ресурсы: статус; реквизиты: пользователь), а текущее актуальное значение статуса - в самом документе.

(52) >> Очень много ... слов

Старался быть кратким насколько это возможно, учитывая полную некомпетентность адресата.
А так по сути - в (52) всё верно.

(51)Ну не знаю. У меня в подобной задаче просто документ является единственным измерением. Это физически исключает два статуса одновременно.

(53) Всё верно, в принципе, сказано... кроме фразы "Решать их при помощи одного регистра - это..." - это было излишне эмоционально :)

В типовых много периодических регистров сведений, которые решают одновременно эти две задачи: первая(основная) - получение состояния на определенный момент времени и вторая- хранение истории. В УПП, например, это аналоги номенклатуры, основные спецификации и тех.карты номенклатуры и т.д.

И кстати, мне есть что добавить на тему РИБ :)
В РИБе, например, типовой функционал версионирования объектов тоже становится "неоднозначным" решением.