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

Фирмы, от лица которых ведется учет (назовем их "своими"), могут вступать во взаимоотношения не только со сторонними контрагентами, но и друг с другом. И если проблема дублирования информации в справочниках "Фирмы" и "Контрагенты" в последних типовых была решена (добавлением справочника "Юр. лица"), то проблема дублирования документов до конца не продумана. Поясню.

В одной базе ведется учет двух фирм: "А" и "Б". Операция продажи товаров фирмой "А" фирме "Б" должна заводиться двумя документами: расходной накладной от имени фирмы "А" в фирму "Б", и приходной накладной в фирме "Б" от фирмы "А". Очевидно, что эти накладные – сиамские близнецы, однако ни в одной из известных мне типовых конфигураций процесс заведения одной из накладных на основании другой не автоматизирован.

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

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

Как это работает?

1. Определяем промежуточный буфер для хранения всех реквизитов документов. Буфером служит объект типа "СписокЗначений". Причем в строковом представлении каждого значения списка хранится идентификатор того реквизита, которому принадлежит наше значение. Табличная часть документа хранится в списке отдельным значением типа "ТаблицаЗначений", идентификаторы колонок которой совпадают с идентификаторами колонок документа.

   Представление этого значения в списке – "Табличная Часть". Пробел посередине критичен для избежания коллизии с возможным реквизитом "ТабличнаяЧасть".

2. Создается глобальная функция глПрочитатьДокумент(Конт), в которую передаётся контекст документа, а возвращаемым значением является список значений, тот самый "буфер".
3. Создается глобальная процедура глЗаполнитьДокумент(Конт,РеквизитыСЗ), в которую передается контекст заполняемого документа, и "буфер" в виде списка значений.

   Результатом выполнения процедуры является изменение контекста документа в соответствии со значениями, взятыми из буфера.

   Код обеих процедур см. в приложенном файле внизу страницы.

Процедура Сформировать()    //Прочитаем документ-шаблон    ДокументСЗ=ГлПрочитатьДокумент(ВыбДокумент);    //Отредактируем изменяемые реквизиты    ДокументСЗ.Установить("Фирма",Константа.ФирмаБ);    ДокументСЗ.Установить("Клиент",Константа.КлиентА);    //Создадим документ-результат    ПН=СоздатьОбъект("Документ.ПриходнаяНакладная");    ПН.Новый();    //Заполним его реквизитами    глЗаполнитьДокумент(ПН,ДокументСЗ);    //Запишем документ    ПН.Записать(); КонецПроцедуры

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