От Excel к актам ГПХ и расчетным данным: как организовать загрузку в ЗУП 3.1

Можно ли взять один Excel-файл, массово создать в ЗУП акты по договорам ГПХ и из тех же строк заполнить данные для расчета зарплаты?

На первый взгляд задача выглядит простой. Находим сотрудника, находим договор, переносим сумму в акт, а нужный показатель — в документ «Данные для расчета зарплаты».

Но уже на небольшом реестре появляются вопросы:

• одна строка файла — это один акт или отдельная работа внутри общего акта;
• сумма акта повторена в нескольких строках или каждую сумму нужно прибавить;
• как выбрать договор, если у одного исполнителя их несколько;
• можно ли считать ФИО достаточным признаком сотрудника;
• какому объекту принадлежит показатель: сотруднику, подразделению или организации;
• является значение показателя итогом за месяц или отдельным событием, которое нужно накопить;
• нужно создать новый документ расчетных данных или заполнить уже выбранный;
• что произойдет при повторной загрузке и после частично выполненного запуска;
• не попадет ли одна и та же сумма в расчет дважды.

Загрузка становится полезной, когда дает проверяемый ответ на эти вопросы. Само по себе появление документов в списке еще не означает, что в них попали правильные суммы и что дальнейший расчет использует их по назначению.

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

 

Сначала определим границу задачи

Предположим, в базе уже заведены сотрудники, договоры ГПХ, необходимые начисления и шаблон ввода расчетных данных. Внешний реестр содержит сведения о выполненных работах.

Полезная узкая задача обработки:

проверить реестр, однозначно сопоставить его с существующими данными ЗУП и подготовить предусмотренные учетной схемой документы без повторного ввода одних и тех же событий.

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

Автоматическое заведение сотрудников и договоров, изменение кадровых условий, настройка новых начислений и создание ведомостей — самостоятельные задачи. Для загрузки актов и показателей они не становятся обязательными только потому, что какого-то объекта не удалось найти.

Есть еще одна существенная граница. Формулировка «заполнить данные документа» не определяет, должен ли загрузчик создавать новые документы или переносить значения в уже существующий. Эти режимы требуют разных правил, поэтому к ним вернемся отдельно.

 

Акт, расчетные данные, начисление и выплата — разные результаты

В типовом сценарии договора подряда с оплатой по актам документ «Акт выполненных работ» регистрирует принятую сумму по договору. Начисление выполняется последующим расчетным документом: «Начисление зарплаты и взносов» либо «Начисления по договорам, в том числе авторским». Эта последовательность описана в учебном материале 1С по договорам подряда.

Документ «Данные для расчета зарплаты» вводит предусмотренные настройками исходные показатели. Он не является универсальным документом начисления и сам по себе не оформляет выплату.

 

Результат	Что требуется проверить	Что из него еще не следует
Акт по договору	Договор, исполнитель, принятая сумма, даты и предусмотренные реквизиты	Что вознаграждение уже начислено или выплачено
Расчетные данные	Шаблон, показатель, получатель значения, период и способ ввода	Что показатель участвует именно в нужном начислении
Начисление	Результат типового расчета, основания и использованные показатели	Что оформлена выплата
Выплата	Предусмотренные учетной схемой платежные документы	Что загрузка актов должна создавать их автоматически

 

Даже наличие печатной формы акта не подтверждает его подписание сторонами. Обработка создает учетный документ; юридическое оформление работ и подтверждение первичных документов остаются отдельной частью процесса.

 

Главный вопрос: зачем одни данные направляются в два документа

Из одного реестра можно получить два разных результата. Например, сумма принятого вознаграждения относится к акту, а натуральный объем — к согласованному показателю.

Но нельзя автоматически считать, что оба результата должны независимо начислить одно и то же вознаграждение.

Предположим, акт регистрирует 15 000 руб. Затем в расчетные данные загружается показатель, по которому дополнительное начисление рассчитывает еще 15 000 руб. Если оба начисления включены в один расчет как самостоятельные оплаты одной работы, получится повторное начисление.

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

До разработки нужно проследить всю цепочку:

1. какой факт подтверждает акт;
2. какой факт представляет показатель;
3. в какой формуле и для какого получателя он используется;
4. какие документы начисления попадут в итоговый расчет;
5. какой результат ожидается при ручном вводе тех же данных.

Если назначение второй ветки неизвестно, правильность загрузки нельзя доказать только проверкой заполненных ячеек.

 

