Экономическая библиотека

Учебники по экономике

7.3. Гибкость в организации расчётов

  Благодаря развитой организации и продуманной поддержке документооборота в названных разработках аналитический учёт может быть необходимым образом распределён по различным подсистемам, аналогично тому, как это реализовано в системе «Галактика», заслужившей положительные отзывы многих экспертов. Разработчики «Инфософта» и «Компаса» в некотором смысле даже пошли дальше: работая с их системами, пользователь может выбирать, распределять ли аналитический учёт по подсистемам управления (что, на наш взгляд, целесообразнее всего) или же вести аналитический учет в произвольном объеме.
  Так, например, с помощью модуля «Бухгалтерия» системы «Флагман» («Инфософт») может быть организован аналитический учёт почти любой сложности: к какому-либо счёту можно привязать до 15 типов аналитических счетов. Поддерживаются как предопределённые, так и произвольные аналитические разрезы. К первым относятся субъекты учёта (контрагенты, сотрудники), объекты учёта (всё, что подлежит не только суммовому, но и количественному учёту), статьи и центры затрат. Вторые (произвольные) разрезы могут быть увязаны с любыми ведущимися в системе списками. Особо следует отметить то, что настройка аналитического учёта в бухгалтерской подсистеме производится предельно просто, чего нельзя сказать о многих других разработках.
  В системе автоматизации фирмы «Компас» план счетов содержит множество настроек: активности счёта по отношению к балансу, типа сальдо счёта, признака необходимости закрытия, признака ведения учёта в иностранной валюте, признака забалансового счёта и т. д. К синтетическому счёту/субсчёту можно подключить до девяти кодов аналитики. Весьма интересно то, что при установке признака типа сальдо счёта можно регулировать, до какого уровня аналитики следует держать сальдо свёрнутым, а с какого следует его разворачивать. Это важно при ведении развёрнутого аналитического учёта на счетах взаиморасчётов, и такая возможность в большинстве других разработок не поддерживается. Например, можно сворачивать сальдо на уровне контрагентов, но вести развёрнутое сальдо на счёте/субсчёте. А можно сворачивать только на уровне документов-оснований, а на уровне контрагентов вести его развёрнуто. Последнее не вполне корректно, но многие пользователи хотят работать именно так. И разработчики предоставляют им такую возможность.
  Говоря о гибкости организации различного рода типовых расчётов, следует отметить ещё и такое важное свойство программы фирмы «Компас», как возможность выбора конкретного механизма списания себестоимости товарно-материальных ценностей. Дело в том, что программы вычисляют средневзвешенные цены, а также оценки методами ФИФО и ЛИФО по-разному. Проиллюстрируем данную проблему на простом примере вычисления средневзвешенных цен. Пусть один и тот же товар поступил на два склада предприятия от разных поставщиков несколькими партиями, что отражено в табл. 7. Для упрощения примера будем считать, что цены приведены в рублях. Из приведённых данных следует, что средневзвешенная цена данного вида товара по складу № 1 составляет 110 руб., по складу № 2 - 120 руб., а в целом по предприятию себестоимость составит

(2200 + 2400) / (20 + 20) = 115 руб.

Таблица 7

Таблица 7

Таблица 8

Таблица 8

  В условиях нашего примера данные по себестоимости склада и предприятия отличаются не только при использовании методики оценки по средним ценам, но и при применении методов ФИФО и ЛИФО.
  Следовательно, ответ на вопрос, какова себестоимость отгруженного со склада № 1 товара, будет во многом зависеть от того, какая «средняя» применяется в вычислениях: по складу № 1 или в целом по предприятию.
  Кстати, одни программы вычисляют средневзвешенные цены по каждому складу, а другие — по предприятию.
  Другая особенность выполнения подобных расчётов состоит в выборе временного диапазона, за который производится расчёт себестоимости. Рассмотрим следующий пример.
  Пусть за месяц поступили две партии одного и того же товара по разным ценам. В течение месяца одна из партий была полностью реализована (10.06.01), но первая поставка была произведена до реализации (5.06.01), а вторая позже (15.06.01). Принята методика учета по средневзвешенным ценам. Схема движения товара представлена в табл. 8.
  Если, основываясь на данных приведённого примера, списать себестоимость товара по состоянию на 10.06.01, то списанная сумма составит 1000 руб., а если за месяц в целом - то 1100 руб. (по средневзвешенной цене за месяц). При использовании метода ФИФО результаты списания будут идентичными (поскольку всегда сначала списываются первые по поступлению партии), а результаты списания по методу ЛИФО — различными.
  Традиционно при ручном учёте периодом расчёта является месяц, поэтому средневзвешенные цены или оценки методом ЛИФО выводятся в целом за данный период. Это вполне объяснимо, поскольку вручную производить оперативный пересчёт показателей оценки запасов по большой номенклатуре весьма затруднительно.
  При использовании же компьютерных программ появляется возможность проводить расчёт себестоимости более оперативно, т. е. на момент совершения операций отгрузки товаров или отпуска материалов в производство. В одних системах расчет производится динамически, на момент списания партии, а в других — в целом за какой-либо период.
  Таким образом, получается, что расчёт средневзвешенной цены может быть реализован четырьмя различными способами:
  - по каждому складу на момент списания;
  - по каждому складу за выбранный период;
  - в целом по предприятию на момент списания;
  - в целом по предприятию, но за выбранный период.
  В каждом конкретном случае это будут разные оценки. В качестве полезного упражнения предлагаем проверить, по какой схеме ведутся расчёты в используемых на практических занятиях программах.
  Вообще, в соответствующих ПБУ пусть и не совсем явно, но всё-таки рекомендуется осуществление расчётов по схеме «в целом по предприятию за выбранный период». Однако в этом случае складской учёт можно вести только в натуральном выражении.
  Предположим, что в условиях первого примера со склада № 1 отгружены обе поступившие на него партии товара. Конечно, следовало бы списать со склада всю их стоимость, т. е. 2200 руб., однако если программа вычисляет средневзвешенную цену в целом по предприятию, то скорее всего в ней реализован алгоритм, в соответствии с которым вычисления будут производиться путём перемножения списываемого количества (20 единиц) на средневзвешенную цену по предприятию (115 руб.). В результате остаток в натуральном выражении на складе № 1 будет равен нулю, а в стоимостном выражении окажется отрицательным (-10 руб.).
  Вот почему в тех программах, в которых расчёт «средней» осуществляется в целом по предприятию, стоимостные остатки по каждому складу обычно не ведутся. Многих пользователей такой подход не устраивает.
  Наиболее целесообразным решением в данном случае является настройка программы на любой способ расчёта в зависимости от пожеланий конкретного пользователя. Однако большинство систем такой возможности не предоставляет, и в них реализуется только один из вариантов расчёта.
  В этой связи хотелось бы отметить, что разработка фирмы «Компас» предоставляет выбор варианта расчёта: в целом по предприятию, по подразделениям либо в привязке к каждой партии. К тому же оценки можно получать как в целом за период (месяц, квартал, год), так и на текущий момент. Более того, система в течение периода позволяет списывать себестоимость динамически, по факту движения ТМЦ, а в конце данного временного интервала можно выполнить пересчёт, в результате которого будут проставлены суммы списания исходя из себестоимости приходов за весь период. Таким образом, реализуются любые варианты.
  Выполнить настройку программы на необходимый вариант довольно просто. В условиях, когда правила выполнения расчётов строго не установлены, это, пожалуй, наиболее верный подход. В конце концов, клиент сам выбирает то, что ему нужно, и вся ответственность лежит на нём.
  Представляется, что настройки уровня аналитического учёта, с которого следует вести развёрнутое сальдо на счетах взаиморасчётов, и порядка расчёта оценок себестоимости списываемых ТМЦ должны иметься в каждой программе, по крайней мере, до тех пор, пока в нормативных документах не появится строго определённый порядок расчёта.

 
© www.eclib.net