Принципы внедрения и сопровождения учета на базе 1С

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

Введение

Внедрением 1С я занимаюсь с 2004 года. Преимущественно, приходилось заниматься бухгалтерским учетом, или около бухгалтерскими задачами в управленческом учете, а также непосредственноуправленческим учетом в самых различных формах. 

В ходе деятельности приходилось сталкиваться с самыми разными проектами — от простейших отчетов до сложных проектов с распределенной базой и двойным (управленческим и бухгалтерским) учетом, савтоматической генерацией хозяйственных операций, полной разработкой и внедрением схемы налогового учета по ПБУ18/02 в абсолютно нетиповой бухгалтерской конфигурации, и др.

В ряде случаев, приходя к клиенту с уже поставленным, но неправильно работающим учетом, достаточно было вдумчиво посмотреть на то, что происходит в учете, и нанести несколько точно выверенных «ударов гаечным ключом», после чего у клиента все начинало работать правильно..

Было несколько неудачных внедрений, которые стыдно вспоминать, и тем не менее — они дали свой, незабываемо ценный опыт.

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

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

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

В качестве критериев успешности внедрения (внедрения, а не проекта в целом) я подразумеваю:

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

Я не рассматриваю здесь, как критерий, прямую коммерческую выгоду от проекта и своевременность оплаты, полагая, что эти вопросы успешно решаются на стадии планирования отношений, заключения договора или подписания документов.

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

1. Принцип окупаемости

Мне кажется, это главный принцип, по которому можно оценить успешность внедрения или сопровождения: Автоматизация должна себя окупать каким-либо образом.

А именно:

а) Постоянно приносить прямую или косвенную выручку.

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

б) Экономить издержки, причем,на большую сумму, чем было затрачено на внедрение.

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

в) Позволять существовать бизнес-процессу, который окупает автоматизацию.

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

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

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

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

2. Принцип доверия

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

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

В результате, пользователи делают двойную работу, у них не хватает времени на перепроверку результатов, они допускают арифметические ошибки, а потом героически их ищут. Как следствие, срывают сроки, жалуются на жизнь, программу и свою злую судьбу. В системе, по итогу, отражаются недостоверные данные, либо данные с нарушениями, не позволяющими использовать их в вышестоящих участках (например, неправильное ведение в "Бухгалтерии предприятия" НДС с авансов полностью дискредитирует идею автоматизированного учета НДС и составления книг покупок и продаж, а НДС с авансов, в свою очередь, зависит от корректности отражения взаиморасчетов с покупателями и поставщиками).

Бывает также, что пользователи начинают вручную, на калькуляторе, проверять данные вполне очевидных отчетов и агрегаций (что, впрочем, более подробно изложено в принципе под №4).

Указанное состояние можно охарактеризовать как недоверие автоматизированному учету.

Такое поведение пользователей, и как следствие, недоверие учету, могут вызывать следующие причины:

• пользователь недостаточно обучен, не владеет системой в части своих участков учета – экплуатационно, и/или методически;
• пользователь консервативен, не доверяет "этим новым технологиям, черт бы их побрал", предпочитает свои "проверенные и надежные" методы, сознательно саботируя автоматизацию;
• пользователю неудобно пользоваться системой -- какие-либо операции объективно необходимо считать на бумаге, т.к. возможности системы не соответствуют реальному процессу расчета (в основном касается нетиповых участков, или особенностей учета на предприятии);
• система откровенно некорректно работает (что случается не только в заказном, но и в типовом поведении)

Основными следствиями недоверия учету являются:

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

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

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

3. Принцип наличия схемы бизнеса

Если у клиента нет схемы бизнеса — никакая автоматизация его не спасет.

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

Здесь, для правильной иллюстрации данного принципе, мне придется углубиться в длинный и распространенный пример из практики (помимо технической информации будет бухгалтерия и налоги)

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

1. ООО, применяющее общую систему налогообложения (ОСНО), и торгующее оптом с НДС;
2. ООО или ИП на УСН 15%, продающий товары бюджетникам, и иным клиентам, не требующим входящий НДС;
3. Индивидуальный предприниматель (ИП), применяющий единый налог на вмененный доход (ЕНВД) и торгующий в розницу.

Товары в холдинге одни и те же, управленческий учет товаров (обычно, на базе конфигурации «Торговля и склад» или «Управление торговлей») осуществляется по общему складу, взаиморасчетов и денежных потоков – разделяется по хозяйствующим субъектам.

В общем-то все эти случаи делились на случаи, когда у холдинга имелась четкая схема работы, и когда ее не было.

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

В случае наличия схемы, товар, обычно, предсказуемо покупался на распределяющую организацию, с правильно и легально оформленной маркетинговой политикой дилерской сети (для избежания нарушений статей 20 и 40 НК РФ). Эта организация продавала товар на остальные хозяйствующие субъекты бизнеса по мере необходимости. Эти субъекты продавали товар конечным покупателям (менеджеры выбирали субъект продажи исходя из потребностей клиента и формы оплаты). Весь свободный остаток концентрировался на распределяющей организации, распределение товара, — вопрос чистой арифметики — выполнялось один раз в месяц, автоматически, специально написанными обработками. В бухгалтерию выгружались оформленные документы внешнего и внутреннего товарооборота, отрицательные остатки отсутствовали как класс (кроме небольших случаев оперативного пересорта). С управленческой точки зрения, товары двигались в одну сторону, деньги — навстречу, у организации была возможность абсолютно легального оптимизирующего маневра по НДС и налогу на прибыль, предсказуемое финансовое планирование.

Совершенно другая ситуация наблюдается там, где нет схемы. Товары покупаются хаотично, на любой хозяйствующий субъект, исходя из текущего наличия у субъекта денежных средств. Продаются менеджерами с любого же субъекта (как можно отказать постоянному покупателю купить товар оптом, когда он есть на розничной витрине?). При общем складе невозможно определить покупался ли товар на того субъекта, с которого ведется продажа. Соответственно, при выгрузке документов товародвижения в бухгалтерию, у субъектов, находящихся на ОСНО и УСН 15% (им это критично, в отличие от ИП на ЕНВД) возникала ситуация, когда продавался не тот товар, что был куплен, а тот, что был куплен — не продавался.

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

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

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

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

Кроме того, проблемы распределения товара, в этой ситуации, нередко поглощают 90% времени и нервов бухгалтера. У него не остается времени на правильное ведение учета, срываются сроки сдачи отчетности, и нередко все это мотивируется, якобы, плохой программой.

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

Таким образом, в ходе анализа проекта следует обратить внимание на проработанность схемы бизнеса, проверить, как она соотносится с возможной автоматизацией, и в случае, если имеются несоответствия, по примеру вышеизложенных, необходимо:

а) отказаться от данного проекта вообще;

б) указать на необходимость проработки клиентом отдельных элементов схемы ДО начала автоматизации, и дождаться завершения этой проработки, либо за оплачиваемое время, оказать содействие в проработке этих элементов (либо намекнуть на то, как эти элементы правильно организовать);

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

Желательно, при этом, обеспечить предоплату :-)

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

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

4. Расширенный принцип IBM для автоматизированного учета

Девизом IBM является фраза «Компьютер должен работать, человек — думать». Впрочем, я встречал такую фразу в законах «Мерфи» и других источниках. Не знаю, честно, откуда она произошла. Но всякий раз, на моей памяти, когда этот постулат нарушался, у клиента в ИТ начинался какой-то страшный бардак.

Расширим ее для автоматизированного учета следующим образом:

«Человек должен предоставить данные, затребовать отчеты и провести анализ. Компьютер должен все сосчитать».

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

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

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

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

5. Принцип замыкания

Учетная схема должна быть, по возможности, замкнута на максимальном количестве (реализованных в программе и целесообразных для постановки автоматизации) участков.

Указанный принцип можно рассмотреть как на техническом, так и на эксплуатационном уровне.

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

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

Так, например, в конфигурации «Торговля и склад 9.2» ведется налоговый учет по НДС предъявленному и начисленному: документы поступления и реализации приходуют остатки в регистры «КнигаПокупок», «КнигаПродаж», а документы «Формирование записей книги...» - расходуют. В большинстве случаев учета в рассматриваемой конфигурации, налоговый учет по НДС никого не интересует — он ведется в бухгалтерской системе. В то же время, остатки вышеупомянутых регистров постоянно накапливаются, и переносятся при закрытии очередного периода, создавая дополнительные записи в информационной базе.

