Привет, форумчане!
Бухгалтерия предприятия ред. 2.0.17.6. Начали вести учет с 01.01.2011 (перешли с Бухгалтерии 7.7). В организации применяется УСН. На счете 41.01 "Товары на складах" установлен признак учета Количественный и субконто Партии.
Требуется, чтобы на счете 41.01 велся только суммовой учет (данные программно без разбивки по товарам, но с разбивкой по покупателям, договорам и документам расчетов будут переноситься из отраслевого решения на базе 7.7).
Хотелось бы вносить как можно меньше изменений в типовую конфигурацию.
Планирую не вносить изменения в сам счет 41.01, а изменить модуль проведения документов таким образом, чтобы при определенном условии (признак добавлю как дополнительный реквизит) можно было приходовать товар только в суммовом выражении, т.е. Количество = 0; субконто партии при этом не буду заполнять. Тогда на счет 41.01 будут попадать только суммовые данные.

Подскажите, пожалуйста, правилен ли такой подход, может не учел я какие-то подводные камни, и с какими возможными сложностями можно столкнуться?
Таким образом вопрос не столько технический, сколько методологический, но очень нужен совет!!!

Отзовитесь, знатоки бухгалтерии!
Сейчас думаю, что вместо пустого субконто партии заведу один формальный документ партии вида Партия (ручной учет) и буду его в качестве субконто указывать во всех документах

(0) ПИ*ДЕЦ!!!

(0) ты #БАНУЛСЯ.

Я пожалуй соглашусь с предыдущим оратором...

*с предыдущими

(2)(3)(4)(5)
Ругаться вы мастера!
Это требования вообще-то заказчика, а совсем не мои, так что могли бы что-то более дельное подсказать!

(6) ПИ*ДЕЦ Заказчик!!!
Вали оттуда пока не поздно

(6) Я такое бы делать не стал
Если бы заказчик сильно настаивал - озвучил все свои аргументы "против" и расстался с ним по хорошему.
Он бы все равно ко мне вернулся после вот такого, как ты, безотказного

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

(8) Заказчик очень сильно настаивает, и бросить его не вариант. А в чем конкретно минусы этого подхода?

Эээ,
а у меня такое работает.
На 1.6.
На 2.0 вот допишу скоро.

(11) Ну то есть это вполне рабочая схема, как я понял? А минусы есть какие-нибудь?

(10) Оценивай все модули, которые придется переписать.
У тебя УСН - значит туча дополнительных регистров по учету доходов-расходов.
Будешь их затрагивать или нет?

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

(2)(3)(4) Неопытные кодеры детектед.
Иногда такое действительно бывает нужно.
Я делал такое на 1.6, работает у клиента до сих пор.

Методик реализации две:
1) Никаких изменений субконто на 41 счете делать не надо. Заводишь предопределенный элемент номенклатуры с названием наподобие "НоменклатураСуммовая", и при указании его в документах - движения делаются только по сумме без количества. Себестоимость подставляется из документа, расходы на товары при УСН считаются по методике, допущенной Минфином в одном из писем для предприятий с большим товарооборотом, краткое описание методики - расчет "доли оплаченных в доле отгруженных" товаров. Минусы - изменений в модули придется вносить ДОХРЕНА. Основной объект для раскурочивания - общий модуль "НалоговыйУчетУСН".
2) Указывать во всех документах Количество=Стоимости. Т.е. добиваться, чтобы цена везде была равна 1. И одна-единственная номенклатура, естественно. Плюсы - дорабатывать почти ничего не нужно. Минусы - есть какие-то ограничения в применимости, за давностью лет уже не помню, какие.

Одно НО: все эти методики применимы, если у заказчика наряду с БП работает любая учетная система, в которой ведется пономенклатурный учет и ведется расчет себестоимости. Ибо себестоимость отгруженного товара в БП нужно будет перекачивать именно из этой системы. Или ручками, как говорит (13).
Если себестоимость взять неоткуда, то (0) не взлетит.

(0) На хрен оно это надо? Делаешь цену 1 рубль, в количество пихаешь сумму. И получаешь суммовой учёт без гемороя.

(14) Не успел :)

(14) Не, номенклатура не одна, а по количеству ставок НДС как минимум :)

(14) я не увидел ни одного упоминания про внешнюю программу.
Если есть - да фиг с ним чего там на 41 с количеством. Но тогда и вопроса этого не встанет, потому что БП только для отчетности и бухгалтера.

(17) Зачем в разрезе ставок НДС? Входной НДС в КУДиР выделять отдельной строкой?

(19) Пригодится для ясности картины :)

(14)Спасибо, дельно объяснил. Конечно, есть внешняя программа, откуда берется себестоимость, я об этом в (0) написал: установлено отраслевое решение, где ведется оперативный и управленческий учет; будет настраиваться выгрузка из этого отраслевого решения в БП.
Методику наверное буду брать, которая описана в (14) под цифрой 1), потому что именно методику "доля оплаченных в доле отгруженных" товаров бухи собираются использовать.

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

(22) чего-то не могу найти в теме где написано про внешнюю программу

(21) А если есть внешняя программа откуда берутся данные, то зачем эти танцы с суммовым учетом? Ну переносите As Is и голову не морочте.

(0) Количество = Цена; Цена = 1;

(24) видимо по накладным хотят в БП учет

(0)
>Таким образом вопрос не столько технический,
>сколько методологический, но очень нужен совет!!!

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

(25) И? Что мешает формировать проводки при выгрузки? И переписывать ничего не надо

Точнее загружать не только документы, но и сразу формировать проводки (ставишь флаг ручная корректеровка, что бы при перепроводки данные не изменились)

(28) тогда уж проще подписку прифигачить

(29) И что твоя подписка будет делать?

(30) проводки

(31) а данные откуда она брать будет?

Мы говорим о том, что есть учетная система (не 1С БП), и мы говорим что данные о себестоимости мы будет выгружать из этой учетной программы. Поэтому ничего не мешает выгружать не только документы, но и самому формировать движения в БП, благо 8-ка это позволяет. А чтобы после перепроводки в БП наши труды не исчезли, можно выставить флаг ручная корректировка (вполне типовой флаг).

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

(28) Проводки - это одно, а движения регистров РасходыУСН, ВзаиморасчетыУСН, ПартииТоваровНалоговыйУчет - ты тоже предлагаешь вручную формировать? А ведь без них формирование КУДиР не взлетит...

(34) Да, а по твоему программа знает откуда их взять?

(32) ну да, логично)

(22) В теме про внешнюю программу не написано, написано в (0):
>Требуется, чтобы на счете 41.01 велся только суммовой учет
>(данные программно без разбивки по товарам, но с разбивкой
>по покупателям, договорам и документам расчетов будут
>переноситься из отраслевого решения на базе 7.7).

(23) Не хотят бухи видеть разбивку по товарам, но хотят видеть в БП разбивку в разрезе расходных накладных и договоров покупателей.

(33)Интересный вариант насчет ручной корректировки. Но я так понимаю, что ручная корректировка идет только после проведения, а при проведении в типовой БП контролируется количество, и если количество равно 0, то Отказ = Истина; скорее всего, ты подразумеваешь записывать движения документа без проведения и выставлять флаг ручной корректировки?

(34) Уважаемый Lys, подскажи пожалуйста, с использованием методики расчет "доли оплаченных в доле отгруженных" товаров, можно ли обойтись вообще без КУДиР, просто на основе движений по регистру бухгалтерии отчет наваять соотвествующий?

Так не надо ничего проводить.
Нужно установить реквизиты "Проведен" и "РучнаяКорректировка" и сформировать и записать набор регистра бухгалтерии.

(37) "Не хотят бухи видеть разбивку по товарам, но хотят видеть в БП разбивку в разрезе расходных накладных и договоров покупателей." - и что? Что мешает при выгрузки конвертировать 400 позиций в одну - товары в ассортименте?

"Интересный вариант насчет ручной корректировки. " - нет, если флаг стоит, то программа ничего не контролирует и не проверяет. Например у тебя может быть пустая табличная часть и накладная на Васю, а в проводка стоит Петя, и движения по товарам.


Вопрос в другом. Спроси у бухов, по НУ товар можно принять к зачету, только если он принят к учету и оплачен. Как по их мнению программа должна это узнать? Т.е. если вы 100% берете товар по предоплате - это одно. Если вы оплачиваете поставщику после поступления поступления, то вот тут и кроются грабли.

