В версии 8.3.24 настраивать ведение истории данных для объектов будет можно из пользовательского интерфейса.
Это, помимо очевидных удобств визуальной настройки, ещё и даст чёткое понимание: настройка истории изменений данных не влечёт за собой изменение конфигурации.
https://wonderland.v8.1c.ru/blog/nastroyki-istorii-izmeneniy-dannykh/

(332) "Изменения в заказах можно не контролировать. Изменения в комментариях к документам тоже." - При изменении комментария ведь изменится и хеш-сумма документа. Разве нет?

с любимыми правами

(338) Совершенно верно

(343) обоснуй

(341) С чего вы взяли?

(341) Это смотря как хеш собирать. Можно ведь по определенным полям строку хешировать.

(340) Неправда. Бывают так построены бизнес-процессы, что несколько изменений в один документ вносятся вполне легитимно и не требуют контроля.

(345) Ответьте на простой вопрос, где будет храниться вся работа с блокчейном? В базе 1с?

(344) Прочти как это работает

(348) + код по формированию хеш сумм так же будет конфе базы в открытом виде?

(348) Это не принципиально. Можно блокчейн-журнал хранить в той же базе. Можно в другой. От этого ничего не изменится

(349) Где ?? Чем ты обеспечишь запись в блокчейн но запись в версионирование или ЖР исклю.чишь?

(350) Контролер запускает код на своем устройстве

(351) я как програмист в течении дня тормозну блокчейн уведу вагон, запущу блокчейн

(351) Вот смотрите, у вас есть док с хеш суммой b10a8db164e0754105b7a99be72e3fe5. Это дело хранится в базе. Я зашел в код и отключил формирование нового хеша при изменении. Либо присвоил этот же хеш новой версии документа. Кто меня сможет остановить? Как контролер определит, что документ был изменен, ведь хеш у него совпадает?

(352) На хабре, на сайте, на инфостарте. Было бы тебе по настоящему интересно уже давно бы прочитал

(353) "Контролер запускает код на своем устройстве" ага, а это устройство - РДП на терминальнике, где все работают в одной базе 1с.

(356) я в теме потому и говорю что ты несешь чушь, ты не можешь гарантировать запись в один источник и говорить тчо можешь не псиать в другой

(355) Хеш хранится в блокчейн-журнале. Он формируется не при записи документа, а в процессе контроля. Да, надежнее будет, если блокчейн-журнал будет храниться на устройстве контролера. Но, повторюсь, это не принципиально. С журналом все равно ничего плохого сделать нельзя

(358) Нет. Ты не в теме. Вопросы у тебя не по существу. Вот на хабре были по существу. Там мне помогли уточнить схему работы. А здесь пока ничего интересного

(359) "Хеш хранится в блокчейн-журнале" - а журнал где хранится? В 1с же? "Он формируется не при записи документа, а в процессе контроля" -- так это же в 1с делается, обрабоками 1с? Что мешает мне код там поправить и показывать валидность?

(359) " Хеш хранится в блокчейн-журнале. Он формируется не при записи документа, а в процессе контроля " - Т.е. новые документы можно спокойно изменять? :))

(360) ещё раз ты утверждаешь что гарантиуешь не запись в один итсочник и тут же гарантируешь в другой. Это противоречие само по себе

(361) Код запускается на устройстве контролера

(363) Просто разберись, как это работает

(360) Вам бы и здесь помогли, если бы вы не байтили народ сообщениями типа КС гуд, а версионка ненадежно. Вам тут уже множество раз написали, что это разные инструменты.

(364) Так вы ответьте на вопрос, в 1с он запускается, или сторонний софт надо ставить для этого дела? Если в 1с, то все вопросы актуальны.

(324) >> Как найти то единственное нелегитимное изменение? (из 100499).

Элементарно. Разворачиваем из архива 100499 копии на каждый момент времени очередной записи в цепочке изменений и сравниваем между собой и с первичкой, если она есть.

Давайте прям контретику. Контролер, заходит в такую то прогу, жмякает такие-то кнопочки и видит, что такие-то документы кто-то ковырнул.

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

