Жёлтым по белому

Меня тут заставили изложить всё, что я знаю и смогу вспомнить про 1С. В первую очередь - подходы к решению задач, прокачке компетенций, общению с пользователями и бизнесом и т.д. Всё, что касается работы программиста 1С.

Т.к. я живу потоками (flowcon), то это будет не книга, статья, блог или серия, а поток. Назвал "Жёлтым по белому" (в моём стиле).

Ситуация сейчас подходящая - я много работаю с начинающими программистами, да еще и во франче, поэтому очень многое вспоминается из 15-летнего опыта. То, что мне казалось аксиомами, фундаментальными правилами и подходами, оказывается, бывает непонятно начинающим, да и некоторым опытным программистам.

Вот оно и вспоминается, каждый день по десять раз. Чего успеваю - записываю. Может, и вам полезно будет. А может и нет - если вы всё и так знаете, или работаете "разработчиком 1С" (что бы это не значило). Я - программист 1С старой веры.

На какой конфигурации изучать 1С программисту?

Основная работа программиста 1С – доработки какой-нибудь типовой конфигурации. Чтобы этому научиться, надо, собственно, решать задачи по доработке. Начать лучше с учебных задач, конечно. А качестве объекта доработки надо выбирать УПП – это лучший вариант. Чуть хуже – УТ 10.3.

УТ проще в понимании и освоении, но там слишком много нет – бух.учета, производства, расчета себестоимости и т.д. Ну и вся УТ есть в УПП, чего два раза бегать.

Аналогия простая. Вот был на свете такой язык программирования – Паскаль. Говорят, созданный ровно для того, чтобы учить студентов. Потом из него сделали Borland Pascal, который был в Delphi – это уже для промышленной разработки. Но исходный язык – для обучения. Причём, не только программированию, но и красоте. Простой, понятный, эффективный.

Так вот, в среде 1С Паскаль – это УПП. За исключением нескольких мест УПП – проста, эффективна, понятна. Отлаживать и дорабатывать УПП – одно удовольствие, по сравнению с тем же ЕРП или, избави Господи, ЗУПом Третьим. Не, это прекрасные конфигурации, но они – для промышленной эксплуатации, а не для обучения. Там не каждый бородатый разработчик сходу разберется.

А УПП формирует правильные подходы и паттерны. Ну и код понятный. И красивый. И метаданные ничё.

Хотя, и антипаттернов хватает. Хотите увидеть, как не надо рисовать формы? Сходите в любой платежный документ. Хотите увидеть самый недоступный понимаю пользователя документ? Сходите в корректировку долга. Хотите посмотреть на никому не нужный и непонятно откуда взявшийся контур учета? Велкам в лимитно-заборные карты и установку значений точки заказа.

В остальном – всё прекрасно. Ну, в сравнении с современными конфигурациями, разумеется. А когда разберётесь в УПП, дальше проще будет. Правда, можете заразиться 1С старой веры, и при работе с современными решениями будете испытывать больше эмоций, не всегда позитивных.

Самозащита конфигураций от идиотов

Вы как хотите, а я убедился: современные конфигурации защищаются от идиотов-программистов. Причем, и в методическом, и в техническом плане. Видимо, насмотрелись на внедрения первых типовых, и решили – всё, хватит.

В методическом плане самозащита выглядит просто: атомарные, несвязанные друг с другом объекты выстроились в процессы. Раньше цепочку действий для получения результата можно было не выстраивать. Точнее, даже сама конфигурация содержала в себе инструменты обеспечения целостности учета без работы в рамках процессов, а теперь так уже нельзя. Вроде как не рельсы поставили.

Но, самое интересное – самозащита в техническом плане. Приведу пару примеров из недавней практики.

Попробовали тут с парнями доработать оборотно-сальдовую ведомость в Бухгалтерии 3.0. Задача была несложная – приделать к оборотке шапку и подвал определенного формата. Да, задача придурошная, это я понимаю.

Так вот, ни черта не получалось. Меняем схему компоновки – ничего в результате не меняется. Меняем настройки в конфигураторе – не видит, не слышит. Идем в код, обрабатывающий СКД, там меняем – пофиг. Макет – ни в какую.

Оказалось, что есть в Бухгалтерии 3.0 код, который программно формирует настройки оборотки. Вот прям группировки создает, ресурсы и т.д. Всё, что вбито в дефолтную СКД, этот код повторяет еще раз.

А знаете, в какой момент этот код срабатывает? Когда ему не нравятся настройки, внесенные идиотом-программистом, вроде нас. Грубо говоря, там есть ветка «Если мне не нравятся настройки, то я поставлю свои». Нравится или нет – определяется по наличию в настройках определенных элементов.

Но еще дичее ситуация в ЗУП 3. Решали аналогичную задачу – добавить новый вариант отчета, но там одними настройками нельзя было выкрутиться, потребовалось доработать запрос. Честно, не помню, как назывался отчет.

Так вот, памятуя о Бухгалтерии 3 и сознавая единство подходов, я предполагал – есть, наверное, код, формирующий настройки программно. И когда отчет никак не хотел реагировать на вносимые изменения, я искал этот код.

Но нашел Нечто. Никогда такого не видел. Мы меняем запрос в СКД, смотрим на код формирования – ну, где прочиталась схема и компоновщик – всё, вроде, чики-чики, запрос наш, настройки наши. Смотрим в конце – куда-то все изменения подевались, будто и не было. А кода, исправляющего запрос или настройки – нет.

Если помните, программное выполнение схемы компоновки состоит примерно из таких этапов: прочитали схему, загрузили настройки в компоновщик откуда-нибудь, фиганули макет, ну и исполнили через пару процессоров. Обычно всё портят на этапе чтения схемы или применения настроек.

А тут – на этапе формирования макета компоновки. Нет, не так… Они не формируют макет компоновки из схемы и настроек. Они читают макет из регистра сведений. Прям есть регистр сведений, где лежат сериализованные макеты компоновки для этого отчета (может, и для других есть, не помню). Причем, эти макеты туда положены то ли при обновлении, то ли еще как.

Испоганить такой защищенный процесс формирования отчета – та еще задача. Что бы я ни делал со схемой или настройками – пофиг ей, она возьмёт готовый макет, содержащий нужные им запрос и настройки, из регистра сведений.

Браво, парни. Это без сарказма. Тут ведь и задача самозащиты решилась - большинство плюнули бы и не стали докапываться до дна, я лишь из спортивного интереса ковырялся. И, что важно, исходный код остался открытым – проще ведь было его закрыть, чтобы никто не портил.

Не исключено, что дойдёт до скачивания макета компоновки из интернета в момент исполнения отчета. Я так в Консилиуме делаю. Ну а чё.

Пока писал этот текст, подошел коллега и спросил, как так может быть – устанавливаю значение параметра компоновщика, а отчет ни в какую это значение не ловит, где-то теряет по дороге. Рекомендовал искать код, формирующий настройки программно или регистр сведений, в котором лежит скомпонованный макет. Это ERP. Тьма сгущается.

Пользователи врут

Актуально для франча. Если обращается клиент, и пользователь на том конце провода говорит «раньше работало, а щас перестало» - вполне вероятно, что он врёт.

Про то, что сейчас не работает – не врёт. Про то, что раньше работало – врёт.

Вроде, ну врёт и врёт, нам-то что? А нам то, что мы будем искать решение не в той стороне. Если что-то перестало работать, то причина одна – изменился контекст. Платформа, версия конфигурации, данные, пользователь, настройки, доработку сделали – не важно, но что-то изменилось. И программист будет искать, что именно изменилось. Спрашивать пользователя, смотреть в тестовой базе или бэкап поднимать, сравнивать конфигурации, или с конфигурацией поставщика сравнивать.

А оно, возможно, никогда не работало. Просто пользователь никогда туда не заходил. Такое даже с типовыми конфигурациями бывает, встречал на партнерской конференции – пишет кто-нибудь, что не работает такая-то штука, а она уже 2 года не менялась, просто никто туда не заходил.

Чтобы понять, врёт он или нет, надо постараться узнать контекст, в котором оно работало. Когда, на данных какого периода, с какими настройками, под каким пользователем и т.д. Если пользователь сопротивляется, не отвечает или говорит «Да не знаю я! Просто исправьте!» - вероятность того, что он врёт, повышается.

