| Автор |
Сообщение |
|
|
GusVal wrote:
Владимир Игнатов wrote:
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?
Да запросто...
...
Вот такая вот история....
Если смотреть по партнерам, то там одного удалили путем слияния... Но почему тогда при гашении Меркурий это не учитывает?
"Удалили путем слияния" - не важно. Хоть путем аннигиляции. GUIDы поменяться не должны. UUID - может, конечно, а вот GUID. Кому я это рассказываю? Зачем? Разработчики давно уже в каких-то нездешних высях розовых покемонов ловят, как я вижу...
|
 |
|
|
GusVal wrote:
Владимир Игнатов wrote:
GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!
У них разные Consignor.Enterprise.guid !!!
getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.
Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?
По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?
|
|
|
|
GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!
У них разные Consignor.Enterprise.guid !!!
getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.
Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?
|
|
|
|
exteris wrote:Кстати Soap.Rio не обязательно патчить. Можно же в обработчиках THTTPRio OnBeforeExecute и OnAfterExecute сделать сохранение запросов.
Да, правильно. У меня уже так и сделано, просто тогда так показалось проще. Чтобы все писать. Да и писать нужно с разными именами, хоть с прибавлением даты-времени, чтобы не стиралось одно другим и можно было увидеть всю цепочку запрос-ответов.
|
|
|
|
Лёлька)) wrote:У нас РСХН 100% вернул бы такую могилку  Нас то гоняют уже год,чтоб не было этих могил даже за пределы края. А на экспорт мы даже и не думаем отправлять кашу в ВСД. Уже привыкли. Нормально и очень удобно.Всегда все расписываем.
Мы иногда в Калининград отправляем. Т.к. продукция выведена из Меркурия (сыр), сертификатов на нее нет. Создаем товар через инвентаризацию поштучно каждую позицию с "выработана из сырья, прошедшего вет. экспертизу" (для промышленно выработанного сыра, думаю, не обманываю никого). УЛ создает транзакцию, в особых отметках - маршрут следования. Гос.вет.врач распечатывает пакетом, сам ставит печати на заднем листе пакета, товар едет. Несколько раз уже так доезжало.
|
|
|
|
Vlad74ru wrote:Что то меня начали "отстегивать" от ряда веток форума с "невинной" формулировкой:
For detailed error information, please see the HTML source code, and contact the forum Administrator.
com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'post_subject' at row 1
И это всего лишь за планету "Нибиру" и генерала Власова? Обидно)))
Читайте, что Вам пишут!
Data too long for column 'post_subject'
Строка темы слишком длинная, не лезет в базу.
|
|
|
|
start wrote:Признателен за благодарности...
Последняя версия - https://drive.google.com/drive/folders/1rpUVPvftQ6PMena1qkYkncu1XgUdqbME
Версия рабочая, каждый день отгружает по 100 накладных.
Там еще переделка под партионный учет, но пока сырая..
Mercury.zip - структура папок.
Work\Mercury\Soap.OPToSOAPDomConv.pas - исправлен по совету коллеги Игнатова (низкий поклон, я бы сам не справился).
Следом: в Soap.InvokeRegistry.pas заменить метод
Проблема в том, что при вызове RegisterExternalPropName с уже существующим InternalName исходный метод все равно добавляет связку InternalName - ExternalName в массив, а нужно - заменять ExternalName в имеющемся элементе массива.>
|
|
|
|
Vladimir2017 wrote:Похоже просто ApplicationID скис. Сейчас по нему три дня дают ответ и потом "забывают".
Не "забывают", а "сдают в архив". Сколько там миллиардов ВСД в год планировалось в Меркурии сделать? На каждый ВСД - явно больше 2 заявок (создать, погасить), т.к. еще кучи "прочитать список". И все в архиве хранится.
|
|
|
|
Lele4ka13 wrote:
Mak_VET wrote:А пойдемте все в лес? Ну его этот ФГИС. Прям яблоко раздора.
Пойдемте!!! Там сейчас грибооооов уйма после дождиков)))
В Ленинградской нет еще: не промокло.
|
|
|
|
А самому, лично своими ручками - никак? Делается ровно так же, как написано.
|
|
|
|
Ириала wrote:Не все предприниматели работают нормально. У нас были случаи, когда предприниматель отправлял пробы в ветлабораторию от одной партии, а потом результаты прикреплял совсем к другой.
Вот и я про то.
Ириала wrote:Если я не отбирала пробы сама, я ветдокументы на партию выписывать не буду, могу только на эти 5 кг проверенных
С другой стороны - партия 20 тонн. Всю фуру везти на анализ?
|
|
|
|
TWAIN wrote:Объясню проще. Допустим у многих идет работа по расписанию.
Думаю, половина запускает раз в 15 минут, четверть раз в полчаса, четверть раз в час.
В результате в 12:00 к ним валится несколько тысяч запросов списков
от всех интеграторов и все получают дружную 12-ю ошибку.
с 1С не совсем так, но там тоже не все хорошо.
У меня пауза до следующего запроса плавает. Так вот, сейчас посмотрел в логи: никакой корреляции получаемых APLM0012 от минуты, в которую происходил запрос, глазом я не вижу. Можно, конечно, провести НИР и выполнить стат. обработку...
|
|
|
|
TWAIN wrote:
Владимир Игнатов wrote:
TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.
А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?
Ну, исходящие вы знаете ID и запрашиваете конкретно по ID, производственные - тоже.
А зачем? Я все равно синхронизирую все, и свои и чужие, поэтому все по get...changes... Зачем организовывать 2 очереди, 2 обработчика и т.д.? Забираем все от времени последнего изменения, все обрабатываем. Проще, линейнее обработка.
TWAIN wrote:
Владимир Игнатов wrote:
TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза
Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).
Тут тоже понятно что хотят. В 1С все задания любят сбрасываться на 1 секунду.
30 регламентных заданий, а запускаются все одновременно.
И поедут разными пакетами по Интернету. И наложатся на 1000 еще таких же, даже в ту же секунду сработавших, но из других городов и весей. И при приходе к их шлюзу все запросы сами расползутся на несколько секунд.
|
|
|
|
- наделение уполномоченных лиц организаций полномочиями по осмотру перемещаемых подконтрольных товаров (исключая животных), транспортного средства, которое используется для перемещения подконтрольного товара, осуществлению отбора проб подконтрольного товара и его направление на лабораторные исследования, направлению подконтрольного товара для проведения ветеринарно-санитарной экспертизы;
Я, конечно, со стороны ХС, а не со стороны гос.вет. врачей, но по-моему, это перебор. Тут или эти УЛ должны (просто обязаны) быть святыми с нимбами и справками о канонизации, или у них должна быть уголовная (вплоть до расстрела) ответственность за "отрезал не с того края, который уже пованивать начал" и "отправил на исследования из одной партии, а продал другую".
|
|
|
|
TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.
А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?
TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза
Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).
TWAIN wrote:
- По старым заявкам просят ничего не запрашивать, через три дня они уже уходят в архив и недоступны для запроса.
О! Наконец-то озвучено время, которое заявка может быть in_progress!
TWAIN wrote:
- Анализировать системные ошибки и исправлять схему работы
- Анализировать ошибки в бизнес-логике и исправлять схему работы
Пожелания самим себе.
TWAIN wrote:- Запрет на интеграцию через автоматизацию веб-сервиса.
А вот это - вряд ли. Они ещё нам будут указывать, какой рукой мышку держать, когда по их сайту ходим! 
|
|
|
|
|
|
![[Search]](/vetrf-forum/templates/default/images/icon_mini_search.gif){kind=icon}
Поиск
![[Recent Topics]](/vetrf-forum/templates/default/images/icon_mini_recentTopics.gif){kind=icon}
Последние темы
![[Members]](/vetrf-forum/templates/default/images/icon_mini_members.gif){kind=icon}
Список участников
![[Groups]](/vetrf-forum/templates/default/images/icon_mini_groups.gif){kind=icon}
На главную страницу
![[Register]](/vetrf-forum/templates/default/images/icon_mini_register.gif){kind=icon}
Регистрация /
![[Login]](/vetrf-forum/templates/default/images/icon_mini_login.gif){kind=icon}
Вход