Как настроить и организовать учет доставки и постоплаты через транспортную компанию в 1С:Управление торговлей 11

Бизнес-аналитик 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

Работа интернет-магазина с внешними службами доставки (Яндекс Доставка, СДЭК, Boxberry и др.) часто превращается в учетный кошмар. Основные проблемы возникают при оплате при получении (наложенный платеж): заказы долго висят открытыми, менеджеры теряют контроль над сделками, а при возвратах транспортная компания выставляет счета и за доставку, и за обратный путь, что приводит к запутыванию взаиморасчетов и двойному списанию затрат.

В этой статье мы подробно разберем, как правильно организовать документооборот в 1С:Управление торговлей 11 (УТ 11) для работы с транспортными компаниями (ТК). Мы рассмотрим четыре альтернативных метода решения этих проблем — от простых организационных схем до автоматизированных решений.

Проблема 1. Зависание заказов и учет товаров в пути

Когда товар передается в службу доставки, он физически покидает склад продавца, но право собственности к покупателю еще не перешло (особенно при постоплате). Если сразу оформить продажу, то в программе отразится выручка, которой по факту еще нет (клиент может отказаться). Если не оформлять продажу, то товар будет числиться на основном складе, что сделает невозможным проведение корректной инвентаризации.

Проанализируем два способа решения этой проблемы.

Решение А. Использование штатного механизма «Товары в пути»

В современных версиях УТ 11 (начиная с 11.4/11.5) реализован отличный типовой механизм отгрузки без перехода права собственности. Это самый чистый способ учета с точки зрения методологии 1С.

Разберем по шагам, как настроить и использовать этот механизм:

  1. Включение функционала: Переходим в раздел НСИ и администрирование -> Настройка НСИ и разделов -> Продажи -> Оптовые продажи и устанавливаем флаг Статусы реализаций товаров и услуг, а также активируем опцию Отгрузка без перехода права собственности.
  2. Оформление отправки: При передаче заказа в службу доставки менеджер создает документ Реализация товаров и услуг. В поле «Статус» выбирается значение В пути. В этот момент товар списывается с остатков вашего склада (его не будет при инвентаризации), но долг за покупателем еще не признается, и выручка не начисляется. Товар переходит на виртуальный баланс организации как «Товары в пути».
  3. Подтверждение доставки: Как только ТК подтверждает, что клиент забрал и оплатил заказ, статус документа Реализация товаров и услуг меняется на Реализовано. Только в этот момент в системе признается выручка и фиксируется дебиторская задолженность покупателя.
  4. Отказ покупателя: Если клиент отказался от посылки, статус реализации переводится в значение К возврату или документ просто аннулируется (в зависимости от учетной политики), и товар возвращается на склад без сложных сторнирующих операций.

Решение Б. Схема с виртуальным складом ТК

Если по каким-то причинам вы не хотите использовать статусы отгрузки без перехода права собственности, можно применить схему с виртуальным складом. Этот метод часто используется для простоты контроля остатков у конкретного перевозчика.

  1. Создание склада: Создаем в справочнике новый склад с типом «Оптовый» и называем его, например, «Яндекс.Доставка (постоплата)».
  2. Перемещение товара: В момент передачи посылки курьеру оформляется документ Перемещение товаров со склада отправки на склад «Яндекс.Доставка (постоплата)». Товар уходит из остатков реального склада, но вы всегда видите, какой объем номенклатуры сейчас находится на этапе доставки у курьера.
  3. Продажа: После получения отчета от ТК о вручении и оплате, менеджер создает документ Реализация товаров и услуг, где складом-отправителем выступает виртуальный склад «Яндекс.Доставка (постоплата)».
  4. Возврат: Если клиент отказался, оформляется обратное Перемещение товаров со склада ТК на ваш основной склад.

Проблема 2. Разнесение общей суммы оплаты от ТК по заказам

Службы доставки обычно перечисляют денежные средства за доставленные заказы один или два раза в неделю общей суммой по банку. При этом в назначении платежа или в закрывающем реестре приводится список из сотен заказов. Разносить такую выписку вручную на каждый заказ клиента крайне трудозатратно.

Рассмотрим два способа автоматизации и упрощения этого процесса.

Решение А. Использование договора эквайринга

Поскольку постоплата при получении — это фактически прием денег сторонней организацией в вашу пользу, можно настроить эту схему через механизм эквайринга.

  1. Настройка договора: В разделе Импорт/Экспорт / Казначейство создаем Договор эквайринга, где в качестве эквайера (банка) указываем нашу ТК (например, ООО «Яндекс.Доставка»). Указываем процент комиссии за прием платежей.
  2. Оформление оплаты: При отгрузке заказа с постоплатой менеджер оформляет документ Эквайринговая операция. Этот документ сразу закрывает задолженность клиента по заказу, переводя долг на ТК (на транзитный счет/аналитику эквайера). Заказ клиента закрывается и уходит из оперативной работы менеджера.
  3. Поступление денег: Когда от ТК приходит общая сумма на расчетный счет, бухгалтер создает документ Отчет банка по эквайрингу. В этом документе одной кнопкой (или через подбор) заполняются все транзакции, вошедшие в данный реестр. Система автоматически рассчитывает и списывает комиссию ТК на расходы организации, а оставшуюся сумму закрывает на расчетном счете.

Решение Б. Автоматизация разнесения через API или загрузку реестров

