Версия для печати темы (https://pro1c.org.ua/index.php?s=1826cc69bbff92be543c7d89e96fa93e&showtopic=55642)

Нажмите сюда для просмотра этой темы в обычном формате

Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7 _ BAS Комплексное управление предприятием _ Особенности конфигурации BAS КУП

Автор: Salex 10.12.19, 19:58

Добрый день! Наконец и у нас в Украине появились долгожданная 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С Специалст, а именно: НалоговоеНазначение - сущность того же класса что и СтатьяРасходов, только выше, то есть для "Обл. НДС" затраты ведутся по статьям: расходы на осн. производство, зарплата произв. персонала..., для "Пропорц. НДС": расходы на содержание помещения, расходы на транспорт..., для "Необл. НДС": расходы на поставку ПО. Таким образом НалоговоеНазначение целесообразно было бы сделать реквизитом справочника СтатьиРасходов, а не измерением регистра ПрочиеРасходы. Критики могут возразить, что пользователь может поменять реквизит НалоговоеНазначение у статьи расходов и в учете НДС будут большие проблемы, но это надо просто запретить делать для статей, по которым уже есть движения, например, перед записью проверить наличие движений в регистре ПрочиеРасходы по данной статье и отказать в изменении реквизита. При таком методе решения задачи, не нужно было бы дорабатывать российские алгоритмы рассчета с/с, распределения расходов на с/с ГП, а контроль изменения налогового назначения выполнять проверкой списания запаса на статью расходов (реквизит НалоговоеНазначение). К сожалению, украинские разработчики пошли по другому пути, возможно из-за решения другой более сложной задачи, либо же от недостатка квалификации.

Автор: Salex 11.12.19, 13:38

https://pro1c.org.ua/redirect.php?https://www.facebook.com/salex1c/posts/169912064049118

Автор: Acid 11.12.19, 14:27

Цитата(Salex @ 10.12.19, 20:58) *
либо же от недостатка квалификации.

С прискорбием отмечу, - чем дальше в лес, тем больше дров. и костылей.

Автор: andr_andrey 11.12.19, 16:51

Изначально рассматривали БАС только для УУ, с надеждой - а вдруг и по БУ будет нормально.
Спасибо за описание проблем.

Автор: Salex 11.01.20, 14:28

Еще обнаружен важный момент:
Отнести доп.расходы, связанные с приобретением товаров на первоначальную стоимость можно только на себестоимость всех товаров документа ПТУ. Нет возможности указать отдельные товары документа как это было в УПП/УТП. При этом ещё и проводки будут чуть другие: при отражении документа поступления доп.расходов дт28ДР/кт631, а при закрытии месяца дт281/кт28ДР. В принципе инструкции об использовании плана счетов это не противоречит, но бухгалтеру не нравится задвоенные обороты по счету 28.
Как вариант, можно настроить аналитику статьи доп.расходов не ПТУ, а ЗаказПоставщику, разбить товары на разные заказы, сделать одно ПТУ по нескольким заказам и отнести доп.расходы на конкретный заказ поставщику. Но это не более чем "костыль" по-сравнению с тем функционалом отнесения доп.расходов, который был в УТП/УПП. Разработчики пустили пыль в глаза многобразием настроек статей расходов и аналитик и под шумок убрали единственный рабочий вариант, который всех устраивал и которого сейчас невозможно на 100% добиться настройками текущего функционала.

Автор: Salex 03.03.20, 22:12

Чего-то ФБ удалил мою публикацию со ссылками на ответы ЛК. Перепубликовал: https://pro1c.org.ua/redirect.php?https://www.facebook.com/salex1c/posts/235929920780665

Автор: Salex 24.04.20, 22:48

п.4 исправлен в релизе 2.1.15.5. При оформлении операций импорта согласно методическим рекомендациям ИТС себестоимость товаров вычисляется корректно и формируются правильные бухгалтерские проводки.

Автор: Salex 07.05.20, 19:42

8. Аналитические отчеты по зарплате, формируются "...с точки зрения расчетчика а не бухгалтера: суммы учитываются по месяцам выплаты (и месяцам начисления), а не по датам, когда фактически была произведена выплата. Анализа сальдо с точки зрения бухгалтера не предусмотрено..." (подробнее см. ИТС, описание отчета "Задолженность по зарплате".
Объясню, что это значит:
- Начислили зарплату за Март
- Отразили выплату зарплаты за Март документом "Ведомость в банк" датой 6.04.20, указав в ведомости что это выплата зарплаты за Март (чтобы ведомость по кнопке Заполнить правильно заполнила суммы) как написано в метод.рекомендациях.
- Начислили зарплату за Апрель
- Отразили выплату зарплаты за Апрель документом "Ведомость в банк" датой 9.05.20
Формируем отчет "Анализ зарплаты по сотрудникам" за Апрель и видим пустые колнки сальдо на начало и сальдо на конец (хотя выплаты приходятся на начало следующего месяца!)
Формируем отчеты "Расчетный листок", "Задолженность по зарплате" - по полям "Сальдо на начало" и "Сальдо на конец" - все то же самое - пусто!
Формируем отчет "Расчетная ведомость" - в нем колонки сальдо вообще не предусмотрены smile.gif

Автор: Salex 19.05.20, 15:33

9. Если в один и тот же день по нескольким заказам без указания договора (или когда договор совпадает) наступает событие, требующее выписки налоговой накладной, налоговая накладная формируется одна на всю сумму с общим списком продукции. ИТС отвечают что "так не запрещено законодательством".

Автор: Salex 31.07.20, 13:53

10. В УТП/УПП в карточке закрытия месяца было подменю "Печать", из которого бухгалтер формировал справки-расчеты по переоценке вал.средств, списанию РБП, распределению косв.расходов, калькуляциям, себестоимости продукции. В КУП (и ERP) такого не нет.
В рос.бух3 нашел отдельное подменю в разделе Операции/Закрытие месяца/Справки-расчеты.
Про бухгалтера снова забыли. При покупке с целью ведения регламентированного учета следует предусмотреть затраты на написание этих отчетов, т.к. бухгалтеру они обычно нужны.

p/s
Начиная с 30.07.20 программа получила новое название "Business automation software for іntegrated enterprise management". Но на перечисленных проблемах это никак не отразилось: все актуально

Автор: Salex 22.08.20, 21:15

11. Зарплата. Есть, но фактически не работает опция выплаты командировочных, отпускных, больничных в режиме "С авасном" (в одной ведомости): в ведомость правильно попадают НДФЛ, ВЗ, ЕСВ, но в поле "К выплате" попадает только сумма аванса, которая разбивается между строками зарплаты и прочих начислений, сумма же этих прочих начислений не учитывается. В результате, чтобы сделать выплату, бухгалтеру приходится делать отдельные ведомости на выплату начисления (комаднировка, отпускные) в режиме "В межрасчетный период". Данная ошибка зарегистрирована под номером 52999 от (ВНИМАНИЕ!) 22.07.2018 (2 года не могут исправить!)

Автор: Бывалый 26.08.20, 14:56

Всем добрый день!!!
По совету программиста выбрали эту конфигурацию !!!!
Ключевые моментами стали :
- возможность работы в облаке
- подключение с помощью планшета
- рассылка отчетов на e-mail
- мониторинг финансовых показателей
- самостоятельное небольшое конфигурирование системы.

Из этого вышло :

- Нестандартный документооборот
- множество доработок
- одновременная доработка как обслуживающей компанией так и разработчиками одних и тех же вопросов!!!
- НДС вообще случайный человек наверное делал (нарушение отражения бухгалтерских записей по первому событию, в случае когда первое событие "ОПЛАТА"
- отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля.
- поле "ПОДРАЗДЕЛЕНИЕ" в разных документах, тянет с разных справочников!!!
- отсутствие нормальных управленческих отчетов, которые несут реальную картину на предприятии

В реалии урезанная версия конфигурации ERP, должна соответствовать профессиональной программе, для ведения как бухгалтерского, так и управленческого учета.

Автор: Salex 28.08.20, 16:06

Бывалый @ 26.08.20, 15:56 * ,

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

В этом как бы основная проблема. Это вам не 7.7 чтобы доработки делать. Данная коробочная конфигурация довольно системно реализована и имеет кучу настроек. Лезть в доработку сложной системы не имея технической документации о ее принципиальной схеме может либо очень опытный разработчик, либо дилетанты чтобы подзаработать". Тут аналогия ВАЗ2101 и Лексус LX350: поставить стеклоподъемники в ВАЗ можно в любом гараже и они будут там очень даже неплохо работать, но лезть устанавливать стеклоподъемники в лексус не разобравшись может быть очень дорого, ведь они там уже есть, нужно разобраться как их использовать, и привыкнуть к кнопкам, а не заказывать альтернативные стеклоподъемники из-за того что форма рычажка вам не удобна.

Цитата
- отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля.

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

Цитата
- НДС вообще случайный человек наверное делал (нарушение отражения бухгалтерских записей по первому событию, в случае когда первое событие "ОПЛАТА"

здесь вы абсолютно правы, если хотите максимально погрузиться в вопрос - ссылка на мой ФБ выше. Разработчики считают что НДС считается у них идеально ))

Автор: Бывалый 01.09.20, 8:27

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) *
Цитата
- отсутствие возможности установления Констант, которые заведомо должны существовать в любой конфигурации - по каждому документу выбираем и заполняем поля.

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


Не всегда угадывание срабатывает верно! но я имел ввиду другое, при больших объемах ввода первичных документов, Заполнение таких полей как "Наша фирма", "Подразделение по умолчанию" и "Склад по умолчанию" думаю должны реализовываться автоматически! постоянное клацанье для выбора занимает также достаточно времени!! А программа как бы для автоматизации!!!

Автор: Salex 01.09.20, 20:01

Бывалый @ Сегодня, 9:27 * ,

Цитата
Вариант А при закупке

По банку не хватает проводки Дт 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 кв.) - это на самом деле оно и есть.
В связи с изменениями ЗУ о бухучете, мы ждем от Минфина таксономию финотчетности. Вот дождемся хотя бы проект - тогда и будем знать точно, как следует неполученные НН по авансам отражать в балансе.
Полный список неполученных НН. в т.ч. по авансам выданным, можно увидеть как в отчете "Анализ НК", так и в списке "Входящие налоговые документы" на закладке "К получению".

То есть, ситуация до разработчиков была мною успешно донесена, полный текст переписки по ссылке https://pro1c.org.ua/redirect.php?https://www.facebook.com/groups/332141990978726/?post_id=419037202289204
От себя хочу добавить комментарий грамотного внедренца под постом с перепиской:
Цитата
После утраты действия в прошлом году Инструкции по НДС проводка на 6431 и 6441 утратила обоснование. При составлении фин отчётности по МСФО, эта проводка игнорируется и не попадает в баланс, поскольку остаток на 6431 (ну и 6441) не соответствует понятию актива или обязательств. А поскольку у нас национальный рег учёт и отчётность подтянули подтянули под МСФО, то и в отчётности по ПСБУ, в принципе, ей не место. В чем линия поддержки права.


Бывалый @ Сегодня, 9:27 * ,
По поводу
Цитата
Кстате на заметку в конфигурации BAS бухгалтерия нет вопросов к этому блоку

если открыть BAS бухгалтерия в конфигураторе мы обнаружим что учетная модель осталась такая же как в старой бухгалтерии на обычных формах, только формы переделали.
В BAS КУП (BAS ERP) полностью изменили модель бух учета и учета НДС

Автор: Бывалый 02.09.20, 16:02

Цитата(Salex @ 01.09.20, 20:01) *
НН формирует проводку с кредита счета 6432 - соответственно до отгрузки НО учитывается по кредиту 6432. Мы привыкли 6431

