Вы здесь

Главная » Автоматизированное управление основными бизнес-процессами малого предприятия (Пособие для молодого главбуха) » 14. Диагностика бухгалтерских систем

Сообщение об ошибке

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls в функции book_prev() (строка 775 в файле /home/o/oeugeny/spb4plus.ru/public_html/modules/book/book.module).

14.2.Диагностика специализированных учетных модулей.

   Все перечисленные уровни и приемы диагностики относятся к системе проводок. Однако диагностика учетной системы не сводится и не исчерпывается анализом проводок. Не менее важно постоянно проверять, и, если нужно, поддерживать, соответствие между проводками и специализированными модулями учета. Прежде всего, такими как складской учет, модуль учета зарплаты, модуль учета основных средств. При диагностике этих модулей также полезно бывает применить иерархическую процедуру.

   Проблема соответствия бухгалтерского (в узком смысле) и складского учета не нова. Возникает она при внедрении автоматизированных систем на крупных предприятиях практически всегда. Проведя внедрения более чем на полутора сотнях объектов, могу вспомнить только 2-3 случая, когда после ввода вступительного баланса и картотеки складских остатков, дебетовые сальдо на счетах складского учета и суммарная стоимость соответствующих складских остатков совпадали. Более того, приходилось встречать даже полученные в ручном учете отрицательные складские цены.

   В компьютерной системе, построенной по лоскутному принципу, когда складской учет ведется в одной программе, а обработка проводок в другой, соответствие сальдо картотеке также наблюдается достаточно редко. По этой причине, при переходе на программы нового поколения мы обычно рекомендуем издать специальный приказ «О внесении дополнений в учетную политику в связи с модернизацией компьютерного учета». А в этот приказ вставить, например, такую фразу: «Уточнить складские цены в пределах общих сумм, отраженных в последнем квартальном балансе». Означает это только одно – цены надо подогнать под вступительный баланс.  При этом обычно выбираются самые многочисленные в натуральных единицах позиции, с тем, чтобы такое произвольное изменение складских цен не бросалось в глаза.

   Положение может осложняться еще и тем, что при ведении материального учета вручную или в рамках лоскутной автоматизации у бухгалтеров зачастую нет четкого понимания того, какие принципы заложены в его основу. Например, неоднократно приходилось сталкиваться с ситуацией, когда складские цены на одну и ту же позицию на разных складах разные. Теоретически, применение методологии «пообъектного формирования учетных цен», вероятно, возможно. Имеется такая возможность и в системе БЭСТ-5. При настройке счетов складского учета в соответствующих специализированных модулях заполняется поле «Объект учета». Если в этом поле выбрано значение «Номенклатурный номер», складская цена отдельной номенклатуры ТМЦ будет едина на всем предприятии. Если выбрано значение «Номенклатурный номер+Склад», цена на разных складах будет разной. В этом случае надо думать, что делать с разницей цен при внутреннем перемещении, и как отражать ее в учете.

   С интересом познакомился бы с примером осмысленного применения такой методологии. Но, как из-за отсутствия личного опыта, так и вследствие недостаточных теоретических познаний в этой области, ничего не могу сказать о возможных технологических проблемах, которые ожидают на этом пути. Во всяком случае, большинство грамотных главных бухгалтеров против такой методологии возражает решительно. А то, что эта возможность недавно появилась в БЭСТ-5, отнюдь не означает, что ей обязательно надо пользоваться.

   В любом случае, проверка соответствия начального сальдо на счетах бухгалтерского учета и итогов по картотеке складского учета на начала периода, должна быть частью диагностики учетной системы. Посмотрим, как эта проблема решена в системе БЭСТ-5.

   Здесь есть специальная группа отчетов – «Остатки по картотеке». Это различные виды отчетов, в которых фигурируют остатки на начало периода. Они отличается от остатков на первую дату периода тем, что дают остатки на утро первой даты, тогда как второй отчет дает остатки на вечер. Использование этих отчетов возможно на двух иерархических уровнях, когда стоимость остатков дается в свернутом виде по складам или группам, и когда в отчете фигурируют остатки по каждой номенклатурной позиции. Это, соответственно «Ведомость остатков по картотеке (по группам, свернутая)» и «Ведомость остатков по картотеке».

   Если несоответствие возникло, например, в связи с не очень корректным проведением процедуры переоценки начальных остатков, использование двух уровней может оказаться весьма полезным. К сожалению, в БЭСТ-5 нет штатной возможности посмотреть суммы переоценки по каждому складскому подразделению, как и получить данные об остатках до переоценки без использования резервных копий. Это, в ряде случаев, усложняет процедуру диагностики.

   Кроме анализа соответствия между начальным сальдо и начальными складскими остатками необходимо контролировать соответствие между дебетовым оборотом по счетам складского учета, и приходом на склады, а также между кредитовым оборотом и расходом. При этом, если в дебетовом обороте проблем обычно не бывает, при корректно настроенных алгоритмах формирования проводок, то в кредитовом обороте они возникают нередко, особенно при использовании метода учета по фактическим ценам (прошу не путать с «ценой фактического приобретения» из налогового кодекса. Этот мутант вряд ли имеет отношение к серьезному материальному учету). Проблемы в кредитовом обороте связаны, обычно, с процедурой перерасчета цен расхода со склада и соответствующих проводок (расчет себестоимости). Здесь проблемы могут возникнуть, если заданы разные периоды расчета для разных складов или групп, если по какой-либо номенклатуре на какую-то дату внутри промежутка расчета остаются «красные остатки», если где-то вносились ручные исправления, и т.д.

   В системах БЭСТ для этих целей существует очень неплохой отчетный документ, который формируется практически всегда, когда обнаружено несоответствие между оборотами и приходом или расходом. Это ведомость прихода или расхода, сформированная «по документам», с указанием в запросе на ее формирование того счета складского учета, по которому обнаружено расхождение (рис. 100).

Рис. 100

   Эта ведомость имеет колонки «стоимость учетная складская» и «сумма бухгалтерских проводок по счету (складского учета)». Если суммы в этих колонках не совпадают, путем просмотра отчета можно определить, какие именно документы породили несовпадение. Если совпадают, сразу можно сказать, что несоответствие вызвано проводкой, сделанной вручную или вне модуля складского учета. Именно по этой причине мы очень не рекомендуем так настраивать типовые операции, чтобы проводки на счета складского учета делались где бы то ни было, кроме специализированного модуля.

   Во всей этой процедуре есть только одна проблема. Если за месяц было оформлено несколько тысяч документов, отчет получается очень большим. Тем более, что строки этого отчета соответствуют не только документам, но и конкретным номенклатурным позициям в документе. Чтобы избежать непродуктивного анализа больших документов, реально приходится делать отчеты за все более короткие временные промежутки. На этом примере особенно отчетливо видно, что система отчетной документации и система иерархической диагностики тесно связаны друг с другом. В комплексе БЭСТ-5 явно не хватает отчета для промежуточного уровня анализа. Например, это может быть та же ведомость, но с принципом формирования строк «по датам» или «по документам».

   Рассмотрим теперь диагностику модуля учета заработной платы. В основном, эта диагностика также ориентирована, на соответствие между проводками по счету расчетов с персоналом и по счетам расчетов с внебюджетными фондами, с одной стороны, и лицевыми счетами сотрудников – с другой. И так же, как и в модуле складского учета, для проведения эффективной диагностики необходимы несколько иерархических уровней отчетных документов. Дополнительная сложность здесь состоит в том, что чаще всего в эффективных системах учета заработной платы достаточно много счетов затрат. Например, если на счете 20 открыты аналитические счета по видам выпускаемой продукции, этих счетов может быть сотни или тысячи. Может использоваться и многоуровневая аналитика.

   В этих условиях получить традиционный документ для диагностики, которым является расчетная ведомость по счетам затрат, оказывается практически нереально. Не только по причине наличия в документе очень большого числа строк, но и вследствие непомерно большого числа столбцов. Это характерно не только для крупных производственных, но и для госбюджетных предприятий.

   Кроме того, диагностика модуля «Зарплата» не исчерпывается контролем начислений и удержаний. Необходим еще контроль правильности начисления взносов во внебюджетные фонды. Таким образом, центральная проблема всех модулей автоматизации учета зарплаты – это система сводных документов, которая позволила бы быстро расшифровать не только каждую проводку, но и каждую сумму в оборотной ведомости по счету 70 или 69, и, в случае необходимости, довести эту расшифровку до уровня отдельного лицевого счета. К сожалению, единого взгляда на то, какой должна быть эта система, нет. Принципы построения сводных документов по зарплате в разных автоматизированных системах весьма различны. Более того, в некоторых случаях возникает вопрос, а использовались ли какие бы то ни было бухгалтерские принципы вообще?

   По-видимому, вопрос о построении оптимальной системы сводных документов для диагностики системы учета зарплаты должен стать предметом самостоятельного исследования. Тем более, что сам принцип начисления большинства взносов в фонды коренным образом отличается от принципа начисления других налогов. Эти взносы привязаны непосредственно к лицевому счету каждого сотрудника. Что, конечно, вполне соответствует смыслу этих взносов как вычетов из зарплаты сотрудника. И фиговый листок отсутствия в дебетовой части проводок по их начислению счета 70 вряд ли может ввести в заблуждение серьезного специалиста, который путем простых арифметических действий всегда может убедиться в том, что налоги на доходы физических лиц в России составляют не менее 34%, а никак не 13%. А поскольку начисление зарплаты производится из сумм, оставшихся после начисления НДС, реально этот налог еще больше.

   Иными словами, реально налоги, удержанные из зарплаты, в настоящее время имеют два кредитовых счета, 68 и 69. Соответственно, дебетовые счета – 70 и счет затрат начислений, «породивших» соответствующие взносы в фонды. Что, естественно, далеко не упрощает диагностику системы. Если завтра российский чиновник придумает такой способ начисления взносов, когда взнос с суммы зарплат будет не равен сумме взносов с каждой части, возникнут те же проблемы, что и с разделением подоходного налога на бюджетную и внебюджетную части, с которой в течение десяти лет мучаются бухгалтеры госбюджетных предприятий.

   Это обстоятельство привело к стихийно возникшей потребности иметь документ типа расчетной ведомости, в которой по каждому лицевому счету давалась бы не только расшифровка по видам начислений и удержаний, но и по взносам во внебюджетные фонды. Достаточно неуклюжая попытка как-то  удовлетворить этой потребности была сделана в некоторых системах с товарным знаком «1С». Естественно, что такой документ с расшифровкой по счетам затрат даже для достаточно простой системы оплаты труда будет практически бесперспективным для анализа.

   Чтобы сконструировать оптимальную систему сводных документов по зарплате, вероятно, сначала имеет смысл определить, по каким параметрам расшифровки информация может быть свернута, с целью разделения анализа на несколько иерархических уровней. Это могут быть подразделения предприятия, виды начислений и удержаний (включая взносы в фонды), синтетические счета затрат, аналитические, в том числе многоуровневые, счета затрат, лицевые счета отдельных сотрудников. При этом, в соответствии с принципами иерархической диагностики, один документ должен содержать один, максимум – два вида расшифровки.

   Пока ни среди разработчиков программных систем, ни среди бухгалтеров, нет устоявшегося взгляда на то, какой должна быть система сводных документов по зарплате. Более или менее отлажена только система контроля проводок по счету 70 и лицевых счетов. Чаще всего, для диагностики бухгалтерской информации по начислениям и удержаниям на среднем предприятии хватает двух иерархических уровней. На обоих обычно используются документы, структура столбцов в которых совпадает  со структурой столбцов в расчетной ведомости по счетам затрат. Строки в документе первого уровня могут соответствовать подразделениям, во втором – отдельным лицевым счетам.  С их помощью достаточно легко диагностируется один из наиболее распространенных типов ошибок, когда своды по зарплате не совпадают с проводками, или некоторые проводки по зарплате вызывают вопросы.

   Рассмотрим этот случай более подробно. Пусть итоговая сумма начисленной зарплаты не совпадает с сумой проводок в кредит счета 70. Прежде всего, это обстоятельство может оказаться непросто проверить, поскольку проводок может быть очень много, и отличаться они будут дебетовыми счетами. В системе БЭСТ-5 проводки генерируются при формировании расчетной ведомости. В параметрах формирования расчетной ведомости можно задать два способа формирования – «По предприятию» или «По подразделениям». Выберем «По предприятию», а в поле «Формировать проводки» поставим «Да».

   В этом случае сформируется одна расчетная ведомость, которая будет включать всех сотрудников предприятия. Расчет ведомости и формирование проводок делаются нажатием клавиши F10. Полную сумму начисленной зарплаты можно получить как итог в колонке «Всего начислено». Эту же сумму можно получить в п. «Формирование отчетов» - «Своды за период», в нескольких сводных отчетах.

   Особо хотелось бы отметить отчет «Свод за период (по счетам затрат)». Он содержит только начисления с двумя видами расшифровки – по счетам затрат и по видам начислений. Используя итоги по счетам затрат, можно проверять суммы проводок в кредит счета 70. В отчет можно включать или не включать начисления, которые не входят в «Итого» лицевого счета, например, материальную выгоду. В отчет можно включать все начисления, а можно – только те, которые входят в определенную колонку. Последнее обстоятельство можно использовать и для контроля взносов в фонды, особенно когда ни у кого из сотрудников зарплата не превышает с начала года сумму, предусмотренную в регрессивной шкале взносов.

   Проводки, сформированные на основании расчетной ведомости, можно посмотреть непосредственно из реестра расчетных ведомостей (Alt-F10), или из буфера проводок. В любом случае, проводки в кредит счета 70 лучше отфильтровать по клавише F6. После того, как проводки будут отфильтрованы, можно посмотреть их общую сумму с помощью клавиш Shift-F6. Список этих проводок имеет смысл распечатать и дописать в отчет полученную итоговую сумму.

   Эта итоговая сумма и сравнивается с итогом по начислениям. Если они не совпадают, сравниваются суммы проводок с различными дебетовыми счетами, и итоги по счетам в отчете «Свод за период (по счетам затрат)».

   Конечной целью диагностики ошибки является нахождение лицевого счета, ее породившего. Обычно, анализ лицевого счета позволяет сразу определить причину ошибки и принять меры к ее устранению. Если определен счет затрат, для которого сумма проводки и сумма начисленной зарплаты отличаются, это часто позволяет определить подразделение, в котором локализовано указанное различие.

   Конечно, для надежной локализации весьма пригодился бы отчет того же типа, что и «Список по виду н/у», в который включались только те сотрудники, которые имеют составляющие зарплаты, отнесенные на этот счет затрат. Очень не хватает и документа, аналогичного по своей структуре расчетной ведомости по счетам затрат, строки которого соответствовали бы подразделениям.

   Пока же для локализации лицевого счета можно просто просмотреть столбец расчетной ведомости по счетам, соответствующий данному дебетовому счету.

   Если таким образом локализацию лицевого счете произвести не удается, можно сформировать расчетные ведомости по подразделениям. По подразделениям тогда будут сформированы и проводки. Так что можно сравнивать суммы зарплат и проводок уже по каждому подразделению. В этом случае в иерархическую диагностику добавляется еще один уровень, соответствующий подразделению.

   Наиболее распространенной ошибкой при начислении зарплаты является отсутствие у того или иного начисления в лицевом счете счета затрат. Эта ошибка диагностируется в БЭСТ-5 автоматически. В этом случае в буфер проводок попадают проводки в кредит счета 70 и счета 69 с пустым дебетовым счетом. При попытке передать их в книгу хозяйственных операций выдается сообщение об ошибке и эти проводки выделяются красным цветом.

   Начисление, не имеющее счета затрат, попадает в расчетной ведомости по счетам в колонку «Прочие». Просматривая эту колонку, сразу можно определить, в каких лицевых имеются такого рода ошибки. Чаще всего они связаны, например, с каким-то специальным видом премии, для которого предполагается  в каждом отдельном случае указывать источник финансирования. Или просто при приеме на работу сотруднику в карточку забыли поставить счет затрат.

   Блокировать программным путем возможность такого рода ошибок было бы нерационально. Счет затрат в карточке не ставится в том случае, когда все начисления сотрудника имеют индивидуальные источники финансирования. А премия может быть отнесена на те счета, которые фигурируют в карточке. Это лишний раз подтверждает тот факт, что попытка исключить из автоматизированной системы такую составляющую, как голова бухгалтера, редко делает систему лучше.

   Естественно, что для успешной диагностики модуля учета зарплаты, принципы формирования проводок, расчетной ведомости, и сводов по счетам затрат должны быть одинаковыми. В системе БЭСТ-5 проводки могут формироваться одним из трех способов. Во-первых счет затрат может явно задаваться в типовой операции. Во-вторых, может использоваться тот счет затрат, который указан в соответствующем начислении лицевого счета. И, в третьих, счет затрат может браться из карточки персонального учета.

   При этом, в колонку расчетной ведомости, соответствующей тому или иному счету затрат попадают суммы начислений, у которых этот счет затрат стоит в лицевом счете, независимо от того, в проводку с какой корреспонденцией дает вклад эта сумма реально. И это тоже может стать причиной расхождения суммы начисленной зарплаты и суммы соответствующей ей проводки.

   Непростой задачей является диагностика ошибок, связанных с расхождением проводок по начислению взносов во внебюджетные фонды с итоговыми суммами этих взносов, полученных по лицевым счетам, или с появлением иных вопросов по этим проводкам. В системе БЭСТ-5 для этих целей полезно использовать группу отчетов, формируемых в п. «Формирование отчетов» - «Списки и справки» - «Групповые справки». В большинстве этих отчетов строки соответствуют отдельным лицевым счетам, а в столбцах присутствует общая сумма начисленной зарплаты, налогооблагаемая база для начислений в фонды, и сумма начислений. Таким образом, итоговую сумму в этих отчетах можно сравнить с итоговой суммой проводок в кредит субсчетов счета 69.

   Если обнаружено расхождение, чаще всего легко найти лицевой счет, его породивший, просматривая соответствующую колонку этого отчета. Обычно для включения сотрудников в отчет можно использовать фильтр, в частности, по подразделениям.

   Крайне полезным для диагностики является отчет «Налоги и страховые взносы в фонды». Столбцами этого документа являются зарплата и взносы в каждый внебюджетный фонд, рассчитанные по данным лицевых счетов. Строки соответствуют счетам дебета компонент зарплаты, породивших эти взносы, опять-таки из лицевых счетов. Если счет дебета не указан, в отчете будет присутствовать строка с незаполненным номером счета. Особо следует отметить, что расшифровка в этом отчете ведется по отдельным аналитическим счетам счетов затрат. По этой причине каждая цифра из отчета может прямо сравниваться с распечаткой проводок по счету 69 из буфера проводок. Определенные трудности, правда, возникают при локализации лицевого счета в случае, когда такое расхождение обнаружено.

   Следует отметить, что система сводных документов, которые можно применять при диагностике модуля «Зарплата», непрерывно развивается. Многие документы, вероятно, еще придется конструировать. Лучше – после предварительного обсуждения с опытными бухгалтерами или внедренцами систем автоматизации.

   Правила учета основных средств в последние годы претерпели особенно большие изменения, и в далеко не лучшую сторону. Пока не готов высказывать какие-либо соображения относительно диагностики соответствующих модулей. Достаточно очевидной представляется только следующая мысль. Пора подвергнуть систему сводных документов, используемых в этом модуле, коренному переосмыслению, прежде всего, с точки зрения методологии поиска наиболее типичных для учета основных средств ошибок. Думаю, что такое переосмысление могло бы стать предметом серьезного теоретического исследования.

   В заключение следует отметить, что иерархическая диагностика не является изобретением автора. В той или иной мере она применялась в бухгалтерском учете всегда. В значительной мере именно из потребностей диагностики сформировалась традиционная система сводных бухгалтерских документов. Однако, только с появлением автоматизированных систем бухгалтерского учета, появилась определенная свобода оперирования с этими документами. Конечно, диагностика бухгалтерской системы – процесс, в котором нельзя иметь готовые рецепты, и изложенные выше методы представляют собой не более чем попытку поделиться собственным опытом поиска ошибок в учетных системах.

   Чтобы успешно применять методику иерархической диагностики, необходима еще одна «малость». Проводки должны делаться по каждому первичному документу, а не по толстой пачке таких документов. При всей очевидности этого требования, и с точки зрения нормативных актов, и, особенно, с точки зрения правил «хорошей практики бухгалтерского учета», оно реализуется далеко не всегда, даже в условиях применения автоматизированных систем учета.

   В гл. 6 упоминалось предприятие, где проводки делались не на основании первичных документов, а с помощью «16-й ведомости». Что могло получиться, если бы тогда я сдался и сделал такой документ, который просил заказчик?

   На предприятии была бы закреплена совершенно порочная практика ведения бухгалтерского учета, когда проводки делаются не на основании каждого первичного документа, а сразу по толстой пачке таких документов. Ни о какой иерархической диагностике их бухгалтерской системы тогда не могло бы идти и речи.

   А раз надежной системы быстрого поиска ошибок нет, нет и настоящей достоверности бухгалтерского учета, а значит, и необходимых данных, например, для финансовой санации предприятия.

   Так что, когда специалист по автоматизации управления проектирует формы отчетов по принципу «чего изволите», это может иметь далеко идущие финансовые последствия. И ответственность за них мы должны бы чувствовать. Примерно как врач, который хотя и берет деньги за лечение, но совсем не обязательно выпишет наркотический препарат, о котором больной его просит.

   Диагностика бухгалтерских систем очень тесно связана со структурой аналитических счетов. В настоящее время в развитии  российского бухгалтерского учета отчетливо прослеживается тенденция к бездумному увеличению иерархических уровней аналитики, особенно в госбюджетном учете. На взгляд автора, это ничем не лучше увеличения числа передач в трансмиссии автомобиля. Есть некое оптимальное число. Оно может немного изменяться зависимости от особенностей конструкции. Но за его излишнее увеличение приходится платить, увеличением веса автомобиля, энергопотерями, а главное – резким ростом трудозатрат на управление. В некоторых случаях это увеличение трудозатрат делает невозможным решение сложных задач в принципе. Как в автомобильных перевозках, так и в бухгалтерском учете. В госбюджетном учете  такой задачей стало определение эффективности финансового управления организацией. В настоящее время не делается даже попыток ее решения.

   Увеличение иерархических уровней в бухгалтерском учете привело к необходимости заново переосмыслить систему сводных бухгалтерских документов, имея в виду, прежде всего, их функциональное назначение, цели, которым они служат. Попытка такого переосмысления с точки зрения диагностики бухгалтерских систем сделана в этой главе. Естественно, при этом возникает больше вопросов, чем дается ответов. Надеюсь, что такого рода вопросы могут дать некий импульс дальнейшим исследованиям, в том числе, в области теории бухгалтерского учета.