(361) (369) В блокчейне это всё возможно. Вопрос не в этом, вопрос в том - кому и на кой хрен это в принципе всё сдалось. Откуда он в реальном мире будет брать тысячи контролёров и кто всем этим будет заниматься, какой идиот это закажет?)

(371) Вот это правильные вопросы. Когда встретите такого "идиота", будете знать куда обращаться )))

(371) Эти задачи в принципе сильно выходят за рамки оперативного учёта, а следовательно - области применения 1с (большинства прикладных решений на 1с) как таковой.

(373) тут даже не столько это, сколько цена вопроса для большинства контор, которые юзают 1С.

(373) Ну я бы не был так категоричен. Склад он и в 1С склад. И его надо контролировать

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

(374) Цена начинается от чего-то около нуля, если хозяин решит сам все контролировать

(375) склад - это физические объекты. и максимум чего ты сможешь реально прокнтролировать это фактическое количество товара на складе с учетными данными в СКЛАДСКОЙ системе. для этого - инвентаризации. Другого вменяемого способа контроля склада - нет. Все остальные "контроли" - относятся к вопросам контроля документов и неких бумажных воздушных цифр, которые в реальности на складе как физические сущности отсутсвуют.

(377) делать хозяину нехер больше. Еще он может сесть и лично забивать данные вместо оператора в систему. и выгнать нахер всех работников. самому все делать. тогда и контролировать не надо.

(378) Эти "воздушные", как ты говоришь, цифры и есть то единственное, что "сторожит" склад.

(379) "...я пока один работаю" ;)

(370) Да я уже почитал. Вы блин издеваетесь? Мы же тут вашу реализацию обсуждаем:
Вот это к примеру "Шаг 3. Сделаем обработку контроля."
Что мешает тут закоментить и написать свою логику, чтобы обойти контроль?

(379) Ты абсолютно прав. Хозяину не стоит заниматься ни чем иным, кроме как контролировать процесс. Так что, да "нехер больше"

Хокеист как Маня. Изобрел "подход"/инструмент, от которого сам лично тащится. и теперь сует во все места. подавляющему количеству потенциальных потребителей - это нахер не надо. эти предложения только увеличивают стоимость владения это пилятской 1С и жрут ФОТ. На том уровне ответсвенности где в большинстве контор работает 1С, вопросы контроля данных с нужноу степенью защиты реализуются другими имеющимися из коробки методами. их вполне хватает.

(383) контролировать процесс - нахер не надо. если хозяин будет заниматься контролем процессов - его бизнес сдохнет достаточно быстро.

(380) Уфффф... Нет) Склад в конторе крупнее пивного ларька сторожит и любит ERP, на чём бы она написана не была. Там всегда отдельно WMS и стараются разделить бухию. Внутри WMS могут даже позволить в минуса уходить - на многих складах бардак по остаткам. Но вот если цифры начнут не совпадать - всё будет искаться, находиться и все сразу будут наказаны. И никаких блокчейнов не надо, я 10 лет проработал на разных складах человеком, который искал и находил)

(382) Как ты собрался что-то коментить на устройстве контролера? Просто объясни - как

(386) а шансов что по какому то злому умыслу в трёх базах кто то там сможет исправить документы и это никто не заметит - просто нулевые. В таких крупных конторах ни у кого просто нету доступа во все эти места

(387) Я имею админские права и доступ к конфигуратору. Контроль сделан в конфигурации 1с, в которой работает контроллер. У меня есть доступ к ней и я могу ее править. Я ему ее и ставил и внедрял к примеру.

(388) ... или у тех, кто это делал, хватило мозгов не светиться

(387) У контроллера не отдельная база. Он работает в той же ЕРП/УТ/КА, где остальные юзверы с определенным доступом. Я поэтому и писал уточнить за устройство. В большинстве случаев это терминальний и тонкий клиент  у юзвера. Он заходит на сервак, открывает базу 1с и выполняет всю работу там. Что мешает программисту имеющему доступ к этой базе, конфе, скл, ковырнуть контроль?

(389) У тебя нет доступа к устройству контролера

Отдельных людей, которые будут со своих систем получать данные от центральной базы и контролировать у бизнеса просто нет! Как вы этого понять не можете?

(392) Данные как будут передаваться от центральной базы к контроллеру?

(391) зато отдельная внешняя обработка

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

(395) Я как админ имею доступ ко всем файлам сотрудников, а так же стоит запрет на внешние обработки (это обычное дело в плане безопасности)

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

(398) И что это даст?

hockeyist Давай ближе к жизни. скольки конторам было предложено "твое решение" по контролю. сколько контор его купило и полноценно использует. каков экономический эффект полученный?
.
в общем случае - насколько рынок одобрил твое решение?

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

А дальше я просто отменю хеширование в конфе, изменю документ и заберу товар со склада. Кто мне помешает? Для контроллера он будет неизменнным и валидным.

(400) Коммерческая тайна

Я же правильно понимаю, что разбор полетов возникает, если есть ошибки по хешу, в моем случае их не будет, все норм пройдет)

(402) Еще раз. Представь, что блокчейн-журнал хранится на устройстве контролера. Он там же и создается в процессе контроля. Так тебе будет легче. Я просто обращаю твое внимание на то, что журнал можно хранить и в 1С-овской базе. Разницы не будет. Тебе трудно понять, почему так, из за того, что ты не вник в схему работы.
Ты не можешь ничего плохого сделать с журналом. Любое твое вмешательство в его работу будет тут же замечено контролером

Вот это мне еще нравится:
выб=документы.Блокчейн.Выбрать();
    пока выб.Следующий() цикл
Вы тупо каждый раз пробегаете по всем документам блокчейн в базе и свераяете из с реальными документами в цикле. Ммм просто красота реализации. Пробовали запускать это добро частенько на базе размером с 200гигов  и более при полном контроле документов?

(406) Оперативные базы размером в 200 ГБ, это чисто 1С-овское недоразумение. В нормальных местах всегда работает связка оперативная база - архивная база.

(407) Надеюсь вы представляете, что пару запусков такого контроля разными контроллерами и все забьют на это дело, потом как ждать пару часов не у всех есть возможность)

(407) В идеальном мире, с радугами и единорогами, может оно и так, но по факту это обычное дело, даже для средненьких контор.

Мне вот интересно, тут есть хоть кто-то, кто действительно пытается в чем-то убедить hockeyist или это просто пятничное?

Я себе просто представил эту картину. Ведется управленческий учет, документы в течение для по 10 раз правят, вначале просто сотрудники, потом регламент какой-нибудь, потом руководитель проставляет там что-нибудь. Контроллер 3 раза в день запускает эту обработку (а что будет если отгрузили до проверки?), все потому что чаще не получится, она тупо висит. Видит там портянку из сотни документов и начинает дрочить все отделы причастные, кто там что менял и зачем. Несколько дней такой проверки показывает, что это все текучка и никто злонамеренно не вносил никаких левых данных, но на проверку доков все изрядно потратили времени. Через неделю все уже забьют на такой контроль.

(410) скорее второе)

(403) ты даже ИС переплюнул в этом вопросе... ;-)

Имхо это мертворожденное решение для 1с. В узких местах да, возможно пригодится. Тот же контроль кредитов и прочих критически важных дорогих документов, где изменения могут вносить разные филиалы. Там можно эти денежные вопросы хешировать параллельно и раз там в какое-то время проверять. Да и то, та же обувная фирма с кучами филиалов, потратила кучу средств для реализации этой темы, а в итоге убедились, что никто документы важные так и не подменяет)

(411) Я так понял, что после создания документа до следующего контроля его можно менять сколько угодно (ведь хеш-сумма ещё не рассчитана). Так что защиты тут ровно ноль.

Возможно еще и контроль документов, которые не должны меняться после определенных действий/статусов. Только тогда их хешировать.

(415) Именно так, пока не проверили, все можно) А судя по коду реализации, можно и менять, пока обработка будет все доки блокчейна за все года обходить и с реальными документами сверять)

Последние 5копеек по поводу защищенности. Большая вероятность, что админ будет знать кто контроллер, он будет знать где будет ПО контроля (внешняя обработка, или еще что). Хозя будет ставить ему задачу это дело автоматизировать и обучить юзверов работе. И все опять сведется к человеческому фактору. Админ/кодер залезли в эту обработку и закомментили контроль, либо подменили хеш функцию. Более чем уверен, что никаких внешних обработок не будет. Хози вполне доверяют своему IT отделу, все будет в рамках одной базы и одной конфы (контроль там же) и все опять же упрется в права пользователей и ограничение доступа. Никто не даст право запускать внешние обработки для юзверов (даже для контроллеров). Причем один из контроллеров может быть и сам кодер, так как он все это дело тестировал и отчитывался хозе.

