"Предупрежден - значит, вооружен"
1) Слепота обработки «Закрытие месяца» (на один глаз)
Отразим дополнительные доходы несколькими документами:
а)Вводим складской акт «Оприходование излишков товаров»
Намереваясь отнести возникшие доходы на направление деятельности.(Далее используются статьи с аналогичной настройкой)
б) Введём «Поступление безналичных денежных средств»
в) точно также можно ввести «Приходный кассовый ордер»
г) Добавим «Прочие доходы и расходы»
Больше в данном периоде нет никаких прочих доходов, расходов, нет поступлений услуг и прочих активов.
Закрываем месяц:
Таким образом, обработка закрытия месяца «не видит» документы «Оприходование излишков товаров», «Прочие доходы и расходы», «Поступление безналичных денежных средств», «Приходный кассовый ордер» (если были только доходы). Соответственно и финансовый результат будет не корректным.
Решение: Создавать вручную документ «Распределение доходов и расходов»
2) УТ11 помнит то, что следовало бы забыть
Если судьба завела вас в журнал кассовых документов (например Финансы->Приходные кассовые ордера) и вы выбрали там для отбора кассу “Касса 1” организации ООО "ААА" после чего закрыли этот журнал.
Далее пытаетесь оплатить реализацию от организации ООО "ЕЕЕ"
Нажимаете “ввести на основании”->”Приходный кассовый ордер” и открывается ПКО с заполненной кассой “ Касса 1” (касса запомнилась при использовании кассового журнала)
Соответственно документ не проводится, и кассу не перевыбрать т.к. организация (скрытый реквизит) тоже заполнилась (как владелец кассы) ООО "ААА"
Причины:
В кассовых журналах при указании отбора по кассе срабатывает
ОбщегоНазначения.ХранилищеОбщихНастроекСохранить(“ТекущаяКасса”, , ?(СохранитьНеопределено, Неопределено, Касса));
А в ОбработкеЗаполнения кассовых документов срабатывает
ОбщегоНазначения.ХранилищеОбщихНастроекЗагрузить(“ТекущаяКасса”,);
Видимо разработчики сделали это для удобного создания кассовых документов из журнала с отбором. Но забыли почистить отбор.
Кстати, подобная проблема возникает и в помощнике заполнения складских актов, но уже с реквизитом “организация” (но там хотя бы можно вручную поменять организацию).
Решение:
- Создавать кассовые документы вручную (не вводом на основании)
- Перед вводом на основании заходить в журнал кассовых документов, выбирать нужную кассу и закрывать журнал
3) Ошибки ценообразования
Создадим вид цены, пусть он будет рассчитываться от цены поступления.
Пусть сегодня был единственный(первый) приход товара «Товарчег» 2шт., причём 1шт поступила по 100р, а вторая по 2р.
(ведь бывает в накладной два одинаковых товара по разной цене)
И попробуем установить цену. Создаём документ «Установка цен номенклатуры» и заполняем табличную часть
Цена товара в табличной части не заполнится.
Отсюда первая ошибка
а) Не рассчитываются цены от сегодняшнего поступления (в первом документе установки цен)
Причины:
Если документ установки цен один в пределах дня, то его время устанавливается на 00:00:00, но если мы вводим не первый документ, то к его времени прибавляется “НомерВПределахДня – 1″. соответственно срабатывает по разному конструкция “ГДЕ ПоступлениеТоваровУслугТовары.Ссылка.Дата
Именно поэтому, если документ УЦН один, а поступления от того же дня, то цены при подборе не устанавливаются.
Решение:
- Записать один пустой документ установки цен. Тогда в следующих цены будут заполняться.
- Перевести дату документа вперёд, заполнить документ, перевести дату обратно
б) В расчёте цен участвуют помеченные на удаление и не проведённые документы.
В этом можно убедиться, пометив на удаление документ поступления, и попробовав заполнить «Установку цен».
Причины:
В запросе СКД макета ЦеныПоступленияПредопределенный справочника «ВидыЦен» разработчики забыли вставить условие (ТоварыДокумента.Ссылка.Проведен = ИСТИНА)
Решение:
Своевременно удалять помеченные на удаление объекты. Не хранить в базе ненужные не проведённые документы.
в) Для расчёта из документа поступления берётся средняя цена.
Добьёмся (например «сдвигом» поступления на 1 день назад), чтобы «установка цен» всё-таки рассчитала цены по нашему поступлению.
Как видно, «установка цен» высчитала среднюю цену из поступления (100+2)/2=51 и прибавила 100%. Итого мы получили 102р Хотя пользователи часто ожидают увидеть цену в 200р. Логичнее было бы брать для расчёта максимальную цену из документа. Эту особенность нужно знать при внедрениях.
Причины:
В запросе СКД макета ЦеныПоступленияПредопределенный справочника «ВидыЦен»
Решение:
не допускать дублирования строк в документах прихода.
4) Не работает вариант оценки себестоимости «ФИФО (скользящая оценка)»
Для демонстрации полной неработоспособности этого метода оценки достаточно ввести три документа+ закрытие месяца:
а) введём документ поступления в прошлом месяце.
б) создадим документ реализации в прошлом месяце
в) Вернём товар в текущем месяце
Закроем месяц (используем метод оценки ФИФО (скользящая оценка)), и сформируем отчёт «Себестоимость поступивших товаров»
Видно, что товар вернулся с нулевой себестоимостью. Чтобы проверить, что у нас нет ошибки в документах (хотя какая уж тут может быть ошибка). Закроем месяц с методом оценки «Средняя за месяц». Видим, что себестоимость посчиталась верно:
Эта ошибка ставит крест (временно) на всём партионном учёте УТ11.1
Подчеркну, что при возврате товара проданного в одном расчётном периоде (в одном месяце с возвратом) себестоимость считается корректно.
Причины: Отсутствует кусок кода в документе «Расчёт себестоимости товаров»
Решение:
- Использовать другой метод оценки
- Идти на курс «быстрый старт в профессию» и кромсать код УТ11.
5) Зависание себестоимости на складе при возврате поставщику (релиз 11.1.2.15)
а)Создаём поступление товара
б)возвращаем весь товар поставщику
в) Закрываем месяц и формируем отчёт "Анализ себестоимости товаров"
Видно, что половина стоимости товара осталась на складе
Причины: Ошибки в процедуре проведения документа "Возврат товаров поставщику". Дублируются движения по партиям товаров организаций.
Решение: Вводить документ "Возврат товаров поставщику" не вводом на основании "поступления товаров и услуг", либо очистить документ основания в шапке (оставив ссылки на основание в табличной части).
5) Собака кусающая себе за хвост или реализация корректировки...
В релизе (11.1.4.11) встретил забавную ситуацию. При перепроведении реализации и последующем закрытии месяца может случиться, что в движения документа попадёт партия свормированнная коректировкой этой реализации.
Заключение:
Рассмотрены далеко не все ошибки конфигурации УТ11.1. будем надеяться, что фирма 1С исправит большую их часть в следующем релизе. Не все рассмотренные ошибки ужасны, но при внедрении текущей версии «Управления торговлей» нужно их хотя бы знать, и по возможности обходить стороной.
Спасибо за внимание!
