v8: БП КОРП: Декларация по налогу на прибыль - проблемы с автозаполнением по обособкам #540302

Накипело, наблюдаю за этим уже год. Конфа БП КОРП специально разработана для учета по подразделениям. А декларация по прибыли заполняется через одно место. смотрю код заполнения декларации по прибыли: 1) если по всем подразделениям используется одинаковая ставка налога,то при автозаполнении не то что не заполняются  соответствующие подразделениям листы приложения 5 к листу 02, но даже и не генерятся причем если в параметрах учета  настроено на единую ставку налога, то этот РегистрСведений.СтавкиНалогаНаПрибыльВБюджетСубъектовРФ вообще не должен использоваться догадайтесь, что мне бухи сказали, когда узнали что им нужно руками создавать и заполнять 50 доплистов по филиалам??? 2) если в декларации выбрать место предоставления - обособленное подразделение, то вся декларация насильно очищается и кнопка "Заполнить"  - блокируется, т.е. опять вручную 50 деклараций заполнять ручками. Может я что-то делаю не так!??! Если делаю все правильно, то доколе такой сереьзный косяк будет тянутся из релиза в релиз??

походу КОРП-ом никто не пользуется :)

Продолжаем разбор полетов ... при выборе места предоставления 220 (обособленное подразделение) отключил блокирование кнопки "Заполнить" заполняю... заполняются приложения 1,2,3 к листу 02, которые не нужны для предоставления по обособке

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

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

Ну например, то что нормально работало в 1.6 и в 2.0, это учет зарплты, а точнее выплата. Когда одним РКО выплачивается несколько ведомостей и в них одинаковые сотрудники. Он рисует нереальные проводки, пришлось бить старые РКО на насколько, по числу ведомостей

Или к примеру учет в УЕ, когда из-за округления сумма документа не совпадала с суммой в проводках по 51 счету

Самое прикольное, что они забыли в выписки и в кассе добавить на форму реквизит Подразделение, когда идет оплата от покупателей. Т.е. у нас один расчетный счет, но несколько подразделений. Ставим вид документа - оплата от покупателей, реквизит подразделения нет на форму, и в результате подразделение на 62 и 51 совпадают Если же к примеру выбрать прочее, тогда все нормально И как следствие дикий перекос на 51 по подразделению

Аналогично и при списании с видом оплата поставщику. У себя просто отключил учет по подразделению на 51 счете

За склады бы вообще убил бы. Какого они фактически склад привизали к организации. Т.е. если у меня куча фирм (УРИБ), то получаеться по их методологии, я для каждой организации должен завести свой склад? Фишка в чем, когда в приходно/расходном документе выбрать склад, то он плевать хотел на настройки пользователя в части подразделения. А берет подразделение из реквизита склада, А так как подразделение у нас привязано к организации, то я не могу завести один склад - основной, и в настройках указать подразделения, а обязан для каждой фирмы/подразделение создать свой склад К тому же, что им мешала в УРИБ по организации фильтровать по  реквизиту подразделение? Там же такая портянка складов получается у всех. А еще мы получаем гемор в виде объет не найден, так как у склада заполнен реквизит подразделение, т.е. если мы заполним этот реквизит в одной почке, то в другой это будет - объект не найден (что логично). Интересно что будет после ТиИ во второй почке с этим реквизитам, если мы поставим удалять битые ссылки :)

Хотя так как они сделали миграцию справочника РБП ... у себя тупо сделал чтобы мигрировало все и вся, это безопаснее, чем то что у них реализовано

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

по этому вопросу вроде у моих проблем нету, конечно некрасиво разъезжается по подразделениям, но их это не напрягает вроде

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

у нас в складах подразделение не заполнено, и вообще все делаем через основной склад - я так понимаю это и избавило нас от проблем

Подразделение не оборотные, смысл тянуть остатки? Понятно что если базе 2 месяца - фигня. А если базе будет лет пять? Или надеяться что 1с каждые три года будет выдавать новый продукт несоместимый со старый, в который можно только остатки перенести?

что-то ты в разнос пошел, вроде чистятся проводки при перепроведении...

А как же тогда учет по подразделениям? Или предлагаешь в каждом документе руками проставлять нужно? Я бы пошел на это, если бы 1С заполняли бы подразделения из настроек юзверя, а так получается полюбому юзверь должен выбрать подразделение, что ни есть гуд, потому что потом другой должен проверить, а везде ли правильно первый выбрал?

Посмотри код внимаельно, по реализациям остаються

+ щас глянул - при начале проведения везде вызывается    Если ОбщегоНазначения.РучнаяКорректировкаОбработкаПроведения(РучнаяКорректировка,Отказ,Заголовок,ЭтотОбъект) Тогда которая зачищает проводки перед перепроведением

Собственно недавно обсуждали, я не один такой

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

Из той ветки там они хитро замутили, проходят только по входящим в последовательность вроде, типа для ускорения пока пользуюсь из 1.6

Смотрим ГМ Т.е. по умолчанию ВыборочноОчищатьРегистры - истина Далее УдалитьДвиженияРегистратора(ЭтотОбъект, Отказ, Ложь,            ВыборочноОчищатьРегистры И НЕ ЭтотОбъект.ДополнительныеСвойства.ДатаДокументаСдвинутаВперед); Т.е. в процедуру очистки получаем ВыборочноОчищатьРегистры = (истина и не ДатаДокументаСдвинутаВперед) Ну и далее ....

Т.е. даже при ручной перепроводки они не всегда чистят движения

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

я правильно понял - перезаписи движений не происходит при сдвиге даты назад?

хм... может я чего-то не понимаю, но здесь должны чиститься все движения кроме РегистрНакопленияНаборЗаписей.РасходыПриУСН

Там пустые наборы не записываются, а движения очищаются.

почему не записываются??? записываются вначале движения чистятся, а потом

скопипастил неудачно, посмотрите сами  - все там нормально

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

Почему, если дата сдвинута назад или не изменилась, то ВыборочноОчищатьРегистры = Истина и СписокРегистровДляОчисткиДвижений.Найти(ТипЗнч(Движение)) = Неопределено, соотв. условие не выполняется. ЗЫ На всякий случай я сначала в отладчике проверил )

с другой стороны - нафига записывать пустые наборы, если они и так очищены??

32+ я себе, на всякий случай, знак поменял в этом условии с <> на =

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

Кстати не факт что свойства ДатаДокументаСдвинутаВперед корректно заполняется. Оно же не автоматом, а в подписки

может вернемся к сабжу? :) заполнение декларации проверьте кто-нибудь!

вот еще в кучу

Дошли руки до ЗУП, не заполнялось подразделение на статьях налогов, хотя в ПС все указано. Оказывается эти писатели, забили его заполнить :( тр 16067 модуле документа отражения Если мУчетПоПодразделениямНаСчетах и мСоответствиеСчетаУчетаПоПодразделениям[СчетДебета] Тогда А строку Строка.ПодразделениеКт нигде не заполняют, кроме случай с РБП главное в другом месте когда начисления 44-70, то все хорошо Если мУчетПоПодразделениямНаСчетах Тогда Работает

Прибыль когда посмотрите? :)