0. stvorl 942 19.01.12 15:45 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
94. ombun 01.02.12 15:53 Сейчас в теме
Спасибо, отличная статья.
95. vavtrading 01.02.12 17:24 Сейчас в теме
отлично, спасибо за публикацию
96. faleks 01.02.12 22:11 Сейчас в теме
Спасибо за сформулированные принципы внедрения, которые формируются огромной практикой. Статья супер!!!
97. Addi 02.02.12 00:50 Сейчас в теме
Интересно.
Можно подробнее по п. 3., конкретный вопрос: на какой системе налогообложения в описывемом случае работала так называемая распределяющая организация?
В случае наличия схемы, товар, обычно, предсказуемо покупался на распределяющую организацию, с правильно и легально оформленной маркетинговой политикой дилерской сети. Эта организация продавала товар на остальные хозяйствующие субъекты бизнеса по мере необходимости.
98. Oleh 02.02.12 00:57 Сейчас в теме
и некоторым Директорам нужно объяснять что 1с8 отличается от 1с7 как запорожец от мерседеса
99. Гинея 02.02.12 15:00 Сейчас в теме
Отличная статья. И урок, и пособие одновременно!
100. CeHbKA 254 02.02.12 16:26 Сейчас в теме
Увидел на главной, "на дуру" кликнул... Результат - одним залпом от первой до последней буквы. Очень понравилось. Прям как у Насипова Ф. ))
101. alexey_1c 02.02.12 19:09 Сейчас в теме
Статья супер.
Есть идеи или примеры, как оценить точно экономический эффект от внедрения ?
102. GreenLab 75 02.02.12 22:00 Сейчас в теме
Как показывает практика, одним из самых важных результатов автоматизации в торговых организациях является уменьшение издержек в следствии сокращения краж, как результат упорядочивания товарооборота. Причем полностью искоренить эту проблему не способны ни служба безопасности, ни автоматизация как таковая, но грамотно внедренная WMS система, помогает в данном вопросе
116. l_men 10 07.02.12 12:41 Сейчас в теме
(102) GreenLab, А причем здесь WMS система?? она только управляет складом как отдельной единицей, а ведь есть еще заказы, скидки, наценки и т.д., да и не у всех торговых организациях есть склад, что бы там внедрять WMS, выброшенные деньги, см. первый принцип.

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

Выводы можете сделать сами.
175. vladimir_makarov 106 11.08.12 01:35 Сейчас в теме
(102) это не является повышением автоматизации, это является прямым увеличением коэффицента наценки. Я абсолютно НЕ согласен с тем, что на это может каким-либо образом повлиять "развитие автоматизации": лично я НИКОГДА не буду класть пустую/большую сумку в камеру хранения: естественно, я с ней пойду по залу. Ест-но, это дело порядочности: если я зашёл за мелочью, которую в сумку не кладу, я культурно подойду к кассе и скажу: я только вот что взял... При малейшем недоверии открою свою ПУСТУЮ сумку и сделаю так, что ИМ стыдно будет, а не мне. К большому сожалению, меня ни разу не обвиняли, а жаль. Уточню: если собираюсь взять хотя бы несколько наименований, то сумку, всё-таки, оставлю, возьму корзинку: почему? да что-бы народ не тормозить, который перед кассой окажется после меня. Но, повторюсь: каждый имеет право заходить в торгвый зал с ЧЕМ ХОЧЕТ!!! Это дело охраны за порядком смотреть!
Но... я вот к чему: НИКАКАЯ электрика не поможет!!! Когда речь идёт о продуктовых супермаркетах или супермаркетах с аналогичным СРЕДНИМ уровнем цен: датчики ляпать невыгодно: это поднимет цены так, что даже местному персоналу станет воровать невыгодно, и все прочие последствия...
А посему: в любом супермаркете ЗАЛОЖЕН В ЦЕНУ процент краж. Если нет, объяви отдельную тему на форуме (а лучше новую, специальную). Вот там и сойдутся все, имеющие хоть какое-то отношение к теме...
103. GreenLab 75 02.02.12 22:03 Сейчас в теме
К сожалению именно кражи, зачастую составляют отдельную статью издержек, как это ни абсурдно
104. GreenLab 75 02.02.12 22:18 Сейчас в теме
>6. Принцип сохранения типового функционала.
>При внедрении необходимо максимально придерживаться типового функционала

Вот этот пункт, является спорным применительно к продуктам 1С.
К сожалению методология учета в типовых решениях "устаканивается" в течении 2-3 лет после выхода релиза.
Достаточно вспомнить Торговля и Склад ред. 9 , УТ 10.2 - 10.3
После многочисленных и неоднократных замечаний партнеров, 1C доводит до ума типовые.
105. GreenLab 75 02.02.12 22:20 Сейчас в теме
В качестве одного из последних примеров: возврат договоров с контрагентами в добавок к соглашениям.
106. Dethmond 03.02.12 23:54 Сейчас в теме
107. margo2007 10 04.02.12 03:05 Сейчас в теме
Все правильно написано.
Жаль, что по жизни эти принципы постоянно нарушаются.
108. leha.mos 05.02.12 23:46 Сейчас в теме
Читать всем франчайзи, прежде чем отправлять студентов на внедрение! Очень полезная статья, много для себя почерпнул, жду продолжения!
109. silkinv 06.02.12 12:28 Сейчас в теме
спасибо статья отличная и печальная)))
110. mihas1001 06.02.12 20:32 Сейчас в теме
Очень полезная статья, достаточно подробно раскрывает вопросы внедрения 1С!
117. 1C_tradeomsk 92 07.02.12 20:01 Сейчас в теме
Капитан очевидность! Да, с фразами типа "мир во всем мире - это хорошо" хе фиг поспоришь. Конкретики мало. Приблизительно так пишут желтые книжки и особенно буклеты - ни о чём.
118. SHTIN 07.02.12 20:28 Сейчас в теме
Публикация хорошая,спасибо.жизненная)
119. Uscolegy 08.02.12 13:13 Сейчас в теме
не плохая статья. надо будет кой какие куски ее показать некоторым заказчикам. дабы они наконец начали понимать чего они все таки хотят добиться от внедрений
120. kazna2011 08.02.12 17:36 Сейчас в теме
Конкретная - Переход с БП 1.5 на БП 2.0 и ведение учета именно в БП 2.0 после некоторого параллельного учета.
Измеримая - Ну переход он или состоится или нет, большего не дано.
Достижимая - Большинство приготовлений сделано, осталось перенести остатки и начинать загонять документы путем импорта их из разработанной в недрах организации, программы управления производством, складом, документооборотом... Ничего сверх естественного. Лишь бы не мешали.
Реалистичная - Переход на новые рельсы не так сложен, так как по сути всего лишь обновляем версию конфигурации, хоть и с кучей допилов в виде внешних обработок. Стратегию минимального вмешательства в конфигурацию пока выдерживаем, так как печальный опыт виден воочию. Пока ничего серьезнее вывода дополнительной колонки Кода в форме выбора подразделений не менял.
Определенная по времени - До моего прихода решение о переходе было принято годом ранее, но явно никто не готов был это осуществить. Готов получать шишки, да и плевать. Опыт! Временные рамки очень обозримы. Конец января, начало февраля, перенос остатков и первички, потом труды по закрытию периода одновременно с закрытием ныне действующей базы. Параллельный учет несколько месяцев пока страхи не пропадут, а потом Шифт + Делет старой базы.
121. Brawler 449 08.02.12 18:35 Сейчас в теме
(120) kazna2011, и в чем смысл кидать было мой же текст?
123. AlexKoso 17 09.02.12 13:20 Сейчас в теме
статья достойная похвал. Как говорится: Пиши еще :)
124. commo 10.02.12 13:39 Сейчас в теме
Хорошая статья. спасибо
125. Steelvan 10.02.12 13:44 Сейчас в теме
Прочитал. Спасибо. Не помешали бы иллюстрации :)
126. Steelvan 10.02.12 13:46 Сейчас в теме
А как заказчики относятся к тому, что зовут написать программу, а им в ответ - "Вам надо сначала сделать схему БП" ?
127. Steelvan 10.02.12 13:47 Сейчас в теме
Или писать несмотря на принцип "Нет схемы БП - нет программы" ?
128. Steelvan 10.02.12 13:49 Сейчас в теме
Вот пришел я допустим к заказчику, а у него схемы нет. И я начинаю предлагать, а давайте сначала построим БП. В итоге до процессов мы можем дойти очень не скоро.
129. Rudy 10.02.12 16:08 Сейчас в теме
Статья полезная.
Многие расчитывают на работу с "одной клавишей" и пребывают в этом убеждении длительное время, забывая, о том, что положишь, то и получишь.
130. vitn 12.02.12 22:48 Сейчас в теме
В автоматизации 90% успеха зависит от грамотности руководителя, но 90% руководителей хотят чтобы работа была сделана еще вчера и желательно бесплатно...
136. ppotap 14.02.12 20:17 Сейчас в теме
Спасибо за статью. Понравилась. Обобщено хорошо. Чувствуеться опыт.
137. unsimple 27 16.02.12 09:36 Сейчас в теме
Спасибо автору за полезный материал!
138. vitn 17.02.12 15:53 Сейчас в теме
"Владимир Путин поручил министерствам внести к 15 февраля в правительство предложения очередной налоговой реформы. Вчера глава Минфина Антон Силуанов объявил о начале «творческой» работы над реформой. Министр сообщил, что власти могут снизить прямые налоги и взамен поднять косвенные — то есть, например, снизить налог на прибыль, но увеличить акцизы или налог на добавленную стоимость (НДС)."



