Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимальный срок для миграции данных из старой АБС в новую
|
|||
|---|---|---|---|
|
#18+
Во многих рекомендациях наилучший срок для миграции данных это начало календарного года! Прошу объяснить почему лучше всего на начало года? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 15:35 |
|
||
|
Оптимальный срок для миграции данных из старой АБС в новую
|
|||
|---|---|---|---|
|
#18+
Это связано с окончание календарного года в бухгалтерии, но ИМО это все ерунда, особенно для большого и многофидиального банка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 15:57 |
|
||
|
Оптимальный срок для миграции данных из старой АБС в новую
|
|||
|---|---|---|---|
|
#18+
GilyanaВо многих рекомендациях наилучший срок для миграции данных это начало календарного года! Прошу объяснить почему лучше всего на начало года? Очень часто в новую АБС не заливаются данные прошлых лет. То есть отчетность за прошлые годы получается из старой АБС, а за текущий - из новой. В таком случае миграция в начале года удобна тем, что минимизируется объем переносимых данных, а следовательно количество ошибок и необходимых ручных исправлений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 16:24 |
|
||
|
Оптимальный срок для миграции данных из старой АБС в новую
|
|||
|---|---|---|---|
|
#18+
GilyanaВо многих рекомендациях наилучший срок для миграции данных это начало календарного года! Прошу объяснить почему лучше всего на начало года? Вопрос - Это для импортных или отечественных систем? Если для импортных - то у многих из низ РЕАЛЬНЫМ периодом является ГОД. А результаты помесячные получаются суммированием оборотов (т.е. нет промежуточных регистров хранения бухгалтерских остатков). к тому же операция закрытия года - весьма специфична. При такой реализации - альтернативы началу года нет. Для ПРОЧИХ - начало года не оптимально, по организационным причинам: 1. До 20-го февраля из системы будет выключен ключевой отдел - бухгалтерия сдает годовой отчет. 2. Ударными темпами после 20-го ввести ВСЕ документы в НОВУЮ (а значит не отлаженную, с не отработанными процессами) систему за 1,5 месяца и не накопить при этом новых документов за 2 мес. - нереально 3. Аналогичен вариант, когда другие подразделения будут вводить в надежде что бухи закончат отчет и во всем разберутся - В новую систему проще внести "с нуля" чем искать в ней ЧУЖИЕ ошибки. Вывод: Наиболее оптимальным вариантом представляется старт с октября - чтобы успеть выверить все процессы и пользователи могли вводить данные за январь/февраль смело. Да и на начало года остатки будут правильными. Второй вариант: март - отладка; ввод начальных остатков на 2-й квартал; отработка по второму кварталу в полном объеме и выход на остатки первого полугодия; после чего можно отказывается от старой системы и за второе полугодие делать баланс из новой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 18:43 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=34695953&tid=1527405]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 283ms |
| total: | 437ms |

| 0 / 0 |
