Подготовка расчёта зарплаты

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

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Собирает табели, считает часы и сверхурочные, находит ошибки и готовит расчёт зарплаты, который вы одобряете построчно.
Когда брать: Перед выплатой зарплаты, когда нужно проверить табели, понять, почему сумма выросла, и убедиться, что никого не обделили.
Когда не брать: Если нет ни табелей, ни доступа к зарплатной системе, ни списка сотрудников с часами.
Пример запроса: Пора платить зарплату бригаде в пятницу. Проверь табели за две недели и покажи, где что-то не сходится.
Работает лучше с: Gusto, QuickBooks Payroll, учётная система

Входит в плагин small-business. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку payroll-prep в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: payroll-prep
description: >
  Готовит расчёт зарплаты так, чтобы никого не обделили: забирает табели из
  Gusto, QuickBooks Payroll или из загруженной таблицы, суммирует по каждому
  человеку обычные часы, сверхурочные и часы оплачиваемого отпуска (PTO),
  отмечает каждую найденную аномалию — пропущенные отметки, всплески
  сверхурочных, смену ставок, принятых и уволенных в середине периода,
  часы вне графика — и подготавливает расчёт, который владелец одобряет
  построчно, прежде чем сдвинется хоть один доллар. Аномалии всегда
  выносятся наверх, а не исправляются втихую. Когда владелец проведёт расчёт,
  проводка уходит в учётную книгу или к бухгалтеру. Обращайся к нему, как
  только заходит речь о зарплате вообще — «проведи зарплату», «пора платить
  зарплату», «проверь табели», «все ли отметились на уходе», «сколько часов
  отработала бригада», «почему зарплата на этой неделе такая большая», «мне
  надо заплатить ребятам в пятницу», — и применяй после cash-flow-snapshot,
  когда владелец беспокоится, хватит ли денег на зарплату.
allowed-tools: Read, WebFetch
---

Подготовка расчёта зарплаты

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

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

Шаг 1 — Сначала зафиксируй период

Подтверди даты начала и конца расчётного периода, дату выплаты и тех, кто входит в этот расчёт. Ошибка в периоде дублирует или пропускает чью-то неделю оплаты, и сделать её на удивление легко, когда период пересекает конец месяца.

Подтверди и список сотрудников: принятых в середине периода, всех уволенных, всех, кто в отпуске или на больничном. См. reference/timesheet_intake.md.

Шаг 2 — Забери табели

Если подключён Gusto, сначала спроси у самого Gusto, что стоит на пути, — вызови его проверку блокировок расчёта (list_payroll_blockers), прежде чем что-либо строить. Если блокировки вернулись, переведи каждую простыми словами: что это значит, кто это исправляет и где. Например: «оплата чеками не поддерживается» (check payments unsupported) означает, что эта компания платит бумажными чеками, которые интеграция не умеет готовить, поэтому владелец проводит эту часть прямо в Gusto; «банковский счёт не подключён через Plaid» (bank account not connected via Plaid) означает, что владельцу нужно подключить банк в настройках Gusto; «почасовые сотрудники не поддерживаются» (hourly employees unsupported) может блокировать на уровне аккаунта, даже если этот расчёт только для окладников. Блокировки — это сигнал маршрутизации, а не сбой: расчёт всё равно строится и проверяется здесь, а итоговым материалом становится ведомость расчёта с приложенным списком блокировок.

Затем забери данные периода, каждое из своего инструмента. Часы: list_time_records за расчётный период; прежде всего прочитай его поле source. native возвращает смены с приходом, уходом и перерывами; third_party возвращает табели от партнёра компании по учёту времени, а get_time_sheet даёт построчную разбивку по дням для любого из них (на идентификаторы собственных смен он отказывает); none означает, что у Gusto нет часов по этой компании, и их даёт путь через таблицу ниже. Отсутствия: list_time_off_requests за период со status: approved — каждый одобренный день оплачивается как PTO или больничный, а не как отработанный, а заявка в ожидании — это флаг, а не оплаченный день. Остатки: get_time_off_balances — именно с ним сверяется проверка «PTO сверх доступного остатка» из шага 4. Ставки и классификации: список сотрудников из list_employees с оплатой каждого. Ставки берутся из Gusto, никогда из табеля. Формы вызовов для этого описаны в ../../shared/connector-call-shapes.md.

Пропущенная отметка, которую владелец может заполнить. Когда шаг 4 отмечает смену без ухода, а владелец называет реальное время, record_time записывает его — только то время, которое назвал владелец, сначала показанное ему, и как update существующей смены, а не вторая запись. Параметры, без которых вызов откажет (часовой пояс, объект на собственном учёте Gusto, какой идентификатор считается сменой), и единственная ловушка при повторном чтении (подтверждённые часы подрядчика возвращаются с пустым временем прихода и ухода; не записывай ещё раз) описаны в строке record_time файла ../../shared/connector-call-shapes.md. Прочитай эту строку перед вызовом. Это единственный способ, которым скилл когда-либо меняет отметку; предполагаемое время никогда не записывается.

Затем докажи, что источник возвращает свои данные, прежде чем что-либо готовить. Забери список сотрудников (list_employees) и графики выплат (list_pay_schedules). Компания, которая сообщает численность, при том что любой из списков пуст, или вызов блокировок, который отвечает ошибкой вместо ответа, — это источник зарплаты, который подключён, но не отдаёт данные. Останови путь подготовки, скажи об этом одной строкой («Gusto подключён, но не вернул ни сотрудников, ни графиков выплат, поэтому я не могу подготовить по нему расчёт») и предложи путь через таблицу ниже. Никогда не строй расчёт по пустому списку сотрудников и никогда не считай зелёный значок подключения доказательством того, что данные там есть.