Поэтому с Россией никто и не хотит иметь дело, не знаешь что завтра президент придумает
139. novosys 17.02.12 18:45 Сейчас в теме
Статья хорошая, понравился стиль изложения.
Но ложку дёгтя в виде замечаний или скорее предложений автору всё же добавлю.
Во-первых, приведённые примеры несколько узконаправленны в силу опыта работы автора в основном с бухгалтерией и торговлей (особенно касается примера в 5 принципе "на технологическом уровне"). Исходя из этого правильнее было назвать статью "Принципы внедрения и сопровождения бухгалтерскогоучета на базе 1С". Однако это могло бы несколько сузить круг читателей, которым она могла бы оказаться действительно полезной. Приведённые принципы, на мой взгляд, применимы и к управленческому учёту вцелом, и к участку производственного учёта и т.д. Но приведённые примеры с одной стороны уводят читателя именно в бухгалтерские дебри, а с другой не дают, пробежав взглядом статью, использовать её как конспект по принципам автоматизации учёта.
Моё предложение - выделить примеры курсивом или серым цветом. Кстати, некоторые из них при определённой доработке заслуживают отдельной публикации, что позволило бы просто сослаться на них. При этом статью легче было бы воспринимать в общем, а тем, кто сомневается в обоснованности принципов - пожалуйста, примеры! ;)
По первому принципу (отвечая, в частности, [101]): к сожалению или счастью он трудноизмерим, если вообще измерим. Если говорить в общем, а не конкретно о бухгалтерском учёте, то зачастую автоматизация не уменьшает объём работы специалистам и практически всегда стоит дорого. Зато правильная автоматизация даёт более полную информацию управленцу. Другое дело - как он ей воспользуется. Автоматизация может дать возможность оптимизировать принятие правильных решений, но не даёт конкретных советов. Это тот самый "принцип IBM", но немного переформулированный: машина даёт информацию, решение принимает человек. К тому же сложно оценить прямые выгоды от внедрения - нет критериев. Но то, что этот пункт должен учитывать внедренец в разговоре с потенциальным заказчиком, продавая проект - это 100%! Тут играет ролькрасноречивость и убедительность продающего ;)
В дополнение к сказанному в предыдущем абзаце и по принципу 3: иногда внедрение даёт возможность систематизировать имеющиеся бизнес-процессы и поставить паровоз предприятия на правильные рельсы - и это правильно. Одно НО - внедренцы могут показывать, как это реализовано в типовом функционале, как лучше и советовать посмотреть в эту сторону, но решение об изменении бизнес-процессов и вся ответственность за это должна оставаться в рамках предприятия!
140. var03 21.02.12 13:08 Сейчас в теме
Спасибо автору за данную статью. Так или иначе ко всему описанному в ней внедренцы приходят. Судя по положительным отзывам эта статья многим помогла не наступить на грабли при внедрении. Обязательно дам статью перечитать некоторым своим коллегам ;) А сам еще раз вдумчиво перечитаю и возможно что то добавлю. Респект автору.
141. ditiatko 38 23.02.12 00:40 Сейчас в теме
Автору 5. Статья действительно хороша
142. zhleonid8 23.02.12 01:42 Сейчас в теме
год работал на доработанной и 1 мес на типовой, если нет реальной, неизбежной причыны не менять код - неделайте этого, за год около 200 звонков програмисту и разговоров таких нехороших, за месяц прошлый, только один, спасибо сказал и что скучно мне не будет:)

ловите мысль пригодится перед раздумием сесть ли на бочку с порохом
143. zhleonid8 23.02.12 01:46 Сейчас в теме
и ещё, для бухов, Обязательно ведите весь учет в программе, не разбивая на полуручной, ввели остатки и в путь, а то такое встречаю ежедневно, потом практически нереально нормально работать, проще опять с нуля
145. ign 4 11.03.12 13:56 Сейчас в теме
Хорошая статья, спасибо, наши бухгалтера тоже продавливают на изменения в УПП, трудозатраты при обновлении растут как ком накатывается. Грустно стало очень...
146. kng67 19.03.12 20:27 Сейчас в теме
Спасибо автору за хорошую статью!
Критерии успешности внедрения описаны очень точно.
Косвенная выгода у нас в связи с сокращением времени оформления документов.
Принцип доверия... У многих бухгалтеров в запасе пословица:"Доверяй, но проверяй!". Недавно объясняла одной, как у нас работает отдел реализации, а она с удивлением:"А что, журналы никакие вручную не ведутся?" Пришлось пояснить, что периодически на складах делается инвентаризация, в результате которой и проверяется учет.
Принцип наличия схемы, как я понимаю, это постановка задачи. Когда у нас в прошлом году решили дописать к 1С учет оказываемых по ЖКХ услуг жителям относящегося к предприятию жилпоселка, главбух хотела за полчаса все решить, а врезультате обсуждения пришлось рисовать схему и по ходу решения задачи совместно находить с разработчиком подходы по автоматизации.
Расширенный принцип IBM для автоматизированного учета. Бывший руководитель, набравший в штат бухгалтерии молодых девиц, все пытался упростить их работу до расположенной на экране "одной большой кнопки", чтоб не ошиблись. Все возражения в плане того, что они и учет должны знать первоначально, отклонялись. В результате, после его ухода сразу вылетело с работы одно "слабое звено".
Принцип замыкания. К сожалению первый год вели себестоимость вручную, ч/з операции. Потом пришлось много корректировок вносить, прежде чем заработал правильно стандартный механизм. Кстати, в Комплексной автоматизации за 2 года нашей работы 1С-никами было в этом направлении много дописано.
Принцип сохранения типового функционала. Очень важно для обновления!!! Изменений внесли немного, но даже в плане дописанных пунктов меню: периодически при обновлении почему-то они слетают. Имею для этого копию, откуда переношу дописанный функционал.
Принцип методической корректности. Не записала сразу при внедрении выше описанного примера по услугам ЖКХ некоторые тонкости порядка формирования документа. Наступила на эти грабли спустя 3 месяца. Хорошо на Инфостарте спец обработку выложил по корректировке регистров без проведения. Пришлось воспользоваться.
147. api.vl 6 23.03.12 08:49 Сейчас в теме
Очень содержательно. Освещены основные проблемы и их причины. Надо держать сей список всегда перед глазами.
151. electronik 05.04.12 09:21 Сейчас в теме
Статья просто супер как говорится нет слов одни емоции автору респект и уважение ну и конечно 5++++
152. alekseies 04.05.12 10:32 Сейчас в теме
Много умных слов, в жизни все проще!
153. pap 15.05.12 11:05 Сейчас в теме
Отличная статья. Спасибо.
Бухгалтерия хочет переходить с 7.7 на 8.2
распечатаю и дам почитать.
не хотелось бы городить в 8ке не типовые решения 7ки.
154. Alex_E 2053 16.05.12 14:09 Сейчас в теме
Всё совершенно точно. Ситуации, повторяющиеся из раза в раз, и почему то результаты таких внедрений никого ничему не учат. Пример из жизни - разговор с потенциальным клиентом:
- У нас очень много задач по программированию, был программист, но он уволился, а сделать необходимо очень много.
- Какие задачи решал программист и есть ли ТЗ на разработку, вообще хотелось бы посмотреть на схему бизнес-процессов на предприятии, как вообще формируются задачи для программиста?
- О, тут у нас всё просто - приходит пользователь и говорит, мне надо сделать вот это и вот это. Программист пишет.
- А этот пользователь по каким критериям формулирует свою задачу?
- Ему так надо.
- И какие результаты по таким задачам получаются?
- Нууу, чаще всего результат совсем не похож на первоначальную постановку задачи, но мы ведь динамически развивающаяся компания, у нас постоянно всё меняется. Да и вообще мы так давно работаем.

