Вход | Регистрация
 

сравнение состояния документов ...

сравнение состояния документов ...
Я
   lamme
 
18.04.19 - 10:23
Задача.
делать важным клиентам рассылку о том - что его заказ был изменен (количество товара, состав  заказа, количество заказано,  плановая дата поступления, кол-во поступило , кол-во огружено) по сравнению со последним состоянием всех этих параметров.
(т.е. имхо - надо фиксировать "вчерашнее состояние" - чтобы сравнить с "сегодняшним")
Структура работы
- заказ клиента
- заказ поставщику
- поступление
- реализация
везде связь идет по заказу клиента. будь то документ-основание или назначение в тч документа

тут дальше идут рассуждения ..
Наверное, правильнее сделать РС. независимый. непериодический (хотя тут надо подумать). С колонками типа - Заказ клиента / товар / <Отслеживаемый параметр1> / <Отслеживаемый параметр2> /...

ну и как все это отслеживать

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

есть идея?

может оно и так все есть и типа - отчетами просто попользоваться ...
 
 
   ДенисЧ
 
1 - 18.04.19 - 10:24
Версионирование включить не вариант?
   Beduin
 
2 - 18.04.19 - 10:24
(0) Версионирование же есть
   lamme
 
3 - 18.04.19 - 10:25
включено

но - оно отслеживает только 1 объект (определенный док .. определенный спр)
а тут связка параметров - которая зависит от проведения того или иного документа
   Strogg
 
4 - 18.04.19 - 10:26
На вот тебе почти ТЗ:
РС Статусы Документов. Можно периодичсеский. ВидДокумента, период, Статус - Перечисление.
При определенных действиях (запись, проведение, изменение) пишешь туда статус документа.
Затем, делаешь красивый отчет со статусами и отправляешь его ключевым или каким там сотруднкам. Естественно. отправку фиксируешь в другом РС, чтоб дважды не отправить.
   lamme
 
5 - 18.04.19 - 10:28
(4)
мм ..
разжуй .. не понял ..
   lamme
 
6 - 18.04.19 - 10:30
важен же не статус документа по1С - который клиенту не интересен.
клиенту интересен товар - его состояние ..
когда ждать от нас - чтобы начинать монтировать 
и тд и тп
   Strogg
 
7 - 18.04.19 - 10:33
(6) хм, ну в любом же случае, это что-то типа статуса заказа, который будет меняться в зависимости от изменения дочерних документов. При достижении определенного статуса, клиенту отправляется сообщение.
   Darych
 
8 - 18.04.19 - 10:34
(7)+ ну да флажок какой-то нужен, чтобы примерно отслеживать
   1Сергей
 
9 - 18.04.19 - 10:35
(6) можно в момент записи документа оценивать суть изменений и решать что делать рассылку или нет
   Strogg
 
10 - 18.04.19 - 10:38
(9) как я понял, у него даже не в момент записи самого документа, а одного из связанных.
 
 Рекламное место пустует
   lamme
 
11 - 18.04.19 - 10:40
ну вот как я вижу ..
РС.
при проведении документа Заказ клиента - в этот РС пишем инфо
- заказ клиента
- дата
- товар
- количество в заказе


потом - в этот РС при провеении поступления или реализации или ... - находим строку с нужным параметром - заказ/товар .. и пишем туда необходимо значение


Сразу возникает вопрос
- распровели заказ
- изменили состав заказа (товар убрали .. заменили .. добавили..)

что делать с записями РС ..

или ..
заказ клиента был сегодня. сформировались записи сегодня
а поступление через неделю. как искать - в какую запись установить - что товар пришел (сам ж заказ погли провести сегодня - появились записи в РС. потом провели завтра - еще раз записи появились ..)
   Strogg
 
12 - 18.04.19 - 10:46
(11) я бы добавил еще и тип документа, породившего изменения в заказе.
"а поступление через неделю. как искать - в какую запись установить - что товар пришел (сам ж заказ погли провести сегодня - появились записи в РС. потом провели завтра - еще раз записи появились ..)"
тот же заказ, только регистратор, ну, или еще одно измерения, ПТиУ. Ну и статус, какой тебе заблагорассудится.
   lamme
 
13 - 18.04.19 - 10:47
блин ..
если искать последнюю запись и в нее писать информацию  что товара пришло столько то ..
тогда тут может быть так

01 01 провели заказ клиента. в РС записи появились.
02 01- перепровели заказ. записи еще раз появились. с новой датой.

10 01 утром. товар пришел. изменилась запись в РС от 02 01
10 01 в обед заказ перевроели ... и получается ж.
на состояние 10 01 вечер - есть запись в РС , но в нем не отражен приход товара.
   lamme
 
