fpat

Конструктор запроса добавляет в группировку и реквизит группировочного поля, но если запрос писать вручную или убрать поле реквизит из группировки - запрос отрабатывается без ошибки. Данный пункт я нашел в книге Руководство разработчика, они его конечно особо не выделяли. Но вот интересно происходит ли в обоих случаях одинаковый запрос к базе данных или есть всё-таки оптимизация. Опять есть некоторое отличие от обработки запроса к табличной части документа и обращению к некоторому полю основной таблицы документа (в обоих случаях присутсвует левое соединение с другой таблицей: в первом случае - например, справочником номенклатура; во втором случае - таблицей основного документа), но если удалить из группировки данное поле во втором случае, то запрос не выполнится, так как возникнет ошибка; система потребует добавить в группировку. (например, ДокТЧ.Ссылка.Контрагент)

Всем спасибо! Тему закрываю. Пойдем другим путем

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

(9) saszj, Сканеры есть. Для каждой партии генерируется штрихкод. У нас раскомплектовка делается на складе. Поэтому когда товара едет на аптеку, по нему соответственно уже расклеены этикетки. На аптеке он сканируется обычным образом.

(7) falcon, У нас похожая схема, только сам процесс идет на складе, а не на аптеке (товарные остатки на аптеке учитываются в розничных ценах, на складе - в закупочных). Куда вы списываете суммовые разницы после таких операций ? При нажатии кнопки "Разукомплектовать" в форме подбора товаров, указываете какое количество надо разукомплектовать и создается новый документ Разукомплектовка, где заполнены строки товар исходный - товар конечный, количество исходное-количество конечное, цены, суммы. У вас партионный учет ? Партии вы создаете на аптеке ?

(3) falcon, Можно подробнее написать по поводу разукомплектации. Что конкретно она выполняла ? Использовались ли у вас единицы измерения ? Проблемы возникают в основном из-за массовости таких вот разукомплектаций

(2) Кошки рулят, А суммы в приходе вы автоматически подгоняете под бумажный вариант, ведь коэффициенты-то бывают разные (коэффициенты у вас целочисленные?). Проблем не возникает с тем, что по расходной накладной поставщика идут упаковки, а в вашей приходной - штуки ? У вас самописная конфигурация или одна из типовых ? Я правильно понял, что при отпуске, если надо отпустить 5 полных упаковок и 2 блистера (кво в упаковке=3) у вас в чеке едизм = шт пишется 5*3+2=17 блистеров (штук)

(12) iceflash, Статья действительно для новичков. Над оформлением ещё поработаю. Вы забыли упомянуть, что на скорость выполнения также влияет выбор СУБД (одно дело - если это MSQL, а другое дело - PostGreSql или ORACLE). Говорить, что такая-то конструкция выполняется 100% быстрее, чем другая неправильно. Можно лишь рекомендовать, что в большинстве случаев такая конструкция будет оптимальнее, чем другая (полное соединение всегда будет проигрывать объединению с опцей Все в том же PostgreSql). Говорят тоже, что вложенные запросы - это зло и лучше использовать временные таблицы или соединения. Но в ряде случаев эффективнее оказывается могут выполняться запросы со вложенными запросами. На скорость выполнения, как вы заметили правильно, влияет план запроса, который формирует СУБД (в профайлере можно посмотреть) на основании таблиц, связей между таблицами, индексами,размером таблиц,данными, своей статистике запросов и обращений и т.д. И для одного и того же запроса может быть сколько угодно различных планов выполнения запроса, в который можно вмешиваться на низком уровне, изучая конкретную реализацию СУБД. Что касается Различные - это ключевое слово намного читабельнее, чем СГРУППИРОВАТЬ ПО и в простых случаях именно всегда его и рекомендуют использовать, при этом разницы большой в скорости выполнения между ними нет. При добавлении индекса по полю данные запрсы будут выполняться одинаково быстро.По поводу 1С программисту необязательно вникать в планы запросов,которые весьма различаются в разных СУБД. 1С сделала всё, чтобы упростить написание запросов для программистов 1С. 1С программисту важно понимать, что даже если запрос маленький и записан одной секцией выбрать - это не значит, что система будет выполнять обращение к одной таблице и для самой СУБД данный запрос может быть интерпретирован как 7-этажный запрос. В случае составных реквизитов или при наличии разыменования полей 1С программист должен понимать, что фактически в запрос добавляются множественные соединения с количеством, соответствующим количеству типов составного поля + соединения через разыменования полей;поэтому где только возможно нужно ограничивать число таких таблиц с помощью того же ключевого слова ВЫРАЗИТЬ; в случае строк неограниченной длины - знать, что нужно ограничивать их длину в самом запросе иначе может быть вылет из-за нехватки памяти; понимать, что временные таблицы надо своевременно удалять из памяти и не использовать их там где не надо. 1С -это ещё и объектная среда, поэтому отличия между 1С и чисто реляционными СУБД разительные. Язык SQL намного гибче 1С, но отчасти, из-за того, что 1С присущи два подхода - как табличный, так и объектный.

Здравствуйте! Есть отраслевые решения конфигураций, в частности и на 1С 7.7 и 1С 8.2, автоматизирующих аптеки. Те, кто когда-либо автоматизировал аптеки, знают о такой проблеме аптек - продажа неполных упаковок (блистерами, ампулами и т.д.) Обращаюсь к тем, кто работал с подобными конфигурациями (АНР Аптека,РАРУС Аптека, или самописных конфигураций) и разбирался с данным вопросом. Насколько хорошо данная проблема решена в конфигурации 1С 7.7(1С 8.2) АНР Аптека для Украины (у них просто форума нет, где бы данная проблема подымалась, может им удалось её успешно решить)? У РАРУСА есть форум, из него следует, что данная тема до сих пор досконально хорошо не решена и не потеряла актуальности. Из основных проблем я могу выделить следующие: - наличие дробного количества на остатках и резервах, по которому нелегко ориентироваться провизорам; возможные висяки на остатках тысячных копеек (в РАРУСЕ такие висяки решаются регламентным документом, который списывает остатки на затраты) и т.д. Для примера уже заезженный случай препарата с 3 штуками в упаковке (Предположим количество учитывается до 3 знака; при списания 1 шт - списывается 0.333, после 3 списания 0.999 и на остатке зависает 0.001). Понятно, что многие в таком случае предлагают при списании последней упаковки списывать весь остаток (0.334), но в некоторых конфигурациях списывают равными долями, объясняя это тем, что последнему покупателю нельзя продавать товар дороже (такое решение в РАРУСЕ). Проблем как таковых бы не было ни у кого, если бы такого товара было бы немного. Есть решения, в которых не используются единицы измерения, а есть карточки товара (например, №10 и №30). В таком случае делается разделение закупаем упаковками например товар №30,продаем другой карточкой товаром №10(в данном случае коэффициент - 3)В этом случае проблем с дробями нет, но при большом количестве товара - требует постоянной перегонки товара №30 в №10. По сути в этой схеме не используются единицы измерения (так как закупается одна карточка, реализуется другая - в целом что касается аптечной отрасли - единицы измерения слабо нужны). Подобное решение можно сделать и с помощью единиц измерения (выбирая в качестве базовой единицы минимальную), но танцы с бубнами и в этой схеме присутствуют (списание себестоимости, суммы в приходных накладных надо подгонять под бумажный вариант).
Напрашивается более простое решение: если закупать упаковками, то и продавать упаковками или долями упаковки. Есть ли подобные реализации и какие основные проблемы ?

Если кто-то знает какие-то интересные приемы в языке запросов, пожалуйста, пишите. Всем будет интересно почитать.