Как правильно реализовать быстрый поиск документ по текстовому реквизиту табличной части?
Документ "РасходнаяНаклданая"

Добавил в него в ТЧ текстовый реквизит "Стикер продажи" - уникальное поле для всех продаж.
Вот по нему нужно находить документ.

Прямым запросом к таблице "Строки документа РасходнаяНаклданая"
Правда перебор по всем строкам будет жутко медленный

(1) Толком не нашёл в гугле про прямой запрос к табличной части. Немного сложновато для меня.
Более простых способов нет?

Индекс нельзя построить по полю ТЧ документа?

(2) можно и простым запросом через свою фуекцию

(2) Тогда "кривым" запросом. Т.е. штатным семерочным запросом.

ну или через условие если тебе нужно не по подстроке искать, а полному соответствию

в теории был бы справочник "Стикер продажи" было бы немного проще.
НайтиПоНаименованию() - быстро по индексу найдёт, а далее уже запрос с условием на равенство найденному элементу

(6) Да, вот соседняя тема
Вопросик по изменению в конфигурации
Возможно и нужно было бы завести справочник "стикеры продаж", в котором помимо стикера уникального была бы ссылка на документ и номер строки

(7) Ну так сделай. Добавь еще один скрытый реквизит ссылкой на справочник и далее по аналогии как с справочником партии в приходных документах. Т.е. при записи ищи, проверяй, заполняй, редактируй этот справочник без участия пользователей (не забудь при удалении строки удалять и помечать на удаления и элемент справочника)

А собственно зачем? Если это редкая операция то нафиг извращаться, сделать тупо.
  Что это за стикер - это что? Шк-вб товара для конкретного заказа?

(8)  имхо излишне. Реквизит сугубо информационный, используется один раз всего

(9) Стикер - да это ШК конкретного заказа

(10) не совсем информационный ).
Я ведь хочу крыжить ШК заказов из отчётов ВБ, с расходками, которые отгружены на ВБ

ТЫ верно спросил в соседнем ветке, как я предполагаю делать это.
В принципе тупым перебором расходок их их ТЧ пока сделал, не сильно тупит

(12) а я предупреждал в прошлой ветке...

(12) Это пока что, а потом, когда количество документов станет больше...

(12) сделай регистр оборотный

(7) Вот прям во втором и третьем постах той ветки тебе Злопчинский сказал: "смотря зачем тебе этот номер заказа. пока не будет определено зачем и как будут использоваться эти номера заказов - посоветовать что-либо трудно".

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

(0) Графа отбора уже не работает в 77? Давно я ею не занимался..

(0) Там можно графу отбора сделать на реквизит табличной части. И потом выборку по этой графе отбора. Эта выборка находит документы содержащие нужный стикер, а потом уже в самом документе перебираешь строки и определяешь в которой строке есть нужный стикер.

Таким образом можно даже в журнал документов отбор сделать.

(16) Отчасти согласен. Но я привык к университетскому - сначала веное построение базы данных, а уже потом инструменты работы над ней ).
Но согласен что 1с - чуток другая область, здесь нормализация СУБД - далековата )

(18) Вот - есть всё-таки решение красивое решение ).

В регистр обороты не проще добавить Реквизит ШКзаказа и писать при проведении. потом стандартным запросом легко выберется. я бы вообще вместо ШК текстового писал ссылку на сам документ заказа. потом отбор подчиненных документов по заказу и перебор их табличной части.

(22)
В регистр добавлять - это насколько я понимаю - перепроведение всех расходок за 10 лет. Не очень хочется.

делать новый документ "стикер заказа", в котором только один реквизит "номер стикера" - как по мне, тоже не очень. За день 50 заказов, удобней складу и для контроля - когда они в одном документе,и склад обрабатывает этот один документ.

Так а в чём проблема с графой отбора? Помоему это самый красивый вариант

(23) Графа отбора создает дополнительные индексы. Нужна если тебе надо отобрать что-то очень быстро, например отбор в журнале.
Если это отчет, то пару секунд не критично и достаточно обычного "черного" запроса.

(20) >> привык к университетскому - сначала построение базы данных, а уже потом инструменты работы над ней.

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

(23) Смысл штрихкода заказа если самого заказа с перечнем позиций нет. ИМХО какой то у вас косяк с постановкой учета отсюда и траблы лезут. рассказывайте подробно что и как делается и для чего

(23) Обычно документы позже года нафик некому не нужны и если отчет по ним будет строиться долго не критично. А вот отчет по актуальным документам будет летать.

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

