Заказы на доработку 1С (сервис удаленной работы)

Хранилище

База знаний
Неназначенных незавершенных заказов: 6, свеженьких 1
Бесплатные отчеты, обработки, конфигурации, внешние компоненты для 1С Статьи, описание работы, методики по работе с 1С

Здравствуйте, гость ( Вход | Зарегистрироваться )



> Особенности конфигурации BAS КУП , честный обзор проблемных моментов          
Salex Подменю пользователя
сообщение 10.12.19, 19:58
Сообщение #1

Общительный
**
Группа: Пользователи
Сообщений: 23
Из: Харьков
Спасибо сказали: 16 раз
Рейтинг: 16

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

Сообщение отредактировал Vofka - 11.12.19, 9:14

Спасибо сказали: Acid, Alex_2C, andr_andrey, demon14, MATEVI, pablo, palunzik, propka28, python, Vofka,


Salex Подменю пользователя
сообщение 11.12.19, 13:38
Сообщение #2

Общительный
**
Группа: Пользователи
Сообщений: 23
Из: Харьков
Спасибо сказали: 16 раз
Рейтинг: 16

[необходимо зарегистрироваться для просмотра ссылки]

Спасибо сказали: Acid, andr_andrey, propka28,

Acid Подменю пользователя
сообщение 11.12.19, 14:27
Сообщение #3

Про1С-ник
Иконка группы
За заслуги на форуме в 2010 году
Группа: Местный
Сообщений: 2083
Из: Занзибар
Спасибо сказали: 360 раз
Рейтинг: 240.3

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

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


Signature

Документируйте Код! мать вашу...

* Хочу работать не далеко от моря http://www.severniykipr.ru/

Спасибо сказали: polikarpova.07,

andr_andrey Подменю пользователя
сообщение 11.12.19, 16:51
Сообщение #4

Почти ветеран
Иконка группы
Группа: Местный
Сообщений: 507
Спасибо сказали: 119 раз
Рейтинг: 95.5

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


Signature
#define private public
enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day

Salex Подменю пользователя
сообщение 11.01.20, 14:28
Сообщение #5

Общительный
**
Группа: Пользователи
Сообщений: 23
Из: Харьков
Спасибо сказали: 16 раз
Рейтинг: 16

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

Спасибо сказали: audit7buh, MATEVI,

Не нашли ответа на свой вопрос?
Зарегистрируйтесь и задайте новый вопрос.


Ответить Новая тема
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 

RSS Текстовая версия Сейчас: 28.02.20, 19:07
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!