Подскажите, как в оборотно-сальдовой ведомости по счету отразить заказ покупателя?

Ситуация такая: создаю счет 2310, где указываю субконто "Заказ покупателя" и "Статьи затрат". Затем создаю требование-накладную, где указываю заказ покупателя и провожу ее через счет 2310. В результате в оборотно-сальдовой по счету 2310 отражаются только статьи затрат, а "Заказ покупателя" пустой. По нему нем субконто. При прямом создании проводки все отображается корректно. Как это все исправить?

А с какого перепугу он должен там появляться? кто-то код написал по записи оного в проводку?

Тогда зачем заказ покупателя указывается в требовании-накладной?

без самой конфы тут не разобраться. ну или код проводки кинуть.

(2) наверно, он указывается для структуры подчиненности, как документ-основание.

"А с какого перепугу он должен там появляться? кто-то код написал по записи оного в проводку?"

Так что получается? Код написан под каждую проводку, а не уверсальный? И, получается, для других проводок его нужно писать?

"без самой конфы тут не разобраться. ну или код проводки кинуть."
УПП для Украины 8.2. Имеется ввиду программный код или структура проводки

"наверно, он указывается для структуры подчиненности, как документ-основание."
и в этом скрыт великий смысл для учета :). Хотя тоже нужно, конечно.

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

(5) "И, получается, для других проводок его нужно писать?"
ты не поверишь...
В типовом плане счетов нету заявки покупателя... Вот никто и не удосужился сделать это.. Вот сволочи, правда?

А вообще - заявка в УПП двигается по учетуЗатрат, а не по плану счетов... Это если детализация учёта настроена...

Возможно, достаточно каким-то образом привязать нужную аналитику к счету? Или это не поможет?

"В типовом плане счетов нету заявки покупателя... Вот никто и не удосужился сделать это.. Вот сволочи, правда?"
Не, ну я все понимаю. То, что в стандартной конфе нет Заказа покупателя это да, но формирование и обработка проводок должна работать по одному алгоритму. Я просто сейчас перехожу со своего акса на УПП и иногда финиширую от того, что в аксе я могу ввести еще одну аналитику учета за пять минут и выдать всю инфу по этому срезу, а тут такой гемор. Будем писать. Я был уверен, что это все настраивается чуть-ли не автоматически

"А вообще - заявка в УПП двигается по учетуЗатрат, а не по плану счетов... Это если детализация учёта настроена..."

А можно поподробнее, плиз.

(9)
"формирование и обработка проводок должна работать по одному алгоритму"
Вот оно и работает по этому алгоритму. Который даже не подозревает о таком извращении, как заявка покупателя в плане счетов...

(10) А с этим - на курсы по УПП.

"Вот оно и работает по этому алгоритму. Который даже не подозревает о таком извращении, как заявка покупателя в плане счетов..."

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

У нас заказов за год не много, а к тому же длинный производственный цикл. Поэтому и нужен такой учет

Может у нас действительно изврат и достаточно получать оборотку только по произведенной номенклатуре... (мысли вслух)

(13) "универсальный подход тяжело было сделать?"
Сделай. Пешком на луну тоже можно сходить. ТОлько почему-то не ходят. А почему? Потому что никому не надо.
Так и тут.

(14) в УПП учет ведется на регистрах накопления, а не по плану счетов. То есть движения по счетам формируются из соответствующих движений по оперативным регистрам.

"в УПП учет ведется на регистрах накопления, а не по плану счетов. То есть движения по счетам формируются из соответствующих движений по оперативным регистрам."

У меня в моей системе также

"Пешком на луну тоже можно сходить". Не интересно совсем. Я прекрасно понимаю, что в каждой системе есть свои недостатки, но не нужно язвить по этому поводу, тем более делать из этого кич. Если кто-то специально решил мозги не напрягать и сделал "как проще", однако это не повод говорить, что это хорошо