EFSOL для автоматизации электронного документооборота
Одной из наиболее трудоемких составляющих в ведении бухгалтерского учета является внесение закрывающих документов от поставщиков (в просторечии именуемых «первичкой»). Это в частности акты оказанных услуг, товарные накладные, УПД (универсальные передаточные документы), счета-фактуры и многие другие, а также ряд более узко ориентированных документов, например, формы КС в строительной сфере. Все эти «оправдательные документы» критически важны как для бухгалтерии и налогового учета (в части принимаемых к учету расходов), так и для сотрудников, занятых продажей, поскольку даже при фактическом наличии товара (или его комплектующих и/или полуфабрикатов) без их внесения в базу (будь то 1С или аналог) ПО зачастую не позволяет произвести реализацию товара покупателю. Бывают и исключения, когда, например, в базе отключен контроль учета отрицательного остатка. Однако это имеет и свои риски в учетных ошибках, пересортице и возникновению неточностей в реальных складских остатках.
Чем больше объемы продаж или производства, тем больше требуется для этого документации. Если, например, прибор собирается из нескольких десятков деталей, которые приходят от разных поставщиков и при этом различными отгрузками, то для правильного расчета себестоимости одной продажи приходится вносить в учет большое количество закрывающих документов. Таким же сложным может быть и процесс «формирования» единицы товара в сфере услуг, например, в общепите, где на изготовление одного продукта порой нужны ингредиенты от разных поставщиков/изготовителей. И если для повара на кухне салат — это всего лишь одно блюдо, то для бухгалтера это может быть несколько разных документов, необходимых для «комплектации единицы готовой продукции», без которых неверно формируется себестоимость, что может привести либо к занижению налоговой базы (смертный грех в глазах фискального ведомства), либо к завышению (непростительно уже для собственников бизнеса).
В компаниях, относящихся к сфере малого и среднего бизнеса, эти вопросы, как правило, целиком ложатся на измученные плечи бухгалтерии, которая справляется по мере своих сил и возможностей, порой резко не укладываясь в сроки по внесению всей первичной документации. Бывает, что документы проводят менеджеры по закупкам, чьи данные потом правит бухгалтерия на предмет верных счетов учета. Так или иначе, процесс этот занимает много времени и трудозатрат, не исключая при этом ошибок из-за человеческого фактора.
Подобно тому, как вопрос своевременного обмена документами и избавления от хранения гор макулатуры решается через ЭДО и электронно-цифровые подписи, так и для решения проблемы внесения накладных из десятков (а иногда и сотен) позиций решается с помощью автоматизации ручного «вбивания» документов в базы данных. На протяжении многих лет существуют программы интеллектуального сканирования документов с целью их единовременного внесения в БД. В качестве примера рассмотрим программное обеспечение EFSOL.
EFSOL — программа для интеллектуального сканирования данных первичных учетных документов и их автоматизированного внесения в базу данных пользователя [1]. Работает по принципу внешнего приложения, то есть как дополнение к основной программе учета (например, 1С разных модификаций). При этом распознает все наиболее распространенные форматы, включая doc, docx, rtf, excel, pdf, jpeg.
Как выглядит работа с EFSOL на практике? При получении электронной версии документа (через e-mail, ЭДО, сканирование бумажного документа) последний загружается в EFSOL. Программа распознает документ, определяет его принадлежность (например, акт оказания услуг) и вносит в базу данных, находя соответствующие номенклатурные позиции и при необходимости вводя новые. Процесс этот, в зависимости от объема содержимого и качества электронного документа, может занять от нескольких секунд до нескольких минут. Многое также зависит от скорости работы конкретного ПК или мощности сигнала, если работа ведется через сервер либо удаленный рабочий стол посредством приложения.
Что это дает пользователю, например, бухгалтеру или менеджеру? Прежде всего это экономия времени на внесение большого числа позиций. Например, при поставке канцелярских товаров (что присутствует практически в каждой организации любой формы собственности) товарная накладная по форме ТОРГ-12 из, скажем, 60 (Шестидесяти) позиций с разными ставками НДС вносится в течение нескольких минут, в то время как их ручное заполнение в БД может растянуться на полчаса как минимум (учитываются фактор скорости печати исполнителя, количество знаков в наименовании и так далее).
Кто потенциальные пользователи данной программы? Это прежде всего компании с ощутимым (по отношению к имеющемуся персоналу) потоком входящих документов. Вероятно, тем, у кого документов от поставщиков в течение года менее тысячи, вряд ли имеет смысл применять данную программу. Однако бывают и исключения, которые могут быть связаны, например, с большим количеством позиций внутри документа. При наличии «безразмерных» документов от поставщиков работа по их внесению займет большую часть времени работы сотрудников склада или бухгалтерии, и расходы на EFSOL могут быть более чем оправданы.
Также следует отметить ситуации, когда компания нуждается в восстановлении учета. Например, при отсутствии или потери физического носителя с базой данных, но при сохранении подлинников или копий первичной документации вместо непомерного перегруза имеющихся сотрудников или найма новых проще поставить EFSOL и вместо многих недель, а иногда и месяцев кропотливой реставрации внести все данные за несколько дней даже при наличии больших периодов деятельности.
Разумеется, в этом ПО есть и свои слабые места. Например, программа зачастую не понимает, что один и тот же товар (или услуга) с незначительным различием в наименовании является аналогом, поэтому возникает проблема искусственного разрастания учетной номенклатуры за счет появления фактических дублей. Скажем, если просто переставить местами слова в длинном названии единицы товара, то ПО может запросто внести их разные позиции.
Другая проблема связана с выбором счетов в бухучете согласно унифицированному Плану счетов бухгалтерского учета. Как известно, поставка, имеющая материальную форму, может быть как материалом (10 счет в отечественном бухучете) для создания готовой продукции (43 счет), так и товаром для перепродажи (41 счет). EFSOL такие тонкости не понимает, если предварительно не созданы образцы-шаблоны для регулярно повторяющихся операций. Например, если организация покупает муку для выпекания хлеба, то EFSOL при внесении идентичных документов от одних и тех же поставщиков будет вносить документы «по умолчанию». Однако в случае, если та же мука куплена для перепродажи, то исполнителю придется скорректировать ряд показателей, включая счет учета и назначения.
Кроме того, EFSOL не подходит для полноценного внесения ОС (основных средств), а только для проведения первичных документов, на основе которых основное средство принимается к учету. Например, если компания торгует автомобилями, но покупает отдельное грузовое транспортное средство для своих целей (то есть требующее принятия к учету как ОС и дальнейшей амортизации его стоимости), то программа без «работы руками» даже и не увидит проблемы, что данное ТС (транспортное средство) не предназначено для перепродажи …
Ссылка на литературный источник:
Трухан К.А. Автоматизация электронного документооборота с помощью программы EFSOL: Загрузка Документов // Корпоративные информационные системы. — 2020. — №1(9). — С. 53–57. — URL: https://corpinfosys.ru/archive/issue-9/85–2020–9-efsol.
