Бухгалтерия ресторана без человека: Диадок, СБИС, Docsinbox, iiko и 1С в одном цикле
Представьте одну ресторанную компанию. Несколько точек, склад, своя бухгалтерия. Каждый день на точки приезжает товар, и за каждой поставкой едет бумага: накладная, счёт, счёт-фактура или УПД. Часть приходит электронным обменом через Контур.Диадок (Diadoc) или СБИС (SBIS), часть почтой, часть фотографией в рабочий чат точки. Приёмка на точках идёт в Docsinbox (Доксинбокс), склад и калькуляция живут в iiko, учёт в 1С. Вот как выглядит бухгалтерский день этой компании. Весь цикл идёт сам, день в день, и ни один документ не ждёт, пока его кто-то откроет.
Утро. Документы собраны отовсюду. Помощник читает Диадок и СБИС, бухгалтерский ящик и чаты точек. Каждый документ опознан: вид, поставщик, номер, дата, ИНН проверен контрольной суммой, суммы и НДС прочитаны по строкам. Страницы одного акта, пришедшие тремя письмами, склеены в один файл. Накладная, которая приехала и через Диадок, и фотографией в чат, лежит одной записью: склейка идёт по содержимому, а не по имени файла. Скан из почты или чата сверен с документом в обмене: номер, дата, суммы, количество строк. Всё сошлось, и документ идёт дальше.
День. Приёмка на точке. Помощник видит, что накладную приняли сотрудники точки в Docsinbox. Если товар приехал, а приёмки нет, он сам пишет в чат той точки, к которой относится склад, с номером и датой накладной, и возвращается к документу, когда приёмка появилась. Дальше выгрузка в iiko: накладная ушла из Docsinbox в iiko, номенклатура и единицы сопоставлены по истории поставщика, артикула и упаковки, дата стоит по факту получения товара. Новая позиция у знакомого поставщика сопоставлена по его прошлым накладным. Новая упаковка у знакомой позиции пересчитана по коэффициенту, который помощник вывел из самой накладной.
Учёт. Документ заведён в 1С с датой поставщика, скан прикреплён к поступлению. Суммы, НДС и контрагент в 1С совпадают с документом из обмена и со сканом. Поставщик новый, и карточка контрагента заведена по реквизитам из документа раньше, чем его первая накладная легла в учёт. Одна и та же накладная стоит в трёх системах, Docsinbox, iiko и 1С, и в каждой ровно то, что в документе. Диадок, СБИС, Docsinbox, iiko и 1С остаются теми же, что были: помощник работает в системах компании, а не вместо них.
Деньги. По счетам и накладным собраны платёжки. Перед каждой проверено, что этот счёт не оплачивали раньше. Отсрочка посчитана от даты накладной, а не от дня, когда товар приехал. Платёжки ушли в банк по правилам, которые компания задала словами: кому платить без вопросов, кому только после приёмки, какой лимит на день. Клиенту в чат ушла общая сумма платежей дня.
Контроль. К накладной в срок не пришёл счёт-фактура, и запрос поставщику ушёл в тот же день. Акт сверки от поставщика сведён с учётом построчно в обе стороны, расхождения названы с причиной и отправлены поставщику. Поставщик поднял цену на позицию, и это ушло в чат контроля цен с прошлой и новой ценой. Документ датой закрытого периода остановлен до закрытия месяца и внесён отдельной записью.
Вечер. Одна строка в чат владельцу: сколько документов за день, сколько сошлось во всех системах, сколько ушло платежей. Сошедшееся на экране не показывается вовсе. Бухгалтер этой компании утром не обходит почту, СБИС и чаты, не заводит накладные в 1С и не сверяет, что принято на точке. Всё это уже сделано. Он смотрит на одну строку и занимается тем, ради чего его нанимали: деньгами компании.
Правила этого цикла компания задаёт словами. «Счета на оплату в архив не клади», «у этого поставщика всегда договор поставки», «эти ИНН не наши», «этому платим только после приёмки». Сказанное применяется со следующего документа и остаётся навсегда. Новый сценарий заводится так же, фразой, без разработчиков и без ожидания релиза.
Если у вас ресторанная компания, первичка приходит через Диадок, СБИС, почту и чаты, а учёт стоит на Docsinbox, iiko и 1С, пришлите один день документов. Покажем, как он проходит сам.