Кроме того, при использовании типового механизма свертки информационной базы, остатки этих регистров отражаются на дату свертки отдельными документами «Запись книги покупок», «Запись книги продаж» по КАЖДОМУ исходному документу покупки или продажи, с сохранением ссылки на этот документ! В результате, при свертке, мы получаем все исходные документы покупок и продаж помеченными на удаление (и не удаляемыми), по каждому из них отдельный документ «Запись книги...», и те же незакрытые остатки книг покупок и продаж на начало свернутого учета. Кроме того, сама свертка (если ее не доработать, предписав игнорировать эти регистры) может выполняться несколько суток.

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

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

Аналогичная проблема встречается в системе «Управление торговлей 8» (в редакции 10 точно, 11-ю пока к сожалению не довелось полностью рассмотреть и внедрить) — налоговый учет ведется сам по себе, о его «погашении» никто не думает, остатки растут, пользователи «сталкиваются транзакциями» при проведении документов. Отключение формирования движений по налоговому учету НДС (закомментировать 10 строк в общем модуле) позволяет на четверть уменьшить размер информационной базы и ускорить проведение документов.

В бухгалтерском учете можно отметить ситуации, когда на счете существует беспорядок — красно-черная «гребенка» остатков, беспорядочно разбежавшихся между аналитическими объектами, относящимися к одной учетной единице.

Причем (для бухгалтерии 8) на счетах, имеющих субконто составного типа, иногда образуются «встречные» остатки по «пустому» значению субконто (пустая ссылка какого-либо типа) и «очень пустому» (неопределенному значению). То же самое с измерением «Подразделение» - встречается ситуация, когда часть движений прописана на пустую ссылку, а часть — на NULL (исправляется в режиме «Тестирование и исправление ИБ» в конфигуратора). В результате чего, типовые документы непредсказуемо видят или не видят остатки, просматривающиеся по отчетам, доводя пользователя до истерики (по оборотно-сальдовой ведомости товар есть, а реализация его упорно не видит).

На эксплуатационном уровне принцип замкнутости учета выражается немного по-другому. Сформулируем его так: Все используемые участки учета должны получать, по возможности, наиболее полные данные, и между ними должны быть разработаны и установлены контрольные точки для взаимной проверки.

Следование этому принципу позволяет сформировать учет, устойчивый к ошибкам и фальсификациям, полный и актуальный.

Рассмотрим пример формирования контрольных точек:

1. Необходимо правильно отражать движения по кассе и банку, (контрольные точки - соответствие учетных остатков банка выпискам, получаемым из банка, соответствие учетных остатков кассы ранее распечатанной и подписанной кассовой книге).

2. Это, в свою очередь, позволить минимизировать ошибки ввода первички по авансовым отчетам (контрольные точки — задолженность подотчетников) и товарным движениям (контрольные точки — взаиморасчеты с поставщиками и покупателями).

3. Ежемесячный аудит складских остатков и взаиморасчетов с клиентами также позволит минимизировать ошибки первички (контрольные точки — оборотки по сч. 08, 10, 41, 62, анализ субконто 62, отчет по выявлению отрицательных остатков на 10, 41 и т. п.), сверить материальные и прочие затраты, постановку на учет ОС и др.

4. Правильно введенные и учтенные взаиморасчеты позволят автоматически составить налоговую отчетность по НДС, в частности — по НДС с авансов (рассмотрено в иллюстрации к «принципу IBM»), встречно проверить товарные движения и остатки (контрольные точки — универсальные отчеты по регистрам НДС, сверка авансов и НДС с авансов, сверка данных регистров и бух. учета).

5. Своевременно запрошенные через телекоммуникационные каналы связи сверки по налогам, вкупе с п. 1. позволят поддерживать актуальное состояние расчетов по основным и прочим налогам, и контролировать своевременное их начисление (и отнесение на затраты) (контрольные точки — ОСВ по счетам учета расчетов по налогам и сборам, взносам).

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

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

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

В незамкнутом учете никакие взаимные проверки невозможны, а свериться с первичными документами можно только прямым перебором.

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

6. Принцип сохранения типовой функциональности

При внедрении систем, для которых важно находиться на поддержке у поставщика (Бухгалтерия предприятия, ЗуП, УПП) необходимо максимально придерживаться типовой функциональности. Иногда можно использовать ее нестандартно. Если для какого либо участка целесообразно разработать нетиповую, то крайне желательно приписать ее «сбоку». Для подобных случаев удачно подходит термин "неразрушающее конфигурирование", любезно и метко подсказанный пользователем с ником "Арчибальд".

Неправильно приписанная функциональность, или модификация типовой, значительно затрудняют обновление продукта, и заставляют клиента задаваться вопросами «а почему мы столько платим за обновление?» и «почему после обновления опять не работают участки А, Б, В, Г, Д...?». А также, разразиться гневным «Не присылайте к нам больше этого мальчика/девочку для обновления — он/она ничего не знает и нам опять развалит учет».

Для таких конфигураций, как "Управление торговлей" этот принцип менее актуален, т.к. в большинстве случаев, эта конфигурация вынужденно и глубоко модернизируется под оперативные нужды в угоду принципу окупаемости, а обновления ей не требуются. Хотя, с выходом нового постановления по учету НДС в 2012 году появились крайне нужные и важные документы "Корректировка поступления", "Корректировка реализации", достаточно глубоко увязанные в общие модули, и задача обновления глубоко переработанных решений на базе УТ, стала на короткое время крайне актуальной, острой, и авральной.

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

Максимальное использование типовой функциональности позволяет:

• легко накладывать обновления, даже силами специалиста небольшой квалификации;
• переложить знание схемы учета на пользователя — т.е. решить вопросы сложных участков не программно, а эксплуатационно, а эксплуатационные знания дать под запись заказчику, а не замыкать программное «ноу-хау» на специалиста (впрочем, иногда нужно и это :-) ), вынуждая его постоянно держать в памяти особенности учета клиента;
• использовать сравнительно надежный, для широкого спектра ситуаций (валютный учет, различные единицы измерения, особенности учетной политики), многократно протестированный интерфейс и код от разработчиков 1С, а не писать собственную поделку для сугубо частного случая учета.

В ряде случаев можно «выкрутиться», нестандартно применив типовую функциональность, или применив ее не по назначению.

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

Также нужно отметить, что иногда (к сожалению, нередко) типовая функциональность работает неправильно (ошибка в релизе (или в ДНК методолога)). В этом случае следует понять идеологию, заложенную в типовую функциональность поставщиком, вмешаться в конфигурацию и восстановить ее работоспособность (например, откатом отдельных объектов метаданных на предыдущий релиз, или собственными правками, предельно минимальными и аннотированными). Пользователям же базовых версий рекомендуется предлагать (под запись) более-менее подходящий способ обхода неисправности участка ручными корректировками проводок и регистров.<>

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

7. Принцип методической корректности

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

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

Ошибки такого рода, происходят, в основном из двух источников: от клиента и от недостатка знаний специалиста. Рассмотрим первое следствие:

Недопустимо позволить клиенту продавить неверную методику автоматизации учета.

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

Если слепой поведет слепого, оба свалятся в яму (английская пословица)

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

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

Однажды руководством предприятия было принято решение о переводе учета на «1С: Бухгалтерия предприятия 8» (редакция 2.0). Обойдем вниманием причины перехода — они были вполне обоснованы.

Организация пригласила для внедрения фирму-франчайзи, от которой был делегирован специалист (программист по профилю). Со стороны заказчика в проекте участвовала бухгалтерия в количестве нескольких человек.

Перенос остатков был осуществлен более-менее корректно. А потом начались чудеса. Так, как ни программист, ни главный бухгалтер, не обладали методической подготовкой по постановке учета в целевой конфигурации, бухгалтер начал требовать от программиста точного повторения функциональности версии 7.7, и привычных доработок.

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

Для начала была неправильно настроена учетная политика, в частности — включен упрощенный учет НДС. «Этот ваш налоговый учет по НДС такой сложный, давайте просто документы будут попадать в книги покупок/продаж — у нас так было в семерке». То, что НДС с авансов пришлось формировать вручную — никого не смутило, так, как «в семерке тоже так было».

Затем было разработано несколько новых видов документов (связанных, преимущественно, с розницей), и исправлены типовые (реализация, поступление и пр.). Был существено поправлен план счетов, так, например, добавлены счета розничного учета товаров 41.13, 41.14, 41.15, по сути, различающиеся лишь классификацией складов с точки зрения управленческого учета (т.е. бухгалтерски учет на них был одинаковый). Напрочь переделан механизм расчета торговой наценки на счете 42 (конечно - типовой механизм не ожидал новых невнятных субсчетов, и работать отказался).

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

А через год случилось так, что ряд складов-магазинов предприятия, осуществляющих розничные продажи, перешли на ЕНВД, и потребовалось организовать раздельный учет ОСНО/ЕНВД по всем правилам. В это время, главный бухгалтер, вспомнив «семерку», продавил тому же программисту создание счетов 44.01, 44.02, 44.03 (Для чего? Для затрат ОСНО, ЕНВД и распределяемых, плевать что в статье затрат есть соответствующий реквизит, и написан соответствующий штатный механизм закрытия). «Ну как же — нам так удобно — сделал оборотку, и видишь затраты для ОСНО, ЕНВД и распределяемые — на разных счетах. У нас же так было в СЕМЕРКЕ....».

Соответственно, пришлось начисто переписать типовой механизм закрытия счета 44, так, как он был в шоке от такого вольного распоряжения типовым планом счетов.

Кроме того, ВНЕЗАПНО выяснилось, что распределение НДС косвенных расходов автоматически работать не будет ввиду предусмотрительно включенного, годом раньше, режима «Упрощеный учет НДС». А кроме того, не будет работать включение НДС в стоимость товаров / в состав расходов, для товаров, подлежащих продаже по деятельности, облагаемой ЕНВД — опять таки, ввиду того, что для этого требуются сложившиеся остатки партионного учета по НДС, который в режиме «упрощенный учет НДС» не ведется.

Соответственно, весь наиболее сложный НДС, кроме покупок и продаж (а именно, НДС с авансов полученных, НДС по косвенным расходам, НДС включаемый в стоимость/затраты), теперь ведется вручную.

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

В 60/62 счетах на субсчетах расчетов и авансов — красно-черная «гребенка», (встречные дебетовые и кредитовые сальдо в третьем субконто, сходящиеся в договорах и контрагентах) соответственно, баланс автоматически формируется с искажениями в строках дебиторской и кредиторской задолженности. На 19-м счете тоже «гребенка», где дебетовое сальдо находится в разрезе документов, а кредитовое — по пустому субконто, что, вкупе с упрощенным учетом НДС, позволяет сверять книгу покупок с бухгалтерским учетом только «прокрыжив» не одну сотню входящих документов.

По итогу — ни один регламентированный отчет не формируется кнопкой «заполнить» так, чтобы не исправлять его полностью. Книги покупок и продаж составляются только после длительной ручной доработки документами «Отражение НДС к вычету», «Отражение начисления НДС» (для распределения НДС косвенных расходов и включения в стоимость / затраты). Налоговый учет по налогу на прибыль — не ведется, и налог на прибыль не рассчитывается. Механизмы автоматизации раздельного учета ОСНО / ЕНВД — не работают. Каждое обновление (которые делаются редко и по большим праздникам) выливается для специалиста в 10 часовую головную боль, а для предприятия — в издержки, и по сути — абсолютно бесполезно.

Из всех типовых механизмов, по сути дела, работает только журнал проводок и бухгалтерские аналитические отчеты. Работники бухгалтерии 90% времени занимаются тем, что вносят вручную и перепроверяют то, что автоматически можно было бы рассчитать одной кнопкой, и постоянно жалуются на то, как раньше в «СЕМЕРКЕ» было хорошо, а теперь как все плохо и как им трудно жить.

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

В то же время, все, вроде как, работает. Программист — делал ровно то, что просил бухгалтер. А проект — объективно завален, так как нарушен принцип окупаемости, и затрат ресурсов бухгалтерии на ведение учета после внедрения стало, вероятно, больше, чем до.

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

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

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

А всего лишь — невнимательно ознакомился с типовыми возможностями.

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

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

Надеюсь, эта информация поможет при внедрении и сопровождении учета, и спасибо за внимание, если вы дочитали до этого места :-)