Сами же хози в 1ске почти не сидят, им этого не надо, кто-то даже может не уметь ей пользоваться. Им всю инфу подают нужными отчетами для управленческих действий руководители отделов.

(419) https://youtu.be/9nHHgVXcbFA

(420) ахах. Вот у нас в конторе, ген. диру вообще пофиг как там в 1с устроено, ему главное чтобы такого-то числа такие-то отчеты были у него на столе. У него хоть и есть доступ в 1с, но он туда даже не заходит)

(418) обычно в любой непонятной ситуации можно поднять первичку, запросить акты сверки и с водкой (с поллитрой) разобраться в ситуёвине

наши бухи всегда так делают (принципы двойной записи и рукописи не горят)

ну а за фактические недостачи есть МОЛы

(422) В случае Калимулина, все сотры должны боятся контроллеров, которые могут в любой момент запустить контроль и увидеть измененные документы. Но на практике это вряд ли будет работать.

(423) во времена Пачоли блокчейна просто не было

(424) математик из Италии*

Не путать с Пачули
"Пачу́ли, или Инди́йские пачу́ли — вид кустарниковых тропических растений из рода Погостемон (Pogostemon) семейства Яснотковые." Вики

(423) А что плохого в изменениях документов?
Мне казалось блокчейн нужен для невозможности сокрытия изменения документа, а не как то бороться с изменениями.
так то вон у нас один заказ в легкую по пути товародвижения может и 100 раз перезаписаться, потом иди свищи что тебе надо.

(427) "невозможности сокрытия изменения документа" - так и при версионке все это будет видно, кто когда и что менял. Если прог с полными правами в доле, то никакой блокчейн в этом случае не поможет, так как внедрение всего этого чуда будет под под его же руководством.

(428) смотри.
На сколько я помню цель защиты информации - обеспечить невозможность ее получения или расшифровку пока она актуальна.
В версионник в теории можно залезть и изменить байт и контрольную сумму и ничего не найдешь.
В случае с блокчейном - подбор красивого хеш кода с учетом того что предыдущие состояния хранятся в распределенной БД - вот эта штука при текущем развитии технологий является невероятной за разумный промежуток времени.

(429) Другой момент что те реализации которые сейчас есть в 1с - они будут тем камнем которые потопят то самое блокчейн в 1с)

(332) Без настройки - будут 100500 изменений. Также не получил ответа на вопрос - как контролер узнает, что изначально документ введен правильно?

(340) Ага. Только проконтролировано должно быть соответствие физическое состоянию склада, а не сферического коня в вакууме. Расскажите, как посчитать контрольную сумму фактических остатков на складе (чтобы сравнить с теми, что в программе)?

(353) Бесполезно. Если я могу вмешиваться в работу системы, то я могу контролеру отдавать правильные данные, а пользователю - уже измененные. Контролеры банально вычисляются как устройства с неизвестным расположением, которые суют свой нос во все данные.

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

(379) Вот мы и вычислили потенциальных потребителей этой системы: ИП без наемных работников :)

(380) Ничего это не сторожит - ведь можно сразу ввести 1 штуку вместо 10 в 10 раз дороже. И система не пикнет.

(386) А еще всю недостачу вешают на всех кладовщиков - и те сами стучат друг на друга и сдают схемы своих коллег.

(387) А как кто-то вообще увидит, что контролер обнаружил расхождения?

(395) ... которая открывается из темпов сервера, и ничто не мешает подставить туда свой файл? Вы издеваетесь?

(399) Все контролеры будут вычислены за 1-2 дня.

(414) Только вот там по-любому будет и версионирование, т.к. надо знать ЧТО было изменено. Иначе "договор был изменен" - и банк в суде пролетает как фанера над Парижем.

(418) Предлагаю обсудить ситуацию, когда контролер обнаружил расхождение, но никто этого не увидел, потому что система это не вывела на экран :)