Запрос к InventSum с InventLocationId

[Pustik]

Цитата:

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

Вот , вот .... очень актуально . Есть такое и со старой Ахаптой . Работаем с 3,0 SP 4 Ахаптой . Но бывает такие случаи , когда отстаток некореткный . Никак нинашёл в чем дело с етим . Ето бывает редко , словить трудно . Подскажите пожалуйста , с кем ето связано ...

Это может быть связано с тем, если у вас построение отчета происходит по алгоритму не сначала времен. А с использованием inventSum. Принцип такой : Получаем остатки на сегодня (InventSum). Вычисляем приход + расход от указанной вами даты до сегодня. Можем вычислить остатки на указанную вами дату. Затем вычисляем приход. Затем расход. А остатки на конец месяца путем сложения остатки на начало + приход - расход.Такой принцип работает быстрее стандартной оборотки в ваших версиях, за счет того, что при выборке данных используется маленький период(а не сначала времен). Но в этом есть подвох (он не частый но иногда происходит).Пока вы получаете остатки в наличии на сегодня, кто-то может разнести журнал, закупку и т.д.Т.е. вы в процессе выполнения получили остаток без учета этого разнесенного журнала. Затем ваш алгоритм переходит к получению приъхода, расхода и т.д. И вот тут вы получите, что в приход(или расход) попало количество этого УЖЕ разнесенного журнала.В итоге данные не корректные. Если вы запустите этот отчет еще раз, все будет нормально. У нас, такое происходит периодически.

[Rimantas]

Цитата:

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

Это может быть связано с тем, если у вас построение отчета происходит по алгоритму не сначала времен. А с использованием inventSum. Принцип такой : Получаем остатки на сегодня (InventSum). Вычисляем приход + расход от указанной вами даты до сегодня. Можем вычислить остатки на указанную вами дату. Затем вычисляем приход. Затем расход. А остатки на конец месяца путем сложения остатки на начало + приход - расход.Такой принцип работает быстрее стандартной оборотки в ваших версиях, за счет того, что при выборке данных используется маленький период(а не сначала времен). Но в этом есть подвох (он не частый но иногда происходит).Пока вы получаете остатки в наличии на сегодня, кто-то может разнести журнал, закупку и т.д.Т.е. вы в процессе выполнения получили остаток без учета этого разнесенного журнала. Затем ваш алгоритм переходит к получению приъхода, расхода и т.д. И вот тут вы получите, что в приход(или расход) попало количество этого УЖЕ разнесенного журнала.В итоге данные не корректные. Если вы запустите этот отчет еще раз, все будет нормально. У нас, такое происходит периодически.

Вы правы на все 110 % ... :-) . И мы так думаем . Ещё могу добавить что есть несовпадение InventSum-а и InventTrans-a . То есть в том смысле , когда програма сделает query в реальном времени , оно хватает данные от InventSum как такие . И вот когда другие делает попрваки , то в тот момент InventTrans пополняеться записями , а InventSum от query - остаеться непоправленным . Вот ето место необновляеться ( например ) :

while ( qr.next() )
{
inventDim = qr.get( tableNum( InventDim ) );
InventSum = qr.get( tableNum( InventSum ) );
... и т.д.
}

Наверно для того , чтобы избежaть такое , надо ещё раз взять переменную inventSum2 . Например - inventSum2 = InventSum::findRecord( inventSum.RecId ) . Вот тогда данные в InventSum-е будет правильные и точка отчета в данный момент тоже правильное ... Все - попробываю ...

[gl00mie]

Цитата:

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

есть несовпадение InventSum-а и InventTrans-a . То есть в том смысле , когда програма сделает query в реальном времени , оно хватает данные от InventSum как такие . И вот когда другие делает попрваки , то в тот момент InventTrans пополняеться записями , а InventSum от query - остаеться непоправленным . Вот ето место необновляеться ( например ) :

while ( qr.next() )
{
inventDim = qr.get( tableNum( InventDim ) );
InventSum = qr.get( tableNum( InventSum ) );
... и т.д.
}

Это нормально. Когда вы отправляете запрос на СУБД, последняя готовит вам т.н. ResultSet - слепок с нужными вам данными на основе исходных, удовлетворяющих критериям запроса. Если за время обработки этого результата исходные данные изменились, вы этого не увидите без выполнения подзапросов или повторного выполнения всего запроса.

Цитата:

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

Наверно для того , чтобы избежaть такое , надо ещё раз взять переменную inventSum2 . Например - inventSum2 = InventSum::findRecord( inventSum.RecId )

Скорее всего не получится, потому что запросы по InventSum обычно идут с агрегированием, и в результирующей выборке RecId отдельных записей просто нет.

[Pustik]

Цитата:

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

Наверно для того , чтобы избежaть такое , надо ещё раз взять переменную inventSum2 . Например - inventSum2 = InventSum::findRecord( inventSum.RecId ) . Вот тогда данные в InventSum-е будет правильные и точка отчета в данный момент тоже правильное ... Все - попробываю ...

Для исправления такой погрешности, мы использовали фиксированное сальдо. Т.е. после каждого закрытия месяца, заполняется табличка, где фиксируется сальдо. Четко знаем, что закрытый период, и уж тем более эту табличку (насколько я знаю она есть и в 2009), никто не испортит , можно плясать от нее. Идея в том, что любой разнесенный документ (журнал, закупка и т.д.) в любом случае, повлияет на inventSum, а на эту табличку нет.Поэтому можно плясать не от inventSum, а от этой таблички. Например, заказываете вы обороту от 01.01.2012 по 31.01.2012. За старт мы возьмем не InventSum, а нашу табличку (где уже есть закрытый декабрь).И конечное сальдо декабря, как равно начальное сальдо января не поменяется. Дальше дело техники. Погрешность минимизируется.
У нас, почти во все важные оборотки встроена такая возможность.