С переходом на редакцию 3.0 конфигурации 1С:Управление нашей фирмой (УНФ) многие специалисты и пользователи столкнулись с изменениями в механизмах расчета себестоимости и резервирования. Одной из наиболее острых проблем, обсуждаемых в профессиональном сообществе, стала ситуация, когда при проведении документа отгрузки, созданного на основании заказа покупателя, количество списывается корректно, а себестоимость (сумма списания) равна нулю. Это приводит к некорректному отображению валовой прибыли в оперативных отчетах.
В этой статье мы подробно разберем, почему возникает данная ошибка, как изменилась логика работы программы и какие шаги необходимо предпринять для устранения проблемы.
Ситуация выглядит следующим образом: мы оформляем цепочку документов «под заказ». Сначала создаем ЗаказПокупателя, затем на его основании вводим ПриходнуюНакладную (обеспечиваем потребность), и наконец, оформляем РасходнуюНакладную для отгрузки клиенту.
При анализе движений документа РасходнаяНакладная или формировании отчета по валовой прибыли мы обнаруживаем, что:
Проанализируем причины такого поведения системы. В редакции УНФ 3.0 была существенно переработана архитектура регистров накопления и логика работы с запасами. Проблема часто кроется в механизме «обособления» запасов под конкретный заказ.
В новых релизах УНФ (начиная с 3.0) разработчики изменили логику подбора партий при оперативном проведении документов. Если в ПриходнойНакладной явно указан ЗаказПокупателя (в шапке или табличной части), система создает партию товара, жестко привязанную к этому заказу. В регистре накопления Запасы эта запись имеет заполненное измерение «Заказ».
Ошибка, с которой сталкиваются пользователи, часто заключается в несовершенстве алгоритма оперативного списания в конкретных релизах. При проведении РасходнойНакладной система пытается списать товар. Если в алгоритме запроса остатков допущена неточность, программа может искать «свободный» остаток (где измерение «Заказ» пустое), игнорируя тот факт, что товар был зарезервирован именно под текущий документ основания.
В результате система «видит» наличие товара количественно (благодаря контролю остатков или его отсутствию), но не может корректно подобрать партию для списания стоимости, так как нужная партия «спрятана» за измерением заказа.
Важно понимать фундаментальный принцип работы 1С:УНФ: существует два момента расчета себестоимости.
РасчетСебестоимости. Этот механизм полностью пересчитывает движения за месяц, восстанавливает хронологическую последовательность и распределяет затраты более точно.Давайте рассмотрим методы решения и диагностики проблемы.
Прежде чем считать ситуацию программной ошибкой, необходимо исключить пользовательский фактор. Система 1С очень чувствительна к совпадению всех аналитических разрезов.
Проверим документы цепочки:
ПриходнуюНакладную. Убедимся, какая Организация и какое СтруктурноеПодразделение (Склад) указаны. Проверим, заполнен ли ЗаказПокупателя в табличной части или шапке.РасходнуюНакладную. Эти данные должны абсолютно совпадать.Частая ошибка: Товар поступил на «Основной склад» под заказ, а отгружается со склада «Магазин». Даже если заказ один и тот же, партия не будет найдена, и себестоимость будет нулевой (если разрешены отрицательные остатки или списание в минус).
Поскольку оперативный расчет может давать сбои из-за сложности алгоритмов блокировок и резервирования, самым надежным способом получения корректной себестоимости является выполнение регламентной процедуры.
Выполним следующие действия:
ЗакрытиеМесяца за проблемный период.После этого вернемся в отчет по валовой прибыли или движения документа. В 90% случаев, если проблема была в алгоритме оперативного подбора, закрытие месяца исправляет движения, так как использует более прямой алгоритм перебора партий (FIFO) без оглядки на оперативные блокировки.
Чтобы технически подтвердить проблему, нам нужно заглянуть «под капот». Для этого используем стандартную функциональность просмотра движений.
В документе РасходнаяНакладная перейдем к движениям по регистрам. Нас интересует регистр накопления Запасы (или ЗапасыИЗатраты в зависимости от настроек учета).
Проанализируем записи:
0, это подтверждает, что система не нашла партию.Если вы видите нулевую сумму при наличии количества, попробуйте временно отменить проведение ПриходнойНакладной и провести её снова, а затем перезаполнить и провести РасходнуюНакладную. В УНФ критически важна хронология с точностью до секунды. Если Расход был записан раньше Прихода (даже если даты совпадают), себестоимость не спишется оперативно.
Как отмечалось в обсуждении проблемы, данное поведение в УНФ 3.0 признавалось разработчиками как ошибка в ряде релизов (в частности, связанные с частичными отгрузками по заказам и комиссионной торговлей). В более новых версиях (например, начиная с 3.0.4 и выше) механизмы работы с обособленными запасами были доработаны.
Если закрытие месяца не помогает, и хронология соблюдена, рекомендуем:
Если обновление невозможно, а корректные цифры нужны в оперативном режиме до закрытия месяца, можно использовать следующую схему работы:
ПриходнойНакладной не указывать заказ покупателя (принимать на свободный остаток).РезервированиеЗапасов для явной привязки свободного остатка к заказу перед отгрузкой.Проблема нулевой себестоимости в 1С:УНФ 3.0 при работе с заказами чаще всего вызвана либо нарушением хронологии/аналитики, либо ошибкой оперативного алгоритма расчета в конкретном релизе. Главным инструментом «лечения» в УНФ остается процедура Закрытия месяца, которая пересчитывает стоимость запасов по всем правилам управленческого учета, игнорируя временные оперативные ошибки.