(бред, конечно, но тем не менее)
на входе: есть файл заявки покупатели (грузим в базу и пошло-поехало штатное обслуживание заявки)
на выходе: отгрузочные бумажные документы (пусть будет торг12)
задача: обеспечить в отгрузочных документах порядок строк, такой же как в исходной заявке покупателя
т.е.
в заявке покупателя:
001: артикул659
002: артикул700
003: артикул578
..
950: артикул123
.
если товар на отгрузку отсутсвует - то в выходном документе просто строки не будет соответсвующей:
торг12:
003: артикул578
006: артикул456
..
830: артикул555

.

как решить без изменения конфиги в рамках УТ11?
Спсб.

Внешней обработкой печатной формы?

(1) ты реально, блин, умный - я бы сам не догадался.
как в ВПФ будешь обеспечивать требуемый порядок строк?
(менеджеры во время обработки/прохождения заявки могут неоднократно для своих целей менять порядок строк)

(2) Тогда, чего спрашивал-то? ))

15 минут прошло.. где все спецы по ут11? ;-)

(3) я не УТ-ник, может(или даже да) много не знаю... может как-то можно извернуться?

(4) Бутерброды с красной икрой едят. Некогда им.

(0) Чой-то бред? У нас большинство бюджетников просят - как в ком. предложении и порядок, и наименование.

"...как решить без изменения конфиги в рамках УТ11..."

добавление нового РС, например, считается?

(5) в момент печати есть инфо о начальном порядке? файлик там пристегнутый или в заказе покупателя строки как надо?

"...грузим в базу и пошло-поехало..."

чем грузим? своей обработкой?

если рс разрешено - при загрузке своей (если своя) прибулдой пишите в этот рс (свой) для нужного дока как шли строки (структуру рс придумать не сложно)

в впф смотрите в рс параллельно и вот

+ (7) В 7.7 - делала новую таб. часть (в реализации), которая заполняется по счету (без пересчета, без редактирования, короче, тупо копируется из счета) + контроль сумм (на всякий пожарный), ну, и печать из этой таб. части (вкладка + кнопка).

(9) смысл какой: взят табличку с Артикул-НПП, подсунуть ее в запрос получения номенклатура на печать, соединить и отсортировать

(8) если не будет мешать типовому обновлению и работать (вообщем) после обновления - то да.

(11) не хочет тс менять конфу.
ну первая причина, что приходит в голову - дальнейшее обновление.

а создание нового РС на обновление не повлияет.

(13) новый РС не будет мешать

Важно: оператор/менеджер печатающий документ никаких выборов и принятия решений не делает (допускаются "настройки" которые делает "грамотный"). условно: нажал кнопку - распечатался требуемый документ - для клиента которому важен порядок строк - распечаталось в порядке исходных строк, для клиента которому пофиг - как есть...

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

(17) ну и смотрим РС.
есть записи по доку - сортируем из рс
одному-то из типов клиентов пофиг как строки идут

нет записей в рс - не ориентируемся ни куда и печатаем стандартно.

все в одной впф.

(16) Вариант - сделать печать накладной и сф из заявки. Тупо печатные формы. Кстати, автоматом можно сохранять печ. формы.

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

(16) исходный порядок при этом где-нибудь есть?

(19) вы прочитали:

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

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

(20) вот - начали люди понимать - спс.
я тоже спрашивал - чем грузят. Если свое - добавляем допил обработки загрузки для писания в РС.

как вариант, ввести в печ формы заказа и соотвестсвенно потом РТИУ и СФ сортировку по коду или артикулу, и не важно какой порядок в ТЧ

(21) дано: исходный файл заявки - он однозначно есть НА ЭТАПЕ ЗАГРУЗКИ данных. дальше - можно придумывать что угодно и как угодно

(22) Ну, и бред тогда.

(26) ну ка? в чем?

(25) обработку загрузки можно модифицировать? (26) в чем бред?

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

(28) Если обработка загружает и записывает документ, до того как показать его пользователю, то можно и подпиской на новый документ сохранять порядок строк

(27) (28) В том, что исходной сортировки в эске нет, поскольку сортировку в заявке могут менять.
Как потом (в случае чего) проверять? Искать файлик с заявкой? Где и кто?

(22) ВПФой можно заменить печать стандартной формы?

+ (31) У меня лично, и клиент может поменять заявку (порядок и наименования) до реализации. Еще десяток плодить?

(28) обработка загрузки - да, моджно, это своя обработка, частная...

(33) для начала считаем что заявка может только УМЕНЬШАТЬСЯ

(31) Это суть задачи - иметь (записать) порядок строк номенклатуры.
(32) Да.

А вот если обработка загружает заказ с пропусками номенклатуры, то тут сложнее. А если ещё и предоставляет порядок строк до загрузки менять - запретить!

(31) чего нет то? в РС при загрузке записал Артикул-НПП и сортируй при печати как надо

бред - делать левые ТЧ и проверки-конрольки

"...то можно и подпиской на новый документ сохранять порядок строк..."

вот, кстати, пока курил - тоже про подписку подумал.

обработку допиливать не надо, на обновление не повлияет.

единственное, что писаться в рс будет для всех заявок исходный порядок строк (что не всегда нужно ИМХО)

(35) да и пусть ее уменьшается
ты ж сортировать будешь по строкам документка, к которым левым соединением прилепишь НПП из РС
вот если будут строки вообще без НПП из РС, типа заменили номенклатуру на аналог, тут думай куда такие строки отправить, вверх или вниз

Теоретикам виднее... Разгребать - Злопу :)

(40)
по мне дык - одно из явных решений, что пришло в голову.
вроде красиво получается.

(19) не выйдет. ГТД.

(20) пофиг как грузим. в самом худшем варианте - вбиваем руками. но это уже фоорс-мажор - его не рассматриваем ;-)

(38) "единственное, что писаться в рс будет для всех заявок исходный порядок строк (что не всегда нужно ИМХО)" - тут когда грузим - клиент нам известен (спозицинирован по базе) - на него скрее всего можно ввести какое-то свойтсво для клиента типа "СтрогийПорядокСтрок=ДА"..?

(42) Чой-то? Такой вариант печати - только после создания док-ов (накладная + сф). Все данные (номер, дата, партия, ГТД и пр.) берешь оттуда (из док-ов). Делаешь новые внешние печ. формы, в которых переписываешь обработку таб. части.

(44) ну вот - тем. паче

(44) + четко

(40) мне разгребать не надо. в клюшках все давно и просто/красиво реализовано. клюшки они клбюшки, в меясц по релизу с переделками не выходит... думаю вперед про переползание на УТ 9к тому времени наверное ут12 или 13)

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

Подписку на событие ПередЗаписью и там сортировать по заявке

(45) сорри, в предыдущем стрындел не подумав тщательно.
но чем-то мне такая концепция все равно не нравится.

Как саму сортировку написать надеюсь не нужно пояснять?

(50) вы все читали?

А нужно именно в бумажной печформе, или и в документе?

(52) Я - сова (пока). Проблемы ежиков пока не волнуют

(54) как минимум в бумформе. в документе тоже вообщем не помешало бы наверное

(48) а там как реализовывал (если есть там такое) ?

через Спр или, например, через док полукопию - невидимку ?

да хотя, в общем, неважно - левое соединение ТЧ заявки с ТЧ отгрузочного дока с сортировкой по порядку, определяемом заявкой, и все...

Хотя в печ формах своя сортировка не зависящая от документа, так что возможно и их придется доделывать

(58) порядок строк заявки по дороге поменять могут - насколько я понял автора, а нужен порядок как было изначально загружено/забито.

ну я так понял

(51) Думай, Чапай, думай (С)
Такая фишка - вообще бред. Полный. Но - есть :(

(59) про ВПФ опять упустили товарищь?

(55)  "Все люди делятся нa: а) Cов - встaют поздно и поздно ложатся б)Жаворонков - рагно встают и рано ложaтся; в) Дятлов - из-зa них совы встaют рaно, a жaворонки ложaтся поздно."©

(57) реквизит в ТЧ заявки и в ТЧ реализации, ОПС = " (ОригинальныйПорядокСтрок) и свойство контрагента ОПС=Да,

(60) А вот вопрос: если клиент попросил изменить? А заявка уже загружена...

(0)В исходном документе всего один товар.
В процессе работы с заказом, клиент поменял свое требование. В измененном заказе 5 позиций, и исходного нет совсем.
Какой порядок должен быть?
И да - бред конечно. Никогда не понимал таких запросов.

(60) да

в свое время - когда формат ЕДИ требовал совпадения номеров строк - пришлось вводить в заявку "номер строки заказа"

(66) В точку :)
С бюджетниками не работал? Везунчик :)

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

(66) усложняю задачу: заодно поменяли не только товар, но еще фирму и контрагентм, сменили валюту, и вместо расхода сделали приход...

(65) я думаю, это вопрос другой уже.
Изначально ТС этого не просил, а просил именно то, что просил.

(68) угу, практически оно.

(66) см (70)

сделать отдельную внешнюю обработку.
2 реквизита
доумент поступления
документ реализации

обработка читает из первого порядок строк, меняет во втором... Это если тупо в лоб решать.

(70) Смотреть надо ширше, а думать - глубже (С) :)
А если клиент от исходной заявки оставил только сумму и пару позиций (из десятка)? Все остальное - переделано. И по текущей заявке.
Слабо? :)

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

Кстати, совсем кардинально (и с минимальными потерями): при поступлении заявка распечатывается, при реализации - манегер сортирует (ручками!!!) по распечатанной заявке.

(76) возможно. но путем длительной работы клиенты в целом воспитаны. НА ЭТАПЕ СОГЛАСОВАНИЯ ЗАЯВКИ - пофиг что там.

(78) затрахаешься сортировать ручками 700 строк

(77) Клиент изменил уже загруженную заявку. И теперь она другая. Чего не понятно?

(80) Не хрен менять :)

(73) ну значит сохраняй при первой записи тч заявки в РС, а потом - левое соединение ну и т.д.

путем среднего втыкания в предложенные решения - делаю вывод
- решить можно без ущерба для обновления
- потребуется сделать клон ЛЮБОЙ типовой печформы в виде ВПФ(в ней при печати сортируем как надо), подключить ее вместо этой ЛЮБОЙ типовой печформы чтобы при печати все далалось автоматом (возможно?)

- так?

(81) см (83) и выше.

я задолбался что-то уже талдычить

(84)
про записи в рс забыл либо при загрузке либо в подписке приЗаписи, ориентируясь на доп реквизит контра (чтобы записи для всех доков в рс не делать)

еще в (8) начал намекать на РС
+ см (10), например.

Не пойму, в чем сложность-то?

Если нужен порядок именно из исходной загруженной заявки (без учета, что кто-то из пользователей мог поменять уже загруженный документ), то нужно где-то сохранять при загрузке копию таб. части, неважно где - в регистре или в дополнительной ТЧ документа.

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

(88) да в том-то и дело, что нет проблем совсем никаких.
некоторые, может, просто идею не поняли.

да и...
..или в дополнительной ТЧ документа.. не вариант

(89) Почему доп ТЧ - не вариант? На обновление влияет ровно так же, как и регистр - т. е. никак, зато писать туда при загрузке чуть проще, чем в регистр.

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

(68) у нас это до сих пор по одной сети продолжается. Нам проще, исходное сообщение всегда есть. Читаем его заново и сортируем строки.

(0) если без изменения - исходное сообщение при приемке записывать в справочник "Файлы", тупо бинарником. РС и таб.части здесь не обязательны, т.к. речь идет не о проведении/построении отчетов, а о печати, которой скорость не так важна.
Периодически чистить этот справочник.
Печатную форму свою.

Офф: почему вдруг УТ11? Вот уж от кого не ждал ))

(92) Это вроде только Эксайт требовал в лохматом году?

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