14 - 18.04.19 - 10:49
(12)
разжуй ... не понимаю

я зациклился на одном видении ситуации
и не понимаю (
   Strogg
 
15 - 18.04.19 - 10:50
"01 01 провели заказ клиента. в РС записи появились.
02 01- перепровели заказ. записи еще раз появились. с новой датой.  "
А вот тут уже тебе решать, какое событие должно порождать записи в РС, а какое нет. При перепроведении ты можешь решить, необходимо ли менять статус заказа, или нет. И если не необходимо - смотроеть текущий статус этого же заказа, и, если он не изменился - не делать никаких движений.
   lamme
 
16 - 18.04.19 - 10:50
что есть статус документа ?
   lamme
 
17 - 18.04.19 - 10:51
Статус = перечисление ( Проведен, Удален, Записан) ?
   Strogg
 
18 - 18.04.19 - 10:55
(17) да вообще любой: готов к отгрузке, зарезервирован под отгрузку, аннулирован и.т.д.....
   lamme
 
19 - 18.04.19 - 10:57
можно разжевать логику ?
   lamme
 
20 - 18.04.19 - 11:02
проблема пока именно в том - что когда кто куда пишет ... кто что когда отслеживает ..

может сделать иначе
- делаем РС - список документов - которые были изменены сегодня (заказы клиента, постепления, рееализации товаров)
Событие документа - при записи .
РС - не периодический. Но не дублировать записи - если один и тот же документ перепроводится. Просто - этот документ был сегодня изменен.
(а может просто в него писать только заказы клиентов - которые были затронуты сегодня. Например, изменили поступление товаров. но по факту - по назначени. - есть заказ клиента - состояние которого было изменено)
----------
Вечером - роботом - смотрим все измененные документы - заказ клиента.
и составляем слепок ситуации не сегодняшний день.
Типа - заказ клиента такой -то . дата изменения - сегодня. список товаров. заполняем количество пришло/ ушло / заказано ...

составили.
потом берем сегодняшнее состояние и "вчерашнее"
сравниваем по ключевым параметрам ...
----------
   lamme
 
21 - 18.04.19 - 11:02
?
   lamme
 
22 - 18.04.19 - 11:15
ап
   Strogg
 
23 - 18.04.19 - 11:47
(20) ну вот смотри: у тебя ключевой параметр - заказ, состояние которого интересно клиенту. Ок, идем дальше: на состояние заказа влияет хоз.деятельность, а именно, изменение каких либо документов, связанных с заказом по критерию отбора.
Таким образом, состояние заказа меняется одним из типов дочерних документов.
Например, при записи ПТиУ по заказу отслеживаешь: если пришло, к примеру, более 50% позиций, то статус заказа, например, порожденный документом ПТиУ будет "скомплектован более чем на 50%". Ну, или что-то в этом духе. Тебе надо определиться:
1) какие вообще будут статусы у заказа (какие статусы нужны клиентам)
2) при наступлении какого события, должны меняться статусы
3) при наступлении каких статусов, необходимо отправлять оповещение клиенту.
как-то так...
   seevkik
 
24 - 18.04.19 - 11:58
Что должно приходить клиенту? Данные о измененных позициях или просто уведомление об изменении со всеми данными? То есть нужны ли данные что были изменены или хватит только реквизита об изменении?
   seevkik
 
25 - 18.04.19 - 12:02
Как вариант - один реквизит - "Изменено" в Дополнительных сведениях, подписку на событие при которой этот реквизит заполняется и регламентное задание что находит измененные, отправляет клиенту и обнуляет сведение
Изменение конфигурации - одна подписка на событие
Дополнительные сведения уже есть, а регламентное задание как внешняя обработка
   seevkik
 
26 - 18.04.19 - 12:03
(25) естественно все в ваших руках, можно сделать несколько ДС "Изменена ТЧ Товары", "Изменен статус" и тп, но создавать лишний РС достаточно избыточно
   VladZ
 
27 - 18.04.19 - 12:07
(0) Я бы разбил задачу на два этапа:
1. Информирование клиентов о статусе заказа: заказ принят, заказано у поставщика, товар получен, Заказ отгружен заказчику.
2. На этом этапе уже заморачиваться списком товаров.
2.1. Расписать, какие могут быть ситуации (убрали позицию из заказа, изменили количество). Что из этого важно, что не важно. Что нужно отслеживать, что не нужно.
2.2. Разработать механизм контроля только для "нужных" ситуаций.
   lamme
 
28 - 18.04.19 - 12:50
(24)
клиенту должна уходить инфо до конкретного товара. не только общий статус по документу.

