При работе в связке 1С:Управление торговлей 11 и 1С:Розница 2.2 многие компании сталкиваются с серьезной архитектурной проблемой: типовая логика 1С не предполагает повторного использования (цикличности) одного и того же физического подарочного сертификата. В системе подарочный сертификат рассматривается как финансовый документ строгой отчетности. Как только он продан, активирован, а затем полностью погашен при оплате товара, его жизненный цикл завершается. Попытка продать этот же номер повторно в Рознице может пройти успешно (при определенных доработках), но при обмене с УТ 11 документ реализации выдаст ошибку, так как в регистре статусов данный номер уже числится как «Погашен».
В данной статье мы подробно разберем, как автоматизировать процесс «оживления» сертификатов, избавиться от ручных корректировок в УТ и настроить систему так, чтобы обмен данными происходил без ошибок. Мы проанализируем технические аспекты работы регистров и предложим несколько вариантов программного решения задачи.
Разберем ситуацию глубже. В конфигурации УТ 11 учет сертификатов ведется в разрезе серийных номеров и их текущих состояний. Основным «контролером» здесь выступает регистр сведений СтатусыПодарочныхСертификатов. Когда в Рознице происходит гашение сертификата, в УТ прилетает информация о том, что номинал использован. При попытке повторной продажи того же номера, документ РеализацияПодарочныхСертификатов обращается к этому регистру. Видя статус «Погашен», система блокирует проведение, так как с точки зрения бизнес-логики нельзя продать то, что уже перестало существовать как обязательство.
Для решения этой проблемы нам необходимо обеспечить «очистку» истории сертификата перед его повторным вводом в оборот. Рассмотрим основные методы реализации этой задачи.
Первым делом нам нужно разрешить повторную продажу в самой Рознице. Рассмотрим алгоритм создания специальной обработки, которую может запускать менеджер магазина при возврате физического пластика на склад для повторной реализации.
Суть метода заключается в программном изменении статуса серийного номера. Нам необходимо вернуть его в состояние «Активирован» или «Не продан», в зависимости от настроек учета. Проанализируем пример кода, который может быть использован в такой обработке:
// Пример сброса статуса серийного номера сертификата в Рознице
Процедура СброситьСтатусСертификата(ВыбранныйСертификат) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СтатусыПодарочныхСертификатов.Период,
| СтатусыПодарочныхСертификатов.Статус
|ИЗ
| РегистрСведений.СтатусыПодарочныхСертификатов КАК СтатусыПодарочныхСертификатов
|ГДЕ
| СтатусыПодарочныхСертификатов.ПодарочныйСертификат = &Сертификат";
Запрос.УстановитьПараметр("Сертификат", ВыбранныйСертификат);
// Удаляем старые записи или меняем статус на "В наличии"
НаборЗаписей = РегистрыСведений.СтатусыПодарочныхСертификатов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ПодарочныйСертификат.Установить(ВыбранныйСертификат);
НаборЗаписей.Прочитать();
НаборЗаписей.Очистить();
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.ПодарочныйСертификат = ВыбранныйСертификат;
НоваяЗапись.Статус = Перечисления.СтатусыПодарочныхСертификатов.ВНаличии;
НоваяЗапись.Период = ТекущаяДата();
НаборЗаписей.Записать();
Сообщить("Сертификат " + ВыбранныйСертификат + " готов к повторной продаже.");
КонецПроцедуры
После выполнения такой операции РМК (Рабочее место кассира) снова увидит этот номер как доступный для продажи. Однако помните, что это решит проблему только в локальной базе магазина.
Если вы знакомы с инструментом Конвертация Данных, этот метод будет наиболее элегантным. Чтобы УТ 11 не ругалась на «Погашенный» статус при обмене, нам нужно внедрить логику проверки статуса непосредственно в момент загрузки документа из Розницы.
Проанализируем шаги настройки в КД:
РеализацияПодарочныхСертификатов или ОтчетОРозничныхПродажах (в зависимости от того, как настроен ваш обмен).ПередЗагрузкой или ПриЗагрузке пропишем алгоритм поиска существующего сертификата в базе УТ.Рассмотрим пример алгоритма для обработчика (псевдокод):
// Логика в правилах обмена (КД)
Если ТипЗнч(Объект) = Тип("ДокументОбъект.РеализацияПодарочныхСертификатов") Тогда
Для Каждого СтрокаТЧ Из Объект.ПодарочныеСертификаты Цикл
ТекущийСтатус = ПолучитьСтатусСертификатаВ_УТ(СтрокаТЧ.ПодарочныйСертификат);
Если ТекущийСтатус = Перечисления.СтатусыПодарочныхСертификатов.Погашен Тогда
// Сбрасываем статус в регистре, чтобы документ провелся
ОбнулитьСтатусВРегистре(СтрокаТЧ.ПодарочныйСертификат);
КонецЕсли;
КонецЦикла;
КонецЕсли;
Если вы не хотите погружаться в Конвертацию Данных, можно реализовать аналогичную логику на стороне УТ 11 с помощью расширения и подписки на событие ПередЗаписью или ОбработкаПроведения для документов реализации сертификатов.
Разберем, как это работает пошагово:
РеализацияПодарочныхСертификатов.СтатусыПодарочныхСертификатов.Важный нюанс: Не забудьте также очистить регистры накопления, связанные с остатками по сертификатам (если они не обнулились автоматически), иначе в УТ возникнет неверное сальдо по взаиморасчетам. Обычно в УТ 11 это регистр РасчетыСКлиентами или специализированные регистры авансов.
Рассмотрим ситуацию, когда у вас крупная сеть (например, 50 магазинов). Эксперты рекомендуют не настраивать прямой обмен между каждым магазином и УТ 11. Гораздо эффективнее использовать схему: Магазины <-> ЦБ Розницы <-> УТ 11.
В этом случае все операции по «реанимации» сертификатов (сброс статусов) лучше проводить централизованно в ЦБ Розницы. Это гарантирует, что во всех магазинах информация о доступности «б/у» сертификата обновится одновременно после очередной сессии обмена. В УТ при этом будут попадать уже «чистые» данные, что минимизирует количество ошибок и необходимость ручных правок.
Если вы боитесь нарушить целостность финансовых данных, проанализируем еще один «безопасный» путь. Вместо того чтобы менять статус старого элемента, можно создать обработку, которая при возврате погашенного сертификата на склад «перевыпускает» его в системе.
Как это работает:
Физический номер на пластике остается прежним (например, "0001"), но обработка создает в справочнике СерийныеНомера (или аналогичном) новую запись, добавляя к ГУИДу или наименованию скрытый префикс. Для кассира и покупателя это будет тот же сертификат №0001, но для УТ 11 это будет совершенно новый объект учета с чистой историей. Этот метод исключает любые конфликты в регистрах накопления и позволяет сохранить полную историю использования каждой физической карточки.
Подведем итоги нашего анализа. Для избавления от «ручного ада» в УТ 11 при работе с подарочными сертификатами из Розницы 2.2, мы рекомендуем:
Выбор конкретного метода зависит от ваших навыков программирования и сложности архитектуры вашей сети. Наиболее стабильным решением является сочетание обработки в Рознице и доработки правил обмена через КД.