| 0
- 29.03.2017 - 21:40
|
Всем здравствуйте. Пришлось недавно в паре организаций посмотреть ЗУП 3.1 (релизы ес-но свежие), данные в которые перенесли 1) из БУХ 3.0 2) из ЗУП 2.5 Перед переносом д-х базы тестировались-исправлялись. Понятно,что в "старых" базах не все идеально и могли быть (и были) какие-нибудь ошибки. Но перенос сделан. Как теперь в новых базах исправлять старые грехи? Например,в (1) при расчете зпл в новой базе в новом периоде в документ начисление зарплаты попадает сотрудник, уволенный года три назад, с которым полностью рассчитались. В ЗУП 3.1 в документе Начисление зпл за март он неожиданно появляется с некоторой начисленной суммой. В документе Ведомость, сформированной за март, суммы к выдаче по сотрудникам верные (мартовские), но у некоторых сотров перечислено: в т.ч. за ...и какие-то древние периоды. Где это все в ЗУПе 3.1 находится? Какие регистры можно посмотреть и главное поправить? В варианте (2) картина еще удручающее. Может быть конечно база-источник в худшем состоянии была, трудно сказать. Но там какие-то проблемы возникли с расчетами в текущем периоде. Перенесли данные по дек2016. Вводит бух отпуск в январе, он рассчитывается (даже правильно, данные о среднем заработке перенеслись корректно), но когда вводит документ Начисление зпл, этому сотруднику начисляется оклад за полный месяц, без учета отпуска. В настройках вытеснения ничего не трогали, такая картина по всем отпускникам (б/л при мне не пробовали, как там не знаю). Ну и в документ Начисление зпл тоже кто-то давно уволенный попал. Когда-то придется и свою организацию на 3.1 переводить, соломки что-ли подстелить бы. Как бороться с такими явлениями? Может есть у кого опыт положительны? (сорри за много текста)     | | ||
| 1
- 29.03.2017 - 21:44
| И еще, может быть у кого-то есть личный опыт, при переносе 2.5->3.1 какой вариант все же лучшие результаты показывает - короткий, как рекомендует 1с, или длинный? | | ||
| 2
- 30.03.2017 - 01:34
|
Знакомая картинка... 1. Подготовку к переносу надо начинать со старых баз. Почистить "дубли". Ввести пропущенные документы. Что, "давно уволенный" в ЗУП2.5 не вылазил ежемесячно? Вылазил, вылазил... И не надо тут. Получите и распишитесь. 2. Очень полезно сделать копию переносимой базы, и свернуть её. Оставив хвостик в год. И удалить всего ненужного до хвоста. Документы "хвостика" должны быть перенесены. 3. Для переноса используем именно эту копию. Если потребуется "доперенос" (жизнь-то продолжатся) - ничего страшного: внутренние ссылки у копии и рабочей базы одинаковы. И текущая работа не будет мешать переносу. И наоборот. 4. Делайте копии на каждом этапе. Сэкономили время? Можете теперь использовать бережно сохраненное. Чем хорош приглашенный специалист? Как и старый доктор от молодого: ошибки старого уже на кладбище. | | ||
| 3
- 30.03.2017 - 16:16
|
VZ, спасибо огромное. Перечитаю вдумчиво. Специалиста с опытом в поле зрения нет, сама хочу наработать. В свое время с 7-кой получалось вполне красиво. Хочу с 8 попробовать.
Отредактировано Volga; 30.03.2017 в 16:19. Причина: корректировка | | ||
| 4
- 01.04.2017 - 08:00
| (2) Зарплатную базу свернуть??? | | ||
| 5
- 01.04.2017 - 11:03
|
Ну а что? Я как-то давно вначале ради интереса (и время было) игралась с одной небольшой базой 7.7 Только не "сворачивала" в прямом смысле этого слова, а убирала уволенных. Уволенных не только "в хвостик за год назад", а всех, даже уволенных вчера. (Кстати, почему VZ советует оставить "хвостик в год", не понимаю, для больничных нужно 2 года). Так вот, для работающих мне нужна была вся кадровая история, за все их время, а зарплата она и так только за два года переносится. А уволенные вообще зачем нужны в новой базе. И я их аккуратненько вырезала и удалила вообще. Получилось конечно красиво, но... нудная-нудная ручная работа... На маленькой базе если есть желание и время и нечем больше заняться, сделать такую "свертку" в 7.7 конечно можно, но в общем.. игра того не стоит... но это я уже потом поняла - куда проще было после переноса из 7.7 в 2.5 прибить этих уволенных в 8-ке. | | ||
| 6
- 01.04.2017 - 12:26
|
5-Блондинка в шок > "Кстати, почему VZ советует оставить "хвостик в год"..." - возможны переходящие отклонения (отпуска, например). Или ввели в прошлом периоде за следующий. Лишнее не задействованное всегда можно удалить. | | ||
| 7
- 01.04.2017 - 12:48
|
5-Блондинка в шок > "... нудная-нудная ручная работа." - не такая уж нудная ;) Грохаем записи ЖЗ и СБоров по прошлым периодам. Можно внешней утилой типа wDBFView.exe. Грохаем в справочниках все "мусорные" элементы (на которые ссылок не имеются). Отмечатся давно уволенные сотрудники. Удаление всего возможного. Большая часть "давно уволенных" остается: кадровые данные и всякое такое... Грохаем. Удаление всего возможного. ..... Берем большой напильник для финальной обработки. Для v8, собственно, технология схожа, только чистятся регистры. Главное, продумать порядок: сначала накопительные, потом сведения. | | ||
| 8
- 03.04.2017 - 08:22
|
(7) Почему бы не воспользоваться стандартной Svldcj77.ert ---??? --- С флагом на удаление. | | ||
| 9
- 03.04.2017 - 08:24
| Немного не в тему, простите, я про чистку Зик 7.7 | | ||
| 10
- 03.04.2017 - 12:51
|
8-Robotron460 > Какая цель "свертки"? Удалить все, что заведомо не понадобится. Т.е., "давно уволенных сотрудников" со всеми их записями, а у остальных оставить только актуальные сведения. Которые ходя бы могут понадобится. Естественный шаг: выделить область "давно уволенных" пометкой на удаление. Это безопасно: записи остаются на месте, ситуация обратима. Но удалить "окончательно" не выйдет: есть документы, есть записи в ЖЗ и Сборах. Удалять записи ЖР, действительно, муторно. Штатно. Надо писать что-то, тщательно проверять... Но на наше счастье, в ЖР (таблицах) есть поля, указывающие на период, и тут годятся утили типа wDBFView.exe. Документы Начисление зарплаты и Начисление страховых сборов просто расставляют ВР в ЖР без расчетов. Если записей ВР каких-то периодов не будет, то и документы эти за этот период пометятся легко и быстро. Штатно, главное. И вот тут штатная удаление помеченных объектов снесет эдак 90% "давно уволенных". Бонус: все зашуршит быстрее. Просто из-за отсутствия ненужных записей: любая выборка их пропускает по причине отсутствия, и не применяет к ним фильтры. Заметил? Svldcj77.ert или чьё-то другое творчество нам не понадобилось. Нет забот о их надежности. И дальнейшие шаги во многом опираются на штатные механизмы. Надежность - это основа. Как у ружья: что в радости, что осечка одна на 100 выстрелов? Она будет для тебя самой главной... | | ||
| 11
- 03.04.2017 - 13:10
|
(10),(4) Я использовал штатную свертку от 1С из Uniprocs --- Svldcj77.ert - их две версии от 2002 и 2006гг. отличаются в одну строчку. --- обрезает нормально ЖР | | ||
| 12
- 03.04.2017 - 17:16
| Цитата:
один (Иванов) работает и сегодня, второй (Петров) уволился 29.03.2017 для переноса(сегодня) мне нужны данные ЖР по Иванову за 2015, 2016, 2017 гг, а также все кадровые данные с 2010 года. для переноса мне вообще не нужны данные по Петрову. Никакие. Цитата:
увы. | | ||
| 13
- 03.04.2017 - 18:54
|
(12) Никто не претендует на 1 клик, "напильник" - конечно нужен, но в моем случае, базы за более 10 лет и обрезка заметный плюс. -- Только снимайте флаг "формировать файл" иначе придется разбивать на периоды (сворачивать поэтапно) или будет вываливаться по нехватке памяти. | | ||
| 14
- 03.04.2017 - 19:09
|
13-Robotron460 > "иначе придется разбивать на периоды (сворачивать поэтапно)" Я при свертке всегда разбиваю на периоды. Именно для сохранения промежуточного результата. ОбЫдно начинать все по новому... | | ||
| 15
- 08.04.2017 - 09:04
| Я вот сейчас для ЗУП 2.5 разрабатываю программу по чистке уволеных сотрудников | |
Интернет-форум Краснодарского края и Краснодара |
