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

Весь механизм истории создает опасную иллюзию контроля. Если мы хотим реально что-то контролировать, то надо смотреть не на картиночки типа 10 шт. поменяли на 1 шт. (в этом нет никакого смысла), а на контрольные суммы

(1) и какую информацию несет изменение контрольной суммы? ну кроме булево - Да/Нет

(0) Не впечатлен.
Вот если бы при выходе новой платформы было заявлено, что данный релиз не содержит багов - я бы впечатлился.

В типовых конфигурациях этот механизм все равно не используется. Там используют версионирование на регистре сведений от БСП.

(1) Лови наркомана

(5) пусть бежит, на этот бред давно ни кто не обращает внимания

Они сами этим не пользуются, версионированние в актуальных конфах на БСП же. Ну, как бы есть и как бы хорошо. Но такое себе

(7) боятся внедрять ))) могли бы от версии платформы запилит два механизма: встроенный или на БСП

(8) Разные подходы: платформенная хранит только изменения + первый снимок + актуальную версию.
БСП хранит полный снимок. Если объект не менялся, то контрольная сумма совпадает с предыдущим снимком.

(9) это особенности реализации - выполняют то они одинаковые задачи

(10) Когда я делал реализацию на уровне платформы, то не смог удалить старые версии, чтобы не поломался механизм возврата на предыдущую версию (надо будет как-нибудь перепроверить, может упустил что-то, либо не так удалял).
С БСП такой проблемы нет.

(3) Для доказательного программирования нужна более простая система. Вот например SQLite гарантированно не содержит ошибок. Ну так там вся база блокируется для каждой транзакции. Вы такую хотите?

(2) Этого "да/нет" достаточно для любых целей.

(13) Просто нет) Не достаточно ни для каких реальных целей. Как правило этот механизм нужен для двух целей - посмотреть что привело к какому то сбою - кто когда ввёл какие данные. Другая цель - это возвратить как было. Ни первую ни вторую задачу да\нет не решает

(1) в реальном бизнесе реальных задачи всего 2:
- кто и когда ввел эту х-ю
- верните как было на дату N
теперь реши их со своими контрольными суммами.

(14) Сначала нужно получить это самое "да/нет". После того, как вы его получите, можно делать все остальное. Поднимать бэкапы, анализировать, восстанавливать. История этого самого "да/нет" не дает

(15) Все начинается совсем с другого вопроса.
А все ли в порядке?

(17) Когда всё в порядке, то смотреть историю изменений абсолютно незачем.

(18) А как узнать все ли в порядке?

(19) Обычно ты это узнаешь когда уже всё не в порядке. Не закрывается заказ, месяц, ЭДО или ещё что-нибудь. Ты лезешь в историю что бы уже найти проблему, а не посмотреть было ли изменение этого документа\справочника или не было.

(0) ждем блокчейн в платформе 8.3.26

(20) В приходном документе поменяли 10 шт. по 1 руб. на 1 шт. по 10 руб. Месяц закрывается без проблем. Заказ был закрыт еще раньше. Документами по ЭДО тоже раньше обменялись.

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

(23) При сверке чего с чем? Взаиморасчеты не изменились. С закрытием месяца проблем не будет, как я уже сказал. Откуда им взяться?

(21) а зачем? блокчейн ради блокчейна?

(1) я делал обработку, которая считает контрольные суммы по проводкам и аналитикам к ней для двух разных базах. Вполне удобная и нужная штука для быстрой сверки большого массива информации. А там, где КС отличалась, уже детально по реквизитам.

(25) +500.

Не вижу необходимости.

(26) А что, простое сравнение полей уже не работает?

(19) А что такое порядок?

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

(25) все ходы записаны

(31) И?

(25) Можно наверно по этой технологии 1с ЭДО сделать.

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

(28) для этого файл для сверки данных должен содержать все эти поля. А там может быть до 500тыс проводок. Прямого подключения между сверяемыми базами 1С нет

(34) Ну выяснил ты, что порядок нарушен, что дальше?

(34) Проверенных кем? Это вообще отдельная и очень спецэфичная задача, о которой написал (26). Версионированние используется большинством людей не для этого.

(35) А, ви в этом смисле

(36) Он писал выше - тогда типа лезь в бэкапы или используй нормальное версионирование) Но как он собрался проверенные отличать от непроверенных. Вот у меня заказ клиента например менялся 10 раз за месяц. И?

(32) банальщина

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

это я не сам придумал

ну это не про версионирование, а скорее всего про амбарную книгу в граните

(39) Я тогда предлагаю сделать еще более лайтовый уровень, константу, типа менялось ли что в базе вообще с момента последней проверки
И тогда проверяющий смотрит константу, если она не менялась, то не нужно ничего и проверять
А если менялась, тогда уже смотри, какие объекты менялись
Тут правда это, если объект менялся, то не нужно сразу его проверять, надо это, открыть все-таки версионирование и посмотреть, что менялось
Ну в общем это, версионирование нужно, на контрольных суммах далеко не уедешь

(40) Ниче не понял
Напиши рабочий кейс, нахрена ты мне сюда гуглоотрывки срешь?

(41) Чисто описал ТЗ с мой работы на клюшках :-D

(41) Можно просто подписывать файл базы цифровой подписью.

(42) >Ниче не понял

но жутко интересно :)

не понял, прочитай еще раз

(42)

я загуглил за тебя

https://infostart.ru/public/717210/

https://expert.chistov.pro/public/1179411/

https://static.1c.ru/bf/2018/p/02/17_15_Как%20обеспечить%20контроль%20миллионов%20транзакций%20Блокчейн%20на%201С%20(Карпенко%20Д).pdf

(30) И каков порядок этой самой сверки? Приходим утром на работу и начинаем сверять всю первичку с самого начала работы компании?

(36) Я выяснил, что есть документ, который изменили, но еще не проверили. Проверил его, и тем самым восстановил порядок

(39) Каждый раз, как меняется заказ, ты его проверяешь. В чем вопрос?

(26) А что от чего тут может отличаться?

(49) Для ларьков такой подход пойдёт. А если заказов несколько тысяч в день и каждый меняют по несколько раз? Не устанешь проверять?

(44) Нет смысла подписывать то, что нельзя пробежать глазами

(51) Контроль должен быть в любом случае. Если контроля не будет, тогда кто хочешь бери, что хочешь

(53) Проверять каждое изменение каждого документа - это идиотизм и оправдано только там, где этих документов немного. В крупных компаниях необходимы иные методы контроля.

(54) Т.е. ты утверждаешь, что не надо проверять каждое изменение прихода на склад? Ну, ну...

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

(56) К примеру оператор завел поступление вместо 100тыс, на 1лям, а оплата была всего 100тыс. Это сразу заметит бух отдел, или прочие сотрудники, которые дебиторку/кредиторку контроллируют. И так во множестве моментов.

