Счёт за доставку пришёл через месяц: Landed Cost Voucher в ERPNext и себестоимость

Landed Cost Voucher в ERPNext добавляет доставку, разгрузку, пошлины и услуги техники к стоимости уже принятой партии: сумма распределяется по позициям приёмки, остатки не двигаются, меняется только оценка. Разберём шаги, формулы распределения, ошибки и пример расчёта.

Что делает Landed Cost Voucher и когда он нужен вместо обычного счёта

Типичная картина: трубы приняли на склад в первых числах месяца, а счёт от перевозчика приходит через месяц. Материал уже списан на объект по закупочной цене, а доставка осталась в расходах «где-то сбоку». Маржа по объекту выглядит лучше, чем есть на самом деле. Landed Cost Voucher (в переводе «ваучер дополнительных расходов») решает именно это: он берёт сумму расходов и добавляет её к стоимости позиций уже оформленной приёмки. В документации ERPNext сказано, что эти затраты включаются в оценочную стоимость (valuation rate) позиции и меняют общую себестоимость.

От обычного счёта он отличается тем, что не заводит долг и не двигает остатки. Количество на складе остаётся прежним, меняется только стоимость. Voucher создаётся к Purchase Receipt или к Purchase Invoice. С приходной накладной всё просто, но у позиции должен быть включён Maintain Stock (или она должна быть основным средством): код v15 подтягивает из приёмки только складские позиции и основные средства. С Purchase Invoice работает, только если в нём включён Update Stock. Именно здесь многие спотыкаются, потому что счёт без складского эффекта в форму не попадёт.

Когда он нужен, а когда нет. Нужен, если у вас складской учёт с приёмкой и вы хотите видеть полную себестоимость партии: поставщик инженерной сантехники, оптовик, подрядчик со складом объекта. Не нужен, если закупка идёт напрямую на объект без приёмки: распределять расходы тогда не на что, и доставку проводят прямым расходом на проект — это другой сценарий. Если вы только выбираете систему, ориентиры по учёту есть в обзоре какую систему учёта выбрать на Linux, а помощь с настройкой мы предлагаем в рамках внедрения ERPNext.

Как оформить voucher к уже принятой приёмке: пошагово

Порядок действий короткий. В модуле Stock создаём новый Landed Cost Voucher, указываем компанию и дату проводки. В таблице приёмок (в v15 она подписана Purchase Receipts, в v16 Vouchers) выбираем нужный Purchase Receipt и нажимаем кнопку получения позиций (Get Items From Purchase Receipts в v15, Get Items в v16): заполнится таблица позиций (Purchase Receipt Items, в v16 Receipt Items). В таблице расходов (Taxes and Charges в v15, Landed Cost в v16) добавляем строки расходов: счёт расходов (Expense Account), описание и сумму. Затем выбираем способ распределения в поле Distribute Charges Based On и проводим документ.

Обязательно проверьте, что после проведения изменилась стоимость, а не количество. Открываете исходный Purchase Receipt, смотрите проводки по учёту запасов (Stock Ledger и бухгалтерские записи) и убеждаетесь, что оценочная стоимость позиций выросла на распределённую сумму. Подписи кнопок и таблиц отличаются между версиями, я сверил их по коду веток version-15 и version-16 и привёл выше обе.

Список действий для снабженца: 1. Получить счёт от перевозчика и выяснить, к каким приёмкам он относится. 2. Создать Landed Cost Voucher, выбрать приёмки и подтянуть позиции. 3. Внести строки расходов: доставка, разгрузка, страховка — каждая отдельной строкой со своим счётом расходов. 4. Выбрать способ распределения и проверить итоговую сумму. 5. Провести документ и сверить стоимость в приёмке. 6. Оформить сам счёт перевозчика и платёж (см. раздел про долг).

Роли в этом процессе стоит развести. Снабженец знает, к каким приёмкам относится доставка, бухгалтер знает, какой счёт расходов использовать. Если voucher создаёт один человек без согласования с другим, строки расходов уходят на «Прочие расходы», и смысл анализа теряется. В основной роли на DocType у Landed Cost Voucher указан Stock Manager, поэтому права на него лучше выдавать осознанно.

По количеству или по сумме: как ERPNext распределяет доставку по позициям

В поле Distribute Charges Based On в коде DocType есть три варианта: по количеству (Qty), по сумме (Amount) и вручную (Distribute Manually). Выбор определяет, кто получит больше доставки. По количеству каждая единица получает одинаковую добавку независимо от цены. По сумме добавка пропорциональна стоимости позиции, и дорогая труба получает больше, чем дешёвый фитинг. Вручную вы задаёте распределение сами, это нужно для нестандартных случаев вроде негабаритного груза.

Пример расчёта, цифры условные. Приёмка из трёх позиций: труба 20 мм, 500 м по 40 ₽; труба 50 мм, 200 м по 150 ₽; фитинги, 300 шт по 20 ₽. Общая стоимость 56 000 ₽, количество единиц 1 000. Доставка 7 000 ₽. | Позиция | Сумма, ₽ | Добавка по количеству | Новая цена (кол-во) | Добавка по сумме | Новая цена (сумма) | |---|---|---|---|---|---| | Труба 20 мм, 500 м | 20 000 | 3 500 ₽ (7,00 за м) | 47,00 | 2 500 ₽ (5,00 за м) | 45,00 | | Труба 50 мм, 200 м | 30 000 | 1 400 ₽ (7,00 за м) | 157,00 | 3 750 ₽ (18,75 за м) | 168,75 | | Фитинги, 300 шт | 6 000 | 2 100 ₽ (7,00 за шт) | 27,00 | 750 ₽ (2,50 за шт) | 22,50 | | Итого | 56 000 | 7 000 ₽ | | 7 000 ₽ | |

Что видно из таблицы. При распределении по количеству фитинг за 20 ₽ получает добавку 7 ₽, то есть 35 % к цене, а труба 50 мм за 150 ₽ — меньше 5 %. Это неверно по сути: перевозят в основном дорогие трубы, но метр трубы и штука фитинга — несопоставимые единицы. Для смешанных единиц измерения я выбираю сумму, для однородного товара в одной единице подойдёт количество. Результат всегда проверяю глазами: сумма добавок должна совпасть с суммой счёта, а новая цена — выглядеть разумно.

Что делать, если у перевозчика отдельный счёт: долг, Payment Entry и Expense Account

Voucher распределяет расходы по стоимости, но не создаёт долг перед перевозчиком. Механика проводок такая: стоимость запасов увеличивается, а встречная запись уходит в кредит счёта из строки расходов (Expense Account, обычно это счёт вида «Расходы, включённые в оценку»). Если счёт перевозчика потом не провести на этот же счёт, кредит так и останется, и статья в отчёте о прибылях и убытках уйдёт в минус. Поэтому в строке voucher я указываю тот счёт расходов, на который бухгалтер проведёт счёт перевозчика, а номер счёта пишу в описание. В v16 в форме появилась таблица Vendor Invoices (Landed Cost Vendor Invoice), где счёт поставщика услуги связывается с voucher напрямую; в v15 её нет.

Закрыть сам расход можно двумя путями. Первый: оформить Payment Entry напрямую, при необходимости вместе с Purchase Invoice с отметкой Is Paid, чтобы расход был виден в учёте. Второй: создать Purchase Invoice от поставщика услуги, то есть перевозчика, и затем платёж по нему. Второй путь правильнее, когда перевозчик выставляет счета регулярно и вам нужна кредиторка по нему. Первый подходит для разовых оплат наличными или с карты. Как оформляется платёж и аванс, мы разбираем в отдельном материале про оплату поставщикам и авансы.

Отдельная ловушка: один и тот же расход нельзя вводить дважды, то есть и в voucher, и в обычном счёте на ту же сумму со своим складским эффектом. Если счёт перевозчика оформлен как Purchase Invoice с Update Stock, а потом ещё раз внесён в voucher, стоимость позиций вырастет дважды. Правило: voucher — для распределения, счёт — для долга, и они не должны оба менять стоимость склада.

Нюансы, на которых спотыкаются: несколько voucher и пересчёт задним числом

Несколько voucher к одной приёмке. В коде v15 запрета на это нет: проверяется только, что строки voucher действительно принадлежат выбранной приёмке. Это удобно: доставка, разгрузка и страховка приходят отдельными счетами в разное время, и каждый оформляется своим документом. Добавочные расходы можно накапливать, только помните, что каждый voucher запускает свой пересчёт стоимости.

Пересчёт задним числом. Когда вы проводите voucher к приёмке месячной давности, система должна пересчитать стоимость остатков и связанных документов. В сообществе описано, что в старых версиях при пересчёте входящая стоимость на целевом складе при перемещении (Stock Transfer) могла не обновляться, а разница уходила в корректировку остатков. Для v15 и v16 это нужно проверять на стенде. В v15 после проведения voucher код вызывает пересчёт последующих складских и бухгалтерских записей, и он выполняется фоновыми заданиями Repost Item Valuation, поэтому после проведения стоит посмотреть, отработала ли очередь.

