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

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

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

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

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

сами себе злые буратиныМожет быть, вы знаете какой-то секрет, который мне не известен? И, может быть, даже им поделитесь? :)

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

Последний выдох ГПЖно в принципе да - негодование могу понять. из формы работы с прайсом вроде следует что механизм работает универсально - вводишь цена на новую позицию - она заполняется для всех существующих характеристик, потом у одной меняешь - ок, все сохранилось. вводишь новую характеристику - цены нет - т.е. она в реалии на позиция + характеристика идет. это боль. особенно если (несовсем понятно зачем) надо лупить партию в характеристикуОт то-то и оно... :(

andr_andreyGarya,

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

andr_andreyНасчет характеристик вроде с давних времен действовало замечание, что если для номенклатуры включено использование характеристики, то сущностью уже является пара "Номенклатура+Характеристика", по другому не придумали и приходится везде это учитывать.Вот меня и поражает, кто такое "правило" придумал и исходя из каких конгениальных соображений. "Сущностью" для разных целей могут быть совершенно разные вещи. Например, для назначения цены сущностью является модель, независимо ни от разбивки по приходным партиям, ни от цвета (цветов может быть великое-великое множество). А для покупателя цвет иногда даже важнее, чем модель, потому вести учет в разрезе цветов крайне необходимо, не смотря на то, что номенклатура одной модели и разных цветов имеет одну и ту же цену.
Необходимость сидеть и заколачивать одну и ту же цену на номенклатуру, у которой одна и та же модель, но разный цвет - уже радости маловато. А когда выясняется, что еще и под каждый цвет нужно заколотить цену на каждую ее приходную партию, причем каждый раз, когда она приходит, вообще становится тоскливо-тоскливо. Чтобы прочувствовать, просто попробуйте ввести цены сами вручную хотя бы на 5 позиций, введя цену для каждой из них примерно 500 раз (то есть, в совокупности 2500 данных), и не дай бог где опечатаешься. И зацените, насколько это невесело по сравнению с "просто ввести 5 чисел".
А сущностью для управленческого учета, в котором одной из задач является при наличии номенклатуры одной и той же модели и одного и того же цвета всегда выдавать покупателю позицию их наиболее ранней приходной партии (чтобы товар не залеживался), сущностью является не только номенклатура и цвет, но еще и дата приходной партии.
Получаются такие "группирующиеся" сущности с несколькими уровнями группировки для разных целей.

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

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

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

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

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

ViPRosGarya,
только не наследованием, а классификацией и не в коде, а в метаописанииА чем плохо наследование?

Ты посмотрел презентацию? В ней скриншоты из реально работавшей системы.

Справочник номенклатуры - промышленные насосы, двигатели, компрессоры и т.д. Каждый вид номенклатуры имеет порядка 30 характеристик: производитель, класс защиты, взрывозащищенность, климатическое исполнение, монтажное исполнение, мощность, серия, марка, обороты, скольжение, напор, давление, питающее напряжение, принцип действия, помимо массо-набаритных еще и груда соединительных размеров... При этом характеристика "мощность" имеет смысл как для насосов, так и для двигателей, характеристика "обороты", имеет смысл для двигателей и только для вихревых насосов, для вибрационных и плунжерных она не имеет смысла. Характеристики "напор" и "давление" имеют смысл для насосов, но не имеют смысла для двигателей, правда и для некоторых насосов (дозирующих, например) они тоже не имеют смысла. Для нефтяных и химических насосов в дополнение ко всяким другим характеристикам появляются еще несколько характеристик, которые определяют химическую агрессивность среды и виды химически активных жидкостей, для перекачки которых они предназначены. Для насосов, которые применяются для ЖКХ в системах отопления и водоснабжения указывается ряд дополнительных характеристик - верхняя и нижняя температура воды, возможность перекачки перегретого пара и т.п. Для сточных насосов могут быть заданы характеристики перекачиваемой среды как по химическому составу, так и по параметрам абразивных включений...
Если всё это нагромождение характеристик делать в 1С:УТ, количество видов номенклатуры будет занимать несколько экранов, наверняка куча характеристик будут болтаться во всех видах сразу и утяжелять и без того перегруженную информацией карточку (потому что "общие"), а некоторые вроде "ход штока" будут добавлены только для вида "плунжерные насосы", и потому не смогут использоваться ни в каких других видах, даже если в дальнейшем вдруг появится необходимость добавить еще один вид номенклатуры "гидроцилиндры", у которого тоже имеется характеристика "ход штока".

Механизм наследования позволяет добавить в разветвленную иерархию номенклатуры какой-то новый вид насоса - и он сразу унаследует от "родителя" всех насосов груду характеристик - не нужно их заново перечислять и напрягать мозг - вдруг какую-нибудь забыл. Кроме того, он позволяет указать не только перечень характеристик, но и их значения - либо как "зашитые насмерть", либо как значения по умолчанию. Поэтому при добавлении новой записи не требуется указывать значения всех 30 характеристик номенклатуры - примерно 80%-90% характеристик присваиваются соответствующей номенклатуре вместе со значениями , остается лишь указать значения тех характеристик, которыми отличается данная позиция от соседних по группе.

Затем можно искать номенклатуру по совокупности любых характеристик, имеющих смысл для разных видов номенклатуры (их можно представить в виде дерева либо линейного списка). И тогда по совокупности характеристик "мощность" + "обороты" можно будут находиться как вихревые насосы, так и двигатели (иногда это нужно, чтобы посмотреть, какие двигатели можно пришпандорить к каким насосам), а по совокупности "мощность" + "длина статора" - только двигатели, а по совокупности "мощность" + "напор" - только насосы. Почему-то для 1С:УТ реализовать такой вид поиска - большая проблема. Если реализовывать эти атрибуты в виде "дополнительных реквизитов номенклатуры", большинство из них придется сделать "общими", и тогда мы, находясь в карточке двигателя, будем выискивать реквизиты двигателя среди еще 200 атрибутов, которые вообще никакого отношения к двигателям не имеют.

Механизм наследования позволяет наследовать (или НЕ наследовать!) помимо технических и массо-габаритных характеристик (вместе со значениями, либо без них) также единицы измерения, изображения (иногда оборудование с разными техническими характеристиками внешне выглядит одинаково), производителя, цены, варианты комплектации, права доступа пользователей (к разным разделам справочника у разных пользователей они могут быть разными), правила продажи, продуктовые сегменты и еще много-много чего другого - чего захотите, то и будет наследоваться. И никакой дурной пользователь не сможет добавить в "корень" иерархического справочника какую-нибудь запись-элемент, если администратор определил, что на этом уровне должны быть исключительно группы. В 1С добавление элемента в корень иерархии - это ну просто повальная болезнь-эпидемия, заражающая груды пользователей.

Но я заболтался...

Так чем плох механизм наследования?

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

ViPRosв начале все типизируется (шаблон для объектов с указанным в типе набором свойств с ограничениями на значения свойств)Это "начало" может быть длинною в жизнь... :)
Данные уже используются. Внезапно появилась необходимость добавить новую группу номенклатуры со специфическим набором свойств. Разбирается в этом Лоханкин, а была бы другая номенклатура - Пупкин. Кто куда полезет?
Вот, допустим, пришел заказ на новую номенклатуру в конкретный отдел. Этот отдел будет заниматься ее типизацией? Или будут звать на помощь "специалиста по типизации неважно чего"?

ViPRosшаблон для объектов с указанным в типе набором свойств с ограничениями на значения свойств) по мере знаний, но оставляется возможность ввода динамических свойств для типизированных объектовВот допустим, не было раньше плунжерных насосов. А теперь появились. Тот кто типизирует плунжерные насосы должен выбрать из 300 характеристик насосов и не-насосов, то есть, всего-всего, те 30 характеристик, которые имеют смысл именно для плунжерных насосов, добавить специфические "динамические" для плунжерных и задать значения тех свойств, которые для всех плунжерных насосов всегда одинаковы? Я правильно понял?
Каким образом в дальнейшем система понимает, что пользователь намерен ввести именно плунжерный насос, а не вихревой? Перед добавлением номенклатурной позиции ему нужно выбрать тип номенклатуры из нескольких десятков типов?
Если "да" + "да", то мне не очень нравится, извини. Во-первых, пользователь, добавляющий новый тип, может просто забыть указать какую-нибудь характеристику - ну, нечаянно пропустить. А далее просто - система не спрашивает - значит и не нужно отвечать, ее никто не вводит. Через немалое время выясняется, что в системе уже дофига данных, а поиск по содержимому этой забытой характеристики номенклатуру не находит.
Пользователь, добавляющий новую номенклатурную позицию, может ошибиться и при выборе типа указать тип более общий, не дошарив глазами до типа более частного (например "насосы для нефтепереработки" вместо "насосы для нефтепереработки дозирующие" или "насосы для нефтепереработки химически стойкие"), и даже при наличии в системе полных и корректных описаний типов система запросит не совсем полный перечень характеристик. В общем, менее ошибкостойкий подход. Наследование - надежнее. Там глазами сразу видно, что у типа есть подтипы и какие они. И когда добавляешь новый тип, ты его добавляешь в иерархию таким образом, что система (или ответственное лицо за более высокий уровень этой иерархии) просто не даст тебе "забыть" какие-то характеристики, которые обязательно должны быть у всех подтипов данного типа.