Возьмем простой реестр выполненных работ

Пусть в одной организации для условного сотрудника E001 зарегистрированы два договора: GPH014 и GPH025. По ним приняты два акта. Первый акт объединяет две работы, второй — одну.

В Excel пришел такой реестр:

 

ID события	Сотрудник	Договор	ID акта	Объем работы	Полная сумма акта, руб.
R101	E001	GPH014	ACT08	4	15 000
R102	E001	GPH014	ACT08	6	15 000
R103	E001	GPH025	ACT09	3	9 000

 

Идентификаторы здесь относятся к внешнему реестру. Они не являются именами реквизитов метаданных ЗУП. Наличие соответствующих полей и место хранения связи с документами нужно определить для конкретной реализации.

Для примера явно принимаем два правила:

• колонка суммы содержит полную сумму акта, повторенную для каждой входящей в него работы;
• объем содержит отдельное приращение в одинаковых единицах; его можно суммировать для согласованного показателя сотрудника.

В результате должны получиться два акта:

ACT08 по GPH014: 15 000 руб.
ACT09 по GPH025:  9 000 руб.
Итого по актам: 24 000 руб.

Объем E001: 4 + 6 + 3 = 13

Если без понимания структуры просто сложить денежную колонку, получится:

15 000 + 15 000 + 9 000 = 39 000 руб.

Разница в 15 000 руб. возникла до обращения к объектам 1С. Ошибка находится в смысле исходной строки, а не в методе записи документа.

 

Один акт — не обязательно одна строка

Если сумма акта повторяется в строках его работ, обработка должна проверить согласованность этой суммы внутри группы и взять ее один раз.

Для ACT08 значения 15 000 и 15 000 согласованы. Если во второй строке указано 16 000, группа противоречива. Выбор первой строки, максимальной суммы или среднего значения скроет ошибку. Без специального согласованного правила такой акт создавать нельзя.

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

Группировать акты только по сотруднику и месяцу также нельзя. Один исполнитель может иметь несколько договоров и несколько самостоятельных актов по одному договору.

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

 

Почему одинаковые значения показателя нельзя всегда складывать

Возьмем две строки одного сотрудника с числами 4 и 6.

Они могут означать:

• две выполненные работы: итоговый объем равен 10;
• предварительный и окончательный месячный итог: актуальное значение равно 6;
• два значения на разные даты оперативного учета;
• разные показатели или разные единицы измерения;
• повтор одного события, который нельзя учитывать второй раз.

Название колонки «Количество» не позволяет выбрать между этими вариантами.

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

Для объемов 4, 6 и 3 из нашего примера итог 13 корректен только при принятых выше условиях. Он не доказывает, что так же нужно загружать любой месячный показатель ЗУП.

 

Шаблон ввода определяет структуру расчетных данных

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

Для каждого загружаемого показателя нужно зафиксировать:

 

Настройка	Почему она меняет загрузку
Получатель: сотрудник, подразделение, организация	Определяет, к чему относится число и по какому объекту его сопоставлять
Периодичность и способ использования	Разделяют значение на дату, итог месяца и накопление отдельных событий
Тип, точность и допустимость нуля	Определяют проверку значения; пустота и ноль могут иметь разный смысл
Состав шаблона	Показывает, какие показатели действительно можно ввести этим документом
Формула и назначение начисления	Определяют дальнейшее применение данных; одно наличие показателя в справочнике недостаточно
Ограничения шапки документа	Влияют на возможность объединить строки разных подразделений или организаций

 

Отдельный нюанс — виды показателей. Постоянные показатели сотрудника обычно назначаются документами изменения оплаты труда, в том числе кадровыми. Для «Данные для расчета зарплаты» предусмотрены, в частности, постоянные показатели организаций и подразделений, а также разовые и оперативные показатели с соответствующими настройками. Часть разовых показателей сотрудника вводится межрасчетными документами. Вычисляемые показатели получают значение при расчете. Эта классификация приведена в материале 1С о формулах начислений.

Поэтому обещание «загрузим любые показатели через один документ» технически слишком широкое. Сначала нужно установить, что выбранный показатель допускает именно такой ввод.

Шаблон со скалярными показателями, учет времени и ввод сдельных работ тоже нельзя считать одной и той же таблицей с разными заголовками. Если нужен другой тип данных, его структура и правила проверяются отдельно.

 

Договорная аналитика может закончиться на границе показателя

В нашем реестре сотрудник E001 имеет два договора. Акты необходимо разделить по договорам. Но выбранный показатель может хранить одно значение сотрудника за период без аналитики договора.

Тогда после согласованного суммирования в расчетные данные попадет 13, а распределение 10 по GPH014 и 3 по GPH025 останется расшифровкой исходного реестра.

Добавление колонки «Договор» в форму внешней обработки само по себе не создает договорную аналитику в типовом хранении и формуле начисления.

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

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

 

Физическое лицо, сотрудник и договор — три разных сопоставления

ФИО удобно для просмотра, но ненадежно в роли уникального ключа. Возможны однофамильцы, смена фамилии, различия в написании и несколько записей сотрудника, связанных с одним физическим лицом.

Даже однозначно найденное физическое лицо еще не определяет нужную запись сотрудника и договор для операции.

Предпочтительно согласовать внешний идентификатор и его однозначное соответствие объекту базы. Если используются код или табельный номер, нужно проверить их фактическую уникальность в выбранной области поиска. Нельзя объявлять их уникальными во всех базах только по названию поля.

Для каждого сопоставления должны быть различимы три исхода:

1. найден один допустимый объект;
2. не найден ни один;
3. найдено несколько кандидатов.

Третий исход нельзя превращать в первый выбором «самого свежего» или первой строки запроса. Пользователь должен уточнить соответствие либо исправить файл.

В типовой ЗУП договор ГПХ может быть оформлен как для работающего по трудовому договору сотрудника, так и для исполнителя без такого трудового договора. Универсальное ограничение «искать только нештатных» отсекает допустимые случаи.

При отсутствии нужного объекта узкий загрузчик сообщает об этом. Он не создает молча нового сотрудника и не заполняет кадровые сведения предположениями.

 

Найти договор — больше, чем сравнить его номер

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

Номер и дата полезны как признаки сопоставления, но не заменяют ссылку на конкретный объект после проверки. Договоры выполнения работ и оказания услуг и договоры авторского заказа нельзя механически считать одним видом основания.

Далее проверяется способ оплаты. Для рассматриваемой ветки актов нужен сценарий оплаты по актам. Если договор предусматривает иную схему, обработка не должна менять ее лишь для того, чтобы строка Excel прошла загрузку.

Проверки дат тоже требуют смысла. Дата приемки или дата оформления акта может отличаться от интервала выполнения работ. Простое правило «дата акта вне срока договора — ошибка» без учета учетной схемы может отвергнуть корректный поздно оформленный документ.

Аналогично превышение исходной суммы договора не следует автоматически исправлять обрезанием суммы акта: возможны изменения условий, дополнительные соглашения или ошибка реестра. Нужны согласованная проверка и понятный результат, а не скрытая корректировка данных.

 

Дата документа и месяц расчета не взаимозаменяемы

В реестре могут одновременно присутствовать:

• дата оформления акта;
• период выполнения работ;
• месяц, к которому относятся вводимые расчетные данные;
• дата события для оперативного показателя;
• дата самого документа ввода;
• планируемая дата выплаты или получения дохода, если она предусмотрена соответствующим документом и сценарием.

Например, реестр за сентябрь может быть обработан 5 октября. Из этого не следует, что данные нужно отнести к октябрю или заменить все даты на день загрузки.

Для оперативного показателя объемы 4, 6 и 3 могут относиться к разным датам. Даже если месячный итог равен 13, объединение их одной датой способно изменить результат расчета за часть месяца. Возможность такого объединения нужно доказать отдельно.

Не каждая дата внешнего реестра имеет одноименный реквизит в типовом документе. Сначала устанавливается ее назначение, затем — доступное место хранения и влияние на расчет. Создавать вымышленные реквизиты в описании алгоритма нельзя.

Если обязательная дата отсутствует, подстановка текущей даты скрывает недостаток исходных данных. Она допустима лишь как явно согласованное правило для конкретного поля.

 

Сумма к начислению и сумма на руки — разные данные

В заголовке «Сумма» может скрываться стоимость принятой работы, сумма начисления, сумма после удержаний или оплаченный остаток. Для акта нужно определить именно предусмотренный учетной схемой смысл.

В нашем примере 15 000 и 9 000 — согласованные суммы принятого вознаграждения до удержаний. Это условие примера, а не универсальное толкование любой денежной колонки.

Не следует восстанавливать сумму начисления из суммы «на руки» делением на постоянный коэффициент. Такой расчет зависит от фактических правил учета и данных конкретного получателя. Налоги и взносы должен рассчитать типовой механизм.

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

Точность чисел, единицы объемов и округление нужно согласовать. Объем 1,5 часа, 1,5 условной единицы и 1,5 тысячи рублей — три разных значения.

Ноль, пустота и отрицательное число проверяются отдельно. Нулевое значение показателя может быть допустимым и значимым. Отрицательный акт нельзя автоматически превратить в положительный модулем числа; для исправлений нужен предусмотренный сценарий. Правило «пропускать все нули» тоже требует обоснования для каждой ветки.

 

У двух веток загрузки разные ключи

Не стоит искать один универсальный ключ «сотрудник + месяц» для всего процесса.

 

Объект проверки	Логическая идентичность	Что меняется при ошибке
Исходное событие	Согласованный источник + область идентификаторов + стабильный ID события	Повтор одной работы может быть принят за новую
Акт	Организация + конкретный договор + внешний ID акта	Разные акты сливаются либо один акт раздваивается
Документ расчетных данных	Совместимые организация, шаблон, период и ограничения шапки	В один документ попадают несовместимые группы
Значение показателя	Получатель + конкретный показатель + предусмотренная периодом и настройками дата	Складываются разные сущности или перезаписывается чужое значение

 

Это смысловые ключи для проектирования, а не готовые составы индексов и реквизитов ЗУП. В конкретной конфигурации они уточняются по метаданным, типовым процедурам и настройкам.

Для расчетных данных правила совместимости документа и правила объединения значений — отдельные проверки. Два значения могут относиться к одному документу, но к разным получателям. Два события одного показателя могут требовать разных дат или сохранения отдельных записей.

 

Формат Excel должен быть договоренностью

До переноса в ЗУП нужно получить однозначную таблицу. Минимальный контракт файла определяет лист, строку заголовков, обязательные колонки, типы значений, единицы и признаки конца данных.

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

Практические нюансы:

• идентификатор 00125 не должен стать числом 125, если ведущие нули значимы;
• число в числовой ячейке и строка с пробелами, запятой и символом валюты требуют разных правил разбора;
• даты в текстовом виде нуждаются в определенном формате; неоднозначное 03/04 нельзя угадывать;
• для формул нужно определить, читается сохраненный результат или требуется подготовленный файл со значениями; механизм чтения не обязан пересчитывать Excel;
• скрытые и отфильтрованные строки не обязательно исключаются при программном чтении;
• объединенные ячейки и пустые повторяющиеся поля нельзя заполнять значением сверху без согласованного правила;
• итоги, комментарии и повторные заголовки внутри листа не должны становиться строками работ.

Рекомендуемый для узкой задачи вариант — простой лист без объединений, с определенными заголовками и подготовленными значениями. Дополнительные форматы имеет смысл поддерживать по реальной потребности, а не обещать произвольный Excel.

Макросы книги для такой загрузки выполнять не требуется.

 

Чтение файла зависит от среды запуска

Выбор Excel на компьютере пользователя не означает, что тот же путь доступен серверу 1С. В клиент-серверной базе это могут быть разные компьютеры. Для веб-клиента также нужен предусмотренный способ передачи файла.

Разделение клиентских и серверных файловых операций описано в стандарте разработки 1С. Конкретный механизм передачи и чтения выбирается по платформе, используемым библиотекам и режиму исполнения.

Зависимость от установленного Microsoft Excel через COM сужает область работы. Такой подход требует соответствующей среды Windows там, где выполняется вызов, и не является универсальным для Linux, macOS и веб-клиента. 1С рекомендует учитывать переносимость и использовать подходящие платформенные механизмы — см. стандарт работы в Linux и macOS.

Поддержка формата файлов и поддержка среды — отдельные утверждения. Успешное чтение XLSX в файловой базе под Windows не подтверждает работу того же загрузчика в тонком клиенте с сервером Linux.

Временный файл должен удаляться по завершении работы, а ошибочный путь или неподдерживаемый формат — давать понятное сообщение до создания документов.

 

Сначала предварительная проверка, затем создание документов

Первое действие после чтения файла — не запись актов, а нормализация и проверка данных.

Пользователю нужен предварительный результат:

• какие сотрудники и договоры сопоставлены;
• какие акты будут созданы и почему строки объединились;
• какой шаблон и какие показатели используются;
• какие значения получатся после согласованной агрегации;
• какие существующие документы будут заполнены или оставлены без изменения;
• где обнаружен повтор, конфликт либо неоднозначность;
• какие операции заблокированы.

Для нашего примера проверка должна показать три события, две группы актов на 24 000 руб. и объем 13. Итог 39 000 руб. по денежной колонке можно показать как контроль исходных ячеек, но нельзя подписывать его «Сумма создаваемых актов».

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

Ошибки нужно разделить по последствиям. Отсутствующий заголовок может блокировать файл целиком. Неоднозначный договор — конкретную группу актов. Ошибка общей формулы или шаблона способна заблокировать вторую ветку для всего реестра.

Предварительная проверка не делает данные базы неизменными. Между просмотром и записью пользователь может изменить договор, документ или настройки. Существенные условия повторно проверяются непосредственно перед записью.

 

Новый документ и заполнение выбранного документа — разные режимы

Если создается новый документ «Данные для расчета зарплаты», сначала определяется состав совместимой группы, затем заполняется шапка и предусмотренные шаблоном значения.

Если заполняется существующий документ, нужно дополнительно ответить: какие его данные принадлежат этой загрузке и что делать с уже введенными значениями?

 

Режим	Необходимое правило
Добавить отсутствующие значения	Как определить совпадение ключа и что делать при обнаружении существующего значения
Обновить согласованные значения	Какие ключи можно менять, как показывается разница и как сохраняются остальные данные
Полностью заменить содержимое	Почему допустимо удаление ранее введенных данных и как пользователь видит объем замены

 

Последний режим нельзя назначать молча. В документе могут быть ручные строки, другие показатели, автоматически заполненный список сотрудников и данные другого реестра.

Например, файл содержит значение одного показателя для E001. Из этого не следует, что нужно обнулить этот показатель у остальных сотрудников, удалить значение другого показателя у E001 или данные сотрудника E002.

Если в выбранном документе для E001 уже введено 8, а файл дает итог 13, возможны разные последствия. Замена на 13 корректна только при разрешенном обновлении этого значения. Прибавление даст 21 и допустимо только если исходные 8 и новые 13 — независимые приращения, а не перекрывающиеся итоги. Если происхождение прежнего значения не установлено, нужно показать конфликт.

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

 

Типовая логика должна остаться владельцем учетного результата

Обработка должна обращаться к предусмотренным объектам и процедурам конкретной версии конфигурации, сохраняя обязательные реквизиты, проверки и правила проведения.

Присвоить значения реквизитам объекта — не всегда то же самое, что выполнить интерактивное заполнение формы. Часть зависимого заполнения может происходить в обработчиках формы или в отдельных типовых процедурах. Этот маршрут нужно исследовать по реальным модулям целевой конфигурации.

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

Прямая запись в регистры вместо документов обходит их учетный смысл и усложняет проверку. Для рассматриваемой задачи сначала используется типовой документный маршрут.

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

 

Запись и проведение нужно показывать отдельно

Записанный документ может остаться непроведенным. Успешная запись акта еще не подтверждает успешное проведение, а сохранение расчетных данных не подтверждает их доступность для нужного расчета.

Для каждого режима заранее определяются:

• создаются ли только документы для проверки;
• выполняется ли автоматическое проведение;
• какое состояние считается успешным для каждой ветки;
• какой дальнейший ручной шаг необходим.

Если акт записан, а проведение завершилось ошибкой, результат должен прямо сообщить «Акт записан, проведение не выполнено» и дать ссылку на документ. Скрывать его под общим статусом «Ошибка строки» опасно: при повторе пользователь может создать второй акт.

Права на чтение, создание, изменение и проведение также проверяются раздельно. Работа под полными правами разработчика не подтверждает работу под ролью расчетчика.

Запрет изменения данных, ограничения доступа и типовые проверки не обходятся ради массовой загрузки. Изменение проведенных документов требует предусмотренного учетного сценария.

 

Повторная загрузка начинается с идентичности события

Имя файла, его контрольная сумма и номер строки полезны для диагностики. Но они не дают надежной идентичности хозяйственного события.

Тот же акт может прийти в другом файле, после сортировки строк или с исправленным комментарием. В то же время два разных акта могут иметь одинаковые дату и сумму.

Нужен стабильный признак источника: внешний ID акта для первой ветки и ID события либо согласованная идентичность итогового набора для второй. Область уникальности должна быть определена. Например, если источник нумерует акты заново каждый год, один номер без года недостаточен.

При повторе необходимо различать:

1. то же событие с теми же значимыми данными — новая запись не нужна;
2. то же событие с измененными данными — требуется показать изменение и применить согласованный сценарий;
3. новое событие — может быть создан новый результат;
4. нет доказанного соответствия — требуется уточнение, а не уверенный автоматический пропуск.

Связь внешнего события с фактическим результатом должна сохраняться между запусками. Где ее хранить — решение конкретной реализации с учетом допустимых доработок и режима работы. Ее нужно согласованно сохранять с документами и учитывать при восстановлении после сбоя.

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

Найденный вручную документ с такой же суммой и датой нельзя автоматически объявить результатом предыдущего импорта и перезаписать.

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

 

У частичного выполнения две ветки, а не одна ошибка строки

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

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

Связь не всегда имеет вид «одна строка — два документа». В примере две группы актов могут давать значения одного документа расчетных данных. Поэтому единицу совместного выполнения нельзя выбирать просто по номеру строки Excel.

Возможны две политики:

• согласованная бизнес-группа выполняется целиком либо откатывается;
• ветки выполняются независимо, а частичный результат виден и корректно возобновляется.

Выбор зависит от требуемого результата и структуры групп. Его нужно сделать до записи, включая правила восстановления после сбоя.

Одна длительная транзакция на весь произвольный файл не является универсальным решением. Границы транзакций должны соответствовать логическим результатам, а ошибки независимых групп — не скрывать уже созданные документы.

 

Повторная проверка не устраняет гонку двух загрузчиков

Два пользователя могут одновременно проверить, что ACT08 еще не загружен, и оба попытаться создать его.

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

Если первая версия рассчитана на одного оператора и параллельная загрузка организационно запрещена, это нужно назвать ограничением. Нельзя подписывать такую реализацию как защищенную от конкурентных запусков.

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

 

Исправление реестра — отдельный сценарий

Повтор с тем же ID и другой суммой — не обычная новая загрузка. Нужно определить, можно ли изменить прежний результат, требуется ли корректировка и как это влияет на уже выполненный расчет.

Особенно важно разделить исправление непроведенного документа и исправление данных закрытого или рассчитанного периода. Простая перезапись может оставить зависимые результаты в прежнем состоянии.

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

Для выбранной базы нужно проверить допустимый типовой маршрут, состояние исходного документа и последствия для расчета. Автоматический запуск перерасчета или массовое перепроведение не добавляются к задаче без отдельного требования.

 

Проверять нужно фактические документы, а затем учетное следствие

После записи результат полезно повторно прочитать из базы и сравнить с ожидаемым:

• какой именно договор и сотрудник попали в акт;
• какова сумма и состояние проведения;
• какой шаблон, период и получатели записаны в расчетных данных;
• какие значения сохранены по согласованным ключам;
• какие ручные данные остались на месте;
• какие ссылки сохранены для повтора и восстановления.

Это проверяет результат записи, но не заменяет проверку дальнейшего расчета.

Для приемки нужен контрольный сценарий в тестовой базе: те же исходные сведения вводятся штатным способом, затем выполняется предусмотренный типовой расчет. Результат загрузки сравнивается с результатом ручного ввода при одинаковых настройках и датах.

Для нашего примера должны быть подтверждены два акта на 24 000 руб., правильное представление объемов и ожидаемое использование показателя. Отдельно проверяется, что одна работа не оплачивается дважды из-за одновременного участия двух веток.

Если настройка начисления меняется после загрузки, прежняя проверка формулы уже не доказывает правильность нового расчета.

 

Копия рабочей базы не обязательна, доказательства — обязательны

Наличие персональных данных может исключать передачу рабочей базы. Это не повод подменять испытания обещанием «в типовой должно работать».

Практический путь проверки:

1. уточнить полный продукт и редакцию, релизы платформы и конфигурации, режим базы, клиент, ОС, настройки и влияющие расширения;
2. получить обезличенный пример структуры Excel и согласованные ожидаемые результаты;
3. подготовить синтетическую базу нужного продукта и релиза с двумя договорами одного исполнителя, нужными шаблонами и формулами;
4. проверить импорт, повтор, ошибки и ручной контрольный расчет;
5. выполнить согласованный приемочный прогон в среде заказчика под рабочей ролью и зафиксировать результат.

Синтетический пример должен сохранять существенные связи, а не просто содержать одну строку «Иванов — 1000». Полезны два одноименных сотрудника, несколько договоров, повторный акт и несколько значений показателя.

Для исследования структуры не нужны реальные паспортные данные и банковские реквизиты. Но отсутствие копии базы не доказывает отсутствие расширений и особенностей настройки. Если их влияние не проверено, ограничение должно остаться в результатах приемки.

 

Что означает поддержка конкретной конфигурации

Исходная целевая среда этой задачи — платформа 8.3.27.2214 и ЗУП 3.1.38.92. Существование указанного релиза подтверждает официальное описание обновления. Оно не подтверждает работоспособность еще не испытанной внешней обработки.

Полное наименование продукта и вариант поставки нужно уточнить. Формулировка «редакция 3.1» сама по себе не позволяет объявить проверенными Базовую, ПРОФ и КОРП.

 

Среда или конфигурация	Что требуется установить	Статус для этой статьи
ЗУП 3.1.38.92 на 8.3.27.2214	Точный продукт, метаданные, настройки, запись, проведение и контрольный расчет	Целевая среда из исходной задачи; запуск обработки не выполнен
ЗУП Базовая, ПРОФ, КОРП	Применимость реализации и доступных механизмов в каждом заявленном варианте	Общая совместимость не заявлена
Другие релизы ЗУП 3.1	Изменения структуры, типовых процедур, шаблонов и корректировок	Требуют отдельной проверки; совпадение редакции недостаточно
Зарплата и кадры государственного учреждения	Самостоятельные особенности продукта и учетного маршрута	Поддержка не заявлена
ERP, КА, Бухгалтерия предприятия	Иная архитектура и наличие необходимых механизмов	За пределами рассматриваемой реализации; перенос по сходству названий недопустим
ЗУП 2.5	Отдельная архитектура прежней редакции	За пределами задачи

 

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

Файловая или клиент-серверная база, тонкий или веб-клиент, Windows или Linux — дополнительные измерения проверки, а не новые конфигурации.

Работа в 1С:Фреш требует отдельного рассмотрения правил сервиса. Для дополнительных обработок предусмотрен аудит перед использованием — см. описание аудита 1С:Фреш. Локальная работоспособность EPF не заменяет этот этап. Обычный веб-клиент собственной базы и работа в сервисе Фреш также не являются одним режимом.

В этой публикации нет заявления «проверено на всех конфигурациях». Документация, совпадающее название объекта и чужая карточка обработки не заменяют запуск на заявленной среде.

 

Минимальная матрица приемочных проверок

Ниже — сценарии, которые стоит воспроизвести до публикации практической обработки. Это перечень ожидаемых проверок, а не отчет об уже проведенных испытаниях.

 

Сценарий	Проверяемое ожидание
Три строки нашего примера	Два акта на 24 000 руб.; объем 13 только при согласованном суммировании
Разные суммы повторенного ACT08	Противоречивая группа остановлена; сумма не выбрана произвольно
Один сотрудник, два договора	Каждый акт относится к своему договору
Два одноименных сотрудника	Нет автоматического выбора по первой найденной строке
Один человек, несколько записей сотрудника	Выбрана нужная запись по согласованному соответствию
Не найден сотрудник или договор	Нет незаказанного автоматического создания справочников и договоров
Договор с иной схемой оплаты	Ветка акта не меняет условия договора ради загрузки
Отдельные события и месячный итог	Агрегация следует смыслу данных; итог не суммируется как приращение
Оперативные значения на разные даты	Сохранено требуемое распределение; проверен расчет за часть месяца
Показатели сотрудника, подразделения и организации	Значения относятся к правильным получателям
Несколько показателей в одном шаблоне	Каждая колонка сопоставлена своему показателю, соседние значения сохранены
Недопустимый тип показателя или иной тип шаблона	Есть явный отказ либо отдельно проверенный маршрут, без фиктивной универсальности
Ноль, пустота, дробь, отрицательное значение	Применены согласованные правила; значимый ноль не исчез
Ведущие нули, формулы, скрытые строки, текстовые даты	Применен установленный контракт файла; нет скрытого преобразования смысла
Заполнение существующего документа	Совпадают шапка и период; ручные и посторонние данные сохранены согласно режиму
Повтор того же реестра, сортировка и другое имя файла	Новые акты и приращения не появляются только из-за изменения упаковки
Тот же ID с измененным содержимым	Показано изменение; применен согласованный сценарий исправления
В новом файле отсутствует прежнее событие	Нет автоматической отмены; определено, является файл порцией данных или замещающим реестром
Один из результатов уже создан вручную	Не происходит автоматического присвоения или перезаписи по совпадению суммы
Акты созданы, расчетные данные не записаны	Повтор продолжает нужную ветку без новых дублей
Расчетные данные записаны, часть актов не создана	Состав частичного результата виден; дальнейший расчет следует согласованной политике
Ошибка проведения после успешной записи	Записанный документ показан отдельно; повтор учитывает его существование
Рабочая роль, ограничение доступа, запрет изменения	Нет обхода ограничений и ложного статуса полного успеха
Два параллельных запуска или изменение после просмотра	Подтвержден механизм защиты либо явно ограничен режим работы
Контрольный типовой расчет	Результат совпадает с ручным вводом; одна работа не начислена повторно двумя ветками
Каждая заявленная поставка, релиз и среда	Есть отдельное свидетельство запуска; неподтвержденные сочетания не названы поддерживаемыми

 