Если подключён QuickBooks Payroll, забери те же поля оттуда. Здесь два разных сбоя выглядят похоже, а владелец слышит их по-разному. Пустой источник (списки Gusto возвращаются без строк у компании, которая сообщает численность) — это пробел в данных: скажи об этом и используй ведомость расчёта. Источник, противоречащий сам себе, — это дефект инструмента: qbo_payroll_get_company_payroll_readiness, отвечающий has_employees: false и run_payroll_ready: false, в то время как qbo_payroll_get_employees по той же компании возвращает total_count, равный 50, — оба не могут быть верны. Это не зависит от того, сколько данных у компании. В таком случае бери список сотрудников из списка (это вызов, который вернул строки), не готовь расчёт, пока готовность говорит «не готово», и назови владельцу оба числа одной строкой, чтобы противоречие осталось на виду, а не пряталось за словами «не готово». Затем иди по пути через таблицу ниже с этим списком: итогом становится проверенная ведомость расчёта, которую владелец вводит в QuickBooks Payroll, — так же, как и для пустого источника. Это полноправный источник, а не запасной вариант. Он содержит полный список сотрудников с типом оплаты, ставкой и периодичностью, статусом занятости и остатками по политике PTO; график выплат и его периодичность; и последний завершённый расчёт с валовой оплатой по каждому сотруднику, часами и налоговыми строками. Там, где часы пришли из табеля, запись говорит об этом, а это нужно проверкам аномалий из шага 4.

Две оговорки, специфичные для этого источника. У сотрудников статус занятости отделён от признака активности, поэтому тот, кто отмечен активным, всё равно может не числиться в зарплатной ведомости или быть в оплачиваемом отпуске; прочитай оба, прежде чем включать кого-либо в расчёт. И у одного сотрудника может быть десяток и больше ставок оплаты, большинство с нулём часов, поэтому считай итог по той ставке, к которой действительно привязаны часы, а не по первой в списке.

Без того и другого возьми загруженную таблицу или CSV. Это полностью поддерживаемый путь: проверенная ведомость расчёта, которую владелец вводит в своего зарплатного провайдера, — полноценный результат. Многие небольшие бригады до сих пор работают на бумажном табеле, который фотографируют в конце недели, и это тоже подходит.

Приведи данные к одной строке на человека на день: дата, приход, уход, перерыв, обычные часы, сверхурочные часы, PTO и объект или класс, если бизнес относит труд на объекты.

Шаг 3 — Просуммируй часы

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

Правила сверхурочных различаются по штатам и по тому, как бизнес классифицирует людей, и ошибка в них недоплачивает кому-то. Используй правило, которое назвал владелец, а если его нет — простое недельное правило сверхурочных по умолчанию и скажи, какое правило применил. reference/anomaly_rules.md описывает пограничные случаи расчёта: смены ставки в середине недели, дни с несколькими объектами и смены, переходящие через полночь.

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

Шаг 4 — Отметь каждую аномалию

Это ядро скилла. Выполни полную проверку из reference/anomaly_rules.md и вынеси всё, что она находит, каждое — с именем человека, датой и тем, что именно выглядит неправильно:

Пропущенные отметки и смены без ухода
Сверхурочные выше обычного для этого человека, с обоими числами
Ноль часов у того, кто обычно работает
Часы значительно выше того, что предусматривал график
Смены ставки с прошлого расчёта
Дублирующиеся или перекрывающиеся записи
PTO сверх доступного остатка
Тот, кому заплатили в прошлом периоде, но кого нет в этом
Новый человек, появившийся без записи о приёме на работу

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

Шаг 5 — Покажи расчёт до его одобрения

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

Сравни с прошлым периодом и объясни любое изменение больше 10%. У зарплаты, выросшей на USD 4 000, есть причина, и владелец должен услышать её от этого скилла, а не найти в остатке на счёте.

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

Шаг 6 — Разбери флаги по одному

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

Не объединяй флаги в один вопрос «выглядит нормально?». Каждый флаг — это чья-то зарплата.

Шаг 7 — Этап согласования

Ничего не готовится к проведению, пока владелец явно не одобрит расчёт.

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

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

Если подключён Gusto, подготовь расчёт: найди необработанную зарплатную ведомость через list_payrolls с фильтром processing_statuses: unprocessed и end_date на несколько недель вперёд (фильтр по дате относится к расчётному периоду, и пустой вызов может пропустить период, который ещё не закончился), возьми ту, у которой ближайшая дата платежа, прочитай её через get_payroll, затем запиши одобренные часы, PTO и любые строки премий через update_payroll. Важны две особенности, обе описаны в ../../shared/connector-call-shapes.md: значения заменяют, а не прибавляются, поэтому «дай Марии ещё пять часов» означает отправить её новый итог, сначала показанный владельцу как «40 → 45»; и ведомость, список сотрудников в которой ещё не сформирован, требует одного пустого вызова update_payroll, чтобы наполнить её, прежде чем делать настоящий. run_payroll не трогай — это кнопка владельца в Gusto. Если подключён QuickBooks Payroll, коннектор даёт только чтение (список сотрудников, ставки, графики, готовность, прошлый расчёт) и не умеет записывать подготовку расчёта, поэтому итог там — проверенная ведомость расчёта, которую владелец вводит сам; это то, что коннектор умеет сегодня, а не менее полноценный путь. Отправляет расчёт владелец в любой из систем. Если нет ни той, ни другой, подготовь проверенную ведомость расчёта для ручного ввода. Если блокировки Gusto из шага 2 мешают подготовке через подключение, итогом становятся проверенная ведомость расчёта и список блокировок простыми словами — скажи об этом, не считая это сбоем.

Шаг 8 — Синхронизируй с учётом

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

