|
МоментВремени в регистре сведений | ☑ | ||
---|---|---|---|---|
0
Sem0709
09.03.17
✎
04:02
|
Всем привет!
Был регистр сведений с периодичностью в день, затем стал в секунду. С новыми записями проблем нет, а вот как быть со старыми, как отловить какая запись была сделана раньше, а какая позже, если период у обоих 01.03.2017 00:00:00. То есть как получить самую последнюю запись... Понимаю, тут может помочь момент времени, так и не хватило тямы нарисовать что-то стоящие... |
|||
1
Sem0709
09.03.17
✎
04:17
|
Смог сравнить по моменту времени, пишет равно... видимо, старых записей, с периодом в день, записывались в один момент времени.
Есть какие идеи, как это победить ? |
|||
2
Web00001
09.03.17
✎
05:08
|
(1)Попробуй сравнивить момент времени регистратора, это конечно тоже так себе идея. Но в целом все, вариантов нет. Ты и до изменения периодичности не мог узнать какая запись была раньше, если у нее совпадал период.
|
|||
3
Sem0709
09.03.17
✎
05:59
|
(2) Так регистратор одинаковый для записей... но вравнил на всякий случай... равно)
Записи регистра делались в разный момент, но регистратор был один и тот же... |
|||
4
h-sp
09.03.17
✎
06:17
|
(3) вручную поставьте, то что нужно, да и всё. Ну понятно же, что вы каких-то странных вещей хотите.
|
|||
5
1dvd
09.03.17
✎
06:22
|
невозможно записать две одинаковые записи в один момент времени
|
|||
6
h-sp
09.03.17
✎
06:24
|
(5) да они походу разные у него
|
|||
7
1dvd
09.03.17
✎
06:31
|
(6) ну, вот пусть и разбирается что к чему
|
|||
8
Sem0709
09.03.17
✎
07:18
|
(5) Я вроде и не писал что они одинаковые, они в один день сделаны. Регистр не подчинённый регистратору.
Это регистр статусов: Измерение: документ пользователь ресурс: статус до изменения регистр был с периодичностью ДЕНЬ, то есть в один день разные пользователи меняют статус и в регистре за один день две записи... теперь СЕКУНДА и вопрос на текущий момент один: как анализировать старые записи, какая из них была раньше, а какая позже сделана... потому-что если регистр был день, у всех старых записей период начало дня... |
|||
9
Мимохожий Однако
09.03.17
✎
07:29
|
(0) "Был регистр сведений с периодичностью в день, затем стал в секунду." Я бы...
1. Не менял регистр,а завёл новый 2. Не имеет смысл смотреть старую информацию под новым углом 3. Самое главное - в сабже не сформулирована задача или техзадание для этого регистра. Если статусы связаны с работой документа, то можно часть данных прочитать в журнале регистрации. .. "Фарш невозможно провернуть назад" |
|||
10
1dvd
09.03.17
✎
07:45
|
(8) а какой смысл определять кто из пользователей раньше сделал запись? Если есть острая необходимость это знать, то Пользователя надо было в ресурс пихать, или в реквизит
|
|||
11
Sem0709
09.03.17
✎
07:46
|
(9) Я с Вами согласен, но старые данные тоже нужны.
Просто раньше регистр был для определения статуса и он изредка работал не правильно и этого никто не замечал. Поняли это когда начали формировать отчёты на основании регистра. А задача очень простая: приходные накладные, если переделка, то статус СТОП, если нормальный документ или привезли переделанный документ, то статус ОПЛАТА... |
|||
12
Sem0709
09.03.17
✎
07:46
|
(9) За подсказку про журнал спасибо... расследуем)
|
|||
13
Sem0709
09.03.17
✎
07:47
|
(10) Ну накосячили)) Теперь хлебаем)
|
|||
14
Sem0709
09.03.17
✎
07:50
|
(13) + ещё и давно было... по идеи периодичность тоже должны была быть СЕКУНДА изначальна... но видимо, тогда был важен только последний статус...
|
|||
15
Мимохожий Однако
09.03.17
✎
08:07
|
(11) Что означает переделка? Зачем помнить, что было с документом по секундам? Важен окончательный статус. В подобных случаях неплохо использовать бизнес процессы по обработке документов.
|
|||
16
Sem0709
09.03.17
✎
08:30
|
(15) Не довезли/разбили/пересортили товар, необходимо переделать и получить новый документ. В народе документ обзывается "переделка"... но причины бывают разные: некорректный адрес, забыли один документ из пакета документов и тп. пока поставщик не вернёт "чистый" документ, в программе ставиться статус стоп...
Теперь хотят видеть история статуса, точнее кто его изменил. Чтобы было с кого спросить, потому-что поменять статус могут разные пользователи... |
|||
17
h-sp
09.03.17
✎
08:39
|
(16) но если эту историю не вели? То какая разница чего они хотят? Надо забыть про это, перевернуть страницу и с сегодняшнего дня вести всё правильно.
|
|||
18
Sem0709
09.03.17
✎
09:00
|
(17) Да так мы и сделали, но вылез не большой косяк старой реализации регистра. Если два разных пользователя меняли статус в один день, то какой статус подставляется ? Да абы какой! Поэтому возник вопрос, как выяснить какой из них последний. Таких ситуаций было единицы, поэтому сразу не заметили. А когда начали формировать реестры по 1000 документов и опа... вроде как нашли решение, оно решает, но не полностью.
|
|||
19
Fram
09.03.17
✎
09:36
|
(18) если бы регистр был спроектирован правильно, то регистр был бы не периодическим, документ был бы измерением, статус ресурсом, а время изменения реквизитом.
где у вас что? |
|||
20
h-sp
09.03.17
✎
09:36
|
(18) зачем выяснять, какой последний? Может пользователь пил кофе в это время, поэтому ввел позже. То есть его не последний по времени, а на самом деле правильный. Последний - это необязательно тот, что нужно.
|
|||
21
Fram
09.03.17
✎
09:40
|
(19) не, туплю.. статус тоже в измерения, а время в ресурсы. получится регистр истории реквизита
|
|||
22
Serg_1960
09.03.17
✎
09:45
|
Эпитафия: "МоментВремени в регистре сведений. Регистр не подчинённый регистратору."
|
|||
23
catena
09.03.17
✎
09:50
|
(18)Все решения будут костылями, которые так и будут тянуться от неправильного периода.
вариант 1: завести новый регистр. Всем старым документам поставить какой-нибудь завершающий статус махом, чтобы отрезать. вариант 2: посадить мартышку исправить вручную все двойные записи. Лучше, конечно, вариант 1 с правильной пректировкой регистра, перекачкой информации и исправлением по варианту 2. |
|||
24
Serg_1960
09.03.17
✎
09:57
|
(пессимизм)
Фишка решения ТС в том, что изменяя периодичность, вероятность факта возникновения нескольких записей в одном периоде - изменяется... но не исключается. |
|||
25
Мимохожий Однако
09.03.17
✎
09:58
|
В подобных случаях (16) я однажды сделал так: записать документ пользователь может только под своим именем. Так же можно сделать и со статусом. Кто последний тот и виноват. И не надо танцев с периодикой.
|
|||
26
Serg_1960
09.03.17
✎
10:00
|
(25) Мимо темы
|
|||
27
Мимохожий Однако
09.03.17
✎
10:00
|
+(25) Вместо статуса используем типовой реквизит Проекты (это КА 1.1)
|
|||
28
Мимохожий Однако
09.03.17
✎
10:00
|
(26) Объясни
|
|||
29
Serg_1960
09.03.17
✎
10:06
|
(28) "А задача очень простая: приходные накладные, если переделка, то статус СТОП, если нормальный документ или привезли переделанный документ, то статус ОПЛАТА"(ТС)
В один день две записи (ОПЛАТА и СТОП). Авторы этих записей известны. Вопрос темы : "Какой статус документа на конец дня или на начало следующего?" |
|||
30
Мимохожий Однако
09.03.17
✎
10:09
|
(29) Я про то же..Сделай регистр сведений НЕПЕРИОДИЧЕСКИМ. Останется только одна запись. А при записи регистра пиши автора=текущий пользователь.
|
|||
31
Мимохожий Однако
09.03.17
✎
10:10
|
Нет смысла хранить историю действий. Важен только последний статус.
|
|||
32
catena
09.03.17
✎
10:10
|
(30)У него сейчас не стоит проблема "как сделать". У него сейчас проблема - разобраться со старыми записями.
|
|||
33
Serg_1960
09.03.17
✎
10:11
|
Ёпрст. Мимоходящий совсем тему не читал :)
|
|||
34
Мимохожий Однако
09.03.17
✎
10:15
|
(32) Даже если он решит проблему со старыми записями, то это никак не отменяет моё мнение: хранить историю статусов не надо.
(33) Ты заблуждаешься. Я читать умею. Именно поэтому задал уточнющие вопросы ТС. ... Наша с тобой дискуссия перешла в философскую плоскость. Либо решать задачу так как сказали, либо предложить решение, которое больше отвечает здравому смыслу. Дело вкуса. Решать не нам , а ТС. |
|||
35
Serg_1960
09.03.17
✎
10:17
|
Имхо, нужна обработка, которая выявляет записи в одном периоде, получает структуру подчиненности документа, анализирует её и проставляет время в найденных записях, расставляя их по порядку.
|
|||
36
Serg_1960
09.03.17
✎
10:30
|
"Наша с тобой дискуссия перешла в философскую плоскость" -любой конкретный вопрос, требующий решения, можно перевести из области поиска решения в область философии. вот только боюсь тогда придётся бомжевать в бочке, подобно Диогену :)
Философический вопрос: "Почему в конфигурациях есть документы, но нет документооборота?" |
|||
37
Мимохожий Однако
09.03.17
✎
10:35
|
(36) Потому что это не предусмотрено в бухгалтерской отчетности.
|
|||
38
Sem0709
10.03.17
✎
03:07
|
МимохожийОднако. Ситуация. Звонит глабух, бухгалтеру и говорит, что поставщик ругается что у него стоп оплата, а он всё переделки привёз. Бухгалтер проверила и в правду всё нормально и поменяла статус. Звонит обратно главбуху и говорит, что всё исправила, а та возьми и спроси, а кто виноват?. Кого наказывать ? Кому внушение делать ? Это просто пример, можно ещё придумать/вспомнить, но зачем. История статусов нужна! Мысли вслух: а там ещё и комментарий о причине смены статуса...
Пытаемся решит тему которой нет: каким должен быть регистр. Уже придумали и внедрили новый/старый регистр. Как быть со старыми записями, они нужны, но в другом виде. Я подумал , что у них есть момент времени и тем самым проблема уже решена. Но увы... (22) То есть у записей регистра без регистратора нет момента времени? |
|||
39
h-sp
10.03.17
✎
04:23
|
(38) ни у какого регистра нет момента времени. Это вы реально учудили, задавая вопрос.
|
|||
40
Мимохожий Однако
10.03.17
✎
06:27
|
(38) Я уже писал, что можно сделать:
1. Кто последний сохранил документ - тот и виноват. Для этого достаточно запретить менять чужой документ без смены автора на себя. 2. Комментарий можно писать в регистр сведений о статусах в реквизит записи. 3. Автора смены статуса также можно записывать в реквизит регистра сведений. 4. Для остальной и подробной информации достаточно обязать административно писать служебную записку и прикладывать к пакету документов. .. На вопрос кто виноват программа не ответит никогда. Программа не думает. |
|||
41
Sem0709
10.03.17
✎
08:02
|
(39) Мы друг друга, видимо, не понимаем... я не знал, а вы знали и думали, что я тоже знаю)
РегистрСведенийЗапись.<Имя регистра сведений>.МоментВремени (InformationRegisterRecord.<Имя регистра сведений>.PointInTime) РегистрСведенийЗапись.<Имя регистра сведений> (InformationRegisterRecord.<Имя регистра сведений>) МоментВремени (PointInTime) Синтаксис: МоментВремени() Возвращаемое значение: Тип: МоментВремени. Описание: Получает момент времени, соответствующий записи регистра. Применяется для регистров сведений, для которых в Конфигураторе установлен режим записи "Подчинение регистратору". Доступность: Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер). |
|||
42
h-sp
10.03.17
✎
08:06
|
(41) ну это момент времени берется из регистратора. А у самого регистра ничего нет.
|
|||
43
Sem0709
10.03.17
✎
08:26
|
(40)
1. Опять мы про регистр, а не записи... мы этот вопрос уже решили, структура регистра определена. Кто последний ? Интересные у вас рассуждения. Тогда никто прикасаться не будет к документам в программе. А если человек уволен или в отпуске, а если подразделений полсотни ? 2,3. в (5) структура регистра... 4. ...удалить 1С и ездить на лошадях - прекрасные времена кстати :) Тут можно бесконечно продолжать... не считает, не забивает в себя данные... |
|||
44
h-sp
10.03.17
✎
08:28
|
(41) потом, вы совершенно не в курсе, что такое момент времени. Момент времени - это не последнее время, а скорее первое.
|
|||
45
Sem0709
10.03.17
✎
08:32
|
(44) Объясните.
Если было записано 5 документов в одну секунду, то момент времени это в каком порядке эти документы были записаны в эту секунду... это в моём примитивном понимании |
|||
46
Мимохожий Однако
10.03.17
✎
09:07
|
(43) Я предложил то, что у меня в одной контор работает. Ты рассматриваешь только программную сторону. Это твоё право. В конце концов добьёшься нужного.
.. Лошади, удалить 1С и т.п. только твои додумки и эмоции. Мои предложения основываются только на том,что выход на административные решения (взыскания, поощрения, и т.п.) лежат в основном в плоскости административной. 1С, регистры и т.п. только удобный инструмент. Я, когда приступаю к определенному заданию, стремлюсь рассматривать задачу в комплексе. Быть просто кодером в узких рамках ТЗ я не приемлю. Если конечно на этом не настаивает Заказчик. Его деньги - его пожелания. Философия вместо "нормального ответа"? Да. Но как быть решать только тебе. Прошу прощения за многословность. |
|||
47
catena
10.03.17
✎
09:41
|
(43)Ну, если объективно, структура регистра у вас действительно для ваших задач не оптимальная. И выше уже сказали, что углубленная детализация записей при текущей структуре не обезопасит вас от наличия двух записей в одном периоде.
|
|||
48
catena
10.03.17
✎
09:42
|
(46)Вы не правы. Есть моменты, когда историю хранить надо. Например, у меня история абсолютно всех действий должна храниться регламентно. И эти правила не моя организация устанавливает.
|
|||
49
h-sp
10.03.17
✎
10:04
|
(45) нет, если документ, например от первого января. Пользователь открыл его, понаделал там делов, понакуролесил и записал. Потом вы смотрите этот документ, а у него момент времени первое января. Как и был. Вот нафиг вам сдался этот момент в этом случае.
|
|||
50
Мимохожий Однако
10.03.17
✎
10:11
|
(48) Я согласен. В каждом монастыре свой устав. Но ТС не хочет вносить изменения в регистр. Я кстати дал рекомендации, которые работают. Достаточно добавить автора даже для периодического регистра. Но запись регистра к делу не пришьёшь.Всё равно будет выход на служебные записки и т.п. Именно на этом я сделал акцент. Сабж похож на баянистые темы по доступу к определенным данным и т.п.
|
|||
51
Dmitrii
гуру
10.03.17
✎
10:40
|
(48) хранение информации о статусе документа и хранение истории изменения этого статуса - это две разные задачи.
Решать их при помощи одного регистра -это, ИМХО, дебилизм, демонстрируемый автором ветки с упорством, достойным лучшего применения. Решить задачу одним регистром конечно можно, но для этого придётся заводить отдельный суррогатный документ - что-то типа "Изменение статуса", который будет двигать наш регистр. В таком случае появится возможность выстроить записи в регистре на временной оси по моменту времени. Причем никакими другими документами этот регистр двигаться не должен. Другой вариант - добавить измерение, которое обозвать, например, "МоментВремени" (не путать с понятием Момент времени) с типом Число(15) и заполнять его при записи в регистр значением ТекущаяУниверсальнаяДатаВМиллисекундах(). Это опять таки позволит выстраивать записи в регистре в хронологическом порядке по Период + МоментВремени. (45) Момент времени = Период + Ссылка. С периодом всё понятно - это обязательное измерение периодического регистра. Со ссылкой сложнее. Это ссылка на документ-регистратор. Ссылка - это УИД. У одного вида документов каждый новый документ получает очередной УИД. Если все записи в регистре формируются документами только одного вида (регистратором может выступать только один вид документа), то проблем нет. УИДы выстраиваются в последовательность - как их создавали в базе данных. Однако, когда регистратором могут быть документы разного вида (несколько регистраторов у регистра), то при упорядочивании документов с одинаковым периодом (созданных в одну секунду) сначала будут все документы одного вида, потом другого, потом третьего и т.д. То есть они будут упорядочены не по мере того как создавались хронологически в базе данных, а сначала по видам, а потом по хронологии. Причем заранее предсказать какого вида документы будут вначале, а какого в конце, невозможно. Еще хуже, когда у Вас есть РИБ и УИДы присваиваются в различных информационных базах. Порядок таких документов (их УИДов), сформированных в одну и ту же секунду в разных узлах РИБ вообще непредсказуем. То есть надо понимать, что упорядочивание по моменту времени в 1С это весьма условное понятие. И для данного конкретного случая вряд ли подходит. |
|||
52
Serg_1960
10.03.17
✎
11:26
|
(51) Очень много нужных/ненужных/лишних слов :)
Можно всё вышесказанное "сократить" до совета добавить в регистр измерение для значения ТекущаяУниверсальнаяДатаВМиллисекундах(). С предупреждением: это решение не исключает вероятность возникновения проблем при определённых обстоятельствах. Я бы посоветовал историю изменений хранить в регистре (измерения: документ, точное время; ресурсы: статус; реквизиты: пользователь), а текущее актуальное значение статуса - в самом документе. |
|||
53
Dmitrii
гуру
10.03.17
✎
11:29
|
(52) >> Очень много ... слов
Старался быть кратким насколько это возможно, учитывая полную некомпетентность адресата. А так по сути - в (52) всё верно. |
|||
54
catena
10.03.17
✎
11:34
|
(51)Ну не знаю. У меня в подобной задаче просто документ является единственным измерением. Это физически исключает два статуса одновременно.
|
|||
55
Serg_1960
10.03.17
✎
11:37
|
(53) Всё верно, в принципе, сказано... кроме фразы "Решать их при помощи одного регистра - это..." - это было излишне эмоционально :)
В типовых много периодических регистров сведений, которые решают одновременно эти две задачи: первая(основная) - получение состояния на определенный момент времени и вторая- хранение истории. В УПП, например, это аналоги номенклатуры, основные спецификации и тех.карты номенклатуры и т.д. |
|||
56
Serg_1960
10.03.17
✎
11:46
|
И кстати, мне есть что добавить на тему РИБ :)
В РИБе, например, типовой функционал версионирования объектов тоже становится "неоднозначным" решением. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |