Понедельник: Как превратить параллельный расчёт из разового теста в регулярный процесс
Понедельник: Как превратить параллельный расчёт из разового теста в регулярный процесс Привет, коллеги! 👋 В субботу разбирали типовые узкие места, которые ломают параллельный расчёт в 1С:ЗУП. Сегодня — следующий шаг: как сделать так, чтобы это не был разовый акт перед релизом, а регулярный механизм контроля на каждом расчётном цикле. Проблема в том, что многие останавливаются после первого успешного параллельного расчёта. База переехала на продуктив — чек-лист закрыт, все расслабились. А через два месяца — новые виды начислений, новые сотрудники, новые коэффициенты — и расхождения снова вылезают, но уже в «боевом» режиме. Что закладывать в регулярный процесс: - Параллельный расчёт не на одном срезе, а на скользящей выборке: каждый цикл — разные сотрудники, чтобы за квартал покрыть все подразделения. - Статусы в трекере как обязательный gate: «Параллельный расчёт пройден», «НДФЛ/взносы проверены», «Релиз принят». Пока статус не зелёный — расчётный цикл не закрывается. - Фиксация каждого расхождения как инцидента: не «исправили и забыли», а запись в базу знаний — что было, почему, как предотвратить в следующий раз. Недавно был случай: заказчик прошёл первый расчёт чисто, а на третьем цикле всплыли расхождения по северным надбавкам — приняли новых сотрудников из филиала в Мурманске, а настройки территориальных коэффициентов не обновили. Если бы параллельный расчёт был регулярным, а не разовым — поймали бы на копии, а не в отчёте перед СФР. > Главный вывод: параллельный расчёт — это не этап внедрения, а постоянный инструмент. Одна успешная проверка не гарантирует, что следующая пройдёт так же. Контроль качества — это процесс, а не событие. 💬 Как у вас устроен регулярный контроль расчётов — есть статусы в трекере или держится на чьём-то опыте? Делитесь — подскажу, как автоматизировать. 👇 #Кодерлайн 🫰 #1С #ЗУП #контролькачества