Другой вопрос – почему врёт. Основная причина, из известных мне – он боится. Разумеется, если это не директор или собственник небольшого бизнеса, а рядовой бухгалтер, менеджер или расчетчик.

Боится того, что руководство узнает о том, что чего-то отродясь не работало. Контора же деньги за это заплатила, когда-то, а теперь ей, вероятно, придётся платить еще раз. Поэтому пользователь будет настаивать на бесплатном исправлении, даже если контрактные обязательства по исправлению ошибок, в т.ч. неявных, уже истекли. Чтобы не встрять.

Ну и бояться-то есть чего. Даже если вы клятвенно пообещаете никому ничего не говорить, факт работы будет отражен в документах – листах учета или акте. И этот документ пойдет не только пользователю, но и кому-то выше. И там может попасться человек, который скажет «так, стоп, я уже это оплачивал вроде».

Если подозреваете, что нарвались на враньё, то лучше всего поднять исходные требования, и сравнивать с ними, а не с контекстом, в котором «всё работало» - такого контекста просто не существовало никогда. Ну а дальше по стандартному сценарию, принятому в вашей компании по гарантийным работам.

Что изменилось?

Ну а если пользователь не врёт, то начать надо с поиска изменений в контексте. Так намного проще будет найти причину поломки.

Идеальная ситуация – когда есть бэкап базы или возможность его поднять, и пользователь помнит, когда оно работало. Просто поднимаем и смотрим. Если действительно работало – ищем изменения в окружении. Например, если это внешний отчет, можно сохранить его в файл и сравнить старую и новую версии. Или сравнить конфигурации. Или версии типовых. И т.д.

Да, разумеется, если вы и так понимаете, почему не работает, то искать изменения в контексте смысла нет. Это совет на тот случай, если «понимай нету».

Найди 10 отличий

Это метод для задач типа «все затраты закрываются, а эта одна - нет», или «все начисления идут на 70 счет, а это – на 69, хотя они, вроде, одинаковые». Ну т.е. проблема не общая, системная, а частная, локальная.

Обычно помогает простое сравнение реквизитов. В регистре, виде начислений, статье затрат, документе, учетной политике и т.д. – в том месте, на которое падёт подозрение.

Например, у клиента в УПП на РАУЗе не закрывалась одна затрата. Даже не статья, а именно затрата. Ну т.е. пользователь-то видел в отчете незакрытую сумму по статье и подразделению, при том, что сумма расхода была ненулевой.

Программист просто пошел в регистр накопления «Учет затрат», поиском нашел статью, поглядел на остальные реквизиты, и сразу заметил: у всех строк пустая аналитика распределения затрат, а у одной – заполненная. Зашел в документ (требование-накладная), полистал и нашел строку, в которой была указана номенклатурная группа. У остальных она указана не была.

Копнул дальше, в другие месяцы – та же фигня. Одно требование, в конце месяца, и в нем одна строка с заполненной НГ. Спросил пользователя – тот не в курсе. Оказалось, кто-то когда-то заполнил, а док просто копируют каждый месяц (там что-то вроде списания туалетной бумаги на офис).

Другой пример был в БП 3, с каким-то начислением – вот не на тот счет идет, и всё. Должно на затраты, а идёт на 69. Внутри вроде правильная настройка стоит, и счета указаны верно.

Делаем просто – сравниваем проблемный вид расчета с теми, которые работают нормально, и похожи по смыслу. Визуальный осмотр различий не выявил, поэтому полезли через групповую обработку реквизитов. В УПП это было удобно – она в табличку вываливала нужные ссылки, и различия можно было найти быстро. В БСПшной неудобно, поэтому плюнул и написал запрос в консоли.

Ну и оказалось, что там есть скрытый реквизит, точного названия не помню, но он, вроде как, определяет, начисление это или страховые взносы – он и различался. А заполнялся он при переходе с одной версии БП на другую, и сделал это как-то коряво. Тут уже можно было предметно лезть в конфигуратор, искать этот реквизит и его влияние на отражение зарплаты (благо, тип у него было – перечисление, т.е. можно прям глобальным поиском искать). Поменяли программно и всё заработало.

Да, этот метод – на случай, когда вы не шарите в теме, а решение надо быстро найти. Если и так, сходу, знаете, в чем проблема, то искать отличия не надо