1с отчет из разных баз
Эта публикация касается электронного документооброта с контролирующими органами непосредственно из программных продуктов 1С ("1С-Отчетность").
Отличная вещь скажу я вам, даже работает уже во всех типовых конфигурация на платформе "1С:Предприятие 8" и главное везде одинаковый принцип работы и объекты метаданных.
Но есть проблема, с которой я сталкиваюсь постоянно.
У меня несколько юридических лиц, которые ведут бухгалтерский учет в "1С:Бухгалтерии", а персонифицированный в "1С:Зарплате и управление персоналом". В обеих информационных базах у меня одна и таже учетная запись для электронного документооборота.
Из "1С:Зарплата и управление персоналом 8" я отправляю отчетность в ПФР и ФСС, а из "1С:Бухгалтерия 8" во все остальные контролирующие органы. И бывает такая ситуация, что отправил я отчетность из одной информационной базы, а ответ получил в другую. В результате у меня ни в одной из баз нет целой картины. Приняли у меня отчет или нет, что написано в протоколе, и так далее я уже не могу узнать.
Почему так происходит? Я могу только предполагать, что происходит это следующим образом:
2) Содержимое почтового ящика хранится на сервере оператора связи или провайдера, который предоставляет услугу электронного документооборота. Но данные там хранятся только до передачи их адресату. Письма полученные адресатом удаляются с сервера оператора и второй раз их уже не получишь.
Вот и получается, что писал письмо в одном месте, а получил ответ в другом. Несмотря на то что данные не теряются, а лишь располагаются в разных местах, объединить их штатными средствами не представляется возможным.
Объясню по-простому механизм электронного документообррота в 1С-Отчетности:
1) Создаем некое письмо для контролирующего органа, допустим декларацию по НДС.
Как работать с обработкой:
Допустим вы отправили декларацию НДС из ПП "1С:Бухгалтерия", а ответ от ИФНС получили в ПП "1С:Зарплата и управление персоналом".
1) Заходим в ПП "1С:Зарплата и управление персоналом" и запускаем обработку.
2) Указываем параметры подключения к ПП "1С:Бухгалтерия".
4) Нажимаете кнопку Перенести. Ждете. Готово.
Данная обработка работает на платформах "1С:Предприятие" 8.2 и 8.3 в толстом клиенте на обычном приложении.
Так как 1С не предлагает решения описанной проблемы, то я хотел бы развить эту обработку и предоставить возможность работы на управляемых формах, но мне нужна ваша помощь в тестировании. Также я хочу понять актуальна ли эта проблема или есть другое более простое решение. Жду ваших комментариев.
Ведущий разработчик ГАОУ ДПО ТемоЦентр Василий Попов на онлайн-митапе Инфостарта «Интеграционные решения в 1С» поделился кейсом о том, как собрать данные для отчетов из +100 баз, какой стек технологий для этого использовать, и к каким проблемам нужно быть готовым.
Меня зовут Василий Попов. Хочу рассказать о нашем опыте сбора информации с большого количества баз. Какие у нас были трудности, как мы их решали. Расскажу весь путь развития архитектуры нашего решения, возможно, что-то вы сможете почерпнуть для себя.
Начальные условия
Необходимость извлекать информацию из информационных баз у нас появилась исходя из начальных условий:
У нас большое количество баз, вся наша инфраструктура построена на 1С:Фреш. 1С:Фреш основан на технологии мультиарендности – когда в одной информационной базе находится множество разделенных областей данных. Это выглядит так, как будто в одну информационную базу помещены 10 файловых баз, и переключение между ними возможно путем смены области данных. Подобные решения – Битрикс24, amoCRM и прочие SaaS-сервисы.
У нас большое количество областей данных: 700 учреждений,1400 областей данных. Мы используем конфигурации «Бухгалтерия» и «ЗУП».
При таких условиях у нас были проблемы. Например:
Хотелось иметь возможность консолидировать данные за систему – так как много учреждений, хочется видеть все данные в одном месте.
До начала нашего проекта по сбору информации эта проблема решалась с помощью внешних отчетов. Аналитики заходили в информационные базы, запускали отчет, указывали области данных, с которых надо было собирать информацию. Для каждой области данных отрабатывал запрос, который собирал отчет в один табличный документ. Потом этот табличный документ уже обрабатывался в виде Excel – и тут тоже была проблема, потому что приходилось вручную обрабатывать информацию с помощью ВПР в огромных Excel-файлах.
Еще одна проблема заключалась в том, что доступ к сбору информации с помощью внешних отчетов был возможен только на тестовом контуре – там можно было зайти в информационную базу и что-то проверить. Но там помимо отчетов проводилось тестирование новых возможностей, и, получается, что эту информацию могли испортить, изменить. Доверять такой информации было тяжело.
Помимо этого существовал BI-контур. Но доступ в него был возможен только через SOAP-сервисы, и только на чтение, чтобы ничего нельзя было поменять.
Принцип работы модуля для получения доступа к информации
Доступ к информации из областей данных был реализован с помощью модуля, который мог получать запросы и выполнять их, отправляя результаты в систему, которая его запрашивала.
В этот модуль можно было передать текст запроса. На слайде показан пример передаваемого текста запроса – это пример запроса кредиторской задолженности на дату. Сюда передается параметр даты остатков и накладывается условие с поиском счета по коду через «ПОДОБНО».
При передаче параметров запроса для случая, когда нам надо было собирать данные по остаткам на сегодня, мы для себя сделали вычисляемое поле, в котором в значении параметра писали:
Тем самым могли получить динамический параметр запроса, который всегда мог изменяться.
В модуле был реализовано несколько вариантов формата возвращаемых данных:
ЗначениеВСтрокуВнутр – это внутренний формат платформы 1С;
и потом мы еще добавили JSON.
На слайде показано, как выглядел ответ, который пришел из целевой области данных. Здесь приведен вариант ответа в формате JSON, но если в качестве формата возвращаемых данных использовался ЗначениеВСтрокуВнутр, то приходил просто текст внутреннего представления структуры.
В ответе указывались:
флаги ПустойЗапрос или ОшибкаВыполнения;
и идентификаторы для мониторинга выполнения задания.
Так как у нас множество информационных баз, нам нужно понимать, из какой области данных эти данные прилетели и была ли какая-то ошибка при выполнении этого запроса.
Также в модуль передается адрес для отправки, так как обращение к модулю выполняется асинхронно – мы получаем информацию о том, что задание принято, и уже по информации, которая была передана асинхронно после выполнения запроса, его результат улетает в указанный адрес.
Первая архитектура
В таких условиях мы реализовали первую архитектуру – она была выполнена «в лоб».
У нас был BI-контур, мы реализовали на 1С менеджер заданий и забирали информацию из BI-контура по SOAP.
Мы возвращали таблицу значений результата запроса в формате ЗначениеВСтрокуВнутр(ТаблицаЗначений).
Примерное время сбора – 20 минут из 700 областей.
Данные мы приземляли в тот же менеджер заданий – в регистр сведений, который мы описали как модель данных. На примере РС КредиторскаяЗадолженность – у нас есть измерение «Область» и ресурсы. «Область» сделано измерением для того, чтобы устаревшую информацию по области можно было перезаписывать – это позволит распараллелить запись из всех заданий и отбирать отдельно по области.
Время приземления данных в модель – 20-30 минут. Я уже говорил, что собранная информация записывалась в регистр сведений, и показал укороченную версию модели данных, но на самом деле у этого РС было 16 ресурсов, поэтому данные записывались довольно долго.
Проблемы первой архитектуры
Мы опробовали первую модель, и поначалу все было нормально, но в дальнейшем, когда мы начали развивать эту историю, начались проблемы.
Большой объем новых моделей. На тот момент мы начали строить новую модель, объемы которой были больше, чем объемы первой модели. Если в первую модель при запросе приходило порядка 1 млн записей, то в новую модель приходило информации порядка 3 млн. Это были остатки, и с каждым месяцем объем этой информации увеличивался.
Начались проблемы по ресурсам – при записи не хватало мощностей сервера, выскакивали ошибки блокировки и нехватки памяти, процессы рубились. Чтобы приземлить данные в модель, нужно было заново перезапускать процессы.
Тогда наши коллег-аналитики спросили: «Нельзя ли приземлить эти данные не в 1С, а в какую-то другую СУБД, из которой они могли бы забирать данные?»
В качестве другой СУБД они предложили PostgreSQL, потому что на тот момент они уже с ней работали, и им это очень нравилось.
Вторая архитектура
Мы решили отказаться от 1С как от хранилища данных и все писать в PostgreSQL.
Реализовали формат запроса JSON, чтобы можно было приземлять через Go, потому что на Go не было парсера для результата, возвращаемого функцией ЗначениеВСтрокуВнутр().
Пришлось реализовать опрос нашего агента о получении информации, что он ее получил и записал, чтобы не пришлось повторно запрашивать ее в BI-контуре.
Получилась вторая архитектура.
Проблемы второй архитектуры
Но после ее реализации у нас в дальнейшем снова возникли проблемы.
Проблема добавления новых моделей. Чтобы добавить новую модель, аналитикам приходилось привлекать разработчиков – только разработчики могли написать модель, скомпилировать ее и доставить на прод.
Поэтому мы решили написать для каждого аналитика песочницу – назвали ее рандом-таблица, для каждого аналитика она была индивидуальной. Сначала в ней было 30 полей данных, потом 70, а сейчас уже под 100 полей. На этих данных аналитики могли обкатывать новые запросы, новые заборы информации.
Когда процесс извлечения этих данных и преобразования их в отчет был полностью отлажен, аналитики формировали задание разработчикам на то, чтобы написать модель уже конкретно под этот набор данных, и эта модель собиралась и доставлялась на продакшн.
Что такое NSQD и чем отличается от остальных:
На основании этого мы решили сделать третью архитектуру.
Третья архитектура
Также мы разделили агента и того, кто будет получать информацию, подписчика. Если раньше оба этих процесса работали внутри приложения, то теперь подписчик стал собирать информацию из nsqd.
Что это нам дало?
Единственный недостаток – это незначительная нагрузка на ЦПУ, теперь всегда показывает, что ЦПУ загружено на 50%.
Планы
Еще в этом решении нам не понравилось, что в одном приложении у нас реализовано две функциональности: отправка данных и чтение данных из очереди. Мы решили, что в следующей версии у нас будет реализован другой подход, мы разделим нашего агента на две части:
одна часть будет получать данные из BI и класть их в очередь,
вторая часть – подписчик очереди – то есть, мы ее можем гораздо сильнее масштабировать, получать информацию и класть ее в Postgre.
Вопросы
Расскажите подробнее, что такое NSQ, чем она отличается от RabbitMQ и Kafka, работает ли она через AMQP или у нее какой-то свой протокол?
NSQ больше всего похож на NATS, написан на Go, также как NATS. В нем не нужно тащить себе в инфраструктуру Zookeeper, как это сделано в Kafka. И имеет в архитектуре два приложения – nsqlookupd и nsqd. Экземпляры nsqd хранят в себе информацию о топиках, а nsqlookupd являются для конскьюмеров дискавери до nsqd. Таким образом, мы можем масштабировать у себя и nsqlookupd и nsqd. У нас появится двойная защита в плане отказоустойчивости.
По поводу формата – я особо не вдавался в подробности, какой там формат, потому что у нас реально получилось его затащить и начать использовать за два дня. И пока не было времени вдаваться в подробности, какой там формат. Это был лишь эксперимент. Если в его техническом обслуживании появятся какие-то проблемы, мы его в любое время можем заменить на какое-то более продуктовое решение, которое используется в Enterprise.
Сколько времени заняла реализация всего этого проекта?
Реализация была растянута по времени, было отвлечение на разные моменты. Этот проект у нас длится с 2019 года, он плавно развивается, не особо быстро.
Где производится трансформация в аналитическую модель? В PostgreSQL?
Трансформация производится в Qlik. Забирается информация из разных таблиц и уже аккумулируется в Qlik. Базой Qlik занимаюсь не я, а отдельные аналитики, моя задача – собрать данные.
Рассматривали ли вы архитектуру с использованием выделенной базы 1С, которая содержит актуальную модель данных и аналитику – и наполнение этой базы через событийную интеграцию?
Да, в первоначальной архитектуре мы хранили модели в 1С, но из-за того, что большой объем информации, оптимизировать ее было очень дорого, легче было писать данные в PostgreSQL.
Насколько выходной продукт, написанный на Go, получается быстрее или медленнее по производительности, чем на 1С? Насколько масштабный этот сервис? Или он из пяти строчек состоит?
Он не масштабный, изначально в нем было сделано много, сейчас уже пытаемся привести в порядок код.
В команду Go-программистов входил только ты или у вас еще были специалисты?
Мы стараемся иметь универсальные навыки, разбираться и в Go, и в Python, и в 1С. Мы стараемся растить эти компетенции внутри себя.
Насколько легко у 1С-ников получается осваивать Go, насколько они хотят на нем писать?
Go как второй язык программиста – очень легкий. Основные понятия можно выучить за два дня, посмотрев Go-Tutorial на официальном сайте.
Что, по-твоему, побеждает в холиваре Go vs Java vs Python?
Нам понравился Go, мы попробовали – он зашел. Поэтому был выбран Go. Если для Python есть много возможностей применения – нейросети и т.д., то для Go – это язык для создания инфраструктурных приложений. Писать на нем – красота. Плюс не нужно тянуть никакую Java-машину, они легковесные, Docker-контейнеры там вообще занимают мало места. В плане оптимизации расходов на ресурсы инфраструктуры, Go лучше, чем Java.
А что лучше для написания интеграционных сервисов-прослоек – написать веб-сервис на Python или на Go? Куда лучше вложить силы?
Я думаю, на Go, потому что, если это будет высокая нагрузка, есть смысл делать это на компилируемом языке.
Реализован ли какой-то мониторинг всей этой системы?
Да, это необходимо, мы начинаем это делать. В части агентов – у нас swarm, мы смотрим логи и смотрим на мониторинг swarm.
Оно вообще падает когда-нибудь?
Падает, когда аналитики начинают свои эксперименты во время большой нагрузки – когда они пытаются собрать какую-то свою информацию в период закрытия месяца, когда все вместе начинают все делать одновременно. Скоро это у нас решится добавлением ресурсов, которые мы будем подключать по необходимости. Как раз после распиливания нашего сервиса на агентов и подписчиков мы сможем себе масштабировать подписчиков в зависимости от размера очереди. И тогда у нас в принципе из-за этого проблем не будет – просто будем поднимать или убирать необходимое количество агентов.
Рассматривались ли у вас готовые инструменты для ETL, например, SQL Server Integration Services?
Мы можем ходить только в 1С и не можем ходить в СУБД, в котором лежит 1С. Поэтому у нас такое решение.
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Интеграционные решения в 1С". Больше статей можно прочитать здесь.
Потратив несколько лет на исследования в области автоматизации процессов счетоводства, мы разработали уникальные технологии, методологию и ряд программных продуктов. Но, чтобы создать прикладные решения в реалиях повседневной практики, нам пришлось потратить последние два года на общение со специалистами учета и потребителями результатов учета непосредственно.
Для описания результатов всех исследований понадобится писать целую книгу, но для начала мы решили сосредоточиться на существующей в реальной практике задаче, которую сложно назвать беспроблемной.
Задача организации процессов формирования управленческих отчетов на основе довольно разрозненных данных в нестандартном формате и по нестандартным требованиям управленческой интерпретации присутствует на каждом предприятии. В зависимости от размера предприятия, уровня доходности, отрасли, производством данных процессов занимаются различные люди, с разным образованием и различными взглядами. В небольших компаниях микро бизнеса это зачастую делает сам руководитель, который одновременно может являться и собственником. В малом и среднем бизнесе, а это в количественном значении самый большой сегмент, зачастую эта задача накладывается на бухгалтерию. В среднем и крупном бизнесе появляется понятие экономиста и финансиста, появляется должность финансового директора, который стоит выше по иерархии главного бухгалтера, так же появляются целые ФЭД (финансово экономические департаменты).
Объединяет этих людей относительно подходов к решению задачи построения управленческих отчетов только одно: в большинстве своем, как инструмент, используются таблицы Excel.
С одной стороны, таблицах Excel изначально не заложены какие-либо методы и бизнес логика, одновременно с другой стороны функционально они способны обеспечить очень широкие требования. Хотя, при явном удобстве этого инструмента, присутствуют и значительные ограничения.
Если очень коротко.
Отсутствие заложенной учетной бизнес логики порождает очень плохие, с точки зрения базовой систематики, построения. Т.е. каждый выстраивает структуру хранения, обработки и отображения данных в соответствии с собственным уровнем понимания этих процессов.
Excel зачастую называют «плоским». Видимо такое ощущение возникает потому, что не используются реляционные базы данных, и клиент серверная архитектура, но мало, кто в реальной практике это понимает. Плоский и все тут.
Как явный недостаток — невозможна или крайне затруднительна одновременная совместная работа с данными.
1С + Excel.
В целом электронные таблицы решают определенную стадию общей задачи великолепно, поэтому системы начинают выстраиваться гибридным образом. Данные ведутся в базах (реляционные базы данных и клиент серверная архитектура). В России подавляющее большинство используют различные конфигурации 1С. В этих базах вручную формируют ряд агрегирующих отчетов, которые выгружают в Excel и дальше уже чудо специалисты в безграничных возможностях этого инструмента мастрачат собирают нужные отчеты по нестандартным управленческим требованиям.
Также на рынке можно найти прецеденты, когда компании производящие программный продукт для формирования управленческих отчетов позиционируют свои продукты прямым конкурентом Excel. Пример Финград. «А вы уже выросли из Excel?» Кстати, именно этот производитель очень четко формулирует недостатки использования таблиц Excel в процедурах управленческого учета. Еще бы! Ведь они себя так позиционируют. Одним из главных аргументов примечательно выступает фактор, что в Excel нет двойной записи. И вот тут начинается самое интересное. Большинство практиков не поймут этого фактора, а те, кто «вырос из Excel» полностью согласятся.
Основные формы управленческих отчетов.
Основная идея данного фактора исходит из того, что управленческие отчеты должны иметь форму стандартной триады: Баланс; Отчет о доходах и расходах (ОДР); Отчет о движении денежных средств (ОДДС). Технологически крайне сложно построить эти формы, если учет операций не ведется по принципу двойной записи, а делать это в Excel крайне затруднительно.
Очень многие финансисты до сих пор пренебрегают данными формами для построения информационных управленческих отчетов о фактических результатах и соответственно в бюджетировании. Могу процитировать слова финансового директора одного из крупнейших производственно-торговых холдингов в России: «Мне баланс не нужен, мне нужен план-факт». Интересно, что она имела ввиду? Ясно, что баланс ей не нужен, а под план-фактом она, скорее всего, подразумевала ДДС. А ведь этот человек определяет структуру системы управленческого учета в очень большой и серьезной коммерческой организации. Традиционное построение систем управленческого учета и бюджетирования на изначальной основе денежного базиса, согласно нашим исследованиям, наверное, самая большая проблема учета в сегменте малого и среднего бизнеса. И это понятно. Культура и технологии управленческого учета в коммерческих организациях у нас стали зарождаться гораздо позднее, чем стал появляться сам бизнес.
Некоторые аналитики утверждают, что наши экономические учебные заведения приспособились к требованиям рыночной экономики только к 2004 году, а стало быть, только выпускники после 2007 – 2008 годов стали более или менее соответствовать профессиональным требованиям. А все это время, с момента перестройки, нужно было как-то контролировать бизнес и анализировать его результаты. Деньги считать – это самое понятное и простое. Поэтому сначала научились считать деньги и делать отчеты ДДС, как план, так и факт, в Excel (в нашем отечестве он был всегда у всех под рукой, причем в самых последних версиях), а потом уже стали пытаться учитывать начисления и стремиться строить баланс.
Согласно нашим наблюдениям это некая эволюционная лестница развития управленческого учета в коммерческих предприятиях России. Кто не очень жадный и сумел заработать достаточно денег, те поступили проще, купили SAP ERP систему. А в процессе внедрения процедуры и функции учета были на уровне бизнес процессов приведены в должное состояние. Но такие системы не просто стоят несколько миллионов долларов, они еще и очень дороги в эксплуатации. Малый и средний бизнес естественным образом не может себе позволить таких решений по уровню своей доходности.
Основной и самый доступный источник данных для управленческого учета.
В данной статье я рассматриваю вариант построения управленческих отчетов, на основе данных существующих бухгалтерских баз. Под управленческими отчетами подразумевается естественно в первую очередь полноценная триада (Баланс, ОДР, ОДДС), но ей не ограничиваемся. Нужны и отчеты по натуральным значениям, и более детальные данные, и общий финансовый анализ, и графики. Под управленческими отчетами будем подразумевать основную триаду плюс любые другие отчеты на базе данных о хозяйственных операциях, которые могут понадобиться для информационного обеспечения принятия управленческих решений.
Почему мы предлагаем в первую очередь смотреть на вариант использования данных бухгалтерии в управленческом учете?
1. Там есть почти все данные, которые нужны.
2. Данные в бухгалтерии регистрируются согласно принципу двойной записи.
3. Бухгалтерия есть во всех предприятиях.
4. Согласно нашим исследованиям, это самый эффективный способ, и такой подход легко может себе позволить малый бизнес, причем, с использованием ресурсов существующих бухгалтерских служб, не создавая дополнительных специальностей.
Что нужно, чтобы из данных бухгалтерских баз получать управленческие отчеты?
1. Нужно, чтобы предприятие вело бухгалтерский учет должным образом. Это требование совпадает с требованием со стороны закона!
2. Нужен инструмент, который позволит:
a. Собрать данные из разных баз.
b. Интерпретировать собранные данные в условных правилах управленческого учета.
c. Корректировать, удалять, добавлять данные в целях правильного, с точки зрения управленческого учета, отображения информации в отчетах.
d. Производить процедуры консолидации (исключение внутригрупповых операций и установка соответствий справочной информации), когда бизнес включает в себя несколько юридических лиц или бизнес подразделений.
e. Анализировать управленческие отчеты путем детализации, сопоставления, графиков.
f. Делать все вышеперечисленные действия без участия специальных настройщиков или программистов.
Инструмент для превращения данных бухгалтерских баз в управленческие отчеты.
В процессе наших разработок и реализаций их на практике возникло множество инструментов, но самый первый был инструмент, который позволял импортировать проводки из бухгалтерских баз (исходное программное обеспечение не имеет значения), прописывать правила интерпретации данных бухгалтерии в управленческом учете, добавлять, корректировать, исключать данные, консолидировать их между несколькими взаимосвязанными юридическими лицами.
Это был самый простой инструмент. Позднее мы создали возможности интеграции с любыми формами документов, т.е. возможностью импортировать не только из бухгалтерии. Потом появились возможности построения цепочки, когда импорт данных идет из источника в документ с возможностью коррекции и последующим проведением в управленческом учете. Все это обрастало значительным количеством инструментария для комфортной работы на практике. Мы использовали системы в очень сложных больших проектах по постановке управленческого учета и бюджетирования в сложных многоотраслевых холдингах. В целом интеграционные процессы в холдингах с «зоопарком» разрозненных разно функциональных баз настолько сложны, что требуют большого участия внешних специалистов. И это всегда проектная работа. И это всегда очень дорого.
Но нам хотелось создать простой доступный даже для малого бизнеса и масштабируемый продукт, который легко будут использовать обычные практики различных учетных специальностей без особого участия каких-либо внешних специалистов.
Последние два года, исследуя рынок и общаясь с представителями всех звеньев потребительской цепочки, мы решили, что самым эффективным методом, с точки зрения фактора цены (всех затрачиваемых ресурсов) и качества, является вариант использования данных существующих бухгалтерских баз. Мы взяли изначальные наработки и смонтировали масштабируемый доступный вариант. Мы внесли в программу не только возможности формировать правила, но и настроили предварительные варианты под российскую бухгалтерскую систему, а также варианты уже готовых отчетов. Продукт назвали ACCCell (account + cell).
Основные принципы построения управленческих отчетов, на основе данных существующих бухгалтерских баз я опишу именно по функциям программы ACCCell. Это уже будет не просто бла бла в теории, а обоснованные практикой инструментальные методы.
Порядок работы системы по превращению данных бухгалтерских баз в управленческие отчеты с использованием ACCCell.
Первым шагом является импорт данных из бухгалтерских баз. В варианте использования 1С Бухгалтерия существует возможность прямого подключения и синхронизации, плюс возможность импорта через файл. В итоге мы получаем полную копию списка проводок со всем их содержимым, как исходный материал.
Произвести эту операцию может обычный оператор бухгалтерии.
Если за определенный период загрузки ведутся повторно, то мы увидим в списке, какие проводки новые, какие изменились, а какие удалены. Система потребует подтверждения этих изменений, а специалист будет в курсе, что изменяли задним числом в незакрытом периоде.
Загружать проводки возможно из нескольких баз и разных юридических лиц. Каждая проводка будет иметь идентификатор источника данных, а в теле проводки будет информация об организации. Бывает так, что бизнес использует несколько юридических лиц, при этом внутригрупповых операций нет, тогда вы без труда получите консолидированные отчеты, загрузив все проводки в одну базу. Если присутствуют внутригрупповые движения, то необходимо использовать функции консолидации.
В ACCCell есть настроенный вариант интерпретации и настроенный вариант главных отчетов, поэтому загруженные проводки можно сразу обработать и получить материал для анализа.
В полученном отчете все статьи детализируются в различных аналитических срезах. К примеру, мы можем развернуть дебиторскую задолженность прямо в отчете.
А потом развернуть дебиторскую задолженность по покупателям по контрагентам
В итоге, чтобы получить готовые основные отчеты из бухгалтерских баз требуется несколько минут.
Анализируя данные этих отчетов специалист без труда найдет неточности, которые могут быть, как внутри бухгалтерского учета, так и на уровне настроенных правил интерпретации.
На практике специалистов очень радовал факт, что они благодаря ACCCell находили в бухгалтерии множество ошибок.
Следующим этапом работы будет анализ и коррекция
Откорректировать данные мы можем различными путями.
Если автоматическое правило обработки дает системную неточность, то можно ввести самому более приоритетное правило (скриншот 5). Это без труда сделает подготовленный специалист.
Если надо изменить интерпретацию конкретной проводки, то без труда делается исключение, и мы сразу получаем результат.
В ACCCell можно без труда вводить ручные операции, которые будут дополнять или корректировать общую картину, а также можно загружать данные из других внешних источников, к примеру таблицы Excell или другие управленческие базы, или банковские выписки и др. Общая схема работы ACCCell выглядит так:
tma – это основной процессор счетоводства внутри системы, который использует инновационные и запатентованные технологии обработки данных. Благодаря этому движку вы не будете иметь проблем с курсовыми и стоимостными разницами, а процесс счетоводства полностью автоматизируется.
Ну и наконец, исправления можно делать в исходных бухгалтерских базах, потом снова загружать данные и обрабатывать, что занимает совсем немного времени.
Возможность интерпретировать данные бухгалтерских баз в условных правилах управленческого учета – это один из главных принципов и функционал инструмента построения управленческих отчетов на основе данных существующей бухгалтерии.
При этом нельзя пренебрегать другим основным принципом. Надо наладить ведение самого бухгалтерского учета должным образом так, чтобы данные в него заносились своевременно, в соответствии с требованиями управленческого учета, а не РСБУ. К примеру, бухгалтерия может закрываться поквартально, а значит множество данных заносится в конце квартала, хотя могли бы заносится повседневно. Управленческий учет может требовать помесячную отчетность и это накладывает требование полноты данных в бухгалтерии поверх требований РСБУ. Надо отметить, что производить операцию закрытия месяца не придется.
Управленческие отчеты не заканчиваются только тремя основными отчетами.
В заключение надо отметить еще один принцип. Инструмент, предназначенный для формирования управленческих отчетов на основе данных бухгалтерских баз, должен уметь давать различного рода аналитику, в т.ч. на основе натуральных значений и в графиках.
Дополнительные функции
На практике мы пришли к полному убеждению, что управленческий учет не может существовать в полной мере без функций консолидации группы компаний, бюджетирования и казначейства.
Эти функции в полной мере реализованы в программе ACCCell.
Заключение
В 1С:Управление холдингом для различных целей, например, при бюджетировании, подготовке международной и управленческой отчетности необходимо получать данные из внешних источников. В данной статье мы рассмотрим способ получения данных бухгалтерского учета в виде Оборотно-сальдовой ведомости из внешней информационной базы (далее ВИБ).
Шаг 1. Подключение внешней информационной базы.
Для подключения ВИБ 1С:Управление Холдингом необходимо в разделе Интеграция и управление НСИ выбрать «Внешние информационные базы».
Далее – задать имя ИБ и выбрать Тип внешней информационной базы из одноименного справочника. Справочник «Типы внешних информационных баз» предназначен для описания информационных баз с одинаковыми параметрами подключения (платформами, структурами данных).
После того как внешние информационные базы успешно подключены, необходимо открыть элемент Тип внешнего источника, выбрать только что созданную базу как эталонную и нажать на кнопку «Загрузить» структура данных. Структура данных внешней базы будет загружена.
Шаг 2. Создание Вида отчета Оборотно-сальдовая ведомость.
В разделе «Бюджетирование отчетность и анализ» нужно выбрать Виды и бланки отчетов.
Далее создаем новый вид отчета и заполняем реквизиты на всех закладках формы.
Закладка Основное. Важно обратить внимание, что Назначение должно быть «Остатки и обороты по счетам».
Закладка параметры отчета 1С. Ничего не заполняем, потому что в нашем случае нет дополнительных параметров отчета.
Закладка Используемые остатки и обороты. Выбираем план счетов. Открываем форму планы счетов ИБ и устанавливаем отбор по ранее созданному нами Типу.
Выбираем план счетов хозрасчетный.
Выбираем Ресурс регистра Сумма.
Устанавливаем галочку Суммирование подчиненных.
Устанавливаем все галочки в табличной части Используемые виды остатков и оборотов.
Далее нажимаем на кнопку Записать. При этом программа создает все необходимые бланки отчетов. Дальше нажимаем на «волшебную» кнопку Обновить показатели и ждем. Программа автоматически создаст строки, колонки и показатели Бланка отчета и заполнит показатели необходимыми формулами.
Переходим на закладку Настройки по умолчанию, открываем бланк экземпляра отчета и видим, что программа сама все сделала за нас.
Шаг 3. Заполнение отчета данными
Существует несколько способов заполнения отчета данными. Мы рассмотрим заполнение через документ Экземпляр отчета.
Для этого в том же разделе «Бюджетирование отчетность и анализ» нужно выбрать Экземпляры отчетов и создать новый экземпляр. Откроется форма для указания ключевых реквизитов документа. Заполняем реквизиты формы.
Для заполнения формы данными нажимаем на кнопку Панели инструментов.
Выбираем способ Прочие…
На закладке По правилу расчета нажимаем на кнопку «Заполнить отчет».
Программа подключится к внешней базе и заполнит наш экземпляр отчета остатками и оборотами по счетам.
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
Приветствую, коллеги! В этой статье поговорим о вложенных схемах в СКД. Вложенные схемы удобно использовать, когда из одной выборки нужно передать значения в другую выборку.
Другими словами, у нас есть одна выборка, внутри которой также происходит формирование выборки, передавая в нее из первой нужные значения параметров.
Отработаем следующий кейс: в демонстрационной базе ERP необходимо получить отчёт, который собирает сводную выручку по менеджерам, а затем выводится информация о начислении зарплаты менеджеру за этот период.
Рис. 1 Сводная выручка менеджеров
2. Формирование выборки по регистру
Для реализации поставленной задачи нам нужно получить выборку по оборотам регистра накопления «ВыручкаИСебестоимостьПродаж», а внутри нее произвести формирование выборки по регистру «ЗарплатаКВыплате» с отбором по периоду и сотруднику из «верхней» выборки.
Сначала сформируем простой отчет по выручке, сгруппированный по ответственным менеджерам. В документах продажи для поля «Менеджер» используется пользователь базы, чтобы менеджера можно было связать с зарплатным регистром. Дополнительно выведем физическое лицо, соответствующее данному пользователю.
Рис. 2 Простой отчет по выручке
В настройках СКД делаем группировку именно по физическому лицу, добавим заголовки в поля группировки, включим параметры в пользовательские настройки; макет оформления – «Античный».
Рис. 3 Настройки СКД
Сохраним, сформируем отчет по выручке, проверим результат.
Отчет выглядит так.
Рис. 4 Отчет по выручке после нужных настроек СКД
Половина пути пройдена, произошло формирование выборки по выручке за 2016 год в разрезе ответственных менеджеров. Данный период я намеренно выбрал, чтобы проще было связать выручку с существующими начислениями зарплаты. В демонстрационной базе начисления проведены только в 2016 году. Теперь осталось получить эти начисления во вложенной схеме и связать с выборкой по выручке.
Переходим на закладку «Вложенные схемы», создаем новую, проваливаемся внутрь поля «Схема».
Рис. 5 Закладка Вложенные схемы
Видим стандартный конструктор схемы компоновки данных, создаем новый простой запрос.
Рис. 6 Конструктор схемы компоновки данных
Настройки в системе компоновки данных можно сделать мастером, установим заголовок полей, если требуется, для красоты добавим макет «Античный», нажимаем «Ок».
Рис. 7 Настройки системы компоновки данных с помощью мастера
Теперь мы получили выборку по Зарплате, но выборка сейчас по всему регистру, за весь период ведения учета и по всем сотрудникам, осталось наложить отборы на вложенный запрос. Особенность в том, что отборы на вложенный запрос в 1С накладываются в верхнем запросе в поле «Настройки», проваливаемся туда.
Рис. 8 Отборы на вложенный запрос 1С
Затираем произвольную дату, прописываем тип «Поле компоновки», выбираем поля владельца (это как раз верхняя выборка), в параметрах находим «Начало периода». Действуйте внимательно, не перепутайте с параметрами самого вложенного запроса в 1С, они там рядышком и можно легко промахнуться.
Рис. 9 Поле компоновки в системе компоновки данных в 1С
Аналогично задаем «Конец периода» в системе компоновки данных в 1С, в итоге должно получиться вот так.
Рис. 10 Заданный Конец периода в системе компоновки данных
Добавляем отбор. Напоминаю, нам нужен отбор по сотруднику из результата верхнего запроса.
Добавляем отбор, в левой части выбираем физическое лицо, в правой части затираем тип, выбираем тип «Поле компоновки» для данных, там находим поля верхней схемы (владельца) – «МенеждерФизическоеЛицо».
Рис. 11 Поле компоновки данных
Готово, настройка должна выглядеть теперь вот так, нажимаем «ОК».
Рис. 12 Результат настройки СКД
3. Вложенный отчет
Переходим в настройку отчета, кликаем на группировку по менеджеру и добавляем вложенный отчет.
Рис. 13 Добавление вложенного отчета
Рис. 14 Результат добавления вложенного отчета
Если Вы делали какие-либо настройки во вложенной схеме, они сразу перенесутся сюда. Мы только сформировали детальные записи и добавили макет, поэтому просто сохраним отчет и посмотрим результат:
Рис. 15 Перенесенные настройки вложенных схем
Как видите, требуемую информацию отчет выводит, проверьте данные документов, параметры и отборы. Осталось привести отчет в более читаемый вид. Например, выровнять ширину полей, уменьшить шрифт, это можно сделать на закладке «Условное оформление». Также можно отключить отображение параметров и отборов, они засоряют отчет и пользователю не нужны, сделать это можно на закладке «Другие настройки».
Требуемая печатная форма сформирована.
Рис. 16 Печатная форма вложенного отчета
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
Читайте также: