Если в ДелаемЧтоТо(); будет ОтменитьТранзакцию(); без НачатьТранзакцию(); то будет проблема.
Но это значит, что ДелаемЧтоТо() написан не по стандарту, т.к. не соблюдает парность операций.
Потому проверка для всего кода написанного по стандарту не нужна, а если вызываешь чей-то код, которому не доверяешь — то либо надо сделать проверку, либо, поступить правильно и переписать вызываемый ДелаемЧтоТо() по стандарту.
Условие в блоке исключений нужно только если вызывать код написанный не по стандарту.
В общем случае он не нужен.
Потому все просто: если коду вызываемому доверяешь — проверка не нужна.
Хватит изобретать велосипед, есть пример в стандарте "Перехват исключений в коде"
3.6. При использовании транзакций следует придерживаться следующей схемы обработки исключений в коде на сервере:
// 1. Начало транзакции
НачатьТранзакцию();
Попытка
// 2. Вся логика блокировки и обработки данных размещается в блоке Попытка-Исключение
Запрос = Новый Запрос("...");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
...
КонецЦикла;
// 3. В самом конце обработки данных выполняется попытка зафиксировать транзакцию
ЗафиксироватьТранзакцию();
Исключение
// 4. В случае любых проблем с СУБД, транзакция сначала отменяется...
ОтменитьТранзакцию();
// 5. ...затем проблема фиксируется в журнале регистрации...
ЗаписьЖурналаРегистрации(НСтр("ru = 'Выполнение операции'"), УровеньЖурналаРегистрации.Ошибка,,, ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
// 6. ... после чего, проблема передается дальше вызывающему коду.
ВызватьИсключение;
КонецПопытки;
Поскольку исключение не отменяет транзакцию сразу, но запрещает успешное завершение транзакции, то все вызовы НачатьТранзакцию, с одной стороны, и ЗафиксироватьТранзакцию или ОтменитьТранзакцию, с другой стороны, должны быть парными.
Отсутствие обработки исключительных ситуаций приводит к зависшим транзакциям и к сложнодиагностируемым ошибкам вида «В этой транзакции уже происходили ошибки» в произвольных местах кода. При этом в случае вложенных операторов НачатьТранзакцию, следует обеспечить вызов всех парных операторов ОтменитьТранзакцию. Для этого в конце блока Исключение необходимо пробросить исключение выше по стеку с помощью ВызватьИсключение (как в примере выше) и соответствующим образом обработать исключение на каждом уровне стека.
лучше не делать, просто ВызватьИсключение достаточно, так будет проброшено исходное исключение. Синтаксис доступен только в блоке catch
На счет паттерна:
ЗафиксироватьТранзакцию(); обязательно должен быть в блоке Попытка-Исключение
Не должно быть логических операций между НачатьТранзакцию(); и Попытка
ОтменитьТранзакцию(); должна быть первой операцией в блоке Исключение-КонецПопытки
ТранзакцияАктивна() не обязательно использовать для начала новой транзакции, читайте документацию по транзакциям. Открытие новой транзакции в существующей — откроет вложенную транзакцию, закрытие — закроет вложенную, но нужна повторная фиксация чтобы закрыть основную (как раз ваш случай), отмена транзакции отменяет все, включая весь стек сложенных.
Весь код приходит в вид:
НачатьТранзакцию(); // Если транзакция открыта - откроется вложенная
Попытка
ДелаемЧтоТо();
ЗафиксироватьТранзакцию(); // если это вложенная - произойдет переход к основной, иначе произойдет фиксация в базу
Исключение
ОтменитьТранзакцию(); // Отменятся все транзакции, даже если это вложенная
ВызватьИсключение; // Выбросится изначальное исключение
КонецПопытки;
Современные продукты 1С очень гибки в плане настройки прав доступа:
Роли используются как базовые наборы прав, которые задаются разработчиком.
Они атомарны и минимальный набор прав определяется ролями БазовыеПрава<ИмяБиблиотеки>.
Остальные права определяются префиксами Чтение <Что-то> и ДобавлениеИзменение <Что-то>.
На уровне предприятия роли объединяют в профили групп доступа, что показывает какие группы могут быть на предприятии. Профиль — это совокупность ролей.
Профили используются как шаблоны для определения групп доступа, в группах доступа идет уточнение по разделителям, используемыми при огранияениях на уровне записей, т.е. профиль может описать группу Кладовщики, а группа доступа по профилю кладовщики описать группу по складу конкретному, так, чтобы кладовщики одного склада не видели документы по другим складам, или профиль Менеджеры быть использованным для группы по менеджерам конкретной группы партнеров чтобы ограничить работу по организации или группам партнеров.
В типовых конфигурациях заранее поставляют собранные профили и группы доступа, но на реальном внедрении их зачастую переопределяют, потому что каждое предприятие уникально.
Проблемы большего количества администраторов в том, что они относятся к 1С как к чему-то "ну это ваша программа, сами в ней и работайте ", не понимая что администрированим кому-то надо заниматься. Например создание резервных копий, выполнение обновлений на новые релизы, выполнение синхронизаций с другими программами, установка дат запрета редактирования, чтобы определить закрытые периоды, настройки полнотекстового поиска, пересчет итогов и агрегатов для оптимальной работы регистров и очень много чего еще. Это задачи администратора, а не программиста или бухгалтера. Администраторы же не попытавшись разобраться в этом спихивают эту работу на рядовых бухгалтеров, а тем ничего не остается, как просить права на выполнение работы, которая в общем случае вообще за рамками их компетенции.
В первую очередь я бы вам посоветовал прочитать руководство по администрированию для платформы и документацию к БСП, БИП и БЭД, в которую включается большая часть административных механизмов.
А дальше перед вами встанет выбор, спихнуть ли эту работу на бухгалтеров дав им полные права, или же взять административную работу на себя, как администратор, и пользоваться 1С так, как это задумывали разработчики 1С.
Это именно то, о чем я и пишу, те времена, когда IT был статьей затратной — давно прошли.
Сейчас бизнес диктует как должен развиваться IT и делает его под себя.
Если бизнес не может найти денег на это, то и развиваться в современных реалиях он не сможет.
А это значит проблема не в том, что нет денег на программу, проблема в подходе к работе бизнеса.
На основании чего это заключение? Замеры производительности обычно показывают обратное.
если конфа поддерживает тонкие клиенты
Давайте серьезно, уже 8.2 вышла в 2009 году
ERP 2.0 в 2013 (5 лет), против УПП 1.2, выпускаемой с 2006 (12 лет)
УТ 11.0 в 2010 (8 лет), против УТ 10.2, выпускаемой с 2006 (12 лет)
БП 3.0 в 2012 (6 лет), против БП 2.0, выпускаемой с 2010 (8 лет)
ЗУП 3.0 в 2016 (2 года), против ЗУП 2.5, выпускаемой с с 2010 (8 лет)
Все конфигурации на обычных формах морально устарели, в них от 1С предлагается только обновление законодательства и исправление критических ошибок.
Конфигураций, поддерживающих тонкие клиенты, сейчас в разы больше, чем не поддерживающих.
Бизнес, который игнорирует вклады в развитие IT обречен, т.к. рано или поздно не сможет угнаться за конкурентами, которые будут использовать новые методики ведения учета и производства.
И дело тут не только в тонких клиентах, дело в том, что для успешного ведения бизнеса нужны быстрые доработки изменения учета.
Когда мне говорят, что "У нас есть программа, мы ее наладили и работаем" я задаюсь вопросом, "А что, с того момента вы совсем не развились? Вам не нужно обновлять свои бизнес-процессы под измененные условия и объемы?"
Компании, которые до сих пор используют конфигурации на обычных формах, это либо отстающий эшелон, либо какие-то собственные поделки с сумасшедшей не поддерживаемой кодовой базой, в которую поднасрал каждый проходящий мимо студент.
Не смущает. С точки зрения информационной безопасности риски — это деньги, если потенциальный ущерб от угрозы ИБ выше в разы, чем стоимость сервера — то дешевле купить сервер.
Если база не содержит ДСП, то, очевидно, использовать файловую выгоднее.
Все это езжено изъезжено, описано в официальной документации, сняты сотни видеогайдов на ютубе, и тысячи частных доработок на инфостате.
Парсить из почты я не видел, но просто парсить — да, это часть механизма. Загружать можно при поступлении товаров и просто так отдельно, вести можно цены поставщиков и цены конкурентов.
В 1С: УТ (КА или ERP) можно сразу вести номенклатуру поставщика, которая сохраняется в соответствии с собственной номенклатурой. Причем сохраняется и вся динамика цен разных позиций разных поставщиков которую можно использовать в маркетинге и ценообразовании, например для составления правил формирования цен по ценовым групам (средняя по прайсам поставщиков, самая низкая из всех поставщиков плюс 3 % и т.п.) и потом использовать это все подборе при заполнении заявок клиентам.
ВПР — это круто, но только если надо разово что-то свести, а для решения вашей задачи уже есть отработанные и хорошо документированные механизмы.
Как частное решение — это круто.
PS. Заявку на 100 позиций делать за 30 минут — это пипец долго.
Понимаете, есть очень много "Семерочников", которые не понимают принципов разделения кода, не знают паттернов, не желают учить стандарты, ноют об отсутствии ООП, не понимая, что уже есть абстрактные классы, не замечают различий между программным интерфейсом и служебным кодом.
Сейчас только БСП уже порядка 5 миллионов строк кода, на 60 базовых подсистем. Чтобы заключать о качестве такого объема кода нужны определенные показатели. Один из них — это работа более чем в 1 500 000 инсиалляций проектов. Жизненный цикл критической ошибки не более недели.
Запутанным и некачественным код видится в первую очередь людям, не знакомым с принятым стайлгайдом.
Ну если серьезно: сделать юнит тестирование документа в 1С все таки нельзя)
Либо это фактически будет не юнит тест, а интеграционный тест. Без рефлекшина дергать отдельные элементы мы не можем. Так же как и создавать моки с определенными свойствами.
Но можно придерживаться определенных правил: делать код разделенным, не делать в событиях непосредственную логику, т.е. изначально писать такими блоками, для которых можно написать юнит тесты, а после серии юнит тестов каждого блока одним интеграционным проверить взаимодействие блоков между собой.
Окружающие, особенно совладельцы франчей, указывают на то, что выгодно им, а им выгодно, чтобы именно ты получил сертификат 1С, который подтверждает не столько твои знания, сколько наличие специалиста определенной темы у франча, что дает возможность франчу иметь ряд отдельных плюшек.
Неужели примитивы описанные Бруксом и Виртом зависят от языка?
Неужели 1С, как язык, не полон по Тьюрингу?
Неужели паттерны банды четырех не применимы к 1С?
Неужели Роберт Мартин писал только об определенном языке?
Если интересно — то занимаештся и знаешь, если не интересно — отмахиваештся.
Много ОдинЭсников не интересуются, потому что программирование — это вообще не их.
Если в ДелаемЧтоТо(); будет ОтменитьТранзакцию(); без НачатьТранзакцию(); то будет проблема.
Но это значит, что ДелаемЧтоТо() написан не по стандарту, т.к. не соблюдает парность операций.
Потому проверка для всего кода написанного по стандарту не нужна, а если вызываешь чей-то код, которому не доверяешь — то либо надо сделать проверку, либо, поступить правильно и переписать вызываемый ДелаемЧтоТо() по стандарту.
Условие в блоке исключений нужно только если вызывать код написанный не по стандарту.
В общем случае он не нужен.
Потому все просто: если коду вызываемому доверяешь — проверка не нужна.
Все ищется
Ну https://github.com/VladFrost открыл канал в телеграмме t.me/v8std
477 подписчиков сейчас
Всем советую :)
Хватит изобретать велосипед, есть пример в стандарте "Перехват исключений в коде"
3.6. При использовании транзакций следует придерживаться следующей схемы обработки исключений в коде на сервере:
Поскольку исключение не отменяет транзакцию сразу, но запрещает успешное завершение транзакции, то все вызовы НачатьТранзакцию, с одной стороны, и ЗафиксироватьТранзакцию или ОтменитьТранзакцию, с другой стороны, должны быть парными.
Отсутствие обработки исключительных ситуаций приводит к зависшим транзакциям и к сложнодиагностируемым ошибкам вида «В этой транзакции уже происходили ошибки» в произвольных местах кода. При этом в случае вложенных операторов НачатьТранзакцию, следует обеспечить вызов всех парных операторов ОтменитьТранзакцию. Для этого в конце блока Исключение необходимо пробросить исключение выше по стеку с помощью ВызватьИсключение (как в примере выше) и соответствующим образом обработать исключение на каждом уровне стека.
RollBack забыл первой строкой в исключении
лучше не делать, просто ВызватьИсключение достаточно, так будет проброшено исходное исключение. Синтаксис доступен только в блоке catch
На счет паттерна:
ТранзакцияАктивна() не обязательно использовать для начала новой транзакции, читайте документацию по транзакциям. Открытие новой транзакции в существующей — откроет вложенную транзакцию, закрытие — закроет вложенную, но нужна повторная фиксация чтобы закрыть основную (как раз ваш случай), отмена транзакции отменяет все, включая весь стек сложенных.
Весь код приходит в вид:
EvilBeaver
Так стандарты же примерно полгода назад открыли всем :)
Читай без подписки на здоровье.
Кстати в АПК проверка конкретно этого стандарта по транзакциям тоже реализована.
Современные продукты 1С очень гибки в плане настройки прав доступа:
Они атомарны и минимальный набор прав определяется ролями БазовыеПрава<ИмяБиблиотеки>.
Остальные права определяются префиксами Чтение <Что-то> и ДобавлениеИзменение <Что-то>.
В типовых конфигурациях заранее поставляют собранные профили и группы доступа, но на реальном внедрении их зачастую переопределяют, потому что каждое предприятие уникально.
Проблемы большего количества администраторов в том, что они относятся к 1С как к чему-то "ну это ваша программа, сами в ней и работайте ", не понимая что администрированим кому-то надо заниматься. Например создание резервных копий, выполнение обновлений на новые релизы, выполнение синхронизаций с другими программами, установка дат запрета редактирования, чтобы определить закрытые периоды, настройки полнотекстового поиска, пересчет итогов и агрегатов для оптимальной работы регистров и очень много чего еще. Это задачи администратора, а не программиста или бухгалтера. Администраторы же не попытавшись разобраться в этом спихивают эту работу на рядовых бухгалтеров, а тем ничего не остается, как просить права на выполнение работы, которая в общем случае вообще за рамками их компетенции.
В первую очередь я бы вам посоветовал прочитать руководство по администрированию для платформы и документацию к БСП, БИП и БЭД, в которую включается большая часть административных механизмов.
А дальше перед вами встанет выбор, спихнуть ли эту работу на бухгалтеров дав им полные права, или же взять административную работу на себя, как администратор, и пользоваться 1С так, как это задумывали разработчики 1С.
https://its.1c.ru/db/metod8dev/browse/13/-1/1981
https://its.1c.ru/db/bsp245doc#content:1785:hdoc
https://its.1c.ru/db/uisldoc#content:122:hdoc
https://its.1c.ru/db/bed1310doc#content:5:hdoc
Это именно то, о чем я и пишу, те времена, когда IT был статьей затратной — давно прошли.
Сейчас бизнес диктует как должен развиваться IT и делает его под себя.
Если бизнес не может найти денег на это, то и развиваться в современных реалиях он не сможет.
А это значит проблема не в том, что нет денег на программу, проблема в подходе к работе бизнеса.
На основании чего это заключение? Замеры производительности обычно показывают обратное.
Давайте серьезно, уже 8.2 вышла в 2009 году
ERP 2.0 в 2013 (5 лет), против УПП 1.2, выпускаемой с 2006 (12 лет)
УТ 11.0 в 2010 (8 лет), против УТ 10.2, выпускаемой с 2006 (12 лет)
БП 3.0 в 2012 (6 лет), против БП 2.0, выпускаемой с 2010 (8 лет)
ЗУП 3.0 в 2016 (2 года), против ЗУП 2.5, выпускаемой с с 2010 (8 лет)
Все конфигурации на обычных формах морально устарели, в них от 1С предлагается только обновление законодательства и исправление критических ошибок.
Конфигураций, поддерживающих тонкие клиенты, сейчас в разы больше, чем не поддерживающих.
Бизнес, который игнорирует вклады в развитие IT обречен, т.к. рано или поздно не сможет угнаться за конкурентами, которые будут использовать новые методики ведения учета и производства.
И дело тут не только в тонких клиентах, дело в том, что для успешного ведения бизнеса нужны быстрые доработки изменения учета.
Когда мне говорят, что "У нас есть программа, мы ее наладили и работаем" я задаюсь вопросом, "А что, с того момента вы совсем не развились? Вам не нужно обновлять свои бизнес-процессы под измененные условия и объемы?"
Компании, которые до сих пор используют конфигурации на обычных формах, это либо отстающий эшелон, либо какие-то собственные поделки с сумасшедшей не поддерживаемой кодовой базой, в которую поднасрал каждый проходящий мимо студент.
Не смущает. С точки зрения информационной безопасности риски — это деньги, если потенциальный ущерб от угрозы ИБ выше в разы, чем стоимость сервера — то дешевле купить сервер.
Если база не содержит ДСП, то, очевидно, использовать файловую выгоднее.
Не используйте SMB)
клиент-сервер лучше всего
на крайний случай файловую через веб-сервер (но надо уметь настраивать безопасность веб-сервера)
Вы, наверное, не видели предобзор БПО 3.0.1:
https://releases.1c.ru/project/CEL30#plan-release-link-3.0.1
Все это езжено изъезжено, описано в официальной документации, сняты сотни видеогайдов на ютубе, и тысячи частных доработок на инфостате.
Парсить из почты я не видел, но просто парсить — да, это часть механизма. Загружать можно при поступлении товаров и просто так отдельно, вести можно цены поставщиков и цены конкурентов.
В 1С: УТ (КА или ERP) можно сразу вести номенклатуру поставщика, которая сохраняется в соответствии с собственной номенклатурой. Причем сохраняется и вся динамика цен разных позиций разных поставщиков которую можно использовать в маркетинге и ценообразовании, например для составления правил формирования цен по ценовым групам (средняя по прайсам поставщиков, самая низкая из всех поставщиков плюс 3 % и т.п.) и потом использовать это все подборе при заполнении заявок клиентам.
ВПР — это круто, но только если надо разово что-то свести, а для решения вашей задачи уже есть отработанные и хорошо документированные механизмы.
Как частное решение — это круто.
PS. Заявку на 100 позиций делать за 30 минут — это пипец долго.
Понимаете, есть очень много "Семерочников", которые не понимают принципов разделения кода, не знают паттернов, не желают учить стандарты, ноют об отсутствии ООП, не понимая, что уже есть абстрактные классы, не замечают различий между программным интерфейсом и служебным кодом.
Сейчас только БСП уже порядка 5 миллионов строк кода, на 60 базовых подсистем. Чтобы заключать о качестве такого объема кода нужны определенные показатели. Один из них — это работа более чем в 1 500 000 инсиалляций проектов. Жизненный цикл критической ошибки не более недели.
Запутанным и некачественным код видится в первую очередь людям, не знакомым с принятым стайлгайдом.
Отсутствие документации? Вы че, стебетесь?
Профессиональная разработка в системе 1С: Предприятие 8
Настольная книга 1С: Эксперта по технологическим вопросам
Система стандартов и методик разработки конфигураций для платформы 1С: Предприятие 8
Библиотека стандартных подсистем 2.4.4. Документация
1С: Предприятие 8.3.11. Документация
Методическая поддержка для разработчиков и администраторов 1С: Предприятия 8
Партнерская конференция
Ну если серьезно: сделать юнит тестирование документа в 1С все таки нельзя)
Либо это фактически будет не юнит тест, а интеграционный тест. Без рефлекшина дергать отдельные элементы мы не можем. Так же как и создавать моки с определенными свойствами.
Но можно придерживаться определенных правил: делать код разделенным, не делать в событиях непосредственную логику, т.е. изначально писать такими блоками, для которых можно написать юнит тесты, а после серии юнит тестов каждого блока одним интеграционным проверить взаимодействие блоков между собой.
Окружающие, особенно совладельцы франчей, указывают на то, что выгодно им, а им выгодно, чтобы именно ты получил сертификат 1С, который подтверждает не столько твои знания, сколько наличие специалиста определенной темы у франча, что дает возможность франчу иметь ряд отдельных плюшек.
Неужели примитивы описанные Бруксом и Виртом зависят от языка?
Неужели 1С, как язык, не полон по Тьюрингу?
Неужели паттерны банды четырех не применимы к 1С?
Неужели Роберт Мартин писал только об определенном языке?
Если интересно — то занимаештся и знаешь, если не интересно — отмахиваештся.
Много ОдинЭсников не интересуются, потому что программирование — это вообще не их.