Модель данных GST‑счёта: минимальные поля для HSN и заказов

Что обычно идёт не так со счетами GST

Большинство проблем со счетами GST — это не «сложная налоговая логика», а отсутствие или несоответствие данных. Аудит проваливается, когда счёт нельзя однозначно связать с тем, что было продано, кому, где поставлено и как был рассчитан налог.

Частая причина — отсутствие HSN, его устаревшая версия или применение не на том уровне. Команды могут хранить HSN в карточке продукта, но строка счёта формируется из другого имени SKU или варианта, поэтому HSN не попадает в итоговый документ. Ещё одна распространённая ошибка — неверная разбивка налога: взимание IGST вместо CGST+SGST (или наоборот), если «место поставки» было определено по адресу доставки без сохранения кода штата, использованного для решения.

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

Ниже — шаблоны, которые чаще всего вызывают проблемы:

• Продукт и строки счёта не имеют одинаковых HSN, ставок GST и полей облагаемой стоимости.
• Налог считается в нескольких местах (корзина vs счёт) и результаты разнятся.
• Сохраняются только «итоговые» суммы без разбивки по облагаемой стоимости и компонентам налога.
• Нумерация счетов редактируется или дублируется в различных сериях.
• Возвраты фиксируются как отрицательные заказы вместо корректных кредит‑нотов.

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

Минимальный набор записей, который вам нужен

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

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

• Customer: кто купил (имя, телефон/email, GSTIN если B2B)
• Address: доставка и выставление счета, плюс данные о штате и признаках места поставки
• Product (or Service): что продано, единица измерения, базовая цена и дефолтный HSN/SAC
• Order: коммерческое событие (корзина, скидки, доставка, статус)
• Payment: как прошёл платёж (идентификатор шлюза, способ, сумма, дата)

Invoice должна быть отдельной от Order. Заказы меняются (адреса редактируют, позиции отменяют, частично выполняют). Счета не должны меняться: им нужны стабильные номера, даты и суммы, которые не «поплывут», если кто‑то обновит заказ позже.

Якорь точности налога — это Line Items. Каждая строка заказа (и затем строка счёта) должна содержать точное количество, цену за единицу, скидку и разбивку налога для конкретного товара. Именно туда следует переносить HSN/SAC и ставки GST.

Одна деталь, которая экономит время финансам: храните снимки. При генерации счёта скопируйте описание продукта, HSN/SAC, ставку налога и цену в строки счёта. Не полагайтесь на текущую карточку продукта: названия и ставки меняются.

Опционно, но часто полезно добавить с самого начала отдельные записи для Returns, Refunds и Credit Notes. Например: если клиент возвращает один товар из двух, удобнее выписать кредит‑ноту, ссылающуюся на строку исходного счёта, а запись возврата по платёжному шлюзу — на транзакцию. Явные объекты предотвращают ручные правки в сводках по GST в конце месяца.

Если вы строите это в Koder.ai, рассматривайте каждый объект сначала как простой экран (создать, просмотреть, редактировать), а генерацию счёта включайте только после того, как снимки и поля на уровне строки будут готовы.

HSN и SAC: где они находятся в модели

HSN (для товаров) и SAC (для услуг) — это не «только поля в счёте». Они начинаются в описании продукта или услуги, а затем копируются в каждую строку счёта при его формировании. Это сохраняет корректность смешанных корзин и облегчает аудит, потому что каждая строка самодостаточна.

Практически минимальная модель данных:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (опционально для ручных строк), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Размещение HSN/SAC в карточке Product помогает администратору поддерживать данные в одном месте. Копирование в InvoiceLine делает прошлые счета стабильными: даже если продукт изменится позже, счёт покажет, что было верно на момент продажи. Это ядро модели данных GST, которая не ломается при сверке.

Для хранения HSN держите всё просто: код обязателен, описание — опционально, а effective_from date — опционально для истории изменений. Большинству команд не нужно описание на каждой строке, но оно помогает при проверке исключений.

Смешанные корзины — нормальное дело: один счёт может содержать несколько строк с разными HSN/SAC. Не пытайтесь навязать один код на весь счёт. Суммы агрегируются на уровне счёта, а классификация остаётся на уровне строки.

Управление изменениями — где чаще всего появляются проблемы. Простые правила:

• Никогда не перезаписывайте HSN/SAC на уже выпущенных строках счёта.
• Если HSN/SAC продукта изменился, обновляйте Product только для будущих заказов.
• Если вы ведёте историю, добавляйте новую запись с effective_from вместо редактирования старой.

