Контроль отрицательных остатков - это когда перед тобой стоит покупатель, держит в руках нечто, что он собрался купить, а система тебе говорит: а нету этого в наличии, не буду оформлять продажу! Самое смешное, что на первый взгляд все кажется логичным и рациональным. Человек склонен ошибаться. У него может дрогнуть рука и вместо 10 шт. он введет 100 и не заметит. И вот в этот момент добрая и бдительная система подскажет ему путь к истине. И так оно и происходит в тех редких (ну очень!) случаях, когда вводят 100 вместо 10, а на складе как раз те самые 10 и есть. Но склады, они на то и склады чтобы хранить много и очень много. И если на складе в момент пользовательской ошибки будет не 10, а 100, 1000 или 10 000, то тогда система перестанет быть бдительной и заснет на день, неделю, месяц... Было бы лучше, если бы она заснула навсегда (почему - вы поймете чуть позже), но, к несчастью, рано или поздно система просыпается. И вы обнаруживаете себя в ситуации, которую я описал в самом начале. Вот они - эти 10 шт. в руках у покупателя. И руки ни у кого не дрожат. 10 шт. у покупателя и те же 10 шт. пользователь пытается ввести в систему. Но не тут-то было! Система кричит вам: стоп! стоп! стоп! отрицательный остаток! И что теперь делать пользователю? Глубоко вздохнуть и начать сверять все документы с этим товаром за день, неделю, месяц... Как повезет. Если очень повезет, то прилетит фея из известного анекдота и все будет "по-настоящему". В нашем случае "по-настоящему" - это когда причиной отрицательного остатка является не ошибка при вводе какого-либо документа, а пропуск приходного документа. Искать черную кошку в темной комнате особенно тяжело, когда ее там нет. Теперь пользователь просмотрит документы не за неделю-месяц, а вообще все. За все время. Не найдет ошибок. Еще раз глубоко вздохнет. Проведет инвентаризацию на складе. Оформит поступление товара... Все это время продажи этого товара будут стоять (ха! ха!) Вот она - месть программиста!
Самое удивительное в этой истории то, насколько широко распространен ныне этот "замечательный" алгоритм. Суеверный ужас пользователя перед отрицательными числами еще как-то можно понять. Но чем объяснить неприязнь к отрицательным числам со стороны разработчиков? Со стороны тех, кто с математикой все-таки не на "вы"? Отрицательное число - такое же число, как и положительное. И чем, в принципе может быть плох отрицательный остаток? Кому он может навредить? Вот положительный может навредить. И очень сильно. Не верите? Тогда представьте себе, что у вас в системе "хороший", положительный остаток, 100 тонн яблок. А на складе 0. И к вам подходит клиент, который уже оплатил этот самый "хороший" остаток. И теперь он хочет, чтобы его десять тяжелых грузовиков были немедленно загружены. А вот "плохой" остаток никогда не привел бы вас к такой ситуации, не так ли? Как хотите, но лично я бы сперва контролировал положительные остатки, а уж потом, на досуге, отрицательные.
Контроль отрицательных остатков исходит из неверного постулата, что причина отрицательного остатка может быть найдена и исправлена "здесь и сейчас". Сам факт наличия ошибок, приводящих к отрицательным остаткам почти всегда обнаруживается со значительной задержкой во времени, а поиск ошибки может сильно затянуться. Можно сказать, что контроль отрицательных остатков попросту не работает. Но этого мало. Контроль отрицательных остатков не только бесполезен, он еще и опасен. И вот чем:
Мы ни на полнанометра не оторвемся от реальности, если будем исходить из того, что продажи нам не даст остановить никто. Теперь представим себе ситуацию. На складе лежит 10 шт. В учетной системе числится остаток 5 шт. Приходит клиент и забирает все 10 шт. Какие тут могут быть варианты действий пользователя? Первый, самый распространенный, не регистрировать операцию вовсе. Отложить регистрацию до лучших времен. Когда кто-то сумеет найти причину отрицательного остатка и исправить ее. Чем он опасен? Тем, что теперь на складе 0 шт., а в системе все еще числится 5 шт. И рано или поздно эти несуществующие 5 шт. будут проданы. Понимая, что отказ от регистрации события может привести к перерезервированию, пользователь может поступить более изощренно. Списать количество до нуля. Т.е. зарегистрировать отпуск 5 шт. Но это не сильно отличается от первого варианта. Через 10 минут другой пользователь, который вводит приходные документы, спохватится и зарегистрирует наконец поступление 5 шт. То самое поступление, отсутствие которого и вызвало срабатывание контроля отрицательных остатков. И мы снова получим ситуацию с нулевым остатком на складе и положительным остатком в системе. Вообще говоря, искажать информацию или откладывать ввод информации - не самая лучшая идея. Корректный и максимально быстрый ввод информации должен быть в приоритете над всеми прочими соображениями. Поэтому самым разумным было бы зарегистрировать операцию как есть и вывести остатки в минус. Но именно этого нам и не дает сделать жесткий контроль отрицательных остатков!
Справедливости ради надо отметить, что иногда контроль отрицательных остатков может быть реализован в мягкой форме. В отличие от жесткого, мягкий контроль не блокирует работу пользователя, а только лишь предупреждает о появлении отрицательных остатков. Это избавляет нас от опасности перерезервирования. Но и мягкий контроль не является просто бесполезным. Он также вреден, хотя этот вред не столь очевиден, как в случае с жестким вариантом.
Базы данных нуждаются в контроле. Если не будет какой-либо системы обеспечивающей связь с реальностью, база данных очень быстро станет бесполезной и опасной. Это очевидно всем, и пользователям, и профессионалам. Но тут есть еще один момент. Он очевиден, как я надеюсь, профессионалам. А вот пользователям - вовсе нет. Речь идет о том, что систему связи с реальностью невозможно построить только лишь на алгоритме. Какими бы хитрыми ни были ваш алгоритм или группа алгоритмов, не будет такого, что вы их запускаете и получаете на выходе что-то типа: все в порядке, база полностью соответствует реальности. Действительно работающие системы связи с реальностью требуют наличия посредника (кем бы он ни был, но чаще всего это человек). Результат достигается в связке алгоритма и посредника.
Пользователю, однако, все это неочевидно. Он пользователь и полагается на профессионалов. Он склонен думать, что профессионалы уже все предусмотрели. Они снабдили его базу данных чудо-алгоритмом под названием контроль отрицательных остатков. Этот алгоритм сам (подумать только!) находит ошибки. И чего еще тут можно желать? Контроль отрицательных остатков создает у пользователей опасную иллюзию.
Те, кто придумали контроль отрицательных остатков, явно страдают болезнью, которую я ("украв" яркое определение у дедушки Ленина) называю детской болезнью автоматизации в учете. Они совершенно правильно считают, что настоящая автоматизация - это когда система выполняет полезные действия сама. Не пользователь должен сообразить что именно ему сейчас требуется. Найти, к примеру, соответствующий отчет, установить его параметры и получить наконец информацию. Нет, система сама все это сделает за него в нужное время и в нужном месте. И это отлично работает во многих случаях. Например, когда мы резервируем товар. Мы не лезем в один отчет, чтобы посмотреть сколько есть на складе. Затем в другой отчет, чтобы посмотреть сколько уже зарезервировали. Система сама определяет свободный остаток и возможное количество резерва. Кстати, систему резервирования довольно часто путают с контролем отрицательных остатков. Но это суть разные вещи. Система резервирования действует автономно от начала и до конца. А контроль отрицательных остатков блокирует работу и передает решение проблемы на сторону пользователя. Собственно, этот момент и является ключевым в вопросе применимости автоматизации. Жесткий контроль отрицательных остатков останавливает процесс и ждет решения от пользователя. Но пользователь не может решить проблему! У него просто нет времени на это. Кроме того, у пользователя может не быть (и скорее всего не будет) полномочий на внесение исправлений в далеком прошлом. Мягкий контроль не останавливает процесс, но он тоже вреден. Сообщение об отрицательных остатках по причинам, описанным выше, будет полностью проигнорировано пользователем. Сам по себе сигнал об отрицательных остатках - важный и полезный. Но он подается в неподходящем месте и в неподходящее время. В результате, критически важный сигнал будет потерян. Все уверены в том, что в системе есть работающий контур, но он не работает.
Контроль отрицательных остатков - наивная технология, появившаяся на заре автоматизации. Если в старых продуктах с ее наличием еще можно как-то смириться (в смысле, отключить), то в новых продуктах это контрпродуктивное решение просто недопустимо. И если вы встречаете контроль отрицательных остатков в новом продукте, то это повод задуматься.
Тут возникает резонный вопрос. А что взамен? Ответ в общем случае прост. Ничего особенного. У вас ведь есть отчет об остатках. Там наверняка есть отбор или хотя бы сортировка. Так или иначе вы можете получить список отрицательных остатков. А дальше назначается человек (или группа людей) с соответствующими полномочиями и располагающий достаточным временем. Этот человек на регулярной основе будет заниматься расследованием отрицательных остатков и их исправлением. Нет другого способа разумно организовать этот процесс. Что могут сделать разработчики в этой ситуации? Рационального, а не наивно-вредного? Разработать специально под этот процесс инструмент для работы с отрицательными остатками. В современных продуктах, как правило, множество регистров. У вас может не быть отрицательных остатков по складу, но будут отрицательные остатки по партиям, например. Нужен отчет, который выдаст все отрицательные остатки, какие только есть в системе. Далее, расследование отрицательных остатков заключается в основном в сверке с первичными документами. Мы не знаем в какой транзакции была допущена ошибка. Поэтому перебираем все документы от текущей даты к неопределенному прошлому. Этот путь можно сократить, если мы будем знать дату появления отрицательного остатка. Тогда можно будет идти не от текущей даты, а от даты появления отрицательного остатка. И, наконец, довольно часто отрицательные остатки возникают из-за так называемой "пересортицы". Вместо одного склада указали другой, вместо одной партии - другую. Есть способ при определенных условиях находить кандидатов на пересортицу. Не всегда и не всех, но то, что будет найдено сократит время поиска некорректной транзакции до минимума.
iliabvf
Само по себе существование отрицательных остатков в 1С говорит о многом об этой «системе учета».
yukon39
ЕМНИП, это уже лет 20-ть как настраиваемая опция. И наличие отрицательных остатков говорит не об 1С, а об уровне учета в компании. Но тут есть моменты:
1. В маленьких компаниях выключение этой опции потому что мешает продавать это 99,99% признак бардака в системе
2. В больших компаниях проверка на отрицательные остатки обычно не нужна — т.к. «низовой» бардак уже переросли, и в основном это уже «временные» моменты по передвижке остатков по складам/юрлицам компании. Но как граничный «железный» семафор обычно оставляют, ну тут опять же если проверка не ухудшает производительность.
iliabvf
Отрицательные остатки в 1С не опция, если вы создавали решения с нуля, знали бы.
Melex
я создавал. И у нас это тоже опция. В чем проблема?
yukon39
Если вы про техническую реализацию, то да платформенно в регистрах остатков знак остатка не ограничивается, но платформа это еще не система учета, а регистр накопления еще не регистр с остатками товара.
А вот уже создавая РН ОстаткиТоваров разработчик решает, допускаются ли в этом регистре отрицательные остатки.
В типовых решениях от 1С еще в ТиСк ред.8 контроль отрицательных остатков был опцией.
iliabvf
Учитывая то, что 1С так старалась сделать за нас регистры накопления, можно было бы изящно реализовать это средствами платформы, не говоря об изменениях задним числом, это одни из главных причин того, что на западе 1С никогда не займет хоть какую-нибудь значимую долю рынка ERP.
Хотя кому я это говорю, в России же все прокатит, это же 1С.
Melex
Вы вообще понимаете о чем вы пишите? Я надеюсь вы просто кидаете на вентилятор.
Ну я делаю проекты на западе, есть прокты сумарно в 12 разных странах. И там везде люди просто офигивают от возможностей 1С.
Это первое, а второе — жесткий запрет изменения задчим числом — бред. Так как это иногда надо, но оно должно быть контролируемо. И тут вам в помощь блокчейн. И задача решается просто и элегантно, и даже круче чем в этих сапах, ораклах и так далее.
iliabvf
Да я прекрасно понимаю о чем пишу.
В 12 странах говорите, это из СНГ? Я вот только вчера обходил всех партнеров 1С зарубежем, половина сайтов не работает, другая половина просто российские или украинские компании.
Melex
Пополам и СНГ и не СНГ.
От того что компания имеет офисы в разных странах — разве плохо?
Вы опять похоже не понимаете о чем говорите. Не там ищите, раз не находите.
iliabvf
Ну значит мы работали с разными 1С на разных международных клиентов, бывает. Удачи вам.
DMGarikk
изменения задним числом — на западе это чисто административное требование МСФО, есть конфигурации в 1С где задним числом нельзя ничего исправлять без следов
вы несколько путаете причины, следствия и сами решения
вот из опыта — однажды менеджеры по ошибке грузанули в учетную систему пару миллионов проводок с ошибками (просто выбрав неверный файл)… откат его штатными средствами вызвал бы пару миллионов сторнирующих проводок и пару талмудов объяснительных записок для аудиторов на каждую из них.
Думаете это нормальное решение для бизнеса делать совершенно невозможными операции редактирования задним числом? даже по коррекции технических ошибок?
вы так удивляетесь такому кривому 1С, хотя блин взять какуюнить систему Visa или MC
я видел на базе их кода такие конструкции по проведению проводок (в их учетных системах)
типа
update account set amount=0 where acc_id=100
update account set amount=10 where acc_id=110
эти операции идут подряд, и выполняют логику переноса суммы в 10 единиц со счета 100 на счет 110, они идут НЕ в транзакции!!! тоесть если операция падает посередине — бабло просто пропадает, до момента свода баланса за неделю/месяц/когда клиент очнется
Это считается НОРМОЙ, и эта логика существует не первый десяток лет. и в том числе по этому банковские операции идут от 5 до 30 дней. чтобы потом по общим цифрам менеджеры вручную сводили баланс если видят расхождения. (замечали иногда что некоторые суммы в выписке банка подвисают на мноого дней… и висят в холде? (в некоторых клиентбанках там часики около цифры нарисованы) это в том числе по таким вот причинам происходит)
Логика 'у них там на западе всё круто, а у нас сплошная ерунда просто по определению' — она неверная, и там есть странные и кривые решения, и у наших решений есть понятные объяснения 'почему так'
yukon39
«В лоб» отрицательные остатки закрываются парой вполне изящных запросов. Ну и платформенный механизм был бы совсем не юзер-френдли, т.к. по идее он должен тупо выбрасывать исключение.
Редактирование «задним числом» тоже легко можно запретить, буквально парой строчек кода. Но в текущей парадигме типовых конфигураций да, никак. Хотя элементы этого подхода в торговой подсистеме есть (корректировки заказов например).
Навскидку, я не видел учетных конфигураций в которых редактирование «задним числом» было бы закрыто для всех и всегда. Значит не сильно оно востребовано бизнесом. Те же корректировки заказов используют только для контроля работы младшего, линейного персонала.
exwill Автор
Вы не согласны с тем, что отрицательное число — это тоже число, не лучше и не хуже положительного?