Взаимодействие между различными конфигурациями 1С, такими как 1С:Управление нашей фирмой (УНФ) и 1С:Бухгалтерия предприятия (БП), является распространенной задачей в автоматизации бизнеса. Часто возникает необходимость, чтобы документы, созданные и переданные из одной системы (например, УНФ) в другую (БП), принимали нумерацию и префиксы принимающей системы. Это особенно актуально, когда БП является основной системой для ведения бухгалтерского учета и выдачи первичных документов клиентам, а бухгалтеру важно иметь единую сквозную нумерацию для всех документов в своей базе, независимо от источника их создания. Давайте рассмотрим, как мы можем реализовать такую логику, преодолевая стандартные механизмы обмена и обеспечивая корректность данных.
Начнем с анализа сути запроса. Представим ситуацию: в УНФ создана «Реализация товаров и услуг» с номером НФНФ-00002. После обмена с БП, бухгалтер хочет, чтобы этот же документ в БП получил номер, продолжающий текущую нумерацию БП, например, БПБП-00013, а не сохранял исходный номер из УНФ. Причина проста: так легче вести учет, избежать путаницы и обеспечить единый порядок в документации, выдаваемой клиентам из БП. В таком случае, документ, созданный в УНФ, является лишь исходным источником данных, а "официальный" номер он должен получить уже в конечной системе учета.
Это не просто техническая прихоть, а вполне обоснованное требование с точки зрения удобства работы пользователя и соблюдения учетной политики. Бухгалтер, работая с документами в БП, ожидает видеть сквозную нумерацию, и документы, пришедшие из УНФ, не должны выбиваться из общего порядка. Также часто требуется, чтобы префикс документа соответствовал префиксу организации в БП, что также способствует унификации и порядку.
Для реализации нашей задачи нам потребуется вмешаться в стандартный процесс присвоения номера документу. Платформа 1С предоставляет несколько точек расширения, которые мы можем использовать, предпочитая использовать механизм расширений для сохранения возможности обновлений типовых конфигураций.
ПриУстановкеНовогоНомераЭто событие возникает в модуле объекта документа, когда система пытается присвоить новый номер. Это
идеальная точка для перехвата стандартной логики и установки собственного номера. В обработчике этого события мы можем:
ОбменДанными.Загрузка).Мы должны создать в расширении обработчик для этого события. Примерная логика внутри обработчика ПриУстановкеНовогоНомера может выглядеть так:
Процедура ПриУстановкеНовогоНомераДокумента(СтандартнаяОбработка, Префикс)
Если ОбменДанными.Загрузка Тогда
// Отменяем стандартную обработку, чтобы присвоить номер вручную
СтандартнаяОбработка = Ложь;
// Определяем префикс, который должен быть у документов в БП.
// Его можно получить из константы, настроек организации или справочника префиксов.
// Например, "БПБП-"
ПрефиксДляБП = ПолучитьПрефиксОрганизацииБП(); // Ваша функция для получения префикса
// Получаем следующий доступный номер для данного типа документа с учетом префикса БП.
// Стандартный метод объекта УстановитьНовыйНомер() обычно справляется с этим.
ЭтотОбъект.УстановитьНовыйНомер(ПрефиксДляБП);
// Если по какой-то причине УстановитьНовыйНомер() не подходит или требует уточнения,
// можно использовать собственную функцию для генерации номера:
// ЭтотОбъект.Номер = СформироватьНовыйУникальныйНомер(ЭтотОбъект.Метаданные(), ПрефиксДляБП);
КонецЕсли;
КонецПроцедуры
Функция ПолучитьПрефиксОрганизацииБП() и, возможно, СформироватьНовыйУникальныйНомер(), должны быть реализованы нами для получения префикса и следующего уникального номера, гарантируя, что будет использована правильная логика нумерации БП и проверка на уникальность. Метод УстановитьНовыйНомер() объекта документа часто является достаточным.
Подписка на событие ПередЗаписью документа в базе-приемнике (БП) является одним из наиболее
гибких и распространенных способов управления нумерацией для документов, поступающих из обмена. Мы можем создать расширение конфигурации и добавить в него подписку на это событие для всех типов документов, которые требуют такой логики.
Объект.ЭтоНовый()) и пришел ли он из обмена (ОбменДанными.Загрузка).УстановитьНовыйНомер() для объекта документа. Этот метод гарантирует, что будет использована стандартная логика нумерации БП с учетом ее префиксов и контролем уникальности.Критически важно убедиться, что устанавливаемый номер действительно уникален в рамках текущего года или другого периода нумерации. Метод УстановитьНовыйНомер() обычно справляется с этим.
Пример кода для обработчика подписки ПередЗаписью:
Процедура ПередЗаписьюДокументаИзОбмена(Источник, Отказ) Экспорт
// Проверяем, что документ новый и загружается в процессе обмена
Если Источник.ЭтоНовый() И ОбменДанными.Загрузка Тогда
// Получаем метаданные документа для проверки типа
МетаданныеДокумента = Источник.Метаданные();
// Мы можем настроить этот список для конкретных документов,
// для которых требуется сквозная нумерация БП.
СписокДокументовДляНумерацииБП = Новый Массив();
СписокДокументовДляНумерацииБП.Добавить(Метаданные.Документы.РеализацияТоваровУслуг);
СписокДокументовДляНумерацииБП.Добавить(Метаданные.Документы.СчетФактураВыданный);
// Добавляйте другие типы документов по мере необходимости
Если СписокДокументовДляНумерацииБП.Найти(МетаданныеДокумента) <> Неопределено Тогда
// Получаем префикс, соответствующий БП.
// Это может быть префикс текущей организации, настроенный в константе или параметре.
ПрефиксБП = ПолучитьПрефиксОрганизацииБП(); // Ваша функция
// Устанавливаем новый номер для документа.
// Метод УстановитьНовыйНомер() объекта документа автоматически подберет
// следующий уникальный номер с учетом префикса и настроек нумерации БП.
Источник.УстановитьНовыйНомер(ПрефиксБП);
// Если по каким-то причинам стандартный метод не подходит,
// можно реализовать свою логику получения номера.
// Пример: Источник.Номер = ОбщегоНазначения.ПолучитьНовыйНомер(Источник.Метаданные(), ПрефиксБП);
// (Функция ОбщегоНазначения.ПолучитьНовыйНомер может отсутствовать в типовых конфигурациях
// или иметь свою специфику, поэтому часто лучше опираться на стандартный метод объекта
// или собственную надежную функцию).
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Этот подход обеспечивает
высокую гибкость, поскольку мы можем детально контролировать процесс для каждого типа документа, а также использовать все доступные данные объекта для принятия решения о нумерации.
Эта подписка срабатывает, когда система пытается присвоить префикс объекту. В ней мы можем отменить стандартную префиксацию и установить нужный префикс и номер из БП. Однако, мы должны быть
крайне осторожны, чтобы не нарушить общую логику префиксации для других объектов, которые не должны менять свою нумерацию. Этот подход может быть более сложным для универсальной реализации и требует глубокого понимания логики типовой префиксации в вашей конфигурации.
Если в подписке ПрефиксацияОбъектов мы обнаруживаем, что объекту (документу из УНФ) был присвоен префикс УНФ, мы можем программно переопределить его на префикс БП и запросить новый номер. Тем не менее, этот путь может быть сопряжен с большим количеством "подводных камней" из-за сложности универсальной работы с префиксами для всех объектов и потенциального конфликта с типовыми механизмами префиксации. Перед использованием этого метода
тщательно изучите стандартные модули, связанные с префиксацией, например, ПрефиксацияОбъектовБКСобытия или аналогичные.
В Конвертации Данных 3.0 (КД 3.0) мы имеем мощные инструменты для управления данными на этапе их загрузки. Для соответствующих Правил Конвертации Объектов (ПКО) и Правил Конвертации Свойств (ПКС) мы можем задать алгоритмы, которые будут выполняться при создании или изменении объекта в базе-приемнике. Это можно сделать в обработчиках ПередЗагрузкой или ПослеЗагрузки.
ПослеЗагрузки: Этот обработчик выполняется после того, как данные документа уже загружены в объект базы-приемника. Здесь мы можем получить ссылку на объект документа в приемнике.ПослеЗагрузки мы можем сгенерировать новый номер из БП, используя функции платформы для получения нового номера, аналогично подпискам на события.Примерная логика в обработчике ПослеЗагрузки для документа:
// Код в обработчике "ПослеЗагрузки" ПКО для соответствующего документа
// (Например, для РеализацияТоваровУслуг)
// Проверяем, что объект новый (не был найден по GUID) и еще не записан
Если Объект.ЭтоНовый() И ОбменДанными.Загрузка Тогда
// Получаем префикс, который должен быть у документов в БП
// Это может быть взято из параметров обмена, констант или справочников
ПрефиксБП = "БПБП-";
// Устанавливаем новый номер для документа.
// Используем метод объекта для корректной генерации номера.
Объект.УстановитьНовыйНомер(ПрефиксБП);
// Также можно принудительно установить префикс, если это необходимо
// и если УстановитьНовыйНомер() не устанавливает его полностью.
// Например: Объект.Номер = ПрефиксБП + ОбщегоНазначения.ПолучитьНомерБезПрефикса(Объект.Номер);
// Но обычно УстановитьНовыйНомер() сам справляется с префиксом.
КонецЕсли;
Этот подход позволяет сосредоточить логику нумерации непосредственно в правилах обмена, что может быть удобно для администрирования. Однако, он требует навыков работы с КД 3.0 и может усложнить обновление правил при изменениях в типовых конфигурациях. При изменении правил обмена,
необходимо быть особенно внимательными, чтобы не нарушить другие аспекты синхронизации данных.
Реализация новой логики нумерации не ограничивается только установкой нового номера. Мы должны рассмотреть, как это повлияет на общий процесс обмена, особенно если он двусторонний, и как обеспечить уникальность номеров.
При установке любого номера в БП
обязательно нужно выполнять проверку на уникальность. Если номер уже существует, система должна сгенерировать следующий доступный номер. Стандартные механизмы платформы (например, метод УстановитьНовыйНомер() объекта документа) обычно обеспечивают это, автоматически подбирая уникальный номер в рамках текущей нумерации (например, по году, по префиксу). Если же мы реализуем свою функцию получения номера, мы должны
самостоятельно предусмотреть механизм проверки и подбора уникального номера.
Если обмен двусторонний, и документ, получивший новый номер в БП, регистрируется для обратной выгрузки в УНФ, то изменение номера может быть расценено как изменение документа. Это может привести к его повторной регистрации для обмена и, потенциально, к бесконечному циклу изменений. Чтобы этого избежать, мы можем рассмотреть следующие подходы:
НомерВБП. После того как документ из УНФ попадает в БП, получает там новый номер с префиксом БП и записывается, этот номер можно передавать обратно в УНФ и записывать в реквизит НомерВБП исходного документа. Таким образом, в УНФ документ сохраняет свой "родной" номер, но бухгалтер может видеть и номер, присвоенный в БП. При печати документов из БП будет использоваться номер БП. Этот подход позволяет избежать циклов регистрации, так как меняется не основной номер документа УНФ, а лишь дополнительный реквизит, который может быть настроен на одностороннюю синхронизацию (т.е. изменение НомерВБП в УНФ не регистрируется для обратного обмена).Мы помним, что в 1С нумерация документов часто обнуляется с началом каждого года. Это значит, что если мы реализуем механизм, который просто "продолжает" нумерацию, нам нужно учитывать этот фактор.
Важно: стандартный метод УстановитьНовыйНомер() учитывает периодичность нумерации (например, по году), поэтому при его использовании обычно не возникает проблем. Если же мы пишем свою логику, мы должны предусмотреть сброс нумерации в начале нового года. Возможно, потребуется перенумеровать документы за текущий год при внедрении новой логики (что является достаточно радикальным шагом), или указать дату, с которой новая нумерация начинает действовать, чтобы избежать конфликтов с уже существующими номерами.
Для успешной реализации задачи и минимизации рисков мы рекомендуем придерживаться следующих принципов:
Для внесения изменений в типовой функционал
настоятельно рекомендуем использовать механизм расширений конфигурации. Это значительно упростит процесс обновления типовых конфигураций в будущем, так как все наши доработки будут храниться отдельно и не будут затрагивать основные объекты конфигурации. Расширения позволяют добавлять подписки на события, новые реквизиты, формы и модули, не снимая конфигурацию с поддержки.
Прежде чем внедрять любые изменения в рабочую базу,
тщательно протестируйте реализованную логику на копии базы. Проверьте все сценарии:
Слишком сложные алгоритмы в обработчиках событий или правилах обмена могут замедлить процесс обмена данными, особенно при большом объеме документов.
Старайтесь оптимизировать код и избегать избыточных запросов к базе данных внутри циклов обработки документов. Все необходимые параметры (префиксы, списки типов документов) лучше получать один раз перед началом обработки.
Если в УНФ уже есть документы, которые были переданы в БП до реализации новой логики, их номера могут не соответствовать новым правилам. Потребуется принять решение: оставить их как есть, или провести разовую перенумерацию.
Перенумерация — это трудоемкий процесс, который может иметь последствия для уже сформированной отчетности и первичных документов, поэтому к нему следует подходить с особой осторожностью и только после консультации с бухгалтером и руководителем.
Любые изменения в логике нумерации должны быть
согласованы с конечными пользователями (бухгалтерами). Объясните им новую логику, покажите, как она работает, и убедитесь, что они понимают, почему номера документов теперь будут выглядеть иначе.
Реализация сквозной нумерации документов из УНФ в БП — это выполнимая, но требующая внимательного подхода задача. Наиболее надежным и предсказуемым подходом является создание нового номера в базе-приемнике (БП) с использованием стандартных механизмов платформы, таких как событие ПриУстановкеНовогоНомера или подписки на ПередЗаписью, а также применение метода УстановитьНовыйНомер(). Мы рассмотрели основные методы и возможные нюансы, которые помогут нам успешно решить эту задачу и удовлетворить потребности бухгалтера в упорядоченном учете. Помните, что ключевым моментом является баланс между функциональностью, производительностью и удобством сопровождения системы в будущем.