Несоответствие склада и 41 счета

[У.Ю.Т]

Имею постоянные проблемы с соответствием склада и 41 счета.
Расчет с/с периодически не помогает.
Как-то выкручиваюсь, но нужны координальные меры исправления ситуации.
Что делать?

[Asasa]

Расчет себестоимости - дело святое, но этого мало.
Надо проверить:
1. Нет ли проводок по 41 счету, вносимых в других, не складских, модулях.
2. Как настроены типовые операции в складских модулях - везде ли корректно используется 41-й счет, действительно ли проводки по нему выполняются по складской себестоимости, а не по цене реализации, или с НДС, или с наценкой, или с прочими "добавками".
3. Как настроены методы учета - если "по учетным ценам", то расчет себестоимости вообще ни при чем.
4. Проблемы могут быть и там, где один и тот же субсчет 41-го используется в разных складских модулях по-разному (с разными методами учета).

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

[Asxat]

У каждого случая несоответствия есть конкретная причина.
(Не выполненый расчет себестоимости - не в счет, это другое.)
Кардинальные меры можно принять проанализировав эти самые конкретные причины.
А по другому лучше не станет...

[orlov]

Как настроены счета хранения? Учет партионный или сортовой? Метод списания?
Есть отчеты по приходу и выбытию с признаком "сверочные", показывают отклонения проводок от документов.
Недавно видел такую ошибку настройки, когда на разных складах одна и та же группа была определена на разные счета хранения.

[Якoв]

Я сначала нахожу дату, в которой есть несоответствие, а потом ищу документ.
Дату ищу так.
********************************
set deleted on
delete file c:\temp\q1.dbf
delete file c:\temp\q2.dbf
delete file c:\temp\q3.dbf
delete file c:\temp\sravnen.dbf
delete file c:\temp\sravnen.xls
delete file c:\temp\all1.dbf

USE H:\BEST2005\DB\all_2006\SCLAD\Mdocm.DBF NOUPDATE SHARED in 1
USE H:\BEST2005\DB\all_2006\Main.DBF NOUPDATE SHARED in 2


SELECT MAIN.DATAOPER as date, MAIN.DT_SCHET as SCHET, SUM(MAIN.SUMMA) as DSUM ;
FROM MAIN;
WHERE MAIN.DT_SCHET = "41";
GROUP BY MAIN.DATAOPER, MAIN.DT_SCHET;
INTO TABLE c:\temp\Q1.DBF

SELECT MAIN.DATAOPER as date, MAIN.KT_SCHET as SCHET, SUM(MAIN.SUMMA) as KSUM;
FROM MAIN;
WHERE MAIN.KT_SCHET = "41";
GROUP BY MAIN.DATAOPER, MAIN.KT_SCHET;
INTO TABLE c:\temp\Q2.DBF

SELECT MDOCM.DATE, MDOCM.SCHET,;
sum(iif(MDOCM.vid="1",MDOCM.SUM,0)) as prihod, ;
sum(iif(MDOCM.vid="2",MDOCM.SUM,0)) as rashod ;
FROM MDOCM;
WHERE MDOCM.SCHET = "41";
GROUP BY MDOCM.DATE, MDOCM.SCHET;
INTO TABLE c:\temp\Q3.DBF

CREATE TABLE c:\temp\all1;
(date D, schet n(5), dsum n(10,2), ksum n(10,2), prihod N(10,2), rashod n(10,2))

append from c:\temp\q1.dbf
append from c:\temp\q2.dbf
append from c:\temp\q3.dbf

SELECT all1.DATE, all1.SCHET,;
sum (all1.dsum) as dsum,;
sum (all1.ksum) as ksum,;
sum (all1.prihod) as prihod,;
sum (all1.rashod) as rashod,;
sum (all1.dsum - all1.prihod) as luft1,;
sum (all1.ksum - all1.rashod) as luft2;
FROM c:\temp\all1;
GROUP BY all1.DATE, all1.SCHET;
INTO TABLE c:\temp\sravnen.DBF

delete all for (abs(dsum-prihod)<1 and abs(ksum-rashod)<1)
pack
COPY TO C:\TEMP\sravnen.XLS XLS
close all
quit
*********************************
В результате получается файл
C:\TEMP\sravnen.XLS
в котором показаны те даты и счета, на которых есть разница между суммами прошедшими по складу и по 41 счету.

[Иванов Н.Н.]

Господа, а ведь эта проблема достаточно фундаментальна. Как и проблема соответствия счета 70 и сводов по зарплате, счетов 01, 02 и картотеки основных средств. Поэтому, если позволите, начну несколько издалека.
В принципе, я бы делил все системы автоматизации учета на два больших класса. В первом классе все виды учетной дифференциации выносятся в план счетов. Особенно многоуровневую структуру приобретают счета материального учета. Например, счет 41, может иметь четыре уровня деления, склад - группа запасов – номенклатура - партия. Естественно, что такого рода дифференциация плана счетов, приводит к резкому росту числа проводок, и вообще, довольно значительному «утяжелению» бухгалтерского учета. Для малого предприятия с компьютерным учетом увеличение числа проводок в 100-1000 раз, может быть, и не очень существенно само по себе, но заставляет серьезно задуматься о методике поиска ошибок в этой системе. Если же в среднем предприятии обрабатываются в год 1-10 млн. проводок, это порождает серьезные проблемы, как в программных, так и в технических составляющих компьютерной системы.
Во втором классе дифференциация плана счетов ограничена. Ряд задач аналитического учета выносятся в специализированные модули, такие как модуль складского учета или модуль учета зарплаты. Количество проводок в результате становится существенно меньше, упрощается учет в специализированных модулях, но появляются специфические дополнительные проблемы. Приходится периодически контролировать соответствие сводной информации в специализированных модулях с оборотами и сальдо по счетам бухгалтерского учета. Например, проверять соответствие сальдо по счету 41 суммарной стоимости всех товаров по карточкам складского учета, а дебетовый и кредитовый обороты – сумме прихода и расхода. Конечно, при правильной настройке формул вычисления сумм проводок и соблюдении учетных технологий, это соответствие обеспечивается автоматически, но помнить о проблемах такого рода все-таки приходится.
Первый подход реализован в большинстве программ с товарным знаком «1С», программах Инфо-Бухгалтер или Инфо-Предприятие. Второй – в системах БЭСТ или ИС-ПРО. Мне однозначно ближе второй подход. «Лобовое» решение проблемы аналитического учета, когда все его виды выносятся на уровень проводок считаю вчерашним днем построения систем автоматизации учета. Он был характерен для середины 90-х годов, а сейчас, как мне кажется, стал анахронизмом.
Использование специализированных учетных модулей порождает специфическое требование к культуре бухгалтерского учета. Крайне нежелательно делать проводки, например, на счета складского учета, вне специализированного складского модуля. Особенно часто их пытаются настраивать в типовых операциях по обработке авансовых отчетов. На мой взгляд, это совершенно нерационально, т.к. именно в складских модулях хранится информация о ставках налогов и счетах складского учета, к которым «приписана» та или иная номенклатурная позиция.
В системах БЭСТ самым решительным образом отвергается возможность «пообъектного формирования складских цен», когда учетная цена одной и той же номенклатурной позиции может быть разной на разных складах. Так что если, например, один из складов используется в розничной торговле, и при перемещении на этот склад делаются проводки с использованием счета 42, расхождения между бухгалтерским и складским учетом неизбежны. С другой стороны, даже законодательство признает, что учетная политика должна быть единой, и нельзя на одном складе иметь учетные цены, равные цене приобретения без НДС, а на другом – цене предполагаемой реализации. Однако можно одну и ту же группу товаров учитывать на разных складах на разных бухгалтерских счетах, если только они связаны с применением одного метода учета. В этом случае следует внимательно следить, чтобы документы внутреннего перемещения сопровождались проводками между счетами складского учета.
Возвращаясь к проблеме соответствия бухгалтерского (в узком смысле) и складского учета, получается, что она распадается на три составляющих. Контроль остатков, контроль дебетового оборота, и контроль кредитового оборота. Соответственно, первый документ, который хорошо бы подготовить в печатном виде – это оборотная ведомость за тот период, например, квартал, который подвергается анализу. Если начальные и конечные остатки по картотеке совпадают с начальным и конечным сальдо по оборотной ведомости, все в порядке.
Что делать, если не совпадает начальное сальдо и начальные остатки? Особенно часто эта проблема возникает при внедрении систем автоматизированного учета на крупных предприятиях. Проведя за двенадцать лет внедрения более чем на полутора сотнях объектов, могу вспомнить только 2-3 случая, когда после ввода вступительного баланса и картотеки складских остатков, дебетовые сальдо на счетах складского учета и суммарная стоимость соответствующих складских остатков совпадали. Более того, приходилось встречать даже полученные в ручном учете отрицательные складские цены. По этой причине мы обычно рекомендуем издать специальный приказ «О внесении дополнений в учетную политику в связи с переходом на компьютерный учет». А в этот приказ вставить, например, такую фразу: «Уточнить складские цены в пределах общих сумм, отраженных в последнем квартальном балансе». Означает это только одно – цены надо подогнать под вступительный баланс. При этом обычно выбираются самые многочисленные в натуральных единицах позиции, с тем, чтобы такое произвольное изменение складских цен не бросалось в глаза. То же самое придется сделать, если такая ситуация возникла в текущем учете, исправить ее в прошедшем периоде нереально, и в бухгалтерском учете решили начать «новую жизнь».
Если начальное сальдо и остатки совпадают, но не совпадают конечные, следует проверять дебетовый и кредитовый обороты. В БЭСТ-4 и БЭСТ-5 есть штатные средства для решения этой проблемы «под корень». В модуле «Товары» следует составить ведомость учета движения для поступления на склад или выбытия со склада. В поле «Вид поступления» лучше поставить «весь приход», а в поле «Вид ведомости» «по документам». Обязательно следует поставить «счет ТМЦ», а вот склад, группу и т.д. лучше не заполнять, чтобы гарантированно увидеть все движение ТМЦ, числящихся на данном счете. В полученном отчете будут в числе других два столбца «Стоимость учетная складская» и «Сумма бухгалтерских проводок в дебет счета», с итогами в конце. Прежде всего, следует посмотреть на итоговую сумму во втором столбце, и сравнить ее с суммой оборота в распечатанной ранее оборотной ведомости. Если они не совпадают – есть проводки, не связанные с документами складского учета. Найти их обычно не составляет особого труда, чаще всего поле «номер документа» у этих проводок не заполнено. В «АРМ главного бухгалтера» можно также отфильтровать проводки по счету складского учета, сделанные в других модулях. Если же проводки в ведомости движения и оборотной ведомости совпадают, следует проверить совпадение итоговых сумм в двух упомянутых столбцах ведомости. Несовпадение в ведомости поступления встречается достаточно редко, чаще всего не совпадают суммы расхода со склада и проводки в кредит счета. В том числе это может быть связано с тем обстоятельством, что проводки, откорректированные вручную, не пересчитываются при стандартном запуске процедуры расчета себестоимости. Необходимо запустить их пересчет целенаправленно.
Недостатком полученного отчета является то обстоятельство, что он очень большой. В нем приведены все строки всех документов движения. Конечно, если бы система такого рода ведомостей была двухуровневой, было бы значительно удобнее. Тем не менее, если в отчете менее тысячи строк, найти документ, в котором сумма расхода отличается от суммы проводок, можно за несколько минут. Если больше, можно сформировать несколько ведомостей за более короткие промежутки времени и анализировать только ту, где итоги не совпадают. Обычно, когда такой документ найден, понять причину расхождения проводки и суммы прихода или расхода, не представляет труда.
Отдельный случай, когда расхождения в каждом документе составляют одну-две копейки. Тогда это просто ошибки округления. Определяем отклонение стоимости остатков от конечного дебетового сальдо и делаем проводку на эту сумму между счетами 99 и 41, как и положено по правилам ведения бухгалтерского учета.

[orlov]

У.Ю.Т, удалось решить проблему?

[Пудель]

(6) "Мне однозначно ближе второй подход. «Лобовое» решение проблемы аналитического учета, когда все его виды выносятся на уровень проводок считаю вчерашним днем построения систем автоматизации учета. Он был характерен для середины 90-х годов, а сейчас, как мне кажется, стал анахронизмом." Ерунда. Нету такого понятия "уровень проводок". Вы его сами выдумали. Есть синхронное изменение синтетических и аналитических данных - а есть несинхронное. Чем же тут крыть.

[Пудель]

(6) "чаще всего не совпадают суммы расхода со склада и проводки в кредит счета. " Вот это - точно анахронизм. Возврат к "бумажной" журнально-ордерной схеме.

[BDAdmin]

Ерунда. Нету такого понятия "уровень проводок". Вы его сами выдумали. Есть синхронное изменение синтетических и аналитических данных - а есть несинхронное. Чем же тут крыть.

Что значит нету?
Откройте регистры бухгалтерии - вот ваш уровень проводок.
Книга хозяйственных операций - это наш уровень проводок.
В вашем случае на операции по складу с двумя позициями будет 2 проводки по синт.счету учета (по одной на каждую аналитику), в нашем 1, в случае, если схемы учета позиций совпадают.
Синхронно? в обоих случаях да.
Отклонения в нашем случае могут возникнуть при нарушении правил учета.
Т.е. когда документ делается без формирования проводок. В этом случае по складу движение есть а проводок нет, или сумма неверная.

[Пудель]

Вы бы ещё показывали на луке и картошке, как Чапаев. Вы мыслите категориями пользователя, а никак не программиста, не в терминах внутренней структуры базы данных. "На пальцах" и "по аналогии" можно до много договориться...
Я имею в виду, что то, что Вы называете "проводкой" - это взаимосвязанная совокупность нескольких записей в несколько таблиц баз данных, одни из которых отвечают за синтетический учёт, другие - за аналитический учёт по корреспондирующим счетам. В любой базе данных. Другое дело, насколько чётко отслеживается взаимосвязь этих записей.

[BDAdmin]

Мда, порой лучше промолчать? Не кажется?
Беда 1Сников в подмене понятий.
Проводка за 300 лет не изменила своей сути в мире, ни в одной из систем.
Если желаете говорить предметно, ознакомьтесь с предметом разговора.
Документацию по БЭСТу предоставить?

[Asasa]

Вы бы ещё показывали на луке и картошке, как Чапаев. Вы мыслите категориями пользователя, а никак не программиста,

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

Буквально сегодня нам был звонок из Германии и звонивший искренне удивился, что мы не знаем немецкого языка. На наше предложение говорить по-английски ответил "Нихт ферштейн!" Вот и Ваши послания, как этот сегодняшний звонок из Германии. И Вы так же искренне удивляетесь, что не понимают Вашего персонального языка. Говорите на нашем - ответим по существу.

[Пудель]

(12) Уточните, пожалуйста, Вы согласны с утверждением "...то, что Вы называете "проводкой" - это взаимосвязанная совокупность нескольких записей в несколько таблиц баз данных, одни из которых отвечают за синтетический учёт, другие - за аналитический учёт по корреспондирующим счетам. В любой базе данных." - или не согласны?
(13) Нет, я умею на обоих языках, но в данном случае спор сугубо технологический, а не методологический. Т.е. мы выясняем, не что такое проводка в смысле бухучёта, а что такое проводка и её аналитическая расшифровка в базе данных.

[Asasa]

Ну а тема называется "Несоответствие склада и 41 счета". Задавший вопрос ждет практического ответа, а Вы уподобились ученому совету и пустились в теоретические изыски, уводя тему в сторону. Создается впечатление, что Вы тему начали читать только с середины.

[Пудель]

Да, меня заинтересовал именно постинг № 6 Иванова, и я именно ему и написал, и этого не скрываю .

[Аноним]

не лучше ли тогда Пуделю перейти на личную переписку с Ивановым? все-таки тема обозначена...

[Пудель]

А что, от темы в ветке отклоняться нельзя? Я буду иметь это в виду .

[Asasa]

А что, от темы в ветке отклоняться нельзя? Я буду иметь это в виду .

Да не обижайтесь Вы, и отклонятся можно. Но не глобально. Думаю, что задававший изначально вопрос, не ожидал, что на него "упадет" постинг № 6 - целый фундаментальный труд. О-о-о-о-о-о-очень большой. Такой большой, что не прочесть за один раз времени не хватает. А осознать.....

[Иванов Н.Н.]

В своем сообщении я затронул два момента. Во-первых, когда появляется расхождение между бухгалтерским и складским учетом, и что с ним делать практически. Как будто, эта сторона дела вопросов не вызывает, тем более, что в БЭСТах, в отличие, скажем, от ИС-ПРО, проблема решена «под корень». Во-вторых, позволил себе некоторые теоретические рассуждения. Они вызвали возражения. Поэтому дальше касаюсь только вопросов теории.

Да, меня заинтересовал именно постинг № 6 Иванова, и я именно ему и написал, и этого не скрываю .

Отвечаю. Правда, не всегда получается быстро, потому что имею склонность к определенной обстоятельности, и не очень получается вести спор в режиме коротких реплик.
Кстати, есть такое понятие «режим реплик» или я сам его выдумал? Примерно также обстоит дело и с «уровнем проводок». Это в данном случае просто фигура речи, которая призвана пояснить суть проблемы. Давайте сформулируем ее по-другому. Должна или не должна вся аналитическая информация отражаться в плане счетов, а значит, и в проводках?
Наверное, можно сформулировать и с использованием Вашей терминологии. Что лучше, синхронное или несинхронное изменение синтетических и аналитических данных? Хотя в такой постановке проблема выглядит несколько расплывчато. В плане счетов и в проводках отражаются не только синтетические, но и аналитические счета. Скорее проблема состоит в том, вся или не вся аналитическая информация должна отражаться в плане счетов? А также, должна или нет та аналитическая информация, которая в плане счетов непосредственно не отражается, автоматически менять состояние счетов бухгалтерского учета?
Еще раз повторюсь, что проблему эту считаю очень серьезной, малоисследованной, и не думаю, что попытки от нее отмахнуться или решить мимоходом могут привести к чему-нибудь хорошему.
Я какие-никакие, а арагументы привожу, как за, так и против каждой позиции. В.Апралов в №№ 2-4 журнала «Бухгалтер и компьютер» за 2006г. по-другому к этому вопросу подходит. Тогда как Ваша позиция, простите, ближе к полковнику Скалозубу: «А книги все собрать да сжечь». Особенно по теории бухгалтерского учета.

[PiterBest]

У меня сложилось мнение что автор темы пользуется сортовым учетом, может глобальным решением будет переход на партионный учет ?
И второй вопрос а в технологических операциях контролем сумм
в документах и проводках пользоваться пробовали ?

[У.Ю.Т]

1. Острота проблемы снята. Спасибо всем.
2. Партионный учет невозможен ( около 15000 номенклатурных позиций)
3. "Контроль сумм в технологических операциях" контролирует продажную сумму. А мне надо контролировать С/С.

[PiterBest]

Вообще-то есть клиенты с партионным учетом при номенклатуре под 100 тыс. позиций.... Размер номенклатуры вряд ли может быть показателем в даном вопросе. Специфика продукции может, но никак не количество

[Кира]

Я когда-то разбиралась с этой же проблемой. Вопрос в применяемых алгоритмах списания. В БЭСТе на конец какого-то периода (не помню сейчас, месяц или квартал) себестоимость конкретного товара усредняется и образуется на начало след.периода как-бы партия в количестве остатка по средней цене остатка. Т.е. при расчете себестоимости идет уже не чистое ЛИФО или ФИФО, а как-бы частично по средней. Меня это не устраивало, я устала искать несхождения, а найдя, мучиться от невозможности исправить - такой алгоритм! Я даже согласилась с разработчиками, что по-другому нельзя.
Решением проблемы для меня стал переход на партионный учет по учетным ценам. Это кажется, что невозможно применить этот метод при большой номенклатуре. Ничего подобного, все очень просто и логично. Все вопросы снялись.

[BDAdmin]

В БЭСТе на конец какого-то периода (не помню сейчас, месяц или квартал) себестоимость конкретного товара усредняется и образуется на начало след.периода как-бы партия в количестве остатка по средней цене остатка. Т.е. при расчете себестоимости идет уже не чистое ЛИФО или ФИФО, а как-бы частично по средней.

При расчете себестоимости в БЭСТе алгоритм работает, как мне кажется, другим образом. В результате расчета себестоимости в рамках одного периода происходит замена учетных цен в документах списания, принимающих участие в расчете себестоимости. И уже эти цены служат отправной точкой для расчета в следующих периодах.
Все логично.

[У.Ю.Т]

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

Может быть и так.
Мы как-то пробовали партионный учет.
Но у нас ежедневные приходы по достаточно большой номенклатуре позиций.
Получается сильное увеличение количества складских карточек.
А нулевые карточки надо закрывать не все.
В случае сортового учета я закрывал только неактуальную номенклатуру.
А при партионном учете приходится закрывать нулевые партии, что очень трудоемко.
И всё равно приходится оставлять последнюю партию незакрытой.
+ Необходимо отслеживать резерв, (а прайс по номенклатуре) что при партионном учете не совсем возможно.

[Кира]

А при партионном учете приходится закрывать нулевые партии, что очень трудоемко.

Нулевые партии закрываются автоматически. Складскую карточку можно строить сквозную по номенклатурному номеру без учета разбивки по партиям. А вот с резервом я, к сожалению, не экспериментировала - поэтому ничего не могу сказать конкретного. Но скоро у меня на очереди встанет этот вопрос - при партионном учете отслеживать резерв, тогда попробую решить эту задачу. Заранее предполагаю, что будут трудности.

[Кира]

Расчет себестоимости (я выясняла все это несколько лет назад) все же происходит по ФИФО или ЛИФО (как заявлено в учетной политике) в рамках одного периода. В БЭСТе ведь расчет себестоимости делается ежемесячно? т. е. чистое списание ФИФО/ЛИФО идет в течение месяца, а вот на конец месяца возникает следующая ситуация:
Допустим на конец месяца есть остатки по одному ном.номеру из 3-х разных приходов(в хронол.порядке):
1шт - по 50руб.
2шт. - по 55 руб.
1 шт - по 52руб.

На конец месяца образуется как бы партия в размере 4шт по цене ( 50+55*2+52)/4=53руб. и списание в след. месяце идет по этой цене. Если в течение след.месяца списывается весь остаток, то беды особой нет, если же что-то осталось, то это как бы нарушение чистого метода ЛИФО или ФИФО, т.к. накапливается погрешность. Я это все так поняла.

[PiterBest]

При расчете себестоимости в БЭСТе алгоритм работает, как мне кажется, другим образом. В результате расчета себестоимости в рамках одного периода происходит замена учетных цен в документах списания, принимающих участие в расчете себестоимости. И уже эти цены служат отправной точкой для расчета в следующих периодах.
Все логично.

Нет не логично, извините.
ФИФО и ЛИФО это методы, в которых не должно быть усреднения.
От того, что Вы закрываете период, нельзя полагать, что Вы можете себе позволить на эту дату изменение учетной политики.Следовало где-то хранить остатки на границу периода с каждой ценой. Но это решение на самом деле очень и очень не простое для реализации, поэтому у нас и имеет место усреднение. Это понятно, но не логично
Вот поэтому у Киры и были проблемы и она ушла на партионный учет и правильно сделала.

[PiterBest]

Может быть и так.
Мы как-то пробовали партионный учет.
Но у нас ежедневные приходы по достаточно большой номенклатуре позиций.
Получается сильное увеличение количества складских карточек.
А нулевые карточки надо закрывать не все.
В случае сортового учета я закрывал только неактуальную номенклатуру.
А при партионном учете приходится закрывать нулевые партии, что очень трудоемко.
И всё равно приходится оставлять последнюю партию незакрытой.
+ Необходимо отслеживать резерв, (а прайс по номенклатуре) что при партионном учете не совсем возможно.

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