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

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

А как лучше?

Впрочем, проблема не в том, когда происходит запись.

(2) В типовых это сделано через РС. Типа как дополнительные свойства сделаны

(4) РС - ?

А! регистр сведений. Извините, туплю.
И что туда пишут? Пример можно? Какой регистр?

(6) Создай периодический РС с измерением "Заказ покупателя" и ресурсом "Статус". При проведении реализации и прочих доков по заказу - пиши в него.

В форме заказа - просто считывай текущий статус из РС на форму, если требуется в самом заказе статус отображать.

Либо, если речь просто о "обработан/необработан" - то вовсе без ресурсов. Наличие записи в РС по заказу будет означать, что заказ обработан.

(7) защем периодический РС?

(0)Если проведенная РН считается признаком завершения заказа, то зачем тебе какие то еще регистры? Простым соединением по ДокументОснование и условием на проведен спокойно можно получить завершенные и незавершенные заказы

Ну можно и не периодический, если интересует только текущий статус. Если нужна история статусов (и если сами статусы нужны) то вполне себе вариант.

(10) а если у одного заказа несколько РН?

(12)И как тогда будет в случае ТС проставляться завершен или нет? :-)
Если завершен только когда все проведены - тоже не проблема.

+(13)Найдется хоть одна РН непроведенная- не завершен. все проведены- завершен

(14) а РН "Заказы покупателей" не кошерно использовать?

(15)А что в нем? А то у меня такого нет.

(15) ТС конфу не озвучил. Мож там наколенная самописка на справочниках вообще.. откуда там РН-у взяться.

(16) Если у заказа остаток нулевой по этому регистру - значить заказ закрыть

(18)Скорее всего не катит такой вариант.Сплошь и рядом заказанное отличается от реализации.

только если оно потом закрывается как то в ноль, тогда можно

(6) возьми типовую БП 3.0 и посмотри как там сделана галочка "оригинал получен"

А вообще у меня есть похожее только с заказом поставщику.
И я потьом делаю на его основании док "Закрытие заказа поставщику", который закрывает все хвосты.Можно такой же док прикрутить к заказу покупателя

Ну вы даёте. А как же в типовых вопрос решается? А если несколько реализаций по одному заказу?
Есть же решение.
Регистр накопления. Заказ - приход. Реализация - расход. Хотите по позиционно, хотите по документу. Чем не устраивает?

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

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

Всем спасибо. Очень интересно. И все-таки: писать в документ не нужно именно по той причине, что у меня возникла или почему-то еще?

(26) это вопрос уровня эксперта 1С, если не обладаешь достаточными знаниями о таблицах баз данных СУБД, то не поймешь ответ на этот вопрос

(27) Но увидеть этот ответ можно? А что я пойму-не пойму - это моя проблема. Поделитесь уж высшим знанием, пли-и-и-из!

(28) без фотки не взелтит

(26)  потому что это мутное решение. Заказ выписан в понедельник. Сейчас пятница. Делориан ещё в продажу не запустили, нельзя взять и просто так из пятницы метнуться назад в понедельник.
Запись текущей датой в регистр сведений эквивалентна тому что сегодня, в пятницу, ты взяла и сделала отметку НА понедельничном документе. Не В понедельничном, а На

Ну и простое соображение
Манагер любят делать новые заказы копированием старых
Вот он скопировал старый заказ, провёл и он внезапно уже с отметкой

(0) пиши статус в отдельный регистр сведений

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

5 лет 9 месяцев 29 дней...

Продолжайте в том же духе. Чем больше среди одинэсников копрокодеров, тем выше моя ценность на рынке труда.

(34) Спасибо. Мне так не хватало вашего напутствия.
А ваше желание укусить сигнализирует, что ваша ценность на рынке труда, видимо, не так высока, как вам бы хотелось.
И кусая тех, кто подвернулся по пути, вы ее несомненно повышаете.

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

(35) а я ещё и гавкаю злобно, чтобы всякие гопники в мой огород не лезли... ;-)

(35) "Дурака учить - мпх тупить"...

+(30) еще потому, что в норме у продавцов не должно быть ни каких прав на реализацию. А это решение требует права на запись. А право на запись у манагеров в реализацию - is a good way to shoot yourself in the foot.
У нормального продавца шило в жопе, он всегда стремится срезать все углы, до которых дотянется, иначе это не продавец, а балласт. По этому этим людям права надо давать строго дозировано. И -под роспись кровью. Из носа.

сабж следует решать оборотным регистром

заказ пишет сумму заказаную
реализация сумму исполненую

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

(40) В семерке решается 2-мя дополнительными справочниками.
Один - накопительный, итоговый, второй типа регистра сведений.
Ничего сложного.

(41) все правильно, потому и - обороты, а не остатки.

Заказ - это план, реализация - это факт. План с фактом ни когда сходиться не будет. Особенно, если добавить еще удаленные склады и ордерную схему, потом привинтить недовозы-перевозы.

Решение, основанное на (40), даст над этим всем говном какой-то контроль и возможность уровень сервиса посчитать.
Но это на практике все трындец, как не просто.

(41) а вот в этом случае нужна РУЧНАЯ галка в заказе...

тем самым мы имеем как аналитический признак "закрыт/не закрыт", так и качественный "исполнен на 90%"

это очень важно например при начислении бонуса менеджерам, что бы все была видна эта разница.... Да и вообще при анализе эффективности работы менеджеров по продаже без план/факта по заказам не возможен.

(0) Если реализация создана, то заказ обработан. Для определения этого статуса достаточно посмотреть на регистр Заказы покупателей или на реквизит ДокОснование в реализации. Огород не нужен. Можно использовать регистр сведений Дополнительные сведения.

(44) > а вот в этом случае нужна РУЧНАЯ галка в заказе...

Не галка, а кнопка, на которой отображается текущий статус заказа. А реквизит "Галки" в реквизите справочника.

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

(45) Не всегда. У нас считается отработанным заказ, если он доставлен клиенту. И этот факт отмечается доком "Доставка товара (отчет)".

(46) У каждой конторы может быть разное ТЗ. Ну, а реализация может быть еще больше. Я предложил один из вариантов, который не затрагивает код типовой конфигурации. Контекста использования этой функции ТС не озвучил.

(47) Да. Я говорю как это все у меня в интернете магазине 1-го типа сделано.

Выстрадано и отлажено.

(45) (46) как отрабатывать частичную отгрузку? заказ один а отгрузок десять в разные дни?


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

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

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

после моего увольнения с этой работы - прошло 11 месяцев, программиста так и не взяли... все работало без меня, единственное меня сейчас позвали проверить обмены и последовательности...

(50) + например "закрытие заказа" начисляет бонусы менеджеру...

Задачка очень простая. Наши заразы теряют заказы. Не все обрабатывают. Поэтому была просьба, чтобы в списке заказов те, по которым есть проведенная реализация, помечались цветом. Вот и все.

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

(52) Вот и сделай запрос, который работает в зависимости от условий, которые можно вычислить из уже существующих данных без дополнительных телодвижений.

Про то, насколько полностью он выполнен, пока речи нет, я уточняла. Сейчас хотят, чтобы не оставались совсем необработанные.

(54) Но у меня пока нету вашего дополнительного регистра.

(56) Сделай. Что мешает?

(57) Да вот думаю, обязательно ли это нужно. Советуюсь с добрыми умными людьми

(52) > Задачка очень простая. Наши заразы теряют заказы. Не все обрабатывают. Поэтому была просьба, чтобы в списке заказов те, по которым есть проведенная реализация, помечались цветом. Вот и все.

Типа: http://prntscr.com/fkepd0

(40) У нас на остатках сделано, потому что по заказам меняются и подбираются поставщики. На крупных заказах дискретности поставки не хватает и из "хвостиков" вполне набирается вагон или два. А есть ещё режим "опциона до 10%" и куча разных других плюшек.

(58) Ну мне кажется
или РС делать.
Или фоновым заданием по ночам галки ставь)

(54) А этот запрос будет при выводе строки работать на форме списка?