Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

РегистрСведений, многие ко многим, очистить из записей СрезПоследних - как?

РегистрСведений, многие ко многим, очистить из записей СрезПоследних - как?
Я
   Минона
 
10.07.19 - 15:16
Есть конкретная задача - вести учёт оборудования на рабочих местах, по сути ОС.
Выбрали решение Регистр сведений с 2мя измерениями - РабочееМесто и ОС.
Периодический.

Но никак не можем решить под-задачу "Что происходит при уходе ОС?"
Т.е. надо сделать "выбытие" ОС с этого рабочего места
и (!!) сделать так, чтобы в срезе последних не было записи, т.е. чтобы итоговая таблица СрезПоследних была полегче.
История при этом сохранится, из-за периодичности.

Или вообще решение не то (тогда направьте в другую сторону) или непонятно как сделать именно "удаление" записи соответствия РабМесто+ОС на Период.
 
 
   butterbean
 
1 - 10.07.19 - 15:23
а чо не регистрНакопления?
   Минона
 
2 - 10.07.19 - 15:26
накапливать особо нечего, каждое ОС - уникально (инв. и серийный номер)
Разве что писать  +1  и -1
Если не получится РегСведений - то конечно накопление сделаем
   butterbean
 
3 - 10.07.19 - 15:31
(2) ну сделайте вообще без регистра, какой-нибудь реквизит в справочнике ОС меняйте и всё
   butterbean
 
4 - 10.07.19 - 15:32
(3)+ или таб часть с историей
   Минона
 
5 - 10.07.19 - 15:44
не очень подходит, есть подзадачи, типа "Сотрудники <-> Рабочие места"
Поэтому хотелось бы единообразно, регистром.
   Cyberhawk
 
6 - 10.07.19 - 15:54
"чтобы итоговая таблица СрезПоследних была полегче" при наличии там записей не получится
   zwolf
 
7 - 10.07.19 - 15:54
(5) Заведите рабочее место "Корзина"
   Минона
 
8 - 10.07.19 - 15:56
(6) т.е. получается, что из РегистраСведений периодического удалить некую запись соответствия из СрезаПоследних - невозможно, так?
   Cyberhawk
 
9 - 10.07.19 - 15:59
(8) Срез последних для простоты (не берем в расчет таблицу итогов среза последних в новых релизах платформы) считай что это виртуальная таблица, строится по основной таблице. Соответственно, пока есть записи в регистре, то и в срез они будут попадать.
   ИУБиПовиц
 
10 - 10.07.19 - 16:12
А у вас что, миллионы записей в регистре будут, что хотите полегче регистр?
Попробуйте сделать реквизит  - статус (В работе, выбыл) и срез последних делайте с условие не выбыл.
 
 Рекламное место пустует
   Минона
 
11 - 10.07.19 - 16:34
(10) Миллион, не миллион, а архитектуру продумывать надо заранее.
Сам принцип пытаюсь понять.

(9) Так работаем то на свежих релизах.
Пытаемся выбрать именно "правильное решение", задача то обычная, может есть какие рекомендации - как именно хранить подобные данные.
   Cyberhawk
 
12 - 10.07.19 - 16:45
(11) Чтобы продумать архитектуру, надо знать процесс во всех точках на трех уровнях: ввод данных, их изменение и их получение
   Минона
 
13 - 10.07.19 - 16:55
(12) Документом вводят 2 вида комплектации - "Рабочее место + ОС" или "Сотрудник + Рабочее место"
Документом перемещают, 2 вида операции - ОС на другое рабочее место, либо сотрудника на другое рабочее место, либо отмечают выбытие ОС, увольнение сотрудника, "закрытие" рабочего места.
Получение - это отчёты, об истории движения ОС, либо о сотруднике - где сейчас работает/ ранее работал и какие ОС на этом рабочем месте.
   Cyberhawk
 
14 - 10.07.19 - 16:57
Остаточный регистр накопления тогда: ввод рабочего места в плюс, выбытие / закрытие - в минус, перемещение - плюс-минус
   Cyberhawk
 
15 - 10.07.19 - 16:57
Недостаток: со сверткой регистра потеряется история
   ptiz
 
16 - 10.07.19 - 17:06
(15) А вы не сворачивайте.
   Жан Пердежон
 
17 - 10.07.19 - 17:18
(11) так выключите итоги тогда
   Rovan
 
18 - 10.07.19 - 17:31
(+7) да.... или признак "Выбыл (Списан)"
   Минона
 
19 - 10.07.19 - 17:38
(17) Итоги регистра сведений где выключаются? Вы про СрезПоследних ?
   Жан Пердежон
 
20 - 10.07.19 - 17:59
(19) в конфигураторе
а ещё вот это неплохо почитать
https://its.1c.ru/db/v8std#content:708:hdoc
   Минона
 
21 - 10.07.19 - 18:14
(20) Спасибо за информацию.

Но нам как раз НУЖЕН СрезПоследних, чтобы быстро определять "Кто где сидит и каким компом пользуется", по при этом мы не хотим перегружать РегСведений лишними записями в СрезПоследних.
   palsergeich
 
22 - 10.07.19 - 18:23
(21) Ужас какой.
А нас потом на партнерке за такие решения и не слушают.
   palsergeich
 
23 - 10.07.19 - 18:28
По методологии 1С, ну по краней мере что нам там втирают Ваша задача решается 2 РС.
1) История ОС. Измерения РабочееМесто и ОС Периодический или нет, на вкус
2) Текущиее мето ОС Измерение ОС Ресурс - Рабочее место, дата ввода
Это 1 с детка.
   Garykom
 
24 - 10.07.19 - 18:30
(0) Связь Один (Рабочее место) ко Многим (ОС)

ОС в измерение, Рабочее место в ресурс.
Завести служебное рабочее место (списано) и для списанных ОС его устанавливать.
   palsergeich
 
25 - 10.07.19 - 18:30
(23) Ну соответственно если в п1) регистр непериодитеский - то надо в ресурс запихать дату. Но скорее всего периодичность тут уже не нужна. И в ресурс же надо записать что то ТипДвиженияОС.
Оба регистра - подчиненные регистратору.
   Garykom
 
26 - 10.07.19 - 18:31
(23) (25) Слишком сложно когда можно проще (24)
   Жан Пердежон
 
27 - 10.07.19 - 18:31
(21)
СрезПоследних у вас будет в любом случае;
Лишние" записи" только у вас в голове, для РС они совсем не лишние;
одна запись на каждый выбывший объект в таблице итогов - такая "перегрузка" даже обсуждения этого не стоит
   palsergeich
 
28 - 10.07.19 - 18:31
(24) Не, канонично 2 регистра.
Один историю
2ой - оперативное состояние.
Это более правильно
   Garykom
 
29 - 10.07.19 - 18:32
(28) Зачем когда достаточно одного регистра и для истории и для состояния?
   palsergeich
 
30 - 10.07.19 - 18:40
(29) При большом количестве ОС и Рабочих мест - потенциальная опасность
   palsergeich
 
31 - 10.07.19 - 18:42
(30) В плане производительности.
Если хранить срез последних расчитанным - долгая запись.
Если вычислять, особенно не с детализацией конкреноеОС\конкретное рабочее место, тоже опасность
   palsergeich
 
32 - 10.07.19 - 18:44
(31) А так будут и волки сыты и овцы целы.
Притом гарантируб, там кучу всяких еще служебных полей, которые в задаче не обозначены, но 100% будут
   Garykom
 
33 - 10.07.19 - 18:47
(31) Срез последних лучше банально реквизитом в справочнике у ОС хранить, куда текущее рабочее место записано ))
 
 
   palsergeich
 
34 - 10.07.19 - 18:49
(33) Вот смотри.
Перемещение ОС - документ.
Документом меняешь Рабочее место -> меняешь реквизит справочника.
А потом берешь и отменяешь проведение документа.
Что будет?
1) Говня, когда данные не совпадают с реальными учетными.
2) Много кода, что бы это предотвратить
+ Постоянное дергание справочникОбъект.
   palsergeich
 