От клиента пришлось отказаться. От типовых конфигураций остались "одни уши", про регламент никто даже слышать не хочет - там всё неправильно, мы в Ecxel всё сведем. Каждая задача решается локально для удобства одного пользователя, причём её решение приводит завтра к визиту к программисту второго, у кот. в результате модернизации" что-то полетело...... и так до бесконечности.
Предложение перед началом доработок прописать хотя бы схему документооборота на предприятии поддержки не встретило - Зачем нам это?
spawn_a; tango; teflon; +3 Ответить
155. Artemuch2 16.05.12 17:46 Сейчас в теме
Спасибо очень содержательная статья. и понятно что кажды пункт, в качественном внедрении должен быть соблюден. но мы то с вами знаем, что черти как всегда в деталях
1.Принцип окупаемости - к сожаленю выгода от эксплуатации систем почти всегда косвенная. и зачастую автматзатры незаконно присваивают себе ну например сезонные повышение объемов продаж. ну или то что пользователи наконецтобучились работать на компьютере.
2.Принцип доверия – вот я точно знаю если системе не доверяют значит это кому нибудь нужно. часто ктото хочет скрыть свои косяки или элементарную лень. ноесли информацией в системе (что в бухгалтерской программе врядли) будет пользовться директор или лучше всего собственник, то качество регистрации информации существенно повышается.
3.Приринцип наличия схемы – есть такая схема как отсутсви схемы. называют ее гибкостью бизнеса или творческим подходом сотрудников к учету иуправлению. такое часто бывает ипрходится буквльно воспитывать заказчика.
4.Расширенный принцип IBM для автоматизированного учета - это да и тут вопрос больше нек пограмме или компьютеру а к специалисту сопровождению которы часто крутит всеми пользователями как хочет
5.Принцип замыкания - а вообще можно автоматзировать только целостные процессы. именно поэтому многие специализируются на бухучете это уже готовая система полностью замкнутая в хозяйственном цикле
6.Принцип сохранения типового функционала – принцип развития и совместимости.
7.Принцип методической корректности – принцип стандартизации и унификации
156. Varies 17.05.12 08:40 Сейчас в теме
Жизненая статья :) +

На моей практике пока небыло таких сложных внедрений с нуля, а другие я не считаю сложными. Сопровождением бухни занимаюсь уже 5й год. С каждым годом стараюсь выпилить нестандартные документы и механизмы заложенные ещё в 8.0 К сожалению от некоторого не отказывается бухгалтерия, как не объясняй что это не нужно. :(
159. electronik 17.05.12 15:29 Сейчас в теме
Все очень интересно и познавательно.Все принципы действительно важны, особенно заинтересовали - третий (наличие схемы бизнеса у пользователей), пятый (принцип замыкания) и седьмой (методическая корректность).
164. AlexanderKai 18.05.12 12:29 Сейчас в теме
Клиент: Нам надо это и вот это.
Программист: Вполне можно сделать, только обновление потом придется делать каждый раз с программистом.
Клиент: Спасибо, не надо.

Вот так обычно развивается диалог, когда не хочешь внедрять всякие капризы клиентов :)
165. iov 364 18.05.12 12:40 Сейчас в теме
(164) А если не предупредить
1) При обновлении самостоятельно по кнопке - сотрется все нафиг...
2) Говоришь цену обновления измененной - и тебя спрашивают почему не предупредил раньше.
3) Придет мальчик из франча и обновит...
4) Ты это сделал специально чтоб содрать бабла...
166. Sairys 18.05.12 15:29 Сейчас в теме
В целом интересная статья, много чего правильного описано с точки зрения автоматизации. Автор молодец
167. vladir 111 24.05.12 17:53 Сейчас в теме
Хорошая статья. И в комментариях много поучительного. Спасибо.
168. kmar 28.05.12 05:54 Сейчас в теме
Отличная статья, информативно, интересно, познавающе. По больше таких статьей бы.
169. lizard 20.06.12 17:22 Сейчас в теме
Соглашусь со многими комментариями, точное отражение ситуации по автоматизации и подходит к разным ситуациям, "решение бардака и проблем путем нажатия волшебной кнопки".
170. zigomodo 29.06.12 20:12 Сейчас в теме
Спасибо за то что поделились опытом с новичками.
171. Spektr 617 29.06.12 20:24 Сейчас в теме
Спасибо за статью. Понравилась. Познавательно. Добротно. Чувствуется системный подход.
172. Stamper 37 16.07.12 14:09 Сейчас в теме
(0), хочу заметить, что иногда задача удобной поддержки внесенных обновлений (подписки на события, переопределение событий, динамическая прорисовка формы) сводит на нет читаемость и не позволяет пользоваться прозрачными механизмами платформы. и в определённый момент задача перерождается в поддержку системы поддержки :)
конечно же, нужно найти оптимальный способ не отстрелить себе ногу

мы вот сейчас развиваем функциональность УТП без снятия замка. всё что нам нужно -- добавляем в свойства и категории и используем внешние обработки для интерфейсов. костыли, конечно... за то обновляться должно "из коробки".
173. aochkasov 02.08.12 12:53 Сейчас в теме
Хорошая статья! Прочитал до конца. Спасибо автору
174. gradus 07.08.12 22:30 Сейчас в теме
Благодарю за познавательную статейку. Есть о чем поразмыслить.
176. isn 13 24.08.12 12:04 Сейчас в теме
Согласен на все 100%. Жаль что методичек по внедрению к каждому продукту 1С нет. По крайней мере в свободном доступе нет точно. Для этого приходится "выучивать" типовые конфигурации, прокручивать в голове какая может подходить к учету предприятия. Ну и приходится "бороться со стереотипами" бухгалтеров и управленцев.
177. medv 20.09.12 10:34 Сейчас в теме
Отличная статья! Почему раньше не натолкнулись?! Натолкнули на мысль - по поводу технического аудита периодически!
179. eigen20 23.10.12 16:56 Сейчас в теме
Отличная статья, автору +!!!!
183. internetname 08.02.13 14:29 Сейчас в теме
А где принцип "Клиент всегда прав"?
184. Brawler 449 08.02.13 14:31 Сейчас в теме
(183) internetname, а как же "Клиент не ведает чего хочет и чем это ему обернется"?
185. dimonsky 22.04.13 14:58 Сейчас в теме
Спасибо за статью! Очень интересная вещь.
186. tango 484 22.04.13 16:10 Сейчас в теме
перечитал статью, на фоне потока - просто
отлично.
**
зы: пара фраз не по-русски, но это пустяк
"ведение учета будет склонно саботироваться"
"поведение и недоверие могут вызывать причины"
187. iov 364 22.04.13 16:18 Сейчас в теме
(186) Долгими весенними, рабочими, днями люблю посидеть у камина в альпийских горах и перечитывать старые статьи... Ценителя видно сразу. :)
188. tango 484 22.04.13 16:22 Сейчас в теме
(187) iov, а что делать? свои публикации - там где и должны быть, можно слегка расслабиться
Прикрепленные файлы:
189. iov 364 22.04.13 16:45 Сейчас в теме
(188)да потрудился на славу... Спасибо почитал..
190. iov 364 22.04.13 16:46 Сейчас в теме
(188) А что случилось то? Отпуск чтоль?
191. tango 484 22.04.13 16:48 Сейчас в теме
(190) iov, у меня распределенная нагрузка. работают 1с и пользователи
192. iov 364 22.04.13 17:00 Сейчас в теме
(191) Ага вот я тоже думаю написать про эту тему. Программист 1С в нагруженной среде 1с и время еффективной работы. А то смотрю я на этих людей и думаю днем пишут код - вечером и ночью применяют и отлаживают и вечно огребают что их нет на рабочем месте (то есть то что они ложатся в 5-6 утра и из поднимают в 12 часов это нормально)...
193. tango 484 22.04.13 17:19 Сейчас в теме
(192) iov, это ты о чем, брат?
меня тут после звонка как-то тормознула одна из
гб: "ах что-то там надо"
улыбаюсь по-шире: "переработку никто не оплачивает"
она аж покраснела: "тогда завтра утром..?"
ну, я тормознулся, конечно, что-то там понажимал... как личное одолжение
194. iov 364 22.04.13 19:56 Сейчас в теме
(193) Ты познал дзен брат - личное время на то и личное чтобы тратить его на себя и семью. Но вот вокруг такая дискриминация просто ужас.
195. denn15 29.04.13 10:14 Сейчас в теме
Спасибо, ждем новых интересных статей.
196. sumixam 24.05.13 14:52 Сейчас в теме
В большенстве своём интересная статья, много чего правильного описано с точки зрения автоматизации. Автор молодец. Ждём продолжения
197. krreezz 04.07.13 16:46 Сейчас в теме
Соображения о методологии внедрения и сопровождения учета на базе систем 1С в виде коротких принципов, пояснений и иллюстраций к ним в виде примеров и выводов. Относится, преимущественно, к бухгалтерскому учету, однако применимо к любой отрасли, и, мне кажется, не обязательно к 1С. Целью написания статьи было изложить практически доступную информацию, а не завалить теорией, несмотря на получившийся объем. Статья предназначена для специалистов по внедрению, содержит, помимо технической информации, бухгалтерию и налоги.


Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А именно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случае наличия схемы, товар, обычно, предсказуемо покупался на распределяющую организацию, с правильно и легально оформленной маркетинговой политикой дилерской сети (для избежания нарушений статей 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» написал собственный механизм расчета розничных цен от закупочных по запоминаемой наценке, совершенно проигнорировав наличие аналогичного типового. Потратил при этом кучу времени, получив не очень надежный механизм, и даже не до конца отключил штатный, что начало вызывать проблемы при ценообразовании.

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

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

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

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

:-):-)
198. Chernik 06.07.13 14:15 Сейчас в теме
(0) Толковая статья. Чувствуется большой опыт и системность похода. Автору спасибо и пожелание писать еще.
200. KossTON 19.09.13 14:46 Сейчас в теме
Спасибо за статью! Был в похожей ситуации, только дело усугублялось тем, что дело было в бюджете. Жаль, что не прочитал этот материал раньше, хотя самостоятельно пришел к похожим выводам))) Умение посмотреть на ситуацию "сверху" и глобальное мышление в подобных случаях одно из условий успеха проекта.
202. Владимир Зайцев 19.10.14 02:07 Сейчас в теме
Спасибо за базовый материал по учёту на сегодня.Мне это поможет съэкономить время поддержки и знать куда идти.
203. odin777 23.10.14 21:07 Сейчас в теме
Прежде чем внедрить решение задачи, следует изучить соответствующую типовую функциональность и методику ее применения. думаю эти слова в первую очередь нужно осмыслить начинающим внедренцам, таким как я ;)
205. CheBurator 3399 12.05.16 10:06 Сейчас в теме
(203) Есть методика применения, а есть - практика применения - это немножко разные вещи. И владея методикой - окажется что для каких-то нужных клиенту задач нет требуемого инструмента. Но если есть практика применения - вполне очевидно что нужный клиенту результат можно получить используя имеющиеся функциональные возможности. Совсем хорошо когда методика применения - а вы где нибудь видели методику применения Типовой Ут11..? - идет рука об руку с практикой применения
206. goodron 10.05.19 09:56 Сейчас в теме
Автор слегка "лизнул жопу" англичанам - фраза "Если слепой поведет слепого, оба свалятся в яму" никогда НЕ БЫЛА "английская пословица". Погугли и узнаешь. Поколение ЕГЭ.
207. stvorl 942 10.05.19 15:16 Сейчас в теме
(206) Действительно, первоисточник в библейской притче (Ев. от Матф. 15:14). Однако же в английских сборниках пословиц она есть (If the blind lead the blind, both shall fall into the ditch), и я наблюдал ее применение от носителей языка в книгах и фильмах. А вот в сборниках русских пословиц и иной отечественной литературе, что-то, я ее не видел. Даже в интернете одни отсылки и переводы. Поэтому, боюсь, эту пословицу можно таки назвать английской.

Приятно видеть, что люди, по-видимому, из поколения "после ЕГЭ", а может быть, его еще не сдававшие, хоть что-то читают, включая эту статью, но вот вежливо и корректно представлять доводы научились, к сожалению, не все. Тем более, преодолевать искушение утверждать голословно. ЕГЭ (и уж точно - массовую реформу образования под него) я не застал, и даже в этой статье и моем профиле вполне достаточно данных, по которым можно об этом догадаться.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день