Ничего адаптировать особо не нужно. есть же стандартный подход для бухии когда надо вести суммовой учет: Количество=Сумма , СуммаДок=0.
В результате в количестве на счетах ТМЦ лежит сумма. Требуется немного подшлифовать в доках контроль заполнения поля сумма и немного подшлифовать регл отчетность (например баланс, форму 2, декларацию на прибыль)

Закладка.
Сегодня, вернее уже вчера, такой же разговор был. А я всё никак догнать не мог, что за хрень от меня бухша требует.

(14)
>> 2) Указывать во всех документах Количество=Стоимости.

Как мне втолковывала буха, Количество = Стоимости Без НДС.

Правильно втолковала? Если так, то завтра перепишу выгрузку, пусть давятся.

Закладка. Надо помозговать.

есть парочка моментов....

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

Вся опасность в том что (0) это очень опасный момент. И если его никто в реальной жизни еще не применял то это очень рискованно. Особенно если будет принято с горяча и не обдуманно. Просто бухи могут конкретно подставить фирму. И проги тоже которое такое навояли. В случае провала - лучше увольнятся сразу. Буху 5 лет ответственность и решетка. прогу ничего кроме увольнения и подпорченной репутации - типа куда глядел когда такую уйню делал.

если бы такую схему прожевали с десяток фирм и она была рабочая то это бы поперло. а так риск 99 процентов
причем нужен как минимум год по такой программе проработать
и чтобы гб был просто пипец окуенным и смог все проверить и отладить

более коректным было бы условие
не одну номенклатуру а созлдать пороги товаров

в кучу мешать товар за 1 рубль и за 1000 это жестко хотя пишут кол=сумма.
я бы все таки подумал может ценовые категории. т.е. не один товар был. а допустим 10. от 1рубля до -10, от 10 до 100, от 100 до 1000, и т.д. к примеру 50000-100000.
и в разрезе категорий сливать номенклатуру.

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

Хато всегда еще можно было бы проверить. Например при списании товара из ценовой категории явно себестоимость не может вываливаться за определенные рамки. Логично что товар ценовой категории 1000 не может при списании получить 1 рубль.

Кстати идея очень неплохая с ценовыми ктаегориями. Это может быть реальным решением. обалденным.

Блин!!! ЕМАЕ. еще лучше это сочетание - Ценовая категория + номенклатурная группа !! тут максимально можно приблизится в нужным цифрам. я думаю даже на 95 процентов к реальной картине.
И это даже даст некую проверку и контроль. какое то обнаждеживание.

ну будет там кол во номенклатур кратное кол ценовых и номенклатурных групп. Ну может быть 50 будет номенклатр. зато реально все само будет считать причем максимально приближенно.
При этом в БП не надо парится кол=суммы.
Объединяем в рамках номенклатурной группы и ценовой категории товар по количеству и суммам.
Т.е. кол = сумме реальных количеств товаров (которые вошли в сочетание) Сумма - так же.
Т.е. будет кол 100 Сумма 1000. Но будет в рамках сочетания.
При списании прога реально будет списывать приближенную себестоимость в БП.

Это реальная математическая схема. Что скажете? Может я ошибаюсь? (всю жизнь математику за отлично знал).
Вроде это применение математически может приблизится к реальному правильному расчету всего.

Маньяк выпил чего-то алкогольного лишку.

Смотрите еще что. для УТ 9если кто не вел справочник ценовые группы) делаем доп обработку. Во первых каждый сам видя чем торгуем фирма и товарами какоого диапазона цен - создает ценовые категории. Делаем обработку - которая пробежится по номенклатурной базе - каждорму товару автоматом назначит ценовую категорию (т.е. ывсе это можно сделать офигенно автоматизированно). Далее если будет обработка обмена которая будет в БП выгружать данные по номенколатуре в сочетании двух пересечений. Т.е. в приходных будут разбитые строки:
Диваны 1000 и т.п. а также будут в реализациях аналогично.
То я думаю это 100 процентный вариант. Никаких там себестоимостей из ут не надо переносить никаких ручных проводок и т.п.

>> типа куда глядел когда такую уйню делал
задницу тут прикроет письменное и подписанное директором ТЗ.

(53) Это не маньяк, а наша переписка. Именно этим я сейчас и занимюсь.

(56) +1000. Я переписку выкладываю чтобы народ извилины свои подключил. общее дело. математики тут есть?

>>> если его никто в реальной жизни еще не применял

Судя по тому, что даже в этом нашем Мухосранске некоторые так работают, то в остальных У-нсках и подавно.

Ээээ
В конторе где я работаю примерно около десятка организаций на УСН.
По товарам суммовой учет. Себестоимость из другой базы 1С.
Всё работает уже четвертый год.
Доработок в БП для суммового учета совсем немного.

А маньяк про риск 99% и ценовые группы какие-то.

Я покурил меня еще осенило!
Чтобы было ВСЕ максимально четко.
Каждая фирма знает наценку товара (особенно в разрезе номенклутрных групп). Так вот для вышесказанного должно выполнятся следующее условие!!!!
Ценовая группа должна иметь границы (от и до) входящие в рамки наценки и не превышающие её. тоесть значение ОТ до значения ДО должно быть нне более 20 процентов (лучше среднее - например 10). Тогда мы никогда не получим проданный товар ниже себестоимости.
Все это тоже можно уложить в автоматичсекую обработку.

(59) а если не УСН?

(60) это ответ ка назначить ценовые группы когда спросят .
и чтобы каждый не выдумавал чо попало. опять таки математическая закономерность.

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

Не забываем что бухи = женщины. а у женщин напрочь отсуствует логическое мышление. жизненный факт.

завтра обязательно почитаю, сегодня уже не воспринимаю

(64) попрошу не обобщать, потому как я тоже бух, хоть и работаю прогом - им платят больше и работа интереснее

(66) я говорил про баб. из мужиков офигенный главбухи и финансисты. Но их единицы.

Есть и женщины финики нормальные. Но такие же единицы. не всем фирмам посчастливится таких встретить.

(67) тут согласен знаю трех мужиков бухов и все они ГБ :)

(66) вот кстати завтра если прочитаешь. было б интересно что скажешь.

(68) да и вот женщину финика только одну знаю - суперская и как женщина и как финик

(70) обязательно скажу свое мнение

что вы все курите? я тоже хочу )

Все забыли самое главное - А НАФИГА вам это все??

Чем номенклатура на 41-ом помешала?

(74) даже пояснять не хочется если такие вопросы есть. недаром в части ника есть слово нуб ?

Она там не мешает. проблемы у бухов с ней.
1) в торговых фирмах как правило очень большая номенклатура
2) штат бухов которые именно бухи в БП (а не те юухи которых называют бухами, которые счета и не нюхали а сидят там в УТ первичку шлепают - операторы даже я назвал) - очень мал.
Документов много. И не все "шоколадно" в учете.
3) не все шоколадно - ну типа прихода нет на товар который продан был по безналу....ну или еще там всякой мути...типа наоборот когда его купили по безналу а он продан был скажем так без доков...на балансе висит, а реально его нет...и еще куча всего....пришел товар его там накоплектовали тоже из той же серии и т.д. и т.п.
И ВСЕ ЭТО проследить, отработать, обработать тем бухам которые именно бухи (в довольно небольшом количестве) за ВСЮ ФИРМУ - НЕРЕАЛЬНО.

а еще чаще проблемы сыпятся потому что именно те самые бухи которые бухи а не которые операторы - еще хуже чем операторы ибо вообще ни...я не знают и не умеют.

+(76) наимболее проблемные ситуации когда фирма - многофирменная и товар вперемешку. и контроля не стоит - ибо торговля станет. поэтому одна фирма продает товар длругой фирмы. А в типовой нифига инструментов нет нормальных - отслоеживающих это. Работа с товарами организаций настолько тупо и бездарно сделана ,которая должна это все в ИДЕАЛЕ ВЫПОЛНЯТЬ, что дальше некуда. А ты попробуй ка работая бухом отследить в УТ чо продала одна фирма товар другой. Да тут даже МЕГА1Сники ничерта сделать не могут. а я уже молчу про бухов которые пилять даже в отчете не знают где кнопка НАСТРОЙКИ. да даже если и отчет сделать, попробуй

(75)
Инженер, ты понты свои попридержи.

(76)
Если есть некое "отраслевое" решение, где (мы это принимаем) все в порядке, то какие проблемы корректно перенести эту картину в БП?

БУхия - это отражение УЖЕ свершившихся операций.


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

