Что за дурацкий алгоритм в расчете прогноза движения средств

[slava09]

Почему он просматривает ВСЕ заказы, а не только открытые?
И вообще зачем просматривать все заказы, чтобы потом 90% отбросить?
Или я чего-то не понимаю?

[ola]

Продолжу вопрос...
Никто не сталкивался с проблемой быстродействия при работе прогноза движения денежных средств? Похоже, что действительно - неоптимально построены алгоритмы расчета прогноза. Так и не смогли дождаться окончания расчета прогноза с параметром Всего на реальной клиентской базе с наработками за 1,5 года... Одна из ключевых составляющих расчета - неотфактурованные строки заказов и закупок - рассчитывается почему-то по строкам ВСЕХ заказов / закупок, что и занимает ну ОЧЕНЬ много времени..
Реально - кто-то модифицировал алгоритмы расчета? Поделитесь, пожалуйста, опытом.. Какие еще проблемы приходилось решать при внедрении этого функционала?

[mazzy]

Цитата:

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

И вообще зачем просматривать все заказы, чтобы потом 90% отбросить?
Или я чего-то не понимаю?

Угу. В нормальном режиме полностью отфактурованные заказы удаляются автоматически.

Правьте алгоритм, если у вас не так.

[George Nordic]

Не удаляются, а попадают в архив
А проводки - остаются, и это нормально.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Не удаляются, а попадают в архив
А проводки - остаются, и это нормально.

Проводки остаются.

А заказы удаляются. Разреши, я буду на этом настаивать.
Просто если включить галочку "аннулировать вместо удаления", то вместо удаления заказы будут архивироваться.

Заказы - суть черновики. Как и журналы.
При разноске/выписке накладной информация полностью переходит из черновика в проводки (должна переходить )

[Сисой]

Цитата:

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

Проводки остаются.

А заказы удаляются. Разреши, я буду на этом настаивать.

Хм. Теряется информация о том, кто и когда зарегистрировал заказ. Да и с точки зрения бизнес-процесса как-то кривовато получается - удалять документы-инициаторы.

[mazzy]

Цитата:

Сообщение от Сисой

Хм. Теряется информация о том, кто и когда зарегистрировал заказ. Да и с точки зрения бизнес-процесса как-то кривовато получается - удалять документы-инициаторы.

Заказ - не документ и не инициатор.

Если уж говорить об инициаторах, то им является документ Предложение или Заявка, которые создаются на основании Заказа и Закупки соответственно.

Кто, когда, почему зарегистрировал заказ - надо смотреть либо в аннулированных, либо переносить в документы.

Еще раз: журнал - черновик, разноска - перенос информации из черновика в беловик (в проводки/документы), заказ/закупка - специализированные виды журнала.

Как только такое понимание закрепиться в голове, то все сразу сразу станет логично.
Информацию берем только из проводок.
После разноски нельзя обращаться к журналам/заказам/закупкам
Код журнала/заказа/закупки нужен только для объединения документов/проводок, созданных на основании одного журнала/заказа/закупки.

В журналах/заказах/закупках находится только то, что мы собираемся сделать (план/прогноз).
В проводках/документах находится то, что мы уже сделали (факт).

[glibs]

Цитата:

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

...
Никто не сталкивался с проблемой быстродействия при работе прогноза движения денежных средств?
...

Я сталкивался. Правда, на базе за месяцев 7-8 прогноз у меня таки рассчитался примерно за полтора часа.

Цитата:

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

...
Реально - кто-то модифицировал алгоритмы расчета?
...

Я пока только переделал алгоритм поиска счета Прибытия/Себестоимости и соответствующего типа разноски для закупок (чтобы они соответствовали тому, как закупка реально будет разнесена).

Еще там с графиками оплаты полный бред нарисован.

А вообще, похоже, там еще много чего нужно доводить до ума. Причем, своими силами. Так как Микрософт демонстрирует толи свое бессилие, толи упорное нежелание править ошибки с расчетом прогнозных проводок.

[slava09]

Опять начинается "война миров"
С заказами понятно. Но если их и удалять, например раз в год, а в день их набивают по 1000, то всеравно, хоть удаляй хоть не удаляй, а их всеравно будет много.
С алгоримом тоже понятно.
С Микрософтом вообще все понятно
С Георгием, Mazzy и Сисоем тоже все понятно и... спасибо

[Pavel]

Цитата:

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

Проводки остаются.

А заказы удаляются. Разреши, я буду на этом настаивать.
Просто если включить галочку "аннулировать вместо удаления", то вместо удаления заказы будут архивироваться.

Заказы - суть черновики. Как и журналы.
При разноске/выписке накладной информация полностью переходит из черновика в проводки (должна переходить )

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

Вводить информацию в систему, чтобы потом удалить... хм... по меньшей мере, нелогично.
Если приходится удалять, чтобы уменьшить объем информации и, тем самым, повысить производительность системы (или конкретной функции) - это системная проблема, которая существенно ограничивает возможности применение продукта, т.к. ставит пользователя перед неприятным выбором: "или расстаться с информацией или замедлить ее обработку".

"Заказы = черновики" - совершенно не согласен с таким толкованием. Заказ и все что с ним связано - это прежде всего средство для реализации бизнес процесса, без этого (только с проводками) система превращается из управленческой в учетную. В ходе отработки бизнес процесса системе сохраняет массу аналитической информации, которая может оказаться в любой момент востребованной (продавец, приемщик, условия поставки/доставки/оплаты, цены/скидки и пр.).

Журнал можно рассматривать как черновик, но реальная выгода его использования заключается, опять же в покрытии конкретных бизнес процессов.

[leshy]

К сожалению, не всегда можно использовать удаление заказов даже при использовании стандартного функционала. Например, если удалить заказы то не будет работать статистика по продажам в модуле CRM, например "Заказ против плана".

[slava09]

Бойцы! Призываю Вас в отдельную ветку: "Удаление заказов после обработки. За и против."