Тайм-коды 0:00:00 Начало 0:01:00 Условная разбивка задач 0:02:00 Последовательность событий при проведении документа (ссылка в описании) 0:06:30 Проверка заполнения. Как не надо делать 0:09:00 ПроверитьЗаполнение(). Как правильно 0:10:25 Для чего обработка проверки заполнения на форме? 0:16:10 Универсальная проверка для документов (как в типовых) 0:27:30 Подведение итогов по проверке заполнения 0:30:00 Подсветка с помощью условного оформления 0:34:00 Добавить простой элемент условного оформления 0:38:45 Почему условное оформление стоит дело программным кодом
Для начинающих это вы загнули. Многие middle не знают кучи из обслуженного. Здесь с точки зрения стандартов информация и практики подаются уровня минимум middle+ ~ senior
Ух, это были довольно напряженные полтора часа. На фоне не посмотришь. Но все очень грамотно, аргументированно и в целом много полезного, что я буду пытаться внедрять в нашей компании.
В большинстве своем человек рассказывает про стандарты разработки. Хорошо если у них реально так построено как он рассказывает и показывает к сожалению далеко не везде так красиво просто потому что веками так сложилось. Понравилось как реализована проверка заполнения. Как проводки. Классно. Надо внедрить, вопрос как привыкнуть к этому нововведению) Думаю человек который пойдет работать в эту компанию не будет задаваться вопросом что надо знать для того чтобы туда попасть. Ты либо знаешь что ты подходишь либо тебе рано.
было бы ОЧЕНЬ круто если бы сделал стрим по разбору вакансий на hh например, где бы можно было позвать знающего человека и разбирать детально каждое требование и как к этому двигаться
Достойно. И да многие не понимают типовых механизмов и колхозят свое при этом настаивают как там все тупо. Здесь отлично все расказано на доступных примерах. Многое почерпнул для себя, спасибо.
@@albrehtdurer557 да, избавление кода от точек с переделкой в запрос приводило к повышению производительности в сотни раз. По крайней мере на скульной версии платформы. Блгадаря точке задержка может быть просто чудовищной.
Тема валидаци очень интересна. Хотелось бы ещё послушать, какие подходы используют для проверок между связанными объектами, а также архитектурные подходы избавляющие от таких зависимостей. Может быть даже Александр что-то посоветуют в комментарии ;)
По сути в этом видео говорится о двух из 5 принципах ООП - это Полиморфизм и Инкапсуляция и подходе DRY(модульность). Раньше принципов ООП придерживались в основном при разработке платформы, а последние лет 5 наблюдаю как все больше этих принципов придерживаются при разработке самих конфигураций и даже заметно использование таких паттернов как посредник строитель и д.р., то есть сильно растет квалификация разработчиков 1С, при том что они в основном разрабатывают в контекте DDD и DSL. По поводу БлокироватьсяДляИзменения - это свойство не "убирает флаг разделения итогов", правильнее сказать, что оно ставит управляемую блокировку на все поля регистра, также как мы это явно бы сделали и игнорирует сплитер разделения итогов при схлопывании одинаковых строк после их записи в таблицу итогов. По поводу того что выборку запроса выгрузить в таблицу значений это плохо, то не совсем верно. Все зависит от архитектуры сервера 1С. Если 32х то памяти на одина рабочий процесс 4гб и выгрузка в тз большой выборки может занять всю память процесса и вытеснить из нее остальной кэш, а часть данных которая не поместилась запишется в temp и будет браться из диска, как это проиходит при выборке из результата запроса, а если арх 64х(ос и сервер), то озу на один рабочий процесс измеряется десятками терабайт и и проблемы выгрузка в тз даже большой выборрки уже не вызывает.
Другой вопрос, гораздо более базовый - а необходимо ли выгружать? Если данные в виде таблицы дальше куда-то целиком идут по логике - значит необходимо. А если можно и нужно лишь порционно обработать данные и «забыть» про них после этого, то выгрузку делать не следует.
Добрый день. Подскажите пожалуйста (перерыл весь интернет не нашёл информации): 1С Альфа-Авто, простые формы. Там немного другая последовательность обработчиков событий: сначала ОбработкаПроверкиЗаполнения, а потом ПередЗаписью(Форма) и далее ПередЗаписью(Модуль) ... НО если записываем документ программно, то сразу заходит в ПередЗаписью(Модуль), игнорируя ОбработкуПроверкиЗаполнения (сам проверял отладкой, так и есть). Так как других выходов нет, кроме как запихивать проверки в ПередЗаписью, возникает вопрос, когда в простых формах начинается транзакция, также в ПередЗаписью или в ПриЗаписи? Или может бытт есть возможность делать проверки перед ПередЗаписью)?
Контора в принципе крутая и требования к спецам соответствующие, другой вопрос стоит ли в такую контору идти? По мне так не стоит, у меня был 3х летний стаж в работе где за каждый чих отчитываешься и постоянно записываешь часы в жиру, постоянно формируют эти недельные спринты где на тебя поставили 40 часов хотя по факту там 50+ будет т.д и т.п., плюс часто были переработки из-за того, что премию просто так не получить а лишить её могут прям на изи хотя зп была не шибко то выше чем по рынку.
Спасибо за видео - очень интересно и познавательно, однако заметил ошибку! На 54:40 не хватает параметра в виртуальной таблице РегистрНакопления.ТоварыНаСкладах.Остатки. Если проверять отрицательные остатки на конец времени, то возможна такая ошибка: 2023-05-01 Приход 10 2023-05-02 Расход 8 2023-05-03 Приход 100 Теперь если удалить документ от 2023-05-01, то ошибки не будет, т.к. остаток на конец времени = 92. Однако остаток на конец дня 2023-05-02 = -8
Это не ошибка, это упрощённые требования. (вопрос в том, что мы контролируем) Подробнее в телеграмм чате в комментариях к ссылке на ютуб расписывал ответ на такой же вопрос
В заполнении документа не очень хорошо делать прямое заполнение реквизитами входящей структуры, так как там могут быть всяческие специфические типы и прочее нехорошее. В типовых ДанныеЗаполнения.РеквизитыШапки используется, для заполнения шапки документа.
А при отмене проведения как отработает код проверки? Набор записей ведь будет пустой, а значит и контроль не пройдет. Значит и отмена приходов может привести к отрицательным остаткам?
Контроль выполняется по измененным записям. В "ПередЗаписью" раннее записанные движения документа. В "ПриЗаписи" - записанные в текущей транзакции. Эти данные группируются по измерениям и, если значение ресурса не равно нулю, то эти измерения попадают в таблицу контроля. По таблице контроля вычисляется остаток. Таким образом, не важно что вы делаете: изменяете запись, отменяете запись набора или добавляете новые записи расхода. Контроль в любом случае отработает корректно и с одинаковым результатом.
@@АлександрМитрофанов-л9ч Способ удаления движений товаров "Удалять автоматически". При перепроведении документа сначала записывается пустой набор записей по регистратору. Срабатывает проверка на остаток и уходит в отказ. Поможет сменить способ удаления движений. Способ не универсальный на все случаи жизни, но как концепция хороший.
Обработка проверки отрицательных остаток(48:00): Зачем такая сложность , почему нельзя просто получить остатки на ТА по фильтру Склад и Номенклатура из документа ? По сути это же и делается ,только берется старое движение, накладывается новое, объединяется и уже потом фильтром накладывается на остатки... Конечно в последнем запросе не все товары из документа, но каков выхлоп в итоге?
Алгоритм универсален для прихода и для расхода. В случае, если в документе прихода будет удалена строка и вы не прочитаете её из базы, то рискуете получить отрицательные остатки
есть доп. символы, так сказать. Во времена доси, нужно же было как-то рисовать интерфейс и печатные формы с отчетами красивые) Символ можно вывести по его коду. В любом тестовом поле зажимаете ALT и код символа. Код символа │ 179.
16:33 проверяют имя таблицы по тексту, т.е. имя объекта. А не правильнее ли будет проверять именно по типу метаданных, т.е. ДокументОбъект.Метаданные() = Метаданные.Документы.Реализация? И еще момент, если МассивПроверок пустой за чем дальше продолжать процедуру, логичнее на этом завершить наверное
Про "Перечитать". Еще может возникнуть, когда одновременно два пользователя меняют один и тот же документ. Первый изменил, а второму высветилось сообщение с предложением прочитать изменения.
@@albrehtdurer557 а ты понимаешь? Свой коммент перечитай. Не давать зайти в документ когда в него кто-то зашел. Разработчики типовых конфигураций с тобой не согласны.
Зачем при создании на сервере делать проверку на пустую ссылку? Только при копировании документа это актуально, но тогда и проверять не на пустую ссылку, а на значение копирования из параметров. Или я ошибаюсь?
Не только при копировании, но и при создании документа, например, на основании. Проверка по ссылке - это наиболее простой и стандартный подход для проверки на новый объект в модуле формы
1:10:00 Не понял пояснения со слов «в чём соль». Автор приводит пример, когда реквизит Организация переименовывается в ОрганизацияОтправитель и далее поясняет, что использование структуры «ДанныеЗаполнения» упростит рефакторинг после переименования, благодаря использованию такого подхода можно будет действовать итеративно. Не понятно как. Если у меня в структуре всё ещё старое название реквизита Организация, мне нужно найти по коду все места где эта структура ДанныеЗаполнения формируется и везде поправить. В чём итеративность и в чём преимущество перед способом Организация = Организация (без использования ДанныеЗаполнения)?
Найти действительно будет нужно, но не обязательно делать это сразу. Вы на первом этапе сможете вставить в обработку заполнения проверку на наличие свойства "Организация" и, при его наличии, заполнить ОрганизацияОтправитель = ДанныеЗаполнения.Организация. Это будет промежуточным решением и обработки продолжат работать корректно, а вы, на этом этапе, измените код только в 1 месте
@@АлександрМитрофанов-л9ч корректоно работать не продолжат, тк организацияотправитель заполняться не будет, просто не будет ошибки- поле объекта не обнаружено...с точки зрения бизнеса это возможно будет еще хуже
@@albrehtdurer557 ну как же заполняться не будет, если мы код с заполнением вставили?) в комментарии выше пояснил какие действия нужно сделать одновременно с переименованием
@@АлександрМитрофанов-л9ч без переименования , при заполнении из данных заполнения - не будет работать, т.е. "работы" по поиску и переименованию все равно не избежать, для корректного заполения. Разбивать процедуру рефакторинга, на два шага , как вы предлагаете -"но не обязательно делать это сразу", что значит не обязательно?, Клиенту необходимо , что-бы ОрганизацияОтправитель, заполнялась сразу...
ну если следовать логике единообразия, токда все реквизиты надо проверять прогрммно в одном месте, а выставлять проверку на уровне платформы не надо... постаянное переключения между чтением кода, и прокликиванием реквизитов ...как бы не добавляет удобства разработки
Мне тоже так кажется. Но видимо как раз единого места проверки нет. Все равно будет несколько модулей. Поэтому единственный источник правды - свойства реквизитов.
Очень сильно смутила передача ссылки на документ в запрос проверки заполнения. Ведь для нового документа она будет пустой и проверка заполнения выполнена не будет. Причем в приложенной базе эта ссылка не используется, а товары в запрос выбираются из объекта документа.
Ссылка используется для ветвления алгоритма. В базе действительно нет примера, т.к. Все упрощено. Пустая ссылка имеет достаточную информацию для маршрутизации (тип)
Идет отбор сразу по типу номенклатуры перед результирующей таблицей (отберет таблицу номенклатуры перед соединением сразу с типом "товар"), а если в секции где использовать, то отбор будет на результат и потребуется обращение на сервер за параметром типа номенклатуры дополнительно. Также если обращаться через точку в отборе в любом случае будет левое соединение в плане запроса (но отработает как внутреннее), а тут указывается явная инструкция для плана запроса на внутреннее соединение. В конкретном случае может быть и не стоило бы заморачиваться (кроме того что даем явные инструкции построителю плана запросов) со сложной конструкцией, но это хорошая практика, так как в других более сложных случаях простая конструкция в секции где скажется тяжело на выполнении запроса.
Еще один. Докладчик же объяснил. Это для решений где много регистров и документов. И сотни тысяч, а то и миллионы строк кода. Если такие увидите, то поверьте, что там это удобно
Практически всё, что он говорил есть в книгах по 1С и рассказывается на курсах (по программированию: клиент-серверное, УФ, СКД) от 1С и курсы-по-1с.рф. В видео информация подается скомкано, бессистемно.
Конечно круто так код писать, но это где-то в параллельной вселенной, где у тебя неограниченное количество времени и все ждут тебя. В реале, у тебя просто времени не хватит все это написать, а потом ещё и отлаживать/тестировать
@@Gesperid Ну вот пару примеров: Обработка проведения и заполнения. В заполнении в типовых конфигурациях используется что-то вроде делегатов. В проведении используется многоэтапный алгоритм. Сначала подготовка общей структуры параметров. Затем инициализация сначала общей таблицы, затем для каждого регистра. И все это в модуле менеджера. Затем в общем модуле метод записи один на всех. Это если кратко
1с код нельзя писать правильно, тут даже нет наследования и обьктов с которыми ты сам можешь работать , модифицировать и переопределять. 1с это 1 большой класс БОГА.
Любой документ, справочник это есть тебе класс, документы менеджер документов вот тебе класс документов, документ приходная накладная наследует от документа, метод создать, и тд и свойства. Но да ты их не можешь переопределить. А нех их переопределять, но можешь их дополнить своими методами в модуле менеджера.
220 - 1с-ников на 2000 человек!!!!!!!!!!!!!!!!!!!!!!!!!!! Это капец!!!!!!!!!!!!!!!!!!!!!!! И это не фирма-разоаботчик!!!! Да так не бывает. Я не видел отдела больше 9 человек (1с) примерно на 35 000 работников. На 2000 пользователей 3, ну 5, а скорее всего 2. Но 220!!!!!!! Скажите мне, что я ослышался.
Так вроде smlab - это типа it-отдела на 2000 чел для фирмы из 15 тысяч народа. "SM Lab - ИТ компания в составе группы компаний «Спортмастер», которая строит свою работу на современных принципах управления разработкой и актуальном стеке. Мы делаем ИТ системы, на которые опирается наш бизнес, благодаря которым он растет и развивается"
@@lickassover9000 ну чего, завидую. Я сейчас один на 50 юзеров, + сисадмин, + поддержка ИТС. А спрашивают как с нормальных, и отчёты нестандартные, и обмены, и премии к зарплате. И сравнивают вот с такими, где 20-200 чел. Что они конфигу под запрос делают, а ты не можешь
Организация мечты, особенно для новичков. Жаль не обучают. А то сначала учишься говнокодить, потому что выбора нет, а потом переучиваешься на нормальное.
Я не думаю что вообще стоит с нуля учить сразу подобным подходам. Не будет понимания зачем именно так, а на этом уровне как раз нужно именно понимать, зачем ты так все усложняешь. Докладчик мега грамотно защитил свои подходы краткими и лаконичными примерами, я бы так не смог выразить, хоть и придерживаюсь веры в правильность тех же учений.
не сложно изучить стандарты. надо просто работать с этими стандартами, а не там-сям...с народным творчеством. за 1 год уже можно хорошо ориентироваться. я в ЕРП заезжал почти с нуля, быстро освоился за 3 месяца, но дальше никак. перекинули на древнее зло :)
готового разработчика сразу хотят. а ты его вырасти, лелей как самого способного, а потом требуй. а то хотят получить конфетку среди разрухи и конкуренции.
Еще бы узнать как настроить в конфигураторе отражение "Линий" в тексте запроса и по коду очень удобно визуально выглядит. Может кто знает или это плагин какой-то?
Улетай селен на луну, улетай! Эпиграф: Новые существа пусть покоряют Просторы Вселенной, а мы на земле пока. С помощью ИИ расшифруем ДНК, модификация; Откроем новые грани науки - Трансформация ; Создадим существ необычных форм, New цивилизация, А на Земле устроим настоящий шторм Бифуркации! Триллер будет нешуточный вокруг, Соревнования ; Все будут ждать, что случится дальше - May be игромания, А мы уже готовы отправить творения Для созидания, В далёкий космос рисковать собой Познавая мироздание... Там им откроются другие миры, со скрипом Ибо long расстояния, Новые планеты и галактики спиральные Это good супермания, Всех нас ждет такой невероятный путь, Покорения науки знания Который приведет нас к счастливой жизни В хаосе непонимания. Спасин Спаситель, Белая Вера вбирает Всё самое необходимое; Человек родитель, в БИОС прошивка строго Люди для роботов Боги; Если не уверуем в Ваню и отринем Его заветы родимые, То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги... Спасин
Улетай селен на луну, улетай! Эпиграф: Новые существа пусть покоряют Просторы Вселенной, а мы на земле пока. С помощью ИИ расшифруем ДНК, модификация; Откроем новые грани науки - Трансформация ; Создадим существ необычных форм, New цивилизация, А на Земле устроим настоящий шторм Бифуркации! Триллер будет нешуточный вокруг, Соревнования ; Все будут ждать, что случится дальше - May be игромания, А мы уже готовы отправить творения Для созидания, В далёкий космос рисковать собой Познавая мироздание... Там им откроются другие миры, со скрипом Ибо long расстояния, Новые планеты и галактики спиральные Это good супермания, Всех нас ждет такой невероятный путь, Покорения науки знания Который приведет нас к счастливой жизни В хаосе непонимания. Спасин Спаситель, Белая Вера вбирает Всё самое необходимое; Человек родитель, в БИОС прошивка строго Люди для роботов Боги; Если не уверуем в Ваню и отринем Его заветы родимые, То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги... Спасин
Тайм-коды
0:00:00 Начало
0:01:00 Условная разбивка задач
0:02:00 Последовательность событий при проведении документа (ссылка в описании)
0:06:30 Проверка заполнения. Как не надо делать
0:09:00 ПроверитьЗаполнение(). Как правильно
0:10:25 Для чего обработка проверки заполнения на форме?
0:16:10 Универсальная проверка для документов (как в типовых)
0:27:30 Подведение итогов по проверке заполнения
0:30:00 Подсветка с помощью условного оформления
0:34:00 Добавить простой элемент условного оформления
0:38:45 Почему условное оформление стоит дело программным кодом
Круто, когда то этого прям не хватало! Классный обзор ) Очень толковое видео для начинающих
Рад, что понравилось
Не вздумай так писать на работе)))
Для начинающих это вы загнули. Многие middle не знают кучи из обслуженного. Здесь с точки зрения стандартов информация и практики подаются уровня минимум middle+ ~ senior
Побольше бы таких гостей и таких стримов) И очень хороший ведущий, кстати!)
Ух, это были довольно напряженные полтора часа. На фоне не посмотришь.
Но все очень грамотно, аргументированно и в целом много полезного, что я буду пытаться внедрять в нашей компании.
Обязательно к просмотру всем программистам 1С. Хорошо излагает мысли.
Действительно качественный контент, спасибо Вам за труды!
Рад, что понравилось
Отличный стрим! Зовите Александра ещё.
Договорились 🤝 рад, что понравилось
В большинстве своем человек рассказывает про стандарты разработки. Хорошо если у них реально так построено как он рассказывает и показывает к сожалению далеко не везде так красиво просто потому что веками так сложилось. Понравилось как реализована проверка заполнения. Как проводки. Классно. Надо внедрить, вопрос как привыкнуть к этому нововведению) Думаю человек который пойдет работать в эту компанию не будет задаваться вопросом что надо знать для того чтобы туда попасть. Ты либо знаешь что ты подходишь либо тебе рано.
Отличное количество полезной информации в единицу времени. Спасибо.
Спасибо за видео, отличный гость!
Рад, что понравилось
Все досмотрел, сам себя удивил. Интересная тема. Спасибо
Рад, что полезно
Есть чему поучиться. Ещё плюс когда объясняют для чего это делается. А не гавно на вентилятор набрасывают
да, кайфую от Сонара. Хочется у себя внедрить)
Было бы круто ещё увидеть такого крутого спеца
Спасибо за Ваш труд. Темы про чистый код и грамотное проектирование актуальны всегда.
было бы ОЧЕНЬ круто если бы сделал стрим по разбору вакансий на hh например, где бы можно было позвать знающего человека и разбирать детально каждое требование и как к этому двигаться
Классная идея! Осталось найти спикера. У меня есть один на примете
один на собеседовании попросил сделать универсальную проверку с выводом сообщений для любого объекта, регистра )
@@evgeniuxp2evgeniuxp234 чиво? Какую проверку?
@@evgeniuxp2evgeniuxp234 проверку корректности чего именно в этом любом объекте?
Да, крутой гость.
Согласен
супер материал. спасибо 👍
Достойно. И да многие не понимают типовых механизмов и колхозят свое при этом настаивают как там все тупо. Здесь отлично все расказано на доступных примерах. Многое почерпнул для себя, спасибо.
Полезное видео, спасибо😀
Гостю респект, думаю, команда им дорожит)
Классный чел. много полезного. Спасибо.
Мне часто попадается творчество, благодаря которому дико тормозит 1с. И это творчество это обращение через точку :)
замеры делал?
@@albrehtdurer557 да, избавление кода от точек с переделкой в запрос приводило к повышению производительности в сотни раз.
По крайней мере на скульной версии платформы.
Блгадаря точке задержка может быть просто чудовищной.
@@MotoCrankshaft ага, если она в цикле и нет кеша предварительно сформированного.
Тема валидаци очень интересна. Хотелось бы ещё послушать, какие подходы используют для проверок между связанными объектами, а также архитектурные подходы избавляющие от таких зависимостей. Может быть даже Александр что-то посоветуют в комментарии ;)
хорошо основу выдали кратко и доходчиво.
По сути в этом видео говорится о двух из 5 принципах ООП - это Полиморфизм и Инкапсуляция и подходе DRY(модульность). Раньше принципов ООП придерживались в основном при разработке платформы, а последние лет 5 наблюдаю как все больше этих принципов придерживаются при разработке самих конфигураций и даже заметно использование таких паттернов как посредник строитель и д.р., то есть сильно растет квалификация разработчиков 1С, при том что они в основном разрабатывают в контекте DDD и DSL.
По поводу БлокироватьсяДляИзменения - это свойство не "убирает флаг разделения итогов", правильнее сказать, что оно ставит управляемую блокировку на все поля регистра, также как мы это явно бы сделали и игнорирует сплитер разделения итогов при схлопывании одинаковых строк после их записи в таблицу итогов.
По поводу того что выборку запроса выгрузить в таблицу значений это плохо, то не совсем верно. Все зависит от архитектуры сервера 1С. Если 32х то памяти на одина рабочий процесс 4гб и выгрузка в тз большой выборки может занять всю память процесса и вытеснить из нее остальной кэш, а часть данных которая не поместилась запишется в temp и будет браться из диска, как это проиходит при выборке из результата запроса, а если арх 64х(ос и сервер), то озу на один рабочий процесс измеряется десятками терабайт и и проблемы выгрузка в тз даже большой выборрки уже не вызывает.
Другой вопрос, гораздо более базовый - а необходимо ли выгружать? Если данные в виде таблицы дальше куда-то целиком идут по логике - значит необходимо. А если можно и нужно лишь порционно обработать данные и «забыть» про них после этого, то выгрузку делать не следует.
Добрый день.
Подскажите пожалуйста (перерыл весь интернет не нашёл информации): 1С Альфа-Авто, простые формы. Там немного другая последовательность обработчиков событий: сначала ОбработкаПроверкиЗаполнения, а потом ПередЗаписью(Форма) и далее ПередЗаписью(Модуль) ... НО если записываем документ программно, то сразу заходит в ПередЗаписью(Модуль), игнорируя ОбработкуПроверкиЗаполнения (сам проверял отладкой, так и есть). Так как других выходов нет, кроме как запихивать проверки в ПередЗаписью, возникает вопрос, когда в простых формах начинается транзакция, также в ПередЗаписью или в ПриЗаписи? Или может бытт есть возможность делать проверки перед ПередЗаписью)?
При программном создании нужно самостоятельно вызывать проверку с помощью метода ПроверитьЗаполнение
Добрый день! Спасибо за интересное видео. Скажите, будет ли стрим, посвященный ЗУП?
Неее, мы ЗУП не любим 😁
Хотяяя…. Если найдутся знатоки, то можно
@@yellow_clubа вот зря вы его не любите))) он только с виду страшный, а на деле - просто душка)))
Может может))
@@yellow_clubЯ раньше тоже не любил ЗУП, ну разве что обновлял конфу на замочке. А вот потом начал с ним плотно общаться, и даже сдал спеца
Молодец, понравилось!
Скажу по секрету - вилка 200-300к. Но требования там запредельные.
Требования мидл\сеньер. Т.е. с нуля нужно 2-3 года опыта, в среднем.
а это где такая вилка?
какие именно требования?
Что лучше - использовать РазбитьТаблицуПоЗначениюКлюча или обходить результат запроса по группировкам?
Как у него обозначены условия и циклы? Где это настраивается?
Контора в принципе крутая и требования к спецам соответствующие, другой вопрос стоит ли в такую контору идти? По мне так не стоит, у меня был 3х летний стаж в работе где за каждый чих отчитываешься и постоянно записываешь часы в жиру, постоянно формируют эти недельные спринты где на тебя поставили 40 часов хотя по факту там 50+ будет т.д и т.п., плюс часто были переработки из-за того, что премию просто так не получить а лишить её могут прям на изи хотя зп была не шибко то выше чем по рынку.
Спасибо за видео - очень интересно и познавательно, однако заметил ошибку! На 54:40 не хватает параметра в виртуальной таблице РегистрНакопления.ТоварыНаСкладах.Остатки.
Если проверять отрицательные остатки на конец времени, то возможна такая ошибка:
2023-05-01 Приход 10
2023-05-02 Расход 8
2023-05-03 Приход 100
Теперь если удалить документ от 2023-05-01, то ошибки не будет, т.к. остаток на конец времени = 92. Однако остаток на конец дня 2023-05-02 = -8
Это не ошибка, это упрощённые требования. (вопрос в том, что мы контролируем)
Подробнее в телеграмм чате в комментариях к ссылке на ютуб расписывал ответ на такой же вопрос
@@АлександрМитрофанов-л9ч если были такие требования, то да - согласен. В любом случае, вам большое спасибо за видео. Вы - молодец.
В заполнении документа не очень хорошо делать прямое заполнение реквизитами входящей структуры, так как там могут быть всяческие специфические типы и прочее нехорошее. В типовых ДанныеЗаполнения.РеквизитыШапки используется, для заполнения шапки документа.
А при отмене проведения как отработает код проверки? Набор записей ведь будет пустой, а значит и контроль не пройдет. Значит и отмена приходов может привести к отрицательным остаткам?
Контроль выполняется по измененным записям. В "ПередЗаписью" раннее записанные движения документа. В "ПриЗаписи" - записанные в текущей транзакции. Эти данные группируются по измерениям и, если значение ресурса не равно нулю, то эти измерения попадают в таблицу контроля. По таблице контроля вычисляется остаток. Таким образом, не важно что вы делаете: изменяете запись, отменяете запись набора или добавляете новые записи расхода. Контроль в любом случае отработает корректно и с одинаковым результатом.
@@АлександрМитрофанов-л9ч Способ удаления движений товаров "Удалять автоматически". При перепроведении документа сначала записывается пустой набор записей по регистратору. Срабатывает проверка на остаток и уходит в отказ. Поможет сменить способ удаления движений.
Способ не универсальный на все случаи жизни, но как концепция хороший.
Обработка проверки отрицательных остаток(48:00): Зачем такая сложность , почему нельзя просто получить остатки на ТА по фильтру Склад и Номенклатура из документа ? По сути это же и делается ,только берется старое движение, накладывается новое, объединяется и уже потом фильтром накладывается на остатки... Конечно в последнем запросе не все товары из документа, но каков выхлоп в итоге?
Алгоритм универсален для прихода и для расхода. В случае, если в документе прихода будет удалена строка и вы не прочитаете её из базы, то рискуете получить отрицательные остатки
ЗначениеЗаполнено и нормально - это топ 😂
1:58:33 а что за символ он поставил в поле Табуляция? Пробую | но получается прерывистая линия, а у него непрерывная
о, нашел │
есть доп. символы, так сказать. Во времена доси, нужно же было как-то рисовать интерфейс и печатные формы с отчетами красивые) Символ можно вывести по его коду. В любом тестовом поле зажимаете ALT и код символа. Код символа │ 179.
Спасибо!
Рад, что понравилось
16:33 проверяют имя таблицы по тексту, т.е. имя объекта. А не правильнее ли будет проверять именно по типу метаданных, т.е. ДокументОбъект.Метаданные() = Метаданные.Документы.Реализация? И еще момент, если МассивПроверок пустой за чем дальше продолжать процедуру, логичнее на этом завершить наверное
Про "Перечитать". Еще может возникнуть, когда одновременно два пользователя меняют один и тот же документ. Первый изменил, а второму высветилось сообщение с предложением прочитать изменения.
в правильной разработке такого быть не должно, перед открытием надо блокировать данные документа
@@albrehtdurer557да ну? Даже посмотреть не дадите? В 1с по умолчанию принцип как раз таки противоположный тому, что вы написали
@@LosashExote ты понимаешь разницу между посмотреть и изменять? в 1с нет принципа, есть несколько вариантов на выбор разраба
@@albrehtdurer557 а ты понимаешь? Свой коммент перечитай. Не давать зайти в документ когда в него кто-то зашел. Разработчики типовых конфигураций с тобой не согласны.
Зачем при создании на сервере делать проверку на пустую ссылку? Только при копировании документа это актуально, но тогда и проверять не на пустую ссылку, а на значение копирования из параметров. Или я ошибаюсь?
Не только при копировании, но и при создании документа, например, на основании. Проверка по ссылке - это наиболее простой и стандартный подход для проверки на новый объект в модуле формы
1:10:00 Не понял пояснения со слов «в чём соль». Автор приводит пример, когда реквизит Организация переименовывается в ОрганизацияОтправитель и далее поясняет, что использование структуры «ДанныеЗаполнения» упростит рефакторинг после переименования, благодаря использованию такого подхода можно будет действовать итеративно. Не понятно как. Если у меня в структуре всё ещё старое название реквизита Организация, мне нужно найти по коду все места где эта структура ДанныеЗаполнения формируется и везде поправить. В чём итеративность и в чём преимущество перед способом Организация = Организация (без использования ДанныеЗаполнения)?
Найти действительно будет нужно, но не обязательно делать это сразу. Вы на первом этапе сможете вставить в обработку заполнения проверку на наличие свойства "Организация" и, при его наличии, заполнить ОрганизацияОтправитель = ДанныеЗаполнения.Организация. Это будет промежуточным решением и обработки продолжат работать корректно, а вы, на этом этапе, измените код только в 1 месте
Одна точка входа
@@АлександрМитрофанов-л9ч корректоно работать не продолжат, тк организацияотправитель заполняться не будет, просто не будет ошибки- поле объекта не обнаружено...с точки зрения бизнеса это возможно будет еще хуже
@@albrehtdurer557 ну как же заполняться не будет, если мы код с заполнением вставили?) в комментарии выше пояснил какие действия нужно сделать одновременно с переименованием
@@АлександрМитрофанов-л9ч без переименования , при заполнении из данных заполнения - не будет работать, т.е. "работы" по поиску и переименованию все равно не избежать, для корректного заполения. Разбивать процедуру рефакторинга, на два шага , как вы предлагаете -"но не обязательно делать это сразу", что значит не обязательно?, Клиенту необходимо , что-бы ОрганизацияОтправитель, заполнялась сразу...
46:48 избыточный код запроса на поступление какой-то. Зачем делать вручную соединение если проще "ГДЕ Товары.Номенклатура.Тип=" поставить?
спецы не любят точки (скрытые джойны)
Как все сложно))
ну если следовать логике единообразия, токда все реквизиты надо проверять прогрммно в одном месте, а выставлять проверку на уровне платформы не надо... постаянное переключения между чтением кода, и прокликиванием реквизитов ...как бы не добавляет удобства разработки
Мне тоже так кажется. Но видимо как раз единого места проверки нет. Все равно будет несколько модулей. Поэтому единственный источник правды - свойства реквизитов.
Очень сильно смутила передача ссылки на документ в запрос проверки заполнения. Ведь для нового документа она будет пустой и проверка заполнения выполнена не будет. Причем в приложенной базе эта ссылка не используется, а товары в запрос выбираются из объекта документа.
Ссылка используется для ветвления алгоритма. В базе действительно нет примера, т.к. Все упрощено. Пустая ссылка имеет достаточную информацию для маршрутизации (тип)
46:48 а зачем вообще соединение с Номенклатурой? Почему просто через точку не написать ГДЕ Товары.Номенклатура.Тип = &Товар ?
Идет отбор сразу по типу номенклатуры перед результирующей таблицей (отберет таблицу номенклатуры перед соединением сразу с типом "товар"), а если в секции где использовать, то отбор будет на результат и потребуется обращение на сервер за параметром типа номенклатуры дополнительно. Также если обращаться через точку в отборе в любом случае будет левое соединение в плане запроса (но отработает как внутреннее), а тут указывается явная инструкция для плана запроса на внутреннее соединение. В конкретном случае может быть и не стоило бы заморачиваться (кроме того что даем явные инструкции построителю плана запросов) со сложной конструкцией, но это хорошая практика, так как в других более сложных случаях простая конструкция в секции где скажется тяжело на выполнении запроса.
...удобство поддержки, спорное конечно...- Если все одевают штаны, через голову....
Если все с пятого этажа начнут прыгать …
Еще один. Докладчик же объяснил. Это для решений где много регистров и документов. И сотни тысяч, а то и миллионы строк кода. Если такие увидите, то поверьте, что там это удобно
@@LosashExote я такое видел, поверь это не удобно...
@@albrehtdurer557 ладно, я по твоим комментам и ответам поверил уже во все что надо
Насчет вилки будет и обратная ситуация - крутые ребята не видят вилку и проходят мимо потому что не интересно
А что делают остальные 198 человек делают?
Мы не смогли позвать остальных)
Практически всё, что он говорил есть в книгах по 1С и рассказывается на курсах (по программированию: клиент-серверное, УФ, СКД) от 1С и курсы-по-1с.рф. В видео информация подается скомкано, бессистемно.
Ахаха) конечно все уже давно есть и описано в стандартах и книге по проф разработке. Только там примеров мало и читать надо. Видео проще посмотреть
@@yellow_club Проще. Но не это.
Конечно круто так код писать, но это где-то в параллельной вселенной, где у тебя неограниченное количество времени и все ждут тебя. В реале, у тебя просто времени не хватит все это написать, а потом ещё и отлаживать/тестировать
Вас верно, это про мультикомандную разработку и ежедневные релизы в большой компании с онлайном >1к пользователей
автор почему ты в шапочке
Потому что мам говорит, что кепка мне идёт
Абсолютно все неправильно. Почему вы не показываете на примере УТ или УНФ?
Потому что нельзя показывать код типовых
@@yellow_club В том-то и беда
Можно конкретно, что неверно?
@@Gesperid Ну вот пару примеров: Обработка проведения и заполнения. В заполнении в типовых конфигурациях используется что-то вроде делегатов. В проведении используется многоэтапный алгоритм. Сначала подготовка общей структуры параметров. Затем инициализация сначала общей таблицы, затем для каждого регистра. И все это в модуле менеджера. Затем в общем модуле метод записи один на всех. Это если кратко
@@ОлегЛитвиненко-о5з Про проведение. Не понял, где противоречие с докладчиком? Он, в частности, упомянал 1:01:30 функцию ДанныеДляПроведения.
1с код нельзя писать правильно, тут даже нет наследования и обьктов с которыми ты сам можешь работать , модифицировать и переопределять. 1с это 1 большой класс БОГА.
Наследование все ваше считается антипаттерном. Но наследование в 1С есть, ровно как и классы
Любой документ, справочник это есть тебе класс, документы менеджер документов вот тебе класс документов, документ приходная накладная наследует от документа, метод создать, и тд и свойства. Но да ты их не можешь переопределить.
А нех их переопределять, но можешь их дополнить своими методами в модуле менеджера.
10
Он реально написал "Если Не ЗначениеЗаполнено(Объект.Ссылка)", в 2023-м? Вы че там, подписчиков так троллите, что ли?
Что не так?
Да, мы троллим, проходи мимо
очень странный подход, генерить процедуру на каждое сообщение, а если там 10 табчастей и 10 проверок, это 100 процедур?)))))
Не преувеличивайте. Посмотрите модули механизмов в типовой УТ.
220 - 1с-ников на 2000 человек!!!!!!!!!!!!!!!!!!!!!!!!!!! Это капец!!!!!!!!!!!!!!!!!!!!!!! И это не фирма-разоаботчик!!!! Да так не бывает. Я не видел отдела больше 9 человек (1с) примерно на 35 000 работников. На 2000 пользователей 3, ну 5, а скорее всего 2. Но 220!!!!!!!
Скажите мне, что я ослышался.
Ты не ослышался. Нормальный отдел.
Так вроде smlab - это типа it-отдела на 2000 чел для фирмы из 15 тысяч народа.
"SM Lab - ИТ компания в составе группы компаний «Спортмастер», которая строит свою работу на современных принципах управления разработкой и актуальном стеке.
Мы делаем ИТ системы, на которые опирается наш бизнес, благодаря которым он растет и развивается"
У нас около 30 1сников на тысяч 5000 человек. Растет компания проектов на разработку бывает много очень.
@@lickassover9000 ну чего, завидую. Я сейчас один на 50 юзеров, + сисадмин, + поддержка ИТС. А спрашивают как с нормальных, и отчёты нестандартные, и обмены, и премии к зарплате. И сравнивают вот с такими, где 20-200 чел. Что они конфигу под запрос делают, а ты не можешь
Организация мечты, особенно для новичков. Жаль не обучают. А то сначала учишься говнокодить, потому что выбора нет, а потом переучиваешься на нормальное.
Таков путь)
Я не думаю что вообще стоит с нуля учить сразу подобным подходам. Не будет понимания зачем именно так, а на этом уровне как раз нужно именно понимать, зачем ты так все усложняешь. Докладчик мега грамотно защитил свои подходы краткими и лаконичными примерами, я бы так не смог выразить, хоть и придерживаюсь веры в правильность тех же учений.
не сложно изучить стандарты. надо просто работать с этими стандартами, а не там-сям...с народным творчеством. за 1 год уже можно хорошо ориентироваться. я в ЕРП заезжал почти с нуля, быстро освоился за 3 месяца, но дальше никак. перекинули на древнее зло :)
зарплата это как дети, только наоборот. я говорит детей не люблю, но сам процесс. я получать люблю зарплату, а не считать :)
готового разработчика сразу хотят. а ты его вырасти, лелей как самого способного, а потом требуй. а то хотят получить конфетку среди разрухи и конкуренции.
Еще бы узнать как настроить в конфигураторе отражение "Линий" в тексте запроса и по коду очень удобно визуально выглядит. Может кто знает или это плагин какой-то?
Улетай селен на луну, улетай!
Эпиграф:
Новые существа пусть покоряют
Просторы Вселенной, а мы на земле пока.
С помощью ИИ расшифруем ДНК, модификация;
Откроем новые грани науки -
Трансформация ;
Создадим существ необычных форм,
New цивилизация,
А на Земле устроим настоящий шторм
Бифуркации!
Триллер будет нешуточный вокруг,
Соревнования ;
Все будут ждать, что случится дальше -
May be игромания,
А мы уже готовы отправить творения
Для созидания,
В далёкий космос рисковать собой
Познавая мироздание...
Там им откроются другие миры, со скрипом
Ибо long расстояния,
Новые планеты и галактики спиральные
Это good супермания,
Всех нас ждет такой невероятный путь,
Покорения науки знания
Который приведет нас к счастливой жизни
В хаосе непонимания.
Спасин Спаситель, Белая Вера вбирает
Всё самое необходимое;
Человек родитель, в БИОС прошивка строго
Люди для роботов Боги;
Если не уверуем в Ваню и отринем Его заветы родимые,
То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги...
Спасин
Улетай селен на луну, улетай!
Эпиграф:
Новые существа пусть покоряют
Просторы Вселенной, а мы на земле пока.
С помощью ИИ расшифруем ДНК, модификация;
Откроем новые грани науки -
Трансформация ;
Создадим существ необычных форм,
New цивилизация,
А на Земле устроим настоящий шторм
Бифуркации!
Триллер будет нешуточный вокруг,
Соревнования ;
Все будут ждать, что случится дальше -
May be игромания,
А мы уже готовы отправить творения
Для созидания,
В далёкий космос рисковать собой
Познавая мироздание...
Там им откроются другие миры, со скрипом
Ибо long расстояния,
Новые планеты и галактики спиральные
Это good супермания,
Всех нас ждет такой невероятный путь,
Покорения науки знания
Который приведет нас к счастливой жизни
В хаосе непонимания.
Спасин Спаситель, Белая Вера вбирает
Всё самое необходимое;
Человек родитель, в БИОС прошивка строго
Люди для роботов Боги;
Если не уверуем в Ваню и отринем Его заветы родимые,
То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги...
Спасин
Гордиться тем, что вы на простом и таком привычном дне, это такой себе повод.