Хранение данных обработки между сеансами

1. Areal 14 06.08.21 00:18 Сейчас в теме
Добрый вечер!

Написал обработку, которая периодически шлет заявки на доставку (Заказ клиента, Возврат, Реализация и т.п.) на внешний сервис. Часть заявок может быть отменена, а чтобы удалить их в сервисе необходимо конкретно их выгрузить отдельным методом.


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

Так вот, встал вопрос - А где, собственно, хранить эти межсеансовые списки документов внешней обработки?
По теме из базы знаний
Найденные решения
11. Areal 14 06.08.21 23:13 Сейчас в теме
Пришел к выводу, что сохранение списка последних отправленных документов в каком бы то ни было виде ,с последующим сравнением с новым списком, не гарантирует выявление сторнированных заявок, т.к. список ранее выгруженных документов уже может не содержать сторнированные заказы из-за вариаций предполагаемых пользовательских настроек обработки.

Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Остальные ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
3. alxarz 31 06.08.21 02:35 Сейчас в теме
(1)
А где, собственно, хранить эти межсеансовые списки документов внешней обработки?
на диск можно сохранить, или с этим какие-то проблемы?
4. Areal 14 06.08.21 18:19 Сейчас в теме
(3) Использовать файловую систему прям совсем не хочется. М.б. есть какие-то варианты? ХранилищеНастроек и прочие Хранилища умеют хранить в себе ссылки на документы?
2. FatPanzer 06.08.21 00:31 Сейчас в теме
Ясно же где - в регистре бухгалтерии!
5. Areal 14 06.08.21 18:24 Сейчас в теме
Пока что в голову приходит лишь создавать Соответствия с парой ТидДокумента - СтрокаУИД и все это запихивать в Хранилище, но это как-то затратно по машинным ресурсам....
6. Sashares 34 06.08.21 18:57 Сейчас в теме
(1) Для этого в идеале надо статусную модель документам - Не отправлен, Отправлен, К отмене, Отменен и тд.
Статусы для документов логично хранить в регистре сведений и соответственно менять при определенных действиях. Одной обработки для нормального обмена тут не достаточно.
7. Areal 14 06.08.21 19:10 Сейчас в теме
(6)Тут проблема в отсутствии единой архитектуры "API" для подсистемы доставки в УТ11 (КА, ЕРП) и, скорее всего, всю подсистему сделали чисто для галочки. Потому, где-то есть статусная модель, где-то ее нет, а есть вообще документ Поручение экспедитору, который на фиг ломает всю логику, как программную, так и человеческую
8. Sashares 34 06.08.21 19:16 Сейчас в теме
(7)Просто иначе гарантировать нормальную работу обмена кажется не реально.
Надо где то хранить, был ли отправлен документ, чтобы не отправлять повторно, и чтобы в случае необходимости его отменить.
То есть статусы именно для данного обмена.
9. Areal 14 06.08.21 22:16 Сейчас в теме
(8) К сожалению, обработка не предполагает столь масштабного перекроения УТ. На самом деле есть способ узнать отменен заказ или нет - если его не видит алгоритм обработки и его нет в Задании на перевозку, значит доставка отменена и если этот заказ уже был выгружен, значит для надо отправить отдельный POST запрос на удаление.

И вот ключевой момент тут - если этот заказ уже был выгружен.

Первое, что на ум приходит - сохранять в Хранилище Соответствие с парой ТипДокумента-УИДдокумента(по-моему, нельзя сохранять ссылки на документы(мутабельные значения) в Хранилище) для выгружаемых документов, а в следующей сессии сравнить новый список со старым и отсутствующие проверить на сторно

Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система

Минусы - Если заказов будет реально много, то процесс сравнения будет сильно грузить систему, т.к. потребует поиска доков по ГУИДАМ



Второе - использовать штатный механизм дополнительных реквизитов в документах вместо статусов.

Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система и я не очень доверяю Хранилищу(ибо это такая "черная коробочка")

Минусы - для доп рек придется немало продумать и написать кода для "защиты от дурака", каждый выгружаемый документ придется перезаписывать, потенциально тяжеленные запросы для выборки всех отправленных документов
10. Areal 14 06.08.21 22:20 Сейчас в теме
(9)
Первое, что на ум приходит - сохранять в Хранилище Соответствие с парой ТипДокумента-УИДдокумента(по-моему, нельзя сохранять ссылки на документы(мутабельные значения) в Хранилище) для выгружаемых документов, а в следующей сессии сравнить новый список со старым и отсутствующие проверить на сторно


Хотя, можно сначала сравнить строковые ГУИДЫ, вычленить отсутствующие ГУИДЫ и уже по ним вывести документы для проверки. А пару делать УИДдокумента = ТипДокумента.
Это существенно снизит нагрузку.

Есть ли у кого более оптимальное решение?
11. Areal 14 06.08.21 23:13 Сейчас в теме
Пришел к выводу, что сохранение списка последних отправленных документов в каком бы то ни было виде ,с последующим сравнением с новым списком, не гарантирует выявление сторнированных заявок, т.к. список ранее выгруженных документов уже может не содержать сторнированные заказы из-за вариаций предполагаемых пользовательских настроек обработки.

Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)