(26)
избыточность - да. так и есть.
   lamme
 
29 - 18.04.19 - 12:53
(23)
не .. когда просто отслеживать статус целого документа и делать уведомление клиенту - это одно
тут даже вопросов нет - как это сделать.

с товарами - полная засада ..
особенно - если изменили состав товаров
провели
распровели
и тд и тп
   Darych
 
30 - 18.04.19 - 13:02
(29) в хранилище? базе правда плохо будет
   lamme
 
31 - 18.04.19 - 13:23
(30)
не уловил
что значит - в хранилище ?
   Darych
 
32 - 18.04.19 - 13:34
(31) изв.. бегло прочел.
   _Дайвер_
 
33 - 18.04.19 - 15:04
Чтобы реализовать то что ты хочешь, нужно включить версионирование(при проведении) и  сравнивать по нужным тебе метаданным эти документы, и если есть изменения по ним, то отправлять  уведомление на почту клиента. С регистром сведений такая вещь не прокатит. Еще продумать варианты закрытия месяцев, или при групповом перепроведении документов, так как событие будет отрабатывать. Для этого нужно делать дополнительные записи в регистр сведений при проведении, измерение(заказ), ресурс (булево или перечисление) истина\ложь | Отправлено\не отправлено. И если отправлено то пропускать, чтобы не было дублированных писем. А еще можно продумать как именно убедится что письмо действительно отправлено, а не пост фактум поставлен статус. Примерно как то так, не идеально, но как вариант.
 
 
   Darych
 
34 - 18.04.19 - 15:05
(33) там версионирование не подходит
   _Дайвер_
 
35 - 18.04.19 - 15:07
(34) По ним можно сравнивать документы, только для этого
   Darych
 
36 - 18.04.19 - 15:08
(35) прочти всю ветку
   _Дайвер_
 
37 - 18.04.19 - 15:11
(36) Увидел, это сложнее)
   _Дайвер_
 
38 - 18.04.19 - 15:14
Можно проще обойтись, при проведении задавать вопрос Да\нет оператору, "Уведомить клиента о изменении заказа?". И просто отправлять текущую версию.
   lamme
 
39 - 18.04.19 - 15:35
(38)
и вот клиент получает 100500 писем ..
из них 
500 - по одному документу
400 по второму
...
...
..

как он потом будет определять - какое текущее состояние письма актуальное ?
   Darych
 
40 - 18.04.19 - 15:38
(39) ну это уже совсем другое
   lamme
 
41 - 18.04.19 - 15:41
(40)
да  - это называется - не уважение к клиенту
   Darych
 
42 - 18.04.19 - 15:44
(41) согласен
   _Дайвер_
 
43 - 18.04.19 - 15:49
(41) так кто мешает добавить дополнительную проверку? Если документ был изменен, клиент получит новый вариант документа, если нет, то и вопрос задавать не нужно (Модифицированность() )
   lamme
 
44 - 18.04.19 - 15:52
(43)
коммент поставили
документ Модифицированность()=Истина
а толку для клиента = никакой
   _Дайвер_
 
45 - 18.04.19 - 15:56
(44) Верно, можно свою проверку придумать. Вот есть статья на ИТС
https://its.1c.ru/db/metod8dev/content/2754/hdoc
   Darych
 
46 - 18.04.19 - 15:59
Так и пихай свой изначальный док в хранилище значений и по расписанию по критериям сравнивай - надо/не надо
   Garykom
 
47 - 18.04.19 - 16:05
(0) Задача изначально неправильно поставлена.
Сначала нарисуйте всевозможные формы-примеры сообщений для клиентов с нужными данными, о которых уведомляется.
А затем уже пытайтесь решить как получить требуемую информацию для сообщения клиенту.

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

Например если менагер десять раз отменил документ и снова провел - никаких сообщений не уходит, если прежнее сообщение равно текущему по инфе-заказу, ничего не добавилось и не убавилось и сроки не поменялись.
   lamme
 
48 - 18.04.19 - 16:53
(47)
почему НЕ правильно поставлена задача?
это = задача.
и смысл - уведомить клиента 1 раз в сутки по всем изменениям по накладным в разрезе до товара - которые его касаются.
те клиент раз в денб получает письмо со списком только того  -что было изменено
- товар - ожидаемая дата поступления изменена с .. на ..
- товар - пришло на склад
- товар - отгружено
------------------------------------------
как тут отталкиваться от отчетов клиенту ?
если пришло ушло - еще можно наверное по  отчетам ловить
то реквзит тч документа - дата прихда = уже в отчете нигде не выведется.

и тд


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует