Контроль правила двойной записи в платформе Ultima Businessware осуществляется на уровне ядра. Даже программист не в состоянии нарушить или обойти это правило.
Посему в недрах Ultima Businessware дебет всегда бьется с кредитом, неважно, сколько миллионов документов вы проводите ежемесячно.
В решениях некоторых коллег по рынку, когда объем транзакций превышает определенный уровень, контроль правила двойной записи умышленно отключается, в противном случае скорость работы падает до состояния нестояния. Результат в плане качества учета (и неразрывно связанном с ним объеме воровства) немного предсказуем.
С решениями Ultima такой проблемы не существует, проверено на 4000 пользователей в реальной жизни и на 18 000 на стендовом тестировании.
Традиционно в ERP-системах "модульность" реализована следующим образом. Есть «Товарный модуль», «Финансовый модуль», «CRM», «WMS» и так далее (в постсовковых системах это что-то типа «АРМ кладовщика», «АРМ руководителя» и далее по списку).
Для чего? В первую голову — в маркетинговых целях.
Сиречь для развода на пущее бабло.
Например, чтобы в течение цветочно-конфетного периода до подписания контракта иметь возможность утешать перспективного заказчика в стиле «Вот купите складской модуль, он всего 70 килоевро стоит, а потом финансовый докупите когда подрастете». В итоге клиенту приходится докупать "модуль" за "модулем", но птичка уже в клетке. А первоначальный бюджет внедрения вроде бы не выглядел пугающе.
Эффект такого подхода к системной архитектуре примерно следующий: финансисты могут запросто изменить суммовые остатки складов БЕЗ РЕАЛЬНОГО ДВИЖЕНИЯ ТОВАРА. То есть ни приходов, ни расходов, ни любых других товарных операций не было, а сумма склада волшебным образом изменилась.
Результат в плане качества и… да-да, тот самый.
В решениях Ultima подобные чудеса невозможны по определению. Вся система учета построена вокруг концепции интегрированных и согласованных данных, что контролируется ядром платформы, и изменения состояний учетных регистров (счетов — в бухгалтерской транскрипции) могут порождаться исключительно документами движений реальных ценностей — товаров либо денег.
В любой момент вы можете получить баланс предприятия, отчет о прибылях и убытках и отчет о движении денежных средств, нажав соответствующую кнопулю на компьютере (как вариант — совершив эпохальный тычок в iPad). Эти отчеты при желании можно построить с детализацией вплоть до конкретного документа (кассового, банковского, продажи — любого). А у документа при желании можно посмотреть всю историю его изменений. Мгновенно можно получить ответ на вопрос, почему в сводной отчетности для акционеров именно такие цифры. Для построения отчетности система в считанные секунды обрабатывает сотни тысяч документов.
Внесение изменений в отчетность возможно только внсеением корректировки в документ реальной хозяйственной операции. И только в открытом периоде. Такое изменение сразу отражается на показателях смежных отделов, что ведет к многократной выверке данных с разных углов зрения. В итоге отчетность на 100% отражает реальное положение дел в компании.
Для компаний, работающих с большими и сверхбольшими базами данных, в eCommerceERP существует опция вынесения службы расчета отчетов (занимающаяся постобработкой выборки с СУБД), на отдельный сервер (-а) для распределения нагрузки и масштабируемости. Данные при этом могут считываться с резервного standby-сервера, освобождая таким образом основной сервер БД для проведения real-time транзакций.
Кстати, сколько времени в вашей компании занимает процесс подготовки хотя бы просто ежемесячной отчетности — после закрытия месяца? В пределах недели — уже выдающийся результат. А реально, если честно, то минимум две, а то и к концу только следующего месяца акционерам становится известно, что же наработали в предыдущем.
Аналитические инструменты системы позволяют сразу получать нужные данные (закупки, склад, транспортная логистика, продажи, финансы, гарантия) без промежуточной агрегации (XLS-файлы, тысячи их) и ручного переколбашивания обработки в M. S. Excel (ох уж эти пивоты!). Штат "аналитиков" (девочек-волшебниц экселя) просто не нужен. Вы получаете данные сразу и в том виде, в котором они вам нужны.
Поскольку управленческий баланс рассчитывается непосредственно в eCommerceERP (являясь, по сути, одним из видов отчетов), само собой разумеется, что в системе ведется учет ВСЕХ хозяйственных операций и активов предприятия, в том числе НМА и основных средств.
В решениях Ultima вы получите отлаженный процесс оплат с минимальными потерями времени сотрудников. Все заявки на оплату автоматически находят своих подписантов, определенных матрицей согласования документов. У вас поменялся финансист или директор филиала? — пара кликов в кадровом разделе, и заявки на согласование платежа приходят уже новому сотруднику. Ни единого разрыва в операционной деятельности. Причем в результате действий кадровиков новому сотруднику автоматически назначаются права в системе, соответствующие его должности, а у старого отнимаются (или меняются в случае перевода на другую должность).
Копеечная экономия? Попробуйте просуммировать стоимость внутреннего бардака в целом по компании.
Естественно здесь речь идет не только о заявках на оплату, но и о любом документе системы (договоре, платежной ведомости сотрудникам, заявке на набор персонала, бюджете и прочее).
Платежный календарь у вас, вероятно, составляют девочки из бухгалтерии в Excel? В случае внедрения Ultima этим девочкам можно посочувствовать — система заточена на всемерное сокращение народонаселения компаний как раз за счет подобного планктона. В Ultima платежный календарь строится автоматически на основании текущих остатков по кассе и расчетным счетам, плана закупочных и операционных платежей (в плане учитываются и регулярные выплаты типа заработной платы), а так же прогноза поступления денежных средств. Казначей либо утверждает предлагаемый системой план платежей (что происходит в большинстве случаев), либо вносит в него коррективы. Классическая работа по отклонениям.
Важнейший отчет для компании. Для грамотного управления финансами предприятия в системе есть как прогнозный ДДС, так и фактический, а так же план/факт.
Прогнозный ДДС строится на основании планов продаж, закупок с учетом средней отсрочки платежа контрагентам, бюджета операционных платежей, бюджетов инвестиций и заимствований. Например, при заведении в системе лизингового договора, платежи по нему начинают автоматически отображаться в прогнозном ДДС.
Фактический ДДС может детализироваться до каждого офиса предприятия. Для этого:
Если с банками есть договоренность о финансовых ковенантах, финансовый директор за секунды может проверить, на сколько эти ковенанты выполняются.
Помимо классического отчета по продажам, который показывает выручку, прибыль, себестоимость в разрезе точек продаж (городов, регионов) и товаров (товарных категорий, брендов), система предоставляет:
Бюджетирование — обычно больная тема для отечественных предприятий. Как минимум, чрезвычайно бюрократизированный и в силу растянутости по времени малоосмысленный процесс с точки зрения операционной применимости. В массе случаев бюджет принимается задним числом — так же как и планы в совковую эпоху. В общем, бюджет ради наличия бюджета, без бюджета то вроде как некруто получается.
А вот как бюджетный процесс реализован у нас.
При составлении общего бюджета затрат предприятия бюджет ФОТ автоматически рассчитывается на основе формульных данных из кадровой структуры и планируемого изменения штата.
Прочие затраты по подразделению планируются руководителем подразделения — по перечню своих статей затрат. Бюджетный процесс строится на принципе «снизу-вверх». Планирование бюджетов затрат начинается с самых мелких структурных единиц, бюджет следующего более крупного подразделения складывается из бюджетов сводных бюджетов подчиненных отделов плюс свои статьи затрат. И так до самого верха.
После формирования первой версии бюджета начинается процесс утверждения. Маршрут утверждения бюджета напрямую связан с матрицей подчинения, с помощью которой определяется последовательность руководителей, утверждающих бюджет.
При использовании матричной оргструктуры утверждение бюджета происходит в двух измерениях: вначале директорами филиалов утверждаются бюджеты своих филиалов, затем происходит функциональное согласование: например, директор по логистике утверждает сводный бюджет всех складов и отделов логистики всех филиалов, или директор по продажам — сводный бюджет по всем отделам продаж всех филиалов и т. д.
В итоге высший исполнительный орган компании утверждает бюджет затрат предприятия.
Задачей информационной системы в данном случае является:
Минимизировать трудоемкость составления бюджета — система может сама подготовить первую версию на основании статистики и планируемых изменений в штате — руководителю требуется внести минимум ручных корректировок.
Сделать процесс согласования бюджета предельно прозрачным и БЫСТРЫМ. Всегда четко видно, на каком руководителе "зависло" согласование.
У руководителя любого уровня, включенных в бюджетный процесс, есть возможность отказать в утверждении, вручную исправив численные параметры по интересующим статьям затрат. Сводный бюджет этого уровня иерархии уезжает на декомпозицию по корпоративному дереву в противоположном направлении «сверху-вниз».
В итоге, когда сводный бюджет затрат компании утвержден, включается механизм контроля. Ни одна заявка на оплату не сможет быть сформирована, если по соответствующей статье бюджета возникло превышение. В этом случае необходимо будет согласовывать документ корректировки бюджета. Геморройно? Да. Но только так можно приучить ваших руководителей ответственно относиться к планированию ресурсов вашей компании.
Впрочем, по желанию клиента контроль может быть нежестким — при превышении лимита система дает проводить документы, но генерирует заданные бизнес-логикой перечень алертов SMS/e-mail.
Отдельно система позволяет вести учет по проектам компании. Например, открытие новых магазинов. Для проекта задается бюджет, по которому контролируются все проектные договоры и заявки на оплату. В любой момент можно получить отчетность по всем платежам и затратам проекта.
В реалиях разумно организованного российского бизнеса, бухгалтерия — это строго сервисное подразделение, генерирующее отчетность для фискальных органов.
Именно в такой парадигме и тесном содружестве с 1С: Бухгалтерией и реализован блок официальной отчетности в решениях Ultima.
Вот так, в общих чертах, у нас реализован финансовый учет.
Подробнее об используемых компонентах: Ultima MobileView
Подписаться на анонсы
Запросто возможно с eCommerceERP.
На реальном примере работы Ultra Electronics доказано, что торговой компании с оборотом в миллиард долларов, будет достаточно содержать всего четырех бухгалтеров.
Как была оптимизирована работа бухгалтерии Ultra Electronics
Цель бизнеса — зарабатывать деньги, а создание рабочих мест лишь побочный эффект. Зарабатывайте деньги.