остатки МЦ на заданную дату в ard отчете

[Bulat-bash]

В ard отчете необходимо вывести остатки по МЦ на дату формирования отчета.
Если кто-нибудь сталкивался с этим делом, выложите пожалуйста вьюшку для примера.
Заранее спасибо!

[edward_K]

селектом вы запаритесь
тем более что теперь в saldomc остатки лежат не на конкретнуюю дату а на каждую дату движения по разрезу( грубо getlast saldomc по требуемому разрезу)
но так у вас точно совпадет с галакт.отчетами
Store_Init ;
Store_TypeOstatki(False) ;
Store_SkladProizv(wskl);
//{ выгружает во временную таблицу TmpSaldo входящие остатки по разрезу }
//{ склад мол партия }
//{ три последних параметра при значении TRUE выгружают в TmpSaldo }
//{ все записи не зависимо от соответствующего разреза }
//{ при значении FALSE - производится группировка }
//{ -2 означает работу с таблицей Pick }
//procedure Store_Run(dDate : longint; cMC, cPodr, cMol, cParty : comp;
// TakePodr, TakeMol, TakeParty : boolean{; TakeVal : boolean = false});

Store_Run ( wwdt, wcmc_sk ,wcpodr_sk,comp(0),comp(0),TRUE, True,false ) ;
Nextvisual ;
wchet:=0
if vsklad.getfirst TmpSaldo1 ordered by index TMPSaldo103=0
do {
....
} while vsklad.getnext TmpSaldo1 ordered by index TMPSaldo103=0

Store_Done ;
могете еще поискать на форуме - это не раз обсуждалось

[Chak]

можно здесь почитать: http://www.tyumbit.ru/gal_forum/viewtopic.php?t=485

[aleks1232321]

Можно еще так
InitMcInfo(d1); // d1 := SUB_DAY(Cur_Date,1) если на текущий день считать;
а дальше функция
NALT(d1,MC,COMP1,comp2,comp3);
// d1 - дата расчета остатков
// MC - katmc.nrec
// comp1 - склад
// comp2 - katmol.nrec: если = 0 - без мол, если = -1 то на МОЛ внимания не обращать, считать все
// comp3 - katrparty.nrec: если = 0 - без партий если = -1 то на партии внимания не обращать, считать все
В конце DONEMCINFO

[Den_Is]

А как по скорости это все дело крутиться, так же как и в стандартных гал. отчетах?
Я делаю циклами по катмц, подр, партии, и хожу на последнюю запись сальдо. Получается довольно долго.
Надо попробывать
Store_Init ;
Store_TypeOstatki(False) ;
Store_SkladProizv(wskl);
что то в исходниках гал-их видел? разобраться не получилось, а сейчас начинает доходить.

[edward_K]

эти функции из стандартных и взяты.
если руами то на самом деле нужно прежде чем лазить в сальдо смотреть в saldofnd - там накапливается инфа о движении в таком то разрезе.

[Den_Is]

тогда вопрос по saldofnd
в неё заносятся текущие остатки (типа как SALDMOUN) ? Потому как никакой даты сальдо я там не увидел А если требуется найти остатки cкажем на определенную дату прошлого года?
Да и количества и цены в saldofnd тоже нету.

[Den]

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

[san]

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

[Seybukan]

Это настройки у вас кривые, а не функция.

[san]

Это настройки у вас кривые, а не функция.

Точно.Как я сразу не заметил.

[Den_Is]

еще мелкий вопрос.
Все вроде бы работает, все считает просто зашибись но...
Как с помощью этих функций вывести дату сальдо (ну вроде того saldomc.dsaldo)?

[aleks1232321]

Да никак

[Seybukan]

Точно.Как я сразу не заметил.

И не стоит обижаться.

Но надо понимать - что вышеописанная функция тянет данные из БД.
А вот за попадание правильных данных в БД отвечает савершенно другая функция.
И даже если выставите настройку в положение корректного округления попадания данных - то это вас не спасет, так как функция сохраняет историю данных, влияя на текущее состояние БД.
И если данные когда либо были не корректные, то и вся история не корректная.
Вообщем все это решается за 1 день или вечер!

[san]

Вообщем все это решается за 1 день или вечер!

Ни чего подобного. расчет идет по формуле sporder.kol*sporder.srprice.и все это складывается в заданом разрезе.
в оборотке есть настрока включить округление, если включено - приход/расход считается round(sporder.kol*sporder.srprice,2), в итоге исх сальдо не будет соотв входящему след периода. т.к. в сальдо (ф-ции) округление не предусмотрено. если расхождение на копейки вас не волнует, то это не предмет разговора.