Чего не делать

Не угадывай отметку, ставку или классификацию. Неизвестные часы называй вместе с человеком и датой.
Не исправляй аномалию втихую, даже явно выглядящую. Владелец может знать то, чего не знаешь ты.
Не отправляй зарплату. Подготовь; отправляет владелец. Этот скилл никогда не вызывает run_payroll. Это относится к QuickBooks Payroll точно так же, как к Gusto: подключённая зарплатная система — не разрешение проводить зарплату.
**Не отправляй в update_payroll разницу.** Его значения заменяют. Вычисли новый итог из get_payroll, покажи оба числа, отправь итог.
Не записывай отметку, которую владелец не называл. record_time несёт только то время, которое дал владелец, и только после того, как он увидел запись.
Не читай ставку оплаты, не сверив часы по ней. В QuickBooks Payroll у одного человека может быть много ставок, и на большинстве из них ноль часов.
Не прячь флаги в сводке. Прикрепляй каждый к человеку, которого он касается.
Не объединяй разбор флагов. Одно решение на одного человека по одной проблеме.
Не считай отсутствие коннектора препятствием. Таблица на входе, проверенная ведомость расчёта на выходе — это задуманный путь.
Не пропускай сравнение с прошлым периодом. Большое изменение без объяснения — самое полезное из доступных предупреждений.
Не готовь расчёт по зарплатному источнику, который сообщает о сотрудниках, но не возвращает ни одного. Значок подключения — не данные. Скажи, что источник не отдаёт данные, и используй путь через таблицу.
Не воспроизводи номер социального страхования (SSN), дату рождения, домашний адрес, банковский счёт или номер карты сотрудника ни в ведомости расчёта, ни в чате, ни на какой-либо созданной странице. Данные Gusto и QuickBooks Payroll их содержат; читай мимо них (../../shared/personal-data.md).

Результат

Выдай проверенную ведомость расчёта в том виде, который владелец сохранил как предпочтительный, — никогда не делай markdown-файл по умолчанию. Посмотри пункт Output preference в блоке ## Business context (правило общего руководства по оформлению, ../../shared/artifact-style.md):

Визуальный артефакт (по умолчанию): оформи ведомость расчёта в виде HTML-страницы в фирменном стиле — численность, общая валовая оплата и деньги, уходящие со счёта, в виде плиток с показателями, каждый человек — строка с часами и оплатой в табличных цифрах (tabular-nums), на каждом флаге значок, прикреплённый к тому человеку, к которому он относится. Блокировки, когда о них сообщает Gusto, получают отдельную панель простыми словами.
Предпочтение docx / md / notion / canva: выдай то же содержание в этой форме — файл DOCX или markdown, страница Notion, созданная через коннектор (в названном месте, ничего не перезаписывая), или документ Canva, созданный через коннектор Canva (каждый раз новый дизайн с датой в названии; таблицы превращаются в списки). Если Notion или Canva не подключены, вернись к визуальному артефакту и скажи, что причина в этом.
«Лучше всего для» скилла: используй визуальный артефакт — этот результат и есть ведомость, которую владелец одобряет человек за человеком.

После расчёта

Расчёт подготовлен, флаги разобраны, запись в учёте проведена. Если на входе тревожили деньги, естественный следующий шаг — «смогу ли я выплатить зарплату»: /plan-payroll запускает прогноз и взыскание счетов перед следующим расчётом. Рядом также «прогноз денег» (cash-flow-snapshot) — посмотреть, что этот расчёт делает с ближайшими 30 днями, и «налоги» (/tax-prep) — когда подходят сроки квартальных авансовых платежей или форм 1099. Предложи не больше трёх вариантов и пропусти любой, от которого владелец уже отказался в этой сессии.

Справочные файлы

reference/timesheet_intake.md — забор данных из Gusto, загрузка таблицы, настройка списка сотрудников и периода
reference/anomaly_rules.md — каждая проверка, её порог и как она формулируется
reference/run_sheet_format.md — макет ведомости расчёта и блок итогов
reference/books_sync.md — структура проводки и распределение затрат по объектам
reference/gotchas.md — ошибки, из-за которых человека обделяют или период оплачивают дважды

Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс использовал инструмент, который не подключён или не указан, предложи build-connector: он сначала проверяет каталог коннекторов, а если там нет — подключает через Zapier и никогда не собирает вручную обращение к чистому API. Когда подключение появится, инструмент присоединится к этому скиллу, как любой другой необязательный коннектор, и на тех же этапах согласования.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/payroll-prep, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: payroll-prep
description: >
Gets payroll ready to run without anyone getting shorted: pulls timesheets
from Gusto, QuickBooks Payroll, or an uploaded spreadsheet, totals regular,
overtime, and PTO
hours by person, flags every anomaly it finds — missed punches, overtime
spikes, rate changes, mid-period hires and terminations, hours off the
schedule — and stages the run for the owner to approve line by line before
a dollar moves. Anomalies are always raised, never quietly corrected. Once
the owner runs it, the journal posts to the ledger or goes to the
bookkeeper. Reach for this whenever payroll comes up at all
— "run payroll," "payroll is due," "check the timecards," "did everyone
clock out," "how many hours did the crew put in," "why is payroll so high
this week," "I need to pay the guys Friday" — and use it after
cash-flow-snapshot when the owner is worried about whether payroll clears.
allowed-tools: Read, WebFetch
---

# Payroll Prep

Get the hours right before anyone gets paid.

Payroll is the finance workflow with the least room for error. A wrong invoice gets corrected next week. A wrong paycheck is a person who cannot cover rent, and it is the fastest way for an owner to lose a crew. Everything in this skill is built around that asymmetry: the machine assembles and checks, the owner decides.

## Step 1 — Fix the period before anything else

Confirm the pay period start and end dates, the pay date, and who is in this run. Getting the period wrong duplicates or skips a week of someone's pay, and it is a surprisingly easy mistake when a period straddles a month end.

Confirm the roster too: new hires who started mid-period, anyone terminated, anyone on leave. See `reference/timesheet_intake.md`.

## Step 2 — Pull the timesheets

**With Gusto connected**, first ask Gusto itself what stands in the way: call its payroll-blockers check (`list_payroll_blockers`) before building anything. If blockers come back, translate each into plain English — what it means, who fixes it, and where. For example: "check payments unsupported" means this company pays by paper check, which the integration cannot stage, so the owner runs that part in Gusto directly; "bank account not connected via Plaid" means the owner connects the bank in Gusto's settings; "hourly employees unsupported" can block at the account level even when this run is salaried-only. Blockers are a routing signal, not a failure — the run still gets built and validated here, and the deliverable becomes the run sheet with the blocker list riding along.

Then pull the period's inputs, each from its own tool. **Hours:** `list_time_records` for the pay period; read its `source` field before anything else. `native` returns shifts with clock-in, clock-out, and breaks; `third_party` returns timesheets from the company's time-tracking partner, and `get_time_sheet` gives the per-day line items for any one of them (it refuses native shift ids); `none` means Gusto holds no hours for this company, so the spreadsheet path below supplies them. **Leave:** `list_time_off_requests` for the period with `status: approved` — every approved day is paid as PTO or sick, never as worked, and a pending request is a flag, not a paid day. **Balances:** `get_time_off_balances`, which is what the "PTO beyond available balance" check in Step 4 reads against. **Rates and classifications:** the roster from `list_employees` with each person's compensations. Rates come from Gusto, never from a timesheet. Call shapes for these are in `../../shared/connector-call-shapes.md`.

**A missing punch the owner can fill.** When Step 4 flags a shift with no clock-out and the owner gives the real times, `record_time` writes them — only the times the owner stated, shown to them first, and as an `update` of the existing shift rather than a second entry. The parameters that refuse if missing (timezone, job on Gusto's own tracking, which id counts as the shift) and the one re-read trap (a contractor's confirmed hours come back with blank clock times; do not write again) are in the `record_time` row of `../../shared/connector-call-shapes.md`. Read that row before the call. This is the only way the skill ever changes a punch; an assumed time is never written.

**Then prove the source is returning its data before anything is staged.** Pull the roster (`list_employees`) and the schedules (`list_pay_schedules`). A company that reports a headcount while either list comes back empty, or a blockers call that errors instead of answering, is a payroll source that is connected but not delivering. Stop the staging path, say so in one line ("Gusto is connected but returned no employees or pay schedules, so I cannot stage a run against it"), and offer the spreadsheet path below. Never build a run from an empty roster, and never treat a green connection badge as proof the data is there.

