Удаление журнала спецификаций

[rrkrivov]

Доброго времени суток!

Сегодня обноружил что Axapta позволяет удалять журнал спецификаций (при чем, разнесенный журнал тоже позволяет удалять). В связи с этим у меня возникли вопросы - это так и надо или это глюк системы? И что произойдет с проводками разнесенного журнала - будут ли они корректно удалены вместе с журналом?
И рекомендуется ли так удалять разнесенный журнал?

[George Nordic]

Хм. В принципе, нормально...

А зачем нужны спецификации?
1) Для рассчета потребления / себестоимости про-ва
2) Для запуска про-ва, при этом любая спецификация может быть откорректирована.

Так вот, в 1 случае они нужны разово, для расчета / оценки, а во 2м - они все равно логируются, с изменениями, т.е. каждый заказ знает, по какой спецификации он был произведен (BOM -> ProdBOM).

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

[EVGL]

Это не глюк, а один из краеугольных камней архитектуры системы: разнесенные журналы, заказы и закупки и т.д. можно удалять, а проводки остаются. Почему-то только большинство не принимает это во внимание и обращаются, к примеру, повсеместно из журнала накладных к исходным строкам заказа.

Если журнал не разнесен, то складские проводки будут удалены вместе со строками журнала.

[glibs]

Цитата:

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

А разнесенный журнал ГК можно удалить штатными средствами?

[Тимур]

Другой вопрос, впервые за большое количество времени

А как быть с архивированием данных? С заказами, закупками, журналами?
Так чтобы статистика сохранялась?

[mazzy]

Цитата:

Изначально опубликовано glibs
А разнесенный журнал ГК можно удалить штатными средствами?

Да,
Просто какая-то, не побоюсь этого слова, сволочь
запрещает доступ к кнопке Удалить проводки.

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

Иногда до этого доходят пользователи. А внедренцы очень-очень удивляются.

[mazzy]

Цитата:

Изначально опубликовано Тимур
Другой вопрос, впервые за большое количество времени

А как быть с архивированием данных? С заказами, закупками, журналами?
Так чтобы статистика сохранялась?

Статистика ПОЛНОСТЬЮ сохраняется в фактических проводках. В LedgerTrans, InventTrans, CustinvoiceJour, CustinvoiceLine и т.п...

Журналы, Заказы, Закупки - суть черновики, которые могут быть удалены после того, как будет создана фактическая проводка. После разноски черновики анализировать нельзя. Так как черновики можно и нужно удалять.

[Тимур]

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

[mazzy]

Цитата:

Изначально опубликовано Тимур
Как архивируются...

Никак. В Аксапте нет такого понятия.
Или я тебя не понял.

[Тимур]

Я в курсе, что нет.
Меня интересует, как проблема с разбуханием базы данных решают люди, с условием сохранения данных статистики.
Имхо, это существенная проблема. В других системах, с которыми я работал, такой проблемы нет.

[mazzy]

Цитата:

Изначально опубликовано Тимур
Я в курсе, что нет.
Меня интересует, как проблема с разбуханием базы данных решают люди, с условием сохранения данных статистики.
Имхо, это существенная проблема. В других системах, с которыми я работал, такой проблемы нет.

На Оракле такой проблемы нет. Используется сегментирование.
В MS SQL такая проблема есть.

[glibs]

Цитата:

Изначально опубликовано mazzy
...
Если без программирования, то зайди в неразнесенный журнал, выбери пункт удалить проводки, нажми на кнопку Выбор, выбери номер разнесенного журнала. Удали строки, затем можно удалить сам журнал.
...

Что-то у меня не получилось.

В Infolog выдается желтое предупреждение следующего характера:

"
Журнал был разнесен и, следовательно, не является открытым
"

Строчки не удаляются.

Можно уточнить инструкцию для воспроизведения задекларированного эффекта?

Цитата:

Изначально опубликовано mazzy
...
Работает со всеми журналами, включая складские.
...

Со складскими журналами такая проблема вообще не стоит. Они тупо удаляются без каких-либо хитростей.

Цитата:

Изначально опубликовано mazzy
...
Иногда до этого доходят пользователи. А внедренцы очень-очень удивляются.
...

Ну надо же! А версия у пользователей какая? Я тестировал на 3.0 СНГ сп3 ко1.