С точки зрения админ‑экранов достаточно одного места для редактирования налоговых полей Product и только чтения в строке счёта, чтобы подтвердить, что было захвачено при выпуске. Для быстрого построения экранов инструменты вроде Koder.ai могут сгенерировать базовые CRUD‑страницы и таблицы данных по этой модели с минимальными усилиями.

Детали сторон: GSTIN, адреса и место поставки

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

Начинайте с разделения «seller», «buyer» и «ship-to» как отдельных сущностей, даже если это один и тот же человек. Это предотвращает костыли, когда клиент добавляет другой адрес доставки или когда вы продаёте из нескольких регистраций GST.

Минимальные поля для хранения (покупатель и продавец)

Держите поля простыми и явными — те, что обычно нужны в счёте и отчётах:

• Юридическое название (как должно отображаться в счёте)
• Торговое название (опционально)
• GSTIN (продавец — обязательно; покупатель — nullable)
• Телефон/email (не всегда обязателен, но полезен для поддержки)
• Строки адреса, город, штат, страна, PIN/почтовый индекс

Храните штат как человеко‑читаемое название и как код штата, потому что отчётность и правила места поставки часто зависят от кода.

Биллинг vs доставка и место поставки

Фиксируйте и биллинг, и адрес доставки в самом заказе, а не только в профиле клиента. Профили меняются; счёта — нет.

Место поставки должно копироваться в виде конкретного кода штата в счёт (скопированного из заказа на момент выпуска). Не «пересчитывайте» его позже. Если правило — «по адресу доставки», сохраните этот результат и код штата, использованный для решения. Это упрощает аудит и споры.

B2B vs B2C: когда GSTIN обязателен

Для B2B GSTIN покупателя обычно обязателен и должен валидироваться по длине и формату при вводе. Для B2C GSTIN может быть пустым, но всё равно нужен полный адрес и штат, чтобы определить, действует ли CGST/SGST или IGST.

Простое правило, работающее в большинстве систем: если GSTIN покупателя присутствует — считать как B2B; если нет — как B2C. При необходимости храните явное поле customer_type.

Продавцы с несколькими регистрациями (несколько GSTIN)

Если у вас есть филиалы или юниты с разными регистрациями GST, моделируйте «Seller Entity» как отдельную запись с собственным GSTIN и адресом. Каждый заказ должен ссылаться ровно на одну такую сущность, а счёт копировать эти данные, чтобы исторические счета оставались корректными даже при изменениях адреса продавца.

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

Поля расчёта налога, которые нужно хранить

Самая распространённая логика простая: если место поставки в том же штате, что и поставщик, налог — CGST + SGST. Если штат другой — IGST. Система не должна «пересчитывать позже из сумм», потому что небольшие отличия (округление, скидки, доставка) именно и создают несоответствия.

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

Практический минимум на строку счёта выглядит так:

• taxable_value (после распределения скидки по строке)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (храните использованную разбивку)
• cgst_amount, sgst_amount, igst_amount (храните вычисленные суммы)
• line_total (taxable_value + суммы налогов)

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

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

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

Метаданные документа счёта: нумерация, даты, итоги, статусы

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

Начиная с базовых полей: номер счёта, дата выставления (issue date), тип счёта (tax invoice, export, B2B, B2C и т.д.) и валюта. Даже если вы в основном выставляете в INR, хранение валюты избегает сложных случаев для экспорта или мультивалютных маркетплейсов.

Нумерация — где чаще всего наступают проблемы. Держите серию или префикс (например «FY25-INV-»), храните финансовый год и обеспечьте уникальность на уровне базы данных. Храните контроллы «next number» по каждой серии в админке, чтобы два администратора не выпустили одинаковый номер одновременно.

Итоги должны храниться явно, а не только выводиться. Сохраняйте subtotal (облагаемая сумма), total tax, grand total и отдельную сумму округления. Если вы пересчитываете из строк, небольшое изменение правила может привести к несовпадению старых счетов с поданными декларациями.

Статусы должны отражать реальный жизненный цикл и блокировать запись при необходимости:

• Draft (редактируемый)
• Issued (номер присвоен, PDF сгенерирован)
• Cancelled (сохраняется для аудита, не удаляется)
• Refunded (платёж возвращён, может потребоваться кредит‑нота)
• Credit noted (выпущена связанная кредит‑нота)

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

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

Админ‑экраны для продуктов, налогов и данных клиентов

Если хотите чистые GST‑счета, не начинайте со страницы счёта. Начните с админ‑страниц, которые его наполняют. Хорошая модель данных GST остаётся компактной, когда входные данные контролируются и согласованы.

