Добрый день! Наконец и у нас в Украине появились долгожданная ERP и ее "урезанная" сестра BAS КУП Украинские конфигурации создавались методом локализации российской ERP под укр. стандарты ведения учета и отчетности. В некоторых ключевых моментах локализация была проведена некорректно - создана лишь видимость локализации, что на практике на дает возможность вести полноценный учет. Сначала я обратился с данными проблемами непосредственно на поддержку ИТС, но там отказались регистрировать проблемы, ответив в стиле "это вы чего-то недопоняли", а чуть позже заблокировали мне поддержку ))) Потом я описал проблемы в специальной группе в фейсбуке, и мне многие пользователи, приближенные к 1С написали, что я сам виноват в том что не провел моделирование перед покупкой BAS ERP, а программа хорошая )) Прошел год, проблемы не были решены, поэтому публикую особенности конфигураций здесь, чтобы каждый смог перед покупкой провести моделирование и принять взвешенное трезвое решение о том с чем придется столкнуться при внедрении и запуске учета в данной конфигурации. Все нижеописанные особенности перекочевали в BAS КУП из ERP, так как в основном связаны с регламентированным и налоговым учетом.
1. В конфигурации отсутствует возможность складской комплектации товаров и продажи комплекта организацией-плательщиком НДС Номинально, для "отвода глаз", есть 2 метода создания и продажи комплектов, которые продажник показывает потенциальным покупателям на презентациях: функционал "Динамические наборы" и документ "Сборка товаров". И только на рабочем примере покупатель обнаруживает, что на динамический набор нельзя выписать налоговую накладную, а документ "Сборка товаров" формирует проводки через "производство", а именно: дт231кт281(списаны комплектующие) дт281кт231(оприходован комплект), при этом вторая проводка неправомерна, т.к. 231 счет может корреспондировать по кредиту со счетами 25 (полуфабрикаты), 26 (готовая продукция) и 902 (с-сть реализованных услуг), товары предприятие производить не может, следовательно номенклатуру комплекта нужно учитывать как "готовую продукцию" (сч.26), а далее налоговой придется подтвердить, что у вас есть соответствующие производственные мощности для производства данной "готовой продукции", которая на самом деле простой складской комплект). Фактически, без дорогостоящей доработки сборку и продажу складского комплекта сделать нельзя и, судя по ответам, разработчики не собираются с этим что-либо делать в ближайшее время.
2. Учет входящего НДС: ► 2.1. Нет штатной возможности регистрации авансов в бухгалтерском учете (в балансе). В конфигурации реализован так называемый "сложный учет входящего НДС" - проводки по счетам учета НДС формируются товарными документами, при этом, если на дату формирования квартального отчета предприятие заплатило аванс, но не успели получить налоговую накладную, бухгалтеру необходимо вручную создать документ "Операция" и отразить необходимые проводки. ► 2.2. Нет штатной возможности корректировки входящего НДС. Когда это может понадобиться: 1. Договорились с поставщиком о закупке, заплатили аванс, сделка по каким либо причинам отменилась, поставщик вернул аванс. В рабочем месте регистрации НДС к оформлению "висит" 2 строки для регистрации НН и Корректировки. 2. Закупщик "забылся" и скупился по чеку на 260 грн. По закону возместить по чеку можем в рамках 200 грн. Регистрируем входящим налоговым документом чек на 200 грн (налоговый кредит), а НДС с оставшихся 60 грн (10 грн) имеем право отнести на расходы, но штатного механизма как это сделать нет. Бухгалтер делает документом "Операция" 3. Налоговая накладная поставщика была остановлена и прошло 3 года - имеем право отнести НДС на расходы и убрать с неподтвержденного налогового кредита, но штатного механизма как это сделать нет. Бухгалтер делает это документом "Операция" Как итог: рабочее место учета входящего НДС постепенно превращается в "мусорку", где бухгалтеру с каждым днем все труднее разбирать где "висяк", а где документ, реально требующий регистрации входящего налогового документа.
3.Нет штатной возможности скорректировать взаиморасчеты с поставщиком-физ.лицом на сумму уплаченного НДФЛ, в ситуации когда предприятие выступает налоговым агентом, например, когда предприятие арендует автомобиль или объект недвижимости у физ.лица. В документе "Списание задолженности" с операцией "списание кредиторской задолженности" нет возможности отнести списанную сумму на статью прочих активов\пассивов, только на доходы.
4. Закупка импортного товара при авансе осуществляется с нарушением П(с)БУ 21, а именно: согласно п.6: "В случае осуществления авансовых платежей в иностранной валюте поставщику частями и получение частями от поставщика немонетарных активов (работ, услуг) стоимость полученных активов (работ, услуг) признается по сумме авансовых платежей с применением валютных курсов, исходя из последовательности осуществления авансовых платежей." В конфигурации BAS ERP движения документа ПоступлениеТоваровУслуг формируются исходя из текущего курса валюты документа на дату документа, без учета курсов зачтенных авансов. В результате остается сальдо взаиморасчетов с поставщиком в валюте регламентированного учета (и в валюте упр. учета если валюта взаиморасчетов отличается).
5. Распределение общепроизводственных расходов с учетом показателя "нормальной мощности". Документ "Распределение расходов на себестоимость продукции" позволяет распределить общепроизвоственные расходы на выпуски и/или отнести часть (или всю сумму) на другие статьи расходов, среди которых могут быть расходы периода, но вот относимые доли сумм бухгалтеру придется каждый раз вычислять на калькуляторе и вносить "ручками" для каждой распределяемой статьи ОПР.
6. При учете производственных расходов по разным налоговым назначениям закрытие месяца выполняется с ошибкой: алгоритм не может корректно распределить расходы на себестоимость готовой продукции. Это связано с серьезной методологической недоработкой функционала.
7. Модернизация НМА отражается с нарушением В П(с)БУ 8. В движениях по регистрам ПервоначальныеСведеньяНМА (и б/у и н/у) первоначальная стоимость увеличивается на сумму инвестиций (это верно) и уменьшается на сумму накопленной амортизации (на каком основании?), и, при этом уменьшается срок полезной эксплуатации, что противоречит здравому смыслу, т.к. зачастую модернизацию проводят для продления срока эксплуатации, такого в П(с)БУ 8 нет. В результате, после отражения модернизации НМА неверно рассчитывается амортизация.
по п6 развернуто: Ошибка локализации методологии учета производственных расходов и пути ее обхода. [релиз 2.1.12.5]
Начальные условия: учетная политика "НДС и налог на прибыль", ведется раздельный учет товаров по налоговым назначениям НДС.
Первый раз с симптомами данной проблемы столкнулся в обработке "Закрытие месяца" на стадии "Распределение расходов на себестоимость готовой продукции". Обработка после распределения выдала предупреждение что расходы не распределены. В остатке по одной из статей расходов была отрицательная сумма. После анализа содержимого регистра накопления "ПрочиеРасходы" обнаружил что часть расходов по статье расходов ОПР (общепроизводственные расходы) попала в регистр с пустым значением в поле НалоговоеНазначение при проведении документа "ПоступлениеТоваровУслуг". Доработал алгоритм проведения ПТУ, перепровел документы и благополучно закрыл месяц.
В следующем месяце снова та же проблема, и снова анализ содержимого регистра "ПрочиеРасходы" по статье ОПР. В этот раз у всех строк поле НалоговоеНазначение было заполнено, НО налоговые назначения были разные "Обл. НДС" и "Пропорц. обл. НДС". В итоге документ "Распределение расходов на себестоимость продукции" сформировал задвоенную сумму списания расходов. Как я теперь понимаю, рассчитал общую сумму расходов без учета НалоговогоНазначения, а движения с этой суммой сделал для каждого налогового назначения (было бы 3 разных налоговых назначения - сумма была бы утроена). Сделал инструкцию бухгалтеру, что не должно быть пары СтатьяРасходов+АналитикаРасходов с разными налоговыми назначениями. Исправили и перепровели документы, ЗакрытиеМесяца выполнилось без ошибок.
В следующем месяце снова проблема. И тут стоит пояснить. До этого в расходы попадали суммы расходов по амортизации, зарплате и взносам, услугам сторонних орг-й, в этом же месяце бухгалтер списал на ОПР запасы: расходные материалы и инструмент (сверла, аккумуляторы) и спецодежду (перчатки). Себестоимость списанных на ОПР запасов рассчитывается тоже ЗакрытиемМесяца. Алгоритм расчета себестоимости формирует движения документа "Распределение расходов на себестоимость продукции" с пустой статьей расходов, в результате текущий месяц закрывается как бы без ошибок, но в следующем месяце к распределению висит документ с пустой суммой, т.к. в регистре "ПрочиеРасходы" осталось развернутое сальдо в разрезе НалоговогоНазначения. Пользовательского решения данной проблемы нет. Нашел по алгоритму расчета с/сти процедуру формирования движений документа "Распределение расходов на себестоимость готовой продукции" и там в тексте запроса указано "Справочник.НалоговыеНазначенияАктивовИЗатрат.ПустаяСсылка КАК НалоговоеНазначение". Проанализировал в отладке содержание всех переменных и временных таблиц и понял, что НалоговоеНазначение просто неоткуда взять, то есть это не помарка, серьезная методическая недоработка. Минимальная доработка которая позволила закрыть месяц: сделать реквизит "НалоговоеНазначение" в документе "Распределение расходов на себестоимость готовой продукции", и в алгоритме расчета с/с использовать значение этого реквизита для формирования движений по регистру "ПрочиеРасходы". Решит ли такая доработка проблему окончательно мне судить сложно, но это все, что я могу сделать в данных условиях.
В следующем месяце снова проблема из-за возникновения погрешности распределения, которую алгоритм распределения отнес на прочие расходы с пустым налоговым назначением, врезультате чего по распределяемой статье осталось развернутое сальдо. Как ни странно, эту конкретную проблему ИТС зарегистрировали, код ошибки 54567
Я считаю что в данном случае некорректно сделана локализация российского фукнционала. Нужно было решать задачу так, как написано в рекомендациях к сдаче экзамена по 1С Специалст, а именно: НалоговоеНазначение - сущность того же класса что и СтатьяРасходов, только выше, то есть для "Обл. НДС" затраты ведутся по статьям: расходы на осн. производство, зарплата произв. персонала..., для "Пропорц. НДС": расходы на содержание помещения, расходы на транспорт..., для "Необл. НДС": расходы на поставку ПО. Таким образом НалоговоеНазначение целесообразно было бы сделать реквизитом справочника СтатьиРасходов, а не измерением регистра ПрочиеРасходы. Критики могут возразить, что пользователь может поменять реквизит НалоговоеНазначение у статьи расходов и в учете НДС будут большие проблемы, но это надо просто запретить делать для статей, по которым уже есть движения, например, перед записью проверить наличие движений в регистре ПрочиеРасходы по данной статье и отказать в изменении реквизита. При таком методе решения задачи, не нужно было бы дорабатывать российские алгоритмы рассчета с/с, распределения расходов на с/с ГП, а контроль изменения налогового назначения выполнять проверкой списания запаса на статью расходов (реквизит НалоговоеНазначение). К сожалению, украинские разработчики пошли по другому пути, возможно из-за решения другой более сложной задачи, либо же от недостатка квалификации.
Еще обнаружен важный момент: Отнести доп.расходы, связанные с приобретением товаров на первоначальную стоимость можно только на себестоимость всех товаров документа ПТУ. Нет возможности указать отдельные товары документа как это было в УПП/УТП. При этом ещё и проводки будут чуть другие: при отражении документа поступления доп.расходов дт28ДР/кт631, а при закрытии месяца дт281/кт28ДР. В принципе инструкции об использовании плана счетов это не противоречит, но бухгалтеру не нравится задвоенные обороты по счету 28. Как вариант, можно настроить аналитику статьи доп.расходов не ПТУ, а ЗаказПоставщику, разбить товары на разные заказы, сделать одно ПТУ по нескольким заказам и отнести доп.расходы на конкретный заказ поставщику. Но это не более чем "костыль" по-сравнению с тем функционалом отнесения доп.расходов, который был в УТП/УПП. Разработчики пустили пыль в глаза многобразием настроек статей расходов и аналитик и под шумок убрали единственный рабочий вариант, который всех устраивал и которого сейчас невозможно на 100% добиться настройками текущего функционала.
п.4 исправлен в релизе 2.1.15.5. При оформлении операций импорта согласно методическим рекомендациям ИТС себестоимость товаров вычисляется корректно и формируются правильные бухгалтерские проводки.
8. Аналитические отчеты по зарплате, формируются "...с точки зрения расчетчика а не бухгалтера: суммы учитываются по месяцам выплаты (и месяцам начисления), а не по датам, когда фактически была произведена выплата. Анализа сальдо с точки зрения бухгалтера не предусмотрено..." (подробнее см. ИТС, описание отчета "Задолженность по зарплате". Объясню, что это значит: - Начислили зарплату за Март - Отразили выплату зарплаты за Март документом "Ведомость в банк" датой 6.04.20, указав в ведомости что это выплата зарплаты за Март (чтобы ведомость по кнопке Заполнить правильно заполнила суммы) как написано в метод.рекомендациях. - Начислили зарплату за Апрель - Отразили выплату зарплаты за Апрель документом "Ведомость в банк" датой 9.05.20 Формируем отчет "Анализ зарплаты по сотрудникам" за Апрель и видим пустые колнки сальдо на начало и сальдо на конец (хотя выплаты приходятся на начало следующего месяца!) Формируем отчеты "Расчетный листок", "Задолженность по зарплате" - по полям "Сальдо на начало" и "Сальдо на конец" - все то же самое - пусто! Формируем отчет "Расчетная ведомость" - в нем колонки сальдо вообще не предусмотрены
9. Если в один и тот же день по нескольким заказам без указания договора (или когда договор совпадает) наступает событие, требующее выписки налоговой накладной, налоговая накладная формируется одна на всю сумму с общим списком продукции. ИТС отвечают что "так не запрещено законодательством".
10. В УТП/УПП в карточке закрытия месяца было подменю "Печать", из которого бухгалтер формировал справки-расчеты по переоценке вал.средств, списанию РБП, распределению косв.расходов, калькуляциям, себестоимости продукции. В КУП (и ERP) такого не нет. В рос.бух3 нашел отдельное подменю в разделе Операции/Закрытие месяца/Справки-расчеты. Про бухгалтера снова забыли. При покупке с целью ведения регламентированного учета следует предусмотреть затраты на написание этих отчетов, т.к. бухгалтеру они обычно нужны.
p/s Начиная с 30.07.20 программа получила новое название "Business automation software for іntegrated enterprise management". Но на перечисленных проблемах это никак не отразилось: все актуально
11. Зарплата. Есть, но фактически не работает опция выплаты командировочных, отпускных, больничных в режиме "С авасном" (в одной ведомости): в ведомость правильно попадают НДФЛ, ВЗ, ЕСВ, но в поле "К выплате" попадает только сумма аванса, которая разбивается между строками зарплаты и прочих начислений, сумма же этих прочих начислений не учитывается. В результате, чтобы сделать выплату, бухгалтеру приходится делать отдельные ведомости на выплату начисления (комаднировка, отпускные) в режиме "В межрасчетный период". Данная ошибка зарегистрирована под номером 52999 от (ВНИМАНИЕ!) 22.07.2018 (2 года не могут исправить!)
Всем добрый день!!! По совету программиста выбрали эту конфигурацию !!!! Ключевые моментами стали : - возможность работы в облаке - подключение с помощью планшета - рассылка отчетов на e-mail - мониторинг финансовых показателей - самостоятельное небольшое конфигурирование системы.
Из этого вышло :
- Нестандартный документооборот - множество доработок - одновременная доработка как обслуживающей компанией так и разработчиками одних и тех же вопросов!!! - НДС вообще случайный человек наверное делал (нарушение отражения бухгалтерских записей по первому событию, в случае когда первое событие "ОПЛАТА" - отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля. - поле "ПОДРАЗДЕЛЕНИЕ" в разных документах, тянет с разных справочников!!! - отсутствие нормальных управленческих отчетов, которые несут реальную картину на предприятии
В реалии урезанная версия конфигурации ERP, должна соответствовать профессиональной программе, для ведения как бухгалтерского, так и управленческого учета.
- множество доработок - одновременная доработка как обслуживающей компанией так и разработчиками одних и тех же вопросов!!!
В этом как бы основная проблема. Это вам не 7.7 чтобы доработки делать. Данная коробочная конфигурация довольно системно реализована и имеет кучу настроек. Лезть в доработку сложной системы не имея технической документации о ее принципиальной схеме может либо очень опытный разработчик, либо дилетанты чтобы подзаработать". Тут аналогия ВАЗ2101 и Лексус LX350: поставить стеклоподъемники в ВАЗ можно в любом гараже и они будут там очень даже неплохо работать, но лезть устанавливать стеклоподъемники в лексус не разобравшись может быть очень дорого, ведь они там уже есть, нужно разобраться как их использовать, и привыкнуть к кнопкам, а не заказывать альтернативные стеклоподъемники из-за того что форма рычажка вам не удобна.
Цитата
- отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля.
А вы не обратили внимание, что после ввода нескольких документов много полей заполняются сами как бы угадывая что должно быть - это подсистема автозаполнения по статистике, которая пришло на смену жесткому указанию значений по-умолчанию.
Цитата
- НДС вообще случайный человек наверное делал (нарушение отражения бухгалтерских записей по первому событию, в случае когда первое событие "ОПЛАТА"
здесь вы абсолютно правы, если хотите максимально погрузиться в вопрос - ссылка на мой ФБ выше. Разработчики считают что НДС считается у них идеально ))
Salex @ 28.08.20, 16:06
, Спасибо! Но это не сильно поможет! Ищу варианты переговоров с разработчиками или близких к ним сотрудников! Консультанты по вопросам работы в конфигурации КУП, только рассылают ссылки на то, как реализовано в этой программе! Как по мне они далеки от реального процесса работы в программе! Я рад их уверенности в том, что НДС у них считается идеально, но меня и многих других интересуют не только красивые внутренние отчеты по НДС, но и грамотные бухгалтерские записи (проводки)!!!! То что отменена инструкция по учету НДС, но есть еще план счетов, и реалии осуществления поставок и продаж. Как для чайников были книги по компьютерной грамотности, переведу это в плоскость нашего примера НДС. Кстате на заметку в конфигурации BAS бухгалтерия нет вопросов к этому блоку, чего не скажешь про КУП. Вспоминаю первые занятия по бухгалтерскому учету и правила двойной записи по Дебету и Кредиту счетов (самолетики), так вот инструкцию о плане счетов в Украине никто не отменял, и правила типа счета тоже. Существуют счета :активные, пассивные и активно-пассивные, это говорит о том, что каждый может иметь сальдо счета (остаток) только по Дебету, только по Кредиту, либо как по Дебету, так и по Кредиту. Каждому счету в плане счетов присвоен такой признак! При отсутствии логических (корректных проводок) мы можем прийти к отрицательному (красному) сальдо, что есть не допустимым! Поэтому при первом событии "Оплата", пока мы не проведем приходную накладную либо реализацию, столкнемся с тем, что будут отражены бухгалтерские записи по Налоговой накладной, где по 6432 либо 6442 остаток станет отрицательным!!! По первому событию "Оплата" бухгалтерские записи растягиваются на три документа! И в конце все счета закрываются!! Чего не скажешь про КУП, где программисты решили их сократить по своему праву!!! Все что они предложили это подходит для первого события по "Поступлению" или "Реализации". В нашем же случае записи формируются следующим способом:
Вариант А при закупке
По банку не хватает проводки Дт 6442 Кт 6441 При получении Налоговой накладной Дт 6412 Кт 6442 (Это есть) При оприходовании товаров (второе событие)не хватает проводки Дт 6441 Кт 631
Вариант Б при реализации
По банку не хватает проводки Дт 6431 Кт 6432 При выписке Налоговой накладной Дт 6432 Кт 6412 (Это есть) При отгрузке товаров (второе событие)не хватает проводки Дт 70_ Кт 6431
Не понимаю почему это не реализовать как положено, и как это уже имеется в других конфигурациях BAS!!!
Может кто знает, на каких форумах присутствуют представители разработчиков, чтоб можно было им хоть как-то это донести!!!
Еще одна дырка в КУП!!! При ведении бухгалтерского учета в разрезе договоров, для логического завершения всех бухгалтерских записей и регистров, необходимо заполнение в документе полей содержащих договор, он же и документ расчетов! В документе реализация товаров и услуг, данных полей 2 (два): - Первое в шапке документа, на первой вкладке - к нему нет никаких вопросов - Второе в табличной части товаров и услуг в каждой строке!!! Существует ячейка с документом расчетов, в нашем случае это договор. Так вот при заполнении строк товаров, и выборе в ячейке документа расчетов - нажатие F4 либо троеточие, попадаем в окно для выбора договора где нет фильтра по выбранному в шапке Контрагенту!!! Это значит что случайно, можно выбрать договор другого Контрагента. При этом имея тысячи договоров в справочнике нужно найти и выбрать именно договор данного контрагента, и по заверению консультантов это тоже не ошибка и нормально!!! Лучше бы пользовались бесплатными консультациями пользователей и постепенно вносили правки!!!
Цитата(Salex @ 28.08.20, 16:06)
Цитата - отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля.
А вы не обратили внимание, что после ввода нескольких документов много полей заполняются сами как бы угадывая что должно быть - это подсистема автозаполнения по статистике, которая пришло на смену жесткому указанию значений по-умолчанию.
Не всегда угадывание срабатывает верно! но я имел ввиду другое, при больших объемах ввода первичных документов, Заполнение таких полей как "Наша фирма", "Подразделение по умолчанию" и "Склад по умолчанию" думаю должны реализовываться автоматически! постоянное клацанье для выбора занимает также достаточно времени!! А программа как бы для автоматизации!!!
По банку не хватает проводки Дт 6442 Кт 6441 При получении Налоговой накладной Дт 6412 Кт 6442 (Это есть) При оприходовании товаров (второе событие)не хватает проводки Дт 6441 Кт 631
Вариант Б при реализации
По банку не хватает проводки Дт 6431 Кт 6432 При выписке Налоговой накладной Дт 6432 Кт 6412 (Это есть) При отгрузке товаров (второе событие)не хватает проводки Дт 70_ Кт 6431
Не понимаю почему это не реализовать как положено, и как это уже имеется в других конфигурациях BAS!!!
Может кто знает, на каких форумах присутствуют представители разработчиков, чтоб можно было им хоть как-то это донести!!!
У меня в ФБ (ссылка выше) есть ответ разработчиков, ну раз не нашли опубликую здесь чтоб этот вопрос закрыть:
Цитата
ответ разработчиков: Регистрация авансов для целей НДС не производится. Расчет 1-го события конечно же производится. Речь идет только о проводках по счетам 643/644. Эти проводки при получении/выплате аванса не формируются. Ни в самих платежных документах, ни в регламентных при закрытии месяца. По исходящему НДС проводки формируют два вида документов: - РТиУ и др. документы-накладные: Дт 70 Кт 6432 - НН (П2): Дт 6432 Кт 6412 При получении аванса проводки по НДС не формируются, но в соответствии с НКУ выписывается НН, причем выписывается автоматически. Бухгалтер ее проверяет, при необходимости изменяет номенклатурный состав и ставку НДС - все это непосредственно в НН, а не в промежуточном документе. НН формирует проводку с кредита счета 6432 - соответственно до отгрузки НО учитывается по кредиту 6432. Мы привыкли 6431, но Инструкция 291 определяет только счет 643 и не ограничивает нас в создании субсчетов. В баланс счета 6431 и 6432 попадают одинаково. Счет 6431 используется в единственном случае - передача на комиссию. Но при передаче на комиссию НО возникают на пустом месте, без выручки, без дебиторки. Там НО просто не с чем больше корреспондировать. При этом, без всякой связи с проводками по 643, расчет 1-го события и полноту выписки НН можно проверить отчетом "Анализ НО". Отчет - наша гордость, очень информативен. Аналогичная ситуация по полученным НН. По неполученным НН по авансам ситуация несколько другая. Проводка Дт 6442 Кт 6441 не формируется. При наличии такой проводки сумма неполученной НН отражается в балансе трижды: в составе аванса выданного; как прочий актив; как прочее обязательство. Без такой проводки - только в составе аванса выданного, т.е. трактуется как еще невыполненное обязательство поставщика. При наличии СЭА и СМКОР (который не отменен, а приостановлен на 1 кв.) - это на самом деле оно и есть. В связи с изменениями ЗУ о бухучете, мы ждем от Минфина таксономию финотчетности. Вот дождемся хотя бы проект - тогда и будем знать точно, как следует неполученные НН по авансам отражать в балансе. Полный список неполученных НН. в т.ч. по авансам выданным, можно увидеть как в отчете "Анализ НК", так и в списке "Входящие налоговые документы" на закладке "К получению".
То есть, ситуация до разработчиков была мною успешно донесена, полный текст переписки по ссылке [необходимо зарегистрироваться для просмотра ссылки] От себя хочу добавить комментарий грамотного внедренца под постом с перепиской:
Цитата
После утраты действия в прошлом году Инструкции по НДС проводка на 6431 и 6441 утратила обоснование. При составлении фин отчётности по МСФО, эта проводка игнорируется и не попадает в баланс, поскольку остаток на 6431 (ну и 6441) не соответствует понятию актива или обязательств. А поскольку у нас национальный рег учёт и отчётность подтянули подтянули под МСФО, то и в отчётности по ПСБУ, в принципе, ей не место. В чем линия поддержки права.
Бывалый @ Сегодня, 9:27
, По поводу
Цитата
Кстате на заметку в конфигурации BAS бухгалтерия нет вопросов к этому блоку
если открыть BAS бухгалтерия в конфигураторе мы обнаружим что учетная модель осталась такая же как в старой бухгалтерии на обычных формах, только формы переделали. В BAS КУП (BAS ERP) полностью изменили модель бух учета и учета НДС
НН формирует проводку с кредита счета 6432 - соответственно до отгрузки НО учитывается по кредиту 6432. Мы привыкли 6431
Мы не привыкли, а 6431 используется по документу расходная накладная, а не Налоговая накладная!!! И это при втором событии "Отгрузка"
Цитата(Salex @ 01.09.20, 20:01)
Счет 6431 используется в единственном случае - передача на комиссию.
Это кто придумал, что этот счет используется именно для комиссии???
Цитата(Salex @ 01.09.20, 20:01)
Проводка Дт 6442 Кт 6441 не формируется. При наличии такой проводки сумма неполученной НН отражается в балансе трижды: в составе аванса выданного; как прочий актив; как прочее обязательство.
Трижды??? Нет это операция происходит в ТРЕХ документах : Банковская выписка - Налоговая Накладная - Приходная/Расходная накладная. При этом есть контроль НДС не только в отчете анализ счета, а по счетам учета!!!
Нужно услышать тысячи бухгалтеров, которые проверяют первое событие по 6432/6442!!! и пользуются отчетом "Обороты счета" в разрезе даты
Так же пытался достучаться с вопросом заполнения в налоговых накладных в табличной части товаров - объекта расчетов!!! Нет контроля в объектах расчета по значению "Контрагент".
При ручном выборе в строках "Объекта расчетов" - например выбрав договора, в списке высвечивает все договора из базы по всем клиентам!!! И есть вероятность присутствия в одном документе разных договоров!!! Далее при формировании отчета по Анализу НДС - документы (первое событие) и Налоговая накладная в разных строках, ввиду не контроля именно этого поля!!!
Бывалый @ Сегодня, 17:02
, со мной дискутировать смысла нет (я обычный внедренец-фрилансер, даже во франче не работаю), а разработчики в итоге завершили переписку ответом:
Цитата
Наш ответ остается без изменений. При необходимости Вы можете самостоятельно разработать и внести необходимые изменения в код конфигурации под индивидуальные требования Вашего пользователя.
(подробности по ссылке выше) так что думайте сами, решайте сами, использовать этот ПП или нет.
P.S. Если предоставленная мной информация оказалась вам хоть немного полезной, поблагодарите, плиз, кнопкой "палец вверх" возле моей аватарки.
dav.dp @ Вчера, 11:30
, Тему не бросил. По состоянию на сегодня изменений в освещенных проблемах нет, вендор выпустил еще в июле релиз с "косметическими" исправлениями, и все. Освещенные проблемы вендор не регистрирует как ошибки и, соответственно, ничего с ними не делает уже на протяжении почти 3х лет с момента их выявления в конфигурации ERP (я обращался тогда на ЛК). Сейчас изучаю вопрос по отчету 1ДФ. Как только досконально проработаю, будет небольшой отчет о работе фукнционала. При выходе релизов, если какой-то вопрос решат - я обязетльно напишу, как было с п.4
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!
Особенности конфигурации BAS КУП 
10.12.19, 19:58
