Существуют ли механизмы свертывания базы?

[sergeypp]

А в пределах темы

Цитата:

Поэтому правильный алгоритм такой:
1. Найти записи в InventSum для которых InventSum.isAllFieldsZero() == true
2. Найти количество записей InventTrans для каждой записи из InventSum
3. Если количество записей в InventTrans == 0, то InventSum удалять можно.

Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??

[Zabr]

Цитата:

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

А в пределах темы

Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??

видимо по ItemId && inventDimId

[sergeypp]

И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?

[Yprit]

Цитата:

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

И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?

На Аксапте такого пока не делали - делали на Эске, причем не раз
Мне почему-то кажется, что в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....

[Zabr]

Цитата:

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

в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....

Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.

[Yprit]

Цитата:

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

Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.

Да, точно, увлекся

[EVGL]

А что скажет Wamr? Он, кажется, имел непосредственное отношение к "Перекрестку". При упоминании InventTrans волоски на шее у него должны вставать дыбом (извините за поэтическое сравнение).

А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить. Т.е. экстраполировать можно только до 2008 (2009-го ?) года.

[TasmanianDevil]

Цитата:

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

А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить.

Сальдо будут нормальное хранить , а не агрегированные обороты по проводкам ГК?

[Wamr]

Ну раз спросили, то отвечу
В Перекрестке Аксапта использовалась без финансового модуля, то есть проводки были, но никто их не смотрел, так что эта часть чистилась очень просто.
Сокращение InventTrans делалось созданием новой базой с переносом остатков на дату (с сохранением соотношения открытые-закрытые).
Процесс выглядил примерно так:
1. Перед полной инвентаризацией в обязательном порядке закрываются все "зависшие" документы, вычищаются "повисшие" проводки (не продано-приобретено и не заказано- в заказе)
2. Создается новая база, в которую заливаются мастер-данные, открытые документы (с проводками заказано-в заказе)
3. После подсчета (до разноски или параллельно разноске журналов) в новой базе создаются приходные проводки с типом перенос и "красивым" номером по количествам, аналитикам из журналов инвентаризации и средней себестоимостью.
4. Переносятся все InventDim, которые используются в новой базе и все партии которые используются в этих аналитиках.
5. Новая Аксапта запускается ... ночь прошла! ура! домой!
6. После закрытия периода в старой базе, в новой создается приходная накладная (либо стандартно, либо генерация записей своей процедурой) на резервный склад с правильной суммой и создаются расходные проводки с "красивым" журналом переноса с резервного склад со старой себестоимостью. (Создание приходной накладной на несколько тысяч строк - отдельная большая тема)
7. Часть приходных проводок "закрывается" для сопоставления. Можно было бы и помельче подробить для сохранения ФИФО, но это оказалось никому не нужно.

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

[komar]

Цитата:

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

Ну раз спросили, то отвечу

Эту процедуру делали ежегодно или чаще?

[sergeypp]

2 Wamr
Мдаааааааа......но в любом случае как вариант..
накатились воспоминания, как я в наве одну фирму другой продавал.. там тоже.. Ура. ночь прошла.. только вот домой не уходил)))

[mazzy]

Цитата:

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

но в любом случае как вариант..

Категорически против такого варианта.
Только если остальные варианты не подходят.

[Wamr]

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

[glibs]

Я, пожалуй, в общем случае соглашусь с mazzy на этот раз.

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

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

Если уж принято решение работать с Аксаптой, то незачем ныть теперь, и обвинять кого-то другого (Микрософт и его закрытие склада, например).

С позиции "Имеем то, что имеем"... IMHO... вариант Wamr правильный. В данном случае Аксапта есть ни что иное, как учетная система. Тогда имеет смысл выносить из нее аналитику наружу. Например, в ОЛАП.

Кстати, старые DOSовские системы раньше так и работали. Была процедура закрытия года и переноса в архив. Правда, причины были тогда в другом, но суть такая же. ОЛАПа не было. Но, возможно, кто-то делал его вручную.

Насколько такой вариант использования Аксапты правильный — вопрос отдельный. В данной ветке его опустим. Исходя из моей практики, самое козырное правило: "Заказчик всегда прав". Возможно, ему именно это и нужно было.

[Serge Kotov]

Цитата:

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

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

А существенной проблемы с ростом БД в Перекрестке собственно говоря и нет благодаря варианту Wamrа. Пусть некрасив способ внешне, но работает и успешно применяется.

[Zabr]

Цитата:

Сообщение от Serge Kotov

Пусть некрасив способ внешне, но работает и успешно применяется.

Большой вопрос, применим ли этот способ для поднявшего тему Sergeypp. Как я понимаю, в Перекрестке 1 (один) склад - распределительный центр (РЦ), и его инвентаризация позволяет освободить базу для таких рабаот. А Sergeypp - 42 магазина-склада, наверное еще и РЦ есть. Это значит, что нужно останавливать на 1-2-3 дня весь бизнес.

[glibs]

Цитата:

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

...
Большой вопрос, применим ли этот способ для поднявшего тему Sergeypp
...

Если не страдать манией засунуть все 42 магазина в одну базу, то с высокой вероятностью да.

А даже если страдать... а чего это инвентаризация стала камнем спотыкания? Я уже писал про DOSовские программы. Они и без инвентаризации работали. Просто в ночь на Новый Год одним махом перенести остатки в новую базу один в один. А потом инвентаризации делать можно хоть до осени.

[Serge Kotov]

Цитата:

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

...
Как я понимаю, в Перекрестке 1 (один) склад - распределительный центр (РЦ), и его инвентаризация позволяет освободить базу для таких рабаот. А Sergeypp - 42 магазина-склада, наверное еще и РЦ есть. Это значит, что нужно останавливать на 1-2-3 дня весь бизнес.

Если быть точным, в Перекрестке на текущий момент 3 распределительных центра и 169 собственных магазинов. Ничего, бизнес не останавливается.

[glibs]

Цитата:

Сообщение от Serge Kotov

...
существенной проблемы с ростом БД в Перекрестке собственно говоря и нет
...

Перефразируя известную поговорку...



Нет базы — нет проблем.



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

Клиенты, правда, перевнедрения очень не любят.

Но ставить их на поток...

Нет, это дело вкуса, конечно. И спорить нечего...

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

Вот такой вот я романтик

[sergeypp]

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