AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.05.2007, 14:36   #21  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от sergeypp Посмотреть сообщение
А в пределах темы

Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??
видимо по ItemId && inventDimId
Старый 17.05.2007, 14:49   #22  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от sergeypp Посмотреть сообщение
И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?
На Аксапте такого пока не делали - делали на Эске, причем не раз
Мне почему-то кажется, что в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....
Старый 17.05.2007, 15:06   #23  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от Yprit Посмотреть сообщение
в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....
Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.
Старый 17.05.2007, 17:05   #24  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от Zabr Посмотреть сообщение
Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.
Да, точно, увлекся
Старый 17.05.2007, 22:06   #25  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sergeypp Посмотреть сообщение
2 Mazzy
Вот список лидеров.

PHP код:
INVENTTRANS    1092424
SALESLINE    378704
LEDGERTRANS    368968
CUSTINVOICETRANS    289360
INVENTTRANSPOSTING    279896
INVENTSUM    260384
FACTURETRANS_RU    236024
TAXTRANS    197192
INVENTJOURNALTRANS    141784
CUSTCONFIRMTRANS    133688
LEDGERJOURNALTRANS    123232
CUSTINVOICEJOUR    94584
CUSTTRANS    86792
SALESTABLE    77912
... 
Мдя... С InventTrans, LedgerTrans особо ничего не поделаешь...
У складских проводок InventTrans есть стандартная процедура свертки.
Ее можно найти в окне проводок, кнопка Функции, Суммирование.
Но в ней объединяются записи в пределах одного лота.

Плохо то, что вы храните старые заказы (SalesTable, SalesLine) и журналы (LedgerJournalTrans).
Но по этим таблицам у ритейла может быть модификация, которая требует, чтобы заказы и журналы не удалялись. Надо проверить. В стандартном функционале Заказы и Журналы - черновики, которые можно удалить после разноски (у журналов и заказов даже галочки соответсвующие есть).

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

Непосредственный способ работы с такими таблицами - сегментировать в SQL.
Сегменты со старыми данными переносить на более медленные (и дешевые диски)
__________________
полезное на axForum, github, vk, coub.
Старый 17.05.2007, 22:14   #26  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
А что скажет Wamr? Он, кажется, имел непосредственное отношение к "Перекрестку". При упоминании InventTrans волоски на шее у него должны вставать дыбом (извините за поэтическое сравнение).

А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить. Т.е. экстраполировать можно только до 2008 (2009-го ?) года.
Старый 18.05.2007, 09:37   #27  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
Цитата:
Сообщение от mazzy Посмотреть сообщение
Непосредственный способ работы с такими таблицами - сегментировать в SQL.
Сегменты со старыми данными переносить на более медленные (и дешевые диски)
Это, насколько я понимаю, толкько в 2005 MSSQL//
Старый 18.05.2007, 09:40   #28  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от EVGL Посмотреть сообщение
А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить.
Сальдо будут нормальное хранить , а не агрегированные обороты по проводкам ГК?
Старый 18.05.2007, 10:24   #29  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Перекресток
Ну раз спросили, то отвечу
В Перекрестке Аксапта использовалась без финансового модуля, то есть проводки были, но никто их не смотрел, так что эта часть чистилась очень просто.
Сокращение InventTrans делалось созданием новой базой с переносом остатков на дату (с сохранением соотношения открытые-закрытые).
Процесс выглядил примерно так:
1. Перед полной инвентаризацией в обязательном порядке закрываются все "зависшие" документы, вычищаются "повисшие" проводки (не продано-приобретено и не заказано- в заказе)
2. Создается новая база, в которую заливаются мастер-данные, открытые документы (с проводками заказано-в заказе)
3. После подсчета (до разноски или параллельно разноске журналов) в новой базе создаются приходные проводки с типом перенос и "красивым" номером по количествам, аналитикам из журналов инвентаризации и средней себестоимостью.
4. Переносятся все InventDim, которые используются в новой базе и все партии которые используются в этих аналитиках.
5. Новая Аксапта запускается ... ночь прошла! ура! домой!
6. После закрытия периода в старой базе, в новой создается приходная накладная (либо стандартно, либо генерация записей своей процедурой) на резервный склад с правильной суммой и создаются расходные проводки с "красивым" журналом переноса с резервного склад со старой себестоимостью. (Создание приходной накладной на несколько тысяч строк - отдельная большая тема)
7. Часть приходных проводок "закрывается" для сопоставления. Можно было бы и помельче подробить для сохранения ФИФО, но это оказалось никому не нужно.

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

Последний раз редактировалось Wamr; 18.05.2007 в 10:31.
Старый 18.05.2007, 11:26   #30  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
2 Wamr
Мдаааааааа......но в любом случае как вариант..
накатились воспоминания, как я в наве одну фирму другой продавал.. там тоже.. Ура. ночь прошла.. только вот домой не уходил)))
Старый 18.05.2007, 11:29   #31  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от Wamr Посмотреть сообщение
Ну раз спросили, то отвечу
Эту процедуру делали ежегодно или чаще?
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 18.05.2007, 11:30   #32  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sergeypp Посмотреть сообщение
но в любом случае как вариант..
Категорически против такого варианта.
Только если остальные варианты не подходят.
__________________
полезное на axForum, github, vk, coub.
Старый 18.05.2007, 11:37   #33  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
komar,
ежегодно осенью, чтобы зимой система справлялась с увеличенным товарооборотом.
Старый 18.05.2007, 13:45   #34  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Я, пожалуй, в общем случае соглашусь с mazzy на этот раз.

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

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

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

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

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

Насколько такой вариант использования Аксапты правильный — вопрос отдельный. В данной ветке его опустим. Исходя из моей практики, самое козырное правило: "Заказчик всегда прав". Возможно, ему именно это и нужно было.
__________________
С уважением,
glibs®
Старый 21.05.2007, 09:15   #35  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
А существуют ли решения топлогии одной основной базы и несколько вспомогательных (на каждый регион). Какими средствами происходит обмен данных.
Т.е. в основной базы заводятся справочники (товары и др.) , которые растекаются по остальным аксаптам, а из них в свою очередь в основную сливаются агрегированные данные по продажам.
Старый 21.05.2007, 21:53   #36  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Существуют, конечно.

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

Работало надежно.

Так что вот...
__________________
С уважением,
glibs®
Старый 21.05.2007, 22:39   #37  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от glibs Посмотреть сообщение
Существуют, конечно.

...

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

В конце концов так и остались трудности с резервированием товара на центральном складе (особенно дефицитного товара). А процедура создания товара превратилась в отдельный скриптовый язык.

Основные проблемы:
1. Обеспечить целостность справочной информации (один и тот же товар вводится в разных точках, а также удаляется/редактируется).
2. Обеспечить двухфазную фиксацию транзакции в распределенной среде (филиалы имеют реплики остатков центрального склада, заказывают дефицитный товар, в репликах транзакция завершена, а после обмена в центральной базе транзакция одного из филиалов не прошла. Что делать?)

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

Вопрос с репликацией обсуждался неоднократно.
__________________
полезное на axForum, github, vk, coub.
Старый 22.05.2007, 14:40   #38  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
И все таки.. неужели нельзя свернуть тот же самый inventtrans за опред период.. не удалять а просуммировать строки. приделать к ним новое измерение(Допустим в разрезе склада - ячейка и гтд свернуть). В итоге вместо 5 тыс строк получим 2 строки. и отчеты поплыть не должны.. ? неужели так никто не делал
Старый 22.05.2007, 15:37   #39  
Serge Kotov is offline
Serge Kotov
Участник
 
275 / 152 (6) ++++++
Регистрация: 06.10.2004
Адрес: Moscow
Цитата:
Сообщение от glibs Посмотреть сообщение
...
Описанная выше проблема на самом деле с высокой вероятностью является примером неудачного архитектурного решения. По идее, разрабатывая архитектуру решения, выполняющий роль архитектора должен осознавать и ограничения (зачеркнуто) особенности конкретной (ERP или прочей) системы, и потенциально возможные обороты (рост базы), и много других вещей.
...
А существенной проблемы с ростом БД в Перекрестке собственно говоря и нет благодаря варианту Wamrа. Пусть некрасив способ внешне, но работает и успешно применяется.
За это сообщение автора поблагодарили: belugin (3).
Старый 22.05.2007, 16:39   #40  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от Serge Kotov Посмотреть сообщение
Пусть некрасив способ внешне, но работает и успешно применяется.
Большой вопрос, применим ли этот способ для поднявшего тему Sergeypp. Как я понимаю, в Перекрестке 1 (один) склад - распределительный центр (РЦ), и его инвентаризация позволяет освободить базу для таких рабаот. А Sergeypp - 42 магазина-склада, наверное еще и РЦ есть. Это значит, что нужно останавливать на 1-2-3 дня весь бизнес.
Теги
архивирование, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Принципы построения базы данных Гужанов Павел DAX: Администрирование 11 05.09.2008 16:47
Утилиты для работы с журналом базы данных vc DAX: База знаний и проекты 0 10.05.2008 17:40
Размер базы Sergo DAX: Функционал 13 30.10.2006 12:17
Создание полной копии Приложения и базы Perc DAX: Администрирование 5 09.03.2005 07:33
Распределенные базы ???? Alex1009 DAX: Функционал 19 01.12.2004 13:30
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 00:38.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.