Хотелось бы, чтобы EVGL прокомментировал сей непонятный эффект: то, что строчки журнала ГК не удаляются штатными средствами — это бага, на исправление которой в течение нескольких лет не может найтись сил у разработчиков системы, или все-таки для такого запрета существуют определенные мотивы. Хотя в последнем я сомневаюсь, т.к. строки все-таки можно удалять, если до разноски в журнале установить соответствующую галку.

[Тимур]

Цитата:

Изначально опубликовано mazzy

На Оракле такой проблемы нет. Используется сегментирование.
В MS SQL такая проблема есть.

Дело не в СУБД, а в том, что старые данные не стоит хранить. Например, бух. данные старше 5 лет хранить не требуется. Особенно в рабочей БД.
И не хочется, чтобы система с самого начала считала статистические показатели.

[mazzy]

Цитата:

Изначально опубликовано Тимур
Дело не в СУБД, а в том, что старые данные не стоит хранить. Например, бух. данные старше 5 лет хранить не требуется. Особенно в рабочей БД.
И не хочется, чтобы система с самого начала считала статистические показатели.

Я бы сформулировал следующим образом "старые данные МОЖНО не хранить", а можно хранить.

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

Задача архивирования - сделать так, чтобы старые данные не мешали новым. Прежде всего с точки зрения производительности. Так вот сегментиирование с этой задачей атлично справляется.

Glibs - отвечу чуть позже.

[AKIS-Falcon]

Ну давайте обсуждать в одном месте...

Цитата:

Задача архивирования - сделать так, чтобы старые данные не мешали новым. Прежде всего с точки зрения производительности

Не только. Прежде всего - чтобы не засорять базу, а иметь всегда только актуальные данные, за тот период, к которому обращаются часто. Как бы ни была велика производительность, если на запрос о заказах клиента вываливается вся история с 1861 года - это не очень хорошо, на мой взгляд...

Цитата:

Если же подразумевался бэкап, то используйте импорт/экспорт. А еще лучше всетаки пользуйтесь средствами СУБД для бэкапа.

В том-то и дело что НЕ бэкап, а именно архивирование. Средства СУБД не способны учесть функциональные связи таблиц, и поэтому они для такой цели малопригодны.

[mazzy]

Цитата:

Изначально опубликовано AKIS-Falcon
Не только. Прежде всего - чтобы не засорять базу, а иметь всегда только актуальные данные, за тот период, к которому обращаются часто. Как бы ни была велика производительность, если на запрос о заказах клиента вываливается вся история с 1861 года - это не очень хорошо, на мой взгляд...

Я и говорю - соображения производительности.

Смотрите сегментирование в Оракле.
Суть (очень грубо и очень неточно): можно разбить одну таблицу на несколько сегментов. Каждый сегмент можно хранить в отдельном... хм... на отдельном диске (так проще для понимания). Оракл умеет делить данные на сегменты при помощи различных критериев. В частности может делить на сегменты по датам. Так, например, текущий год размещаем на быстрый(ые) диск(и), а данные прошлых лет на медленный(ые). В результате Оракл при запросах к текущему году не обращается к медленному диску (сознательно написал очень грубо, если кому интересно обращайтесь к документации)

Так вот, имея под рукой функцию сегментирования не надо заботиться о СВЕРТКЕ. Данные могут оставаться в первоначальном виде. При больших объемах производительность существенно не падает. Но зато запросы БЕЗ изменений работают по ЛЮБОМУ периоду. Надеюсь вы понимаете, что это означает для получения статистики.

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

Теперь про то как написана Аксапта. Западный функционал написан таким образом, чтобы не перебирать ВСЕ данные за все периоды. Посмотрите финансовые итоги, посмотрите складские итоги. Российский же функционал, к великому сожалению, бывает, что суммирует все данные. См. оборотки по складу, клиентам, поставщикам, оборотки, шахматки. Вывод - постарайтесь не пользоваться российским функционалом.

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

[AKIS-Falcon]

Цитата:

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

С последним утверждением категорически не согласен

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

[mazzy]

Если отчет написан правильно (используется таблица xLastValue), то дату надо будет ввести один раз. В дальнейшем, она подставляется из последних значений автоматически.

[AKIS-Falcon]

Я не про отчеты больше, а про формы...

[mazzy]

Формы никогда не читают ВСЕХ данных (если только программист не постарался и не перекрыл query своими select'ами)
Формы всегда читают только часть. Поэтому большого трафика формы не генерят.