User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

 

За последние два года поимел несколько проектов по внедрению УТ 11. Во всех случаях приходилось программировать. Собственно, я разработчик, а не методист, поэтому там, где не надо программировать меня нет. Еще я не специализируюсь на торговле, я разрабатываю все и везде. Обычные формы, управляемые и даже до сих пор иногда в 7.7. Первое, о чем хочу сказать, что на начальных этапах я все время продалбывался в оценке своей работы. Происходило это из-за моего "богатого" опыта работы. Чтобы оценить задачу в часах, я не изучаю детально "внутренности", я осматриваю "пациента" снаружи (в режиме предприятия), понимаю, что у нас уже есть, смотрю на цель и даю оценку, просто все задачи уже когда-то где-то решались, я знаю как архитектурно решить задачу, знаю сложность работы в той или иной версии платформы, еще я хорошо знаю идеологию 1С поэтому не смотрю внутрь, а предполагаю как оно там устроено, т.к. сдавал им экзамены J, они меня учили делать так, значит и сами должны делать так же.

 

  



И вот первая задача, о которой хочу поведать, простая как валенок: необходим документ, корректирующий заказ клиента, позволяющий заменить номенклатуру или количество. Не спрашивайте зачем, весь мир знает зачем. Что я знал до согласования оценки:

 

1.       Заказ клиента в УТ 11 корректируется непосредственно в заказе. На него даже дата запрета не распространяется.

 

2.       Есть регистр накопления, который заказ двигает в «приход», а реализация в «расход». Я посмотрел на его структуру и кроме кода строки меня там ничего не напугало. Я заложил геморой с кодом строки в оценку.

 

3.       В УТ 11 нет отчета по этому регистру. Я удивился, но просто заложил в разработку простейшую оборотку по этому регистру.

 

Опыт со мной сыграл злую шутку, в УТ 10 была другая идеология работы с заказом клиента. Там были корректировки, а финальную потребность можно было увидеть только в отчете. Тут принцип работы из формы документа, поэтому и отчет не нужен. Но клиенту Важно было фиксировать корректировку, чтобы фиксировать причины и историю изменений. Версионирование заказа не решало поставленные задачи и было решено сделать документ корректировку. К тому же я её так дешево оценил, что клиент не сомневался, что надо делать.

 

Мое решение еще продиктовано идеологией платформы и вообще учета: каждое событие/операция должно фиксироваться отдельным документом, нельзя править ранее созданные документы. И, что радостно, клиент считал так жеJ

 

Что я предполагал сделать, и почему оно оказалось «немного» сложнее. Я хотел создать документ, со всеми нужными клиенту полями и полями нужными для формирования движений по регистру. Например, клиенту идентификатор строки заказа был до лампочки, а мне для регистра нужен, т.к. он – измерение. Потом я хотел сделать оборотку на СКД с разворотом до регистратора. А потом печатную форму по образцу заказчика. Типовые объекты править вообще не собирался, кроме добавления нового регистратора.

 

А оказалось, что записанные в регистр данные могли только «отменить» потребность клиента, а вот изменить они её не хотели никак! Все данные для заполнения реализации на основании заказа брались из… барабанная дробь! ТАБЛИЧНОЙ ЧАСТИ ЗАКАЗА!!! По регистру лишь проверялось, что товар еще не отгружен. Товар, который есть только по данным регистра в реализацию не попадал.

 

 

  



Итак, мне пришлось «бесплатно» доработать обработку заполнения документа при вводе на основании и в обработчиках табличной части.

 

На экзамене специалиста по платформе за обращение к табличной части документа при наличии регистра накопления снижали оценку. Я понимаю, почему они так сделали в УТ 11. Так проще! Им для заполнения реализации нужны значения 20 полей строки, сунуть их все в измерения регистра – очень плохо, заполнять их значениями по умолчанию – сложно, вот они и берут из регистра только номера не закрытых строк заказа, а все поля из строки документа.

 

В чем тут ошибка? Убита масштабируемость. 1С само продвигает этот постулат, что данные для работы логики и отчетов надо получать из регистров, к данным документа обращаться при формировании печатных форм этих документов. Если бы это было так, добавление в учет еще одного вида документа было бы предсказуемое по трудозатратам и минимально по вмешательству в типовой код.

 

По определению 1С:

 

Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.

 

А тут система повела себя агрессивно, она не захотела адаптироваться к появлению нового функционала, а всячески говорила: у меня все и так есть, не трогай меня, ты просто не умеешь мной пользоваться.

 

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

 

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

 

Оказалось, что есть хреналион функциональных опций и условий в коде, по которым реквизит направление деятельности «прячется» от пользователя. Т.е. там нет функциональной опции «использовать направления деятельности». Там есть штук 5 для разных учетов, которые выставляются программно и зависит это все … барабанная дробь! НАЗВАНИЯ КОНФИГУРАЦИИ!!! Вот если вы в комплексной или в ерп, то милости просим, пользуйтесь, а если Вы в УТ, то «пшел вон щенок». Вроде, не страшно, что крутой функционал доступен в более крутых решениях, это логично. Но давайте разберемся тут не все гладко:

 

1.       Функционал есть и он работает (тссс, никому ни слова, пара взмахов скальпелем и все само начинает работать)

 

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

 

3.       Пользователь неявно платит за его существование местом на жестком диске, процессорным временем и платой за услуги таких как я:

 

