Казалось бы, можно сделать вывод, что так и должно быть, всё продумано, и в Бухгалтерии этого просто не требуется! Однако партии есть и там и там и механизм их учёта во многом схожий. И там и там партии списываются при проведении расходующего их документа, и при списании берутся имеющиеся на остатках партии. Если после процедуры списания партий поменять информацию по остаткам партий более ранним числом, то, чтобы документ воспринял эти изменения, его потребуется вновь перепровести.
Но, скажете Вы, в Торговле-то партии учитываются на регистрах накопления, а в Бухгалтерии за их учёт отвечают регистры бухгалтерии, и это-то и есть залог успеха! Однако принципиально между этими регистрами и способом учёта партий разницы нет. При желании управленческий учёт можно с успехом вести и на регистрах бухгалтерии, а бухгалтерский наоборот — на регистрах накопления. Главное — соблюдать принцип двойной записи или создать нужное количество субконто взамен требуемым измерениям. Так что это точно не причина, чтобы не контролировать партии в Бухгалтерии.
Получается, что последовательность партий есть везде, где есть партии. И, значит, есть принцип последовательного проведения документов, оперирующих партиями. В противном случае информация по списанным партиям и себестоимости списанного товара будет не актуальна, т.е. не будет отражать действительное положение вещей.
Для окончательного ответа на вопрос, нужно ли контролировать и восстанавливать последовательность партий в Бухгалтерии, предлагаем очень простой пример. Его Вы можете повторить в демо-версии Бухгалтерии или мысленно.
Пример:
1. Создайте новый Товар1. (Так мы будем точно знать, что ещё никаких документов и остатков по этому товару нет).
2. Создайте новый документ Реализация1, отпускающий одну единицу Товара1 по цене 10 рублей. Как Вы думаете, какая себестоимость товара будет при этом списана и какая прибыль получена? Правильно, себестоимость — 0 рублей, и прибыль, соответственно, 10 рублей. Поскольку на остатках такого товара нет и истинная его себестоимость программе не известна.
3. Создайте новый документ Поступление1 днём ранее, приходующий одну единицу Товара1 по цене 5 рублей. Что после этого действия изменится с нашими показателями прибыли и себестоимости проданного документом Реализация1 Товара1? Они останутся теми же! Как определилось при проведении Реализации1, что списали Товар1 по нулевой себестоимости, так эта информация и хранится в регистрах бухгалтерии.
4. Как же актуализировать теперь эту информацию? Ну конечно! Требуется просто перепровести Реализацию1! И вот теперь всё в порядке, информация по прибыли, остаткам себестоимости и списанной себестоимости верная!
…. Но надолго ли? Исправь мы Поступление1 с 5 рублей на 6 рублей и проблема опять появляется.
А ведь специфика бухгалтерского учёта как раз такова, что документы редко когда проводятся последовательно. И корректировки проведенных документов — не исключение, а, скорее, правило.
Тут то нам и может помочь механизм контроля последовательности документов партионного учёта! Он всё видит и точно знает, что для полноты картины нужно перепровести «тот, тот и ещё вот тот документы».
Либо необходимо взять за правило перепроводить документы 🙂 с нужной периодичностью
(1) Ну-да, ну-да. И в торговле тоже тогда взять за правило. Зачем вообще эти механизмы, верно?
(2) Я прокоментировал БП, так там и так хватает примеров для восстановления последовательности, теже проценты по кредитам и займам, а если организация еще и применяет УСНО, то без «механизма восстановления последовательности» тут точно не обойтись 🙂
Не. Тут, по-моему, все сложнее…
Дело в том, что итоги по регистрам бухгалтерии получаются в разы медленнее, чем по накоплению. Поэтому простое восстановление последовательности на предприятии, где огромный документооборот, будет проходить ОЧЧЧень долго (сталкивался с этим на практике). Дело в том, что при проведении документа списания партий выполняется запрос к таблице ОСТАТКОВ по РБу. Если документ проводится неоперативно — то остатки получаются либо на конец месяца, либо на последний период записи регистра. После этого идет чтение физической таблицы РБу и вычитание оборотов из остатков. И так — по каждой проводимой позиции. Это очень и очень медленно, особенно если товарооборот огромен. Поэтому в типовую БП включена обработка «Перепроведение документов». Она снимает документы с проведения, а потом последовательно их проводит. Таким образом, используется оперативное проведение и читается только одна таблица оперативных остатков. Происходит это НА ПОРЯДОК быстрее.
Меня другое немного удивляет — такой партионный учет (на РБу) — вообще нежизнеспособное решение. А грузить себестоимость из той же торговли — этого до сих пор так и не реализовали, вроде. Нормальный выход — только УПП.
(4) Неужели снятие с проведения — это быстрее?! Бывают просто альтернативные обработки, которые перепроводят выборочно, например. И тогда при обычных нарушениях последовательности её восстановление кажется плёвым делом.
(5) все зависит от объема базы данных и количества рабочих мест
А зачем вообще перепроводить полностью? не проще в конце месяца на нужные позиции докинуть/скорректировать себестоимость…? Имхо, введение партионки в бухии — это тупиковый путь…
В БП, в отличии от УТ есть механизм «Управление датой актуальности учета». Автор упустил описание последнего. Имхо — зря.
Без описания этого механизма статья получилась = ниачём.
(7)
> Имхо, введение партионки в бухии — это тупиковый путь…
Тупиковый — нетупиковый, но клиенты хотят, чтобы все возможности пятого ПБУ были реализованы. Как говорится, любое желание за их деньги… 😉
> не проще в конце месяца на нужные позиции докинуть/скорректировать себестоимость…?
Конечно проще, для конкретной организации с простым учетом. В общем случае — имхо не так просто…
(8) «Дата актуальности учёта» — совсем из другой оперы. Просто с этой даты документы проводятся не полностью — делают не все проводки и движения, какие бы делали обычно. Для ускорения оперативной работы. А начали новый период готовить — будьте добры, сдвигайте дату и перепроводите все документы заново. Вот так экономия!
По сути, это некий аналог функционала УТ «проводить/не проводить по партиям при проведении документа».
Хм… И зачем утверждать, что без описания сего замечательного механизма — статья «ниачём»?! 🙂
как на счет конкурса:
«Как бы я сбацал ФИФО на 8.1»
?
(11) Хорошая идея! Можно оформить, как отдельный блог. В нём оговорить ограничения (только ФИФО и т.п.) и прочие условия. И вперед.
🙂 спасибо, сейчас замутю 🙂
1. ФИФО
2. Партия = ПНК
3. Конфигурация: контрагенты , товар , ПНК , РНК, отчетик по себестоимости, предмет конкурса — структура объектов (регистров) и тексты модулей, обеспечивающих ФИФО.
Критерии успеха: 1 — скорость, 2 — понятность для юзера вплоть до «посмотрел регистр — всё увидел».
замутил
Я так понимаю , что здесь приведено обоснование ввода последовательностей в следующей за БП 1.6 конфигурации .
В тестовой БП 2.
(15) Если введут, то хорошо. Собираются?
Когда статья писалась — тестовой БП 2 ещё даже в планах не было.
(16) Ага , посмотрел БП 2 — есть ОДНА последовательность.
А вот будет ли это хорошо- воздержусь от суждений.
(14) А почему удалил ? Очень интересно.
Ты бы предложил бы свой проект » Как я вижу ФИФО в 8.1″ .
Это интересней , чем мутные обсуждения «жизни без последовательностей».