Таблица «симптом — причина — действие», которой я пользуюсь: | Симптом | Причина | Действие | |---|---|---| | Расходы в P&L ушли в минус | долг перед перевозчиком не отражён | провести счёт перевозчика на тот же Expense Account, что в voucher | | Стоимость на складе не обновилась | пересчёт задним числом не завершён | проверить Repost Item Valuation и очередь воркеров | | Счёт не подтягивается в форму | у счёта не включён Update Stock | использовать приёмку или включить флаг по регламенту | | Позиции не подтянулись из приёмки | у позиции выключен Maintain Stock | проверить карточку Item | | Нужен второй счёт к той же приёмке | расходы пришли в разное время | создать ещё один voucher |

Про настройку, которую стоит знать. В настройках закупок есть опция Set Landed Cost Based on Purchase Invoice Rate: при её включении контроль биллинга в приёмке идёт по количеству, а не по сумме, и создаётся фоновая переоценка. Поле есть в Buying Settings веток v15 и v16; включать его без понимания последствий не стоит.

Как «Труба-Логистик» включила доставку в стоимость партии труб

Условный пример. Поставщик инженерной сантехники «Труба-Логистик», 15 рабочих мест: закупает трубы, фитинги и арматуру на заводах и продаёт монтажным компаниям. Доставка до склада приходила отдельным счётом от перевозчика примерно через месяц после приёмки. До внедрения её относили на общие расходы, поэтому маржа по партиям считалась по закупочной цене. Цифры в этом разборе иллюстративные.

Мы настроили процесс так. Снабженец при приёмке оформляет Purchase Receipt как обычно. Когда приходит счёт перевозчика, бухгалтер вводит его как Purchase Invoice от поставщика услуги. Снабженец создаёт Landed Cost Voucher к приёмке с суммой счёта и распределяет по сумме, потому что в партии разные единицы и разные цены. Для партии из примера выше доставка в 7 000 ₽ распределилась так же, как в таблице расчёта: труба 20 мм подорожала с 40 до 45 ₽ за метр, труба 50 мм со 150 до 168,75 ₽, фитинги с 20 до 22,50 ₽.

Эффект проявился там, где его ждали. Маржа по партии труб 50 мм, которая раньше выглядела на уровне закупки, стала ниже: часть доставки теперь легла на себестоимость. Менеджер, у которого стояла жёсткая скидка по этой группе, пересмотрел цену. Что не вышло с первого раза: бухгалтер ввёл счёт перевозчика с включённым Update Stock, и стоимость выросла дважды, пока это не заметили при сверке. Исправили отменой voucher и счёта и повторным вводом без флага. Показать такой документ можно на демостенде erp-demo.itfresh.ru по запросу.

Как связать эти расходы с рентабельностью объекта и бухгалтерией

Смысл voucher — полная себестоимость. Если после проведения материалы списываются на проект, то в себестоимость объекта попадает и доставка. Но связь с проектом работает только через списание со склада на конкретный проект или объект: сам по себе voucher проект не знает. Поэтому анализ рентабельности объекта строится по цепочке: приёмка, voucher, списание на проект, отчёт по проекту. Если цепочка прервана, доставка так и останется на складе. Расчёт рентабельности объекта целиком — отдельная тема, и мы разбираем её отдельно.

Для бухгалтерии, которая остаётся в 1С, нужно договориться заранее, как передавать эти расходы. Voucher — внутренний документ распределения расходов, он не заменяет первичных документов перевозчика, акта и счёта-фактуры. В 1С должны попасть те же суммы, но как документы по правилам регламентированного учёта. Если вы ищете способ автоматизировать разбор счетов, посмотрите на материал об автоматизации обработки счетов с n8n и ИИ-агентом для 1С.

Ограничения подхода. Voucher не отвечает за налоговый учёт и не определяет, какие расходы правомерно включать в стоимость запасов по российским правилам: это решает бухгалтер. Для складов с терминалами сбора данных приёмка проходит через сканирование, и этот сценарий описан в материале про терминал сбора данных и 1С. Если у вас много мелких доставок, эффект от их распределения может не стоить усилий: тогда допустимо относить их на общие расходы, но решение лучше зафиксировать в учётной политике.

Частые вопросы