Мы не привыкли, а 6431 используется по документу расходная накладная, а не Налоговая накладная!!! И это при втором событии "Отгрузка"

Цитата(Salex @ 01.09.20, 20:01) *
Счет 6431 используется в единственном случае - передача на комиссию.

Это кто придумал, что этот счет используется именно для комиссии???

Цитата(Salex @ 01.09.20, 20:01) *
Проводка Дт 6442 Кт 6441 не формируется. При наличии такой проводки сумма неполученной НН отражается в балансе трижды: в составе аванса выданного; как прочий актив; как прочее обязательство.


Трижды??? Нет это операция происходит в ТРЕХ документах : Банковская выписка - Налоговая Накладная - Приходная/Расходная накладная.
При этом есть контроль НДС не только в отчете анализ счета, а по счетам учета!!!

Нужно услышать тысячи бухгалтеров, которые проверяют первое событие по 6432/6442!!! и пользуются отчетом "Обороты счета" в разрезе даты

Так же пытался достучаться с вопросом заполнения в налоговых накладных в табличной части товаров - объекта расчетов!!! Нет контроля в объектах расчета по значению "Контрагент".

При ручном выборе в строках "Объекта расчетов" - например выбрав договора, в списке высвечивает все договора из базы по всем клиентам!!! И есть вероятность присутствия в одном документе разных договоров!!!
Далее при формировании отчета по Анализу НДС - документы (первое событие) и Налоговая накладная в разных строках, ввиду не контроля именно этого поля!!!

Автор: Salex 02.09.20, 19:33

Бывалый @ Сегодня, 17:02 * ,
со мной дискутировать смысла нет (я обычный внедренец-фрилансер, даже во франче не работаю), а разработчики в итоге завершили переписку ответом:

Цитата
Наш ответ остается без изменений.
При необходимости Вы можете самостоятельно разработать и внести необходимые изменения в код конфигурации под индивидуальные требования Вашего пользователя.

(подробности по ссылке выше)
так что думайте сами, решайте сами, использовать этот ПП или нет.

P.S.
Если предоставленная мной информация оказалась вам хоть немного полезной, поблагодарите, плиз, кнопкой "палец вверх" возле моей аватарки.

Автор: Бывалый 03.09.20, 8:43

Salex @ Вчера, 19:33 * ,
Спасибо, но ответ не устраивает!!
Движемся дальше!

Автор: dav.dp 12.10.20, 10:30

Всем привет! Автор, не забрасывайТЕ тему, нам тоже актуально.


 ! 

https://pro1c.org.ua/index.php?act=announce&id=2: 1
 

Автор: Salex 13.10.20, 13:17