35 - 10.07.19 - 18:53
(34) я уже не говорю о возможности менять реквизит справочника намеренно или случайно.
Да с 2 мя регистрами при отмене проведения без доп кода никак, но его будет минимум.
   Garykom
 
36 - 10.07.19 - 18:55
(34) При отмене берем из РС предыдущее место
   Garykom
 
37 - 10.07.19 - 18:56
Короче я согласен что мало данных чтобы решить как правильно.

Но чем больше разных РС тем больше проблем с их рассинхронизацией, что и происходит постоянно в последних типовых типа УТ11, КА2 и ERP, особенно с работой задним числом и интеркампани.
   palsergeich
 
38 - 10.07.19 - 18:56
(36) и получаем Справочник объект меняем в нем реквизит и записываем.
+ Юзер пошел прошаренный и поиск и замену ссылок умеет.
   azernot
 
39 - 10.07.19 - 18:58
Правильно ли я понимаю следующие моменты:
1. Одно ОС может быть только на одном рабочем месте в каждый момент времени.
2. На одном рабочем месте может быть несколько ОС в каждый момент времени.

В этом случае, подходит обычный РегистрСведений
ОС - Измерение
РабочееМесто - ресурс

При окончательном выбытии, в рабочее место пишется ПустаяСсылка.
Ещё как вариант дополнительный булевый ресурс "НетВНаличии". В момент выбытия, делается запись по ОС и последнему рабочему месту с НетВНаличии = Истина. При снятии среза последний по наличию ОС устанавливается фильтр "НетВНаличии = Ложь"
   palsergeich
 
40 - 10.07.19 - 18:59
(37) Дело не в РС, а в том, что в любой реализации надо предусмотреть некорректные сценарии.
Разработчики типовых в этом плане меня разочаровывают, я 10 часов потратил на поиск ошибки в новой системе взаимозачетов.
При проведении почему то захотелось в закрытый период залезть, хотя в этом не было необходимости, всю голову сломал, но нашел таки. Решение было ещё более неочевидным.
   palsergeich
 
41 - 10.07.19 - 19:00
(39) зачем хранить состояние выбытого ОС?
   azernot
 
42 - 10.07.19 - 19:01
(41) Не понял вопрос. Мы храним только историю перемещений ОС и его выбытия.
   palsergeich
 
43 - 10.07.19 - 19:02
(42) ну по канонам надо хранить историю и оперативное состояние, но как показала практика - делать это надо в отдельных сущностях.
   palsergeich
 
44 - 10.07.19 - 19:03
(43) потому что при расширении функционала - это становится головной болью.
   Минона
 
45 - 10.07.19 - 19:07
(39)(42) После выбытия нам не нужна (!) запись об ОС в "остатках", в СрезеПоследних.
Вот эту проблему при использовании периодического РС не удаётся решить.
   azernot
 
46 - 10.07.19 - 19:07
(43) Если состояний больше чем 2 (в наличии/не в наличии), то я согласен.
Для данной задачи, в постановке ТС для отслеживния местонахождения ОС в наличии - достаточно одного регистра.
   palsergeich
 
47 - 10.07.19 - 19:09
(46) Я на эти костыли уже наступил как раз в том же учете ОС, предлагаю проверенное решение.
Дело хозяйское.
Мое дело предложить.
   azernot
 
48 - 10.07.19 - 19:09
(45) Я и указал, для того чтобы не получать эту запись, надо наложить соответствующий фильтр "НетВНаличии = Ложь" или "НЕ РабочееМесто  = Значение(Справочник.РабочиеМеста.ПустаяСсылка)"
При выбытии ОС при выборе любого метода реализации задачи, это самое выбытие нужно где-то регистрировать.
   palsergeich
 
49 - 10.07.19 - 19:12
(48) Выбытие хранится в истории.
 
 Рекламное место пустует
   Garykom
 
50 - 10.07.19 - 19:14
(45) А после выбытия ОС вы элементы справочника удаляете или может быть используете их "для экономии" под вновь поступившие ОС ? :)
   palsergeich
 
51 - 10.07.19 - 19:15
(50) А ты я смотрю прошаренный)
   lEvGl
 
