Комплексная 1.1 РАУЗ списание себестоимости при проведении РТиУ
Добрый день, коллеги. Следующая ситуация. КА 1.1.99.1.
Был включен партионный учет и вел он себя очень интересно. При включенном контроле остатков при проведении РТиУ документ проводился частично! оО Можете спорить со мной сколь угодно, но это факт! По БУ и УУ делались движения только на те суммы и количество товаров по которым хватало остатков. Если остатка не хватает выдает сообщение, но при этом документ проводится.
Нашел, статью в интернете, что и правда КА 1.1 себя так ведет при партионном учете. Ок, решил включить РАУЗ, перепровел все документ, все вроде хорошо. РТиУ делает списание только по количеству, а себестоимость списывается потом документом "Расчет себестоимости". Начал проверять 41 счет и наткнулся на "красные" копеечки. Залез глубже и вижу что некоторые документы при проведении все же списывают по некоторым позициям себестоимость равную продажной стоимости, а документ "расчет себестоимости" потом делает корректировку минусом до правильной себестоимости.
Вопрос: так и должно быть? Если нет, то почему РТиУ где то все же списывает себестоимость?
З.Ы. Пытался поймать движения по отладке. Не получилось найти место где это делается, банально не могу увидить сформированные в процедуре "ОбработкаПроведения" движения.
Был включен партионный учет и вел он себя очень интересно. При включенном контроле остатков при проведении РТиУ документ проводился частично! оО Можете спорить со мной сколь угодно, но это факт! По БУ и УУ делались движения только на те суммы и количество товаров по которым хватало остатков. Если остатка не хватает выдает сообщение, но при этом документ проводится.
Нашел, статью в интернете, что и правда КА 1.1 себя так ведет при партионном учете. Ок, решил включить РАУЗ, перепровел все документ, все вроде хорошо. РТиУ делает списание только по количеству, а себестоимость списывается потом документом "Расчет себестоимости". Начал проверять 41 счет и наткнулся на "красные" копеечки. Залез глубже и вижу что некоторые документы при проведении все же списывают по некоторым позициям себестоимость равную продажной стоимости, а документ "расчет себестоимости" потом делает корректировку минусом до правильной себестоимости.
Вопрос: так и должно быть? Если нет, то почему РТиУ где то все же списывает себестоимость?
З.Ы. Пытался поймать движения по отладке. Не получилось найти место где это делается, банально не могу увидить сформированные в процедуре "ОбработкаПроведения" движения.
Найденные решения
РАУЗ в УПП и КА работает хитрым образом.
1) Будет ли при списании/продаже суммовая проводка (и движение в регистре УчетЗатратРегл по сумме) зависит от учетки. Есть там (в разделе запасов кажись) пункт о способе оценки при списании МПЗ. Вариант по прямым затратам означает что при проведении "на лету" программа попытается вычислить стоимость в момент проведения, если не найдет стоимость будет нулевой и выдастся сообщение (типа не движение без стоимостной оценки). Вариант 2 - по плановым ценам. Тут просто, если плановая цена на позицию задана, стоимость будет по плановой цене, иначе 0. И последний вариант "по нулевой" - говорит сам за себя. При любом раскладе расчетом себестоимости сумма догоняется до факта.
2) Проблема зависших копеек в ОСВ чаще всего связана с документами доп. расходов (особенно если доп.расходы валютные). Если сумма доп.расходов указана в шапке (а не распределена спец.кнопкой по строкам документа) распредление суммы расходов производится в момент проведения. И из-за разных алгоритмов распределения для проводки и движения в регистр учет затрат может получится разные суммы в движениях. Например, в проводку на 41-й счет придет 99.99р расходов, а в регистр 100 р. Списание позиции идет от регистра. Стало быть при продаже спишется 100р и в регистр и в проводку. Вот и копейка разницы в ОСВ...
3) По поводу ловли процедуры движения. Хитрость в том, что движение по регистру "УчетЗатратРегл" делается не в модуле документа, а в модуле регистра. причем как именно будет формироваться движение прописывается в макете регистра. Фиг отловишь короче)
1) Будет ли при списании/продаже суммовая проводка (и движение в регистре УчетЗатратРегл по сумме) зависит от учетки. Есть там (в разделе запасов кажись) пункт о способе оценки при списании МПЗ. Вариант по прямым затратам означает что при проведении "на лету" программа попытается вычислить стоимость в момент проведения, если не найдет стоимость будет нулевой и выдастся сообщение (типа не движение без стоимостной оценки). Вариант 2 - по плановым ценам. Тут просто, если плановая цена на позицию задана, стоимость будет по плановой цене, иначе 0. И последний вариант "по нулевой" - говорит сам за себя. При любом раскладе расчетом себестоимости сумма догоняется до факта.
2) Проблема зависших копеек в ОСВ чаще всего связана с документами доп. расходов (особенно если доп.расходы валютные). Если сумма доп.расходов указана в шапке (а не распределена спец.кнопкой по строкам документа) распредление суммы расходов производится в момент проведения. И из-за разных алгоритмов распределения для проводки и движения в регистр учет затрат может получится разные суммы в движениях. Например, в проводку на 41-й счет придет 99.99р расходов, а в регистр 100 р. Списание позиции идет от регистра. Стало быть при продаже спишется 100р и в регистр и в проводку. Вот и копейка разницы в ОСВ...
3) По поводу ловли процедуры движения. Хитрость в том, что движение по регистру "УчетЗатратРегл" делается не в модуле документа, а в модуле регистра. причем как именно будет формироваться движение прописывается в макете регистра. Фиг отловишь короче)
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Не припоминаю, есть ли в КА 1.1 Отчет движения документа. Если нет, то его можно внедрить в конфигурацию.
РАУЗ в старых конфигурациях работает по периоду месяц. Корректировка себестоимости происходит кроме Расчета Себестоимости еще в ЗакрытииМесяца.
Закрытие месяца создает временные записи в регистре сведений что-то типа "УзлыКорректировкиСтоимостиСписания", а после очищает регистр.
Документ реализации указывает предварительную себестоимость в регистре, если он может это сделать. Если есть, например переход из месяца в месяц или нарушение последовательности, то это корректируется Закрытием Месяца.
РАУЗ в старых конфигурациях работает по периоду месяц. Корректировка себестоимости происходит кроме Расчета Себестоимости еще в ЗакрытииМесяца.
Закрытие месяца создает временные записи в регистре сведений что-то типа "УзлыКорректировкиСтоимостиСписания", а после очищает регистр.
Документ реализации указывает предварительную себестоимость в регистре, если он может это сделать. Если есть, например переход из месяца в месяц или нарушение последовательности, то это корректируется Закрытием Месяца.
РАУЗ в УПП и КА работает хитрым образом.
1) Будет ли при списании/продаже суммовая проводка (и движение в регистре УчетЗатратРегл по сумме) зависит от учетки. Есть там (в разделе запасов кажись) пункт о способе оценки при списании МПЗ. Вариант по прямым затратам означает что при проведении "на лету" программа попытается вычислить стоимость в момент проведения, если не найдет стоимость будет нулевой и выдастся сообщение (типа не движение без стоимостной оценки). Вариант 2 - по плановым ценам. Тут просто, если плановая цена на позицию задана, стоимость будет по плановой цене, иначе 0. И последний вариант "по нулевой" - говорит сам за себя. При любом раскладе расчетом себестоимости сумма догоняется до факта.
2) Проблема зависших копеек в ОСВ чаще всего связана с документами доп. расходов (особенно если доп.расходы валютные). Если сумма доп.расходов указана в шапке (а не распределена спец.кнопкой по строкам документа) распредление суммы расходов производится в момент проведения. И из-за разных алгоритмов распределения для проводки и движения в регистр учет затрат может получится разные суммы в движениях. Например, в проводку на 41-й счет придет 99.99р расходов, а в регистр 100 р. Списание позиции идет от регистра. Стало быть при продаже спишется 100р и в регистр и в проводку. Вот и копейка разницы в ОСВ...
3) По поводу ловли процедуры движения. Хитрость в том, что движение по регистру "УчетЗатратРегл" делается не в модуле документа, а в модуле регистра. причем как именно будет формироваться движение прописывается в макете регистра. Фиг отловишь короче)
1) Будет ли при списании/продаже суммовая проводка (и движение в регистре УчетЗатратРегл по сумме) зависит от учетки. Есть там (в разделе запасов кажись) пункт о способе оценки при списании МПЗ. Вариант по прямым затратам означает что при проведении "на лету" программа попытается вычислить стоимость в момент проведения, если не найдет стоимость будет нулевой и выдастся сообщение (типа не движение без стоимостной оценки). Вариант 2 - по плановым ценам. Тут просто, если плановая цена на позицию задана, стоимость будет по плановой цене, иначе 0. И последний вариант "по нулевой" - говорит сам за себя. При любом раскладе расчетом себестоимости сумма догоняется до факта.
2) Проблема зависших копеек в ОСВ чаще всего связана с документами доп. расходов (особенно если доп.расходы валютные). Если сумма доп.расходов указана в шапке (а не распределена спец.кнопкой по строкам документа) распредление суммы расходов производится в момент проведения. И из-за разных алгоритмов распределения для проводки и движения в регистр учет затрат может получится разные суммы в движениях. Например, в проводку на 41-й счет придет 99.99р расходов, а в регистр 100 р. Списание позиции идет от регистра. Стало быть при продаже спишется 100р и в регистр и в проводку. Вот и копейка разницы в ОСВ...
3) По поводу ловли процедуры движения. Хитрость в том, что движение по регистру "УчетЗатратРегл" делается не в модуле документа, а в модуле регистра. причем как именно будет формироваться движение прописывается в макете регистра. Фиг отловишь короче)
(4)
А что делать далее, как добиться суммовой проводки? В какой момент она появится? Так же ситуация возникает при оформлении возвратов (корректировка реализации).
) Будет ли при списании/продаже суммовая проводка (и движение в регистре УчетЗатратРегл по сумме) зависит от учетки. Есть там (в разделе запасов кажись) пункт о способе оценки при списании МПЗ. Вариант по прямым затратам означает что при проведении "на лету" программа попытается вычислить стоимость в момент проведения, если не найдет стоимость будет нулевой и выдастся сообщение (типа не движение без стоимостной оценки)
А что делать далее, как добиться суммовой проводки? В какой момент она появится? Так же ситуация возникает при оформлении возвратов (корректировка реализации).
(6) По какому принципу будет формироваться суммовая проводка расписано в моем посте выше. Все варианты когда стоимость пишется сразу в документе расхода - (по плановым ценам и по прямым затратам) - рисуют предварительную стоимость (она почти всегда неполная, не учитывает взвешенную оценку по средней и т.п.), окончательная - только в результате документа расчет себестоимости (где программа "догонит" суммы).
С возвратами есть отдельная фишка. Воспроизвожу по памяти... Программа не знает по какой себестоимости была продажа в конкретном документе РТУ (ну не связана сеебстоимость с документом продажи). Когда использовали документ возврата от покупателя там была возможность либо указать в табличной части документ партии (РТУ), либо вручную указать себестоимость возврата. Со вторым вариантом все ясно (сумма возврата фиксирована в документе). Если же указывали документ партии - то программа при проведении расчета себестоимости пыталась вычислить себестоимость продажи товара в месяце первичной реализации и именно эту сумму докидывала возврат на склад. Если же пользователь лажал и не указывал ни документ партии, ни ручную себестоимость, то программа пыталась вычислить стоимость продажи этого товара в текущем месяце возврата (на этапе расчета себестоимости) и если позицию в месяце возврата не продавали - сумму вообще не писала, в результате не склад возвращался безценный товар.
С корректировками реализации вроде все было проще (там нет вариантов указания себестоимости вручную и нет возможность забыть партию продажи) все работает только по партии возврата (РТУ-основание). По идее по аналогии программа должна вычислять стоимость продажи в месяце первичной реализации и именно по этой цене возвращать. Проводку по возврату сделает в документе расчета себестоимости (не проверяла на варианте по прямым затратам, так как редко его использую, может в этом режиме и попробует сделать сумму сразу)
С возвратами есть отдельная фишка. Воспроизвожу по памяти... Программа не знает по какой себестоимости была продажа в конкретном документе РТУ (ну не связана сеебстоимость с документом продажи). Когда использовали документ возврата от покупателя там была возможность либо указать в табличной части документ партии (РТУ), либо вручную указать себестоимость возврата. Со вторым вариантом все ясно (сумма возврата фиксирована в документе). Если же указывали документ партии - то программа при проведении расчета себестоимости пыталась вычислить себестоимость продажи товара в месяце первичной реализации и именно эту сумму докидывала возврат на склад. Если же пользователь лажал и не указывал ни документ партии, ни ручную себестоимость, то программа пыталась вычислить стоимость продажи этого товара в текущем месяце возврата (на этапе расчета себестоимости) и если позицию в месяце возврата не продавали - сумму вообще не писала, в результате не склад возвращался безценный товар.
С корректировками реализации вроде все было проще (там нет вариантов указания себестоимости вручную и нет возможность забыть партию продажи) все работает только по партии возврата (РТУ-основание). По идее по аналогии программа должна вычислять стоимость продажи в месяце первичной реализации и именно по этой цене возвращать. Проводку по возврату сделает в документе расчета себестоимости (не проверяла на варианте по прямым затратам, так как редко его использую, может в этом режиме и попробует сделать сумму сразу)
(7)
Спасибо за внимание к теме.
Как раз проблема с себестоимостью, если корректировка реализации не в одном месяце с продажей.
Проводка формируется с пустой суммой. Если так и оставить, расчет себестоимости в конце месяца ругается на отрицательные остатки по разделу МПЗ. Приходится делать Корректировку записей регистров, дописывать себестоимость в проводки и движения.
1С отвечает по этому вопросу:
"УПП в режиме РА не сможет корректно рассчитать стоимость товара если: 1. У него не было начальных остатков. 2. Он появился на складе при сторнировании (корректировке реализации) прошлого периода. Если у вас происходит полная отмена факта реализации. Попробуйте сделать сторно документа."
Видимо, надо дописывать движения документа...
С корректировками реализации вроде все было проще (там нет вариантов указания себестоимости вручную и нет возможность забыть партию продажи) все работает только по партии возврата (РТУ-основание). По идее по аналогии программа должна вычислять стоимость продажи в месяце первичной реализации и именно по этой цене возвращать. Проводку по возврату сделает в документе расчета себестоимости (не проверяла на варианте по прямым затратам, так как редко его использую, может в этом режиме и попробует сделать сумму сразу)
Спасибо за внимание к теме.
Как раз проблема с себестоимостью, если корректировка реализации не в одном месяце с продажей.
Проводка формируется с пустой суммой. Если так и оставить, расчет себестоимости в конце месяца ругается на отрицательные остатки по разделу МПЗ. Приходится делать Корректировку записей регистров, дописывать себестоимость в проводки и движения.
1С отвечает по этому вопросу:
"УПП в режиме РА не сможет корректно рассчитать стоимость товара если: 1. У него не было начальных остатков. 2. Он появился на складе при сторнировании (корректировке реализации) прошлого периода. Если у вас происходит полная отмена факта реализации. Попробуйте сделать сторно документа."
Видимо, надо дописывать движения документа...
Прикрепленные файлы:
(8) АП
Похоже исправили в последнем релизе УПП:
Номер версии 1.3.126.1 Дата выхода 27.09.19
В документ "Корректировка реализации" добавлен механизм расчета ручных и автоматических скидок. Добавлена возможность указать себестоимость партии вручную (для корректного расчета себестоимости при использовании РАУЗ).
Надо тестировать
Похоже исправили в последнем релизе УПП:
Номер версии 1.3.126.1 Дата выхода 27.09.19
В документ "Корректировка реализации" добавлен механизм расчета ручных и автоматических скидок. Добавлена возможность указать себестоимость партии вручную (для корректного расчета себестоимости при использовании РАУЗ).
Надо тестировать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот