—

Правильная методика расчета управленческой прибыли (финансового результата). Отчет о прибылях и убытках (P&L). Управленческий баланс (Balance Sheet). Немного о методе начислений и о кассовом методе.

(Статья в текстовом формате будет позже.)

—

Управленческая отчетность для руководителей (отчет о финансовых результатах (P&L), управленческий баланс для оценки финансового состояния компании). Организация документооборота для ведения управленческого учета на базе конфигурации «Управление торговым предприятием». Проверка двойной записи в управленческом учете. Параллельное ведение бухгалтерского и управленческого учета в единой базе данных. Управленческая касса. Операции, которые отражаются по разному в бухгалтерском и управленческом учете. Расшифровка каждой цифры в управленческой отчетности, путем детализации до первичного документа. Полезно: собственникам, руководителям, специалистам, занимающимся организацией и ведением управленческого учета. Горбенко Олег.

(Статья в текстовом формате будет позже.)

—

Как начислить управленческую заработную плату. Как автоматизировать расчет управленческой заработной платы. Что такое белая и черная заработная плата. Как выплаты на карточки сотрудникам в бухгалтерии попадут в управленческую заработную плату. Как начислять управленческую заработную плату в конфигурации «Управление торговым предприятием для Украины». Горбенко Олег.

(Статья в текстовом формате будет позже.)

 —

Стоимость готовых блоков: http://upruchet.com/стоимость-модулей-прибыли-и-убытки-и/

Статья «Белые и серые продажи и закупки в 1С. Управленческий учет и бухгалтерский. Управленческая касса»

Статья «Почему бухгалтерский и управленческий учет стоит вести в одной базе.»

The post Отчет о прибылях и убытках. Управленческий баланс. Управленческий учет в 1С first appeared on Управленческий учет в 1С для Украины.

Почему в 1С вместо непосредственного удаления объектов, мы лишь помечаем объекты на удаление? Удаление помеченных объектов. Поиск ссылок на объекты.

(Статья в текстовом формате будет позже.)

The post Удаление объектов в 1С. Пометка на удаление. Поиск ссылок на объекты. first appeared on Управленческий учет в 1С для Украины.

В данном видео рассматриваем как настроить отправку счетов, накладных и других печатных форм из 1С на электронную почту. Речь идет о таких конфигурациях: Управление торговлей для Украины (ред. 2.3), Управление торговым предприятием для Украины и Управление производственным предприятием для Украины.

(Статья в текстовом формате будет позже.)

The post Отправка счетов и накладных из 1С по электронной почте. first appeared on Управленческий учет в 1С для Украины.

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

(Статья в текстовом формате будет позже.)

The post Транзакция. Блокировки и взаимоблокировки в 1С. first appeared on Управленческий учет в 1С для Украины.

Допускаются без о/р, в том числе выпускники ВУЗов и студенты технических (ИТ) или экономических специальностей (если нет соответствующего ВО, то на собеседовании Вам будет задан ряд вопросов, чтобы определить, что Вы с компьютером на “ты”).

— Полный рабочий день без совместительства.

— Техническая и компьютерная грамотность не менее чем на среднем уровне. Умение вести письменную документацию.

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

— Быстрая обучаемость и стремление к развитию, повышению квалификации, карьерному росту.

— Адекватное отношение к аргументированной критике.

— Понимание основ программирования, уверенные знания одного или нескольких языков программирования (в рамках учебной программы, а еще лучше за её пределами).

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

— Готовность проявлять инициативность.

— Аналитический склад ума и высокая скорость мышления.

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

— Понимание важности своевременной обратной связи.

Что предстоит делать? (Обязанности):

— Программирование на платформе 1С.

— Доработка типовых конфигураций и разработка новых на языке «1С» по техническим заданиям.

— Интеграция программных продуктов «1С» с торговым и иным оборудованием.

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

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

— Автоматизация процедуры переноса данных, текущее управление переносом данных.

— Готовность работать как с внутренними (наши аналитики и внедренцы), так и с внешними клиентами. Работа осуществляется как на выезде (редко), так и удаленно из нашего офиса.

Условия:

— Офис находится в 3 минутах от м. Васильковская.

— График работы достаточно гибкий, но стараемся придерживаться стандартного графика.

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

— Отсутствие потолка в заработной плате, ваш доход зависит только от вас.

Тип занятости:

Полная занятость, полный день

Отправляйте резюме на адрес: hr@bsp.com.ua

Ждем Вас в нашей дружной компании!

The post Вакансия стажер программист 1С (сейчас закрыта) first appeared on Управленческий учет в 1С для Украины.

Требования к претендентам:

• Опыт доработки и разработки модулей, отчетов и др. в 1С 8.x не менее 3-х лет (знание 1С 7.7 приветствуется, но не обязательно).
• Умение разбираться в чужом коде (и, главное, спокойное к этому, отношение).
• Умение правильно оценить задачу согласно четкому ТЗ и указать сроки.
• Стремление к саморазвитию.
• Высокий уровень самоорганизации, ответственности, умение работать на результат.
• Системное мышление, аналитический склад ума.
• Умение размышлять как вслух, так и письменно.
• Адекватное отношение к аргументированной критике.
• Понимание важности своевременной обратной связи.

Функциональные обязанности:

• Доработка конфигураций 1С (отчеты, обработки, изменение печатных форм).
• Разработка новых подсистем учета в 1С.
• Интеграция 1С с другими системами (в т. ч. конвертация, внешние файлы, JSON, COM-соединение, WEB и т.д.);
• Настройка прав доступа для пользователей, доработка механизмов настройки прав доступа (как стандартными средствами + RLS, так и программно).
• Участие в методической проработке задач и оценке работ (согласно ТЗ).
• Соблюдение сроков, стандартов разработки и наших внутренних правил работы программистов.
• Делать доработки согласно написанному ТЗ.
• Тестировать сделанные доработки (с описанием, как именно тестировал)
• Документировать сделанные доработки (сохраняя баланс между пользой описания и затраченным на это временем).
• Готовность работать как с внутренними (наши аналитики и внедренцы), так и с внешними клиентами. Работа осуществляется как на выезде (редко), так и удаленно из нашего офиса.

Условия работы:

• Возможность обучения, повышения квалификации в сфере 1С, сертификации за счет компании — мы поощряем стремление к знаниям, желание развиваться и самосовершенствоваться.
• Возможности профессионального и финансового роста.
• Отсутствие потолка в заработной плате, ваш доход зависит только от вас.
• Оплачиваемый отпуск.
• Офис находится в 3 минутах от м. Васильковская.
• График работы достаточно гибкий, но стараемся придерживаться стандартного графика.
• Оплата сдельная. Но мало зарабатывать Вы будете только в случае, если не будете справляться с работой.
• Также, если у Вас есть свои авторские разработки, Вы можете получать % от их продажи (по договоренности).

Тип занятости:

Полная занятость, полный день

Отправляйте резюме на адрес: hr@bsp.com.ua

Ждем Вас в нашей дружной компании!

The post Вакансия программист 1С (сейчас закрыта) first appeared on Управленческий учет в 1С для Украины.

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

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

При оформлении  поставил галочку “самовывоз”. Было около 4 часа дня, и, у меня было время заехать и забрать этот товар, если бы он, вдруг, оказался у них в магазине. Итак, я оформил заказ. Это была среда. После этого, по вайберу мне пришло сообщение, что мой товар можно будет забрать в пятницу, т.е. через день. Дальше, мне звонит менеджер и говорит, что данного товара осталась только 1 штука. Я спросил, есть ли аналогичный по всем характеристикам товар, так как в компьютер лучше ставить 2 модуля памяти одного и того же производителя. Менеджер немного поклацал и сказал, что, да, есть практически такой же товар производителя Kingston, но чуть дороже. Я сказал, что это меня полностью устраивает. Он ответил, что товар есть в магазине, что он его поставил в резерв и можно прямо сейчас уже ехать и забирать. Я обрадовался и спросил, поменяется ли номер заказа или останется тот же? Он ответил, что мне придет смска. Я подождал смс еще минут 20, так как не был уверен, сколько я там на месте проведу времени не зная номера заказа. Видимо, менеджер имел в виду то сообщение по вайберу, что мне уже пришло. Но это несколько странно, так как то сообщение было с другой номенклатурой товаров и в нем было указано, что мне нужно приехать в пятницу. Дальше, я решил, что, может, я на сайте смогу узнать номер заказа, но обнаружил, есть только мой старый заказ, и в нем не изменилась ни номенклатура, не стоимость. Статус у заказа все еще был “Новый”. Я решил посмотреть, какую память мне мог поставить в заказ менеджер и обнаружил, что у производителя Kingston были 2 разные номенклатуры памяти, по-практически одной и той же цене. При этом, один из этих товаров у меня бы не заработал. Соответственно,  мне очень нужно было понять, какую же именно номенклатуру менеджер поставил в заказ. А учитывая, что никаких доказательств того, что заказ, действительно, изменился, кроме слов менеджера, у меня не было, а я, даже, не запомнил его имя, то в этот день я решил уже никуда не ехать. От греха подальше, я создал новый заказ, в котором выбрал именно ту номенклатуру, что мне нужна. После создания нового заказа, мне пришло по вайберу сообщение, что заказ можно будет забрать завтра, т.е. в четверг. Через час в тот же день, я обнаружил, что в старом заказе статус поменялся на “Ожидает в пункте самовывоза”. Но номенклатура и стоимость в нем не изменились. На следующий день, картина с обоими моими заказами уже выглядела вот так.

Как видите, в старом заказе все еще фигурирует красная память и старая стоимость. А в новом правильная зеленая память и новая стоимость.

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

В итоге, насколько я понимаю, если бы я не создал новый заказ, а забрал бы товар по старому заказу, то старый заказ с неверной номенклатурой и стоимостью на сайте поменял бы статус на “Выполнен” и остался бы висеть в истории заказов. Это неудобно, так как я часто обращаюсь к истории заказов с Rozetka.Ua, чтобы посмотреть модели товаров, которые я приобрел и почитать их характеристики. А, представьте, как это может быть неудобно людям, которые захотят провести финансовую сверку своих данных с данными Rozetka.Ua и просто не подозревают, что данные на сайте могут отличаться от данных в их внутренней базе, а реальную сверку нужно у них просить отдельно? Я очень надеюсь, что эти недочеты в скором времени Rozetka.UA подправит.

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

Как видите, он до сих пор висит у меня со статусом “Новый”. Я уверен, что во внутренней базе этот заказ у них отменен, а на сайте, почему-то отображается вот так…

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

Так вот, дело в том, что синхронизация двух и более источников данных между собой — это не та работа, которую можно начать и в какое-то ограниченное время закончить. И, самая основная беда в том, что заказчик уже на этапе постановки задачи приходит с этой роковой ошибкой в архитектуре. Он, даже, может проводить тендеры с такой изначально выбранной архитектурой. Пытаешься объяснить ответственному лицу, насколько большие проблемы могут возникнуть, и обязательно возникнут, при таких решениях. Объясняешь, насколько это дороже и сложнее обслуживать. Он идет, общается с руководством, и, все равно, не всегда может донести корректно эту мысль, а часто и получает отказ от перевода всего на единую базу. Кроме того, руководство не понимает, почему сумма на внедрения может значительно увеличиться от необходимости грамотной настройки синхронизации между базами. И в этом случае, мы пытаемся выйти напрямую на руководство, чтобы пообщаться, но это не всегда получается… К сожалению, с высоты руководству часто кажется, что, мол, что за проблема такая — перенести один документ в другую базу, а из другой базы перенести другой документ в первую. Сама постановка задачи же поместилась в одно предложение. Значит, по идее, и реализация будет довольно простой! В итоге, пытаются сделать все это за один раз и дешево, за что, в итоге, получают проблему с синхронизацией данных… Особенно, если исполнитель попался, который говорит: “Скажите мне что сделать и я сделаю”. И он не особо беспокоится о том, что будет у заказчика с данными после окончания проекта. А между тем, самое дешевое и надежное решение — это, как раз, использовать единую базу.

К примеру, если рассмотреть данный пример с Rozetka.UA, то в архитектуру на упрощенном уровне, на котором любит рисовать схемы руководство, могло быть заложено следующее:

1. Пользователь на сайте вбивает заказ, и он переносится во внутреннюю базу компании.
2. Когда менеджер меняет статус заказа во внутренней базе компании, новый статус заказа переносится в базу данных сайта.

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

В целом, я не говорю, что Rozetka.UA выбрала неправильную архитектуру по обмену данными с сайтом. Скорее всего, как раз, правильную. Такая архитектура, разумеется, имеет право на жизнь. И, в некоторых случаях, ее нужно выбирать. Проблема заключается в том, что отладка синхронизации, если уж ее приходится использовать, никогда не должна останавливаться. Т.е. раз в несколько дней или, даже, каждый день, автоматическая обработка, которую, конечно, еще нужно написать, должна сверять те данные, которые, по идее, должны совпадать для обоих баз. Когда нет различий — все хорошо и не тратим на это время. Когда есть различия, то обработка должна сигнализировать разработчику, например, на электронную почту, что есть различия, а он уже должен восстанавливать причинно-следственную связь и разбираться, как эти различия появились. Таким образом, всплывают процессы, которые на этапе проектирования не были учтены, о них не знали, либо, даже, забыли о них. И они обязательно будут. От этого никуда не деться. Не стройте иллюзий, что Вы избежите этого. Любой другой путь приведет к тому, что данные в нескольких базах поплывут безвозвратно. Особенно, если Вы автоматическую проверку не внедрите как часть архитектуры синхронизации данных, а просто несколько раз вручную сверите данные между собой, решите, что они не отличаются и что все хорошо, дело сделано. Но нет, так не бывает! Сами процессы могут поменяться уже после внедрения таким образом, что синхронизация перестанет работать корректно. Да и, в принципе, из-за одного какого-то недокументированного редкого действия данные могут поплыть так, что концов уже не найдешь… Заметьте, что при работе в  единой базе, мы о таких вопросах НИКОГДА не задумываемся! Их для нас просто не существует!

Часто руководство пребывает в блаженном неведении, что все их базы четко копейка в копейку синхронизированы и совпадают. В этом и беда. Как видите, если руководство Rozetka.UA решит, что можно какие-то отчеты строить по данным сайта, то, во всяком случае, на текущий момент, их ждет разочарование… А, ведь, Rozetka.UA, на мой взгляд, самый технологичный интернет-магазин в Украине. И я  уверен, что они тратят на поддержку ИТ достаточно большие средства! И, заметно, что они постоянно работают над улучшением сервиса. То, что было раньше и то, чего они достигли сейчас — это просто небо и земля! И я люблю покупать там товары, что и Вам рекомендую. Так что я пишу данную статью не с целью поругать Rozetka.Ua, а с одной стороны, с целью указать им над чем еще стоит поработать, ради моего удобства как покупателя. А с другой стороны, показать Вам, что, даже у такой крупной и серьезной структуры, которая вкладывает в поддержку IT достаточно внушительные средства, есть проблемы обмена между двумя базами. Поймите, что это очень сложный и серьезный вопрос, а ему, почему-то, уделяется невероятно мало внимания! И нужно, чтобы руководство заказчика было, как минимум, в курсе этой проблемы, а отладкой синхронизации занимались истинные перфекционисты, которые хорошо понимают данную задачу. Правда, думаю, что, конкретно с Rozetka.UA проблема заключается только в том, чтобы руководство поставило задачу своим айтишникам потратить на это время и наладить процессы обмена, которые, как видите, вышли из-под контроля.

Буквально, на днях, мне попалась интересная статья про такое понятие, как “Технический долг”. Она о том, что ко всем “костылям”, которые были занесены в программный код, как временное решение, требуется отразить в проекте их последующее разрешение. Главное, чтобы заказчик видел, что есть доработки, на которые, еще, в будущем, придется потратить время и средства. И, как раз, в случае, когда есть несколько баз, я бы на каждый месяц зарезервировал какое-то время специалиста под “допиливание” процедуры обмена. Причем, не важно, есть у Вас свой штатный программист или у Вас программисты на аутсорсе. Все равно это нужно делать. Просто не питайте иллюзий, что синхронизация делается один раз и на века и тогда у Вас будет возникать меньше неожиданностей в работе. Спасибо за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».

The post Сложность обмена данными между двумя базами на примере Rozetka.UA first appeared on Управленческий учет в 1С для Украины.

Статья будет интересна не только соискателям на вакансию, а и другим пользователям 1С. В ней я делюсь опытом, рассказываю, «как дошел до такой жизни». Также, говорю о распространенном губительном заблуждении, что программист 1С может помочь по любому вопросу.

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

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

В общем, как Вы понимаете, все это привлекает множество людей к освоению продуктов 1С. Беда заключается в том, что под специалистами 1С “неискушенные” люди понимают программистов. И, действительно, очень многие новички учатся, именно, на программистов 1С. Да, несомненно, программисты нужны. Без них нельзя сделать чего-нибудь существенного, например, изменить программные алгоритмы под наши нужды. И для рынка, вроде бы, большой плюс, что таких людей достаточно много. Но уже давно бросается в глаза, что рынок ими, явно, перенасыщен. Я не отрицаю, что спрос на подобного рода услуги — громадный, и на кусок хлеба таким людям хватает. Проблема заключается в том, что результаты внедрения такими людьми учета во многих компаниях оставляют желать лучшего. Причем, так можно сказать о любом экономическом ПО, не только об 1С. Программы у людей установлены, а учета, толком, и нет. И все это касается как бухгалтерского, так и управленческого учета. В чем же проблема?

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

Чтобы показать Вам, какое я сам отношения имею к программированию, расскажу немного о себе и о том какой путь я прошел. В 5 лет у меня был компьютер синклер, на котором игры и программы загружались с аудиокассет. В этом возрасте я уже умел немного читать и писать. И вот, в моменты, когда игры мне немного поднадоедали, я разбирался со встроенным в этот самый синклер языком программирования. Более того, когда меня спрашивали в детском саду, кем я хочу быть, я один из немногих, уверенно отвечал, что программистом. Несколько позже, с 13 лет, когда у меня появился современный персональный компьютер, я начал изучал такие языки программирования, как Basic, Pascal, затем, Visual Basic. В 14 лет у меня с друзьями появились, даже, первые коммерческие проекты. А с 16 лет я начал изучать язык программирования 1С версии 7.7. В 17 лет я уже стал сертифицированным программистом по 1С. Так вот, к чему я все это говорю? А к тому, что я с детства любил компьютеры, но не знал, что были и другие, не менее важные,  технические профессии. Видимо, так было не только у меня. Оглянитесь, даже сейчас, того же системного администратора или какого-нибудь консультанта, люди могут продолжать называть программистом.

Но перейдем к сути. Я начал работать как программист 1С в маленькой фирмочке 1С-Франчайзи (она стала франчайзи немного позже, когда я сдал экзамены). Шеф привозил мне задачи по доработке программы 1С, и я их выполнял. Первые пару месяцев, кстати, я думал, что 1С — это просто печатные формочки документов. Даже, не знал, что она умеет учитывать и выводить товарные остатки. Ну, просто мне ничего не объяснили, а сразу начали ставить задачи. А задач на изменение механизма учета остатков, просто поначалу, не было. Почти сразу я почувствовал эйфорию, и что я могу сделать в программе все, что угодно. И, поверьте, что, по сути, любой начинающий программист может почти сразу, тоже, сделать в программе что угодно. Да, дольше, да, допустит больше ошибок. Но если за ним хорошо все проверять и вовремя просить его исправить найденные ошибки, то, поверьте, он все сделает как надо. И, кстати, парадокс заключается в том, что любого, даже, самого лучшего и опытного программиста, все равно, нужно очень хорошо проверять. Дело в том, что, как таковые, стандарты знаний программистов 1С, они-то существуют, но вот воспользовался или нет ими программист, когда делал для Вас ту или иную конкретную доработку — неизвестно. Поэтому, если Вы ставите задачу и принимаете работу, то Вы эти стандарты должны знать еще лучше, чем он сам. Есть, правда, нюансы в написании  кода, с которым сможет работать больше количество пользователей одновременно и у них не будут возникать, так называемые, блокировки. Также, есть нюансы со скоростью выполнения программного кода, когда опытный программист может сильно ускорить работу критического участка в программе. Но все эти нюансы важны, наверное, где-то в 1 случае из 100, и, для большинства поставленных в 1С задач, они не понадобятся. Подробнее мы эти вопросы рассмотрим в следующих статьях.

Теперь, вернемся снова к моему пути. От работы я получал много удовольствия. Так как я был и, наверное, остаюсь, достаточно тщеславным, я уговорил шефа, что буду сам ездить к клиентам и брать у них задачи напрямую. Плохо то, что сделанная мною доработка никогда не сдавалась в один заход. Во-первых, мои программы запускались не с первого раза и не всегда работали у клиента так, как они работали у меня в офисе. Во-вторых, будучи новичком и, общаясь с клиентом, я понимал что-то одно, а клиент хотел чего-то совершенно другого. Так что, иногда, приходилось переделывать задачу, практически, с нуля. В этом плане, было заметно, что когда задачу у клиента брал мой шеф и передавал мне — она намного ближе  подходила к тому, чего изначально хотел клиент. Шеф знал бухгалтерию, предпринимательство и экономику. Я всегда восхищался тем, как клиент мог сказать только 2 слова, а мой шеф уже рисовал из этого всего схему, глядя на которую, клиент довольно и утвердительно кивал головой. Были у нас, конечно, и провалы. В основном это происходило, когда задача стояла не доработать программу, а внедрить типовое решение. Ведь, учитывая, что я не знал бухгалтерию, шеф, тем не менее, отсылал меня “обучать” сотрудников заказчика тому, как вводить данные в программу. И получалось это, как Вы понимаете, из рук вон плохо. Заказчики чувствовали, что я по всем вопросам плавал, да и сидеть с ними и помогать им вводить документы в программу мне, как программисту, который, как супермен, “может все”, казалось очень скучным и “недостойным” занятием. Шеф называл это внедрением, а я ненавидел такие проекты. Несложно догадаться, что в основном, они заканчивались фиаско. Видите, а, казалось бы, человек, умеющий программировать, наоборот, универсален, как многие думают. Он может, вроде бы, и как консультант выступать, а может и что-то доработать… Но не тут-то было!

Отработав ровно 3.5 года, я уволился и стал фрилансером 1С. Размещал свои  резюме на сайтах работ и старался никому из приходящих клиентов не отказывать. В тот период, мною были довольны компании, которые достаточно хорошо знали, чего они хотели. Такие компании ставили мне задачу по доработке торгового учета, а я им помогал улучшить постановку их задачи, думал вместе с ними как лучше это будет сделать. Тогда я называл то, чем я занимался управленческим учетом, но сейчас-то я понимаю, что это была лишь его часть. Так вот, то что я помогал клиентам в постановке задачи — это, по их мнению, называлось “хороший программист”. Если появлялись задачи по бухгалтерскому учету, то я, наоборот, ожидал от бухгалтера, что он скажет, что конкретно нужно сделать и четко распишет все проводки. Потому, для заказчиков бухгалтеров — я уже не считался “хорошим программистом”. Проекты, касающиеся обучения и внедрения мне, к счастью, в этот период не попадались. Как Вы понимаете, у меня, на тот момент, созрела проблема. У меня были серьезные заказчики, которые, как правило, вели и бухгалтерский и  управленческий учет. И я понимал, что мне, желательно, было бы объединится с каким-нибудь специалистом по бухгалтерскому учету. На прошлой работе, как Вы помните, меня в этих вопросах выручал шеф, а здесь я был сам по себе со своими знаниями и не знаниями. Была, конечно, мысль говорить всем, что я обслуживаю только управленческий учет, но понимание того, что для обслуживания бухгалтерского учета клиентам придется привлечь другого разработчика, с которым мне придется потом конкурировать, не особо грела.

На самом деле, период моего фрилансерства — это уже был период, когда я потихоньку начал, так сказать, “эволюционировать” из программиста в аналитика и постановщика задач. Кто-то может, также, “эволюционировать”, наоборот, в более глубокого технического специалиста. Кроме того, чтобы стать постановщиком задач, совсем не обязательно вырастать в него из программиста. У нас, наоборот, даже, больше успешного опыта в том, что люди с нуля становился аналитиками, чем  вырастали из программистов. Как я уже говорил в одной из прошлых статей, когда я был фрилансером, то часто затягивал работы. Вообще-то, получалось, что я за рабочий день объезжал клиентов, с каждым из них более-менее подробно общался о том, как правильно сделать ту или иную задачу и обещал поскорее ее закончить. Вечером приезжал домой очень уставший, и уже был не особо способен программировать. Совмещать общение с клиентом, обдумывание задачи и программирование в один день очень тяжело физически. Как будто мозги совсем на другой лад приходится перестраивать. А на завтра, уже, опять запланированы встречи и т.д. Возможно, к тем же самым клиентам уже по другим вопросам нужно ехать, например, какой-то документ не проводится и т.д. Тогда, кстати, удаленный доступ только появлялся и чаще нужно было мотаться, чем сейчас. И, чтобы исправить любую допущенную ошибку, приходилось ехать к заказчику снова. В общем, получалось, что в рабочее время нужно ездить, а только в нерабочее и в выходные программировать. Кроме этого, мне не давало покоя, что вот я сегодня приехал к этому заказчику, как большой специалист, чуть ли не консультант по бизнесу, а завтра к нему же приехал помочь нажать на одну кнопку. А в это время, я не могу запрограммировать ему очень важную работу, как раз из-за недостатка времени. Этим, кстати, очень страдают программисты, которые работают в торговых или производственных компаниях на полный рабочий день. Они могут что-то разрабатывать, быть полностью погруженными в это, а пользователи их постоянно отвлекают вопросами или звонками. Со временем пользователи уже боятся задавать вопросы, так как программист начинает агрессивно на них реагировать и т.д. Во всяком случае, некоторые клиенты имеют у себя в штате программиста, но, дополнительно, обращаются к нам, так как с ним “невозможно разговаривать” и т.д. И здесь я хочу заметить, что, возможно, как раз срочный мелкий вопрос приоритетнее той задачи, которую программист взял разрабатывать на целую неделю. Просто программисту интереснее возиться с этой задачей. Я сам когда-то допускал такие ошибки и скандалил с заказчиками, не понимая, что я просто неверно оценивал расстановку приоритетов. Уже когда у меня появилась своя компания и я перестал эмоционально участвовать в процессе разработки, то до меня это “дошло”. Есть еще такое понятие, как “неинтересная” для программиста работа. Например, я хорошо запомнил, как один заказчик жаловался, что попросил своего программиста, разумеется, за деньги, помочь внести в программу остатки руками. На что тот ответил “Не жирно ли Вам будет? Сами внесете.” и не стал этого делать. Я лично не понимаю, если заказчик знает цену и готов ее платить, почему он должен не получить услугу?  Чувствуете, вот эту “иллюзию” универсальности программистов?

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

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

Итак, дальше, в 2005 году по резюме на сайтах работ, меня нашел Олег Горбенко. Он в качестве консультанта обслуживал программы 1С в разных компаниях, но с точки зрения не управленческого, а, именно, бухгалтерского учета. И, так как ему, иногда, приходилось делать некоторые доработки в программах клиентов, а он этого не умел делать сам, то ему нужен был программист. У Олега был и опыт работы главным бухгалтером и, действительно, хорошее знание бухгалтерии. Кстати, напоминаю, если кто не знает, что с того времени, мы с ним партнеры по бизнесу. Я до сих пор помню, как Олег меня поразил на моем же поле, где я считал себя “Богом”… Я его пригласил к одному из своих клиентов по бухгалтерскому вопросу. А я им, как раз, должен был одну доработку сдавать, но, как всегда, затянул по времени. Олег после того, как решил свой вопрос, узнал, что они от меня чего-то ждут, и спросил, мол, а чего Вы ждете-то? Вы же, пока, доработки нет, можете делать в программе вот так и так, а как появится доработка от Юры, будете делать по-другому. Они с радостью согласились, а у меня как от души отлегло. И я тогда всерьез задумался о том, как же так получилось, что я все замкнул на себе, а вопрос так просто решался. В итоге, по этой задаче больше не было никакого чувства вины и срыва сроков. Я не помню, о какой доработке тогда шла речь, но само это чувство облегчения я очень хоршо запомнил. Вот пример того, как я зациклился на самой доработке, а взглянуть на ситуацию чуть шире, чем из роли программиста, чтобы не подводить людей, не мог. Олег тогда открыл для меня какой-то целый новый мир, о котором я не задумывался раньше.

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

На форумах я заметил, что многие программисты-фрилансеры таких людей как Олег называют нахлебниками. Мол, зачем нужен посредник между заказчиком и нами? Мы и сами можем приехать к заказчику, взять задачу и выполнить ее, и заказчику так только дешевле выйдет. Так думают и некоторые “неискушенные” клиенты. А что же происходит на деле? А на самом деле программист приходит к заказчику и говорит: “Я могу сделать все, что угодно. Скажите мне, что сделать”. При этом, программист редко знает программу с точки зрения пользователя. А зачем ему это нужно? Он учится в процессе, на тех задачах, за которые клиенты готовы платить. Так что если программист сознательно не начнет в своей работе выполнять анализ данных, направлять клиента не только по пути доработок, а и по пути обучения, то ничему такому он никогда и не научится. Плюс, некоторые клиенты могут не ценить такую работу, а считать, что стоит каких-то денег только доработка и т.д. Да и редко клиенты задают вопрос, мол, может, мы что-то не так делаем в программе? Чаще всего, они вызывают программиста и говорят — тут у нас не те цифры в отчете, а тут нам надо доработать программу и т.д. В итоге, вместо того, чтобы показать заказчику, где он допустил ошибку в исходных данных, и как ему, возможно, изменить некорректный бизнес-процесс (если он, действительно, некорректен), программист просто, как правило, “ломает” программу по требованию заказчика. Причем, если торговый и управленческий учет, действительно, может нуждаться в доработке, то бухгалтерию, чаще всего, не нужно дорабатывать. У Олега нередко случается, что после других “программистов” приходится ставить клиенту чистую программу, обучать бухгалтеров в ней работать, и, оказывается, о, чудо, им подходит стандартная конфигурация без каких-либо доработок. Например, ни в коем случае нельзя ломать программу дробя план счетов на субсчета или делать другие глобальные изменения. Ведь, программист редко знает, куда какая цифра должна попасть из бухгалтерских счетов в регламентированные отчеты. И, часто, заказчик оказывается разочарован, когда после доработок ни один отчет не формируется правильно, и т.д. Но о проблемах бухгалтерии больше расскажет Олег в своем видео по аналогичной вакансии (https://www.youtube.com/watch?v=MZ2PkYBbbJo), связанной с бухгалтерским учетом. Моя же вакансия связана с торговым, управленческим и финансовым учетом.

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

Аналитик, также, должен понимать, что такое управленческий баланс, управленческий отчет о прибылях и убытках, должен понимать, что такое двойная запись и зачем она нужна. В крайнем случае, мы этому, конечно, обучим. Это только некоторые примеры. Потому, часто, чтобы заказчик остался доволен нашей работой, нужно поднять его осознанность, как в плане финансового учета, так и в плане знания программы. Например, иногда нужно отобразить в Экселе откуда и куда попадут его цифры, или сделать тестовый пример в программе и посмотреть по отчетам, что и куда попадает. Все потому, что заказчик, иногда, придумывает такие методики, которые, если их реализовать в точности, как он говорит — не сойдутся в итоговых цифрах… Как Вы понимаете, программист таким заниматься, вряд ли, станет, а сразу возьмет эти задачи в работу. Аналитик же, получая задачу от заказчика, в любом случае, должен задаваться таким вопросами: “от кого исходит задача (от этого конкретного сотрудника, который ее озвучивает, начальника отдела или руководителя компании)?”, “Какова цель этой задачи на самом деле?”, “Нужно ли ее делать, на самом деле, принесет ли она заказчику ожидаемые результаты”? По поводу последнего вопроса, иногда, руководитель передает нам, заведомо, недодуманную задачу своим подчиненным, а они ее ставят нам. И нам, тогда, приходится пробиваться напрямую к руководителю, чтобы подкорректировать эту задачу, привести ее к логической целостности. Иногда ставится задача расширить учет, сделать больше аналитик в существующих данных. В этом случае, мы обращаемся к людям, которые эти данные должны будут заносить и узнаем их мнение о том, возможно ли это. Допустим, как пример, если сотрудник разносит какие-то данные в документе одной строчкой и данная процедура занимает у него 15 минут, а будет вносить те же данные 20 строчками и это будет у него занимать у него 2 часа. Тут вопрос в том, есть ли у этого сотрудника столько времени. Тогда, руководитель должен решить, что, либо он приказывает сотруднику делать эту дополнительную работу, хоть она и будет отбирать намного больше времени, реорганизует каким-то образом работу этого сотрудника с учетом наших рекомендаций, расширяет штат, либо отменяет эту задачу. Выигрыш для заказчика в том, что это все выясняется еще до того, как он потратил деньги на данную доработку. Опять-же, программист, скорее всего, сразу возьмет данную задачу в работу, не думая о том, смогут ли люди заказчика ею пользоваться. Он искренне будет думать, что это не его проблемы. Что-то вроде “мне сказали, я сделал”. А нам бы хотелось, чтобы заказчик имел результат на все потраченные им деньги, и, если, ему немного не хватает, допустим, организованности, или каких-то специфичных знаний — мы это скомпенсируем своей компетентностью. По этой же причине, мы стараемся никогда не продавать программу сразу, без личной встречи с заказчиком. Но об этом поговорим подробнее в следующих статьях.

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

Продолжая данную тему, хочу немного остановиться на том, что если некую задачу можно решить без программирования или с минимальным программированием, то это, как правило, и будет оптимальным решением. Помню, лет в 15, когда я еще программировал на Visual Basic, я хотел внести дополнительный модуль в нашу с другом программу. А он сказал, мол, сам будешь потом исправлять ошибки. Я так обиделся на это и дулся на него несколько дней. А на деле-то, он был прав. Чем больше программного кода, тем больше в нем будет ошибок. Даже, если этот код будет писать супер-опытный программист. Типовые конфигурации протестированы сотнями тысяч пользователей и уже максимально отлажены. Потому, мы стараемся, именно, с их помощью решать вопросы клиентов, а не изобретать велосипеды. А тут, кстати, программисты, как видите, и не нужны. Помните, как я будучи программистом неудовлетворительно с этими задачами справлялся? И, только, если базовым функционалом поставленную задачу никак не решить или она этим функционалом решается неудобно, мы принимаем решение о доработке программы. Для программиста — это парадокс. Его вызывают доработать программу, значит, он должен ее доработать. Программисту кажется, даже, что если он придумает как выполнить задачу без доработки, то заказчик решит, что он ленивый или просто отлынивает от работы. Теперь, немного об оптимальных решениях. Недавно, ко мне приходил человек, хотел устроиться на должность аналитика. Так вот, он хвастался, что был постановщиком задачи разработки конфигурации “с нуля” для фитнес-клуба. Знаете, когда я только начинал, мне казалось, что написать свою конфигурацию с нуля — это очень круто и это могут сделать только очень сильные специалисты. Теперь, я на это смотрю совсем по-другому и считаю, что этот человек, скорее всего, просто принял не оптимальное решение. И намного было бы больше пользы, если бы тот функционал, что он придумал, он реализовал бы как дополнительный модуль для конфигурации “торговля”. Тогда программа умела бы не только то, что он в нее заложил, а и весь базовый функционал типовой конфигурации. Но это же тогда пришлось бы придумать, как увязать возможности этого модуля и типовой функционал. Так вот для этого, как раз, и нужна квалификация. Потому, конфигурации с нуля, в основном, как раз, пишут те, кто не разбирается в типовых конфигурациях. Они просто идут по пути наименьшего сопротивления. Но для заказчика, в перспективе, конфигурация с нуля, как правило, окажется намного более плохим решением, чем дополнительный модуль к существующей типовой конфигурации. Да и когда я показал этому человеку, как мы составляем ТЗ, оказалось, что он его составлял куда более поверхностно (без описания структуры справочников, регистров и т.д.).

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

Вот зачем нужны люди между программистом и заказчиком, ставящие поверхностные ТЗ — мне, конечно, непонятно… Получается, что с ним должен работать особенный и очень крутой программист (а такого ресурса, вообще-то, нехватка), в то время, как, работая по нашей схеме, справится и средний программист. К тому же, я лично ценю ТЗ, написанные таким образом, чтобы его можно было дать, практически, любому программисту, он там все понял и смог это быстро сделать, не отвлекаясь на придумывание неописанных в ТЗ нюансов. Такое ТЗ — это и есть продукт аналитика. Это документ, который реально стоит денег. О том, какие ТЗ стоят денег, а какие — нет, мы еще поговорим в следующих статьях. Опять-же, “хорошие программисты” — это мифические существа и очень ограниченный ресурс. Их очень мало и на всех их не хватает. Потому, когда заказчик мечтает сэкономить, наняв “хорошего программиста”, якобы, универсала, я могу только пожелать ему только удачи. Мой личный опыт в качестве программиста, как и опыт большинства наших заказчиков, которые когда-либо работали напрямую с программистами, говорит о том, что рассчитывать на это не стоит.

Итак, мы подходим к концу. Если Вас вдохновила работа, которую я здесь описал, то скажу, что, скорее всего, на нее подойдет человек с опытом работы финансистом, бухгалтером, экономистом, возможно, логистом и другие… В общем, человек, так или иначе связанный с делопроизводством. Если Вы, наоборот, работали полностью в сфере 1С, это, одновременно, и хорошо, и плохо. Главное, чтобы у нас с Вами совпадали взгляды на “правильное обслуживание клиентов”. Если у Вас нет никакого опыта, но работать все равно хотите, Ваш запрос мы, тоже, рассмотрим. В общем, мы ждем от Вас письмо на email: hr@bsp.com.ua. В письме я ожидаю увидеть пометку, что Вы прочитали данную статью и, также, ожидаю от Вас небольшое сопроводительное письмо о себе и чем Вам нравится данная вакансия + некоторая информация, которую Вы считаете, нам будет полезно узнать о Вас. И, разумеется, в письме, хочу увидеть, также, Ваше резюме в стандартной форме. Обещаю внимательно просмотреть все письма, которые придут.

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

Оплата сдельная. Вы получаете % от выработки. Со временем, Ваш % растет.

Да, и рекомендую заглянуть в видео на подобную вакансию от Олега (https://www.youtube.com/watch?v=MZ2PkYBbbJo). А потом, по ходу, уже решить, какая из двух Вам будет ближе.

Спасибо за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».

The post Вакансия аналитик 1С (сейчас закрыта). Почему от программиста 1С мало толку? История моего становления. first appeared on Управленческий учет в 1С для Украины.

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

Мы уже говорили с Вами в статье “Бухгалтеры и управленческий учет” о том, что далеко не каждый бухгалтер соглашается вести управленческий учет. Это происходит по разным причинам и, иногда, создает предпринимателю некоторые трудности. Но сейчас я хотел бы поговорить немного о другом. Я хотел бы обратиться к бухгалтерам и привести причины, почему им все же стоит присмотреться к перспективе ведения управленческого учета.
Одна из главных причин для бухгалтера приобщиться к ведению управленческого учета состоит в том, что это, все-таки, дополнительная квалификация и возможность карьерного роста. Если посмотреть на вакансии разных компаний в Интернете, Вы увидите, что знание управленческого учета сегодня очень востребовано на рынке труда.

Сейчас максимально популяризировалось такое понятие-симулякр, как “личностный рост”. Есть куча тренингов, пройдя которые, нельзя объективно сказать, что Вы как-то изменились. Но зато точно можно сказать, что деньги Вы потратили.

Здесь мы, среди прочего, поддаемся на, так называемую, “ошибку трансформации”, когда верим в то, что какое-то яркое переживание может полностью изменить нас изнутри. Подробнее про тренинги личностного роста смотрите одноименное видео кандидата психологических наук Александра Невеева по ссылке. (https://www.youtube.com/watch?v=_PPij1PtDUc).

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

А что же по поводу личностного роста? Вы согласны, что в понятие личностный рост входит лучшее понимание мотивации и поведения других людей, а также, повышенное спокойствие? Так вот, часто, бухгалтер, на своем уровне развития, хорошо понимает некоторых других сотрудников в своей компании, но плохо понимает менеджеров по продажам и руководителя. Я лично наблюдал много конфликтов, связанных с тем, что бухгалтер высоко ценит свою работу, а руководитель — нет. Так вот, бухгалтер, вовлеченный в ведение управленческого учета понимает, что же на самом деле происходит в компании, какая получилась настоящая прибыль от деятельности компании и растет ли бизнес, в целом. С таким бухгалтером руководитель может начать делиться своими мыслями, советоваться. Такой бухгалтер становится доверенным лицом руководителя. Все это приведет к тому, что отношения бухгалтера и руководителя улучшатся, и бухгалтер начнет лучше понимать как  менеджеров по продажам, так и своего руководителя, ведь он будет больше болеть за итоговые цифры и прибыль компании. Также, он перестанет удивляться, почему бухгалтерский учет для руководителя является второстепенным, по сравнению с управленческим учетом. А то часто от бухгалтеров слышу “снисходительное”, мол, посмотрите, там наш директор хочет доработать-поиграться с какими-то отчетами в программе. Пообщайтесь с ним, а то мне это неинтересно. Мне, главное, чтобы от этого ничего в бухгалтерии не нарушилось. По поводу ничего не нарушить в бухгалтерском учете — это, конечно, правильно. Но, все-таки, тот тон, с каким бухгалтер это говорит, показывает, что такой бухгалтер еще не созрел для “личностного” роста, иначе, ему было бы интересно узнать, что же, все-таки, хочет видеть его руководитель, и он бы всеми силами помог в реализации данного функционала.

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

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

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

Еще один повод присмотреться внимательнее к изучению управленческого учета состоит в том, что данный вид учета, по сути, даже, проще бухгалтерского и освоить его несложно. Как я уже говорил в статье “Принцип преобладания сущности над формой”, проблема состоит в том, что бухгалтеры, вначале, долго учатся называть вещи НЕ своими именами, а так, как это нужно государству для целей налогообложения. Затем, если они осваивают управленческий учет, то, наоборот, возвращают, так сказать, способность называть вещи своими уже НАСТОЯЩИМИ именами. К примеру, ООО не может продать товар за наличку, если у него нет лицензии на розничную торговлю и фискализированного в налоговой кассового аппарата. Начинающего бухгалтера такая, произведенная компанией операция, конечно же, введет в ступор. А “простому” человеку, не изучавшему бухгалтерский учет,  такая операция видится обычной продажей, где деньги пришли не на расчетный счет предприятия, а сразу в кассу. Причем, эта операция, даже, понятнее, так как сразу видишь живые деньги, которые можно пощупать, а не какие-то электронные деньги в виде цифр на экране монитора. В точно таком виде данную операцию, как раз, и отразит управленческий учет. Об этом и многих других отличиях бухгалтерского и управленческого учета читайте в статье “Что такое управленческий учет?”.

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

Итак, что же делать, если Вы готовы начать? Во-первых, я бы, конечно, рекомендовал, как минимум, повысить оперативность внесения информации в ту базу, в которой Вы уже работаете. Часто бухгалтеры не задумываются о других пользователях и вносят всю информацию с опозданием. В частности, это касается занесения банковских документов раз в несколько дней, несвоевременного внесения приходных накладных и т.д. Во-вторых, если у Вас “Управление торговлей для Украины”, “Управление торговым предприятием для Украины” или “Управление производственным предприятием для Украины”, то я рекомендую Вам почитать статью “Какую 1С выбрать”, чтобы узнать основные “фишки” этих конфигураций для целей одновременного ведения управленческого и бухгалтерского учета в единой информационной базе, а также, статью “Серые и белые закупки и продажи”. Да, и немаловажным будет прочитать статью “Почему бухгалтерский и управленческий учет стоит вести в единой базе”. В-третьих, не стесняйтесь задавать в комментариях любые вопросы. Я отвечаю на все комментарии. Важно то, что Вы уже сейчас можете начинать вести некоторые элементы управленческого учета без каких-либо дополнительных затрат, повышая свою квалификацию и радуя руководителя. Удивите его, в хорошем смысле! Станьте сами инициаторами начала ведения управленческого учета в Вашей компании! В худшем случае, Вы только повысите стоимость своего труда на рынке, что, согласитесь, не так и плохо! Спасибо за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер»

The post Зачем бухгалтеру управленческий учет? Карьерный и личностный рост бухгалтера first appeared on Управленческий учет в 1С для Украины.

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

 

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

Ну что же, начнем со сравнения управленческих товарных остатков с бухгалтерскими товарными остатками. Компании, как правило, стремятся привести бухгалтерский склад в соответствие с управленческим, чтобы не было неприятностей при проверках соответствующими органами. Но, даже, если это Вас не заботит, все равно, иногда полезно знать, насколько велико расхождение. Заходим в “Отчеты -> Запасы (склад) -> Ведомость по товарам на складах”.

Раскрываем период, выбираем сегодняшнее число. Нажимаем “Ок”.

Теперь, “Сформировать”.

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

Это меня устраивает. Обратите внимание, что у нас показывается единица измерения в конце наименования номенклатуры. Ее нужно убрать. Потому, зайдем в настройку.

Обратите внимание, что у меня сразу стоит галочка “расширенная настройка”.

Перехожу на вкладку “Дополнительные поля” и убираю строчку с единицей измерения.

Сформировать.

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

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

Дальше, удерживая кнопку “Shift” на клавиатуре щелкаем левой кнопкой мыши на последней ячейке с данными.

Теперь, “Shift” можно отпустить. Как видите, у нас выделились все данные отчета. Нажимаем правой кнопкой мыши и выбираем в меню “Копировать”.

Заходим в меню “Файл->Новый”.

Выбираем “Табличный документ” и нажимаем “OK”.

Выделяем первую ячейку и нажимаем правую кнопку мыши. В меню выбираем “Специальная вставка”.

Нажимаем галочку “Все”, чтобы все галочки снялись. Теперь, нажимаем на галочку “Текст” и “OK”.

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

Для удобства, дважды щелкаем сверху между 1 и 2 колонкой и между 2 и 3, чтобы колонки раздвинулись по размеру.

Теперь, “Файл->Сохранить как”.

Создаем папку “Сверка”. Напоминаю, что сохранять нужно как “Табличный документ (*.mxl)”. Называем файл, допустим, “Товары_Упр_24022016”. Сохраняем.

Теперь зайдем в “Отчеты -> Бухгалтерский и налоговый учет -> Оборотно-сальдовая ведомость по счету”.

Установим период. Выберем 281 счет.

Сформируем отчет.

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

Переформируем.

Уже заметно лучше. Но, как видите, Сумма и Количество делят 1 ячейку на две. Это, кстати, та причина, по которой мы не можем сверить оба учета, одновременно, по количеству и сумме. Это можно будет сделать только по очереди. Значит, убираем “показатель” “БУ”.

Сформировать.

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

Кстати, в данном месте оно может немного подтормозить. Дождитесь, пока оно покажет, что все выделилось. Копируем данные в буфер обмена, как и в прошлый раз, вызвав правой кнопкой мыши контекстное меню и нажав левую кнопку мыши на пункте “Копировать”. Дальше, новая таблица и т.д. “Файл->Сохранить как” — “Товары_Бух_24022016.mxl”.

Теперь, заходим в меню “Файл->Сравнить файлы”. Выбираем в первое поле, допустим, управленческий отчет, а во второе — бухгалтерский.

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

Давайте, теперь, в ускоренном варианте я покажу, как сравнить управленческую и бухгалтерскую номенклатуру по стоимости. Для этого я возьму управленческий отчет “Ведомость по партиям товаров на складах”. Кстати, помним, что сравнить мы сможем только сумму без ндс, так как в бухгалтерии товары учитываются на счетах учета без ндс. Потому, в управленческом учете выведем только показатель “Стоимость”, а показатель “НДС” оставим “за скобками”. (В видео это можно посмотреть подробнее с 6:27). Кстати, проверка по стоимости в УПП сработает только если в учетной политике прописано вести стоимость товаров в управленческом учете без НДС (в большинстве случаев, мы это считаем неправильным). В УТП таких вопросов не возникает.

Как видите, вот мы и сделали проверку по стоимости номенклатуры.

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

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

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

Открываем “Отчеты -> Продажи -> Взаиморасчеты -> Ведомость по взаиморасчетам с контрагентами”.

Как Вы помните из статьи “Взаиморасчеты с контрагентами в 1С”, в управленческом учете ведомость по взаиморасчетам с контрагентами содержит и покупателей, и поставщиков, одновременно. В бухгалтерском же учете все по-другому и остатки взаиморасчетов покупателями и поставщиками хранятся на разных счетах учета.

Настройка. Период. В показателях оставляем только конечный остаток по сумме взаиморасчетов.

Отборы. Добавляем фильтр на договоры по покупателям. Также, поставим ограничение в договоре по валюте взаиморасчетов — “Гривна”.

Дело в том, что мы будем сравнивать управленческую дебиторку с 361 счетом, а на нем хранятся только взаиморасчеты с резидентами. Если нам понадобится сравнить валютную дебиторку, то нужно будет, наоборот, “обрезать” тогда в управленческом отчете гривну и сравнивать только валютную дебиторку, но уже не с 361, а с 362 счетом. Теперь, нужно поставить ограничение на конечный остаток суммы взаиморасчетов в “больше 0”.

Данным ограничением мы выбираем только тех покупателей, кто нам должен, игнорируя тех, кому должны мы. Объясняю, почему я так делаю. Дело все в том, что в бухгалтерском учете у нас есть дебетовое и кредитовое сальдо и оно у нас там в разных колонках. В то время, как в управленческом учете — все это находится в одной колонке, только с разными знаками. Все это создает несовместимость для нашего инструмента сравнения. Потому, мы и будем сверять эти колонки по очереди. Более того, если Вы используете счета полученных авансов, то покупатели, которым должны Вы у Вас осядут не на 361 счете, а, соответственно, на счете полученных авансов. Из группировок уберем разворот по договору.

Теперь, нажимаем “Сформировать”.

Отлично! Нас все устраивает. Теперь, проделаем все необходимые операции, как в прошлые разы, и сохраним отчет как “Дебиторка_Упр_Намдолжны_Гривня_24022016.mxl”.

Теперь бухгалтерская оборотка по 361 счету. Сформировать.

Так, нужно убрать разворот по “Документам расчетов” и “Договорам”. Сформировать. Уже лучше, но нужно, теперь, убрать тех, кому должны мы. Добавляем новый элемент в “отбор”. Сальдо на конец периода (Дт) <> 0.

Отлично! Делаем проделываем все, что нужно и сохраняем как  “Дебиторка_Бух_Намдолжны_Гривня_24022016.mxl”.

Можно сравнивать.

Как видите, все получилось.

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

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

Если у Вас что-то не получается по теме данной статьи или нужны дополнительные разъяснения — оставляйте комментарии и я постараюсь Вам помочь. Благодарю за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер»

The post Сравнение данных бухгалтерского и управленческого учета в 1С. Сравнение товаров и дебиторки. first appeared on Управленческий учет в 1С для Украины.