Себестоимость проданного товара SQL запросом

[MBurachkov]

Цитата:

Сообщение от Prophetic

В Кубе привязывается inventTransPosting по полю voucher и InventTransId, а также таблица sales По полю salesid=TransRefId

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

[fed]

Цитата:

Сообщение от Prophetic

Т.е. "правильно" использовать именно таблицу сопоставлений.

Правильно, но долго Тупой запрос по inventTrans быстрее отрабатывает, хотя и выдает неправильные данные для даты из прошлого.
Хотя с другой стороны - если вы все равно данные потом в куб закачиваете, большой беды от замедления выборки в два раза не будет, так что можно всегда от inventSettlement идти...

[Prophetic]

Цитата:

Сообщение от MBurachkov

Посмотрите в настройках куба Axcision связки факт-таблиц и то, какую именно себестоимость хотят получить пользователи.

Хм.. интересно, а реально ли посмотреть SQL-запрос, который Куб генерит?

[sukhanchik]

Цитата:

Сообщение от Prophetic

Да, благодарю. Связывается по inventTable.RecID, если я правильно понял.

Да.

Цитата:

Сообщение от Prophetic

and itr.StatusIssue = 1 or itr.statusIssue=2
and itr.dateFinancial <=@DtEnd

Ээээ.. Вы либо используете финансовую дату и используете StatusIssue = 1, либо используете физическую дату и используете StatusIssue = 1 or StatusIssue = 2.
Иначе - косяк получится. Вы просуммируете все проводки в статусе Отпущено независимо от даты (т.к. 1900-й год заведомо раньше).
Так что в Вашем запросе фразу or itr.statusIssue=2 лучше убрать

[MBurachkov]

Цитата:

Сообщение от Prophetic

Хм.. интересно, а реально ли посмотреть SQL-запрос, который Куб генерит?

В теории, наверное, можно (как минимум через профайлер SQL) но в данном случае вся логика описывается параметрически. Есть факт-таблицы и есть все связки между ними и все фильтры, накладываемые на таблицы + есть описание всех показателей и источники данных для них. На основании этого Axcision формирует sql-запрос.

[Prophetic]

Цитата:

Сообщение от MBurachkov

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

Да, согласен. InventSettlement используется для расчета корректировки в кубе.

[Prophetic]

Цитата:

Сообщение от sukhanchik

Да.


Ээээ.. Вы либо используете финансовую дату и используете StatusIssue = 1, либо используете физическую дату и используете StatusIssue = 1 or StatusIssue = 2.
Иначе - косяк получится. Вы просуммируете все проводки в статусе Отпущено независимо от даты (т.к. 1900-й год заведомо раньше).
Так что в Вашем запросе фразу or itr.statusIssue=2 лучше убрать

Убрал. Получается какая-то безумная сумма, все равно.

[sukhanchik]

А в остальном запрос у Вас остался тот же? А то там суммируется все на конечную дату - т.е. мы имеем сумму товара в ценах себестоимости, который отгрузили с начала времен до 31.12.09.
И почему бы ей не быть безумной?
Возьмите сумму по CustInvoiceTrans.LineAmount за тот же период (сумма отгрузок в ценах продажи) и сравните. Может будет такая же безумная сумма

[MBurachkov]

Цитата:

Сообщение от MBurachkov

В теории, наверное, можно (как минимум через профайлер SQL) но в данном случае вся логика описывается параметрически. Есть факт-таблицы и есть все связки между ними и все фильтры, накладываемые на таблицы + есть описание всех показателей и источники данных для них. На основании этого Axcision формирует sql-запрос.

В Axcision (настройка куба, привязка факта) есть колонка "идентификатор факта" (например, AxF0014) - по нему можно посмотреть запрос в Views MS SQL сервера. (например, KAX_OLAP_Fact_AxF0014_View) - там видно, какой SQL запрос генерится.

[Владимир Максимов]

Не мучайте "птичку" Простейшее решение выглядит так

PHP код:

set @DtBeg = '20091201'
set @DtEnd = '20091231'

select sum(itr.CostAmountPosted + itr.CostAmountAdjustment) 
from inventTrans itr with (nolock)
where itr.dateFinancial between @DtBeg and @DtEnd
    and itr.TRANSTYPE = 0 -- Заказ на продажу 


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

Но вообще-то, MBurachkov задал правильный вопрос. Что именно подразумевается под термином "себестоимость на дату"? И нужно ли определять себестоимость именно на дату?

Так вот, Вам надо знать, по какой мгновенной (скользящей) себестоимости продавался товар без учета накладных расходов (это значение поля CostAmountPosted) или же сумма по некой усредненной себестоимости товара (это сумма CostAmountPosted и CostAmountAdjustment).

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

Если цель - это сравнение с бухгалтерией "на дату", то заранее следует смириться с тем фактом, что с бухгалтерией у Вас НИКОГДА не сойдется. Вне зависимости от выбранного способа расчета. Ну, разве что, Вы будете суммировать напрямую бух.проводки под чутким руководством бухгалтера

[MBurachkov]

Цитата:

Сообщение от Владимир Максимов

Не мучайте "птичку" Простейшее решение выглядит так

PHP код:

set @DtBeg = '20091201'
set @DtEnd = '20091231'

select sum(itr.CostAmountPosted + itr.CostAmountAdjustment) 
from inventTrans itr with (nolock)
where itr.dateFinancial between @DtBeg and @DtEnd
    and itr.TRANSTYPE = 0 -- Заказ на продажу 


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

