Как выгружать цены

В 1С принята известная схема ведения цен: периодическй регистр сведений, в который цены записываются с датой начала действия. Соответственно когда нам нужна цена товара — мы берем СрезПоследних на текущую дату на этом регистре. Все логично.

Припомним также, стандартную систему регистрации изменений в 1С: записал — зарегистрировал изменение; прочитал изменения — передал — забыл. Тоже простая и логичная тема.

Проблема

Но когда нам нужно передать цены куда-то, например, в кассовую систему или на сайт, где ничего не слышали про дату начала действия цены и цена одна: текущая — механизм регистрации изменений и СрезПоследних никак не желают "переваривать" такую логику. В этом месте очень помог бы механизм типа "РегистрСведений.ЦеныНоменклатуры.СрезПоследних().Изменения", но ничего подобного в платформе нет. Приходится колхозить на коленке, продумывая по дороге такие варианты:

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

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

Решение

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

Делаем регистр сведений ДействующиеЦеныНоменклатуры, отличающийся от стандартного регистра ЦеныНоменклатуры, следующим:

• новый регистр не должен быть подчинен регистратору и не должен быть периодическим
• данные о регистраторе и дате начала действия цены добавим в реквизиты нового регистра на всякий случай

В этом регистре будем хранить внезапно действующие цены. Т.е. состояние нового регистра должно соответствовать состоянию виртуальной таблицы РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ТекущаяДата) с поправкой на задержку заполнения. Иными словами, мы виртуальную таблицу РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ТекущаяДата) делаем реальной в РегистрСведений.ДействующиеЦеныНоменклатуры. Регистрировать изменения цен и выгружать их также будем из нового регистра по простой и линейной логике: изменилось — выгрузил.

Наполнять регистр, будем по следующей логике: выполняем запрос, который соединяет срез последних ЦеныНоменклатуры и регистр ДействующиеЦеныНоменклатуры и выбирает те строки, у которых цена отличается. Далее обновляем в регистре действующих цен полученными из запроса строками. Стоит обратить внимание на тот момент, что нужно делать полное соединение, т.к. записей может не оказаться с любой стороны.

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

Производительность этого дела такова, что на неплохом серверном железе, при 10000 активной и 50000 всей номенклатуры и 500 видах цен вся логика отрабатывает в районе 5 минут. В моем случае, происходит это раз в час отдельным регламентом.

Описанная механика позволяет обработать весь спектр возможных диверсий действий пользователей. Уже готовая подсистема приложена. Платформа 8.3.9.2233