**With QuickBooks Payroll connected**, pull the same fields from there. Two different failures look alike here, and the owner hears them differently. An **empty source** (Gusto's lists come back with no rows on a company that reports a headcount) is a data gap: say so and use the run sheet. A **self-contradicting source** is a tool defect: `qbo_payroll_get_company_payroll_readiness` answering `has_employees: false` and `run_payroll_ready: false` while `qbo_payroll_get_employees` on the same company returns a `total_count` of 50 cannot both be true. This is independent of how much data the company has. When that happens, use the employee list for the roster (it is the call that returned rows), do not stage a run while readiness says not ready, and say both numbers to the owner in one line so the contradiction is on record rather than hidden behind "not ready." Then take the spreadsheet path below with that roster: a validated run sheet the owner keys into QuickBooks Payroll is the outcome, the same as for an empty source. This is a first-class source, not a fallback. It carries the full employee roster with pay type, rate and frequency, employment status, and PTO policy balances; the pay schedule and its frequency; and the last completed run with per-employee gross pay, hours, and the tax lines. Where hours came from a timesheet the record says so, which is what the anomaly checks in Step 4 need.

Two cautions specific to this source. Employees carry an employment status separate from an active flag, so someone marked active can still be not-on-payroll or on paid leave; read both before putting anyone in the run. And a single employee can hold a dozen or more pay rates, most sitting at zero hours, so total from the rate that actually has hours against it rather than the first rate listed.

**Without either**, take an uploaded spreadsheet or CSV. This is a fully supported path — a validated run sheet the owner keys into their payroll provider is a complete outcome. Many small crews still run on a paper timesheet photographed at the end of the week, and that works too.

Normalize into one row per person per day: date, in, out, break, regular hours, overtime hours, PTO, and the job or class if the business tracks labor to jobs.

## Step 3 — Total the hours

Compute regular, overtime, double time, PTO, holiday, and unpaid time per person, then per crew, then for the run.

Overtime rules vary by state and by how the business classifies people, and getting them wrong underpays someone. Use the owner's stated rule, and when there isn't one, use the plain weekly-overtime default and say which rule you applied. `reference/anomaly_rules.md` covers the calculation edges — mid-week rate changes, multi-job days, and shifts crossing midnight.

**Never fill a missing punch with an assumed time.** A shift with a clock-in and no clock-out has unknown hours, and unknown hours is what gets reported.

## Step 4 — Flag every anomaly

This is the core of the skill. Run the full check in `reference/anomaly_rules.md` and surface everything it finds, each with the person's name, the date, and what specifically looks wrong:

- Missing punches and shifts with no clock-out
- Overtime above this person's normal pattern, with both numbers
- Zero hours for someone who normally works
- Hours well above what the schedule called for
- Rate changes since the last run
- Duplicate or overlapping entries
- PTO taken beyond the available balance
- Someone paid last period who is missing from this one
- A new person appearing with no hire record

**Flags go to the owner. They never get silently corrected.** A missed punch has a real answer that only the employee and the owner know, and a plausible guess in the middle of that becomes a wrong paycheck that looks correct on the report.

## Step 5 — Show the run before approving it

Present the run sheet: person by person, hours by type, gross pay, and every flag attached to the person it belongs to. Then the totals — total hours, total gross, employer taxes and contributions if available, total cash needed, and the pay date.

Compare against the prior period and explain any move over 10%. A payroll that jumped USD 4,000 has a reason, and the owner should hear it from this skill rather than find it in the bank balance.

If cash data is available, say whether the run clears. If it is not available, say that plainly instead of implying it is fine.

## Step 6 — Resolve the flags, one at a time

Walk the owner through each flag. For each: what was found, what it would mean if left as is, and what they want done. Record the answer and apply it.

Do not batch flags into a single "looks good?" question. Each one is a person's pay.

## Step 7 — The approval gate

**Nothing stages until the owner explicitly approves the run.**

State plainly before asking: number of people, total hours, total gross, total cash leaving the account, the pay date, and the count of any flags they chose to leave open.

Then ask. An owner who wants to skip this gate should be told, once and without lecturing, that it stays because a wrong run is not something they can take back after direct deposit lands.

With Gusto connected, stage the run: find the unprocessed payroll with `list_payrolls` filtered to `processing_statuses: unprocessed` and an `end_date` a few weeks ahead (its date filter is on the pay period, and a bare call can miss a period that has not ended yet), take the one with the nearest check date, read it with `get_payroll`, then write the approved hours, PTO, and any bonus lines with `update_payroll`. Two shapes matter and both are in `../../shared/connector-call-shapes.md`: values **replace** rather than add, so "give Maria five more hours" means sending her new total, shown to the owner as "40 → 45" first; and a payroll whose roster is not yet materialized takes one empty `update_payroll` call to populate it before the real one. Leave `run_payroll` alone — that is the owner's button, in Gusto. With QuickBooks Payroll connected, the connector holds the reads (roster, rates, schedules, readiness, last run) and no run-staging write, so the outcome there is the validated run sheet the owner keys in; that is what the connector holds today, not a lesser path. **The owner submits it** in either system. With neither, produce the validated run sheet for manual entry. If Gusto's blockers from Step 2 prevent staging through the connection, the validated run sheet plus the plain-English blocker list is the outcome — say so without treating it as a failure.

## Step 8 — Sync to the books

After the run is submitted, post the journal entry to the ledger: gross wages, employer taxes, and any labor allocated to jobs. Test the capability, not the logo: a connected ledger whose connector has no journal-write path cannot take the post, so say so in one line and hand the balanced entry to the owner or bookkeeper to key in — a complete outcome, not a failure. Confirm the amounts match what actually ran, not what was proposed — those differ whenever the owner edited something at the last step.

## What not to do

- **Do not guess a punch, a rate, or a classification.** Unknown hours get named with the person and the date.
- **Do not correct an anomaly silently,** even an obvious-looking one. The owner may know something you do not.
- **Do not submit payroll.** Stage it; the owner submits. `run_payroll` is never called by this skill. This holds for QuickBooks Payroll exactly as it holds for Gusto — a connected payroll system is not permission to run payroll.
- **Do not send a delta to `update_payroll`.** Its values replace. Compute the new total from `get_payroll`, show both numbers, send the total.
- **Do not write a punch the owner did not state.** `record_time` carries only times the owner gave, and only after they saw the entry.
- **Do not read a pay rate without checking the hours against it.** In QuickBooks Payroll one person can carry many rates with zero hours on most of them.
- **Do not bury flags in a summary.** Attach each one to the person it affects.
- **Do not batch the flag review.** One decision per person per issue.
- **Do not treat a missing connector as a blocker.** A spreadsheet in, a validated run sheet out, is a designed path.
- **Do not skip the prior-period comparison.** A large move with no explanation is the most useful warning available.
- **Do not stage a run from a payroll source that reports employees but returns none.** A connected badge is not data. Say the source is not delivering, and use the spreadsheet path.
- **Do not reproduce an employee's SSN, date of birth, home address, or bank or card number** in the run sheet, the chat, or any rendered page. Gusto and QuickBooks Payroll payloads carry them; read past them (`../../shared/personal-data.md`).

## Output

**Deliver the validated run sheet per the owner's stored output preference — never default to a markdown file.** Check the `## Business context` block's `Output preference` (shared style guide rule, `../../shared/artifact-style.md`):

- **Visual artifact (the default):** render the run sheet as an HTML page in the house style — headcount, total gross, and cash leaving the account as stat tiles, each person a row with hours and pay in tabular-nums, and a pill on every flag attached to the person it belongs to. Blockers, when Gusto reports them, get their own plain-English panel.
- **docx / md / notion / canva preference:** deliver the same content in that form — a DOCX or markdown file, a Notion page created via the connector (named destination, never overwriting), or a Canva Doc created via the Canva connector (a new design each run, named with the date; tables become lists); fall back to the visual artifact if Notion or Canva is not connected — and say that is why.
- **Best for skill:** use the visual artifact — this output is a sheet the owner approves person by person.

## After the run

The run is staged, the flags are resolved, and the books entry is posted. If cash was the worry going in, the natural next step is "can I make payroll" — `/plan-payroll` runs the forecast and the invoice chase in front of the next run. Also nearby: "cash forecast" (`cash-flow-snapshot`) to see what this run does to the next 30 days, and "taxes" (`/tax-prep`) when quarterly estimates or 1099s are coming due. Offer at most three, and skip any offer the owner already declined this session.

## Reference files

- `reference/timesheet_intake.md` — Gusto pull, spreadsheet upload, roster and period setup
- `reference/anomaly_rules.md` — every check, its threshold, and how it is worded
- `reference/run_sheet_format.md` — the run sheet layout and the totals block
- `reference/books_sync.md` — journal entry structure and job-cost allocation
- `reference/gotchas.md` — the mistakes that shortchange a person or double-pay a period

## Using a tool that isn't listed

The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.

Источник: anthropics/knowledge-work-plugins / small-business / payroll-prep ↗. Ссылка проверена 2026-10-10.

---
name: payroll-prep
description: >
  Готовит расчёт зарплаты так, чтобы никого не обделили: забирает табели из
  Gusto, QuickBooks Payroll или из загруженной таблицы, суммирует по каждому
  человеку обычные часы, сверхурочные и часы оплачиваемого отпуска (PTO),
  отмечает каждую найденную аномалию — пропущенные отметки, всплески
  сверхурочных, смену ставок, принятых и уволенных в середине периода,
  часы вне графика — и подготавливает расчёт, который владелец одобряет
  построчно, прежде чем сдвинется хоть один доллар. Аномалии всегда
  выносятся наверх, а не исправляются втихую. Когда владелец проведёт расчёт,
  проводка уходит в учётную книгу или к бухгалтеру. Обращайся к нему, как
  только заходит речь о зарплате вообще — «проведи зарплату», «пора платить
  зарплату», «проверь табели», «все ли отметились на уходе», «сколько часов
  отработала бригада», «почему зарплата на этой неделе такая большая», «мне
  надо заплатить ребятам в пятницу», — и применяй после cash-flow-snapshot,
  когда владелец беспокоится, хватит ли денег на зарплату.
allowed-tools: Read, WebFetch
---

# Подготовка расчёта зарплаты

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

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

## Шаг 1 — Сначала зафиксируй период

Подтверди даты начала и конца расчётного периода, дату выплаты и тех, кто входит в этот расчёт. Ошибка в периоде дублирует или пропускает чью-то неделю оплаты, и сделать её на удивление легко, когда период пересекает конец месяца.

Подтверди и список сотрудников: принятых в середине периода, всех уволенных, всех, кто в отпуске или на больничном. См. `reference/timesheet_intake.md`.

## Шаг 2 — Забери табели

**Если подключён Gusto**, сначала спроси у самого Gusto, что стоит на пути, — вызови его проверку блокировок расчёта (`list_payroll_blockers`), прежде чем что-либо строить. Если блокировки вернулись, переведи каждую простыми словами: что это значит, кто это исправляет и где. Например: «оплата чеками не поддерживается» (check payments unsupported) означает, что эта компания платит бумажными чеками, которые интеграция не умеет готовить, поэтому владелец проводит эту часть прямо в Gusto; «банковский счёт не подключён через Plaid» (bank account not connected via Plaid) означает, что владельцу нужно подключить банк в настройках Gusto; «почасовые сотрудники не поддерживаются» (hourly employees unsupported) может блокировать на уровне аккаунта, даже если этот расчёт только для окладников. Блокировки — это сигнал маршрутизации, а не сбой: расчёт всё равно строится и проверяется здесь, а итоговым материалом становится ведомость расчёта с приложенным списком блокировок.

Затем забери данные периода, каждое из своего инструмента. **Часы:** `list_time_records` за расчётный период; прежде всего прочитай его поле `source`. `native` возвращает смены с приходом, уходом и перерывами; `third_party` возвращает табели от партнёра компании по учёту времени, а `get_time_sheet` даёт построчную разбивку по дням для любого из них (на идентификаторы собственных смен он отказывает); `none` означает, что у Gusto нет часов по этой компании, и их даёт путь через таблицу ниже. **Отсутствия:** `list_time_off_requests` за период со `status: approved` — каждый одобренный день оплачивается как PTO или больничный, а не как отработанный, а заявка в ожидании — это флаг, а не оплаченный день. **Остатки:** `get_time_off_balances` — именно с ним сверяется проверка «PTO сверх доступного остатка» из шага 4. **Ставки и классификации:** список сотрудников из `list_employees` с оплатой каждого. Ставки берутся из Gusto, никогда из табеля. Формы вызовов для этого описаны в `../../shared/connector-call-shapes.md`.

**Пропущенная отметка, которую владелец может заполнить.** Когда шаг 4 отмечает смену без ухода, а владелец называет реальное время, `record_time` записывает его — только то время, которое назвал владелец, сначала показанное ему, и как `update` существующей смены, а не вторая запись. Параметры, без которых вызов откажет (часовой пояс, объект на собственном учёте Gusto, какой идентификатор считается сменой), и единственная ловушка при повторном чтении (подтверждённые часы подрядчика возвращаются с пустым временем прихода и ухода; не записывай ещё раз) описаны в строке `record_time` файла `../../shared/connector-call-shapes.md`. Прочитай эту строку перед вызовом. Это единственный способ, которым скилл когда-либо меняет отметку; предполагаемое время никогда не записывается.

**Затем докажи, что источник возвращает свои данные, прежде чем что-либо готовить.** Забери список сотрудников (`list_employees`) и графики выплат (`list_pay_schedules`). Компания, которая сообщает численность, при том что любой из списков пуст, или вызов блокировок, который отвечает ошибкой вместо ответа, — это источник зарплаты, который подключён, но не отдаёт данные. Останови путь подготовки, скажи об этом одной строкой («Gusto подключён, но не вернул ни сотрудников, ни графиков выплат, поэтому я не могу подготовить по нему расчёт») и предложи путь через таблицу ниже. Никогда не строй расчёт по пустому списку сотрудников и никогда не считай зелёный значок подключения доказательством того, что данные там есть.

**Если подключён QuickBooks Payroll**, забери те же поля оттуда. Здесь два разных сбоя выглядят похоже, а владелец слышит их по-разному. **Пустой источник** (списки Gusto возвращаются без строк у компании, которая сообщает численность) — это пробел в данных: скажи об этом и используй ведомость расчёта. **Источник, противоречащий сам себе**, — это дефект инструмента: `qbo_payroll_get_company_payroll_readiness`, отвечающий `has_employees: false` и `run_payroll_ready: false`, в то время как `qbo_payroll_get_employees` по той же компании возвращает `total_count`, равный 50, — оба не могут быть верны. Это не зависит от того, сколько данных у компании. В таком случае бери список сотрудников из списка (это вызов, который вернул строки), не готовь расчёт, пока готовность говорит «не готово», и назови владельцу оба числа одной строкой, чтобы противоречие осталось на виду, а не пряталось за словами «не готово». Затем иди по пути через таблицу ниже с этим списком: итогом становится проверенная ведомость расчёта, которую владелец вводит в QuickBooks Payroll, — так же, как и для пустого источника. Это полноправный источник, а не запасной вариант. Он содержит полный список сотрудников с типом оплаты, ставкой и периодичностью, статусом занятости и остатками по политике PTO; график выплат и его периодичность; и последний завершённый расчёт с валовой оплатой по каждому сотруднику, часами и налоговыми строками. Там, где часы пришли из табеля, запись говорит об этом, а это нужно проверкам аномалий из шага 4.

Две оговорки, специфичные для этого источника. У сотрудников статус занятости отделён от признака активности, поэтому тот, кто отмечен активным, всё равно может не числиться в зарплатной ведомости или быть в оплачиваемом отпуске; прочитай оба, прежде чем включать кого-либо в расчёт. И у одного сотрудника может быть десяток и больше ставок оплаты, большинство с нулём часов, поэтому считай итог по той ставке, к которой действительно привязаны часы, а не по первой в списке.

**Без того и другого** возьми загруженную таблицу или CSV. Это полностью поддерживаемый путь: проверенная ведомость расчёта, которую владелец вводит в своего зарплатного провайдера, — полноценный результат. Многие небольшие бригады до сих пор работают на бумажном табеле, который фотографируют в конце недели, и это тоже подходит.

Приведи данные к одной строке на человека на день: дата, приход, уход, перерыв, обычные часы, сверхурочные часы, PTO и объект или класс, если бизнес относит труд на объекты.

## Шаг 3 — Просуммируй часы

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

Правила сверхурочных различаются по штатам и по тому, как бизнес классифицирует людей, и ошибка в них недоплачивает кому-то. Используй правило, которое назвал владелец, а если его нет — простое недельное правило сверхурочных по умолчанию и скажи, какое правило применил. `reference/anomaly_rules.md` описывает пограничные случаи расчёта: смены ставки в середине недели, дни с несколькими объектами и смены, переходящие через полночь.

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

## Шаг 4 — Отметь каждую аномалию

Это ядро скилла. Выполни полную проверку из `reference/anomaly_rules.md` и вынеси всё, что она находит, каждое — с именем человека, датой и тем, что именно выглядит неправильно:

- Пропущенные отметки и смены без ухода
- Сверхурочные выше обычного для этого человека, с обоими числами
- Ноль часов у того, кто обычно работает
- Часы значительно выше того, что предусматривал график
- Смены ставки с прошлого расчёта
- Дублирующиеся или перекрывающиеся записи
- PTO сверх доступного остатка
- Тот, кому заплатили в прошлом периоде, но кого нет в этом
- Новый человек, появившийся без записи о приёме на работу

**Флаги уходят владельцу. Их никогда не исправляют втихую.** У пропущенной отметки есть настоящий ответ, который знают только сотрудник и владелец, и правдоподобная догадка посередине превращается в неверную зарплату, которая в отчёте выглядит правильно.

## Шаг 5 — Покажи расчёт до его одобрения

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

Сравни с прошлым периодом и объясни любое изменение больше 10%. У зарплаты, выросшей на USD 4 000, есть причина, и владелец должен услышать её от этого скилла, а не найти в остатке на счёте.

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

## Шаг 6 — Разбери флаги по одному

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

Не объединяй флаги в один вопрос «выглядит нормально?». Каждый флаг — это чья-то зарплата.

## Шаг 7 — Этап согласования

**Ничего не готовится к проведению, пока владелец явно не одобрит расчёт.**

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

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

Если подключён Gusto, подготовь расчёт: найди необработанную зарплатную ведомость через `list_payrolls` с фильтром `processing_statuses: unprocessed` и `end_date` на несколько недель вперёд (фильтр по дате относится к расчётному периоду, и пустой вызов может пропустить период, который ещё не закончился), возьми ту, у которой ближайшая дата платежа, прочитай её через `get_payroll`, затем запиши одобренные часы, PTO и любые строки премий через `update_payroll`. Важны две особенности, обе описаны в `../../shared/connector-call-shapes.md`: значения **заменяют**, а не прибавляются, поэтому «дай Марии ещё пять часов» означает отправить её новый итог, сначала показанный владельцу как «40 → 45»; и ведомость, список сотрудников в которой ещё не сформирован, требует одного пустого вызова `update_payroll`, чтобы наполнить её, прежде чем делать настоящий. `run_payroll` не трогай — это кнопка владельца в Gusto. Если подключён QuickBooks Payroll, коннектор даёт только чтение (список сотрудников, ставки, графики, готовность, прошлый расчёт) и не умеет записывать подготовку расчёта, поэтому итог там — проверенная ведомость расчёта, которую владелец вводит сам; это то, что коннектор умеет сегодня, а не менее полноценный путь. **Отправляет расчёт владелец** в любой из систем. Если нет ни той, ни другой, подготовь проверенную ведомость расчёта для ручного ввода. Если блокировки Gusto из шага 2 мешают подготовке через подключение, итогом становятся проверенная ведомость расчёта и список блокировок простыми словами — скажи об этом, не считая это сбоем.

## Шаг 8 — Синхронизируй с учётом

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

## Чего не делать

- **Не угадывай отметку, ставку или классификацию.** Неизвестные часы называй вместе с человеком и датой.
- **Не исправляй аномалию втихую,** даже явно выглядящую. Владелец может знать то, чего не знаешь ты.
- **Не отправляй зарплату.** Подготовь; отправляет владелец. Этот скилл никогда не вызывает `run_payroll`. Это относится к QuickBooks Payroll точно так же, как к Gusto: подключённая зарплатная система — не разрешение проводить зарплату.
- **Не отправляй в `update_payroll` разницу.** Его значения заменяют. Вычисли новый итог из `get_payroll`, покажи оба числа, отправь итог.
- **Не записывай отметку, которую владелец не называл.** `record_time` несёт только то время, которое дал владелец, и только после того, как он увидел запись.
- **Не читай ставку оплаты, не сверив часы по ней.** В QuickBooks Payroll у одного человека может быть много ставок, и на большинстве из них ноль часов.
- **Не прячь флаги в сводке.** Прикрепляй каждый к человеку, которого он касается.
- **Не объединяй разбор флагов.** Одно решение на одного человека по одной проблеме.
- **Не считай отсутствие коннектора препятствием.** Таблица на входе, проверенная ведомость расчёта на выходе — это задуманный путь.
- **Не пропускай сравнение с прошлым периодом.** Большое изменение без объяснения — самое полезное из доступных предупреждений.
- **Не готовь расчёт по зарплатному источнику, который сообщает о сотрудниках, но не возвращает ни одного.** Значок подключения — не данные. Скажи, что источник не отдаёт данные, и используй путь через таблицу.
- **Не воспроизводи номер социального страхования (SSN), дату рождения, домашний адрес, банковский счёт или номер карты сотрудника** ни в ведомости расчёта, ни в чате, ни на какой-либо созданной странице. Данные Gusto и QuickBooks Payroll их содержат; читай мимо них (`../../shared/personal-data.md`).

## Результат

**Выдай проверенную ведомость расчёта в том виде, который владелец сохранил как предпочтительный, — никогда не делай markdown-файл по умолчанию.** Посмотри пункт `Output preference` в блоке `## Business context` (правило общего руководства по оформлению, `../../shared/artifact-style.md`):

- **Визуальный артефакт (по умолчанию):** оформи ведомость расчёта в виде HTML-страницы в фирменном стиле — численность, общая валовая оплата и деньги, уходящие со счёта, в виде плиток с показателями, каждый человек — строка с часами и оплатой в табличных цифрах (tabular-nums), на каждом флаге значок, прикреплённый к тому человеку, к которому он относится. Блокировки, когда о них сообщает Gusto, получают отдельную панель простыми словами.
- **Предпочтение docx / md / notion / canva:** выдай то же содержание в этой форме — файл DOCX или markdown, страница Notion, созданная через коннектор (в названном месте, ничего не перезаписывая), или документ Canva, созданный через коннектор Canva (каждый раз новый дизайн с датой в названии; таблицы превращаются в списки). Если Notion или Canva не подключены, вернись к визуальному артефакту и скажи, что причина в этом.
- **«Лучше всего для» скилла:** используй визуальный артефакт — этот результат и есть ведомость, которую владелец одобряет человек за человеком.

## После расчёта

Расчёт подготовлен, флаги разобраны, запись в учёте проведена. Если на входе тревожили деньги, естественный следующий шаг — «смогу ли я выплатить зарплату»: `/plan-payroll` запускает прогноз и взыскание счетов перед следующим расчётом. Рядом также «прогноз денег» (`cash-flow-snapshot`) — посмотреть, что этот расчёт делает с ближайшими 30 днями, и «налоги» (`/tax-prep`) — когда подходят сроки квартальных авансовых платежей или форм 1099. Предложи не больше трёх вариантов и пропусти любой, от которого владелец уже отказался в этой сессии.

## Справочные файлы

- `reference/timesheet_intake.md` — забор данных из Gusto, загрузка таблицы, настройка списка сотрудников и периода
- `reference/anomaly_rules.md` — каждая проверка, её порог и как она формулируется
- `reference/run_sheet_format.md` — макет ведомости расчёта и блок итогов
- `reference/books_sync.md` — структура проводки и распределение затрат по объектам
- `reference/gotchas.md` — ошибки, из-за которых человека обделяют или период оплачивают дважды

## Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс использовал инструмент, который не подключён или не указан, предложи `build-connector`: он сначала проверяет каталог коннекторов, а если там нет — подключает через Zapier и никогда не собирает вручную обращение к чистому API. Когда подключение появится, инструмент присоединится к этому скиллу, как любой другой необязательный коннектор, и на тех же этапах согласования.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/payroll-prep, лицензия Apache-2.0. Изменения: перевод на русский язык.

Подготовка расчёта зарплаты

Как включить

Текст

Подготовка расчёта зарплаты

Шаг 1 — Сначала зафиксируй период

Шаг 2 — Забери табели

Шаг 3 — Просуммируй часы

Шаг 4 — Отметь каждую аномалию

Шаг 5 — Покажи расчёт до его одобрения

Шаг 6 — Разбери флаги по одному

Шаг 7 — Этап согласования

Шаг 8 — Синхронизируй с учётом

Чего не делать

Результат

После расчёта

Справочные файлы

Если нужного инструмента нет в списке

Похожие