Завершаем внедрение 1С:УТ 11.1 для магазина-салона, который оказывает постижерные услуги и продает парики. Есть позитивные моменты, есть негативные.

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

Негативные:

1. Ужасные тормоза. Несмотря на номенклатуру всего в 5000 наименований, поиск номенклатуры по штрих-коду занимает порядка 10-15 секунд. Возможно, связано с тем, что штрих-коду сопоставлена не только номенклатура, но и характеристика, посредством которой идентифицируются приходные партии. А возможно, криво взаимодействие с драйвером сканера штрих-кодов (при работе в одном из режимов работает с вот такой задержкой, при работе в другом режиме работает на порядок быстрее, но требуется каждый раз нажимать клавишу F7 перед вводом штрих-кода).

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

3. Масса концептуальных нелепостей, в частности:
- Не имея полных прав администратора, пользователь не имеет возможности выполнить процедуру архивирования БД (в нормальных продуктах для этого предусмотрена роль вроде Backup помимо Administrator)
- Для того, чтобы приложение (толстый клиент) смогло-таки нормально взаимодействовать с эквайринговым пинпадом, в операционной системе необходимо запускать 1С от имени администратора рабочей станции.
- Подключаемое оборудование привязывается к номерам COM-портов. Достаточно включить оборудование в какой-то иной последовательности, и всё, 1С:УТ уже "заблуживается в трех соснах", потому что оборудованию операционной системой присвоились номера COM-портов в каком-то другом порядке.
- Не понятно, почему поиск торговых документов, в которых фигурирует та или иная номенклатура, может осуществлять только пользователь с правами администратора и при этом только "левой ногой через правое ухо". Это что, какой-то мало востребованный функционал? Почему, находясь в карточке номенклатуры, нет возможности отобрать документы, в которых эта номенклатура фигурирует?
- Не понятно, почему нельзя задать текущую учетную дату иной нежели текущая дата компьютера (как в 1С:Бухгалтерии). По ряду причин ввод вступительных остатков мы вводили НЕ в режиме "ввод вступительных остатков", а приходными документами - и каждый раз нужно было не забыть изменить дату на дату ввода вступительных остатков.
- Какой великий смысел в присутствуюшей на форме номенклатурного справочника суперкнопке "Изменить выделенные", если она позволяет изменить сразу у груды записей реквизиты и дополнительные реквизиты, но не позволяет при этом переформировать "Рабочее наименование" и "Наименование для печати" по шаблонам, в результате чего все равно приходится заходить отдельно в каждую запись справочника номенклатуры и жмакать кнопку "Заполнить по шаблону" отдельно для каждой записи. Трудно было догадаться, что групповое заполнение наименований по шаблону должно быть частью этого функционала?
- Какой смысл мучиться с "настройкой создания" конкретного "вида номенклатуры", указывая видимость/невидимость и доступность полей и дополнительных характеристик, которые имеют смысл для конкретного вида номенклатуры, если в карточке номенклатуры тебя по любому завалит всеми "общими" дополнительными характеристиками, в том числе, не имеющими для данного "вида номенклатуры" никакого смысла?
- Какой смысл делить "дополнительные характеристики" на "общие" и "для конкретного вида номенклатуры", если ни те, ни другие невозможно использовать с позиций масштабируемости решения? Если переборщить с "Общими", то ими буквально заваливает все карточки номенклатуры, и там, где такие характеристики нужны, и где не нужны (мы сначала допустили такую ошибку, и потом вдруг обнаружили, что карточка номенклатуры растянулась на несколько экранов). Если использовать "для конкретного вида номенклатуры", то они оказываются недоступными для любых других видов номенклатуры, даже тех, которые имеют общие черты с какими-то другими. Иными словами, "дополнительные характеристики" не могут быть привязаны к двум или к трем видам номенклатуры - либо сразу ко всем, либо только к одному. "МудрО"... :(
- Почему в настройках вида номенклатуры невозможно указать значения по умолчанию ряда полей (например, "Производитель") и дополнительных реквизитов - ни на закладке "Значения по умолчанию", ни на закладке "Настройки создания"?
- Почему не предусмотрен самый востребованный стандартный функционал партионного учета, при котором идентификатором приходной партии является дата прихода (либо дата и время)? И чтобы дата прихода проставлялась автоматически по всем строкам табличной части приходного документа. Нам пришлось код партии хранить в "характеристике" (общие для вида номенклатуры), а для заполнения "характеристик" одной и той же датой в строках табличной части приходного документа задействовать внешнюю обработку.
- Если, как указано выше, "характеристики" уже задействованы для целей реализации партионного учета, то их уже нельзя использовать для других целей. В частности, у нас стоит задача вести детальный (количественный и суммовой) учет по приходу и расходу париков не только в разрезе моделей, но и в разрезе их цветов, размера головы и ряда других параметров (это всё - "дополнительные реквизиты"). Однако, цена у всех париков одной модели, независимо от цвета и размера головы - одинаковая. Как можно удобно задать цену для всех париков по-модельно? Никак. Можно было бы выкрутиться, если использовать "цвет парика" как характеристику, но характеристики уже задействованы под партионный учет - в них дата прихода, цвет уже туда совать нельзя. Иные решения не позволяют вести учет и в количестве, и в сумме в разрезе складов/магазинов и в разрезе не только моделей, но и цветов парика. В общем, как ни крути, либо масштабные доработки со снятием с поддержки, либо придется смириться с неудобствами. Нам пришлось смириться с неудобствами. Приходится 100500 раз задавать одну и ту же цену для груды записей номенклатуры, отфильтровав записи по дополнительному реквизиту "модель" (и не дай бог при этом ошибиться, указав ее разной для разных записей справочника номенклатуры одной модели но разного цвета!). И настроить внешний отчет, который формирует прайс-лист не по позициям номенклатуры, а сгруппировав множество записей номенклатуры по моделям париков (которая может быть одинаковая для разных записей номенклатуры, поскольку у париков разный цвет).

В общем, полностью и совершенно избежать неприятных моментов не удалось. Так что, уважаемые trdm_ и Программист 1с, продукт сей НЕ идеален. Хотя, в принципе, без больших затрат позволяет-таки в принципе добиться решения задачи во многих случаях, оставшись на стандартной поддержке 1С с рядом оговорок и неудобств.

Garya- В справочники номенклатуры не работает поиск номенклатуры по части наименования, хоть по начальной части, хоть по произвольной подстроке. Исключительно только по полному наименованию, который не отключается даже при сброшенной галочке "По точному соответствию".Разобрался, как это лечится. Если грохнуть индекс полнотекстового поиска и создать заново, то поиск начинает работать нормально. Насколько я понял, перестройка полнотекстового индекса по расписанию работает как-то криво - не создает индекс на то, на что должна создавать. И при этом считает, что "перестройка индекса не требуется".

Уже разобрался. Задержка действительно на уровне драйвера. Задействовали другой драйвер - стало работать почти на порядок быстрее.
Однако, программа очень тяжелая для освоения. Юзеры просто стонут, и я прекрасно понимаю, почему.
Может кто-нибудь объяснить, почему программа позволяет выполнить внесение денег в кассу ККМ и изъятие денег из кассы ККМ как в пределах кассовой смены, так и за ее пределами? А как же человеческий фактор, а как же "защита от дурака" или хотя бы от "сильно уставшего в конце смены сотрудника"? Почему программа допускает расхождения остатков по кассе ККМ и фискальной памяти фискального регистратора, это, типа, такая фича?
Почему на "рабочем месте кассира" промежуточный итог по чеку вместе со скидками можно увидеть только после нажатия кнопки "Расчет", а добавлять позиции в чек можно только до нажатия этой кнопки, и нажатие на эту кнопку необратимо? Это, наверное, специально придумали, чтобы жизнь кассира малиной не казалась. Потому что на вопрос "сколько у меня там набежало вместе со скидкой?" и "хватит ли мне денег?" кассир оказывается ответить внятно не может, пока не нажмет эту "волшебную кнопку", чтобы уже утратить способность добавлять позиции, если у клиента денег все же хватает.
Есть номенклатура, которая не только продается, но и используется в качестве подарка при приобретении покупателем какой-то особо дорогой позиции - нужно отслеживать факты дарения, отделяя их от продаж, но при этом фиксировать, какой подарок привязан к какой продаже... Вроде бы элементарная задача, решать которую приходится почему-то "левой ногой через правое ухо". Отразить в чеке ККМ позицию как подарок или хотя бы как продажу со 100% скидкой программа не позволяет (кто-то из разработчиков решил, что 100%-ная скидка в природе существовать не может, нужна хотя бы на копейку меньше). Приходится списывать товар отдельными документами как "списание недостач" - при этом утрачивается связь между подарком и проданной позицией, к которой этот подарок привязан. Супер!
Аванс-залог - это вообще, ужас какой-то. Нужно сделать около 20 лишних телодвижений, чтобы выбить кассовый чек на залог, который покупатель оставил за товар, чтобы его не продали, пока он бегает домой за остальными деньгами, а потом пробить еще один кассовый чек на остаток суммы, когда он принесет остальные деньги. Для того, чтобы отразить такую операцию в программе, приходится оформлять заказ клиента, заполнять данные клиента, тратить груду времени на никому ненужные детали и подробности о данных клиента (хотя, казалось бы, какая разница, какие у него паспортные данные и ФИО, если даже и другой человек вместо него придет с ранее пробитым чеком, который выдан ему на руки и если у него вообще нет с собой паспорта)... Кто придумал, что по таким операциям необходимо оформлять отдельный приходный кассовый ордер, который не тот же самый, который "поступление выручки из кассы ККМ" в пределах той же самой кассовой смены? Или предполагается, что кассир за кассой ККМ выступает при пробивании таких чеков уже в какой-то специфической ипостаси?
Банк ведется в 1С:Бухгалтерии, соответственно эквайринговые операции тоже отражаются в другой программе, а не в 1С:УТ. И где, в каком отчете можно увидеть продажи за период по банковским картам в 1С:УТ по чекам ККМ? Ответ ну просто изумительный - нигде. А у нас комбинированное налогообложение - услуги облагаются по ПСН, а товары по УСН. И нам нужно группировать продажи за произвольный период на 4 группы: 1) товары, проданные за наличные 2) услуги, проданные за наличные 3) товары, проданные по банковским картам 3) услуги, проданные по банковским картам. Увидеть такое "чудо" можно только посредством специально разработанного внешнего отчета.
Более всего, конечно же, поражает, способ, которым находится ответ на вопрос "что у нас происходило в системе с такой-то номенклатурой?". Это хорошо, что франч по нашему заказу сделал специальную внешнюю обработку, которая из карточки номенклатуры способна отыскать документы, на которые данная номенклатура ссылается. Реализовать же такой типовой функционал разработчик как-то не догадался. Видимо, полагал, что этот вопрос, как правило, никого не интересует. Или что он возникает достаточно редко, что посредством этого вопроса можно было бы поднять на уши администратора, потому что кроме администратора ответить на него в типовом функционале не может, а администратор может тоже "левой ногой через правое ухо". А что, так сложно было в любых справочниках 1С реализовать кнопку "где используется?", на которую можно было бы жмакнуть, выделив любую запись?
В общем, это какой-то тяжеловесный монстр, в котором при изобилии заморочек и функций, нужных 0,1% пользователей почему-то отсутствуют самые простейшие и самые востребованные из них. И почему-то работая с этой программой, ощущаешь себя этаким мулом, который тащит воз размером с трехэтажный дом.

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

Иногда создается ощущение, что в 1С сидят вредители. Каким местом они думают, когда реализуют подобный маразм... :(

Александр ПузаковGarya- Почему не предусмотрен самый востребованный стандартный функционал партионного учета, при котором идентификатором приходной партии является дата прихода (либо дата и время)? И чтобы дата прихода проставлялась автоматически по всем строкам табличной части приходного документа. Нам пришлось код партии хранить в "характеристике" (общие для вида номенклатуры), а для заполнения "характеристик" одной и той же датой в строках табличной части приходного документа задействовать внешнюю обработку.
Эээ... Серийный учёт , не?Не. Нам сроки годности не нужны. Нам нужна не дата "годен до", а дата прихода , которая автоматически берется из даты приходного документа. И при этом чтобы в разрезе дат прихода по партиям велся и количественный, и суммовой учет по складам.