Product master (SKU → HSN/SAC)

Карточка продукта — источник большинства будущих несоответствий, поэтому держите её строгой. Каждый SKU должен иметь ровно один дефолтный HSN (или SAC для услуг), дефолтную ставку GST и возможные исключения по датам.

Практический экран продукта обычно требует:

• SKU и название продукта (как печатать в счёте)
• HSN/SAC код, ставка GST и налоговая категория (если используете)
• Даты активации (active from/to), чтобы изменения не переписывали старые счета
• Переопределения цен (для специальных MRP или цен по каналам)
• Статус (active/inactive) с явной причиной деактивации

Настройки налогов (ставки и входы для внутриштатных vs межштатных)

Избегайте UI‑калькулятора. Храните входные данные, которые система применит последовательно: таблицы ставок, правила места поставки и логику определения intra‑state vs inter‑state (обычно сравнение штата поставщика и штата доставки).

Фокус экрана налогов: ставка по категории/группе HSN, даты вступления в силу и поведение при наличии валидного GSTIN покупателя или при его отсутствии.

Профиль клиента и компании (кто в счёте)

Экран клиента должен фиксировать GSTIN и статус его валидации, а также дефолтные биллинг и адрес доставки. Не позволяйте пользователям свободно вводить названия штатов; используйте контролируемый список, чтобы «KA» и «Karnataka» не стали двумя разными значениями.

Экран профиля компании не менее важен: юридическое наименование, GSTIN, адрес регистрации и настройки серии счётов (префикс, следующий номер и границы финансового года). Ограничьте права на эти поля, поскольку изменения влияют на все будущие документы.

Базовый аудит (доверие и трассируемость)

Не требуется сложной системы, но нужен след. Логируйте, кто менял HSN/SAC, ставки, настройки серии счётов или GSTIN компании, вместе со старым значением, новым, меткой времени и причиной.

Если строите экраны в Koder.ai, делайте аудит и даты вступления в силу первоочередными полями. Это недорого в реализации и экономит часы на проверках у финансов.

Пошагово: от заказа к корректному счёту

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

1) Зафиксируйте, что действительно купил клиент

До расчёта налога заблокируйте снимок заказа: позиции, количества, цены за единицу, скидки, доставка/обработка, GSTIN покупателя (если есть), биллинг и доставка, а также признаки места поставки. Этот снимок не должен меняться даже если цена продукта или сопоставление HSN изменится позже.

2) Преобразуйте снимок в строки счёта (с копированием налоговых атрибутов)

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

3) Выпустите счёт и сделайте его неизменяемым

Присвойте номер счёта и дату выпуска, затем пометьте счёт как issued. С этого момента блокируйте правки цен, ставок налога, HSN и адресов в записи счёта. Если что‑то разрешено менять — только нефинансовые заметки и внутренние теги.

4) Сгенерируйте окончательный документ и сохраните итоги

Сгенерируйте PDF/печатный вид из выпущенного счёта, затем сохраните финальные итоги, которые будете отчётывать: облагаемая сумма, суммы CGST/SGST/IGST, округление и итоговая сумма. Для дополнительной безопасности храните версию документа или контрольную сумму, чтобы доказать соответствие печатной версии и сохранённых чисел.

5) Обрабатывайте изменения по закону

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

• Коррекция цены: выписать кредит‑ноту (или дебит‑ноту), ссылающуюся на исходный счёт.
• Отмена заказа после выпуска: аннулируйте счёт, если это допустимо, иначе выпустите кредит‑ноту.
• Обновление адреса после выпуска: не переписывайте счёт; корректируйте через соответствующий документ и сохраняйте аудит.
• Частичный возврат: кредит‑нота только по возвращённым строкам/сумме.
• Замена отправления: новый заказ/счёт, а не тихая правка.

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

Сделайте сверку простой: платежи, возвраты и регистры

Сверка усложняется, когда платежи трактуются как простое «оплачен/не оплачен» в заказе. Храните платежи и возвраты как отдельные записи, связанные с заказом и счётом, чтобы финансы могли свести банковские выписки без переписывания истории.

Отдельные записи платежей и возвратов (не редактируйте счёт)

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

Минимальные поля, упрощающие сверку:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (опционально): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (если выпущено), gateway_refund_id, amount, reason, refunded_at, status
• Ключи для сверки: order_id, invoice_id, payment_id, refund_id, credit_note_id — никогда не переиспользуйте

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

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

Дайте финансам один экран, который отвечает на вопросы: что выпущено, что оплачено, что открыто и что отменено. Включите ageing (0‑7, 8‑30, 31‑60, 60+ дней) и возможность детального просмотра связанных платежей и возвратов.

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

• Регистр счетов (issued, cancelled, credit‑noted)
• Сводка по налогам по ставкам и HSN/SAC
• Сверка платежей и счетов (invoice_id, суммы платежей, баланс)
• Реестр возвратов и кредит‑нот
• Отчёт по выплатам шлюза (payout_id → сопоставление с invoice/payment)

Пример: заказ на Rs 10,000, оплачено Rs 6,000 сегодня и Rs 4,000 на следующей неделе. Счёт остаётся Rs 10,000. Представление для финансов показывает баланс Rs 4,000 до второго расчёта, затем помечает счёт как полностью оплаченный без изменения выпущенного документа.

Частые ловушки, приводящие к несоответствиям и проблемам с комплаенсом

Большинство проблем со счетами GST — это не «логика налога», а учёт: числа в PDF не совпадают с выгрузками, или счёт нельзя объяснить спустя месяцы.

Первая ловушка — вычислять GST только при просмотре. Если вы пересчитываете CGST/SGST/IGST при каждом открытии счёта, со временем вы получите разные результаты после изменения ставки, правила округления или исправления ошибки. Храните вычисленную налоговую разбивку, использованную при выпуске, даже если вы сохраняете и входные данные.

Вторая ловушка — разрешать правки выпущенного счёта. После финализации изменения должны проходить через кредит‑ноту или новый документ с аудиторским следом. Иначе вы получите вопросы «почему PDF клиента не совпадает с книгами?».

Частые паттерны несоответствий:

• Отсутствует место поставки или код штата неверен, в результате IGST применяется вместо CGST+SGST (или наоборот).
• HSN/SAC продукта или ставка обновлены, и старые заказы пересчитываются по новым значениям.
• Налог сохранён, но правила округления различаются между UI, генерацией PDF и CSV‑экспортами.
• Скидки применяются после налога в одном месте и до налога в другом.
• Возвраты записаны как отрицательные строки без явной ссылки на исходный счёт.

Быстрый пример: вы продаёте клиенту в Karnataka, но адрес доставки — Maharashtra. Если система по ошибке берёт штат биллинга как место поставки, вы можете начислить CGST+SGST вместо IGST. Если при этом вы пересчитываете налог на лету, ошибка может «автоматически» исправиться позже, оставив финансы с числами, не совпадающими с выпущенным документом.

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

Быстрый чек-лист и следующие шаги

Перед тем как отправить счёт клиенту или пометить его как «issued», прогоняйте быстрые проверки. Именно здесь маленькие ошибки превращаются в большие проблемы при сверке. Если вы строите модель данных GST, стоит внедрить эти проверки как валидации и в админ‑интерфейс.

Проверки по счёту (до выпуска)

• HSN/SAC присутствует в каждой строке и соответствует реально проданному товару/услуге.
• Правила GSTIN применены корректно (B2B vs B2C), а данные биллинга и доставки не противоречат друг другу.
• Место поставки сохранено и разбивка налога имеет смысл (CGST/SGST vs IGST).
• Итоги сходятся точно: облагаемая сумма, каждая налоговая составляющая, округление и итоговая сумма.
• После выпуска счёт блокируется (никаких тихих правок). Исправления происходят через кредит‑ноту или аннуляцию, а не перепись истории.

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

Проверки данных и процессов (чтобы финансы оставались чистыми)

• Нумерация счетов уникальна, последовательна по политике и генерируется только при статусе «issue».
• Храните вычисленные налоговые суммы, а не только ставки, чтобы отчёты оставались стабильными при смене ставок.
• Явные статусы: draft -> issued -> cancelled (и отдельные документы кредит‑ноты).
• Отчёты сверяются по периоду: итоги регистра счетов должны совпадать с захваченными платежами, обработанными возвратами и открытой дебиторской задолженностью.
• Поля аудита всегда присутствуют: created by, issued at и причина для аннуляции или кредит‑ноты.

Следующие шаги: реализуйте экраны и валидации в первую очередь, затем итерационно улучшайте. В Koder.ai начните с Planning Mode, чтобы набросать записи и админ‑экраны (продукты с маппингом HSN/SAC, данные клиентов/GSTIN, налоговые правила и счета). Сгенерируйте приложение, протестируйте несколько реальных заказов end‑to‑end, затем используйте снимки и откаты, чтобы безопасно отточить процесс. Когда потребуется более глубокая кастомизация, экспортируйте исходный код и продолжайте развивать приложение обычным способом.