Каждый день мы отгружаем полученные заказа на комиссию ВБ. Еженедельно ВБ даёт отчёт, что из отгруженного продано (продаётся в среднем 70% - остальное клиенты не забирают).

Вот и стоит задача вести учёт по ВБ. Я вижу только один выход, каждое списание у себя товара отмечать стикером (их мы видим в заказах).
И затем обрабатывать еженедельные отчёты, в которых ВБ даёт список забранного покупателями товара, и в них же он даёт цену реализации каждого товара (в заказе к сожалению он её не даёт)

Большинство селлеров при реализации в своей 1с товара на ВБ создают один счёт, и в него добавляют полученные за день товары. И списывают его одной расходкой.
Это минимизирует варианты не отгрузки товара складом. Если же делать один заказ - один документ, риски что заказ создан, но складом не отгружен - возрастают. Либо реализация этого метода усложняется. Смысла в этом я не вижу.

Для себя я принял решение, что номер стикера, это число из 10знаков, (это же и номер заказа) я тупо добавлю в ТЧ счёта и расходки.
И далее все еженедельные отчёты от ВБ я по этому номеру стикера буду сопоставлять с расходками, решая две задачи:
1) в расходке на каждом товаре проставится цена реализации (та цена которую ВБ нам оплатит за товар) и
2) я пойму, что данная конкретная поставка была в отчёте и значит профинансирована нам.

Заказа это заказы 1 заказ 1 документ. и у него состояние и остальные реквизиты. кто купил забрал не забрал почему не забрали поступила оплата когда. Возвращаем товар или стоимость его возврата дороже товара и проще его оставить у грузоперевозчика. Склад это склад по заказам отгружаемым за день создается документ отгрузки куда собираются из заказов все отгруженное и если отгружено 20 кепок то в складском документе это 1 строка кепка к-во -20. Дальше работаем с заказами не трогая склад. если будет возврат создаем документ возврата. помещаем заказчика в черный список и т.п. можем заказчику послать какую то рекламу и т.п.
А своим ШК в табличной части ты решил 1 задачу и не оставил никакого задела для маркетинга и последующего развития это не правильно.

Можно клиенту написать, что обычно с этой вещью народ покупает еще и вот это, не желаете ли ее добавить к своему заказу. и т.д.

(25) > "Не может быть построение БД оторвано от инструментов работы с ней.@

не только может но и должно ). Любая БД должна быть нормализованна, т.е. приведена к какойто правильно структуе (в обычной теории их 5, 1, 2, 3яя нормальная формы, затем форма Бойса-Кода и 5ая)
А один из 3х постулатов ООП, это Абстракция — отделение концепции от ее экземпляра.
Т.е. если следовать построению базы данных через принципы ООП, то мы сначала её правильно строим (т.е. приводим к какойто правильной форме), а затем уже следующий : через инструменты SQL решаем любые задачи с ней.

сори за оффтоп, решил вспомнить 5й курс )

(30) > "Заказа это заказы 1 заказ 1 документ. и у него состояние и остальные реквизиты. кто купил забрал не забрал почему не забрали поступила оплата когда"

Смотри что ты не учитываешь. Ты не учитываешь что думаю любая стандартная конфигурация по складскому учёту,(если брать отгрузку) это два документа: счёт и на основании счёта расходка.
И когда селлер выходит на ВБ, естественно изначально он все поступающие заказы вбивает в счёт, и затем   его списывает через расходку.
в поступающем заказе он видит : товар, количество всегда 1шт, неправильную цену и много других столбцов, которые на начальном этапе ему не интересны.
И вот он работает  так пол года и понимает, что вылазит проблема сверки, когда куча товара отгружена по каким то ценам, но сверится с ВБ возможности нет.
И тогда он понимает, что нужно внести изменения в структуры базы, и отмечать в расходках ещё номер заказа, который ВБ даёт. чтобы по нему потом через получаемые еженедельные отчёты сопоставить свои списания построчно.

Так вот ИМХО, намного проще "стикер" ввести в ТЧ расходки (добавив их во все расходки за 6 прошедших месяцев), чем кардинально менять структуру отгрузки.
либо какой смысл в новом документе "стикер", если мы всёравно будем ежедневно их группировать в единственную расходку?

Если создавать документ стикер, то всёранво нужно придумать связть между ним и каждой строкой расходки. Зачем такое усложнение?

(31) Это всё решается точно не из 1с в котором будет отдельный документ "стикер заказа" ))

