Как рассчитать срок окупаемости партии товаров в днях в 1С?

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

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

Разберем логику построения такого расчета, а также несколько способов программной реализации задачи на платформе 1С:Предприятие.

Экономическая логика и постановка алгоритма

Для вычисления количества дней окупаемости нам потребуются следующие исходные данные:

  1. Дата начала отсчета: дата оприходования партии или дата поступления контейнера на склад (ДатаПриходаКонтейнера).
  2. Целевая сумма затрат: совокупные расходы на закупку и сопутствующие затраты (ИтогоВсехСуммаРасходов).
  3. Хронология продаж: список документов реализации с суммами продаж и датами по номенклатурным позициям, входящим в состав анализируемой партии.

Алгоритм расчета строится пошагово:

  1. Выбираем все продажи номенклатуры из партии, начиная с даты оприходования.
  2. Группируем продажи по дням и суммируем выручку за каждый день.
  3. Вычисляем нарастающий итог выручки по дням.
  4. Фиксируем первую дату, в которую нарастающий итог становится больше или равен целевой сумме расходов.
  5. Вычисляем разницу в днях между датой оприходования и найденной датой окупаемости с помощью функции РАЗНОСТЬДАТ.

Способ 1. Расчет через постобработку выборки на встроенном языке

Проанализируем наиболее простой и производительный способ для небольших и средних объемов данных — получение посуточных продаж запросом с последующим вычислением накопительного итога в цикле.


// Запрос для получения посуточных продаж товаров из партии
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ПродажиОбороты.ПериодДЕНЬ КАК ПериодДень,
    |	СУММА(ПродажиОбороты.СтоимостьОборот) КАК СуммаВыручки
    |ИЗ
    |	РегистрНакопления.Продажи.Обороты(&ДатаПрихода, &КонецПериода, Авто, Номенклатура В (&МассивТоваров)) КАК ПродажиОбороты
    |СГРУППИРОВАТЬ ПО
    |	ПродажиОбороты.ПериодДЕНЬ
    |УПОРЯДОЧИТЬ ПО
    |	ПериодДень ВОЗРАСТАЮЩЕ";

Запрос.УстановитьПараметр("ДатаПрихода", ДатаПриходаКонтейнера);
Запрос.УстановитьПараметр("КонецПериода", ТекущаяДата());
Запрос.УстановитьПараметр("МассивТоваров", СписокТоваровПартии);

Выборка = Запрос.Выполнить().Выбрать();

НакопленнаяСумма = 0;
ДатаОкупаемости = Неопределено;

Пока Выборка.Следующий() Цикл
	НакопленнаяСумма = НакопленнаяСумма + Выборка.СуммаВыручки;
	Если НакопленнаяСумма >= ИтогоВсехСуммаРасходов Тогда
		ДатаОкупаемости = Выборка.ПериодДень;
		Прервать;
	КонецЕсли;
КонецЦикла;

Если ЗначениеЗаполнено(ДатаОкупаемости) Тогда
	КоличествоДнейОкупаемости = (НачалоДня(ДатаОкупаемости) - НачалоДня(ДатаПриходаКонтейнера)) / 86400;
Иначе
	// Партия еще не окупилась
	КоличествоДнейОкупаемости = Неопределено;
КонецЕсли;

Способ 2. Расчет накопительного итога целиком на языке запросов 1С

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


ВЫБРАТЬ
	ПродажиПоДням.ПериодДень КАК ПериодДень,
	ПродажиПоДням.СуммаДня КАК СуммаДня
ПОМЕСТИТЬ ВТ_ПродажиПоДням
ИЗ
	(ВЫБРАТЬ
		НАЧАЛОПЕРИОДА(Продажи.Период, ДЕНЬ) КАК ПериодДень,
		СУММА(Продажи.Стоимость) КАК СуммаДня
	ИЗ
		РегистрНакопления.Продажи КАК Продажи
	ГДЕ
		Продажи.Номенклатура В(&МассивТоваров)
		И Продажи.Период >= &ДатаПрихода
	СГРУППИРОВАТЬ ПО
		НАЧАЛОПЕРИОДА(Продажи.Период, ДЕНЬ)) КАК ПродажиПоДням
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Т1.ПериодДень КАК ПериодДень,
	СУММА(Т2.СуммаДня) КАК НакопленнаяВыручка
ПОМЕСТИТЬ ВТ_НакопительныйИтог
ИЗ
	ВТ_ПродажиПоДням КАК Т1
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ПродажиПоДням КАК Т2
		ПО Т1.ПериодДень >= Т2.ПериодДень
СГРУППИРОВАТЬ ПО
	Т1.ПериодДень
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	МИНИМУМ(ВТ_НакопительныйИтог.ПериодДень) КАК ДатаОкупаемости,
	РАЗНОСТЬДАТ(&ДатаПрихода, МИНИМУМ(ВТ_НакопительныйИтог.ПериодДень), ДЕНЬ) КАК ДнейДоОкупаемости
ИЗ
	ВТ_НакопительныйИтог КАК ВТ_НакопительныйИтог
ГДЕ
	ВТ_НакопительныйИтог.НакопленнаяВыручка >= &ИтогоВсехСуммаРасходов

Способ 3. Вычисление нарастающего итога средствами СКД

В отчетах на базе Системы компоновки данных (СКД) соединение таблицы самой с собой может приводить к избыточной нагрузке на СУБД. В СКД расчет нарастающего итога реализуется через встроенные функции выражений на вкладке Поля итога или Вычисляемые поля.

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

ВычислитьВыражение("Сумма(СуммаВыручки)", , , "Первая", "Текущая")

Далее в пользовательском макете или постобработке результата отчета фиксируется день, где полученный накопительный итог превышает плановую себестоимость партии.

Пограничные случаи и методологические нюансы

При реализации расчета срока окупаемости важно учитывать особенности торгового учета:

  1. Возвраты от покупателей: Документы возврата уменьшают накопленную выручку. Если возврат проведен задним числом, расчетная точка окупаемости может сместиться. В запросах к регистрам продаж суммы возвратов должны уменьшать оборот (учитываться со знаком минус).
  2. Недостижимость точки окупаемости: Если часть товаров списана по браку, уценена ниже себестоимости или долго лежит без движения, сумма расходов может быть не покрыта. В программном коде обязательно должна быть предусмотрена обработка ситуации, когда ДатаОкупаемости = Неопределено, с выводом процента покрытия расходов вместо дней.
  3. Учет отсрочки платежа: Отражение реализации фиксирует переход права собственности, но не факт прихода денег. Если бизнес требует расчета по кассовому методу (фактическая оплата), источником данных должны выступать регистры взаиморасчетов с покупателями, а не регистр продаж.
← На главную