Финансовый контур: операции, ДДС, инкассация и сверка

Нет. AIERP ведёт управленческий контур параллельно с бухгалтерией. Правилом «выгружать в 1С» на пересечении статьи и контрагента вы выбираете, какие операции уходят в 1С — обмен идёт по стандартному формату EnterpriseData, который понимают 1С:Бухгалтерия, 1С:ERP и 1С:УТ. Бухгалтерская отчётность и налоговая декларация остаются в 1С:Бухгалтерии.

Часто да, но не всегда. Касса — это та точка, через которую деньги физически прошли (наличными или эквайрингом). Точка отчёта — магазин, на котором операция учитывается в отчётах. Пример: клиент заказал товар в магазине ТТ-7, забрал из ПВЗ ТТ-1 и оплатил там же. Приход — на кассу ТТ-1, отчёт о выручке — по ТТ-7. Два поля закрывают такие сценарии без костылей.

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

Система читает текущий остаток наличных в кассе магазина и сравнивает с запрашиваемой суммой. Если хотите забрать больше, чем фактически есть — операция отклоняется с сообщением «Сумма инкассации превышает остаток в кассе: X ₽», и проводки не создаются.

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

У статьи пять переключателей. «Операционный расход» — включает статью в анализ OPEX. «Не считать расходом» — статья не учитывается как расход (инкассация, перевод между счетами). «Не выбирать в операции» — узел доступен только для группировки. «Требует закрывающего документа» — без акта или накладной операцию не закрыть. «Системная» — защита от удаления (например, у системной статьи «Инкассация»).

Да, глубина не ограничена. В дереве отображаются количество операций и привязанных правил на каждой ветке. На экране «Статьи ДДС» каждая компания собирает свою структуру БДДС под себя: «Реклама → Контекстная → Yandex Direct», «Аренда → Магазины → Центральный регион», «Логистика → Доставка клиентам → Курьер».

У операции два уровня: «согласовал сотрудник» и «согласовал руководитель точки». Обычно кассир магазина согласует первым, финансовый директор управляющей компании — вторым. Лимиты по сумме настраиваются через ролевую модель. Все ожидающие согласования собраны в отдельной очереди — финансист видит, что висит.

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

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

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

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

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

Указываете юрлицо, контрагента и период — система собирает входящее сальдо, ленту операций (отгрузки и оплаты, отсортированы по дате с дебетом и кредитом), итоги и исходящее сальдо. Готовый акт выгружается в PDF (для отправки контрагенту) и Excel (для внутренних нужд).

PDF и Excel. PDF формируется в A4 с поддержкой кириллицы — можно сразу отправлять контрагенту по почте. Excel удобен для проверки внутри компании. Имя файла включает период сверки. Есть и сводный вариант — Excel сразу по всем контрагентам компании.

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

Да, это поведение по умолчанию. Запись видна сотруднику, если у него есть доступ хотя бы к одной из трёх точек, привязанных к операции: точка отчёта, касса или точка согласования. Директор сети видит всё без ограничений. Это закрывает реальные сценарии вида «операция приписана к ТТ-7, но согласована из УК».

Каждая финансовая операция знает, откуда она пришла: из заказа, из приёмки, из платежа, из рейса логистики. На карточке операции виден источник со ссылкой («Создано из заказа №4218» или «Приход по рейсу №LR-128»). Параллельно есть отдельная ссылка на закрывающий документ — акт, накладную, счёт-фактуру.

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

Запись на пересечении контрагента и статьи ДДС. Поля: шаблон описания операции (подставляется автоматически при выборе этой пары), правило «выгружать ли в 1С», правило «создавать ли черновик закрывающего документа автоматически». Это даёт тонкую настройку: «по статье „Реклама“ с конкретным контрагентом — всегда создаём черновик акта и помечаем к выгрузке в 1С».

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

Бюджета доходов и расходов с лимитами по статьям в текущей версии нет — есть фактическое движение денежных средств в аналитике. Платёжного календаря как отдельной сущности тоже нет — но будущие платежи можно отражать через дату операции в будущем и пометку «скрыть из основного списка». Если нужен полноценный БДР с план-факт — это отдельная разработка под клиента.

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