1с 7.7. В Бухгалтерских Итогах Операция Не Разбивается На Проводки

[RZX]

Здравствуйте!

Сейчас объясню, что имел ввиду. ))
Есть две базы на 1С 7.7 Бухгалтерия: Юкола и МиСофт.

В двух базах есть документы "ПоступлениеТовара".

В каждом документе делаем приход ОДНОГО И ТОГО ЖЕ товара: 5 и 6 штук., но по разным ценам.

Вот что делается в базе МиСофта при проведении документа:


Тоже самое в Юколе:


Теперь смотрим оборотку по 41-му счету:
МиСофт:


А в Юколе почему-то вот такая вот хрень:


Как так получается? Почему?
Почему Юкола не разбивает операцию на две проводки???

Соответственно БухгалтерскиеИтоги работают точно также.
В итоге партии в Юколе считаются неправильно, когда в приходе один и тот же товар - пишет в партию 11 шт. по цене последней записи. А не как положено 5 и 6 по своим ценам.

Где это настраивается??? Я впервые в жизни с таким сталкиваюсь.
Поиск по форуму и Гуглу ничего не дал.

Буду очень благодарен за ответ!

 

[Дайнеко]

Сравните в Плане счетов на 41 Субконто какие параметры Субконто (в Конфигураторе)
Они разные

 

[RZX]

>Сравните в Плане счетов на 41 Субконто какие параметры Субконто (в Конфигураторе)
>Они разные

Ээээ... Ну как сказать...

План счетов МиСофт
41.1 Товары на складах Номенклатура МестаХранения Партии

План счетов Юкола:
41.1 Товары на складах Номенклатура МестаХранения Партии

Это я правильно понял?

Если имелся ввиду именно 41 счет, то таки да отличаются:
МиСофт:
41 Товары на складах Номенклатура
Юкола:
41 Товары на складах Номенклатура МестаХранения Партии

Это правда влияет на проводки?

 

[KiR]

А Вы не пробовали ли сделать оборотку с подсчетами, или конкретно по счету 41.1? думаю - это Вас бы спасло.
Так как на 41м счету в одной из баз только одно субконто, а не 3 как в другой (кажется в предыдущем посте перепутаны базы по 41му) - Вы получаете такой результат

 

[RZX]

А Вы не пробовали ли сделать оборотку с подсчетами, или конкретно по счету 41.1? думаю - это Вас бы спасло.

Тут ситуация такая:
на картинках в первом посте в МиСофте проводки и оборотка по 41.1 (не по 41),
в Юколе проводки и оборотка по 41.4 (тоже не по 41).
На всякий случай несколько раз перепроверил.
То, что разные субсчета (41.1 и 41.4) - не думаю, что должна быть какая-то разница.

Так как на 41-м счету в одной из баз только одно субконто, а не 3 как в другой (кажется в предыдущем посте перепутаны базы по 41му) - Вы получаете такой результат

Нет, ничего не перепутано - опять же перепроверил.
В МиСофте, где все нормально работает, по 41 счету именно одно субконто, а по субсчетам 3.
А в Юколе, где косяк, по 41 счету субконто 3 штуки, как и по субсчетам 41.1, 41. 2 и т.п - везде 3 субконто.

P.S.: Уже несколько суток ломаю голову - ничего. Может кто-нибудь у кого есть возможность, гляньте партии в Юколе. Не может быть, чтобы оно так работало.
Я уже думаю в Юколе в обработке проведения создавать ручные операции и проводить, а при отмене проведения - выключать проводки в этих ручных операциях - другого пути не вижу.

 

[KiR]

RZX, суть в том что согласно первым двум рисункам - программа проводки все одинаково правильно делает. копать нужно в сторону оборотки - она схопывает по какому-то алгоритму. как будто просто включено только первое субконто

 

[RZX]

Да! В том то и дело, что проводки и там, и там правильные.

А оборотка тут постольку поскольку....

Потому что если смотреть обороты для Юколы через СоздатьОбъект("БухгалтерскиеИтоги");
то опять же получается одна проводка с 11 шт., а не две по 5 и 6.
А оборотка она ведь тоже строит отчет по Бухгалтерским итогам - вот поэтому так и выводит. Оборотка как раз правильно отработала.

Грубо говоря получается, что косяк Юколы в Бухгалтерских итогах?

 

[Дайнеко]

Юкола, при всем желании, в самом механизме БИ не может накосячить.
Откровенно говоря, отчет Юколы более правильный. (с точки зрения механизма). Поясню:

Отчет разворачивает по субконто: 1) Склад 2) Партии (эта надо думать строка с документом). Субконто Номенклатура пропущена.
Т.к. в 2-х проводках указанные субконто абсолютно одинаковы, то механизм просто обязан их сложить и показать 1 строкой.
Это задача и механизма БУ и ОСВ по счету.

Поэтому ненормальность в другом: как Мисофт умудряется их разделить? Или делает анализ по какому-то дополнительному субконто (например номер строки), но не показывает его в отчете. Или отчет строиться не запросом по субконто, а перебору проводок.

 

[KiR]

я думаю что просто дело в настройках. как будь-то в ОСВ просто выключены 2 и 3 субконто, а посему он и сворачивает. если сделать оборотку по 41.1 со включенными субконто - ситуация не изменится?

 

[puh14]

не знаю насчет вышеописаных конфигураций, но в типовой бухгалтерии 8.2 из-за того, что на 41 счету субконто могут быть только склад/номенклатура/документ поступления происходит суммирование строчек с одинаковой номенклатурой в документе. С точки зрения бухучета такое допустимо, с точки зрения управленчесгого - не годится. Я такую штуку ( штобы строчки не схлопывало) решал в середине прошлого года, уже год отработали, косяков нет.

 

[RZX]

я думаю что просто дело в настройках. как будь-то в ОСВ просто выключены 2 и 3 субконто, а посему он и сворачивает. если сделать оборотку по 41.1 со включенными субконто - ситуация не изменится?

Без разницы. Если делать оборотку по 41.1 со включенными субконто - тоже самое.
Я смотрел механизм проведения документов в случаях партионного учета в этих конфигурациях - ничего особенного, никаких отличий не увидел.

Единственное, что я заметил, так это то, что в МиСофте у операций есть еще один реквизит:
Операция.ПервичныйДокумент = глПредставлениеПервичногоДокумента(Контекст);
Понятия не имею, насколько это влияет. (Кстати, в первом посте в картинках в проводках это видно).

Может, есть какие-либо способы обойти такую ситуацию со слиянием проводок?

 

[KiR]

а какие в плане счетов юколы стоят субконо по счету 41.4 ?
точно ли стоит партионный учет в настройках, а не расчет себестоимости по средней?

 

[RZX]

а какие в плане счетов юколы стоят субконо по счету 41.4 ?

В плане счетов для Юколы:
41.4 Товары на складах Номенклатура МестаХранения Партии

точно ли стоит партионный учет в настройках, а не расчет себестоимости по средней?

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

 

[KiR]

Партионный учет писался вручную.

ааааа.. если так тогда

 

[Paume]

А какого типа у вас ваши партии?
Вполне возможно, что если это подчиненный справочник, то в первом случае создается две партии, с одним и тем же номером накладной, но разными ценами, а во втором только одна.

 

[RZX]

А какого типа у вас ваши партии?
Вполне возможно, что если это подчиненный справочник, то в первом случае создается две партии, с одним и тем же номером накладной, но разными ценами, а во втором только одна.

Действительно, в МиСофте, где идет разбивка, партия - это справочник, который подчинен номенклатуре.
А в Юколе - нет, это отдельный справочник, который ни к чему не привязан.

Если это как-то влияет, то попробую партии в Юколе сделать подчиненными номенклатуре.

 

[Paume]

Действительно, в МиСофте, где идет разбивка, партия - это справочник, который подчинен номенклатуре.
А в Юколе - нет, это отдельный справочник, который ни к чему не привязан.

Если это как-то влияет, то попробую партии в Юколе сделать подчиненными номенклатуре.

Нет, не влияет.
Проверь просто, что у тебя в твоих проводках ссылки на разные элементы справочника, а не на один. Вот и все.
Открываешь справочник, ищешь по наименованию. Если в той базе, где суммируются проводки, элемент такой один - то вот твои грабли. Если нет - то ищешь дальше.

 

[RZX]

Нет, не влияет.
Проверь просто, что у тебя в твоих проводках ссылки на разные элементы справочника, а не на один. Вот и все.
Открываешь справочник, ищешь по наименованию. Если в той базе, где суммируются проводки, элемент такой один - то вот твои грабли. Если нет - то ищешь дальше.

ээээ.. прошу прощения, если я что-то неправильно понял...

Здесь суть в том, что и в первом, и во втором случае элемент ОДИН, НО приходит по разным ценам.
То есть бывает такое, что у поставщика тоже партионный учет. И у него один и тот же элемент пришел в разные моменты времени по разным ценам. Вот и получается, что у него в расходной накладной висят два одинаковых элемента, но по разным ценам.
Мы этот элемент приходуем в документе прихода. Мы ведь тоже получается приходуем ОДИН элемент, НО по разным ценам.
И нужно чтобы при отгрузке этого элемента мы тоже имели возможность выбора цены.

Я делаю в Юколе: вот там в приходе одного элемента по разным ценам все сливается - получается вот как на картинке в первом посте. А у меня обработка, которая при выборе товара дает еще и выбор партий (с количеством по партиям и ценой в каждой). Лежал рядом МиСофт: смотрю там - все нормально разбивает и все прекрасно работает!

Вот я вот и думаю...

 

[Paume]

Ну, может, я чего не понимаю тоже...

Один элемент - какого справочника?

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

 

[RZX]

Ну, может, я чего не понимаю тоже...

Один элемент - какого справочника?

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

Выглядит это так:
Элемент номенклатуры один
Партия (документ прихода) тоже одна
НО
проводки две: номенклатура партия - цена 1
номенклатура партия - цена 2

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

и в Юколе Бухгалтерские Итоги выдают, что запись одна, а в МиСофте - что записи две, хотя никакой разницы в обработке проведения приходного документа МиСофта и Юколы я не нашел (ну за исключением того, что в МиСофте партия - это подчиненный справочник номенклатуре, а в Юколе - нет).
Вот мне нужно как в МиСофте, потому что тогда я простым БИ.ВыполнитьЗапрос(...) получаю список партий с разбивкой по ценам.