(55) а зачем?

Историю изменений удобнее хранить в отдельной базе. Иначе твоя база неоправданно пухнет как на дрожжах.
Если базы разделить, то оптимальнее настраивать архивы. А то каждый раз за историю изменений так переживать, что...
Историю изменения документов совсем прошлых периодов хранить не к чему. История части объектов вообще не нужна.

(1) Иллюзия контроля - это надеяться, что просмотр истории данных выявит виновника и решит проблему.

Человеческий фактор никто не отменял. Узнавали пароли других пользователей, входили с чужого компа, меняли что хотели.. и поди докажи, что это ты. А если и доказали и напортил, то что? Это решило проблему? Да нихера.

(57) Кто-то заменил 10 шт. по 1 руб. на 1 шт. по 10 руб. в приходном документе. Обрати внимание, что сумма взаиморасчетов не изменилась

(58) Если этого не делать, будет кто хочешь бери, что хочешь

(61) Вам нравится по 10ому кругу одно и тоже обсуждать? Фетиш такой? Заменил и что дальше? Провели ревизию частичную на складе и нашли лишние 9шт. Посмотрели движения по этому товару и сравнили с накладными от поставщика. Надавали люлей оператору.

(60) Все гораздо хуже. История не только не может выявить виновника проблемы. Она не может выявить саму проблему.

(63) Провели ревизию на складе, а там все совпало. Догадайтесь, почему

(63) Доступа у оператора к складу нет, забрать он от туда ничего не может (если вы вдруг решите написать, что 9шт он свистнул со склада). Есть и другие документы, отражающие приход товара, бывают и ордерные схемы, есть еще цепочки документов, ЭДО и прочее. Не проканает такое, а если и пройдет, то в мизерном проценте, где подобный контроль от вас (видимо продвигаете свою тему блокчейна на нимфостате) будет куда дороже для компании.

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

(67) Это все равно, что в туалете поставить амбарный замок, камеру видеонаблюдения на туалетную бумагу, сигналку на движение, с кодовой панелью и т.д. чтобы не дай бог, кто-то не спер у вас рулон туалетной бумаги. Может ли такая защита? Наверное поможет, только вот смысла в этом нет.

(68) Вы спорите с самим собой

(69) Всего лишь показываю абсурдность тотального хеш контроля каждого чиха в 1с, если на это нет веских оснований.

(70) Нет. Вы сами придумали какую-то свою систему. Сами нашли в ней абсурд. И теперь этот выдуманный вами абсурд разоблачаете

(71) Ваше предложение какое? То что на ИТС в плане хеша и блокчейна?
Я в (66) детально описал, абсурдность вашего (61) (65)

(62) За каждым сотрудником закрепить проверяльщика? А за проверяльщиком - проверяльщика этого проверяльщика?

(0) Делал лет 10 назад подобную хрень в управленческой базе (переделанная УНФ), в транзакции в спец. регистры записывались все изменения ключевых элементов справочников, документов в базе (не всех подряд), вот как в (0). При том, что онлайн пользователей в базе было не более 25-30, этот регистр за пол года раздулся до неимоверных размеров, а понадобилось такая информация заинтересованным лицам за это всего пару раз. В итоге механизм заблокировал, а регистр очистил.

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

(72) В чем абсурдность? Это практика. Кто принимает товар, тот и вводит первичку.
В (61) и (65) реальная практика. Скоропорт ждать не будет, пока кто-то в офисе что-то введет и на месте это согласуют.

Обычно,не 1 на 10,а одну единицу измерения на другую - разные коробки с разным количеством.
И тут не проблема в том,что переправили,а в том,что такое имеет место быть - можно при приемке сразу не ту единицу ввести.

(77) Можно сразу, а можно и не сразу. Чем "не сразу" от "сразу" отличается догадываетесь?

(74) так надо было в хранилище пихать, а не в чистом виде хранить.
Структура, скорее всего, была Ссылка - ИмяРеквизита - Старое значение (представление строкой/число/дата) - Новое значение (представление строкой/число/дата)

тут реально никто не понимает как избавится от изменений если это необходимо?
Вы месяц смотрю вообще не закрываете.

(79) пффф вообще в файлы кидали такое, имя папки идентификатор файла. Размер был гиганский за пару месяцев, надобность около нулевая.

(21) блокчейн тебе покажет последовательность изменений как и любая другая система без видеокарт )))))) глупости такие.

(74) Я бы посмотрел на реальные кейсы применения истории (в любой реализации), отличные от этого.

(83) прибегает начальник склада, бухгалтер, продажник с выпученными глазами в том документе была другая цифра - кто поменял и какая была?
у буха допустим изменился баланс, на складе остаток по конкретнйо позиции ушел в минус, у продавана вдруг позиция за которую светил бонус пропала

(84) Это закрывается 1 раз, и больше такого не возникает

(84) Напридумывать и я могу, ценен реальный опыт.

(83) И я бы посмотрел. Подозреваю, что их просто не существует в природе

(86) это реальный опыт если ты не в киоске работаешь. Бух банально поправил документ поступления на правильный, дальше поехало.

(46) На Инфостарте кусок г-на от Калимулина, на форуме Чистова - разводилово от инфоцыган и почему я не удивлен. Несите другой блогчейн, этот сломался.

(89) инфоцигане судя по всему ещё и сдохли, последний коммит 2 года назад почти и телеграм бот умер и в выдаче их на первой позиции нет. Нахрена блокчейн в 1с мне вот непонятно)

(89) обувь россии это же те что недавно чуть не обанкротились ))))

(49) Ты работал на реальном предприятии хоть раз?) Вот у меня сейчас контора, примерно 1500 заказов в сутки по всем филиалам. Каждый заказ перезаписывается от 3 до 10 раз, причём часть что то там менеджеры меняют, часть делается автоматически системой или регламентами. УТ 11, РЕАЛЬНЫЙ пример. Кто будет эти 15 тысяч изменений в сутки проверять?) Что за клоунада?)

(92) Ах да, и по твоей же охренительной логике, ты видишь сам факт что он изменён, и каждый раз должен лезть в нормальное версионирование всё равно что бы понять что там хотя бы было изменено :-D Потому что в моём реальном примере что тебе даст осознание того что у тебя 1500 заказов менялось за последние сутки по 10 раз каждый?

Прочитал-кайф

(94) Эмм, ты с самописками работаешь? В ERP это не используется)

Вы как-то уперлись в технические варианты решения. Значимые изменения, которые требуют внимания или возврата к предыдущему состоянию - при нормальных административно-организационных и регламентах работы возникают настолько редко, что даже не знаю как прокомментировать все написанное выше... делала логгирование изменений лет 10-15 назад (уже и не помню настолько давно это было), практиеской необходимости в этом не было в итоге (как в (74))

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

