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