Консигнация

Здравствуйте.
Подскажите, в какой учетной системе есть учет консигнационной торговли ?
Системы интересуют фриварные или с доступной демоверсией, и желательно попроще.
Нужно в своей самописке сделать такой учет, по общепринятым методикам.
Особенно интересует методика расчета доходности: если используется партионный учет, то как привязывать расходные накладные к еще не существующим приходам, или может быть средние цены по какой-то особой методике считаются, и т.п.

1. О каком учете идет речь - о бухгалтерском и налоговом, или о каком-то еще?
2. Учет на чьей стороне - комитента? комиссионера или обоих?

Для торговой организациии, которая выступала и комитентом, и комиссионером, мне приходилось настраивать системы 1С:УПП и ИНФИН, при этом обе изначально имели не всё, что нам было нужно. С УПП пришлось значительно труднее, чем с ИНФИНом, про нюансы можно рассказывать долго и нудно. По поводу "общепринятых методов" могу сказать, что в ряде очень важных вопросов таких методов просто нет. Я приведу только один пример, который это иллюстрирует.

Часто информация от комиссионера до комитента о том, что какая-то часть товара продана и/или отгружена, доходит не сразу, а с некоторой периодичностью, с которой предоставляется отчет комиссионера, на составление которого, доставку и обработку требуется еще некоторое время. Соответственно, товар может быть отгружен в одном периоде, а информация о том, что он отгружен, придет со значительной задержкой. Между тем, НК предписывает начислять НДС по отгрузке. Сумма, которую уплачивает покупатель, распадается на две компоненты - на продажную стоимость, заявленную комитентом, и на комиссионное вознаграждение, исчисляемое в процентах от суммы реализации. С комиссионным вознаграждением все относительно легко и просто, потому что НДС на него начисляется комиссионером, у которого изначально появляется информация о продаже. А вот со второй компонентой всё значительно сложнее. Комиссионер должен предоставлять информацию комитенту об откгрузках с такой скоростью, чтобы комитент успел начислить НДС по отгрузке на основании не выписанной им счет-фактуры, а на основании счет-фактуры, которую выписывает другое юрлицо. Если комитент с комиссионером не смогли наладить оперативное взаимодействие для выпонения требований НК по НДС, у комитента возникает налоговый риск.

Это только один нюанс из великого множества. В общем-то, не совсем понятно, почему задача решается с помощью самописки. Формы РСБУ-отчетности тоже она будет формировать, вести налоговый очет по ОС и т.д. и т.п? Все-таки я бы порекомендовал воспользоваться готовой системой, которую нужно поднастроить под вашу специфику.

Игорь_М
Подскажите, в какой учетной системе есть учет консигнационной торговли ?

в большинстве систем в том или ином виде можно настроить (именно настроить, а не дорабатывать). но с бухучетом по российским (украинским) стандартам могут быть проблемы, но это не только к консигнации относится.

Игорь_М
Нужно в своей самописке сделать такой учет, по общепринятым методикам. Особенно интересует методика расчета доходности: если используется партионный учет, то как привязывать расходные накладные к еще не существующим приходам, или может быть средние цены по какой-то особой методике считаются, и т.п.

извините, а как вы его умудряетесь продать по консигнации, не имея на складе?
цитата из википедии:
"Консигнация — форма комиссионной продажи товара, при которой его владелец (консигнант) передает комиссионеру товар для реализации со склада комиссионера. При этом товар, поступивший на склад комиссионера остается собственностью консигнанта до момента его реализации."

Garya
1. О каком учете идет речь - о бухгалтерском и налоговом, или о каком-то еще? 2. Учет на чьей стороне - комитента? комиссионера или обоих? ...

Учет подразумевается управленческий, для владельцев бизнеса. У бухгалтеров, к счастью, вопросов нет.
Схема работы у нас такая:
Комитент отгружает нам контейнер товара по накладной на перемещение. У нас этот товар находится на ответственном хранении по ценам, назовем их учетными складскими.
Мы, комиссионер, оптом торгуем этим товаром.
За каждый рабочий день мы снимаем отчет по продажам за этот день, и высылаем его комитенту.
Комитент через некоторое время высылает нам оригиналы документов (счет-фактура, товарная накладная) датой этого отчета о продажах и с количеством, равным нашим продажам. Но цену в этой приходной накладной и счет-фактуре он ставит уже не учетную складскую, а другую, ниже. И соответственно на основе этих, как-бы виртуальных, приходных накладных образуется наш долг перед комитентом.
Цены в этих приходных накладных комитент изменяет обычно с началом нового месяца.

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

P.S. Бухгалтерский и налоговый учет ведется в 1С-бухгалтерии, а оперативный в самописке. У нас, в регионах, почти у всех так. По крайней мере в местных компаниях, без головы в Москве.

Игорь_М

Комитент отгружает нам контейнер товара по накладной на перемещение. У нас этот товар находится на ответственном хранении по ценам, назовем их учетными складскими. Мы, комиссионер, оптом торгуем этим товаром. За каждый рабочий день мы снимаем отчет по продажам за этот день, и высылаем его комитенту. Комитент через некоторое время высылает нам оригиналы документов (счет-фактура, товарная накладная) датой этого отчета о продажах и с количеством, равным нашим продажам. Но цену в этой приходной накладной и счет-фактуре он ставит уже не учетную складскую, а другую, ниже. И соответственно на основе этих, как-бы виртуальных, приходных накладных образуется наш долг перед комитентом. Цены в этих приходных накладных комитент изменяет обычно с началом нового месяца. Основная проблема у нас связана с расчетом доходности. Получается, что приходные накладные находятся на оси времени позже расходных. И эти виртуальные приходные накладные не формируют складские остатки, а только сальдовку. Для расчета доходности используем метод средних цен, цену берем из накладных на перемещение. Все понимают, что это неправильно, но другую методику предложить некому, уже больше 10 лет так.

Вы путаете документы товарные (приход, расход, перемещение) и финансовые.
В большинстве случаев партии считаются в разрезе товарных документов (серийные номера, лоты и тп). То есть всегда можно увидеть, из какого прихода списан товар при продаже.
Финансовые документы определяют себестоимость товаров, а точнее суммы, которые проходят по фин счетам и связаны с товарными операциями.
К одной товарной операции прихода (покупки) может быть связано несколько финансовых документов. Например купили за 10 рублей - создали записи стоимости на 10 рублей. Пришел счет на транспортные расходы, их распределили по товарам - получилось, что на эту позицию пришлось 2 рубля - добавили еще одну запись себестоимости (можно изменить существующую запись, но по многим причинам изменять хуже) - итого 12 рублей. А потом получили от поставщика скидку (кредит-ноту), по которой мы ему должны меньше денег, чем думали раньше - например на 1,5 рубля. И делаем еще одну запись, уменьшающую себестоимость - итого себестоимость позиции 10,5 рублей.
И потом на основе этих вновь созданных операций себестоимости первичного прихода пересчитываются и создаются записи себестоимости для связанных товарных операций - перемещений, списаний (продаж).
Это стандартный механизм работы с себестоимостью, реализованный в большинстве нормальных систем. Разумеется, есть нюансы (товарная операция в закрытом периоде, товар продан/списан в производство/списан на создание ОС), которые усложняют картину, но общие принципы такие, как я описал.
Со средней себестоимостью все менее наглядно, так как расчеты более сложные. Поэтому при прочих равных лучше использовать ФИФО - его проверять и вылавливать ошибки проще.

s_ustinov
И потом на основе этих вновь созданных операций себестоимости первичного прихода пересчитываются и создаются записи себестоимости для связанных товарных операций - перемещений, списаний (продаж).

А в этих записях себестоимости для продаж, итоговая, рассчитанная себестоимость закупки хранится ? Если да, то значить при любой дополнительной проводке, влияющей на себестоимость закупки, эти записи для продаж нужно пересчитывать ?

Игорь_М

s_ustinov И потом на основе этих вновь созданных операций себестоимости первичного прихода пересчитываются и создаются записи себестоимости для связанных товарных операций - перемещений, списаний (продаж). А в этих записях себестоимости для продаж, итоговая, рассчитанная себестоимость закупки хранится ? Если да, то значить при любой дополнительной проводке, влияющей на себестоимость закупки, эти записи для продаж нужно пересчитывать ?

А это уже особенности реализации.
В большинстве систем себестоимость продажи хранится в виде нескольких записей. То есть когда нам надо изменитьсебестоимость продажи - добавляется новая строка с плюсом или минусом.
А пересчет...
Конкретный алгоритм пересчета может быть разным.
В навике сделано так:
Появился новый документ, который изменил себестоимость покупки. Создается еще одна запись себестоимости. Регулярно запускается задание "пересчет себестоимости товарных операций". Задание находит все вновь созданные записи стоимости и создает дополнительные записи стоимости для связанных товарных операций.
Вообще это нормально описано в документации. У меня в архиве где-то валяется, но быстрее поискать в инете.
Например
http://www.navisioninfo.com/whitepapers/Navision%20Costing%20Technical%20White%20Paper.htm
у меня было на русском, но сразу найти не смог.

s_ustinov,

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

Игорь_М
s_ustinov, То-есть в моем примере нужно использовать два партионных учета ? Один для распределения товарных остатков. Другой для распределения себестоимости, т.е. для связывания счет-фактур с накладными перемещения от комитента комиссионеру ?

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

s_ustinov,

Вот я и хочу посмотреть в других системах, как решена эта задача