dav.dp @ Вчера, 11:30 * ,
Тему не бросил. По состоянию на сегодня изменений в освещенных проблемах нет, вендор выпустил еще в июле релиз с "косметическими" исправлениями, и все. Освещенные проблемы вендор не регистрирует как ошибки и, соответственно, ничего с ними не делает уже на протяжении почти 3х лет с момента их выявления в конфигурации ERP (я обращался тогда на ЛК). Сейчас изучаю вопрос по отчету 1ДФ. Как только досконально проработаю, будет небольшой отчет о работе фукнционала. При выходе релизов, если какой-то вопрос решат - я обязетльно напишу, как было с п.4

Цитата(Salex @ 24.04.20, 23:48) *
п.4 исправлен в релизе 2.1.15.5.

Автор: Salex 16.10.20, 13:11

12. Регл.отчет 1ДФ. Данный отчёт подают все компании, у которых есть хозяйственные отношения с физическими лицами, в том числе ФОП. В части зарплаты, когда начисления облагаются НДФЛ отчет заполняется верно. Для начислений, не облагаемых НДФЛ (декретные, необл.мат.помощь) не заполняется суммы начисленного и выплаченного дохода по строке Военный сбор.
При регистрации документом РегистрацияПрочихДоходов выплат физ.лицам по договорам с ними (напр, аренда автомобиля), в 1ДФ попадает указанная сумма в обе колонки (сумма начисленного и сумма выплаченного дохода).
При регистрации документом РегистрацияПрочихДоходов выплат поставщикам-ФОПам, в отчет в сумму начисленного и сумму выплаченного дохода попадает одна и та же сумма, хотя в реальности с поставщиками-ФОПами есть сумма начисленного дохода (отражена документом "ПоступлениеТоваровУслуг") и сумма выплаченного дохода (отражена платежными документами АО, Платежка), и эти суммы часто отличаются. Поэтому в части отражения доходов ФОПов в 1ДФ типовой функционал работает корректно только в частном случае: когда с ФОПом документы оплаты и акты оформляются в одном и том же квартале. Иначе отчет нужно делать ручками, либо заказывать доработку.

Автор: Salex 22.10.20, 19:32

13. При расчете себестоимости готовой продукции есть очень важный нюанс в учетной модели, если включено использование серий материалов и готовой продукции: при выпуске нескольких серий готовой продукции и списании нескольких разных серий материалов их себестоимость "усредняется". Пример: оформляем док ВыпускПродукции на Изделие1 серия 0001, оформляем еще 1 док ВыпускПродукции на Изделие1 серия 0002. Оформляем документ СписаниеЗатратНаВыпуск на основании первого документа выпуска, указывая в материалах, Материал1 Серия М1001 количество 1 шт и Материал2 Серия М2001 количество 1 шт. Оформляем еще 1 документ СписаниеЗатратНаВыпуск на основании второго документа выпуска, указывая в материалах, Материал1 Серия М1002 количество 1 шт и Материал2 Серия М2002 количество 1 шт. Закрываем месяц, смотрим отчет по фактической себестоимости выпущенной продукции с детализаций по сериям и наблюдаем картину:
Изделие1 0001 количество 1 шт., материалы: Материал1 Серия М1001 количество 0,5 шт, Материал1 Серия М1002 количество 0,5 шт, Материал2 Серия М2001 количество 0,5 шт, Материал2 Серия М2002 количество 0,5 шт. Таким образом хотя в учете мы явно прописали какая серия какого материала идет на какую серию изделия, механизм расчета себестоимости это дело "усреднил". Та же ситуация наблюдается и с возвратными отходами. Для многих клиентов такой функционал оказывается неприятным сюрпризом.

Автор: Salex 23.10.20, 19:31

14. Не доделана печатная форма Авансового отчета:
На 2й странице бланка не заполняется колонка ДебетРахунка, и не выводится отдельной строкой НДС при отражении расходов с НДС. Полез в код, в макете в данной колонке даже параметра нет. Глянул в УТП - в макете есть 2 области (Строка и СтрокаСНДС), и есть параметр СчетБу, таким образом в УТП печатная форма формируется с указанием сумм и счетов. Решить вопрос по-быстрому не получается, проводки явно не связаны со строками АО (в АО есть 2 табличные части ПрочиеРасходы и ОплатаПоставщикам и не понятно с какой строки какой ТЧ сформировалась проводка). Похоже, разработчики не смогли решить данную задачу и просто бросили как есть. Доработка вылилась в 3 часа.

Автор: Salex 28.10.20, 14:42

15. Механизм запрета редактирования по дате запрета имеет серьезный изъян. РегистрСведений КурсыВалют не включен в механизм контроля по дате запрета, но при изменении курса "слетает" закрытие месяцев начиная с даты, которая была поставлена в курсе валют. На днях добавили еще одну валюту в справочник, поставили ей курс 1 на дату 1980, после этого слетело закрытие всех месяцев за 2 года работы - бухгалтера пришлось откачивать 47046430.gif Уточню: по данной валюте не было никаких движений, ее просто добавили и поставили задним числом курс, всё.

Автор: mbyura 13.11.20, 14:12

Є проблема з розрахунком резервів по відпустках ... Для використання резервів відпусток є документ НачислениеОценочныхОбязательствПоОтпускам який робить рухи в регістр відомостей РасчетРезерваОтпусков в якому вказуються суми на резерв із зарплата і сума страхових внесків з цього резерву... В проводки цього документу на рахунок 471 попадають разом сума резерву з зарплати і сума страхових внесків що є правильно.... Потім документ відпустка аналізує цей регістр і знімає тільки суму резерву із зарплати, а суму страхових внесків - ні. В описі вказано що це повинний робити документ нарахування зарплати. В конфігуратор я знайшов в модулі проведення нарахування ЗП такий текст:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
Документы.НачислениеЗарплаты.ПровестиПоУчетам(Ссылка, РежимПроведения, Отказ, Неопределено, Движения, ЭтотОбъект, ДополнительныеСвойства);
// Резервы отпусков 3286
ДанныеДляПроведения = ОтражениеЗарплатыВУчете.НоваяСтруктураРезультатыРасчетаЗарплаты();
ДанныеДляПроведения.НачисленияУдержания = Движения.НачисленияУдержанияПоСотрудникам.Выгрузить();
ДанныеДляПроведения.СтраховыеВзносы = Движения.СтраховыеВзносыПоФизическимЛицам.Выгрузить();
СтрокаСписокТаблиц = "НачисленнаяЗарплатаИВзносы";
// Конец
КонецПроцедуры

Тобто ніякої обробки резерву відпусток немає. Вирішив проблему дописанням свого блоку проведення відпусток де розраховую ФОП і порівнюю з поточним залишком.... після чого документ формування проводок по ЗП робить правильні рухи

Немає методу нарахування амортизації ВидыТМЦВЭксплуатации.МалоценныйНеоборотныйАктив 50/50. При введені в експлуатацію списує одразу всю суму хоча в російській версії це реалізовано!!!

Для цього випадку створив обробник перед записом регістру бухгалтерії де спочатку змінюю рухи документа ВводОстатков списую тільки 50% а другу половину в документі СписаниеИзЭксплуатации

Автор: kievanton 04.12.20, 6:59

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

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

Документ "Списание безналичных ДС" иногда не делает движений по регистру накопления "НДС: Расчет налогового кредита", причем выполняется это произвольным образом, закономерности нет. И для исправления ситуации документ нужно распровести, затем провести и отразить в рег учете.

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

Нет возможности списания выданного контрагенту займа.

Система при проведении/отражении списания денежных средств с видом операции выплата по зарплатным проектам/выплаты по лицевым счетам, не всегда делает движение по регистру сведений "Сведения об оплате ведомостей на выплату заработной платы"

Система не позволяет формировать Инвентаризационные ведомости по безналичным денежным счетам и Дебиторско-Кредиторской задолженности с контрагентами.

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

Автор: dav.dp 11.12.20, 10:48

Всем добрый день! Добавлю и я кое-что в тему.
В разделе «Финансовый результат и контроллинг» отчет "Управленческий баланс" вот такая ошибка:


 ! 

https://pro1c.org.ua/index.php?act=announce&id=2: 8
 


Склоняемся с коллегами к ошибке в конфигурации, т.к. конфа на поддержке, и мы ничего не доделывали. Исправил следующим методом.
1. Сохранил как внешний отчёт.
2. В СКД на закладке «Параметры» исправил параметры «АктивыМинусПассивы» и «СтрокаБалансНеНарушен» - изменил тип с неограниченной длины на 250 символов.
3. В режиме предприятия выключил видимость у старого отчёта, и подключил внешний.


В разделе «Финансовый результат и контроллинг» отчет "Монитор целевых показателей(коротко)". Выполнение отчёта запускается автоматически, при нажатии команды в разделе. Вылезает такая ошибка:


 ! 

https://pro1c.org.ua/index.php?act=announce&id=2: 8
 


Над ней сейчас работаем.

Автор: Salex 14.12.20, 1:39

16. Зарплата. Система неправильно считает дни компенсации отпуска при увольнении, если увольнение происходит в середине месяца.
Алгоритм расчета заработанных дней отпуска реализован согласно российского, а не украинского законодательства, а именно: количество дней положенного отпуска делится на 12 (месяцев) и в средине месяца начисляется полученное значение, например при ежегодном отпуске 24 дня, количество в месяц 2 дня, начисляется каждый месяц 15-го или 16-го числа в зависимости от количества дней в месяце. Таким образом если человек увольняется 13-го числа согласно укр.законодательства он заработал еще 1 день за период с 01 по 13 число, а согласно заложенного алгоритма - нет, а если уволняется 17 го числа, по укр.закон-ву он заработал все еще 1 день, но по заложенному алгоритму получает 2 дня.
Бухгалтеру нужно вручную пересчитывать дни компенсации отпуска, иначе реально получить штраф за недорасчет с уволившимся сотрудником.

Автор: Salex 23.02.21, 0:41

В релизе 2.1.18.3 все выявленные проблемы по-прежнему актуальны

Автор: Vofka 17.03.21, 10:37

Релиз 2.1.13.2, но думаю, что в поздних то же самое, т.к. есть и более важные проблемы, которые не исправлены, судя по сообщениям выше.
Отправка смс через провайдера TurboSMS не работает. Причем для этого все есть и сам модуль рабочий. Но задание, которое выполняет отправку СМС передает пустое ИмяОтправителя, хотя без него отправка через TurboSMS не работает.

РезультатОтправки = ОтправкаSMS.ОтправитьSMS(МассивНомеров, ТекстСообщения, "", ОтправлятьВТранслите); // "" это имя отправителя

Если вместо "" передать корректное имя - все работает.

Добавлено в 15:40.
Оказалось, это не все. В модуле отправки через Турбо есть косяк, из-за которого СМС не фиксируется, что СМС была отправлена и с каждой отправкой все СМС повторно отправляются. Это какой-то позор. faceoff.gif

Автор: Salex 17.03.21, 17:36

Vofka @ Сегодня, 11:37 * ,
Вы думали они просто так имя отправителя хардкорно потерли)) это они так "заглушили" алгоритм который ниасилили) Очень часто такое встречал, общее правило при правке типовых ошибок ERP/КУП - если кажется что "вот тут исправишь и все заработает" - жди подвоха wink.gif

в релизе 2.1.19.3 все по-старому (стабильность smile.gif )

Автор: Vofka 17.03.21, 20:50

Цитата(Salex @ 17.03.21, 17:36) *
если кажется что "вот тут исправишь и все заработает" - жди подвоха

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

Автор: optimusprinceps 24.03.21, 14:27

Salex @ 10.12.19, 19:58 * ,

Цитата(Salex @ 10.12.19, 19:58) *
на динамический набор нельзя выписать налоговую накладную


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

Автор: Salex 26.03.21, 17:44

optimusprinceps @ 24.03.21, 15:27 * ,
Вы ж уточните, что налоговая накладная у вас выписалась на номенклатуру комплектующих. Описанная проблема касалась случая, когда клиент хочет видеть в печатных накладных набор одной строкой: мы создаем набор, в его настройках указываем "печатать только набор". Выписываем счет - там одна строка набора, выписываем расходную накладную - там одна строка набора, выписываем налоговую накладную - там несколько строк комплектующих. В результате налоговая накладная не соответствует счету и расходной накладной.

ничего не исправили, в релизе 2.1.20.1 все по-старому (стабильность smile.gif )

Автор: Vofka 01.04.21, 9:51

Понадобился значит учет залоговой тары. Было проведено некоторое исследование, которое показало, что во многих сущностях есть реквизит ТребуетсяЗалогЗаТару, который даже выведен на формы, но уже на самих формах он скрыт. Причем скрыт так, что без вмешательства в конфигурацию включить его нельзя. Аналитик говорила, что в видео, которые она смотрел по этой теме, этот реквизит на формах есть (я думаю, что она смотрела видео по российской ERP). При всем при этом если проводить документ с этим флагом и без, то движения отличаются. Ситуация была непонятна и вызывала определенные вопросы по учету залоговой тары. Ответ на эти вопросы такой:

Цитата
Залог за тару, влияющий на расчеты с клиентом/поставщиком, не поддерживается и не планируется.

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

Получение залога рекомендуется отражать платежным документом с видом операции "Прочее поступление" в корреспонденции со статьей пассивов. Для этого должна быть включена ФО "Учитывать прочие активы и пассивы".

Автор: Тираэль 29.05.21, 15:00

Статья мне понравилась.

Но видать переход на этот костыль Беса очень сложный((

Что Выгрузка данных.epf в комплекте кривая и сама на себя ругается что как не пробуй выгрузить то всё пусто((

П.С. Не мала баба клопоту — купила порося.

Автор: glavbuh1976 07.06.21, 8:17

Salex @ 07.05.20, 20:42 * ,
С этой же проблемой столкнулись в BAS CORP.
По заработной плате и кадрам очень много косяков.
Я жалею что поменял ЗУП на BAS CORP...

Автор: andr_andrey 09.06.21, 9:17

Цитата(glavbuh1976 @ 07.06.21, 9:17) *
Я жалею что поменял ЗУП на BAS CORP...

Как будто ЗУП образец без косяков? Ведение декретчиц, инвалидов и периоды командировок/отпусков - вечная консультация новых пользователей ЗУП.

Автор: Salex 02.07.21, 17:12

17.
Глюк с восстановлением последовательности расчетов перед выпиской НН и заполнение НН:
бывают такие ситуации, когда после актуализации движения по налоговому регистру не сформированы, хотя признака что последовательность сбита нет, так бывает например когда меняют в реализации Контрагента или Договор и не распроводят перед этим документ.
В таком случае, когда дальше выписываются налоговые по предоплатам, но есть реализация позже (второе событие) и в ней не все в порядке с заполнение налоговых регистров получаем налоговую не на номенклатуру заказа, а на служебную.

Автор: Salex 10.08.21, 18:07

в версии 2.1.23.2 из выявленных проблем ничего не исправлено, в конфе куча исправлений украинских синонимов

Автор: Salex 08.09.21, 18:25

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

Автор: Salex 26.10.21, 15:48

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

Автор: prog_sap 18.11.21, 22:14

BAS КУП 2.1.24.3
Отсутствует возможность ведения учета по заказам клиента, а именно в плане счетов нет возможности добавить 3-е субконто заказ клиента.
Программой предусмотрено ведения учета только в разрезе контрагент/договор.
Например: Отчет Анализ субконто. Нет возможности сформировать в разрезе заказ как в УТП/УПП

Автор: Vofka 19.11.21, 9:18

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

Автор: Salex 23.11.21, 15:29

Цитата(prog_sap @ 18.11.21, 23:14) *
BAS КУП 2.1.24.3
Отсутствует возможность ведения учета по заказам клиента, а именно в плане счетов нет возможности добавить 3-е субконто заказ клиента.
Программой предусмотрено ведения учета только в разрезе контрагент/договор.
Например: Отчет Анализ субконто. Нет возможности сформировать в разрезе заказ как в УТП/УПП

Такая постановка задачи для ERP/КУП не совсем корректна.
В ERP/КУП (как и в рос ERP/КА), принципиально отличная от УПП/УТП модель бух.учета, а именно: он теперь так сказать "вторичный". Есть Оперативный учет ("первичный"), данные из которого трансформируются в управленческий (не путать с черным учетом) и бухгалтерский учет, причем в некоторых случаях эта трансформация происходит при закрытии месяца. Наиболее показателен в этом плане документ РеализацияТоваровУслуг(РТУ). Если этот документ, созданный в текущем месяце по текущей продаже отразить в БУ мы увидим, что в проводке "списана готовая продукция на себестоимость продажи дт90кт26" стоит пустая сумма. Учетной моделью подразумевается, что для текущих учетных целей пользователи используют оперативный учет и все его отчеты, а в конце месяца, после закрытия месяца получают бухгалтерский учет, и если в оперативном учете вели учет верно, бухгалтерский учет априори будет выполнен верно и останется только сформировать и подать отчетность (именно поэтому весь оперативный учет по организации должен быть белым).

В старых же системах УПП/УТП был параллельный управленческий и бухгалтерский учет и документ при оперативном проведении формировал все необходимые проводки.
Почему в новых системах сделано так как сделано? Нужна была оптимизация. Тут 2 направления:
1. Партионный учет: в старых системах приходилось перепроводить документы если нарушалась последовательность партионного учета. Это огромные ресурсы. Новая модель этого не требует: решается система линейных уравнений и результат "себестоимость выбытия" записывается в регистр и исправляются движения только у некоторых документов
2. Нагруженная система: Когда работают десятки пользователей, а подавляющее число документов проводится по "тяжелому" бухгалтерскому регистру, возникает конкуренция за запись данных в этот самый регистр, поэтому в таких системах пользователи получают ошибки связанные с блокировкой данных транзакцией другого пользователя. Оперативный учет разнесен по разным регистрам, и в нем конкурируют за таблицы только пользователи, выполняющие однотипные функции (таких пользователей в разы меньше)

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

Автор: Salex 31.01.22, 20:31

19. При продаже товара по цене ниже себестоимости по закону обязаны сделать НалоговуюНакладную на условную продажу и доначислить НДС. Система генерирует такую НН на правильную сумму, но вот этот документ делает проводку дт704/кт6412, хотя должна быть проводка дт949/кт6412 (http://tax-expert.in.ua/uk/publications/265-buhoblik-perevishennya-pdv/?fbclid=IwAR16Jx4OPn-Sc69JlxEdmdGN3RV43OAy-xXPs3kTuEsCUxWwiIXDwN6x1fE, https://pro1c.org.ua/redirect.php?https://consulting.dtkt.ua/ru/taxation/pdv/5719?fbclid=IwAR3eJEMdUQ_E0fCTOEPthwUuvPXAuDdhGAUHZ_tT_NMB7InzoglNgAizCyM)

Автор: Salex 13.05.22, 15:41

В релизе 2.1.26.2 от 18.04.2022 все по-старому.
В декабре 2021го в среде разработчиков были разговоры что в мае 2022 станет доступным обновление ERP до версии 2.5, а за ней и производных конфигураций (КУП. УТ), но этого не случилось.
Вместо этого в свете последних событий многие в партнерской сети всерьез задумались об альтернативах.
Этот процесс был возглавлен одним из партнеров (TG.Consulting), направившим коллегам письмо следующего содержания:
Члени Спілки Автоматизаторів Бізнесу. Ви продаєте та супроводжуєте російське програмне забезпечення (BAS = 1C).
Будемо відвертими, частина доходів від цієї діяльності йде в росію і вертається в Україну у вигляді бомб на житлові квартали, школи та лікарні.
Ми хочемо зберегти Ваш бізнес у майбутньому та позбавити вас моральних докорів. Тому пропонуємо партнерську програму від TG Consulting по продукту SAP Business One.
Ми допоможемо Вашій компанії переорієнтуватись на SAP Business One, а Вам зберегти свій бізнес.
Деталі, після реєстрації.
Сошніков Ігор,
Слава Україні!!!

P.S. Я тоже забрасываю эту тему, констатирую факт, что конфигурации ERP/КУП ограничено работоспособны, какого-либо улучшения в обозримой перспективе не предвидится, перспектива внедрения данных продуктов сопряжена с большим риском потери инвестиций.

Автор: andr_andrey 13.05.22, 17:23

Цитата(Salex @ 13.05.22, 16:41) *
перспектива внедрения данных продуктов сопряжена с большим риском потери инвестиций.

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

Автор: АлексВ 15.06.22, 16:47

Доброго дня!
Так чем дело закончилось по отображению авансовых оплат поставщику?
На мой взгляд:
1.Оплатив аванс покупатель получает Право , а у поставщика возникает Обязательство на выписку налоговой накладной.(Перша подія)
Проводки у покупателя:
Дт3711 Кт311 1200 грн. Произведена оплата по счету №1 в том числе НДС 200 грн.
Дт6442 Кт6441 200 грн. НДС
Дт 6442(Налоговый кредит неподтвержденный) - отображает сумму долга покупателя по передачи налогового кредита из реестра EДР НДС ( выписать и зарегистрировать ПН). Остаток в 200 грн. по Дт 6442 используется для учета-выявления неполученных вовремя налоговых накладных от поставщика.

Почему нужно использовать Дт 6442 ?

В понимании стандарта "Національне положення (стандарт) бухгалтерського обліку10 "Дебіторська заборгованість" https://pro1c.org.ua/redirect.php?https://zakon.rada.gov.ua/laws/show/z0725-99#Text :
п.4. Дебітори - юридичні та фізичні особи, які внаслідок минулих подій заборгували підприємству певні суми грошових коштів, їх еквівалентів або інших активів.
( 200 грн в Дт 6442 это актив)
п.5. Дебіторська заборгованість визнається активом, якщо існує ймовірність отримання підприємством майбутніх економічних вигод та може бути достовірно визначена її сума. (если покупатель не получит налогового кредита от Поставщика то он будет вынужден дополнительно понести затраты - оплатить НДС 200 грн.)

Закон Украины "Про бухгалтерський облік та фінансову звітність в Україні" https://pro1c.org.ua/redirect.php?https://zakon.rada.gov.ua/laws/show/996-14#Text
Стаття 4. Принципи бухгалтерського обліку та фінансової звітності
Бухгалтерський облік та фінансова звітність ґрунтуються на таких принципах:
повне висвітлення - фінансова звітність повинна містити всю інформацію про фактичні та потенційні наслідки господарських операцій та подій, здатних вплинути на рішення, що приймаються на її основі;

2. У покупателя после получения оплаченного товар от поставщика все равно право на налоговый кредит остается нереализованное без выписки и регистрации в ЕДР НДС (друга подія)
Дт 281 Кт 631 1000 грн (стоимость товара в накладной без учета НДС)
Дт 6441 Кт 631 200 грн. (стоимость НДС в накладной)
Дт 631 Кт 3711 1200 грн. (зачет авансового платежа)

3.Получение из EДР НДС зарегистрированной налоговой накладной от поставщика.
Дт 6412 Кт 6442 200 грн.

В учете бухгалтерском и даже управленческом (для собственника) Важно отображать денежную оценку ВСЕХ прав! Кроме того, важно полностью отображать учет НДС! Просто представьте большой объём выписки ПН (штук 30-300 в день), добавьте два-три нолика в накладную и не выписанные (заблокированные) накладные. Такие суммы получаться что мало не покажется! Тогда кто виноват?! Тот кто внедрил ПО!

Автор: Irtex 31.08.22, 14:23

Цитата(Salex @ 13.05.22, 15:41) *
P.S. Я тоже забрасываю эту тему, констатирую факт, что конфигурации ERP/КУП ограничено работоспособны, какого-либо улучшения в обозримой перспективе не предвидится, перспектива внедрения данных продуктов сопряжена с большим риском потери инвестиций.

Спорное утверждение, уважаемый коллега.
Если системы BAS - это сборник костылей, то это костыли, с которыми мы хоть примерно знакомы, и знаем, чего ждать от них.
А какой процент бухгалтеров умеют работать с той же SAP B1? Сколько граблей ждет пользователей и внедренцев в этой системе?
И какой ценник на внедрение SAP?
Я лично не вижу пока другой вменяемой альтернативы BAS с аналогичной стоимостью и функционалом.

Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7
https://pro1c.org.ua