Русский
Русский
English
Статистика
Реклама

Учет

Привет из прошлого кто, что и зачем пишет в журнале учета СКЗИ

11.02.2021 10:09:47 | Автор: admin

Скорее всего, вы знаете, что учет СКЗИ регламентирован Инструкцией об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащих сведений, составляющих государственную тайну. Этот документ невиданной силы утвержден приказом Федерального агентства правительственной связи и информации при президенте Российской Федерации (ФАПСИ) от 13.06.2001 152.

Тогда, 20 лет назад, сертифицированные СКЗИ применялись крайне редко, а большинство организаций не имели такой разрозненной и распределенной по всей стране ИТ-инфраструктуры. В итоге инструкция, например, до сих пор не предусматривает возможность удаленной передачи ключей шифрования, а журнал учета требуется хранить в отдельном помещении. Вести учет в электронном виде можно, но только с применением квалифицированной ЭП (учет СКЗИ в электронном виде это тема для отдельной статьи, и об этом мы поговорим следующий раз), либо сопровождать каждое действие соответствующими актами.

Кстати, само ФАПСИ было расформировано в 2003 году. Его функции были распределены между ФСО, ФСБ, СВР и Службой специальной связи и информации при ФСО. Но написанный агентством документ не утратил силы.

Кто и как ведет учет

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

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

В первом случае организация должна издать приказ о создании ОКЗ, определить его структуру и обязанности сотрудников. Например:

  • начальник отдела занимается организацией и совершенствованием системы управления работой своих сотрудников;

  • администратор безопасности обеспечивает сохранность информации, обрабатываемой, передаваемой и хранимой при помощи средств вычислительной техники.

Все работники, которые занимаются установкой и настройкой СКЗИ и в принципе имеют к ним доступ, должны быть внесены в приказ и ознакомлены с ним. Для каждой должности нужно разработать должностную инструкцию и ознакомить пользователей с порядком применения СКЗИ.

В итоге перечень необходимых документов состоит из:

  • приказа о создании ОКЗ;

  • должностных инструкций;

  • утвержденных форм журналов учета;

  • шаблонов заявлений, актов;

  • инструкции для пользователей по работе с СКЗИ.

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

Но если орган криптографической защиты информации это структурное подразделение организации, на его плечи ложится ведение обоих журналов. Дело в том, что в этом случае организация не только является обладателем конфиденциальной информации, но и выполняет часть функций ОКЗ. Например, крупные холдинги, как правило, выделяют в своем составе ИТ-компанию, которая в том числе отвечает за информационную безопасность с использованием СКЗИ. Она ведет все журналы и сопутствующую документацию и является для своего холдинга поставщиком услуг.

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

Вы еще тут? Надеемся, не запутались!

Журналы учета хранятся в течение 5 лет. Сами СКЗИ и документация к ним должны находиться за семью замками в специальном помещении, а доступ туда могут иметь только сотрудники ОКЗ.

Операции с СКЗИ: взятие на учет

Рассмотрим порядок учета на конкретном примере (данные в таблицах ниже вымышленные все совпадения случайны). Организация N обладатель конфиденциальной информации хочет использовать СКЗИ компании КриптоПро. При этом организация N не готова создавать у себя ОКЗ и обращается к сервис-провайдеру, который будет предоставлять ей соответствующие услуги. Итак, для начала вендор ПАК должен предоставить организации N исходные данные для учета. Выглядит это так:

Предмет

Данные

с/н лицензии СКЗИ

Сопроводительное письмо

т/н 44313 от 22.02.2020

-

Формуляр СКЗИ КриптоПро CSP версии 4.2

ЖТЯИ.00002-02 30 10

-

Диск CD-ROM с дистрибутивом СКЗИ

Инв. 5421

34DR-4231-4123-0003-1200

HR9J-EEWR-45W3-VL4Q-842Q

4454-NG96-8421-6401-WQRG

В 16 графы журнала поэкземплярного учета должна попасть информация о:

диске с дистрибутивом;

формуляре;

серийном номере лицензии на СКЗИ.

После заполнения всех этих данных СКЗИ выдаются пользователям, то есть тем работникам в организации, для которых они закупались. Это может быть как сотрудник бухгалтерии, который применяет ЭП для подписания и отправки документов, так и другой ответственный специалист, взявший на себя обязательства по сохранности СЗКИ.

На этом этапе заполняются 7 и 8 графы журнала (кому и когда выдается СКЗИ с обязательной росписью пользователя). Если возможности расписаться в журнале нет, то можно заполнить акт передачи, где в свободной форме указывается, кто (администратор безопасности) и кому (пользователю) передает СКЗИ. При этом обе стороны расписываются, а номер акта вносится в 8 графу (Дата и номер сопроводительного письма).

В 9 графу записывается имя сотрудника, производившего установку СКЗИ. Чаще всего это делает специалист технической поддержки, который также является администратором безопасности. Но это может быть и пользователь, если он обладает соответствующими навыками и правами доступа в сеть. В 11 графе указывается серийный номер материнской планы или номер опечатывающей пломбы системного блока.

Если сотрудник, который производил установку, уволился, то СКЗИ нужно изъять и составить акт, в котором указывается предмет и способ изъятия (например, удаление ключевой информации с носителя). Все это фиксируются в 12, 13, 14 графах.

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

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

Заглянуть в журнал учета
Журнал поэкземплярного учета СКЗИ для обладателя конфиденциальной информацииЖурнал поэкземплярного учета СКЗИ для обладателя конфиденциальной информации

Журнал учета СКЗИ для органа криптографической защиты во многих пунктах перекликается с аналогичным документом для организации и заполняется по такому же принципу, поэтому не будем подробно останавливаться на его разборе. В примере ниже ООО Организация это обладатель конфиденциальной информации, который воспользовался услугами сервис-провайдера.

Заглянуть в журнал еще раз
Журнал поэкземплярного учета СКЗИ для органа криптографической защитыЖурнал поэкземплярного учета СКЗИ для органа криптографической защиты

Что в итоге?

Сложно не согласиться с тем, что все эти требования уже давно морально устарели и Инструкция нуждается в актуальных корректировках, но пока мы вынуждены выполнять требования ее текущей редакции. Обратите внимание, что для ведения журнала поэкземплярного учета СКЗИ в электронном виде требуется подписывать документы только квалифицированной ЭП либо сопровождать каждое действие соответствующими актами. Если же речь идет о физическом документе, то все данные и подписи должны быть внесены в него всеми ответственными лично.

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

Надеемся, эта памятка была для вас полезной.

Автор: Никита Никиточкин, администратор реестра СКЗИ Solar JSOC Ростелеком-Солар

Подробнее..

Учет умер, да здравствует учет

31.03.2021 16:16:13 | Автор: admin

Учет, как особый, достаточно сложный и уважаемый вид человеческой деятельности действительно умер. Навсегда ушли те времена, когда человек, нашедший в себе силы освоить премудрости дебета и кредита, сразу становился обладателем магических перков. Он мог разговаривать с налоговой и следить за тем, чтобы не разворовали склад. При том, что не стоял день и ночь рядом со складом с ружьем, а использовал магию цифр, сидя в комфортном кабинете. Теперь с налоговой разговаривает программа 1С. И о чем они там перешептываются, похоже, скоро уже не будет знать никто. А на страже склада стоит чудесный алгоритм под названием контроль отрицательных остатков (плохо, правда, стоит, но это тема отдельного разговора). Человеку же остается всего лишь незавидная роль оператора по вводу данных. Да и то, пока. Совсем скоро программы окончательно научатся обмениваться данными без участия людей-операторов, и будет у нас самый настоящий и повсеместный скайнет.

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

Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.

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

для каждого документа из документов в базе
превратим данные документа в строку
добавим к ней предыдущий ключ/хеш
получим новый ключ/хеш для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец

В этих шести строчках описана технология блокчейн в чистом виде. Под получением ключа/хеша подразумевается вычисление какой-либо хеш-функции, например SHA256. Сразу надо отметить, что человек может вести журнал в той же самой базе. Как мы уже говорили, данные в базе могут изменить. В том числе могут изменить сам журнал. Но человека это не волнует. Потому что, как вы увидите дальше, изменить журнал незаметно для человека не получится.

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

Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы. Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:

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

Мы убедились, что документы внесенные в журнал не изменялись. После чего добавили в журнал новую порцию документов, попутно сверяя каждый с первичным документом. Теперь осталось определиться с тем, что делать когда обнаруживается изменение ранее введенного в систему документа. В принципе, это нормальный рабочий момент. Время от времени он имеет место быть. Поэтому, человек принимает следующее решение. При обнаружении изменения, делать повторную сверку с первичным документом, старую запись в журнале оставлять как есть, а в конец журнала добавлять новую запись. В старой записи указывать ссылку на новую, как на потомка. А в новой указывать ссылку на старую, как на предка. И, наконец, использовать указатель на предка при формировании ключа. Список действий в окончательном виде выглядит так:

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

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

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

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

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

Подробнее..

Учет спецодежды и спецоснастки в 1СERP как обойти ограничения типового функционала

13.05.2021 18:23:09 | Автор: admin

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

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

В типовом функционале ERP существует ряд ограничений:

  • Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.

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

  • Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.

Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.

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

  • Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.

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

Ограничение типового функционала 1С:ERP заключается в данном случае в том, что по счетам МЦ и 10.11 не будет отображаться движение спецодежды в том же месяце, в котором произошла передача и было сделано списание или перемещение. Пользователи не смогут получить полные сведения по эксплуатации одежды в апреле, в котором она и была передана, данные будут отображены только в мае. Такой формат противоречит полноте отображения данных.

  • Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.

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

Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.

Может ли автоматизация процессов в 1С решить насущные проблемы учета?

В нашей работе мы сталкиваемся с абсолютно разными отраслями, масштабами организаций, отношением сотрудников к внедрению новых механизмов и правил. Но 90% компаний схожи в двух моментах: бухгалтерии нужны максимальное удобство и экономия времени при аврале задач, а руководству - полная и прозрачная финансовая картина по процессам производства и контроль состояния активов.

Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.

Данный отчет позволяет:

  • увидеть суммовые и количественные показатели в одном отчете, в разрезе всей необходимой аналитики;

  • работать без ограничений по отражению ТМЦ, срок службы у которых закончился. В отчете отражаются все ТМЦ, числящиеся в учете, но с помощью настроек пользователь может сам установить отбор, показывать ему такие ТМЦ или нет;

  • увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;

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

Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.

Разбираемся с инвентаризацией

Чуть выше мы говорили о том, что 1С:ERP в принципе нет документов по инвентаризации. Но данный процесс нельзя обходить стороной. Удачной альтернативой ручному труду будет является проведение доработки самой системы 1С, учитывая нюансы самой компании, так как тут все индивидуально.

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

Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.

Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации

В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:

  • заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;

  • заполнение реквизитов Физическое лицо получатель при перемещении.

Разумеется, можно рассматривать альтернативные решения автоматизации. Например, если компания будет формировать оборотку, а затем загружать заполненный excel-файл в свою систему. Но учитывая объемы работ, с уверенностью можно сказать, что такой способ повлияет на рост количества ошибок.

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

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

Подробнее..

Учет рабочего времени MeteorHR

14.09.2020 06:15:13 | Автор: admin

Здравствуйте! Меня зовут Руслан и разрабатываю сервис meteorhr.com для управления персоналом, который позволит Вам сосредоточиться на людях, а не процессах. Разработка сервиса я занимаюсь полностью один и сервис бесплатный.

Сегодня сервис поможет Вам наладить учет рабочего времени с использованием функции мобильного телефона геопозиции. Сотрудник отмечает свой приход (уход) на работу (с работы) в мобильном приложении, и если позиция совпадает с данными позиции офиса происходит отметка. В сентябре я планирую добавить в приложение дополнительно авторизацию к геопозиции по сканированию лица. Приложение написано на Flutter, вчера разместил в play market жду валидации от google.

Сегодня я занят в разработки удобных графиков выходов, что бы сравнивать время и дату графика и фактическую дату и время отметки, для ведения рейтинга сотрудников и табеля рабочего времени. На основание табеля рабочего времени сотрудник в реальном времени видит свою ЗП.

Я бы хотел обратиться к сообществу habr за помощью, так как мой проект бесплатный мне нужны тестировщики, может кто-то поможет с дизайном приложения, у кого-то есть идеи, прощу дать информацию на email: ruslan.khissamov@meteorhr.com. Одна из целей помочь мало бизнесу.

Всем заранее спасибо за обратную связь.

PS Пишу не так часто, особенно статьи, поэтом сделайте скиду если что-то не так. ;)

Подробнее..

Контроль отрицательных остатков

22.03.2021 16:16:43 | Автор: admin

Контроль отрицательных остатков - это когда перед тобой стоит покупатель, держит в руках нечто, что он собрался купить, а система тебе говорит: а нету этого в наличии, не буду оформлять продажу! Самое смешное, что на первый взгляд все кажется логичным и рациональным. Человек склонен ошибаться. У него может дрогнуть рука и вместо 10 шт. он введет 100 и не заметит. И вот в этот момент добрая и бдительная система подскажет ему путь к истине. И так оно и происходит в тех редких (ну очень!) случаях, когда вводят 100 вместо 10, а на складе как раз те самые 10 и есть. Но склады, они на то и склады чтобы хранить много и очень много. И если на складе в момент пользовательской ошибки будет не 10, а 100, 1000 или 10 000, то тогда система перестанет быть бдительной и заснет на день, неделю, месяц... Было бы лучше, если бы она заснула навсегда (почему - вы поймете чуть позже), но, к несчастью, рано или поздно система просыпается. И вы обнаруживаете себя в ситуации, которую я описал в самом начале. Вот они - эти 10 шт. в руках у покупателя. И руки ни у кого не дрожат. 10 шт. у покупателя и те же 10 шт. пользователь пытается ввести в систему. Но не тут-то было! Система кричит вам: стоп! стоп! стоп! отрицательный остаток! И что теперь делать пользователю? Глубоко вздохнуть и начать сверять все документы с этим товаром за день, неделю, месяц... Как повезет. Если очень повезет, то прилетит фея из известного анекдота и все будет "по-настоящему". В нашем случае "по-настоящему" - это когда причиной отрицательного остатка является не ошибка при вводе какого-либо документа, а пропуск приходного документа. Искать черную кошку в темной комнате особенно тяжело, когда ее там нет. Теперь пользователь просмотрит документы не за неделю-месяц, а вообще все. За все время. Не найдет ошибок. Еще раз глубоко вздохнет. Проведет инвентаризацию на складе. Оформит поступление товара... Все это время продажи этого товара будут стоять (ха! ха!) Вот она - месть программиста!

Самое удивительное в этой истории то, насколько широко распространен ныне этот "замечательный" алгоритм. Суеверный ужас пользователя перед отрицательными числами еще как-то можно понять. Но чем объяснить неприязнь к отрицательным числам со стороны разработчиков? Со стороны тех, кто с математикой все-таки не на "вы"? Отрицательное число - такое же число, как и положительное. И чем, в принципе может быть плох отрицательный остаток? Кому он может навредить? Вот положительный может навредить. И очень сильно. Не верите? Тогда представьте себе, что у вас в системе "хороший", положительный остаток, 100 тонн яблок. А на складе 0. И к вам подходит клиент, который уже оплатил этот самый "хороший" остаток. И теперь он хочет, чтобы его десять тяжелых грузовиков были немедленно загружены. А вот "плохой" остаток никогда не привел бы вас к такой ситуации, не так ли? Как хотите, но лично я бы сперва контролировал положительные остатки, а уж потом, на досуге, отрицательные.

Контроль отрицательных остатков исходит из неверного постулата, что причина отрицательного остатка может быть найдена и исправлена "здесь и сейчас". Сам факт наличия ошибок, приводящих к отрицательным остаткам почти всегда обнаруживается со значительной задержкой во времени, а поиск ошибки может сильно затянуться. Можно сказать, что контроль отрицательных остатков попросту не работает. Но этого мало. Контроль отрицательных остатков не только бесполезен, он еще и опасен. И вот чем:

Мы ни на полнанометра не оторвемся от реальности, если будем исходить из того, что продажи нам не даст остановить никто. Теперь представим себе ситуацию. На складе лежит 10 шт. В учетной системе числится остаток 5 шт. Приходит клиент и забирает все 10 шт. Какие тут могут быть варианты действий пользователя? Первый, самый распространенный, не регистрировать операцию вовсе. Отложить регистрацию до лучших времен. Когда кто-то сумеет найти причину отрицательного остатка и исправить ее. Чем он опасен? Тем, что теперь на складе 0 шт., а в системе все еще числится 5 шт. И рано или поздно эти несуществующие 5 шт. будут проданы. Понимая, что отказ от регистрации события может привести к перерезервированию, пользователь может поступить более изощренно. Списать количество до нуля. Т.е. зарегистрировать отпуск 5 шт. Но это не сильно отличается от первого варианта. Через 10 минут другой пользователь, который вводит приходные документы, спохватится и зарегистрирует наконец поступление 5 шт. То самое поступление, отсутствие которого и вызвало срабатывание контроля отрицательных остатков. И мы снова получим ситуацию с нулевым остатком на складе и положительным остатком в системе. Вообще говоря, искажать информацию или откладывать ввод информации - не самая лучшая идея. Корректный и максимально быстрый ввод информации должен быть в приоритете над всеми прочими соображениями. Поэтому самым разумным было бы зарегистрировать операцию как есть и вывести остатки в минус. Но именно этого нам и не дает сделать жесткий контроль отрицательных остатков!

Справедливости ради надо отметить, что иногда контроль отрицательных остатков может быть реализован в мягкой форме. В отличие от жесткого, мягкий контроль не блокирует работу пользователя, а только лишь предупреждает о появлении отрицательных остатков. Это избавляет нас от опасности перерезервирования. Но и мягкий контроль не является просто бесполезным. Он также вреден, хотя этот вред не столь очевиден, как в случае с жестким вариантом.

Базы данных нуждаются в контроле. Если не будет какой-либо системы обеспечивающей связь с реальностью, база данных очень быстро станет бесполезной и опасной. Это очевидно всем, и пользователям, и профессионалам. Но тут есть еще один момент. Он очевиден, как я надеюсь, профессионалам. А вот пользователям - вовсе нет. Речь идет о том, что систему связи с реальностью невозможно построить только лишь на алгоритме. Какими бы хитрыми ни были ваш алгоритм или группа алгоритмов, не будет такого, что вы их запускаете и получаете на выходе что-то типа: все в порядке, база полностью соответствует реальности. Действительно работающие системы связи с реальностью требуют наличия посредника (кем бы он ни был, но чаще всего это человек). Результат достигается в связке алгоритма и посредника.

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

Те, кто придумали контроль отрицательных остатков, явно страдают болезнью, которую я ("украв" яркое определение у дедушки Ленина) называю детской болезнью автоматизации в учете. Они совершенно правильно считают, что настоящая автоматизация - это когда система выполняет полезные действия сама. Не пользователь должен сообразить что именно ему сейчас требуется. Найти, к примеру, соответствующий отчет, установить его параметры и получить наконец информацию. Нет, система сама все это сделает за него в нужное время и в нужном месте. И это отлично работает во многих случаях. Например, когда мы резервируем товар. Мы не лезем в один отчет, чтобы посмотреть сколько есть на складе. Затем в другой отчет, чтобы посмотреть сколько уже зарезервировали. Система сама определяет свободный остаток и возможное количество резерва. Кстати, систему резервирования довольно часто путают с контролем отрицательных остатков. Но это суть разные вещи. Система резервирования действует автономно от начала и до конца. А контроль отрицательных остатков блокирует работу и передает решение проблемы на сторону пользователя. Собственно, этот момент и является ключевым в вопросе применимости автоматизации. Жесткий контроль отрицательных остатков останавливает процесс и ждет решения от пользователя. Но пользователь не может решить проблему! У него просто нет времени на это. Кроме того, у пользователя может не быть (и скорее всего не будет) полномочий на внесение исправлений в далеком прошлом. Мягкий контроль не останавливает процесс, но он тоже вреден. Сообщение об отрицательных остатках по причинам, описанным выше, будет полностью проигнорировано пользователем. Сам по себе сигнал об отрицательных остатках - важный и полезный. Но он подается в неподходящем месте и в неподходящее время. В результате, критически важный сигнал будет потерян. Все уверены в том, что в системе есть работающий контур, но он не работает.

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru