Внедряя или обслуживая 1С, многие сталкиваются с проблемой расчета себестоимости – то копейки зависают, то вообще непонятно какой порядок формирования себестоимости. И тут, судя по комментариям на форумах, вспоминают про волшебный документ корректировки регистров.) Я являюсь ярым противником применения этого документа и соглашаюсь на него только в случае, когда нужно свернуть базу. Поэтому, читая статьи и видя обработки по их применению для корректировки регистров партий, первым делом мне хочется написать огромными буквами – «Муля, НЕ НЕРВИРУЙ меня!!!». Мои партнеры, программисты-внедренцы 1С, об этом в курсе и даже подшучивают – «Шепотом скажи «корректировка регистров» и очень быстро беги как можно дальше!». Но это сугубо мое мнение. Предвижу после прочтения море возмущения – «Да в 1С баг на баге в расчете себестоимости!», «1С-ники в каждом новом релизе или обновлении вместо того, чтобы исправить старые ошибки добавляют кучу новых!» и в том же духе. Даже в мыслях не возникает желание оспаривать это.))) Но хочу заверить, что все это устранимо своими силами, если в этом разобраться.
Также хочу отметить, что простое перепроведение документов не всегда все проблемы решает. Большинство ошибок исправляется соблюдением логики последовательности проведения документов, а также, что немало важно, правильным их оформлением. Причем под правильным оформлением имеется ввиду не только логика работы, но и логика самой системы, так как иногда система позволяет сделать всякие вещи, которые потом вылетают неявным «боком». Конечно же, кое-что приходится править в самом коде, но с большой осторожностью и пониманием возможных последствий. И вот почему:
С 2009 года ежедневно занимаюсь приведением в порядок регистров партий в разрезе складов, характеристик, качества (в УТ3, аналог УТ11 для Украины, добавилось еще и такое – Вид запасов и Аналитика учета партий). Имея опыт работы в УТ2, УТ11, УТ3 и какое-то понимание в финансовом учете, я хочу немного рассказать о последствиях его применения.
Программисты-внедренцы, исправляя ошибки корректировками регистров в регистрах партий гарантировано в довесок к своей работе получают следующее:
-
При написании любого отчета, использующего данные из этих регистров, они должны постоянно помнить о документах корректировки.
-
При обмене или переносе данных снова должны учитывать эти документы.
-
При работе с мобильным приложением так же могут возникнуть сложности.
-
Обновили базу, а 1С «забыла» указать, что исправила кое-какие ошибки в расчете себестоимости. Вдруг понадобилось по какой-то причине перепровести документы прошлым периодом. Со спокойной совестью это делаем, закрываем месяца и тут «вдруг» ошибки в расчете себестоимости. Возникает паника — «Откудааааа?» и судорожно начинаем искать причину, успешно забыв про документы корректировки регистров годичной давности, например.
-
Кто еще что-то может дополнить – буду рада прочитать в комментариях.
Заказчик, который соглашается на документы корректировки регистров, или клиент, который уже имеет в своей базе эти документы, должен понимать, что в результате будет иметь простую, если в двух словах, но очень важную в работе его компании, цепочку последствий:
Документ корректировки регистров партий => Неверно рассчитанная себестоимость => Недостоверные данные при расчете большей части финансовой отчетности => Некорректные данные большинства финансовых показателей предприятия => Принятие неверных управленческих решений => И, как результат, возможно возникновение вопроса, – «по всем показателям у нас все прекрасно, но ГДЕ ДЕНЬГИ?».
То есть, последствия растут как снежный ком и достигают катастрофических размеров.
Поэтому я просто советую, прежде, чем применять документ корректировки регистров партий задайте себе один простой вопрос – «А надо ли мне это «счастье»?».
Предлагаю несколько практических решений, основанных на опыте ежедневного выравнивания последовательностей и закрытия месяцев, для решения проблем с расчетом себестоимости в УТ3 (аналог УТ11 для Украины). Возможно, кому-то они пригодятся и для УТ11. В базе ежедневно около 100 пользователей (+50 торговых, набивающих заказы с мобильной 1С) и порядка 1000-1500 только документов заказов покупателей (а добавьте теперь к этому реализации, приходные кассовые, расходные ордера и прочее-прочее).
Для начала хочу обратить Ваше внимание на несколько условий, без которых эти решения не будут работать:
-
Обязательно ежедневная установка даты запрета редактирования партионных документов «задним» числом.
Как показала практика, это начинает работать и прекращаются жалобы где-то месяца через три-четыре после перехода в новую базу. Через год у сотрудников заказчика даже не возникает желание что-то править в прошлых периодах, потому что они уже начинают понимать последствия этих изменений – перерасчет себестоимости, изменение финансовых показателей, а у многих и перерасчет заработной платы.
Живой пример: Наш клиент с 2009 года. Были ситуации, когда не представлялось возможным пару-тройку дней закрывать период. Первый разы переживала – «70 магазинов… Вот же ж сейчас мне начудят… Придется потратить кучу времени на нудную работу…». Каково же было мое удивление, когда все оказалось в порядке и выравнивание последовательностей заняло ровно столько времени, сколько и раньше. То есть, сотрудники, зная о том, что прошлый период открыт, не рискнули где-то что-то «ковырнуть» задним числом. Все последующие разы и новые проекты по внедрению только укрепили мое мнение о том, что ежедневное закрытие периода работает и это возможно.
-
Своевременное и правильное заполнение первичной документации. Этот пункт, понятно, нужен для того, чтобы можно было осуществить п.1.
-
Внести изменения в документы в прошлых периодах могут только несколько ответственных лиц, которые четко понимают, что надо сделать, чтобы минимизировать последствия и как их устранить. Можем считать его как исключение для п.1.
-
Совет – закрывать месяц(-а) каждый день. Это кто и как посчитает нужным, но так меньше проблем и, соответственно, уходит меньше времени на исправление ошибок, так как иногда приходится перенести что-то куда-то, и тогда плывут цифры в разрезе недели, например.
Итак, у Вас возникли ошибки при закрытии месяца при расчете себестоимости в УТ3. В чем могут быть причины:
-
Отрицательные остатки по регистру «Товары организаций».
Как все понимают, в этом случае необходимо исправить все «минуса» с учетом всех разрезов (организаций, видов запасов, УКТВЭД и ГТД (УТ3), характеристик, качества). Это позволит устранить большинство ошибок, потому что данные из этого регистра берутся для расчета «Партий товаров организаций», «Себестоимость товаров», «Партии расходов на себестоимость товаров» и т.д.
Предостережение: при возникновении отрицательных остатков по видам запасов при закрытии месяца (в УТ3) не советую использовать встроенные механизмы. Проблем будет еще больше. Лучше ручками просто еще раз провести проблемные документы. Обычно все сразу становится на место.
-
Если, все же, ошибки остались, то причин может быть несколько:
-
Иногда «слетают» или «задваиваются» движения по регистру «Партии товаров организаций» некоторых документов поступления товара (ввод начальных остатков, поступление товаров и услуг, оприходование излишков товара, прочее оприходование товара). Обычно данная проблема возникает, если при закрытии месяца программа вылетела в ошибку. В этом случае достаточно перепровести данные документы, которые были в том месяце, при закрытии которого возникла ошибка при расчете себестоимости, распровести документ «Расчет себестоимости» и закрыть месяц заново.
-
Не проставлен документ основания в возврате товара от покупателя.
-
В возврате товаров от покупателя несколько документов оснований. В этом случае необходимо такие документы разбить на несколько – обычно, на количество документов оснований. То есть, под одну заявку на возврат от покупателя будет несколько возвратов.
-
Те же проблемы, что и в пункте «а», могут возникать с поступлениями доп. расходов (ТЗР и т.д.). Решается аналогично.
-
Как показала практика — это позволяет устранить 99% ошибок, которые возникают при расчете себестоимости. Оставшийся 1% — это частные случаи, которые решаются в индивидуальном порядке. Например, ошибки при расчете себестоимости комиссионного товара после проведения отчета комиссионера (УТ3). Это вообще тема для отдельной статьи.) Мы с моим напарником, программистом-внедренцем, потратили довольно прилично бессонных ночей на нахождение и исправление 4-х ошибок в коде именно по этому документу. Хотя, нам ничего не мешало просто ввести документ корректировки и забыть про это, как про страшный сон!
Как видите, все решаемо и без документа корректировки регистров, хоть и не всегда быстро. Если следить за всем этим каждый день, то сложностей не должно быть. У меня ежедневное закрытие месяца в УТ3 занимает на данные момент 0,5-1,5 часа со всеми «шаманствами» в виде переноса непроведенных документов, контроля отрицательных остатков и т.д. Если крайне необходимо закрыть месяца за больший период, то и тут мы выработали свою методику, которая, например, позволяет закрывать год за 3,5 – 4 часа. И это при огромном документообороте. С другой стороны, если пользоваться простой кнопкой «Выполнить операции» в обработке закрытия месяца, то это может занять 8, а то и 10 часов!
И, напоследок, хочу предупредить, что даже, если обработка по закрытию месяца показала Вам, что все операции выполнены успешно, то это еще не означает, что у Вас все в порядке. В УТ3, например, из-за того, что в регистр «Расчеты с клиентами по документам» не попадает НДС в регламентной валюте (в нашем случае регламентная отличается от управленческой), точка актуальности партий может откатываться на дату проблемного документа поступления товаров и услуг, которая может быть и годичной давности. И откатываться она будет при каждом срабатывании регламентного задания «Выполнение отложенных движений по расчетам с клиентамипоставщиками». Так же у Ваших клиентов могут строиться долго или показывать неверные данные отчеты, например, по задолженности клиентов или по срокам задолженности из-за того, что у «Заказа клиента» и «Реализации товаров и услуг» по этому заказу могут быть разные аналитики учета по партнерам или вообще отсутствовать. Так что, проблем предостаточно, но решать их «как бы побыстрее и полегче» не стоит. Слишком высокой может быть цена – Ваша репутация.
P.S. Отдельно хочу передать большой привет и огромное спасибо разработчикам УТ3 за то, что не оставляют нас и наш ум без работы!). Помимо этого счастья по товарному учету, у меня еще много «Когда? Зачем? Почему?» по финансовому. Но это отдельная тема. И, несмотря на это, я прекрасно понимаю, что 1С (в частности УТ3) — это, при правильном подходе, один из мощных инструментов для управленческого учета и контроля для бизнеса, например, малого и среднего.
Согласен, что корректировка регистров не способ править ошибки учета. Но, например, в ERP есть недоработки программы , которые без корректировки не решить. И сама служба поддержки 1с предлагает решать некоторые проблемы с помощью корректировок.
(1) Приведу простой пример — отчет комиссионера о продажах в УТ3. Подробнее можно здесь . Вроде как все, предел, дальше только корректировка регистров… Я сопротивлялась как всегда) В результате придумали способ обойти эту проблему — создать возврат товара от комиссионера на виртуальный склад с перечнем проданного товара и провести обычную реализацию. С помощью небольших ухищрений можно соблюсти все условия комиссионного соглашения. Да, это не лучший способ, но это не корректировка регистров! Но, слава богу, обошлось и без этого. К чему я все это — корректировка регистров самая крайняя мера, а не способ избавить себя от головной боли. Ну а разработчикам, которые рекомендуют ее применять — жирный минус от меня лично). Потому что для меня это равносильно взятию «греха на душу».
Автора поддерживаю.
Сам стремлюсь к тому, чтобы операции, приводящие к проблемам — не могли выполняться.
Самый действенный способ — невозможность сделать нужное при наличии ошибок в учете.
(3) вот тут и кроется самое печальное в текущих конфигурациях, которые сделаны на базе ERP — это то что большую часть проблем можно выявить только пост фактум, увы…
А если ставить много защит — то все будет дико тупить 🙁
(4) Дима, ну тут два варианта — тупизм заразителен.. поэтому если тупят юзвери то тупят и компы.
а многовариантность и альтернативность — зло для прог оперативного контура.
выпилил несколько сценариев по бизнес-процессу и вперед — результат надежен и предсказуем. все регламенты сводятся к нажать кнопочку и получить результат.
(5) Сергей, ну я тут согласен, но иногда бизнесс проыессы не позволяют этого делать, а иногда этот абсурд заложен самими разработчиками, причем пипец как глубоко, взять то же отчет комисионера о продажах, он по партиям делает движение датой указанной как дата окончания отчетности, а по складам — датой документа.
И все, пипец, мало того, что если даты отличаются, то оно тупо ничего не рассчитает, так как там механизм нативно заточен на то, что даты в партиях товара и в товарах организации должны быть одним днем, так и еще по сути позволяет юзверю нарушить партии хоть 10 летней давности.
В данном случае мы конечно тупо запретили менять дату окончания отчета и ставим ее всегда равной дате документа, но блин, вот тебе сама 1с дала доступ ковырять задний период и ломать что вздумается.
А сама проблема то еще глубже.
Но видь бывают случаи — когда такого сделать нельзя, нельзя тупо запретить дату и все, взять в пример тот же документ взаиморасчетов, в котором надо было пачку проверок приделать, а то они творили фиг знает что, но увы, есть варианты, когда такого сделать нельзя, ибо бизнесс процесы 🙁
(5)
— не совсем так. Например, остатки контролируются на конец дня => приход товара может быть позже, чем расход => минус по товарам организаций => не корректно рассчитывается с/ст. Все равно надо контролировать. Я думаю, что нужна золотая середина — что-то контролирует и ограничивает сама 1С, что-то можно правами, что-то датой запрета изменения данных, а что-то серьезное нужно просто запретить. Ну и мы еще занимаемся разъяснительной работой, почему правильно будет так, а не по другому — это то же играет немаловажную роль.
<<Если крайне необходимо закрыть месяца за больший период, то и тут мы <<выработали свою методику, которая, например, позволяет закрывать год за <<3,5 – 4 часа.>>
А что же очень секретная методика ? 🙂
(8) да ничего тайного))) В планах выложить этот секрет, но чуть попозже) Просто хотелось понять — интересно ли это вообще публике. 🙂
(9) Очень интересно
(10) значит напишем)
(4) Так нужно их ставить думая.
«Срочно, нам прям сейчас, остатки по декларации не бьются, иначе проблемы с таможней»
Слишком поздно я прочитал эту статью…
(13) что так?
(14) «Накорректировал» лопух. С работающем всеми любимым «Интеркомпани» после обновления на УТ 11.4.2.144 и при попытки проведения РТиУ выдал такое с утра)))
(15)ясно)))) модель расчета с/ст меняли? Если да, то ТЗР все равно должны быть в одном месяце с приобретением. Иначе подвисает сумма в контроле распределения. На расходы как бы падает, но хвостик одной суммой, который должен был упасть на номенклатуру, которая была продана в прошлом месяце. То есть без распределения на нее. Если ставить галку распределять на прошлые периоды, то тоже как-то странно отрабатывает.
«Слетают» по причине того, что вначале удаляются все движение по регистру, а далее программа пытается их заново заполнить. Но вот почему «задваиваются» движения? Этот вопрос остается открытым.
(17)
(17)
В статье описаны проблемы с расчетом себестоимости УТ3 (аналог УТ11). В этом случае задваивание происходит из-за ошибки в тексте запроса 1С. Особенно, если это касается товара, отданного под реализацию.
В новых версиях УТ11 с моделью расчета себестоимости по версии 2.2 такого замечено не было.
(18)
Товара отданного под реализацию нет. Думаю, что дело не в запросе, потому как способ, который Вы описали
помогает.
Сложность только в том, что приходится контролировать такие ситуации. Дополнительные затраты времени на обслуживание программы. И причину возникновения этой ошибки пока найти не получается (речь идет о конфигурации УТ3).
(19) Такое возникает только тогда, когда при закрытии месяца программа вылетает в ошибку. И да, это нужно контролировать. В нашем случае у нас каждый день закрывается месяц регламентом, а потом контроль, исправление и новое закрытие ручками. К сожалению, другого способа не нашли. Минимизировали эту проблему переходом на 64х битный SQL и пользователи таки научились правильно работать — соблюдать логику документооборота, запрет на редактирование задним числом партионных документов, вносить правильно первичку, работать без отрицательных остатков. На данный момент ежедневное закрытие месяца занимает около часа.
Еще новая фишка 1с. Константа версии партионного учета 1С. Пии редактировании выбирается дата начала действия.
Отличие версии партионного учета 2.2 от 2.1:
Основным отличием является то, что разработчики уже в очередной раз отказались от использования группы регистров, отражающих движения партий товаров: «ПартииТоваровОрганизаций», «ПартииТоваровПереданныеНаКомиссию», «ПартииРасходовНаСебестоимостьТоваров», «ПартииПроизводственныхЗатрат», «ПартииЗатратНаВыпуск». Расчет теперь выполняется исключительно по одному регистру учета «Себестоимость товаров».
В регистре «Себестоимость товаров» для реализации полноценного партионного учета «ФИФО (скользящая оценка)» теперь добавились дополнительные измерения: «Партия» и «АналитикаУчетаПартий». Для метода оценки: «ФИФО (взвешенная оценка)» и «Средняя за месяц» новые измерения остаются не заполненными.
(21) Добавлю , что в КА2.4 стало считать себестоимость совершенно некорректно
И учетной политике в запасах «метод оценки стоимости товаров» = ФИФО
В случае 2 последовательных приобретений товаров (скажем 1 числа и 2 числа) после реализации товара списывается как и положено партия от 1 числа.
При дальнейшей Корректировки приобретения поступления от 1 числа обязательно в последующем месяце, когда месяц с реализацией уже закрыт (см Реестр торговых документов.jpg),
в регистре «Себестоимость товаров» некорректно списываются партии в процессе расчета себестоимости при закрытии месяца, в котором проведена Корректировка и
выдается ошибка в обработке Закрытие месяца в закладке «Расчет себестоимости»
с текстом «Обнаружены отрицательные остатки партий в регистре себестоимости по организации «……..» на конец периода ….». (см Ошибка расчета себестоимости.jpg и Регистр Себестоимость товаров.JPG)
Закрытие месяца – невозможно!?
При включении опции Обособленный учет себестоимости «По видам запасов» в тестовой базе закрытие месяца происходит без ошибок и
движения Корректировки приобретения в регистре Себестоимость товаров становятся правильными. (см Корректный расчет себестоимости.jpg)
Но в рабочей базе мы не имеем возможности включить эту опцию, так как это требует перепроведения всех документов! Да и не нужна нам она….
Показать
Подскажите как решить подобную проблему …