52 - 10.07.19 - 19:34
(45) всего не читал, но в (10) сказали правильное решение
срез последних с условием ГДЕ Выбыл = Ложь даст нужный результат, выбывшее ОС не попадет
   catena
 
53 - 11.07.19 - 05:17
(21)Вы хотите странного. Либо у вас есть история и есть записи, либо после выбытия чистите все записи по этому ОС и лишаетесь истории. Сколько их там у вас, что вы так боитесь "перегрузки" регистра?
   Сияющий в темноте
 
54 - 11.07.19 - 08:45
(53) они поди каждый коврик для мыши учитывают.
ну если не хочется флаг выбытия,то можно в регистре поставить дату окончания события и выбирать по дате,тогда нужно будет просто проставить дату окончания к предыдущему событию при записи нового и к текущему при удалении.
от флага отличается тем,что мы точно знаем дату окончания каждого события.
   ptiz
 
55 - 11.07.19 - 08:49
Я так и не понял - почему остаточный РН отвергли?
   ptiz
 
56 - 11.07.19 - 08:51
Хотя, по большому счету, даже 100 тыс. ОС - это фигня для СрезаПоследних.
   Sayan_mi
 
57 - 11.07.19 - 09:44
Интересно а временного перемещения или передачи сотруднику нет, так чтобы по окончании само назад вставало. Если есть, то ещё бы и аналог интервального регистра из ЗУП не помешало бы.
   ИУБиПовиц
 
58 - 11.07.19 - 11:16
(57) А чем не устраивает вариант с реквизитом состояние.
И временное перемещение легко будет сделать, и запрос с срезом можно с условием по нему сделать.
Или вообще ОС  в ресурсы переместить. (если есть возможность конечно)
И тогда выбытие легко делать.
типа Ноутбук  - раб место 1 01.07
Ноутбук - раб место 2 10.07
Срез будет показывать, что ноутбук на раб месте 2 чистится, а срез до 10 на раб месте 1.
У нас например примерно так и сделано, только еще в ресурсы запихнули МОЛ и Помещение. Работает.
   Минона
 
59 - 11.07.19 - 11:42
Решили всё таки делать через РегистрНакопления (РН, 2 штуки).
Задача не стояла в формате "не использовать статус", использовать его без проблем.

В целом - было непонятно, каким образом можно исключить данные из таблицы РегистраСведений "СрезПоследних".
Задача оказалась нерешаемой, и можно сказать что тут 1С неплохо бы доработать этот момент.
Поэтому отказались от РС в пользу РН.
   Жан Пердежон
 
60 - 11.07.19 - 12:41
(59)
мде, тут столько советов неплохих дали, а сделали всё равно херню.
рано вам еще, похоже, архитектурой заниматься
   Simod
 
61 - 11.07.19 - 13:30
(0) Решение в (23) самое нормальное. Оно избыточно для простых случаев, но обладает запасом по масштабируемости. Если не хотите дополнительную таблицу "СрезПоследних", то не делайте РС периодическим. Виртуальная таблица "СрезПоследних" реализуется обычным запросом (http://catalog.mista.ru/public/527518/#Как_работает_СрезПоследних_в_запросе).
   azernot
 
62 - 11.07.19 - 13:56
(59) С одной стороны, нет особого смысла в регистре накопления, у которого в ресурсе "Количество" всегда будет 1.
Но, с  другой стороны, всегда есть что-то типа оборотно-сальдовой ведомости, которую можно вертеть в различных изменениях и периодичности, без особых затрат на разработку отчётности.
Осталось непонятным, зачем 2 штуки РН, но вам, очевидно, виднее.
   Минона
 
63 - 11.07.19 - 14:30
(62) ранее в итерации решения было "Всё-в-одном", сейчас решили разделить при переделке.
функциональное разделение:
1) Петров может сидеть за столом N1 или N2 (какой свободен)
2) На столе N1 стоит телефон 111 и комп с IP 111, на столе N2 соответственно другое оборудование

Звонит Петров. Служба поддержки видит номер 111, слышит фамилию Петров. 1С:ServiceDesk по фамилии "Петров" находит "111" и "222", а специалист выбирает и подключается к компу "111" для решения вопросов.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует