Comments 55
…в момент внесения записей в регистр делается проверка на возникновение отрицательного остатка и далее либо операция запрещается, либо количество корректируется соответствующим образом. Этот путь практически безнадежен, потому что контролировать надо не только добавление и изменение записей регистра, но и удаление, т.е. отмену проведения. …
Всегда знал, что 1С абсолютно ущербная, отсталая и гнилая система, непонятно как дожившая до наших дней. Но чтоб настолько?
Пока другие придумывают какие-то условия, валидации, пре- и пост-проверки для всех операций, программисты 1С решают проблему игнорировать. max() с нулем вообще стоит делать в какой-нибудь мобильной игре, чтоб не дать объекту выйти за пределы экрана, или еще что-то мелочное - но не для того, чтоб костыльно закрывать бизнес-проблему
Всегда знал, что 1С абсолютно ущербная, отсталая и гнилая система, непонятно как дожившая до наших дней. Но чтоб настолько?
Нет, в 1с как раз стандартом является "Пока другие придумывают какие-то условия, валидации, пре- и пост-проверки для всех операций". А эта статья — об особом видении конкретного автора.
Какие-то странные решения выдуманных проблем.
Идеальное решение отрицательных остатков предлагала преснопамятная 1С 7.7 - там просто все транзакции работали в SERIALIZABLE и параллельно два раза что-то зарезервировать было невозможно. К счастью, 1С 8.х действительно стала многопользовательской, а это значит, что теоретически возможны и списания "в минус". А дальше уже в зависимости от ситуации программист должен что-то с этим делать - либо проверять остатки до и после транзакции, либо добавлять регламентную постобработку, либо просто ничего не делать (посмотрите, как работает ритейл или WMS - если товар лежит перед кассиром/кладовщиком, значит он должен его отдать, даже если программа считает, что на остатке его нет). max(остаток, 0) - частное и вредное решение, плодящее плохие паттерны проектирования
Встроенный метод распределения... а по каким критериям он будет распределять? Надо ли учитывать гипотетическое измерение "серия номенклатуры"? А если учёт по сериям не ведётся? А если списывать нужно по FIFO в привязке к партиеобразующему документу, ссылка на который лежит внутри "серии"? Эти все условия тоже нужно передавать в некий магический метод распределения? И потом гадать, как этот черный ящик, встроенный в платформу, получил нужные цифры? Нет, увольте, пусть лучше это будет написано кодом, доступным для отладки
там просто все транзакции работали в SERIALIZABLE
насколько я помню, было не важно, в каком уровне изоляции работали транзакции для проведения документов. Потому что при начале проведения устанавливалась табличная блокировка на "общий журнал документов", а это в любом случае выстраивало все проведения в одну очередь друг за другом. Уровни изоляции были важны для получения отчетов: нужно ли читать данные "до", "после" и допустимы ли чтения "грязных" данных.
И нет, никакого особенного решения отрицательных остатков это не давало. Все также можно было зайти в документ прошлого года, его исправить, а все документы после него оставались в неведении, что произошло. И врятли вообще существует хорошее решение, потому что оно упирается в вычислительные ресурсы "пересчитаем операции миллионов документов после исправляемого".
но есть решение "не давать делать такие исправления". Что и реализовано сейчас в современных конфигурациях.
Хорошее и дешевое решение есть — во всех регистрах накопления есть строчка с финальным итогом на 3999 год (если они не отключены) и она обновляется при каждой записи движения. Так что если кто упал в минус это сразу видно платформе (с точностью до разделяемых итогов)
Это спасёт от отрицательного остатка "в конце баланса", но не поможет от минусов "в моменте": если будет 3 транзакции
+100
+400
+500
,а потом задним числом вторая транзакция поменяется на -400
мы получим отрицательный остаток после 2 действия, но положительный - на финальном итоге
Это лечится запретом изменения документов - все исправления делаются новым корректирующим документом (такое есть в ЗУП). Всё это реализуемо языком платформы - и тут совершенно не нужен предлагаемый автором "неотрицательный остаток"
Да, от промежуточных минусов не спасет. Но неотрицательный остаток на платформенном уровне был бы быстрее на один запрос. Так как платформа сначала вычисляет остаток, потом записывает его в конец баланса, и только потом вы можете вызвав еще один запрос проверить, отрицательный ли он получился. То есть лишний межсерверный вызов и повторный расчет уже рассчитанного только что результата.
Насколько часто такое нужно, чтобы встраивать прям в платформу — большой вопрос.
да, тут "идеальное" надо было взять в кавычки - по сути, даже с такими ограничениями положительный остаток не гарантировался. А с развитием платформы параллельность работы выросла, проявились классические артефакты многопользовательской работы - и появились классические же способы борьбы с ними (блокировки, проверки остатков в конце транзакции), которыми можно пользоваться, а можно и не пользоваться, если в конкретной ситуации не надо
Не раскрыт вопрос: кому это "нам" не хватает настолько экзотических возможностей?
Если имеются в виду разработчики и архитекторы 1С — то нам совершенно точно не хватает только произвольного индексирования регистров накопления (но это касается всех прикладных объектов). В платформе много проблем, но регистры накопления — одна из самых беспроблемных вещей, что там есть.
Если по вопросу неотрицательных остатков у меня просто возникло недоумение (что??), то по поводу распределения глаза начали вылезать на лоб (вы вообще понимаете, что такое ORM и реляционные СУБД?), а по поводу точки актуальности в Заключении вы нагородили такой сонм логических и терминологических ошибок ("Функциональное" проведение???), что, честное слово, можно ответить только словами Филиппа Филипповича про советы космического масштаба и космической же глупости...
Извините, но по этой статье можно сделать вывод, что вы абсолютно не разбираетесь в том, о чем пишете. Ни в 1С, ни в резервировании, ни в том, как вести учет.
Я искренне надеюсь, что курсы otus ведут гораздо более компетентные специалисты.
В более ранних версиях в служебных таблицах по умолчанию хранились еще и остатки на каждый месяц. Это было откровенно непродуманное решение и сейчас от него отказались. Остатки по месяцам все еще можно включить по желанию, но лучше этого не делать.
Это не так. Это абсолютно продуманное и очень полезное решение. Промежуточные остатки помогают ускорить расчеты, чтобы не расчитывать остатки с начала времен.
Прекращают бесплодную борьбу с отрицательными остатками. Вместо этого, получив остаток из регистра резерва, применяют нехитрую операцию:
резерв = максимум(0,резерв)
В целом это более правильное решение.
Это самое неправильное решение, какое только можно представить. Если закрыть глаза или убрать мусор под ковер, то от этого он не исчезнет.
Поэтому, к уже имеющимся в нашем распоряжении операциям сделать приход и сделать расход, я бы добавил операцию распределить.
Не существует универсального распределения. Даже такой вариант, как "по среднему" может быть средневзвешенным, а может быть скользящим. Существует 1000 разных нюансов, которые нужно учитывать. Для решения таких задач в любых языкпах программирования пишут специальные библиотеки. 1С в этом не исключение.
Т.е. то, что пишет в регистр документ, зависит только от самого документа. Но не от того, какие записи попали в регистр ранее (и не от того, какие попали позднее!) Этот принцип было бы правильным назвать функциональным.
То, что пишет в регистр документ, как раз таки часто зависит от окружения и от того, какие записи попали в регистр ранее. Так работают учетные системы, чтобы вы себе там не придумали. Учетная система -- не математическая функция. У нее есть состояние, которое нужно учитывать.
Насчет резерв = максимум(0,резерв).
Обратите внимание, что речь идет о резервах. Что конкретно плохого в таком подходе? Можете объяснить?
Минус это бага в учете. Резерв же кто-то списал? скорее всего это был пересорт. И сейчас на соседней позиции висит положительный резерв, который никогда не закроется.
Плохо то, что таким подходом пытаются скрыть проблемы в учете, процессах или в алгоритмах работы вместо их решения.
Из-за этого ошибки накапливаются -> попадают в отчеты и дашборды -> на основании этих данных принимаются неверные бизнес-решения -> бизнес теряет деньги.
Если резерв ушел в минус, то, на вскидку, может быть несколько ситуаций:
Ошибка в алгоритме резервирования. Система неправильно расчитывает резервы в целом или в каких-то конкретных ситуациях.
Пользователь отметил, что нужно резервирование товаров, товары пришли, а пользователь "задним числом" отменил резерв, поменял товар в заказе или вообще удалил заказ. В таком случае, как отметили выше, где-то висит положительный резерв, который никогда не закроется.
Извините, но по этой статье можно сделать вывод, что вы абсолютно не разбираетесь в том, о чем пишете. Ни в 1С, ни в резервировании, ни в том, как вести учет.
Я искренне надеюсь, что курсы otus ведут гораздо более компетентные специалисты.
Полностью поддерживаю. Пробежался по другим статьям автора. Их уровень производит удручающее впечатление.
Непонятно даже, как объяснить автору в комментариях, где ошибка. С чего начать — с самых азов 1С, с оперативного учета или основ SQL? Поскольку даже в таких вопросах обнаруживается отсутствие системных знаний.
Под видом документов мы регистрируем в системе некие события. Каждое событие располагается где-то на временной оси. Но сам процесс ввода (и тем более последующей корректировки) документов тоже разворачивается во времени!
В настоящий момент, как мне кажется, этот принцип не соблюдается ни в одной конфигурации 1С:Предприятие.
Не понял, какие у вас претензии к 1С. Есть документ и есть документ корректировки, никто не заставляет править документы в защищённом периоде.
Предложения по нововведениям в последней платформе, можно оставлять в этом канале:https://t.me/platform_suggestions
"Этот путь практически безнадежен, потому что контролировать надо не только добавление и изменение записей регистра, но и удаление, т.е. отмену проведения"
Этот "безнадежный" путь уже давно стандарт.
Как-то слишком слишком серьёзно приняли эту статью. Мне вот по содержанию видно, что автор просто совсем не разбирается в том, о чём пишет: ни разу не писал механизм распределения (по FIFO или по среднему), ни разу не разбирал как он работает в разных конфигурациях 1С. В его представлении там нет вообще никаких особенностей и нюансов, а разработчики просто копипастят его не думая между всеми конфигурациями, чтобы он там работал. Для него это просто 1 функция, которую если реализовать в платформе, то у пользователей перестанут возникать "минусы".
Если регистр должен контролировать остатки - отдайте эту обязанность самому регистру. Не надо это делать ни в обработке проведения, ни в обработке отмены проведения. Стандартный подход: читаем какие наборы измерений были перед записью, читаем после записи. Проверяем остатки по объединенному множеству наборов измерений до и после. А ещё лучше - внедряем в набор записей регистра зависимость от некого МенеджерКонтроля, который разрешает/запрещает запись по своим правилам: от контекста, от прав пользователя и т.д.. Передавая разные МенеджерКонтроля можно получить разную стратегию, что на мой взгляд более гибко.
Но тут важно понимать, что действительно надо контролировать, а что нет. Например, резервирование товара не более свободного безусловно нужно, иначе это необеспеченный резерв. А вот контроль неотрицательных остатков на кассе в розничном магазине нет - товар есть, клиент хочет его купить, а что там у вас в учёте с алгоритмами и/или пересортицей придётся разбираться после продажи.
По поводу распределения по "виртуальным" измерениям (пишу "виртуальный" потому что никаких партий ФИФО или номеров ГТД на самом товаре нет, он неотличим между этими партиями) - надо исходить из того - необходимо это для оперативного учёта или нет. Если необходимо, то фиксируем в самом документе перед его проведением. Например, номера ГТД требуется указывать в реализации по закону и будет неправильно, что данные изменяться после перепроведения не изменившего состав документа. С другой стороны нет никакой необходимости получать себестоимость оперативно (да и не всегда возможно) - соответственно и расчёт партий можно отложить, либо провести его не полностью (только по количеству без сумм). Сам же окончательный расчёт проводить регламентно в фоновом режиме, например.
Как-то слишком коротко. И еще, не очень понятна фраза "от механизма остатков отказались, как от откровенно плохого". Как понять "отказались", ведь таблица итогов РегистраНакопления существует?
Там постоянно что-то изобретают. Например в УТ 11.5 сделали оборотный регистр РаспределениеЗапасовДвижения, в модуле которого пере заполняется регистр сведений РаспределениеЗапасов. Этакие таблицы итогов "вручную".
Отказались от механизма хранения остатков на каждый месяц. Теперь по умолчанию хранятся только последние остатки
Добрый день, очень понимаю поднятую проблему и она близка, поэтому приходилось писать "суперконтроли" в модуле регистра, получая аналитики до записи, аналитики текущего набора и в после записи запрос с выбором аналитик по каким можно минус сделать, а по каким нет. Ещё есть существенный нюанс - минус в регистре можно позволять по регистру в целом по аналитикам или нельзя разрешать минус в течении и после каждого регистратора.
В связи с такими нюансами и потребностями можно применить стандартизированные методы бсп по контролю остатка или отдать платформе по параметрам при записи. Вообще в бсп было бы полезным ещё сделали бы 3 уровня пользователя - 1.можно делать все что угодно.(админы и программисты) 2. Минус возникает и контролируется так как сейчас -только расход 3. И минус нельзя не прикаких условиях с возможностью задавать настройку как на регистр так и по пользователям и группам пользователей. (И многие контроли перевести в новый способ) этот шаг убрал бы много костамизации функций контроль, не все конечно но процентов 90
Такие предложения писал в компанию 1с, но это слишком сложное изменение)
Не написана причина появления минусов (откуда минус по резервам?), а следовательно и дальнейшие рассуждения не имеют ценности. Теория оторванная от реальности.
А минусы появляются например так:
Менеджер по закупкам приходует 10 шт. товара. Менеджер по продажам через месяц продает 10 шт товара. В конце квартала/года, при сверке первичных документов оказывается, что поступило не 10 шт, а 8 шт, менеджер ошибся занося в 1с документ. Бухгалтер требует срочно привести с/ф в соответствие. Поступление исправляется на 8 шт. и получаем -2 шт. на остатке.
Как продали 10 шт. если было всего 8 шт.? Просто был пересорт на складе, физически товар был в наличии вот и продали.
Как вы предлагаете программнно бороться с данными минусами?
Для этого разделяют складской учет от финансового. И делают сверку одного с другим, в случае разногласий - оформляют соответствующие документы, указывая каким способом будут отражены излишки/недостачи/пересортицы.
Поэтому кладовщик на складе должен вводить приходный ордер не по данным УПД от поставщика, а по факту поступления на склад.
Я с вами согласен - что этот вопрос выходит за рамки ИТ и является организационно-административным.
У вас есть документ реализация. В нем есть строка
апельсин 2 шт.
и есть регистр резервов. Ваши действия? Как вы отразите эту строку в регистр?
Не понятно как это относится к моему вопросу, на который вы написали ответ.
На ваш вопрос ответ:
Движение по регистру резервов зависит от того, был ли в заказе покупателя установлен резерв или нет. Если не было резервирования в заказе, то никак не нужно отражать.
Если заказ делал резерв 2 шт (приход по регистру), то реализация делает расход по резерву 2 шт
А если был резерв 1 шт?
Если в заказе был резерв 1 шт, а в реализации продано 2 шт, то реализация делает по регистру резвов -1 шт, еще 1 шт, просто со склада, а не с резерва
В заказе было 100 строк. И среди них
апельсин 1 шт.
Заказчик просит изменить его заказ. В новой версии пересмотрены 50 строк из 100. А апельсина вообще нет. Заказчик ведь его уже получил. Ваши действия?
Просто меняются данные в заказе. Тут же подразумевается что реализации апельсина еще не было, ведь клиент его не заказывал? А если заказывал, то почему мы должны убирать их из заказа?
Я не понимаю к чему ваши все вопросы. В статье указано, что проблемы минусов по регистрам нужно решать на уровне платформы. Я привел конкретный пример и спросил как вы предлагаете это решать технически в платформе. Вместо ответа вы задаете мне общие вопросы по учету не имеющие отношения к технической части.
Ну нет уже апельсина в новой версии заказа от клиента. Мы ее приняли. Изменили старый заказ и проводим его. Ваши действия?
Если вы про реализацию, которая списывала резерве, то нужно ее перепровести, что бы резерв не списывался, т.к. резерва нет.
Можете проверить это все на любой конфигурации УТ 10, УТ 11, УПП 1.3, ЕРП 2.х . Только ЕРП и УТ 11 вам не даст просто так изменить документ в минус, т.к. идет контроль остатков на текущую дату и нужно менять все документы начиная с последнего в цепочке.
Не вижу смысла в дальнейшей переписке, такое ощущение, что вы хотите что бы я научил вас вести учет.
Это я к тому, чтобы вы представили хотя бы приблизительно всю сложность алгоритмов проведения и механизмов перепроведения связанных документов. И уже на этом фоне смотрели на то, что я предлагаю
Вы предлагаете, что бы платформа применяла функцию Максимум(0, Остаток) при чтении остатка из регистра накопления.
Но то, что при чтении (например при выводе отчета) вы уберете минус, от этого он не исчезнет из регистра. Там же просто математика: приход - расход.
Если же вы хотите применять функцию Максимум при записи в регистр, то это еще более бессмысленно. В вашем же примере, когда из заказа убрали апельсины, которые продали и получился минус по резерву. При проведении измененного заказа минус в регистр же не записывается, просто убирается запись прихода на момент заказа. А реализация как делала расход так и делает, пока мы ее не перепроведем.
Можете на примере своих апельсинов привести пример как платформа должна не дать сделать минус?
Я предлагаю опцию для регистра накопления с условным названием "неотрицательный". Установка этой опции означает, что при обращении к виртуальной таблице остатков происходит следующее:
Вычисляются остатки с учетом установленных фильтров. Вычисляются так же, как это делается сейчас. Тут никаких изменений нет.
К каждому остатку применяется максимум(остаток,0)
Выполняется агрегирование, если оно требуется по условиям запроса.
Это можно сделать и сейчас, средствами встроенного языка, но платформенная реализация, конечно, была бы быстрее.
на какой момент "вычисляются остатки"? на [для апельсинового примера] момент первичного заказа, на момент отгрузки, на момент исправительного заказа, на точку актуальности, на момент восхода рождественской звезды, на каждый момент времени в периоде с заказа до сейчас, на каждый период времени с первого приобретения апельсина в системе?
Это как у нас нет отгруженного по заказу в новой версии заказа?
Заказ уже создан, изменен и даже частично отгружен. зачем его изменять? либо "закрывать", снимая оставшиеся резервы, либо делать корректирующий (изменяющий остаток резерва)
вы задаете вопросы по базовому оперативному учету, как это относится к 1с?
Не зря Михаила Каллимулина выперли из Бауманки. Интересно, когда Отус повторит этот процесс.
А поместите, пожалуйста, эту статью ещё на Инфостарт.
Кажется, что там будут комментарии более приближенные к жизни. Ссылкой на ваш вебинар, наверно, там тоже заинтересуются.
Чего нам не хватает в регистрах 1С