И как от этого спасет суммовой учет в БП? Кроме как - концов уже ОКОНЧАТЕЛЬНО никто не найдет.

" и контроля не стоит - ибо торговля станет. "

Опять же - суммовой учет - панацея??

"А ты попробуй ка работая бухом отследить в УТ чо продала одна фирма товар другой."

Умилил. Я в УТ не работаю.

(80) ты понимаешь что в УТ никогда гне было ничего в порядке того что касается БП. разве что если фирма не идеал просто белоснежного учета. Хотя даже в таком варианте не будет 100 процентов БУГАГА. потому что в УТ методики заложены благодаря которым даже самый белоснежный учет будет иметь ОШИБКИ.
Ибо партионка это партионка. минусы, не списанные партии и прочая прочая шняга, работа задним числом, ошибки программы, ошибки ввода и т.д. и т.п. - сотни ..
Ты не путая реальную жизнь с идеалами заложенными в программы. идеального учета не бывает - это фантасктика.

(81) в том то и дело главбухи знают чо с этим делать.

(83) так вот поэтому ты многого и не понимаешь.

Инженер - по делу будет что-то? Или так - "тень на плетень"?

У меня-то были случаи - зачем это могло потребоваться, в 7.7 в одном случае это даже работало.

Мне хочется узнать - зачем людям из этой темы это нужно?

(84)
Сына, ты ушатал меня. На моих программах работают три крупных дистрибьютора; давай ты меня жизни учить не будешь, ок?

И пускай тебя ник не смущает, это третий. Волшеник меня банит - я ники заводить не успеваю.

Какой то недекват ты. лезешь в тему. ничерта не шаря. и еще хочешь чего то понять чего не дано понять.
чо тебе по делу писать если все написано а ты ничего не понял.

(90)
Математик, это - слив?

(84)
"ошибки программы, ошибки ввода"

И дальше-то что? Типа на них можно что-то списать? Ты ерунду-то не городи.

Делал подобную штуку на механизмах типовой БП8, заводится 3 номенклатуры "Товар с НДС 10%", "Товар с НДС 18%" и аналогичны

Делал подобную штуку на механизмах типовой БП8, заводится 3 номенклатуры "Товар с НДС 10%", "Товар с НДС 18%" и аналогичный без ндс. При приходе количество ставится сумма*100, т.е. 1 штука товара стоит 1 копейка, при списании в поле количество указывается себестоимость, которую нужно списать, в сумме продажная стоимость. Все работает, абсолютно без доработок.

Ньюансы - работа идет вся в белую, оперативный учет ведется в другой программе.

(94) Извините, что влез со своей ложкой в эту тарелку. :)
Как в этом случае отрабатывается вопрос со списанием товара (именно списание, а не реализация) и перемещение?
Есть ещё вопросы с комиссионными товарами (отчёты комиссионеров, комитенту).

Интересно, что тема продолжает развиваться, я уж и не чаял.
(44) Учет товаров в отраслевом решении на базе "Аналит фармация 7.7" (порядком доработанном), там нет отдельно регламентированного, отдельно управленческого учета, т.е. фактически только управленческий.
(45) В реальной жизни вариант этот и до этого применялся, просто перешли на базу Бухгалтерия 8, и я засомневался, решил посоветоваться с форумчанами, потому и ветку эту поднял.
(46-50) Хитро это, конечно с номенклатурными группами, но я пошел по пути вообще без количества (см. пост (14) вариант 1)).
(78) Фирма-то конечно многофирменная, но каждая фирма ведет управленческий учет в отдельной программе, т.е. фактически есть не одна, а 3 базы по каждой фирме, из каждой из которых все будет сливаться в одну базу бухию (по каждой фирме, разумеется)
(84) >партионка это партионка...
Партионный учет вообще там в отраслевом решении своеобразно ведется: в качестве партий выступают серии, при этом списание конкретной серии определяется оператором, т.е. ручное списание партий имеет место.
(96) А что со списанием смущает тебя, ведь себестоимость-то вручную в бухию переносится...
С комиссией вообще интересно: имеется работа комитентами. При этом реализуется она без отчета комитенту, необходимые проводки, которые списывают комиссионный товар, отражают долг перед комитентом и размер комиссионного вознаграждения, будет делать все тот же документ реализации (у него будет соотвественно изменена ОбработкаПроведения)