(92) Ты споришь сам с собой. Я говорил по складские документы. Ты переключился на заказы и с удовольствием доказываешь абсурдность контроля каждого изменения заказа. Если хочешь подискутировать, не слезай с темы

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

Я тебе говорю что это крайне спецэфичная задача, которая практически никому не нужна, а версионированние нужно совсем для других целей. Никак не для контроля неизменности транзакций

(16) "можно делать все остальное. Поднимать бэкапы, анализировать, восстанавливать"
Разворачивать копию базы в много десятков гигабайт из бэкапов, чтобы выяснить что и когда наколбасили пользователи пару месяцев назад? Вот чтобы такого не было нужно, и сделали хранение версий. Крайне полезная функция.

(99) Для каких целей нужно версионирование?

Всегда на всех базах полностью включаю версионирование. Кто думает что это сильно раздувает базу - да нифига. Зато позволяет ткнуть носом в случае чего "это ваш сотрудник поменял один товар на другой, а 1с всё считает правильно".

еще в 2007 писал такую универсальную подсистему, прямо 1 в 1.

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

(100) При нормальном контроле такое будет случаться крайне редко. Буквально разы за все время работы базы. А так, как сейчас повсеместно, когда никакого контроля нет, то тут, да. В базе бардак и она уже давно во многих местах разошлась с реальностью. Время от времени эти расхождения прорываются наружу. Все начинают бегать с выпученными глазами и каждый думает, как бы прикрыть свое заднее место. В такой ситуации версионирование конечно полезно. Но не для организации. Для программиста. Он этаким королем берет и всех "тыкает носом" в те или иные изменения. Его заднее место версионированием прикрыто надежно. Для организации же версионирование вредно ровно по этой причине. Потому что напускает дыму, за которым не видна некомпетентность программиста

(104) Хорошо. Остановимся на документах. Зачем возвращать старую версию документа? Чтобы что?

(106) В случае если документ исправили ошибочно, если он не успел причинить последствий - можно откатиться на предыдущую правильную версию.

(106) Я повторю свой вопрос - ты работал в УТ\ERP на предприятии где хотя бы несколько сотен заказов в сутки есть? Где реализовываются какие то хотелки, допиливаются какие то фишки, есть ЭДО, интеграции и прочая модная хрень?
Вернуть старую версию, что бы сэкономить время менеджера, например, если в результате какого то процесса, ошибки ли человека или программного кода - документ отменился или потёрся.

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

(108) Т.е. все сводится к восстановлению удаленных документов? Но для этого достаточно существующего уже давным-давно механизма пометки на удаление.

(107) Есть документ, есть исправление документа. Как понять, что из них правильно, а что нет?

(110) Вот есть у вас документ с 1000 позиций, а потом какой-нить Вася, имеющий доступ к нему, случайно удаляет все позиции кроме одной. Вы как автор документа, замечая кучу косяков и вопли менеджеров, понимаете, что что-то не так. Заходите в свой документ и глазками видите, что накладную испортил кто-то.  Заходите в историю изменений, видите там Васю, время когда он ковырнул, откатываете свою версию и идете к Васе для разбирательств. А он просто док перепутал и случайно в чужой зашел...

Без версионки, ему бы пришлось заново вбивать все эти 1000 позиций.
По вашей теме с блокчейном, любой пук по изменению документа пришлось бы по 100500 раз согласовывать, что сказалось бы на скорости работы.

(109) Нет. Восстановление документа - это одна из целей. Ты чем читаешь, я это уже 4 раза, блин написал. Вторая цель - выяснение истории - кто что и когда менял в документе. Что бы в случае возникновения ошибки можно было быстро расследовать кто виноват - регламентное задание криво отработало или менеджер нахреновертил - и предпринять меры для того, что бы ошибка не повторилась - исправить код, допилить запрет на изменение реквизита\строка или объявить выговор менеджеру.

(110) Это совершенно идиотский вопрос. Тебя, как программиста, в принципе не должны волновать такие вещи. Ты не должен знать захотел клиент 10 товаров по 1 рублю или 1 товар по 10 рублей. К тебе обратился менеджер или начальник отдела - сказал - у меня сломался заказ, помоги разобраться. Ты лезешь, смотришь что менеджер упал лицом на клавиатуру и поломал его. Предлагаешь ему восстановить его и дорабатываешь например, что бы загруженные заказы нельзя было менять. Или ещё что. Если проблему нашли и тебя просят её исправить, то тот кто проблему нашёл итак знает как правильно, какой документ верен, а какой - нет.

(111) * в место Васи может быть какой-нибудь корявый регламент, или обработка написанная с ошибкой сломавшая ТЧ документов некоторых.

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

(112) Вы опять выстраиваете у себя в голове какую-то фантастическую версию.

(116) Все из практики, никакой фантастики. Например делали ревизию на складе, вбили количество факт по каждой позиции, а потом каким-то макаром факт стал равен плану. Как вернуть все "взад"?)

(117) Я имею ввиду ваши рассуждения о системе контроля

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

(119) Кого?
Девок или старшего продавана?

(120) https://www.youtube.com/watch?v=fgNTUXho-zE

(120) старший продаван - тоже девка, я тут пердельно бздителен! ;-)

из моего опыта все программные ухищрения в плане контроля исправлений и поиска виновников оказываются на порядок менее эффективны чем административно грамотно выстроенные процессы.
если Вася знает что для исправления ему придется идти к Петровичу и объясняться нахрена, а после исправлений снова идти и клясться что это в последний раз и теперь там точно все верно - то он будет как минимум внимательнее.

(117) (118) Вообще не очень понятен ваш спор.
Версионирование и разного рода блокчейн - два разных инструмента, решающих различные задачи.
И могут применяться как совместно так и по отдельности.
И универсального ответа на вопрос - что из них лучше, хуже, правильнее, надёжнее - не существует.

(123) +100500!

(122) Удобно

(34) Для этого предназначены планы обмена, а не история данных. Кстати, а ты в курсе, что если перепровести документ без изменения - данные все равно меняются? Как минимум номер версии объекта меняется. Так что КС будут всегда разные.

(64) У тебя по КС документ меняли 5 человек. Кто из них ввел неправильные данные? История позволяет ответить на этот вопрос, в отличие от КС. И вообще, зачем КС, если есть ЖР? Там все изменения зарегистрированы.

(75) О, пошли сферические кони в вакууме. У Вас неверная информация.

(95) Ничего не мешает включить, кстати.

(101) Если ты не знаешь - значит просто не работал с реальным бизнесом.

(105) Нормальный контроль стоит денег. Немалых денег. Постоянно. Более того, одномоментно такая система не строится. Так что опять рассуждаете о сферических конях в вакууме. Что же касается компетентности... в 99,99% случаев там некомпетентность пользователей, и версионирование позволяет быстро и дешево определить, каким пользователям надо повышать компетентность. Т.е. как раз полезно для организации - упрощает принятие корректирующих действий. Если, конечно, она умеет пользоваться инструментом.

(111) Классика жанра: думал, что скопировал документ, а на самом деле просто открыл.

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

(129) "Хотя франчи радостно берутся за такие задачи."
Ещё бы. Два раза заплатят. Один раз за то чтобы сделать ограничение, второй раз за то чтобы убрать его)

(34) "что порядок это отсутствие непроверенных изменений в базе"
- все изменения надо проверять? как отличить заведомо правомочные изменения от подозрительных, которые надо проверять?
кто будет проверять? по логике - тот, кто имеет право на изменение и ввод данных, ибо тот кто не представляет что такое правильно - не поймет ничего. Отсюда - если документ изменили - его изменил тот, кто к этому допущен. Зачем тогда это проверять?
Или как?

(131) В современных типовых документ меняет не только пользователь. Плюс есть куча реквизитов, которые не видно на форме. А в версии видно.

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

(133) Слава богу, что вы не работаете в крупных торговых компаниях)

(133) Что такое настоящая безопасность данных? ERP\УТ11, актуальные релизы. В нормальном, легальном рабочем процессе заказ клиента может меняться раз 10. Просвети нас, какой механизм должен быть реализован что бы была настоящая безопасность данных, при том что таких заказов, ну, допустим, тысячи 3 в сутки

(133) Настоящая безопасность данных - это когда их нет. А вот отрицательные остатки - это однозначная ошибка либо в самих данных, либо на складе.

(131) Можно упростить, чтобы было понятно.
Пусть оператор и контролер будут одним лицом. Тогда задача звучит так: как оператору-контролеру получить доказательство, что те данные, которые он ввел-проверил, никто не менял.

(136) Настоящая безопасность - это доказательство неизменности данных.

(137) :) Возьмем тот пример, когда вместо 10 шт. поставили 1 шт. Оператор поставил 1 шт., и договорился с кладовщиком вынести 9 шт. на двоих.

(138) Какая, нафиг, это безопасность? Опасность представляет даже чтение данных - это тебе любой бизнес скажет.

+(137) И, кстати, если совмещать оператора и контролера, то функция контролера становится ненужной - достаточно просто запретить всем, кроме оператора, менять данные. КС опять в пролете.

(140) "достаточно просто одеть кошке колокольчик на шею..."

(139) Поэтому лучше разносить эти роли между разными людьми. В идеале, каждый оператор знает, что есть контролеры, но не знает кто они и сколько их.

(141) Зачем кому-то другому менять данные, чтобы потом ответственный потом их еще и проверял? Это же двойная работа.

(142) В (137) предлагаете получить доказательство "что те данные, которые он ввел-проверил, никто не менял", и тут же предлагаете другим менять данные... у Вас что-то с логикой.

(143) Все нормально с логикой. Мы только что с вами выяснили, что нужна связка оператор-контролер. А из этого уже вытекает задача получения доказательства неизменности проверенных данных

(144) нам к 200 менеджерам нанять 600 контроллёров? Это только для заказов. А есть ещё соглашения с клиентами, номенклатура, контрагенты, справочники пользователей и ещё 100500 справочников, документов плюс несколько миллионов транзакций в сутки. В общем, раздуть штат раз в 10, зато проверять глазками каждую транзакцию?)

(144) Еще раз. Задача неизменности данных решается не проверкой, а правами доступа. Так что априори на вход контролеру поступают измененные данные. И тогда возвращаемся к (131).

(138) у мелкософта древняя учетная система была типа такой - данные можно менять только новыми документами. Ну и где она теперь?

(146) Права доступа ненадежны

(148) Контрольная сумма тоже.

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

(149) А контрольная сумма надежна, причем абсолютно

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

(153) В системе ничего менять не надо. Получение доказательства - это чистое дополнение к системе. Его даже можно вынести в отдельное приложение

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

(154) Зачем получать доказательство, что данные не изменились, если они ДОЛЖНЫ изменяться?

(156) затем, чтобы в это уверовали остальные и покупали обработку блокчейна у Калимулина ака hockeyist Другого объяснения я не нахожу.

(155) Это ваши данные не верны. Да, чисто теоретически одной и той же хеш-сумме в 32 байта может соответствовать несколько вариантов исходных данных. Здесь ключевое слово МОЖЕТ. Может соответствовать, а может и не соответствовать. Теперь посчитайте какова вероятность, что вы вдруг попадете в такую ситуацию, где это может превратиться в реальность. Учтите, что количество всех возможных сумм в 32 байта сравнимо с количеством атомов в наблюдаемой вселенной. Потом сделайте поправку на то, что вам нужны не любые два совпадения. У вас на руках структурированные данные и совпасть они должны со структурированными данными.
Впрочем, можете и не делать никаких подсчетов. Просто примите к сведению, что хеш-суммы используются давно и повсеместно. Вся криптография на них построена

(156) Чтобы проверить то, что изменилось

Хэш, хэш, они сверяют хэш
Я бы тоже посверял, но у меня нету кэш!

(159) Ты пытаешься решить задачу, которая никогда у 99.(9)% людей не стояла и не стоит. Версионирование - это совсем о другом. По делу тебе уже 100500 раз написали, в том числе (153). Слушай Злопа, он херни не скажет)

(158) Вы написали "абсолютно надежна". Теперь крутитесь. Ладно. А теперь такой вопрос: а что мешает заменить КС вместе с заменяемыми данными? И остается вопрос - что делать с измененными легально данными.

(159) Как проверить? Зачем для этого КС, если достаточно сделать отметку об изменении данных в плане обмена? Причем автоматически, а не глазками глядя на буковки...

(157) Тьфу, так это Калимулин. А я всё гадаю, почему такой упёртый :))

(157) Вот оно что.. А это не тот ли самый разоблачитель неправильного среза последних?

(161) Замену КС контролер обнаружит.
Отметка в плане обмена ненадежна

(164) Как контролер обнаружит замену КС?

(163) Ага и любитель работы с фактическими таблицами (тема из серии на кой нужные регистры, если компуктеры мощные) =)

(165) Сравнит с тем, что у него записано

(166) SQL ненадёжен. Только учётная книга в сейфе у кладовщика с тремя замками 4 класса взломостойкости

(167) Где записано? Откуда он знает, что КС не поменяли и там?

Так вы и до САПа с аксаптами договоритесь.
... и всерьёз.

(169) Например, в личном смартфоне, который лежит у него в кармане. В особо ответственных случаях можно и на бумажке записать

(168) Математика надежна. Надежнее сейфа

(171) Личный смартфон взламывается, бумажку тоже можно подменить.

(171) Смартфоны ненадёжны. Там операционная система от компаний Apple и Google - считай подконтрольных АНБ и ЦРУ. Кем надо быть что бы интегрировать свои решения с этим????

(172) Математика надёжна. Люди, которые вообще не отдупляют о чём ведут дискуссию - ненадёжны

(172) Вот есть у вас документ №0000001 От 13.01.2023. У него есть КС 123 к примеру. Если документ изменят, то и КС пересчитается. А теперь что мешает изменить документ и присвоить ему КС 123?

К примеру контроллер в сговоре с программистом, который этот блокчейн систему ввел, что тогда?)

(173) Ага, и голову у контролера тоже можно подменить. Неубедительно. Бумажка, лежащая в кармане контролера достаточно надежна. И смартфон с фото контрольной суммы тоже

(178) "Бумажка, лежащая в кармане контролера достаточно надежна" - это какой класс безопасности не подскажите?))

(178) Контроллёр ненадёжен. Думается, один специалист с терморектальным криптоанализатором получит бумажку от него быстрее, чем медвежатник взломает сейф с 3 замками 4 класса.

(178) Знаете, вариант с нормально настроенными правами доступа и планом обмена как-то понадежнее будет, если в Вашем случае всё определяется надежностью головы человека и физическим доступом к карману (который любой карманник имеет)...

(177) Проверяющее ПО можно скачивать из надежного источника при каждом сеансе контроля. Или время от времени.

(180) А еще человек может просто пропасть... вместе с "правильными" контрольными суммами.

(182) Что за надежный источник? Почему он надежный?

(181) Нет. Права доступа опираются на человеческие отношения. С людьми можно договориться. С математикой нельзя.

(185) А никто не будет договариваться с математикой. Договорятся с человеком и подгонят математику под ответ.

(183) Примите во внимание простую вещь. Атакующий не знает и не может знать, кто именно является контролерами и сколько их

(185) >>С людьми можно договориться. С математикой нельзя.

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

(186) С каким человеком?

(187) Не приму. При построении системы защиты всегда исходят из того, что атакующий знает все ее особенности. Узнать кто контролер - можно (он регулярно проверяет данные и работает с контрольными суммами). Узнать сколько их - тоже можно.

Что-то я упустил момент, когда дискуссия успела перейти к "бумажному журналу учёта электронных документов".

(189) Контролером, например.

(186) > и подгонят математику под ответ.

главный вопрос математики - а не всё ли равно?

ЧТД - в геометрии

(190) Опишите, пожалуйста, способ узнать личность человека, который работает с данными

(194) Позвонить на телефон и спросить - самый простой и эффективный способ. Личность узнавать вообще не обязательно.

(187) "Атакующий не знает и не может знать, кто именно является контролерами и сколько их" - еще как знает, если он и есть атакующий, а внедренец блокчейна его подельник/соучастник.

(194) способы: агентство ОБС (одна баба сказала), терморектальный криптоанализ, дознаватель/следователь (если из органов), подкуп должностного лица, банальный взлом или утечки

ну так то еще можно просто спросить

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

(194) Только обыск. Ведь судя по всему у него в кармане штанов лежит бумажка.

(191)
В нерезиновой можно прикрепиться к любой поликлинике в пределах района.
Что я и сделал N лет назад.
Но в прошлом году у нерезиновых властей что-то перемкнуло.
И в нерезиновых госуслугах стоит, что N лет назад я всё-таки выбрал базовую поликлинику, а не ту которую хотел.
Только в моей почте осталось напоминание, что услуга была оказана и поликлиника выбрана другая.
Но кому это предъявить? В системе другое, и все слуги системы теперь заявляют, что в системе правда.

Коллеги, извините, дела не ждут. Я вынужден на какое-то время покинуть тему. Спасибо всем за вопросы. И у меня к вам просьба. Прочтите подробное описание как все это работает на хабре или на сайте. Тогда дискуссия будет значительно интереснее

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

ну так вот, даже если учесть во внимание, что алгоритм расчета КС - секрет Полишинеля и утёк вместе с создателями этой шняги, валидность сертификата проверялась по факту поступления денег за него (факт продажи) и еще смс-ка на телепон покупателя сертификата во время его "гашения" в качестве платежного средства

(202) ... и работало это только потому что сертификат оказывался дешевле затрат на организацию схемы по обходу, где самое дорогое - это перехватить SMS (для чего достаточно, например, перевыпустить SIM-карту на нужный номер). А номерки хороших оплаченных сертификатов работники могли сливать по знакомству (что нейтрализовало сразу 2 степени защиты и удешевляло обход третьей степени защиты).

(203) > А номерки хороших оплаченных сертификатов работники могли сливать по знакомству

типа инсайда? доступ к телепонам, на который сертификат был выпущен есть не только лишь у всех

ну и скандалы/интриги/расследования - это ж воровство в чистом виде (статья УК)

(204) ну я х.з.

за несколько лет не было прецендентов. слишком всё размазано по системам, риски не оправданы. хотя номинал сертификата максимальный был на 50 тыр доступен для покупки на сайте

(159) в журнале регистраций без хэшей видны все твои изменения

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

(205) Может просто принцип Неуловимого Джо? Ну и, ясен пень, слишком рискованно подделывать сертификат максимального номинала. Такие, скорее всего, дополнительно будут проверяться. Нужны самые ходовые номиналы, чтобы вообще рутина была для сотрудников. А там, скорее всего 5-10 тыс. максимум.

(207) ну вот пришел ты гасить электросертификат в магазин - а тебе говорят - идите в баню, сертификат уже погашен

твоя реакция? > Может просто принцип Неуловимого Джо?

(208) когда нгасишь сертификат смс надо было вводить. нефиг изобретьа велосипед

(208) Это называется "Спор хозяйствующих субъектов". Покупатель сертификата может подать на магазин в суд.

(208) > Воровство было бы, если бы это были деньги. Но, обычно, это не деньги, а обязательства

по сути это аванс (как и подарочные сертификаты) и при гашении он в чеке не как скидка, а как отдельный вид оплаты

(209) ну дык (202)

(210) а как же Джо, которого никто не ловит?

(211) Аванс - это обязательство. Соответственно, погашенный сертификат - это означает что магазин исполнил обязательство перед тем, перед кем не должен был исполнять. Это не воровство. В лучшем случае здесь найдут состав на мошенничество.

(207) > Нужны самые ходовые номиналы,

да не вопрос, чтобы выпустить сертификат - нужно денег в кассу/банк занести

а если тырить телепоны с уже выпущенных - что с неуловимыми Джо делать? пусть покупатели в суд идут?

говорю же, не было пока еще прецендентов/обиженных покупателей

(212) " где самое дорогое - это перехватить SMS (для чего достаточно, например, перевыпустить SIM-карту на нужный номер)."
Дак это клиника.

Больной то какое решение предлогает?

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

(218) "Можно ли пользоваться одним номером на двух разных сим-картах
По словам операторов, запрет связан с тем, что технологии мобильных операторов просто технически не выдерживают регистрацию двух идентичных абонентов одновременно, отчего начинаются сбои в сети и самые разные неприятные неполадки. Кроме того, существует угроза мошенничества, обмана и большой простор для разных афер и недобросовестных комбинаций, а эти моменты сложно игнорировать."

(219) первая попавшаяся сцылка на выпуск сим-карты

(219) Все правильно. Старую SIM-карту блокируют еще до перевыпуска, новая работает. На какое-то время владелец номера остается без связи, а потому не может заблокировать новую SIM-карту.

(218) > что этот номер ему выдал какой-то сайт с указанием при гашении получить код на сайте.

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

но чтобы магия выпуска электросертификата случилась - нужен факт покупки этого электросертификата (транзакция через банк/кассу) в магазине/на сайте

(221) у вас блокировали сим-карту и вы на какое-то время оставались без связи? или это сферический конь в вакууме?

(222) Да сайт вообще левый, типа купонатора. Он просто усложняет привлечение непосредственного исполнителя к ответственности.

(223) Я менял SIM-карту - она блокируется еще когда стоишь у стойки в салоне связи и ждешь оформления новой. Кстати, телефонная книжка (которая на SIM-карте) тоже блокируется. Т.е. если номера не продублированы в локальной памяти телефона - она исчезнут (хотя ридером SIM-карт ее можно считать). Но сейчас SMS от банков блокируются на сутки (т.к. до этого массово уводили деньги по такой схеме, входя в интернет-банк). А вот как они блокируют (только банки или все короткие номера) - не уточнял.

(223) насколько мне известно - миграция номеров и перевыпуск сим-карт это целый квест

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

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

(224) какой левый сайт типа купонатора? что еще придумать? я вам про реальность, а вы про левые сайты и как наипать систему

(225) Я в МТС поменял такую SIM-карту. Для этого потребовалось по электронной почте обратиться в поддержку, указать салон, куда отправили информацию, что я приду менять SIM-карту без владельца номера. Указание сотрудникам давал лично начальник салона. При смене номера надо было ответить по звонку из службы безопасности на несколько вопросов, ответ на которые должен знать владелец номера, но остальным такую информацию собрать будет довольно дорого стоить. При неправильном ответе SIM-карта блокируется без возможности перевыпуска.

Но это недавно так стало. А до этого в любом салоне любой сотрудник мог перевыпустить SIM-карту. И она полноценно работала сразу же. Поменялось это именно из-за того, что было множество хищений денег из интернет-банка с использованием схемы смены SIM-карты.

(226) Сайт, который подтвердит легенду, что Джо увидел в Интернете рекламу типа "Сообщи нам номер телефона и получи сертификат на 5000 руб.". Выполнил указанные действия, использовал сертификат. В смартфоне в истории останется ссылка на эту страницу. К моменту проверки следователем на сайте будет просто надпись, что эта акция, к сожалению, закончилась. Всё, обычный следователь махнет рукой на это дело и откажет в возбуждении дела.

(227) ну дык денег чтоли в кассу занес? если занес - на здоровье, значит купил серт

>Сайт, который подтвердит легенду, что Джо увидел в Интернете рекламу типа "Сообщи нам номер телефона и получи сертификат на 5000 руб."

факт покупки сертификата можно узнать по выписке банка/чеку, если Джо не может у себя найти

(159) >> Чтобы проверить то, что изменилось.

Чтобы проверить то, что изменилось, нужно видеть - что именно изменилось. Приходим к необходимости либо сравнивать версии - т.е. версионированию, либо хранить где-то сами изменения (разницу или логи изменений), что по сути тоже является урезанным вариантом версионирования.
Довод о возможности развернуть копию базы на момент ДО изменений, чтобы посмотреть что изменилось, даже рассматривать нет смысла.

Фантазии о том, что перед глазами всегда есть какая-то исходная первичка - не более чем фантазии. В 90% случаев её либо нет (например, изменяются проведенные, но ещё не напечатанные и не подписанные документы), либо изменения касаются тех данных, которых в первичке нет. Например, бухгалтер поменял в приходном документе аналитику и счета учета затрат, ТМЦ или взаиморасчётов. Это изменение важное, с точки зрения учёта, но никак не влияет на количества и суммы, которые есть в первичке. Подобных примеров - миллион каждый день в любой системе. Решить их можно только двумя способами.
1. Прослеживаемость. Транзакцию изменить нельзя никак и никому. Только вводом двух новых - первой - сторнирующей исходную и второй - отражающей новую исправленную версию. Такой подход, например, в САПе применяется. Можем проследить всю цепочку изменений. Цепочка может быть какой угодно длины.
2. Разрешить изменения, но построить систему контроля. И вот с системой контроля как раз и начинаются дебри. Что контролировать, кто и как будет контролировать, как вносить изменения и контролировать их правомерность, кто и как будет контролировать контролёров и контролёров, контролирующих контролёров. В любых таких системах одного лишь наличия факта изменения некой контрольной суммы мало. Всегда(!) нужны дополнительные инструменты или механизмы, позволяющие ответить на кучу дополнительных вопросов - кто именно и когда внёс изменения (журнал регистрации), что именно было изменено (версионирование или логи самих изменений), какая версия правильная/корректная, что нужно сделать или не делать для исправления - вносить очередное изменение или сторно или корректировочные транзакции.

(228) За сертификат - не занес. Факт отсутствия покупки сертификата вам придется доказывать следователю, пуская его во всю внутреннюю кухню. Сертификат мог быть оплачен наличными - банк сразу в пролете. Чек на сертификат Джо вообще не получал - он же бесплатный по легенде (это вам надо будет доказать, что бесплатных сертификатов вы не выдавали). Уверены, что ради такой мелочи собственник пустит органы в бизнес?

(230) > Факт отсутствия покупки сертификата вам придется доказывать следователю

сертификат куплен однозначно - это факт

а вот его неправомерное использование в случае спора хозяйствующих субъектов - это отдельная история (сначала внутренее раследование всех заинтересованных и непричастных лиц, в том числе собственников бизнеса, а если совсем всё пичально - то и органов)

ну и еще раз. чтобы воспользоваться сертификатом - нужно заветные цихры из смс ввести. т.е. здесь и сейчас в момент погашения нужно тело.
у вас при оплате покупок в тырнете с карты (авторизация/согласие банка на транзакцию) нет страха, что вашу смс-ку кто-то перевыпустит и с3.14тырит ваши денежки/обязательсво?

(231) >что вашу смс-ку кто-то перевыпустит
SIM-карту

ну и банки еще и аппараты физически гвоздями прибивают к sms-оповещению

(232) у райффа например не прокатит, если сим-карту в другое тело вставить

(231) Ну так я и написал, что самое сложное - это перехватить SMS. Но это не невозможно. Кроме смены SIM-карты есть еще вариант установить троян на телефон. В случае какого-нибудь крупного магазина это может иметь смысл. А в случае Неуловимого Джо - нет смысла.

А вот насчет расследования. У вас что, сертификаты были именные? Т.е. человек подписывал разрешение на обработку персональных данных при покупке сертификата, предъявлял удостоверение личности? Как вы установите, кто реальный покупатель сертификата, чтобы у него выяснить, кому он его подарил? И не удаляете эти данные после погашения сертификата (т.е. когда надобность в них отпала)?

P.S. А ведь легенда может быть и такой: "Купил сертификат на Авито, код сообщил продавец".

P.P.S. Как Вы думаете, с чего бы банки стали подробно расписывать сколько, кому и за что будут списаны деньги, если ввести код из SMS? Просто было достаточно много прецедентов, когда покупали одно, а деньги уходили другим.

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

(234) > P.S. А ведь легенда может быть и такой: "Купил сертификат на Авито, код сообщил продавец".

что за бред?

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

если купил на авито, поздравляю "вы осёл". код с авито не прокатит

(236) Отправил сообщение продавцу с Авито при погашении - тот назвал код.

(237) > Отправил сообщение продавцу с Авито при погашении - тот назвал код.

опять неуловимый Джо с Авито


были случаи, когда покупатель не мог погасить сертификат на кассе (девушке подарили серт). ну так вот, кассир попросил выяснить код, девушка позвонила своему Джо и он ей прислал ей по ватцапу код подверждения :)

повторяю еще раз, пока за столько лет обиженок не было

(238) единственный "рабочий" способ - в базе данных менять телепон у сертификатов на "свой" телефон Джо. но так как все ходы записаны - Джо станет вполне себе уловимым

(238) Дык Неуловимый Джо - это не только человек, но и компания. Поэтому пока и не было. Если операцию можно будет поставить на поток, например, взломав ваш шлюз SMS для перехвата кодов и отправки их на нужный телефон, а сертификаты продавать за часть стоимости - это будет сделано.

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

(206) Журнал регистрации ненадежен

(242) Программист внедряющий блокчейн систему в 1с ненадежен. Дальше будет это обсуждать?

*будем

(241) Но ведь первичный документ не меняется. Т.е. достаточно запретить возможность изменения документов в системе.

(244) Доказательство надежности программы получить нетрудно. Та же хеш-сумма, если вы не в курсе

(246) Хеш имеет к надежности программы отношение чуть меньше чем никакое. Есть, в конце-концов, WriteProcessMemory()...

(245) Запрет изменения ненадежен. Все, что вы предлагаете, в конечном счете опирается на людей. А то, что предлагаю я, опирается на математику. Субъектность убирается полностью. В этом смысл

(246) Я говорил не о программе, а о человеке внедряющего ее. Не путайте теплое с мягким!

(247) Эта атака не пройдет

(248) Все, что Вы предлагаете, в конце-концов опирается на людей. Это мы уже выяснили выше.

(250) Это лишь один из вариантов, и он пройдет при наличии соответствующих прав. А несколько более сложные атаки пройдут и без прав доступа.

Есть хозя, он поставил задачу внедрять ваше чудо. В итоге ему показываются хешсуммы типа b10a8db164e0754105b7a99be72e3fe5. Вот красота, теперь у всех объектов есть это чудо. Но где гарантия, что кодер, внедяя это добро не оставил дыр? А может он и сам соучастник, а что ему мешает изменить код, чтобы сделать лазейку? А что мешает это сделать остальным имеющим доступ к конфигуратору и sql?

(249) А что там внедрять? Там несколько десятков строк кода. Пригласили трех независимых программистов. Они 10 минут посмотрели в код, дружно покивали, сделали вам хеш-сумму и пользуйтесь на здоровье.

Кстати, вопрос как определить легитимность изменения данных также оставлен без ответа.

о какой надежности мы говорим?) (248) "Все, что Вы предлагаете, в конце-концов опирается на людей" - у вас все тоже самое.

(254) А код может быть и закрытым, что тогда?

Например всякие отраслевые решения

(253) Есть несколько контролеров. Никто, кроме хозяина, не знает кто они, где они, на каких устройствах они запускают ПО контроля. Оставьте это. Программу контроля не сломать

(254) Хеш-сумму чего? Кода? Байт-кода?

(257) С чего ему быть закрытым? Он уже больше пяти лет, как открыт

(259) нахера она нужна? если есть журнал регистраций?

(259) Контролер не знает, что он контролер? Оригинально. А программы хозяин сам устанавливает и обслуживает? А снифферы трафика уже все поломались?

(263) а самое галвнео теперь все воруют контролеры!!!

(259) какие блин контроллеры? Есть фирма ХОТАшот, его хозя проникся вашей идеей и заказал ваше внедрение на нимфостате? Какие блин 3 разраба независимых, какие еще контролерные контролеры? Все будет по простой схеме. Вы ему внедряете ваше расширение, показываете как это работает, она вам оплачивает за работу.  Сам он в 1с не бельме, своих спецов нет. Вы о чем блин?)

(263) А хозяин не знает, что он хозяин, и хакер не знает, что он хакер, поэтому систему не сломать :)))

с хозяином н апару - очень удобно и никто не видит )))

о какой безопасности может идти речь?

(262) Журнал регистрации ненадежен. Сделать транзакцию мимо журнала регистрации, как вы понимаете, совсем не трудно

(269) пеерсчитать всю твою цепочку как ты понимаешь не сложно

(269) очень трудно пользователю это сделать - вот я дам тебя права юзеры ты не сдлеаешь

(270) Контролер обнаружит пересчет

(272) По бумажке из кармашка?

(272) А если контролёр в доле?

(272) где хранится хешсумма? Что мешает ее программно изменить?

Имея доступ к конфигуратору и скулю, что мешает имитировать корректность работы блокчейна для юзвера?

(274) Контролер не знает и не может знать, есть ли еще контролеры и сколько их

(277) В вашем случае контроллер это человек, сотрудник компании?

(277) Почему не знает? Что ему помешает? Вы полагаетесь на секретность того, что в принципе невозможно сохранить в секрете.

(276) Секрет мешает. В конце каждого сеанса контроля, контролер сохраняет последнюю хеш-сумму в секретном месте (фотка, бумажка)

(277) А сколько минимально контролёров требует твоя система на одного кладовщика?

(279) А что ему поможет в этом деле?

(280) И как он решает - куда сохранять?

(283) куда админ скажет ахаха )))

(280) " сохраняет последнюю хеш-сумму в секретном месте (фотка, бумажка)" - Посылает по факсу на другой континент дельфину (с)

(282) Немотивированная передача информации (хешей).

(281) Это количество стремиться к нулю (но не достигает его). Разве не очевидно?

(287) так и скажи что не хочешь включать рлс

(287) Т.е. повысить ФОТ кратно? Да еще работать в чёрную?

(287) Т.е., если в компании один склад, с одним кладовщиком, то контролёр может быть уверен, что он единственный.

(290) Один или два. Точно знает только хозяин

(280) "в секретном месте (фотка, бумажка)" - и вы на полном серьезе считаете это безопасным? Я не в плане подбора, а в плане перехвата информации, да просто по камерам посмотреть, что там на бумажку принтер выплюнул и т.д.

(291) 2 контролера с зарплатой на порядки выше, чем у кладовщика контролируют 1 кладовщика? План - огонь!

И вы так и не ответили, что делать, когда нужно первичные документы править и множество раз в вашем варианте реализации?

как исктаь что исправили?

И самый прикол будет в следующем: внедрили эту системы с кодовыми словами, блокчейном и прочими ништяками. Но это никак не помешало кладовщику Васе, в последний день работы стянуть пару ящиков с товаром и уехать в закат)

(292) По каким камерам? Где находится контролер знает только хозяин. А может и не знает, если будет работать через специальную фирму, предоставляющую услуги контролеров

(295) В религии Калимулина это неправильный вопрос, у него только одно булево (да/нет)

(296) А можно просто не поставить пару ящиков на приход :)

(297) Дальше то что ??? увидел что чегото поменяли какие действия? Когад поменяли? Кт о поменял? Что поменял?

(294) В смысле что делать? Ничего особенного. Точно так же проверять

ахахаххах ))))))))

(297) Вот эта фирма и будет воровать :)

т.е. у него уволокли вагон тушенки ))) он радуется что система рабоатет и далее проверяет?

(300) Увидел, что документ изменен, проверил его. Вот, собственно и все

(305) А если документ не изменен, а сразу был введен некорректно?

(305) как он узнает какой изменен?

(306) Тогда система Калимулина не работает :)))

кто изменил когда изменил?

ЧТО изменил

(304) Он радуется, потому что не знает, что уволокли вагон тушенки :)

(306) Один ввел некорректно, а другой этого не заметил?

(311) не знает он что уволкли он просто значет что чета не так

(312) А нет другого. Представьте себе, всего 1 сотрудник занимаете этими документами.

(312) Какой другой? У вас всю первичку контролеры вводят?

(241) Ты видимо совсем не читал.
Я про первичный документ аж несколько предложений написал.
Во-первых, утверждение, что первичка всегда под рукой - это твоя личная фантазия. Причём очень далёкая от реальности. И не я один тебе об том уже писал.
Во-вторых, в документе могут быть изменены данные, которых в первичке физически нет. Например, перевыбран другой элемент справочника "Договоры", изменены счета учёта и аналитика учёта затрат, ТМЦ или взаиморасчётов, исправлены какие-то прочие реквизиты, которые важны для учёта, но отсутствуют в первичном бумажном документе и никак не влияют эту самую первичку.

Никто не критикует твою идею с хеш-суммами. Она не хороша и не плоха.
У неё есть свои определенные преимущества. И она решает вполне определенные задачи.
Но не надо натягивать сову на глобус и пытаться доказать, что она способна быть альтернативой версионированию.
Хеш-суммы с блокчейном не заменяют версионирование. Никак.

Тут нет предмета спора как такового.
Это попытка сравнения тёплого с красным.

Попытка доказать, что хеш-сумм с блокчейном достаточно для контроля достоверности и корректности данных, обречена на провал.
Потому что блокчейн отвечает только лишь на вопрос о неизменности данных. И не на какие больше.
Действительно есть целый ряд случаев, когда этого может быть вполне достаточно.
Но в большинстве случаев всё таки надо точно знать - что именно было изменено. А тут никакие хеш-суммы не помогут.

*занимается

(307) ПО контроля выдаст все измененные с предыдущего сеанса документы

(318)   hockeyist
269 - 13.01.23 - 14:43
(262) Журнал регистрации ненадежен. Сделать транзакцию мимо журнала регистрации, как вы понимаете, совсем не трудно

(318) ты погорел на своей логике

(316) "Но в большинстве случаев всё таки надо точно знать - что именно было изменено" - еще важно кто и когда)

(320) ПО контроля не использует журнал регистрации, там блокчейн

(318) Допустим, ПО выдало, что с момента последнего сеанса изменено 20000 документов. Твои дальнейшие действия?

(318) И там будет 100500 изменений, из которых легитимны 1000499. Как найти то единственное нелегитимное изменение?

(322) мимо блокчейна псиать не сложно как ты понимаешь

(324) ахаха спам блокчейна ))))

(323) (324) Все же просто! Нанимаем еще 20 сотрудников обслуживания блокчейнов. А те уже будут проводить расследования по каждой транзакции)

(321) >>  еще важно кто и когда.

Безусловно. Но я предположил, что в блокчейне записаны не только сами хеш-суммы, но и момент (дата+время) их изменения, и автор.

(327) 20 на каждого кладовщика. И с соответствующей зарплатой за секретность.

(327) " проводить расследования по каждой транзакции)" -  Для этого они должны знать кто именно контролёр, чтобы он выдал им бумажку, с которой сверять. А по условию контролёр неизвестен. Тупик :)))

(329) Зарплату им платить так же в биткоинах по блокчейну, чтобы их не вычислили и не подкупили)

(324) Не будет там 100500 изменений. Будут изменения за прошедшие сутки. Что вы пытаетесь доказать? Что есть изменения в базе, которые надо контролировать, и есть такие, которые не надо? А я с вами разве тут спорил? Изменения в заказах можно не контролировать. Изменения в комментариях к документам тоже. А вот количество, цену и сумму в поступлении на склад и в списании со склада надо контролировать. По любому. Сколько бы их ни было

походу мы создали депутатов и чиновников - чотаделают контролируют но все бесполезно

(332) ну дак твоя гПоделка не более чем убогая версия версионирования

(332) В крупной конторе за одни сутки бывает и больше изменений :)))

(325) Не сложно, согласен. Просто невозможно.

думаю чо так смешно, оказываетс япятница же

(336) т.е. мимо журнала можно а мимо блокчена нельзя?

(332) А воттеперь ты с правами кладвощика раскажи как это сделаешь

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

(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) Предлагаю обсудить ситуацию, когда контролер обнаружил расхождение, но никто этого не увидел, потому что система это не вывела на экран :)