- Распознавание должно завершаться проверенным документом в учёте, а не только текстом со скана.
- Соответствия товаров, единицы, фасовку, цены и НДС проверяют до окончательной записи.
- Начинаем с ваших документов и версии системы; способ передачи и режим черновика подтверждаем отдельно.
Распознавание накладных убирает повторный ввод: вы загружаете фотографию, PDF или таблицу поставщика, программа извлекает реквизиты и товарные строки, сопоставляет их с вашим справочником и готовит данные для учёта. Сотрудник проверяет спорные места и подтверждает результат. Для Syrve, Poster и BAS способ передачи и возможность сохранить именно черновик проверяем на вашей версии.
Такой процесс можно разработать под ваши документы и правила приёмки. Результат оценивают в учётной системе: нужный товар, количество и закупочная цена появились на правильном складе, а сотруднику не пришлось перепечатывать накладную. Получить текст со скана для этого недостаточно.
Где ручной ввод задерживает учёт закупок
Поставка уже на кухне, бумага осталась у принимающего сотрудника, фотография лежит в чате, а электронную версию бухгалтер получил отдельно. Для оприходования нужно найти документ, выбрать поставщика, отыскать каждую позицию в своей базе и перенести количество с ценой. Затем сверить итог и разобраться с расхождениями.
Дело не только в невнимательности. Поставщик указывает цену за упаковку, а у вас учёт в килограммах. Сокращённое название похоже на другой ингредиент. Скидку написали под таблицей, а не в строке. Даже правильно переписанные числа дадут неправильное поступление, если выбрана другая единица или карточка товара.
Когда документы вводят с опозданием, расчёт себестоимости использует неполные данные. Владелец открывает отчёт и ещё не знает, учтено ли последнее подорожание. Сокращать нужно путь от приёмки поставки до проверенной записи в учёте. Само по себе быстрое чтение фотографии эту задачу не решает.
Что можно прочитать с бумаги, фото, PDF и Excel
Бумажную накладную сначала фотографируют или сканируют. OCR, то есть оптическое распознавание символов, превращает изображение в текст. Затем программа определяет поставщика, дату, номер, товарную таблицу и итоговые суммы. ИИ может помочь разобрать разное оформление и предложить значения полей, но предположения необходимо проверять.
PDF бывает электронным документом с доступным текстом или изображением скана. В первом случае можно прочитать текст и структуру без повторного распознавания картинки. Во втором нужен тот же путь, что для фотографии. Страницы должны собираться в один документ: на последней может находиться итог, без которого сверка не закончится.
Excel с заполненными ячейками разумнее читать как таблицу. Не нужно фотографировать экран, чтобы заново извлекать уже существующие данные. Но остаются объединённые ячейки, несколько листов, скрытые строки и отдельные колонки с ценой до скидки и после неё. Для каждого источника определяем, какие значения считаются окончательными.
На фотографии должен быть весь лист, без обрезанного края и бликов на цифрах. Нечитаемый участок программа должна выделить для проверки или попросить переснять. Подставлять правдоподобную цену вместо отсутствующей нельзя. Поддерживаемые форматы и требования к качеству согласовываем до разработки, чтобы неподходящие документы не стали неожиданностью при запуске.
Как накладная проходит от загрузки до подтверждения
Рабочий процесс состоит из последовательных действий с понятным результатом на каждом этапе:
- Принять документ. Сохранить оригинал, проверить читаемость и принадлежность страниц одной поставке. Сразу выяснить, не обрабатывали ли его раньше.
- Извлечь поля. Собрать поставщика, дату, номер, товары, количество, единицы, цены, скидки, НДС и общий итог, если они присутствуют в источнике.
- Сопоставить с учётом. Найти ваши карточки товаров и поставщика, перевести согласованные фасовки в единицы учёта, выбрать склад.
- Подготовить проверку. Показать оригинал рядом с результатом, выделить новые товары, необычные цены и несовпадения итогов.
- Передать подтверждённые данные. Создать черновик в учётной системе, если такой режим доступен. Иначе проверить данные до записи, а после передачи показать созданный документ.
Под черновиком здесь понимается запись, которая ещё не должна окончательно влиять на учёт. Способ её сохранения зависит от программы. Если доступный метод сразу создаёт поставку, согласование нужно выполнить перед этим шагом. Кнопка подтверждения должна соответствовать реальному моменту записи, иначе сотрудник получит ложное представление о состоянии учёта.
Почему сопоставление товаров сложнее чтения цифр
Номенклатура означает ваш справочник товаров и ингредиентов. Поставщик может называть их иначе. Условный пример: в накладной указаны «сливки кулинарные», а в базе есть несколько карточек с разной жирностью и упаковкой. Похожие слова ещё не доказывают, что продукт один и тот же. Ошибочный выбор изменит остатки и расчёт блюд.
Начинать лучше с проверенных соответствий: артикул конкретного поставщика, согласованная карточка в вашей базе, фасовка и коэффициент пересчёта. Штрихкод помогает искать товар, но сам по себе не объясняет, что посчитано: штуки, упаковки или вес. Даже знакомое название у нового поставщика требует проверки перед сохранением соответствия.
Подтверждённое соответствие можно использовать в следующих документах. Однако оно не делает безопасными любые будущие изменения. Поставщик может поменять массу упаковки или использовать прежний артикул для другой продукции. Изменение единицы, фасовки или описания должно вернуть строку сотруднику. Иначе старое правило продолжит незаметно создавать ошибочные поступления.
Заранее решаем, как поступать с товаром, которого нет в справочнике. Создавать новую карточку по каждому незнакомому названию значит накапливать дубли. Лучше показать подходящие варианты и дать ответственному выбрать существующий товар либо осознанно добавить новый. Тогда справочник остаётся управляемым, а происхождение каждой связи можно объяснить.
Единицы, цены и НДС проверяются отдельно
Количество и цена должны относиться к одной единице. Если поставщик продаёт ящик, а склад считает килограммы, нужна подтверждённая масса ящика. У весового товара фактическая масса может отличаться, поэтому стандартный коэффициент подходит не всегда. Сотруднику нужно видеть исходное количество, правило пересчёта и результат, который попадёт в учёт.
Дальше проверяем, включает ли цена НДС, как распределена скидка и есть ли дополнительные расходы. Итоговую сумму нельзя записывать в поле цены за единицу. Проверяем арифметику строк, а их сумму сравниваем с итогом документа по согласованным правилам округления. Расхождение нельзя скрывать автоматическим изменением последней позиции ради совпадения итогов.
Правила НДС задаёт ваш бухгалтер в соответствии с учётом компании. Программа переносит обозначения и проверяет согласованность сумм. Выбирать налоговый режим по внешнему виду скана она не должна. Отсутствующее обязательное поле или разные ставки в одном документе требуют отдельного согласования. Такие исключения включают в проверку до запуска.
Как передать результат в Syrve, Poster или BAS
API означает программный способ обмена данными между системами. Для накладных нужен доступ к конкретным справочникам и документу поступления. Наличие API вообще этого не гарантирует. Возможности вашей версии, права и условия подключения проверяем до обещания автоматически записывать результат в учётную систему.
Syrve: проверить путь к складскому документу
Syrve публикует документацию для интеграций, включая Syrve Live API и Syrve POS API. Интерфейс для работы кассы или заказов сам по себе не подтверждает возможность записать накладную поставщика. Для вашей установки нужно уточнить доступный интерфейс складского учёта, права, лицензионные условия и поведение создаваемого документа.
Производитель также описывает собственное распознавание PDF с созданием черновика накладной. Сначала имеет смысл проверить его доступность и пригодность для ваших документов. Если остаются особые правила сопоставления или другой канал получения, оцениваем дополнение. Конкретный метод записи и сохранение без проведения подтверждаем на тесте, без универсального обещания для всех версий Syrve.
Poster: поставка через API после проверки
В официальной документации Poster есть метод storage.createSupply для создания поставки. Он принимает поставщика, склад, дату и позиции с идентификатором, количеством и ценой. Также описан необязательный параметр фасовки. До отправки нужно установить, каким объектам Poster соответствуют строки в документе поставщика.
Режим черновика в этом описании метода не указан. Не обещаем его по умолчанию: можно сделать промежуточное окно проверки и создавать поставку после согласования. Налоговые поля и нужные вам настройки проверяем отдельно. После вызова проверяем успешность операции и полученный документ, а не только сам факт отправки запроса.
BAS/1С: импорт или обмен под конфигурацию
Для платформы 1С официально описаны файловый обмен, HTTP-сервисы и планы обмена. HTTP-сервис позволяет программам передавать запросы и данные. План обмена определяет участников и состав передаваемых данных. Это инструменты для разработки, а не готовая кнопка импорта любой накладной в каждой конфигурации BAS.
Проверяем название и версию конфигурации, доработки, режим работы и разрешённые способы подключения. Началом может стать файл для существующей обработки загрузки. Другие варианты: отдельный сервис или настроенный обмен. Создание непроведённого документа и его обязательные поля проверяем в вашей базе на безопасных тестовых данных, учитывая изменения типовой конфигурации.
На странице интеграции с 1С и BAS описаны наш подход к карте данных, проверке обмена и передаче кода. Распознавание документов поставщиков оценивается как отдельный сценарий под ваш учёт. Одинаковый готовый модуль для всех систем мы не обещаем.
Как точные накладные связаны с технологической картой
Технологическая карта блюда описывает состав, количество ингредиентов и правила приготовления. Калькуляция блюд определяет затраты на ингредиенты по принятым в учёте ценам. Правильное поступление даёт данные для расчёта, но не создаёт верную рецептуру автоматически и не проверяет фактический размер порции на кухне.
Если поступление отнесли на другую карточку продукта, в рецептуре может остаться старая стоимость нужного ингредиента. Если перепутали килограммы и упаковки, ошибочными окажутся количество и цена единицы. Поэтому одного совпадения общей суммы накладной мало: итог может сойтись даже при неправильном распределении между товарами. Проверять нужно и сами строки.
Фудкост показывает долю затрат на продукты в выручке; конкретный способ расчёта нужно согласовать для вашего отчёта. Закупочные цены нужны для оценки затрат, но фактическое потребление зависит также от остатков, списаний и инвентаризаций. Полная себестоимость бизнеса не ограничивается ингредиентами: зарплату и другие расходы учитывают отдельно.
Что остаётся человеку и как действовать при сбое
Человек подтверждает полученный товар, решает расхождения с поставщиком и согласовывает новые соответствия. Скан не доказывает, что привезли именно такое количество и что качество подходит. Распознавание помогает оформить результат приёмки. Решение о фактическом приёме продукции остаётся у команды, которая видит поставку и отвечает за неё.
В согласованном решении нужны понятные состояния: документ ждёт проверки, содержит ошибку, готов к передаче или уже записан. Если доступ к учётной системе прекратился, накладная должна остаться в очереди с объяснением для ответственного. Обновление программы или новый формат поставщика тоже требуют проверки, даже когда код интеграции не меняли.
Особенно опасна ситуация, когда система приняла документ, но ответ потерялся. Слепой повтор может создать вторую поставку. Сначала нужно сверить состояние в учёте по сохранённой связи или реквизитам, затем разрешить повтор. Исправленный документ также не должен незаметно перезаписывать согласованную запись. Эти правила восстановления входят в обсуждение процесса до его запуска.
От чего зависит объём разработки
Для оценки важно количество разных правил. Повторяющаяся таблица с согласованным справочником и фотографии от разных поставщиков требуют разной работы. Отдельно учитываем готовность товарных соответствий, доступный способ записи и проверку исключений. Количество страниц само по себе не показывает сложность: короткий документ с неизвестной фасовкой может потребовать больше внимания, чем длинный с проверенными товарами.
В предложении стоит разделить разработку и расходы во время работы: распознавание, необходимый доступ к учётной системе и поддержку после обновлений. Условия сторонних сервисов проверяем перед оценкой. Обещать отсутствие текущих расходов, не разобравшись в этих зависимостях, было бы неправильно. Бюджет обсуждаем после проверки реального пути документа.
Также согласовываем, кто видит накладные и где они хранятся. Реквизиты контрагентов и закупочные цены нужны не всей команде. До внешнего распознавания определяем допустимость передачи данных, срок хранения и удаление копий. Для первоначальной оценки подходят обезличенные образцы с сохранённой структурой.
Назначьте ответственного за очередь ошибок. Инструкция должна объяснять, как проверить статус, исправить строку и продолжить после сбоя. Если сотрудник не понимает причину остановки, он может ввести ту же поставку вручную, а поздний автоматический повтор создаст дубль. Согласованный порядок действий нужен и для такого случая.
Как начать под ваш учёт и проверить пользу
Для первого разговора достаточно названия системы, версии и обезличенных примеров документов. Покажите обычную накладную и неудобный случай: другую фасовку, нечёткую фотографию, скидку или новый товар. Добавьте пример того, как данные должны выглядеть в учёте. Пароли в первом сообщении не нужны: сначала определяем задачу и возможный путь подключения.
Согласовываем минимальный результат: определённые форматы, необходимые поля, правила сопоставления и шаг подтверждения. Такой сценарий можно реализовать в рамках индивидуальной разработки под ваш процесс. Дополнительные каналы, другие документы и более широкий обмен добавляем после проверки первого рабочего пути, когда понятно, какую ручную работу он действительно убрал.
На пилоте, то есть пробном запуске, сравниваем время полного ручного ввода со временем загрузки, проверки и исправлений. Считаем нераспознанные строки, ошибочные соответствия и повторные документы. Проверяем результат в системе назначения: склад, товар, количество, цену, НДС и состояние документа. Красиво извлечённый текст не заменяет проверку созданного поступления и удобства ежедневной работы.
Если штатный импорт или уже доступный инструмент решает задачу, начать стоит с него. Собственная разработка нужна там, где остаются ваши правила, нестандартные документы или ручной перенос между программами. Возможности ИИ-ассистентов для бизнеса и наши публично описанные интеграции помогут обсудить объём. Можем разработать этот процесс под вас; оценка начинается с документов и проверки системы.
Частые вопросы
Что такое распознавание накладных?
Это извлечение реквизитов и товарных строк из фотографии, скана или электронного документа. Для записи в учёт нужны сопоставление с вашим справочником, проверка единиц, цен и НДС и подтверждение сотрудником. Распознанный текст сам по себе ещё не означает правильно оформленное поступление.
Можно ли распознавать накладные из фото, PDF и Excel?
Да, процесс можно разработать для этих форматов. Фото и сканированный PDF требуют распознавания изображения, электронный PDF можно читать по тексту, а Excel лучше обрабатывать как таблицу. Форматы и требования к качеству проверяем на ваших примерах. Нечитаемые поля передаём на проверку.
Можно ли автоматически заносить накладные в Syrve, Poster или BAS?
Возможность и способ записи проверяем на вашей версии и с вашими правами. Poster документирует создание поставки через storage.createSupply, но режим черновика там не описан. Для Syrve уточняем путь к складскому документу и доступность штатного распознавания. Для BAS проверяем импорт, HTTP-сервис или настроенный обмен под конфигурацию.
Нужен ли человек после распознавания накладной?
Да. Ответственный подтверждает фактически полученный товар, новые соответствия, фасовку, спорные цены и налоговые поля. Согласование выполняют до окончательной записи или проведения. Если учётная система не поддерживает черновик, проверку размещаем перед передачей. Безошибочное распознавание не обещаем.
Как распознавание накладных помогает калькуляции блюд?
Правильное поступление связывает закупочную цену и количество с нужным ингредиентом. Это даёт данные для калькуляции по технологической карте. Саму рецептуру оно автоматически не исправляет: порции, потери, списания и остатки требуют отдельного учёта и проверки.
