В 1С принята известная схема ведения цен: периодическй регистр сведений, в который цены записываются с датой начала действия. Соответственно когда нам нужна цена товара - мы берем СрезПоследних на текущую дату на этом регистре. Все логично.
Припомним также, стандартную систему регистрации изменений в 1С: записал - зарегистрировал изменение; прочитал изменения - передал - забыл. Тоже простая и логичная тема.
Проблема
Но когда нам нужно передать цены куда-то, например, в кассовую систему или на сайт, где ничего не слышали про дату начала действия цены и цена одна: текущая - механизм регистрации изменений и СрезПоследних никак не желают "переваривать" такую логику. В этом месте очень помог бы механизм типа "РегистрСведений.ЦеныНоменклатуры.СрезПоследних().Изменения", но ничего подобного в платформе нет. Приходится колхозить на коленке, продумывая по дороге такие варианты:
- цену назначили с послезавтра.
- "случайно" перепровели документ, который перезаписал уже не актуальные цены двухнедельной давности.
- отменили проведение документа с актуальными ценами, начали действовать цены двухнедельной давности.
- удалили несколько строк из документа с актуальными ценами.
Это только некоторые из тех вариантов, которые возможны на практике, думаю можно придумать и более витееватые сценарии. Понятно, что такое обращение с системой больше похоже на ее изнасилование, чем на нормальную работу, но если 1С это все не запрещает - у нас нет другого выхода, кроме как поддержать это и в нашем обмене.
Решение
Качественно и гарантированно решить все эти проблемы "на коленке" не получится, придется развести Архитектуру. Нам потребуется промежуточный регистр.
Делаем регистр сведений ДействующиеЦеныНоменклатуры, отличающийся от стандартного регистра ЦеныНоменклатуры, следующим:
- новый регистр не должен быть подчинен регистратору и не должен быть периодическим
- данные о регистраторе и дате начала действия цены добавим в реквизиты нового регистра на всякий случай
В этом регистре будем хранить внезапно действующие цены. Т.е. состояние нового регистра должно соответствовать состоянию виртуальной таблицы РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ТекущаяДата) с поправкой на задержку заполнения. Иными словами, мы виртуальную таблицу РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ТекущаяДата) делаем реальной в РегистрСведений.ДействующиеЦеныНоменклатуры. Регистрировать изменения цен и выгружать их также будем из нового регистра по простой и линейной логике: изменилось - выгрузил.
Наполнять регистр, будем по следующей логике: выполняем запрос, который соединяет срез последних ЦеныНоменклатуры и регистр ДействующиеЦеныНоменклатуры и выбирает те строки, у которых цена отличается. Далее обновляем в регистре действующих цен полученными из запроса строками. Стоит обратить внимание на тот момент, что нужно делать полное соединение, т.к. записей может не оказаться с любой стороны.
Запуск этой логики может выполняться как независимым регламентным заданием, так и вызовом непосредственно из регламентного задания выгрузки цен, перед самой выгрузкой в систему-потребитель. В пользу независимого регламента стоит сделать выбор, если потребителей цен больше одного, периодичность высокая и регистр должен быть всегда готов к выгрузке или же если вы хотите рассматривать эту функциональность как полностью независимую. В остальных случаях представляется оправданным формирование таблицы действующих цен непосредственно в процессе выгрузки.
Производительность этого дела такова, что на неплохом серверном железе, при 10000 активной и 50000 всей номенклатуры и 500 видах цен вся логика отрабатывает в районе 5 минут. В моем случае, происходит это раз в час отдельным регламентом.
Описанная механика позволяет обработать весь спектр возможных диверсий действий пользователей. Уже готовая подсистема приложена. Платформа 8.3.9.2233