Но вообще-то, MBurachkov задал правильный вопрос. Что именно подразумевается под термином "себестоимость на дату"? И нужно ли определять себестоимость именно на дату?

Так вот, Вам надо знать, по какой мгновенной (скользящей) себестоимости продавался товар без учета накладных расходов (это значение поля CostAmountPosted) или же сумма по некой усредненной себестоимости товара (это сумма CostAmountPosted и CostAmountAdjustment).

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

Если цель - это сравнение с бухгалтерией "на дату", то заранее следует смириться с тем фактом, что с бухгалтерией у Вас НИКОГДА не сойдется. Вне зависимости от выбранного способа расчета. Ну, разве что, Вы будете суммировать напрямую бух.проводки под чутким руководством бухгалтера

Если я правильно понял вопрос - то задача не просто написать запрос на вычисление себестоимости - но и при этом совпасть с конкретными цифрами в уже существующем отчете. А для этого нужно понять, по какому алгоритму существующий отчет вытаскивает данные. Отсюда и куча наводящих вопросов и советов
PS "Чтобы правильно задать вопрос, нужно знать бОльшую часть ответа." (С) Р. Шекли

А почему с б/у не сойдется, если брать данные из settlement??? Они полностью совпадают с проводками в ГК

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

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

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

Цитата:

Сообщение от Владимир Максимов

Что именно подразумевается под термином "себестоимость на дату"? И нужно ли определять себестоимость именно на дату?

Для неискушенного Аксаптой бухгалтера - это стоимость запасов именно на ту дату именно в тот момент. Другое дело - что в Аксапте сведение данных по ГК и запасам в плане себестоимости - вещь нетривиальная и хранит в себе ряд допущений и ограничений.

Цитата:

Сообщение от Владимир Максимов

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

... которые (накладные расходы) м.б. сделаны вне (позже) рассматриваемого периода.

Цитата:

Сообщение от Владимир Максимов

Если цель - это сравнение с бухгалтерией "на дату", то заранее следует смириться с тем фактом, что с бухгалтерией у Вас НИКОГДА не сойдется. Вне зависимости от выбранного способа расчета.

Я бы не стал так категорично утверждать.
Если выполнить ряд условий, а именно:
1. Рассматривать только те товары, которые разносятся в ГК (галка Разносить финансовые запасы в группе складских моделей)
2. Рассматривать только те бух счета, на которые падают только складские операции
3. Рассматривать коррекции по складу (CostAmountAdjustment) по InventSettlement
4. Не делать корректировки / накладные расходы спустя более [месяца] периода, в который закрывается склад
5. Рассчитывать стоимость только на конец даты, на которую была проведена корректировка или закрытие склада
6. Рассматривать только операции по финансовой дате в заданном периоде.
(список, возможно, не исчерпывающий - но основные моменты в нем определены)
То суммарное исходящее сальдо по всем складам и товарам из п.1 будет совпадать (при отсутствии косяков в данных) с суммарным исходящим сальдо по бух счетам из п.2.
Грубо говоря - отчет InventTurnover_RU (только если его считать не по физической дате как он есть, а по финансовой и без учета операций Отпущено/Получено) по исходящему сальдо будет совпадать с итоговым сальдо по товарным счетам.

При наложении дополнительных ограничений (без учета журналов переноса или наоборот с их учетом, но тогда с их отражением в ГК) можно и обороты выверить.

[Владимир Максимов]

Насчет "в тех проводках, которые учитывать" - это я к тому, что дополнительные условия, например, по StatusIssue - бессмысленное. Если StatusIssue отличен от 1, то и себестоимости еще нет. Она собственно и проставляется только в момент проведения. Запрос (возможно!) захватит "лишние" проводки, но они не повлияют на результат, поскольку в них еще нет себестоимости.

Почему с бухгалтерией не сойдется никогда? По той причине, что, в общем случае, слишком велико количество условий, которые надо учесть, чтобы "очистить" себестоимость складской проводки до состояния себестоимости в КГ. Причем способ "очистки" крайне громоздкий, как следствие, чрезвычайно медленный.

Как правило, останавливаются на каком-то компромисе. Неких допущениях. Что-то вроде: вот этого у нас никогда не будет, а если будет, учтем вручную. Если действительно "этого" нет, то все сходится. А если "это" появляется, то начинаются долгие и мучительные поиски причин расхождения, поскольку про "допущения" все уже благополучно забыли...

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

Насчет "в тех проводках, которые учитывать" - это я к тому, что дополнительные условия, например, по StatusIssue - бессмысленное. Если StatusIssue отличен от 1, то и себестоимости еще нет.

А... в этом смысле - согласен. Сразу не осознал.

Цитата:

Сообщение от Владимир Максимов

Почему с бухгалтерией не сойдется никогда? По той причине, что, в общем случае, слишком велико количество условий, которые надо учесть, чтобы "очистить" себестоимость складской проводки до состояния себестоимости в КГ. Причем способ "очистки" крайне громоздкий, как следствие, чрезвычайно медленный.
Как правило, останавливаются на каком-то компромисе. Неких допущениях. Что-то вроде: вот этого у нас никогда не будет, а если будет, учтем вручную. Если действительно "этого" нет, то все сходится. А если "это" появляется, то начинаются долгие и мучительные поиски причин расхождения, поскольку про "допущения" все уже благополучно забыли...

Согласен.

[Prophetic]

Всем спасибо за просветление.