Предисловие.
Почему было решено перейти на РАУЗ я тут описывать не буду. Главная причина это тормоза. Тормоза именно в подсистеме партионого учет (РН " Партии товаров на складах УУ, БУ НУ"). остальное нас в принципе все устраивало.
Партионка это вообще узкое место в УПП, КА. Да и 1С забросила ее развивать. Там даже основной запрос, который считывает остатки сделан не оптимально и громоздко.
Итак, примерно про учет на что стоит обратить внимание:
Как было в партионки:
1) Списывать партии при проведении;
2) Себестоимость по средней;
3) Учет себестоимости по складам;
4) Детализация управленческого учета: по организации
Учет:
5) Оптовая торговля
6) Розничнная торговля . Все точки АТТ. Удаленно работают в терминале. С кучей торгового оборудования.
То есть все старались по настройкам сделать максимально просто.
Перешли на РАУЗ с 01.08.2012.
Основные настройки:
1) Детализация учета Регламентированный учет с дополнительной аналитикой(УУ отрубили не нужен лишний регистр);
2) Учет себестоимости по складам;
3) Порядок формирование учетных цен: по плановым
Теперь напряги(подводные камни)
Напряг 1 Возвраты!
Как работает типовой механизм в РАУЗ.
Когда возвращается товар то идет сторно запись в РН «Учет затрат» и для документа Расчет себестоимости это товар как бы и не продавался.
То есть, пример:
Приход 100
Расход 80
Возврат 20
При расчете себестоимости программа считает что расход 60.
Поэтому 1С рекомендует:
- Если возвращается товар текущего месяца, то вводить на основании реализации и в табличной части будет Себестоимость = «из документа». (будет сделано движение расход сторно)
- Если возвращается товар предыдущего месяца, то рекомендуется ставить себестоимость, например, предыдущего месяца. То есть колонка Себестоимость = число. (будет сделано приход, то есть для РАУЗ это внешнее поступление).
Иначе может выйти такая ситуация:
Приход 100
Расход 80
Возврат 120
При расчете себестоимости программа считает что расход -40. Ошибка!!!
Пункт 2(рекомендаций 1С) можно добиться, если вводить документ «Возврат от покупателя» не на основании Реализации. То есть, в табличной части реквизит реализация не будет заполнен.
Нам уже это не подходило по причинам:
1) Там на основании, тут не на основании. Это просто бы запутало всех.
2) Связка Реализация - Возврат нам нужна по ним стоятся отдельные упр. отчеты для анализа.
Далее еще интересней.
У нас все возвраты приходуются на отдельный склад возвратов. Виртуальный.
То есть, возвращается на склад возвратов потом с него: или утилизация или обратно перемещение на склад готовой продукции.
То есть может выйти ситуация что(и довольно часто может быть):
- Нач. остатков нету;
- И есть только сторно движения расход.
То есть, только вводили документы «Возврат товаров от покупателя» на основании реализации, то есть в РН "Учет затрат" только сторно записи расхода.
В итоге расчет себестоимости не калькулирует этот товар. Он просто не может составить уравнение СЛУ. Так как расход есть, а прихода нету.
У нас, например, несколько складов возврата. И вот именно на одном складе была такая ситуация. Весь склад повис не скалькулировался!!!
Как можно было выкрутиться, не изменняя конфигурацию:
1) Возвращать на тот склад с которого продали, а потом перемещением на склад возвратов (лишняя нагрузка по первичке)
2) Отключить в РАУЗ разрез по складам (не подходит- нужно по складам, да и при отключенном разрезе по складам из РН «Учета затрат» уходит Склад, так же он уходит из РН «Товарах на складах». То есть, по данным регистрам нельзя ответить на вопрос: Сколько лежит товаров на таком-то склада и на такой- то организации? Можно анализировать РН «Товары в организации». Но он не по всем операциям совпадает с товарами на складах.)
Поэтому было принято решение по доработке документа Возврат товаров от покупателя.
Вносятся документы на основании реализации, то есть стандартно как и раньше. Но при проведении идет движение приход по плановой себестоимости, если себестоимсти нету на возвращаемый товар,
то выводиться сообщение и блокируется проведение. То есть, мы оставляем связку Реализация - Возврат, но при проведение Движение приход по плановой, а не сторно Движение расход по себестоимости возвращаемого документа. Что нам и нужно.
Напряг 2 закрытие 44 счета!
Во первых кто сталвиквался в традиционки в Комплексной вообще нету закрытия 44,25,26 :)
Мы писали закрытие свое 44 счета.
При переходе на РАУЗ 44 закрывает документ "расчет себестоимости". То есть, необходимость в самописном документе отпала.
Но:
Для того чтобы 44 закрылся все движение должны быть сделаны в РН "Учет затрат" по разделу учет "затраты". А это не всегда автоматизировано
Например у нас:
1) Корректировка долга. начисление премии поупателям. Проводка 44.01.1 / 62.01.
Этот документ вообще не знает что существует подсистема РАУЗ.
2)Отражение начисления НДС. Там у нас через подписку на событие так же делается проводка 44 / 19, мы так восстанавливаем НДС хитро, чтобы не включать сложный учет(отдельная тема). То же самое РАУЗ для него не существует.
3)Налоги, например, как сделать проводку 44 /68.1? В традиционке: налоги на регистры накопления никакие не задействованы в принципе, их ранее можно было смело делать ручной операцией. В РАУЗ такой фокус не проходит. Дебет 44 - это ЗАТРАТА. А это РН "УЧЕТ ЗАТРАТ"
К чему пришли:
1) Все что связано с затратами: забыть про ручную операцию. Заменять на документ "Прочие затраты"(УПП полный интерфейс: Документы - Управление производство - Прочие затраты).
2) Для документов "корректировка долга" и "Отражение начисление НДС" навешали подписки на событие, которые загоняют затраты в РАУЗ
Напряг 3 Передача материалов в эксплуатацию!
Ситуация: когда материал передается в эксплуатацию по плановой, то он при закрытии месяца он не закрывает эти суммы.
Комментарий: у всей спецодежды назначение использование - "списывать на затраты при передачи".
Ситуация в следующем:
На 44 счет он пишет подразделение, которое в шапке указано.
В РН «Учет затрат» он пишет Подразделение, которое берет из назначения использования. Из-за расхождения в счете 44 и в РН «Учет затрат» расчет себестоимости не закрывает 44.
Как выкрутились:
Разбираться глубже не стали, просто для материалов можно в течении месяца и по нулевой учитывать, поэтому, просто эти материалы из установки цен плановой себестоимости убрали. Тогда он все хорошо закрывает.
Напряг 4 Надо залезти в период до РАУЗ. Ничего не полетит???
Ответ :) ПОЛЕТИТ!!!
Нам, например, надо было в июле поправить кое что.
После правки перезалить остатки в РАУЗ не проблема. Я себе обработочку сделал, которая по тому же алгоритму, если вы переходить будете стандартно, формирует начальные остатки.
НО ...
Подсистема НДС и подсистема партионного учета
Есть две волшебные константы:
СписыватьПартииПриПроведенииДокументов
СписыватьПартииПриПроведенииДокументовБух
Настройка параметров учета - Режим учета затрат. Эти флаги увидите. Скрин не стал делать. Кто работал в УПП в традиционке про них знает без вариантов :)
Они у нас стояли. НО ХИТРАЯ 1С при перехода в РАУЗ их сбросила в ЛОЖЬ!!!
В итоге:
При перепроведении июля месяца (напомню в РАУЗ мы с августа) документ уже в подсистеме партионого учета и при продаже в подсистеме НДС (НДС начисленный) движения не делает.
В частности у нас было так:
Реализация товаров. Движение по подсистеме партионного учета не сделал, так же не сделал в подсистеме НДС. Проблема!!!
Основные средства. Идентично. Там у нас вообще хитро получилось. Идет цепочка: Поступление товаров(закладка оборудование) - Принятие к учете ОС
Мы первый документ не трогали, то есть, там отражено было по всем учетам корректно.
Просто перепровели «Принятие к учету ОС».
И что получилось:
Для процесса принятие к учету ОС в КА/УПП сложный учет НДС ведется независимо от того, включен у вас сложный учет или нет (если языком программы говорить, то задействуется РН «НДС по партиям запасов»). Так вот для документа поступления все корректно -приход в РН "НДС по партиям запасов" сформировался.
А вот когда принятие к учете перепровели, то он по РН "НДС по партиям запасов" не сделал движение и, как следствие, не сделал движения в РН «НДС по ОС, НМА» и, как следствие, книга покупок по этой хоз. операции ПУСТА.
Тут конечно вы можете сказать что-то вроде того: «Ну запустили бы обработку проведение по париям» и все.
Но:
1) Последовательность эту никто не восстанавливал никогда. Она стояла у нас далеко в прошлом. (почему это отдельная темы описывать не буду, будет много букв)
2) Даже если мне как администратору сдвинуть ее принудительно, то все равно пришлось бы перепроводить чуть ли не весь месяц. И это после того как месяц уже закрыт.
В идеале 1С-ники: или должны эти волшебные константы «загнать» в периодический регистр сведений ну, или на крайний случай, не сбрасывать их при переходе.
Как выкрутились:
Обработкой принудительно установили в Истину эти волшебные константы.
Перепровели снова Только те документы, которые перепроводились после переходы на РАУЗ и потом вернули константы назад.
Перезалили остатки в РАУЗ.
********************************************************************************************
Ну вот и все. И так много букв. Я написал самые явные напряги. При том, что это просто торговля.
Это филиал. В головной организации у нас производство. Многопередельное. С давальческой схемой и.т.п
Используем традиционный учет. Внедрена УПП.
Как подумаю сколько подводные камней там вылезет, если переходить на РАУЗ. волосы дыбом встают.
переход на РАУЗ в головной организации я буду откладывать до последнего. Тут трмозов нету. Сервера сильнее и все такое. Блокировки конечно в партионки это зло!!!
В целом результаты внедрения в РАУЗ ... впечатления ...
1) Переход на РАУЗ это далеко не тривиальная задача;
2) Тормоза ушли, блокировок нету, работать стало намного комфортней;
3) То что сейчас не надо придерживаться постулата "сначала приход потом расход" это конечно супер. Для РАУЗ минимальный разрез анализа МЕСЯЦ!!! он его смотрит весь целиком. (так же как подсистема производства в традиционки )
То есть в общем в РАУЗ работать можно. Просто нужнотеоритически подготовиться к РАУЗ и сделать выводы
- что мы потеряем, уйдя от традиционки;
- что мы поимемем, придя на РАУЗ.
Надеюсь статья будет полезна тем кто подумывает на то что перейти на РАУЗ ...
Ну и напоследок решил вставить из комментариев мои ответы на хорошие и четкие вопросы от iov, где более подробно описаны "причины перехода"
Вопрос:
Профи не интересно как профи интересно, почему решили перейти?
Ответ:
В трех словах. Это блокировки. И узкое место - это партионный учет (РН "Партии товаров на складах УУ,БУ,НУ). Долго думали. В идеале нужно было глубже капнуть по блокировкам (план запроса, профайлеры, индексы и.т.п.), но у нас в отделе 2,5 человека и специалиста именно в этом направлении нету.
Попробовали на аутсорсинг, но там у нас варианты, какие были:
1) Фрилансера. В нашем городе точно не найти. Тут на инфостарте проскакивала тема, как сдавали экзамен по 1С:Эксперт по технологическим вопросам //infostart.ru/public/122462, хотел даже в личку написать пообщаться. Сейчас даже вам не скажу, почему не написал, то ли закружился, то ли что еще.
2) Гибкие блокировки. Есть такой внедренец на рынке http://www.softpoint.ru, ИМХО контора серьезная. В свое время мы на платформе 7.7, на другом предприятии, внедряли гибкие блокировки. Эффект был существенный. Но там есть таблица общий журнал 1SJOURN и от нее не уйдешь, она блокируется постоянно при проведении. Это ограничение платформы 7.7. А в платформе 8.2 я думал можно все-таки самим повоевать (управляемые блокировки ну и.т.п.) В итоге я все-таки связался с ними, запросил коммерческое предложение. Они провели экспресс обследование и выкатили коммерческое предложение. Ценник московский :), а мы сибиряки :). К тому же, внедрение шло на филиале (просто оптово - розничная торговля), и вкладывать такую сумму было нецелесообразно.
А время поджимало, так как пользователи начинали нервничать. В итоге получилось так:
- От п.2 отказались (от гибких блокировок);
- п.1 я по этой линии вообще не работал.
В итоге:
1) или РАУЗ
2) Или попробовать аутсорсеров найти по п.1.
Решаем в пользу РАУЗ. До первого закрытия месяца. Если не устроит, откатываемся назад и дальше работаем в направлении найти грамотных аутсорсеров.
Вот как то так ...
Вопрос:
Сроки перехода. Что делала компания во время перехода? Какие управленческие решения были приняты?
Ответ:
Бизнес процессы на предприятии достаточно просты.
Мы отталкивались от следующего:
Максимально не ломать привычную работу пользователей. То есть «первичка» и отчеты должны быть остаться те же.
Сроки перехода: Получается, примерно 1,5 месяца. Никакие план графики, ничего не составляли. И как проект его не считали. Просто крупная задача.
Для всех, кроме Гл. бухгалтера, вообще практически все шло безболезненно. Каждый штатный бухгалтер/оператор/продажник/снабженец как бил первичку в своей области, так и бил. Были изменения для них, но не существенные.
По управленческим решениям: бизнес процессы на предприятии не поменялись, вся упр. отчетность осталась та же. По большому счету изменился только алгоритм калькулирования себестоимости. Один из центральных отчетов для упр. отчетности был Валовая прибыль, который в РАУЗ не работает. Показали загруженные из демо базы произвольные отчеты, где аналогичный отчет "Валовая прибыль".
То, что надо следить за установкой плановой себестоимости постарались обяснить то, что это очень важно.
Вопрос:
Как работает бухгалтерия, которая при традиционке то не может разобраться в производстве? Это все проблемы?
Ответ:
Проблем нету. Работаем уже почти год.
Но, повторюсь, у нас торговля. Все на порядок проще.
Вопрос:
Не описаны затраты на переход?
Ответ:
1) Время нашего отдела(1,5 месяца);
2) Зарплата нашего отдела;
3) Ну и нервы, без них никак.
Резюме:
Прошел уже почти год. Работаем .
Второй филиал перевели на РАУЗ. Я почему и публикацию обновил, так как сам ее прочел (освежал память).
Успехов в работе!!!.