Добрый день. УТ11.3. ТСД работает на Cleverence Soft.
На данный момент реализована такая схема:
1. На ТСД грузится заказ целиком.
2. В 1с в заказе изменяется у части товара статус на "К отгрузке". В регистре товаров на складах соответственно из свободного остатка они уходят в отгружаемые. Оттуда мы их достаём и печатаем форму Подборочного листа, с которым кладовщики подбирают товары для заказа.
3. Подобрав товар по Подборочному листу, с терминала заказ грузится как реализация, в которой привязываются строки к строкам заказа и товар уходит из остатков.

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

Решил попробовать оптимизировать схему. Задумка такая:
1. В заказе ставятся нужные строки на отгрузку, на основании них формируется реализация товаров услуг только по нужным строкам.
2. На терминал грузятся реализации и по ним идёт подбор - т.е. непосредственно в док на терминале попадает только то, что нужно отгружать, а ни весь заказ.
3. После подбора реализации на ТСД, документ грузится в созданную реализацию товаров услуг в 1С для проверки расхождений (тонкий момент - нужно что-то с расхождениями делать ещё).

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

Я ещё подумал про ордерную схему чтоб из заказов создавать промежуточный док, а на основании него уже после всех расхождений с фактом делать реализацию. Но ордерная схема работает в другом порядке и логика там в ут11.3 такая, что сначала реализация, а поотм ордер, делающий движение товара по складу. Т.е. типовая ордерная схема не подходит.

ап

В заказе ставишь строки в режим "к отгрузке". Этот набор строк по заказу сливаешь на ТСД. Проводишь подбор товара с использованием тсд. Подобраные товары - а это может быть подмножество скинутых на тсд, а не все - скидываешь в расходный ордер, строки заказа переводишь в состояние типа " готово к отгрузке". Упрощенно как-то так

(2) плюс может получиться что строка заказа по результатам сборки может расщепиться на две... К отгрузке и готово к отгрузкн

(0) "Т.к. у кладовщиков на терминале весь заказ вместе с теми строками, которые нужно отгружать и не нужно отгружать" там обработки на языке 1с, поменяйте под себя да и всё

>>Но ордерная схема работает в другом порядке и логика там в ут11.3 такая, что сначала реализация, а поотм ордер, делающий движение товара по складу. Т.е. типовая ордерная схема не подходит...

1. Порядок оформления накладных и расходных ордеров ставишь в "Сначала заказы, затем ордера и накладные"
2. В заказе для нужных строк ставишь "Отгрузить"
3. в АРМ Отгрузка появляется твой заказ с состоянием "Ожидается отбор". Жмешь кнопку "Создать ордера". Ставишь статус "К отбору", распечатываешь задание на отбор.
4. После сбора заказа оный проводится, статус ставится в "К отгрузке".
5. После этого, в журнале Накладные к оформлению появляется твой заказ, выдяляешь его и жмешь "Оформить по отгрузке". Создается РТУ.
6. После этого расходный ордер переводится в статус "Отгружен".

Вот так работает типовая схема.

(4) +1. Не понятно, зачем вы грузите заказ целиком, если только часть строк отгружаете. Грузите только то, что нужно. В чем проблема в этом случае?

(6) как обычно ;-)
Кто-то занимается тем в чем нет квалификации ;-)
И внезапно выясняется что склад живёт немножко по другим законом чем учётная программа которая оперирует какими-то обезличенными строчками каких-то документов в базе...

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

Как закончится этап массовых отгрузок, снесу временную схему и  попробую через ордера сделать.

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

(9) "Но это уже к этапу проверки чего они там нащёлкали на складе."
= вот чего они нащелкали на складе - надо считать как правда. а вот проверять надо - что там у вас по учету в базе значится и какое это имеет отношение к действительности

(10) конечно. Этап проверки = сверка факта и плана, в результате которой выдаются автоматизированные пинки в правильном направлении для проверки того, кто же накосячил.

По факту, расхождение плана с фактом чаще всего является ошибкой склада. По крайней мере тут.