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

[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 система с возможностью сводного планирования, расчета норматива страхового запаса, АВС-классификации, а также бджетирования, анализа бюджетов и фактических данных... ну пусть хотябы за три последних года, всякой там оборачиваемости запасов, дебиторской задолженности, истории взаиморасчетов, кредитной истории...

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