Для каждого прогона следует фиксировать полную среду, настройки, исходные данные, ожидаемый и фактический результат, ссылки на созданные документы и выявленные ограничения. Фраза «проверено на ЗУП 3» слишком мало сообщает профессиональному читателю.

 

Как выглядит полный маршрут узкой обработки

1. Пользователь задает организацию, период, шаблон, режим второй ветки и правила записи.
2. Обработка читает файл согласованным для среды способом.
3. Исходные ячейки преобразуются в проверенную таблицу событий с сохранением связи со строками файла.
4. Сотрудники, договоры и получатели показателей сопоставляются однозначно.
5. Формируются отдельные группы актов и расчетных данных; проверяются повторенные реквизиты и правила агрегации.
6. Пользователь получает предварительный результат с суммами, будущими изменениями и блокирующими ошибками.
7. Перед записью повторно проверяются существенные условия базы и существующие результаты.
8. В разрешенном режиме выполняются типовое заполнение, запись и, если предусмотрено, проведение.
9. Фактические документы повторно читаются, а результаты двух веток и их связи фиксируются раздельно.
10. Приемочный контроль подтверждает дальнейшее использование данных штатным расчетом.

Отчет загрузки должен объяснять результат действия: создано, уже было загружено, изменено по согласованному правилу, записано без проведения, заблокировано либо выполнено частично. Общий счетчик «обработано строк» не заменяет эти сведения.

 

Когда внешний инструмент действительно полезен

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

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

Его ценность — в прозрачном переходе от внешнего события к типовым документам: однозначные соответствия, правильные группы, видимые изменения, устойчивый повтор и понятный отчет.

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

 

Что потребуется уточнить перед реализацией

1. Образец Excel без реальных персональных данных: структура, типы ячеек и два-три неоднозначных случая.
2. Смысл строки, суммы и каждого показателя: событие, итог, повторенная шапка либо значение на дату.
3. Правила выбора организации, сотрудника и договора, включая несколько договоров одного исполнителя.
4. Нужные даты и периоды для обеих веток.
5. Шаблон, настройки показателей и контрольный пример их участия в начислении.
6. Создание нового документа расчетных данных либо заполнение выбранного; правила сохранения ручных данных.
7. Запись или проведение, повтор, исправление и допустимость частичного результата.
8. Точная среда запуска, влияющие расширения и способ приемки без передачи рабочей базы.

Это не формальное расширение задания. Каждый ответ меняет алгоритм и позволяет проверить, действительно ли загрузка выполняет нужную учетную операцию.

 

Вывод

Массовое создание актов ГПХ и ввод расчетных данных из одного Excel — задача прежде всего о смысле событий и границах типового учета.

Одна строка не обязана быть одним актом. Одинаковая сумма не обязана быть новым начислением. Несколько чисел одного сотрудника не обязаны складываться. И две заполненные ветки не доказывают правильность итогового расчета.

Рабочий подход начинается с согласованного реестра, разделяет ключи актов и показателей, сохраняет типовой маршрут документов и дает проверяемый результат при повторе и частичном выполнении.

Такое введение задает основу для практической обработки: сначала уточненная учетная схема, затем реализация, испытания на целевой версии и публикация подтвержденной области применения. Имена служебных методов, готовый файл обработки и заявления о совместимости должны появляться вместе с реальными доказательствами их работы.