Обороты и остатки номенклатуры по счетам

[Михаил Андреев]

Цитата:

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

Правильно.

ИМХО, судя по форме, такой отчёт строится по InventSum (остатки), InventTrans и, возможно, InventTransPosting. Для остатков на дату где-то на форуме было обсуждение классов. А вот профильтровать номенклатуры по счетам ГК можно легко, если для всех операций по одной группе номенклатуры (или самой номенклатуре) прописывается один счёт (обычно так и делают), в этом случае можно взять счёт по любой операции из настроек разноски и профильтровать номенклатуры, у которых в настройке разноски указан этот счёт. Только это не будет выверкой, как ни странно, так как нужно сверять суммы по LedgerTrans и InventTrans.

А вот если умудрились прописать разные счета ГК для разных операций в разноске для одной группы номенклатуры...

[pyramid]

Цитата:

Сообщение от Михаил Андреев

А вот профильтровать номенклатуры по счетам ГК можно легко, если для всех операций по одной группе номенклатуры (или самой номенклатуре) прописывается один счёт (обычно так и делают), в этом случае можно взять счёт по любой операции из настроек разноски и профильтровать номенклатуры, у которых в настройке разноски указан этот счёт.

А корректно ли использовать настроенный в профилях разноски счёт? Например, если пользователь изменит счёт в середине отчетного периода, то наш отчёт станет неверен!

[Михаил Андреев]

Цитата:

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

А корректно ли использовать настроенный в профилях разноски счёт? Например, если пользователь изменит счёт в середине отчетного периода, то наш отчёт станет неверен!

Конечно, будет неверен. Потому я и подчеркнул это условие.

[coolibin]

Цитата:

Сообщение от Михаил Андреев

ИМХО, судя по форме, такой отчёт строится по InventSum (остатки), InventTrans и, возможно, InventTransPosting. Для остатков на дату где-то на форуме было обсуждение классов.

При такой постановке задачи классы inventSum* не очень помогут. Отчет придется строить по InventTrans inner join InventTransPosting. Фильтровать по номеру счета из InventTransPosting . Остаток на начало считать как сумму всех оборотов от царя гороха.

[Михаил Андреев]

Цитата:

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

При такой постановке задачи классы inventSum* не очень помогут. Отчет придется строить по InventTrans inner join InventTransPosting. Фильтровать по номеру счета из InventTransPosting . Остаток на начало считать как сумму всех оборотов от царя гороха.

Насчёт фильтрации по InventTransPosting согласен. Но, если у заказчика такой бардак, то это не поможет

А вот насчёт остатков. ИМХО, лучше использовать всё-таки InventSum - можно сразу отсечь все старые закрытые остатки и их не суммировать.

[coolibin]

Цитата:

Сообщение от Михаил Андреев

ИМХО, лучше использовать всё-таки InventSum - можно сразу отсечь все старые закрытые остатки и их не суммировать.

Как отсечь старые закрытые остатки с помощью inventSum?

[ZVV]

Цитата:

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

Как отсечь старые закрытые остатки с помощью inventSum?

Птичка есть специальная. Closed.

[Михаил Андреев]

Цитата:

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

Как отсечь старые закрытые остатки с помощью inventSum?

Например, по полю LastUpdDatePhysical и Closed.

[coolibin]

Цитата:

Сообщение от Михаил Андреев

Например, по полю LastUpdDatePhysical и Closed.

Ну да, это понятно. Я-то имел в виду семейство классов inventsum*, а не таблицу.

Что же касается указанных полей из InventSum - все бы хорошо, но и они не помогут гарантированно отсеять все лишние номенклатуры. Например, взять случай, когда одна и та же номенклатура на 10-м уже закрыта, а на 08-м еще болтается.

[Михаил Андреев]

Цитата:

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

Что же касается указанных полей из InventSum - все бы хорошо, но и они не помогут гарантированно отсеять все лишние номенклатуры. Например, взять случай, когда одна и та же номенклатура на 10-м уже закрыта, а на 08-м еще болтается.

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