При работе в программах нового поколения, таких как 1С:Комплексная автоматизация 2 или 1С:ERP, многие специалисты сталкиваются с неожиданным поведением системы при распределении оплат. Типичная ситуация: у нас есть крупный клиент (сетевая структура или холдинг), состоящий из головной организации и нескольких подчиненных магазинов (точек доставки). Мы отгружаем товары на конкретные магазины, а оплату получаем централизованно от головной компании.
В регламентированном учете мы видим логичную картину: продажи отражаются по дебету счета 62.01, а оплата поступает по кредиту счета 62.02 и зависает там в качестве аванса, несмотря на то, что сумма долга на счете 62.01 полностью покрывает этот платеж. Давайте подробно разберем, почему так происходит, как устроена внутренняя архитектура программы и какие существуют способы решения этой проблемы.
В отличие от классической «1С:Бухгалтерии», где проводки по счетам 62.01 и 62.02 формируются непосредственно по субконто «Контрагенты» и «Договоры», в 1С:Комплексная автоматизация 2 логика регламентированного учета полностью подчинена оперативному (управленческому) контуру.
Все движения по расчетам с клиентами фиксируются в регистре накопления РасчетыСКлиентами. Ключевым разрезом этого регистра является измерение АналитикаУчетаПоПартнерам. Это специальный внутренний ключ (справочник), который жестко связывает между собой триаду реквизитов:
Когда мы проводим документ РеализацияТоваровУслуг, система делает запись в оперативный регистр по следующей аналитике:
Организация + Партнер Магазин 1 + Головной контрагент
Когда же на расчетный счет поступает платеж через документ ПоступлениеБезналичныхДенежныхСредств, в качестве плательщика указывается головная организация, а в качестве партнера — Головной партнер. Аналитика в регистре формируется так:
Организация + Головной партнер + Головной контрагент
Для системы эти две записи представляют собой абсолютно разные объекты расчетов, поскольку у них отличаются партнеры (Партнер Магазин 1 и Головной партнер). Программа считает, что магазин все еще должен нам деньги, а головной офис просто прислал свободный аванс. В итоге проводки по регламентированному учету послушно отражают эту картину: долг остается на 62.01, а оплата уходит на 62.02.
Давайте посмотрим на упрощенную схему запроса к остаткам взаиморасчетов, который делает система при попытке распределить платеж:
ВЫБРАТЬ
Остатки.АналитикаУчетаПоПартнерам КАК Аналитика,
Остатки.СуммаОстаток КАК Сумма
ИЗ
РегистрНакопления.РасчетыСКлиентами.Остатки КАК Остатки
ГДЕ
Остатки.АналитикаУчетаПоПартнерам.Партнер = &ПартнерИзОплаты
Поскольку в параметре запроса передается Головной партнер, система физически не «видит» долги, числящиеся за партнером Магазин 1.
---
Если перед нами стоит задача сделать так, чтобы все оплаты закрывались полностью автоматически при проведении банковской выписки, без ручного вмешательства и создания дополнительных документов корректировки долга, нам нужно изменить подход к заполнению документов реализации.
Вместо того чтобы плодить множество партнеров-магазинов в качестве «Клиентов» в шапке документов продажи, мы будем использовать единую аналитику расчетов.
Рассмотрим этот алгоритм по шагам:
РеализацияТоваровУслуг в поле Клиент (Партнер) мы выбираем Головной партнер.Головной контрагент.Контрагент магазин 1) со своим уникальным адресом доставки и КПП.Почему этот способ является оптимальным?
Головной партнер), система мгновенно распределяет платежи и закрывает дебиторскую задолженность в момент проведения банковской выписки.ТОРГ-12, УПД и Счет-фактура реквизиты будут заполнены идеально в соответствии с требованиями законодательства: «Покупатель» — головная компания, «Грузополучатель» — магазин с его собственным КПП и адресом.Выручка и себестоимость продаж) и настраиваем группировку или отбор по реквизиту Грузополучатель или Адрес доставки.---
Если по каким-то причинам (например, из-за специфических требований управленческого учета) вам жизненно важно указывать в поле Клиент именно партнера-магазина, в системе предусмотрен специальный альтернативный механизм работы с торговыми сетями.
Проанализируем его настройку:
Головным контрагентом.Партнер магазин 1, Контрагент = Головной контрагент.Головной контрагент, Получатель (Покупатель) = Головной партнер.Важная особенность распределения оплат (нюанс версий 2.4 и 2.5):
В актуальных версиях программных продуктов линейки ERP и Комплексной автоматизации разработчики 1С изменили логику автоматического распределения. Даже при включенном флаге дочерних партнеров, автоматический зачет при простом проведении выписки может не сработать. Это сделано для того, чтобы система не путала долги разных магазинов по своему усмотрению.
Чтобы схлопнуть взаиморасчеты, нам потребуется воспользоваться встроенным рабочим местом Помощник зачета оплат (его можно открыть напрямую из формы документа реализации или общего списка документов продаж). Помощник увидит, что на головном договоре висит свободный аванс от головной организации, и предложит перенести его на конкретную реализацию дочернего магазина, автоматически сформировав документ ВзаимозачетЗадолженности.
---
Мы выяснили, что поведение программы обусловлено логикой связывания партнеров и контрагентов. При выборе пути автоматизации рекомендуем придерживаться следующего правила:
Помощник зачета оплат в конце отчетного периода.