Пишем обработку по расчету цен для УНФ 1.6

В УНФ есть ОчередьРасчетаЦен — ужасное архитектурное решение, которое я обсуждал на мисте. В итоге оно просто перестало работать, накопив огромный массив цен за несколько лет учета.

Пришлось даже отключать очередь расчета цен:

Потратив 4 часа (оплаченных) на борьбу с этим конструктом, я убедил клиента сделать динамический расчет цен. Оценил это, правда, в 2 часа, хотя для УНФ все следует умножать на два, там совсем другая архитектура.

У меня есть готовая обработка для другого клиента, реализованная как внешняя обработка, где есть команда для открытия формы и команда для работы из регламентного задания.

Кроме того, там есть сохранение настроек.

Её и взял за основу, просто переименовал имя и синоним.

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

Добавил на форму список вида цен, кнопку по их расчету. Добавил период дней расчета.

Поправил команды внешней обработки, чтобы они вызывали открытие формы или расчет цен по расписанию.

По сути, сделал интерфейс. На это ушло с отладкой 35 минут. При этом один раз вылетел конфигуратор по непонятной причине (база файловая).

Теперь можно писать непосредственно код по расчету цен. Я хочу все сосредоточить в запросе, чтобы находить только те цены, которые нужно рассчитывать.

Идея была такая, что на каждую установку закупочной цены создавать установку зависимой цены за период в 100 дней (или другой).

Помучавшись час с запросом, я понял, что реализовать в разумные сроки (а тем более в отведенный бюджет) такой алгоритм сложно. Да, наверное, и не нужно. Ведь если поменяется процент, будут рассчитаны все цены за период, а это плохо для истории цен. А как быть с ценами, которые были установлены более 100 дней назад (закупка давно была).

Вот какой монструозный запрос у меня был на этот момент:

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

На этот момент я израсходовал 1.5 часа по проекту. Поэтому решил отставить эксперименты.

Кусок кода по созданию документа установки цен я взял из УТ11. Правда, долго искал регламентное задание или внешнюю обработку, где этот код находится. Оказалось, что я корректирую цены перед выгрузкой на сайт, из модуля выгрузки на сайт, т.к. выгрузка на сайт делается регулярно.

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

Глядя на свой прошлый код я осознал, что могу рассчитывать каждый вид цен отдельно, поэтому сам запрос по расчету цен стал проще:

В целом уложился в 2.5 час, на полчаса больше, чем планировал. И тут УНФ подогнала мне еще одну неожиданность.

При проведении зачем-то устанавливались базовые виды цен — закупочные. Видимо, потому что розничные и дилерские — зависят от закупочных.

Пришлось поменять тип цен на статические:

Параметры расчета цен вынес в обработку:

Все это заняло еще пол-часа. В итоге объем работ вышел 3 час. Никогда не стоит недооценивать УНФ.

Среда: УНФ 1.6.26.172 Объем: 3 час.

fixin

Программирую на 1С с 1999 года. В 1С просто Гений. В 2020 году ушел из офиса на вольные хлеба фриланса. Принимаю заказы.

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *