1с конфигурация поставщика отличается от основной. Восстановление конфигурации поставщика

Таблица №1

3) составить ведомость расчета изменения норм в незавершенном производстве отдельно по изделию «А» и по изделию «Б» - таблица 2

Ведомость расчета изменений норм в незавершенном производстве на начало месяца по изделию

Таблица № 2

4) составить ведомость распределения расходов по организации производства и управлению таблица 3.

Ведомость распределения расходов по организации производства и управлению

Таблица № 3

6) Произвести оценку выпущенной продукции по нормативной себестоимости в ведомости расчета нормативной себестоимости выпуска продукции таблица 4. Данные этого расчета используются для заполнения ведомости учета затрат.

Ведомость расчета нормативной себестоимости выпуска продукции

Таблица 4.

7) Заполнить отчетные калькуляции отдельно по изделию «А» и по изделию «Б» - таблица 5 на основании нормативной калькуляции и ведомости учета затрат на производства.

Отчетная калькуляция на изделие «А» и «Б»

Таблица 5

Данные для выполнения

1. Нормативная калькуляция, руб.

2. Остатки незавершенного производства на начало месяца, тыс. руб.

6) Выписка из ведомостей распределения материалов и заработной платы руб.

4. Расходы по организации производства и управлению, руб.

5. Выпущено из производства изделий «А» - 400 штук, изделий «Б» - 350 штук.

«Стандарт-кост»

Компания использует систему «Стандарт-кост» в своем подразделении по производству изделий из стекла. Нормативные затраты на производство одного изделия следующие:

Прямые материалы 60 кг * 1 у.е. = 60 у.е.

Прямые трудозатраты 3 часа * 10 у.е. = 30 у.е.

ОПР 3 часа * 8 у.е. = 24 у.е.

Итого нормативные затраты = 114 у.е.

Планируемые ОПР пер. составляют 3 у.е. на 1 ч прямых трудозатрат и ОПР пост. равны 27000 у.е. Нормативная цена одного изделия 145 у.е.

В течение января подразделение изготовило 1650 изделий при нормальной мощности производства 1800 таких изделий, реализовано 1500 изделий (планируемый объем продаж 1600 изделий).

Фактические затраты на одно изделие составили:

Прямые материалы 58кг * 1,1 у.е. = 63,8 у.е.

Прямые трудозатраты 3,1 часа * 10 у.е. = 31 у.е.

ОПР 39930 у.е. / 1650 изделий = 24,2 у.е.

Итого фактические затраты = 119 у.е.

Фактические ОПР пост. составили 23000 у.е. Фактическая цена одного изделия 160 у.е. Определить:

1) отклонение по прямым материальным затратам и его составляющие.

2) отклонение по прямым трудозатратам и его составляющие.

3) отклонение по ОПР и его составляющие: 1)отклонение по объему и контролируемое отклонение; 2) отклонение по ОПР пост. и его составляющие; отклонение по ОПР пер. и его составляющие);

4) отклонение по выручке и его составляющие.

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

Оборот документов по счету 20

Поступление расходных материалов в производство фиксируется внутренними документами:

• Требование на отпуск материальных ценностей;
• Накладные.

При начислении заработной платы производственников составляется расчетно-платежная ведомость.

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

Регистры сводной ведомости по счету 20

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

ООО «Ромашка» производит детские вещи на продажу. Анализ счета 20 отражается в оборотно-сальдовой ведомости:

Из ведомости мы видим, что в себестоимость продукции входит сумма затрат равная 238 367,84 руб.

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

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

Отношение между счетами является синтетическим анализом, где показаны какие счета корреспондируют со сч.20. Данный анализ составлен по таким проводкам:

• Дт20 Кт02 – начислена амортизация производственного оборудования;
• Дт20 Кт10,71 – использованы материальные ценности;
• Дт20 Кт60 – начислены коммунальные расходы;
• Дт20 Кт69 – начислены страховые взносы в ПФ, ФФОМС, ФСС;
• Дт20 Кт70 – начислена заработная плата производственникам.

В конце каждого месяца сч.20 закрывается, корреспондируя со сч.90 такой проводкой:

Дт90 Кт 20 – 244 567,99руб. – списаны производственные расходы.

Конечное сальдо сч. 20, после закрытия месяца должно быть нулевым, но при незавершенном производстве конечное сальдо будет числовым.

Функции ведомости производственных затрат

Правильное распределение затрат позволяет:

• Достоверное отражение производственных расходов;
• Исчисление фактической себестоимости продукции;
• Анализ рационального использования материальных ценностей;
• Определение реальной цены на продукцию;
• По анализу принимать решения производственного и управленческого характера.

Дебетовое сальдо сч.20 отражает прямые расходы на выпускаемую продукцию, вспомогательные и косвенные затраты, потери от брака. Он корреспондирует со сч. 23, 25, 26, 28.

Кредитовое сальдо сч.20 отражает фактическую себестоимость производственного процесса продукции. Списываются суммы со сч.20 в Дт сч. 40,43,90.

Главным критерием бухгалтерского и хозяйственно-управленческого учета являются производственные затраты на выпускаемую продукцию.

Рассмотрим типичную ситуацию, в которой часто оказываются новички. Допустим имеется типовая конфигурация 1С:Комплексная автоматизация 8. Первоначально конфигурация была установлена из дистрибутива (допустим релиза 1.1.20.1). Затем в связи с необходимостью адаптации под специфику предприятия была включена возможность изменения (новички очень часто ошибочно называют это действие снятием с поддержки, хотя на самом деле это не так).

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

1) Спустя какое-то время после очередного обновления мы получаем сообщение от бухгалтерии об ошибке, которая вылазит в момент проведения регламентной операции закрытия месяца. До этого такой ошибки не было, следовательно всему виной обновление. Вполне типовая ситуация. Мы начинаем диагностировать ошибку и видим, что ноги растут из общего модуля УчетНДСФормированиеДвижений. Начинаем разбираться и понимаем, что данный модуль был значительно переработан в типовой и после объединения мы «потеряли» часть процедур/функций (или как часто происходит в типовых, они «перепрыгнули» в другой общий модуль) . В виду хитросплетения общих модулей между собой в типовых, на этапе обновления не всегда можно выявить проблему, которая проявляет себя только при работе пользователей.

Итак мы понимаем, чтобы разобраться нам нужна типовая конфигурация текущего релиза (допустим 1.1.23.1). Но где ее взять? Если есть знакомый франч и он может оперативно переслать дистрибутив — прекрасно, но предположим его нет, а исправить проблему нужно срочно. (Варез не предлагать!). Более того, может и интернета не быть, и что делать в такой ситуации? Неоднократно был свидетелем процесса, когда человек для решения данной проблемы устанавливал новую базу из имеющегося первоначального дистрибутива, а затем последовательно ее обновлял до последнего, чтобы в чистой базе посмотреть «как оно должно быть на самом деле». А ларчик как всегда просто открывался:)

Теперь рассмотрим различные варианты решения:

а) Первый вариант: Меню -> Конфигурация -> Сравнение конфигураций, затем выбираем конфигурацию поставщика и сравниваем ее с основной конфигурацией.

Удивительно, но есть такие, кто про это не знает. Или при любых обстоятельствах используют пункт Сравнить, объединить с конфигурацией из файла (предварительно раздобыв/получив типовой.cf).

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

Меню -> Конфигурация -> Поддержка -> Настройка поддержки и внизу нажимаем кнопку Сравнить, объединить.

2) Другая ситуация: допустим мы изменили или удалили какой-то кусок типового кода, а через некоторое время оказалось, что мы допустили ошибку и нужно все вернуть обратно. И как часто происходит, бэкапа сохраненной конфигурации до внесенных изменений не оказывается. Но мы то точно знаем, что этот кусок кода содержится в типовой, поэтому конфигурация поставщика решила бы проблему.

Естественно можно поступить как и в первом случае. Дождаться окончания процесса сравнения, и из окна сравнения конфигураций открыть типовой модуль и скопировать оттуда код.

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

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

Просто многие единственный раз открывают данную форму только лишь для включения возможности изменения и больше никогда к ней не возвращаются.

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

А для чего еще может понадобиться сохранение конфигурации поставщика в файл?

3) Рассмотрим следующую ситуацию. Допустим на начальном этапе существования конфигурации в типовой не было нужного нам функционала и было принято решение о доработке. Доработка была минимальной, но в дальнейшем это все же создавало неудобства при обновлении. Но затем, спустя какое-то время, мы обнаруживаем, что данный функционал (как в свое время было с версионированием объектов) появился в типовой (и как часто бывает, реализован на порядок лучше, чем «кустарная» доработка).

Приведу еще несколько примеров реальных ситуаций, когда может потребоваться откат к типовой конфигурации:

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

2. Опять же по незнанию типового функционала (очень часто этим страдают бывшие "семерочники") вместо использования свойств и категорий были добавлены реквизиты справочников/документов, когда это не имело веских на то оснований (данные например использовались только для вывода в печатные формы).

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

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

Единственный способ поставить конфигурацию снова на полную поддержку - это загрузить (не в режиме сравнения и объединения, а именно пункт Загрузить конфигурацию из файла) типовой.cf. Вот для этого нам как раз и пригодится возможность сохранения конфигурации поставщика в файл.cf. Делаем сохранение, затем загрузку, и после обновления конфигурации базы данных, получаем типовую конфигурацию в первозданном виде, т.е. с замочком:) Естественно перед выполнением данных действий вы должны заранее позаботиться о сохранении/переносе необходимых данных, которые "смоет" после возврата к типовой конфигурации и обязательно сделать резервную копию базы данных!

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