Цитата:
Сообщение от
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-е будет правильные и точка отчета в данный момент тоже правильное ... Все - попробываю ...