3.1.    Куча колонок в табличных частях и шапках документов, влияет на размер таблиц, т.е. база растет быстрее, чем могла бы.

 

3.2.    Огромное количество кода выполняется при каждом чихе пользователя, который сводится к тому, чтобы спрятать лишние поля, т.е. программа тормозит. Пользователь видит, что в документе три реквизита в шапке и пять в табличной части, а документ проводится и записывается очень долго. Даже форма нового документа открывается в разы дольше из-за выполнения кода по анализу настроек.

 

3.3.    При выборе партнера в документе опять все висит. Пользователю трудно объяснить чем УТ занята в этот момент J а она заполняет направление деятельности пустым значением.

 

3.4.    Я очень по долгу сохраняю конфигурацию, сравниваю её, создаю хранилище, обновляю и прочее, короче я не программирую, а сижу смотрю, как платформа анализирует кучу объектов, недоступных пользователю. Та самая платформа, которая в 1000 раз быстрее «клюшек» и рассчитана 1000 пользователей, не тянет одного менеджера по продажам на ноутбуке 4ех летней давности, т.к. жесткий диск у него не SSD и памяти всего 6Гб.

 

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

 

Итак, мы имеем следующие архитектурные проблемы:

 

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

 

Нет единого места анализа доступного функционала. Если анализ заполнености реквизитов считает, что мы в ЕРП, то почему на форме не отобразились реквизиты? Это очень грустно. В системе не должно быть более одной функции отвечающей на один и тот же вопрос.

 

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

 

Дело было в сетевом маркетинге. Им очень понравилась иерархия элементов в справочнике партнеров. Надо было добавить в партнера реквизит «статус»: бриллиант, изумруд, золотой, серебряный. Статус не связан с уровнем иерархии, а связан с количеством подчиненных.

 

Для отчета надо было собрать продажи по определенному статусу. Т.е. имеем продажи по самым разным статусам, и надо заменить партнеров со статусом ниже выбранного, на ближайшего подходящего по дереву иерархии. Например, всех «рядовых» меняем на «золотых», но между ними N ступеней в дереве справочника, где N для каждого разное. Максимальная глубина дерева пока 21, но может меняться, поэтому в запросе писать «.родитель.родитель.родитель.родитель.родитель…» я не захотел, плюс глубина может вырасти в любой момент.

 

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

 

Так вот какова была моя радость, когда я обнаружил регистр сведений «ИерархияПартнеров». В нем есть для каждого партнера все вышестоящие родители и указан уровень. В типовой с помощью этого регистра ищутся, например, ближайшие контрагенты, которые привязаны к родителям. Вяжем партнера с этим регистром, наложив на родителя условие и сгруппировав по полю «уровень». Потом второй раз вяжем таблицу регистра уже по условию уровень=уровень.

 

Отчет получился хорошим, запрос изящным и я был доволен собой и типовым архитектурным решением. Пока не узнал цену вопроса J А цена высока! При записи партнера надо переписать записи в регистре сведений для всех кто ниже и выше. Если у него в подчинении 10000 партнеров, то все, транзакция будет «жирной», готовьте память и жесткие диски.

 

Я объяснил клиенту, что «крутых» бриллиантов лучше не перезаписывать, а, чтобы не путаться, лучше вообще никого не перезаписывать. Люди привыкли. Пока не выяснилось страшное. УТ сама перезаписывает партнера при выбивании фискального чека. Не буду говорить, что это ошибка архитектуры, архитектура тут крутая, позволяет решать интересные задачи. Это косяк разработчиков обработок торгового оборудования, по ФЗ-54 чеки ходят на почту или телефон, при выбивании чека указанную контактную информацию писали в партнера, к сожалению, даже если она не заполнена в форме выбивания чека. Да даже если и указана, это не повод переписывать иерархию, если мы заполняем контактную информацию, надо анализировать, что изменилось, прежде чем запускать рекурсивный алгоритм перестройки иерархии. Никто об этой фигне не знает, т.к. при иерархии в 1-2 уровня все проскакивает за доли секунд. А вот сетевой маркетинг вскрыл проблему. Сами справочники были готовы к большим данным, но их использование в типовом коде как-то – нет. Итак, я радостно решил задачу, загрузил с сайта всех клиентов, создал хороший отчет и получил свои деньги, а потом они начали продавать и … продажи встали из-за проблем производительности.

 

Выводы, которые жизнь заставила меня сделать: УТ это продукт высокого уровня сложности. Настолько высокого, как и ЕРП. Цена разработки одного «бантика» должна быть очень высокой. Не думайте, что это маленький бантик и сейчас я его за час привяжу вот сюда. С большой вероятностью не привяжите. Тут надо по-взрослому, проводить обследование и анализ, составлять ТЗ, закладывать риски. Не советуйте УТ11 клиентам с маленьким бюджетом, если им мало типового функционала. Это очень грустно, когда клиент платит мало, Вы работаете много, а клиент все равно не доволен. Оно и понятно, клиент же хотел только маленький бантик, а вы там возитесь, наверное, Вы плохой программист. Это все не очень коррелирует с ценой УТ. УТ стоит как продукт для небольших организаций, не способных платить сотнями тысяч рублей разработчику. Бизнес у организаций такого масштаба очень гибкий, иначе не выжить, у тех, кто автоматизирует свой бизнес срок жизни программы без доработок очень короткий, они постоянно что-то допиливают, улучшают и оптимизируют.

 

 

 

 

 

 

 

 

 

Авторизуйтесь пожалуйста