(32) Заметно что основы построения БД только на 5 курсе стали давать, ничему не успели научить. В наше время с этого во 2 семестре 3 курса начинали.
(33) это костыли не решающие проблему. за это 1с-ников и ругают. Нужно делать нормально, создать документ заказ перезаполнить их с в старых периодах автоматически. или сделать документ ввода остатков и начинать вести эту часть учета с этого документа. У заказа есть куча действий и логики поведения которая не соответствует логике расходной и ШК в табличной части РН это временное кривое решение которое придется потом переделывать только документов будет уже не за пол года, а гораздо больше.

(35) курс я не помню, может и в 2й или 3й ).
п.с. и я не уверен что мой 5 курс в 98 году был позже твоего ) /я понимаю что можно на ты здесь/

(35) "У заказа есть куча действий и логики поведения которая не соответствует логике расходной и ШК в табличной части РН это временное кривое решение которое придется потом переделывать только документов будет уже не за пол года, а гораздо больше."

вот я и не вижу что конкретного есть у заказа ВБ, что диктует необходимость изменять типовую конфигурацию путём создания нового документа, а не реквизита в расходке?

(37) Маркетплейс не один. и работают по разному. Сегодня работаете с одним завтра с 20. во что таблица РН в конце концов превратиться? Я тоже начинал с 1 сейчас их 3 и логика работы с разным разная. Где то за доставку товара до конечного потребителя Маркетплейс где то уже наши проблемы. При подключение нового Маркетплейс меняется при необходимости только документ заказ рн трогать не приходиться.

(38) Верно. В шапке расходки стоит контрагент-маркетплейс. А в ТЧ всё тотже стикер заказа. Пусть у озона он 12 знаков например и всё отличие.

я пока не понимаю, как в вашем случае вы предполагается установить взаимосвязть между конкретной строкой расходки и отдельным документом "заказ маркетплейса"?

(39) это если у них свой склад и отгрузки конечным клиентам происходит с их склада а не вашего. + оплаты контролируют они и идут через них.

(40) Отгрузки со склада МП - это ФБО. ФБО - это немного другая история. Да там есть Поставка, это есть отдельный документ, в нём селлер сразу отгружает на склад МП определённый список товаров. Сущность "поставка" завести отдельным документов можно в 1с (правда не понимаю почему им не может быть уже существующий счёт или резерв).
Только это не решает проблему определения тех товаров, которые у себя затем МП продаёт конечникам, и определения продажной цены этих товаров.

Мой же выше вопрос был связан с продажами по схеме ФБС.
Но в обоих случаях нужно решение вопроса - увязать каждую списанную единицу товара с еженедельным финансовым отчётом маркетплейса, в котором он даёт конкретную цену продажи товара и показывает сам факт продажи.

Пока я вижу лучшим решением - добавить стикер продажи в ТЧ расходки.

(40) А оплаты всегда маркетплейсы сами контролируют ). При любом способе отгрузки товара. Вопрос только в том, чтобы это контролировать, т.е. иметь возможность сверяться с МП.

может тогда вообще это учитывать через реализация отчет реализатора. вроде этот документ ближе к реальной схеме работы.

(43) У меня самописная конфа, не использую типовую. Но не уверен что в типовой решена задача построчного сравнения комиссионных продаж

(39) В вайлдберриз не работаем. Но в озоне и ЯМ мы пошли по пути 1 заказ на МП - один заказ в 1с - один отгрузочный документ. И номер заказа соответственно в шапке документа.
И свертки удобнее проводить и возвраты и прочее. Визуально документов конечно прибавилось, но удобнее .

У нас FBS если что

(45) Каким образом ставится отметка в 1с, что отгружен конкретный заказ?

Ещё раз: совершенно похер по каким ценам вы отгружаете на МП. Цена отгрузки влияет только на взаиморасчеты между вами и МП в случае утери товара на стороне МП или возврата от МП.

(41) при передаче товара на мп - регистр "товары переданные" - отчёт мп - списание с этого регистра и запись в продажи по компании. Просто и прозрачно как в типовой Российской ТИС

(47) Естественно мне понятно, что похер какая цена стоит в ТТН . Но абсолютно не похер, цена финансирования, т.е. та цена, которую ВБ перечислит нам за проданный товар.
Т.к. только зная её можно вести сверку с маркетплейсом, и второе - получать конкретную прибыль в 1с в разрезе любой продажи, товара

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

Либо всётаки более простой вариант, который я пока держу в уме, Стикер заказа в ТЧ расходки, еженедельно обработка читает финансовые отчёты и по стикеру в расходках цену исправляет на верную продажную (тем самым прибыль будет как создаваться именно расходкой по бухучёту), и отдельно показывать  те стикеры, которые ещё не закрыты.