Писал заметку для профильного infostart.ru, но там ее не пропустили, т.к. “не несет методической ценности”. Размещу здесь, т.к. я все таки потратил на написание определенное время и жалко если оно будет потрачено впустую.
Данная небольшая заметка написана на эмоциях от того, что вместо автоматизации и развития ПО в организации приходится часами выискивать и править баги в самой дорогой флагманской конфигурации от 1С – ERP. Я надеюсь, что проблема привлечет внимание разработчиков типовых конфигураций компании 1с и они задумаются о повышении качества разрабатываемого ПО.
Не буду вдаваться в технические детали, а приведу пару примеров для общего понимания проблемы.
Первый пример связан с закрытием месяца и помощником исправления остатков товаров организации.
Обращается сотрудник и сообщает, что в закрытии месяца показывает отрицательные остатки, которые не исправляются помощником
Помощник показывает следующие ошибки, которые связанны с учетом по ГТД
При попытке запуска исправления выходит ошибка вида «нет метода ПолучитьОбъект»
Решаем квест платформы с отладкой фоновых заданий, когда постоянно открываются какие-то модули и в них приостанавливается выполнение (хотя стоит флаг РежимОтладки) и находим, что проблема в расширении EF_00_00528946
Удивительным образом данное расширение не решает описанной проблемы, а только ломает помощник. Как это попало в прод?
После исправления пары процедур в расширении исправление все же запускается, но не проходит и вываливается с ошибкой
А если посмотреть, что же там за минуса и из-за чего потребовалось это расширение, то увидим интересную схему:
Приобретение по схеме «в пути» делает минус без ГТД и плюс с ГТД, а потом, когда товар поступает, он закрывает минус без ГТД. И получается, что по итогам месяца висит минус и он отображается как ошибка при закрытии месяца. При этом данный «минус» исправить никак нельзя.
Зачем было делать такой алгоритм, какая логика была у аналитика и разработчика? Я думаю, тут просто изначально не было никакого продуманного алгоритма, а когда вылезла логическая проблема, то просто стали закрывать костыль на костыль.
Второй пример связан с платежными документами.
Создаем заявку на расход ДС и ставим в ней ставку “без НДС”. Копируем заявку и в копии ставка НДС 20%. Смотрим процедуру ПриКопировании, убираем в ней замену ставки НДС но ничего не меняется. Оказывается, при создании формы ставка НДС высчитывается еще раз и не важно, копировали заявку или вводили списание на основании заявки (в списаниях та же проблема). Интересно, что в договоре есть специально поле «Ставка НДС для платежей» и когда договор является объектом расчетов, ставка должна по идее браться из этого поля. Но вот поле то сделали, а получение ставки из этого поля при изменении договора в заявках и платежках забыли.
Зачем в нескольких местах при одной операции выполнить одно и тоже действие? (или процессоры мощные, памяти много, можем хоть 10 раз подряд посчитать одно и тоже значение?) У меня такое ощущение, что разработчики 1с уже сами сильно запутались в своем коде и не знаю где, что происходит.
Другие замечания.
А еще множество проблем с НДФЛ 2023 г. которые подпортили много нервных клеток расчетчикам, бухгалтерам и программистам, не говоря уже об огромных потерях времени и косвенных убытках.
Функции из сотен сток с кучей ветвлений, процедуры из одной строки вызывающие такие же процедуры. Повальные Оповещения вместо использования асинх/ждать. (Попробуйте отладить работу торгового оборудования в котором каждая процедура запускается через Оповещение). Кстати с оповещениями и обработками ожидания связанна интересная проблема (в 1с Розница была): если на медленном ПК в файловой версии на кассе кассир делает двойной клик по кнопке пробития чека (и вроде продажа по терминалу привязанному к 1с), то из-за оповещений и обработчиков ожиданий запускаются два потока и чек пробивается дважды.
При каждом обновление ERP уже морально готовишься потратить часы на анализ и исправление новых ошибок.
Вспоминается УПП, где не было такого огромного количества ошибок и были более понятные и быстрые алгоритмы.
В УПП журнал «Документы контрагентов» открывается можно сказать мгновенно, а в ERP журнал документов продаж 6 секунд. Проведение Реализации товаров и услуг в УПП занимает 4 секунды, в ЕРП 8 секунд. При этом в УПП еще и партии сразу вычисляются и отражение в БУ, а в ЕРП нужно будет потратить 10 секунд (один документ) на отражение в БУ и отдельно партии рассчитать.
Почему все настолько ухудшилось? Когда мы покупаем новую версию продукта, то считаем, что все должно стать лучше, быстрее, стабильнее. А получаем кучу багов и архитектурных ошибок
Можно отправлять кучу писем с детальным описанием бага в 1с, вот только исправят они его через пару месяцев (если вообще исправят), а организации нужно исправление сегодня. При этом я свое время потратил уже и за анализ и исправление бага организация заплатила со своего кармана, вместо вложения денег в развитие. Получается, что организация сначала покупает ПО за сотни тысяч рублей, а потом еще и за свои же деньги (те же сотни тысяч) правит ошибки.
В 1с ПО проектируют и разрабатывают джуны-мидлы с опытом 2-3 года, нет тестирования или огромная нагрузка с постоянными дедлайнами из-за того, что не хватает людей? Решение: набрать больше разработчиков высокого уровня, тестировщиков, грамотных архитекторов и аналитиков (с опытом работы в реальных крупных организациях от 7-10 лет), но этого не случится.
Пока 1с, по сути, монополист и может ухудшать качество своего продукта сколько угодно.
UPD:
Дело не в самих багах, их нельзя избежать. Но можно избежать попадания их в прод.
Проблема в методологии разработки и я конечно понимаю почему так с точки зрения бизнеса: хорошие специалисты дорогие и их нужно много на большой проект. Это увеличит себестоимость и снизит маржинальность бизнеса (меньше яхт и золотых унитазов ). Владельцам бизнеса придется повышать стоимость ПО для того, что бы остаться на том же уровне дохода, но это может привести к падению доходов, т.к. у конкурентов дешевле. Поэтому занимаются оптимизацией расходов. Только вместо оптимизации и автоматизации процессов выбирают легкий путь сокращения ФОТ (расходов на зарплату). Как следствие это сильно сказывается на качестве продукта и конечные пользователи по сути становятся бета-тестерами.
1с выбрали “Быстро, Дешево” (из “Качественно, Быстро, Дешево”).
Возможно на каком то этапе архитекторы выбрали неправильное направление и так усложнили продукт, что его поддержка требует огромных затрат и сейчас выходом будет только разработка нового продукта.