Как оформить продажу

Что Вы создаёте, когда оформляете продажу

Продажа в Skyline Nexus — это одна строка в таблице транзакций с типом sell, набор строк продажи и ноль или более записей об оплате. Эти три вещи разделены намеренно. Счёт — это требование к клиенту. Строки — это то, что ушло с полки. Оплаты — это пришедшие деньги. Большая часть путаницы с продажами в ERP возникает из-за того, что эти три вещи воспринимают как одно событие: за прилавком магазина они обычно происходят в одну и ту же секунду.

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

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

Три входа в один и тот же документ

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

Готовые документы попадают в список «Все продажи» (/sells) независимо от того, через какой вход Вы вошли. У черновиков и коммерческих предложений свои списки — «Список черновиков» (/sells/drafts) и «Список коммерческих предложений» (/sells/quotations), — потому что это ещё не настоящие счета и загромождать ими список продаж не нужно. Кассовые чеки POS также выводятся отдельно в «Список продаж POS» (/pos).

Одна деталь реализации, которую стоит знать, потому что она объясняет часть поведения системы: форма «Добавить продажу» отправляется в тот же контроллер, что и экран POS. Это два интерфейса над одной процедурой сохранения. Поэтому налоговые правила, правила учёта запасов и проводки в главной книге одинаковы, с какого бы экрана Вы ни начали, и поэтому не стоит ожидать, что кассовый чек POS и счёт из «Добавить продажу» будут отражены в учёте по-разному.

• POS (/pos/create) — экран кассы для сенсорного ввода. Один клиент, сетка товаров, панель оплаты — всё за несколько секунд. Правильный вход для розницы, ресторанов и любой торговли через прилавок.
• «Добавить продажу» (/sells/create) — полная форма счёта. Видны все поля: схема счёта, валюта, срок оплаты, доставка, пользовательские поля, несколько строк оплаты. Правильный вход для счёта B2B, продажи с доставкой или любой сделки с отсрочкой платежа.
• «Прямая продажа» (/sells/direct/create) — сокращённый вариант «Добавить продажу» для простых счетов.
• «Добавить черновик» (/sells/create?status=draft) и «Добавить коммерческое предложение» (/sells/create?status=quotation) — та же форма, открытая с заранее заданным статусом, чтобы нельзя было случайно провести документ как окончательный.
• «Добавить заказ на продажу» (/sells/create?sale_type=sales_order) фиксирует заказ клиента, счёт по которому будет выставлен позже. Пункт появляется только при включённых заказах на продажу в настройках POS.

Заполнение экрана «Добавить продажу»

Первая карточка — «Детали продажи». Поле «Выберите локацию» обязательно и не декоративно: оно определяет, с какого склада списывается товар, какая нумерация счетов используется, какие платёжные счета предлагаются и — если Вы подаёте электронные счета — подаётся ли продажа вообще, поскольку электронное выставление счетов включается для каждой локации отдельно. «Схема счёта» определяет номер, который получит счёт. «Дата продажи» — учётная дата документа, по умолчанию текущий момент. «Валюта счёта» и «Курс обмена к SAR» появляются, только если настроена продажа в иностранной валюте.

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

В карточке клиента указываются «Клиент» и «Срок оплаты» — число плюс единица измерения: «Месяцы» или «Дни». Отдельного поля срока платежа на этом экране нет: дата платежа выводится из срока оплаты, а если его оставить пустым, используется срок оплаты по умолчанию из карточки клиента. Вот почему стоит потратить пять минут и задать сроки оплаты в карточке клиента, а не в каждом счёте.

Статус решает почти всё

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

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

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

• «Окончательный» — настоящий счёт. Он списывает запасы, принимает оплату, может быть проведён в главной книге и там, где действует электронное выставление счетов, подаётся в налоговый орган.
• «Черновик» — незавершённая работа. Он не проводится в главной книге и не принимает оплату: процедура сохранения отказывается записывать оплаты по продаже со статусом черновика, коммерческого предложения или проформы. По умолчанию он не затрагивает и запасы.
• «Коммерческое предложение» — это оферта. Ничего не движется. Ни запасов, ни главной книги, ни оплаты.
• «Проформа» — предварительный счёт. Как и коммерческое предложение, ничего не двигает.

Как рассчитывается налог при продаже

Налог может входить в продажу на двух уровнях, и разница существенна. Налог строки — это ставка, привязанная к отдельной товарной строке. Налог документа — одна ставка, применяемая к документу в целом и выбираемая в поле «Налог на заказ» под сеткой товаров. Большинство компаний используют что-то одно. Применение обоих в одном документе — то место, где в других системах начинаются проблемы, и Skyline Nexus устроен так, чтобы предотвратить именно эту ошибку.

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

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

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

Оплата — отдельная от счёта запись

Карточка «Добавить оплату» внизу формы необязательна. В каждой строке оплаты запрашиваются «Сумма», «Дата оплаты», «Способ оплаты» и «Платёжный счёт», а также необязательное «Примечание к оплате». Кнопка «Добавить строку оплаты» позволяет разделить один счёт между несколькими способами расчёта — это нужно, когда клиент платит частично наличными и частично картой. Под строками выводятся итог к оплате, вносимая сумма (в русском интерфейсе оба поля подписаны «Всего к оплате»), «Сдача» и «Баланс».

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

Статус оплаты документа вычисляется, а не вводится. Он «оплачено», когда полученная сумма не меньше суммы счёта, «частично», когда получено что-то, но не всё, и «к оплате», когда не получено ничего. Этот расчёт повторяется при каждом добавлении, изменении или удалении оплаты, поэтому последующие оплаты следует принимать через «Добавить оплату» в списке продаж (/payments/add_payment/{id}), а не редактированием счёта. Редактировать счёт, чтобы цифры сошлись, — неверный инстинкт; об этом подробно рассказано в руководстве об отмене и исправлении операций.

Что продажа делает с запасами

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

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

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

Что проводится в главной книге

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

Для проводки должны выполняться все три условия, иначе ничего не проводится, и стоит проверить все три, прежде чем решить, что главная книга сломана. Во-первых, продажа должна быть со статусом «Окончательный»: черновики, коммерческие предложения и проформы намеренно пропускаются. Во-вторых, в настройках бухгалтерского учёта (/accounting/settings) должна быть включена настройка «Автоматически проводить продажи». В-третьих, счета должны быть сопоставлены: счёт дебиторской задолженности, счёт выручки и счёт исходящего НДС, настроенные на /accounting/settings/mapping. Отсутствующее сопоставление ничего не портит — оно просто не даёт провести операцию.

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

Электронные счета — там, где они применяются

В Саудовской Аравии модуль электронного выставления счетов автоматически формирует и подаёт счёт, когда продажа сохраняется со статусом «Окончательный». Он включается для каждой локации бизнеса отдельно, а не для всей компании, поэтому одна локация может работать в режиме электронных счетов, а другая — ещё не подключена. Настройки находятся на /zatca/configuration.

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

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

После сохранения

Продажа появляется в списке «Все продажи» с номером счёта, клиентом, суммой, статусом оплаты и — где применимо — статусом электронного счёта. Из меню строки её можно просмотреть, распечатать, добавить оплату, посмотреть оплаты или начать возврат. Детальный просмотр /sells/show/{id} показывает строки, разбивку налога и историю оплат в одном месте — это экран, который нужно открыть, когда Вас спрашивают, что произошло с конкретным счётом.

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

Короткий чек-лист

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