В конфигурации «1С:Управление производственным предприятием 1.3» (УПП), поддерживающей многофирменный учет, пользователи часто сталкиваются с ситуацией, когда в отчете «Карточка счета» по конкретной организации внезапно появляются записи, относящиеся к контрагенту или договору другой фирмы. Это вызывает путаницу в актах сверки и искажает сальдо по счету 60.01.
Такая ситуация не является магией или «шпионажем», как шутят на форумах. Это прямое следствие особенностей архитектуры регистров 1С и механизмов контроля (или их отсутствия) при вводе данных. В этой статье мы подробно разберем причины возникновения такой ошибки и пошагово пройдем путь от обнаружения записи в отчете до исправления первичных данных.
Для начала проанализируем, как строится отчет. «Карточка счета» берет данные из регистра бухгалтерии Хозрасчетный. Каждая запись (проводка) в этом регистре имеет обязательное измерение Организация. Когда мы формируем отчет с фильтром по «Организации №1», система выбирает все записи, где в колонке Организация указано именно это значение.
Однако аналитика (субконто) на счете 60.01 (Контрагенты, Договоры) живет «внутри» этой проводки. Если в проводке по «Организации №1» в качестве субконто выбран договор, принадлежащий «Организации №2», система все равно выведет эту строку в отчет, так как измерение проводки соответствует фильтру. Выясним основные причины, почему такая пересортица становится возможной.
Первое, что мы должны сделать — это использовать метод «провала» в данные. В самой «Карточке счета» выделим проблемную строку и дважды кликнем по ней. Система откроет документ-регистратор, который сформировал эту проводку. Это может быть «Поступление товаров и услуг», «Платежное поручение исходящее» или «Операция (бухгалтерский и налоговый учет)».
В открывшемся документе необходимо выполнить следующие действия:
ДоговорыКонтрагентов имеет владельца — Контрагента, но внутри карточки договора есть обязательный реквизит Организация.Если в движениях мы видим, что в колонке Организация стоит «Фирма А», а в субконто Договоры — договор, закрепленный за «Фирмой Б», значит, мы нашли корень проблемы.
Разберем подробнее, как «чужой» договор мог попасть в документ. Рассмотрим типичные ситуации.
Наиболее часто ошибка возникает при использовании документа Операция (бухгалтерский и налоговый учет). В отличие от типовых документов, где работают программные проверки (при выборе договора система фильтрует их по организации), в ручной операции бухгалтер волен выбирать любые элементы аналитики.
Пример: Бухгалтер копирует операцию прошлого периода. В шапке (в измерении регистра) он меняет организацию на нужную, а в табличной части в субконто оставляет старый договор. Система 1С не выдаст предупреждения, так как это «свободный» ввод проводок.
Если пользователи часто используют механизм «Правая кнопка мыши -> Скопировать» для создания новых документов на базе старых (особенно если старый документ был по другой организации), штатные механизмы очистки аналитики могут не сработать. Если в коде конфигурации или внешних обработках принудительно не прописана очистка договора при смене организации, «чужой» договор сохранится в реквизитах, даже если он скрыт в форме документа из-за фильтров.
В 1С:УПП 1.3 реализована схема работы между собственными организациями. Рассмотрим ситуацию, когда «Организация №2» выступает в роли поставщика для «Организации №1». В этом случае в справочнике Контрагенты создается элемент, который по названию совпадает с вашей второй фирмой.
Проанализируем карточку контрагента. Важно не перепутать:
Организации).Контрагенты).Если вы видите название своей второй организации в карточке счета 60.01, убедитесь, что это не легитимная закупка у собственного филиала. В этом случае все корректно: «Организация №1» должна денег «Организации №2» как внешнему поставщику.
Если данные в УПП загружаются из внешних систем (например, из «1С:Торговля 10.3» или фронт-офиса), правила обмена могут содержать логические ошибки. Посмотрим на типовой сценарий:
В источнике документ был создан по одной организации, а при загрузке в УПП сработал «мэппинг» (сопоставление) на другую организацию по каким-то признакам (например, по ИНН/КПП). При этом договор контрагента мог создаться или подтянуться от старой организации. В итоге в базе УПП получается «гибридный» документ-монстр, где шапка принадлежит одной фирме, а хвост аналитики — другой.
В редких случаях проблема носит чисто технический характер и связана с кэшем или сбоем итогов. Проанализируем состояние регистров с помощью стандартных средств платформы.
Если после проверки документов вы видите, что в самом документе все указано верно, а отчет продолжает показывать «чужие» данные, выполните следующие шаги в режиме Конфигуратора (предварительно создав архивную копию):
Администрирование -> Тестирование и исправление.Также полезно выполнить очистку кэша на рабочем месте пользователя, так как иногда «Карточка счета» может кэшировать результаты предыдущих запросов.
Для предотвращения подобных ситуаций в будущем, рекомендуем:
ОперацияБух).Договор.Организация и Документ.Организация. Для этого можно написать простой запрос в консоли отчетов:
ВЫБРАТЬ
ПоступлениеТоваровУслуг.Ссылка,
ПоступлениеТоваровУслуг.Организация КАК ОргДокумента,
ПоступлениеТоваровУслуг.ДоговорКонтрагента.Организация КАК ОргДоговора
ИЗ
Документ.ПоступлениеТоваровУслуг КАК ПоступлениеТоваровУслуг
ГДЕ
ПоступлениеТоваровУслуг.Организация <> ПоступлениеТоваровУслуг.ДоговорКонтрагента.Организация
Использование этого запроса позволит быстро выявить все документы, ставшие причиной «развала» аналитики в вашей информационной базе.