Если объемы продаж исчисляются сотнями заказов в день, ручной подбор не поможет. В этом случае требуется написать обработку для автоматического разнесения выписок. Большинство ТК предоставляют реестры в формате Excel/CSV или отдают данные по API.

Ниже приведен пример концепта кода на языке 1С для обработки загрузки реестра платежей из CSV-файла и автоматического создания документов взаимозачета или оплаты:


// Пример процедуры обработки строки реестра от Яндекс.Доставки
Процедура ЗагрузитьСтрокуРеестра(СтруктураДанныхСтроки)
    
    // Поиск заказа клиента по уникальному номеру отправления ТК
    ЗаказСсылка = Документы.ЗаказКлиента.НайтиПоРеквизиту("НомерОтправленияТК", СтруктураДанныхСтроки.ИдентификаторТК);
    
    Если ЗначениеЗаполнено(ЗаказСсылка) Тогда
        // Проверяем наличие неоплаченного остатка по заказу
        ТаблицаРасчетов = РасчетыСКлиентами.ПолучитьОстатокДолга(ЗаказСсылка);
        
        Если ТаблицаРасчетов.Количество() > 0 Тогда
            // Создаем документ ВзаимозачетЗадолженности для переноса долга покупателя на ТК
            НовыйВзаимозачет = Документы.ВзаимозачетЗадолженности.СоздатьДокумент();
            НовыйВзаимозачет.Дата = ТекущаяДата();
            НовыйВзаимозачет.ВариантОформления = Перечисления.ВариантыОформленияВзаимозачета.ПроизвольныйВзаимозачет;
            
            // Заполнение дебитора (конечный клиент)
            НоваяСтрокаДебитор = НовыйВзаимозачет.ДебиторскаяЗадолженность.Добавить();
            НоваяСтрокаДебитор.Партнер = ЗаказСсылка.Партнер;
            НоваяСтрокаДебитор.Контрагент = ЗаказСсылка.Контрагент;
            НоваяСтрокаДебитор.Сумма = СтруктураДанныхСтроки.СуммаОплаты;
            
            // Заполнение кредитора (ТК Яндекс.Доставка по договору купли-продажи/оказания услуг)
            НоваяСтрокаКредитор = НовыйВзаимозачет.КредиторскаяЗадолженность.Добавить();
            НоваяСтрокаКредитор.Партнер = Справочники.Партнеры.НайтиПоНаименованию("Яндекс.Доставка");
            НоваяСтрокаКредитор.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию("ООО Яндекс.Доставка");
            НоваяСтрокаКредитор.Сумма = СтруктураДанныхСтроки.СуммаОплаты;
            
            НовыйВзаимозачет.Записать(РежимЗаписиДокумента.Проведение);
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Проблема 3. Учет возвратов и двойное списание затрат на доставку

Очень часто возникает путаница с затратами:

  1. ТК везет товар клиенту -> выставляет счет за доставку (мы списываем на затраты).
  2. Клиент отказывается от товара.
  3. ТК везет товар обратно -> выставляет счет за возврат (мы снова списываем на затраты).

При некорректной настройке статей расходов в 1С эти суммы могут задваиваться, искажая финансовый результат по направлению продаж.

Выясним причину этой проблемы. Она кроется в использовании одной общей статьи расходов «Транспортные услуги» для всех операций ТК. Нам необходимо разделить эти потоки.

Рассмотрим правильный алгоритм настройки учета затрат:

  1. Разделение статей расходов: Создаем две разные статьи расходов в разделе Финансовый результат и контроллинг -> Статьи расходов:
    • Доставка покупателям (ТК) — тип расходов: «Расходы на продажу», распределяется на финансовый результат по направлению деятельности «Продажи».
    • Логистический брак и возвраты (ТК) — тип расходов: «Прочие операционные расходы», списывается напрямую на себестоимость или на убытки организации (не путать с коммерческими расходами на успешные продажи).
  2. Оформление возврата товара: При фактическом возврате товара от ТК оформляется документ Возврат товаров от клиента. Он восстанавливает товар на складе по его исходной себестоимости.
  3. Отражение услуг ТК: Получив от ТК ежемесячный закрывающий акт, мы разносим его документом Приобретение услуг и прочих активов:
    • Стоимость успешных доставок относим на статью Доставка покупателям (ТК).
    • Стоимость обратной транспортировки по отказам относим на статью Логистический брак и возвраты (ТК).
    Это позволит вам в конце месяца четко видеть в отчете «Доходы и расходы» реальную маржинальность продаж и сумму прямых потерь от возвратов.

Использование встроенного сервиса «1С:Доставка»

Если вы хотите полностью уйти от ручного отслеживания статусов отправлений, рекомендуем настроить встроенный модуль 1С:Доставка. Этот сервис бесплатно интегрирован в УТ 11 и напрямую связывает вашу базу данных с личными кабинетами Яндекс Доставки, СДЭК и других операторов.

Преимущества интеграции:

  1. Автоматическое создание заказов на доставку: Прямо из документа Заказ клиента или Реализация товаров и услуг менеджер в один клик отправляет заявку в личный кабинет ТК.
  2. Синхронизация статусов: Программа в фоновом режиме опрашивает API перевозчика и автоматически меняет статусы документов в 1С (например, с «В пути» на «Доставлено» или «Возвращен на склад»). Это полностью исключает человеческий фактор и необходимость вручную сверять реестры.

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

← На главную