Документ «Периоды, оплаченные до начала эксплуатации»

Конфигурация: «Зарплата и управление персоналом для Казахстана 3.1» (ЗУП КЗ). Нумерация документа: строка длиной 11 символов, периодичность нумерации — в пределах года (Year).

1. Назначение и место в учёте

Документ начального ввода данных: им регистрируются периоды отсутствий/начислений сотрудников, которые были оплачены ещё до начала эксплуатации программы (до перехода на ЗУП КЗ), чтобы система знала о состояниях сотрудников (отпуск, болезнь и т.п.) и об исходных данных для перерасчётов и расчёта среднего заработка в будущих периодах. Пользуется им расчётчик/внедренец однократно — на этапе переноса начальных данных при старте учёта в базе; в текущей работе документ не нужен. Документ проводится и пишет сразу в четыре регистра: расчётный регистр «Начисления», регистры сведений «ДанныеСостоянийСотрудников», «ИсходныеДанныеПерерасчетов» и «ПараметрыПериодовСтажаПФР» (последний — наследие российской типовой, см. ниже). Расположение в меню в карте объекта не определено (типично — раздел начального заполнения/переноса данных). Прямых движений по казахстанским налогам и взносам (ИПН/ОПВ/СО/ВОСМС) документ не делает — он формирует исходную базу данных расчёта.

2. Структура объекта

2.1 Реквизиты шапки

Все реквизиты из metadata.attributes (имена дословно):

2.2 Табличные части

Начисления — основная ТЧ: по строке на каждый оплаченный период сотрудника (все 33 колонки из metadata, имена дословно):

ФизическиеЛица — служебная ТЧ со списком физлиц документа:

ДополнительныеРеквизиты — стандартная подсистема дополнительных реквизитов:

2.3 Формы

(не определено) — в карте объекта список форм пуст (metadata.forms = []), собственные UI-структуры в выгрузку не попали.

3. Сценарии работы

3.1 Сценарий: «Начальный ввод оплаченного отпуска, выданного до старта программы (Create)»

• Когда применяется: при внедрении ЗУП КЗ: сотруднику до начала эксплуатации базы уже оплатили отпуск, который захватывает периоды после старта учёта; система должна знать об этом периоде и сумме.
• Шаги пользователя: 1. Создать документ «Периоды, оплаченные до начала эксплуатации». 2. Заполнить «Организация» (единственное обязательное поле, ShowError). 3. Указать «ПериодРегистрации» (месяц, к которому относятся данные) и при необходимости «Подразделение». 4. Выбрать «ВидРасчета» — вид начисления (план видов расчёта «Начисления»), которым период был оплачен. 5. В ТЧ «Начисления» добавить строку: «Сотрудник», «ДатаНачала», «ДатаОкончания», «ВидПериода» (состояние сотрудника), оплату — «Результат», время — «ОплаченоДней»/«ОплаченоЧасов», нормы — «НормаДней»/«НормаЧасов». 6. Провести документ.
• На что обратить внимание: колонки «ВидСтажаПФР», «КодВычета» (ВидыВычетовНДФЛ), «СкидкаПоВзносам» — российское наследие типовой, для казахстанского учёта не используются.
• Какие проверки сработают: платформенная проверка заполнения только для «Организация» (ShowError); программные проверки в карте не определены (BSL отсутствует в выгрузке).
• Что произойдёт после «Провести»: документ сформирует движения по 4 регистрам: CalculationRegister.Начисления (строки начислений периода), InformationRegister.ДанныеСостоянийСотрудников (состояние сотрудника на введённый интервал), InformationRegister.ИсходныеДанныеПерерасчетов (база для будущих перерасчётов), InformationRegister.ПараметрыПериодовСтажаПФР (RU-наследие).

3.2 Сценарий: «Массовый ввод по нескольким сотрудникам»

• Когда применяется: на старте эксплуатации оплаченные вперёд периоды есть сразу у нескольких сотрудников с одним видом расчёта.
• Шаги пользователя: 1. Создать документ, заполнить шапку («Организация», «ПериодРегистрации», «ВидРасчета»). 2. В ТЧ «Начисления» добавить по строке на каждого сотрудника и каждый его период (сотрудник может встречаться несколькими строками с разными интервалами «ДатаНачала»–«ДатаОкончания»). 3. Провести.
• На что обратить внимание: строковое поле шапки «КраткийСоставДокумента» (синоним «Сотрудники») — служебное представление состава для списка документов, вручную его вести не нужно; ТЧ «ФизическиеЛица» — служебный список физлиц документа.

3.3 Сценарий: «Корректировка ранее выполненного начисления»

• Когда применяется: нужно скорректировать введённые исходные данные относительно того, что уже было начислено до эксплуатации.
• Шаги пользователя: 1. В строке ТЧ «Начисления» установить флаг «КорректировкаРанееВыполненногоНачисления». 2. Заполнить «РанееНачислено» (сумма, начисленная ранее) и «Результат». 3. Провести документ.
• Проверки: программная логика в карте не определена (BSL пуст); контролируйте суммы вручную.

3.4 Сценарий: «Ввод времени в целом за период / в часах»

• Когда применяется: оплаченный период задаётся не по дням, а часами, либо одним числом за весь интервал без помесячной разбивки.
• Шаги пользователя: в строке ТЧ установить флаги «ВремяВЧасах» и/или «ВремяВЦеломЗаПериод», заполнить «ОтработаноЧасов»/«ОплаченоЧасов» и «НормаЧасов», при необходимости — «ПериодРегистрацииВремени», «ПериодРегистрацииНормыВремени», графики («ГрафикРаботы», «ГрафикРаботыНорма», «ОбщийГрафик», «ВидУчетаВремени»).
• На что обратить внимание: «ГрафикРаботы» и «ГрафикРаботыНорма» — составного типа (CatalogRef.Сотрудники или CatalogRef.ГрафикиРаботыСотрудников): норму можно брать по графику сотрудника либо по конкретному графику.

3.5 Сценарий: «Просмотр / исправление введённых данных (Read / Update)»

• Когда применяется: проверка или правка начального ввода после старта эксплуатации.
• Шаги пользователя: 1. Найти документ в списке (номер — строка из 11 знаков, нумерация в пределах года; в списке виден состав через «КраткийСоставДокумента»). 2. Исправить строки ТЧ «Начисления» (даты, суммы, флаги фиксации «ФиксРасчет»/«ФиксЗаполнение»/«ФиксРасчетВремени» при ручных правках). 3. Перепровести документ — движения по всем 4 регистрам перезапишутся.
• Что произойдёт: старые движения заменяются новыми; от этих данных зависят последующие перерасчёты (регистр «ИсходныеДанныеПерерасчетов») и состояния сотрудников.

4. Per-field reference

BSL-анализ в карте пуст (bsl_static = [], bsl_summaries = []) — обработчики «ПриИзменении» и «ОбработкаПроверкиЗаполнения» не определены; справка по метаданным:

• Организация (CatalogRef.Организации): единственный реквизит с контролем заполнения (ShowError); без него документ не запишется.
• ПериодРегистрации (xs:dateTime): период (месяц) регистрации вводимых данных; не проверяется, но содержательно ключевой для расчётных регистров.
• ВидРасчета (ChartOfCalculationTypesRef.Начисления): вид начисления, которым оплачены периоды; общий для документа (в строках есть служебный «ИдентификаторСтрокиВидаРасчета»).
• Подразделение (CatalogRef.ПодразделенияОрганизаций): в шапке — общее; в строке ТЧ — своё, перекрывает шапку при заполнении (программная логика не определена в карте).
• ТЧ Начисления.Сотрудник / ДатаНачала / ДатаОкончания / ВидПериода: смысловой минимум строки — кто, какой интервал, какое состояние (EnumRef.СостоянияСотрудника).
• ТЧ Начисления.Результат / ОплаченоДней / ОплаченоЧасов: сумма и оплаченное время периода — то, что «уже оплачено до эксплуатации».
• ТЧ Начисления.НормаДней / НормаЧасов / РасчетнаяБазаЗаЕдиницуНормыВремени: нормы времени и база за единицу нормы — исходные данные для будущих перерасчётов среднего.
• ТЧ Начисления.ФиксРасчет / ФиксСтрока / ФиксЗаполнение / ФиксРасчетВремени (xs:boolean): флаги фиксации ручных правок — типовая механика «не пересчитывать автоматически».
• ТЧ Начисления.ВидСтажаПФР (EnumRef.ВидыСтажаПФР2014): RU-наследие (стаж ПФР 2014, Россия); в КЗ-учёте не используется, но пишется в регистр «ПараметрыПериодовСтажаПФР».
• ТЧ Начисления.КодВычета (CatalogRef.ВидыВычетовНДФЛ) и СуммаВычета: RU-наследие (вычеты НДФЛ); казахстанские вычеты по ИПН ведутся своими механизмами.
• ТЧ Начисления.СкидкаПоВзносам (xs:decimal): RU-механика страховых взносов, наследие типовой.
• ТЧ Начисления.РанееНачислено / КорректировкаРанееВыполненногоНачисления: пара для сценария корректировки (см. 3.3).
• КраткийСоставДокумента (xs:string, синоним «Сотрудники»): автопредставление состава; вручную не заполнять.
• Ответственный (CatalogRef.Пользователи), Комментарий (xs:string): служебные, необязательные.

5. Бизнес-логика

• Обработчики событий: (не определено) — BSL-модули объекта и форм в выгрузке отсутствуют.
• Проводки/движения (ОбработкаПроведения): текст обработчика не выгружен, но по metadata.register_records документ пишет в:
• CalculationRegister.Начисления — расчётный регистр начислений (строки оплаченных периодов);
• InformationRegister.ДанныеСостоянийСотрудников — состояния сотрудников на введённые интервалы;
• InformationRegister.ИсходныеДанныеПерерасчетов — исходные данные для последующих перерасчётов;
• InformationRegister.ПараметрыПериодовСтажаПФР — параметры стажа ПФР (RU-наследие типовой).
• Валидации (ОбработкаПроверкиЗаполнения): (не определено) программно; декларативно обязательна только «Организация» (ShowError).
• Зависимости от других модулей: (не определено) — bsl_summaries пуст. Используются типовые подсистемы: план видов расчёта «Начисления», дополнительные реквизиты (ПВХ «ДополнительныеРеквизитыИСведения»).

6. Связи с другими объектами

6.1 Документы-основания

(не определено) — metadata.based_on пуст: документ вводится только вручную, «на основании» не создаётся.

6.2 Кто создаётся на основании этого

(не определено) — metadata.inverse_based_on пуст.

6.3 Регистры движения

Из metadata.register_records (имена дословно): - InformationRegister.ИсходныеДанныеПерерасчетов - InformationRegister.ДанныеСостоянийСотрудников - CalculationRegister.Начисления - InformationRegister.ПараметрыПериодовСтажаПФР (RU-наследие)

7. Заметки для ИИ-агента

1. Это документ начального ввода при внедрении, а не текущего учёта: используй его только для периодов, оплаченных ДО начала эксплуатации базы. Для текущих отпусков/больничных есть свои документы.
2. Обязательное поле всего одно — «Организация» (ShowError); но содержательный минимум строки ТЧ «Начисления»: Сотрудник, ДатаНачала, ДатаОкончания, ВидПериода, Результат и оплаченное время (ОплаченоДней/ОплаченоЧасов). Без них движение в регистры будет пустым по смыслу.
3. Не заполняй RU-наследие: ВидСтажаПФР (ВидыСтажаПФР2014), КодВычета (ВидыВычетовНДФЛ), СуммаВычета, СкидкаПоВзносам — это российская типовая механика (ПФР/НДФЛ/взносы); в Казахстане действуют ИПН/ОПВ/СО/ВОСМС, которые этим документом напрямую не регистрируются.
4. Документ проводится и пишет в 4 регистра (Начисления, ДанныеСостоянийСотрудников, ИсходныеДанныеПерерасчетов, ПараметрыПериодовСтажаПФР) — проверка успеха автоматизации = появились движения, а не просто запись документа.
5. КраткийСоставДокумента (синоним «Сотрудники») и ТЧ ФизическиеЛица — служебные, формируются для представления/отборов; не пытайся вводить их руками.
6. Флаги ФиксРасчет, ФиксЗаполнение, ФиксРасчетВремени, ФиксСтрока ставь только при ручной правке рассчитанных значений — они фиксируют строку от автопересчёта.
7. ГрафикРаботы и ГрафикРаботыНорма — составного типа (Сотрудники ИЛИ ГрафикиРаботыСотрудников): при программном заполнении укажи правильный тип значения, иначе подбор значения в поле откроет выбор типа.
8. Собственных форм и BSL-обработчиков в карте нет — автозаполнений «ПриИзменении» не жди; перепроведение после правок обязательно, иначе регистры останутся со старыми данными.