Сообщения, отправленные пользователем: kuzmin

Здравствуйте.

Столкнулись с проблемой загрузки предприятий ХС, а именно с некорректным XML содержимым:
SQLSTATE = S1000
[Sybase][ODBC Driver][Adaptive Server Anywhere]XML parser error: character: 8073, line: 1, column: 8073
Illegal control character

Виной оказался символ SUB в наименовании предприятия.
Как поступать в такой ситуации, исправлять своими усилиями внося правки в XML, заменяя указанный символ на пусто, или произойдет магия и правка произойдет на Вашей стороне?)))

Пишу сюда исходя из ветки форума))):
"Автоматизированная система МЕРКУРИЙ
Форум, посвященный разработке и внедрению системы оформления ВСД в электронном виде. Приветствуются любые мысли и идеи по теме. Приглашаем всех вас в соавторы системы."

http://help.vetrf.ru/wiki/ResolveDiscrepancyOperation_v2.0
При оформлении инвентаризации по изменению/удалению в веб форме достаточно ввести номер записи журнала продукции и фактический объем.

Но при оформлении через Ветис.API, казалось бы достаточно указать UUID и VOLUME, но возникают ошибки.
запрос:
<ns3:stockDiscrepancy>
<ns5:resultingList>
<ns5:stockEntry>
<ns4:uuid>5306a3cb-4286-4ea6-9cb6-f9c331af1fc5</ns4:uuid>
<ns5:batch>
<ns5:volume>510.000000</ns5:volume>
</ns5:batch>
</ns5:stockEntry>
</ns5:resultingList>
</ns3:stockDiscrepancy>
ответ:
<errors>
<error code="MERC24601">При добавлении или изменении вырабатываемой продукции необходимо указывать номенклатуру из справочника.</error>
<error code="MERC24081">Скоропортящаяся продукция или нет для записи складского журнала обязательно для заполнения.</error>
<error code="MERC24082">Дата выработки для продукции обязательна для заполнения.</error>
<error code="MERC24083">Дата окончания срока годности продукции обязательна для заполнения.</error>
<error code="MERC24094">Единицы измерения для записи складского журнала обязательны для заполнения.</error>
<error code="MERC24095">Тип продукции для записи складского журнала обязателен для заполнения.</error>
<error code="MERC24096">Продукция для записи складского журнала обязательна для заполнения.</error>
<error code="MERC24097">Вид продукции для записи складского журнала обязателен для заполнения.</error>
<error code="MERC24139">В запросе отсутствуют сведения о наименовании продукции.</error>
</errors>

1. Зная UUID можно однозначно идентифицировать запись журнала продукции => для чего необходимо заполнять указанные поля в списке ошибок?
2. Да, есть 2 варианта решения
- собирать все данные из учетной системы, предполагая, что данные актуальные, а если неактуальные, то тянуть по методу обновления записи журнала продукции по GUID
- не обращать внимание на данные в учетной системе и сразу тянуть данные по GUID
В конечном итоге, конечно работает, но если вдруг увеличится время обработки запросов, а на практике такое не редкость, то на оформление инвентаризации уйдет куча времени, если обновлять все записи журнала продукции на момент формирования инвентаризации.

PS: совокупность указанных параметров нужна больше для создания новой записи журнала продукции, может быть стоит разделить обработку транзакции по типу операции?: изменение/удаление и создание. Где проводить соответствующую обработку параметров.

Yoreg07 wrote:Добрый день. Собственно, сам вопрос в заголовке темы. Позволит ли API 2.1 сделать такое? Кто пробовал?

Технически может и пройдет. Но с логической точки зрения это неверно. Для этого есть процедура аннулирования выписанного ВСД(тот кто выписывал его).

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

oleg-x wrote:Все, не правильно прочитал, оператор указал что произвели меньше фактического. Тогда действительно делается отчет производства без списания.
Это будет являться ошибкой (критичной или нет пока неизвестно) и по результатам этих ошибок будут блокировать УЛ. Но пока при мониторинге анализируют не отдельные отчеты, а в целом по предприятию.
То есть будут смотреть сколько списали сырья и сколько получили продукции. И если есть аномалия, то будут проводить проверки.
Аномалии я так понимаю вычисляются методом статистики.
По поводу недоработанности мерка абсолютно согласен и могли бы сначала доработать на той продукции, которая была всегда подконтрольна, а не добавлять всю молочку. Но имеем, что имеем.

А какая молочка(или продукция) не подконтрольная?
Если счетчик на сайте РСХН "протикал" время на всю молочку, ожидалось, что стало все подконтрольно.

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

Могут ли самозанятые граждане использовать систему Меркурий?
По сути самозанятые - это физ.лицо, а физ. лицо не может быть ХС в системе Меркурий(по моему где-то было обсуждение по этому поводу).

http://www.consultant.ru/law/hotdocs/55771.html/

Самозанятые в праве вести некую деятельность и платят соответствующие налоги. Деятельность поднадзорная в Меркурии будет для таких лиц недоступна?

oleg-x wrote:Если списали сырья больше, то это ошибка оператора. Делаете инвентаризацию на сырье с указанием, что ошибочно добавили больше в такой то производственный сертификат.
Меркурий не идеальна, но пока нет четкого НД, каждый может творить что угодно и каждый будет отстаивать свою точку зрения в суде.
Сделать обязательным указание сырья нельзя, так как есть продукция которая производится из не подконтрольной продукции.

Инвентаризация сырья, кстати, тоже будет неправильно. Если сырье еще не успели списать в 0, то да инвентаризация с изменением отработает верно. А если уже успели списать в 0, то ее уже не получится увеличить => приходим к моему примеру, то есть создаем сырье, продукцию грубо говоря из воздуха или даже просто из воды, а далее производим кефир на воде => фальсификат)))

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

oleg-x wrote:Если списали сырья больше, то это ошибка оператора. Делаете инвентаризацию на сырье с указанием, что ошибочно добавили больше в такой то производственный сертификат.
Меркурий не идеальна, но пока нет четкого НД, каждый может творить что угодно и каждый будет отстаивать свою точку зрения в суде.
Сделать обязательным указание сырья нельзя, так как есть продукция которая производится из не подконтрольной продукции.

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

А что за продукция, которая не подконтрольная в Меркурий? Я ошибаюсь, или 1 ноября введен не весь молочный ассортимент? Или речь идет о каком-то пальмовом масле и запрещенных веществах? - интересно)))))
По определению как раз таки Меркурий вроде как и был создан чтобы можно было посмотреть из чего произведен продукт, а тут выясняется что можно добавлять что угодно - смысл тогда всей этой системы?

В указанном примере все просто, есть молоко(сырье) и продукция из этого сырья - нельзя банально оформить правильно инвентаризацию(можно, но она не будет соответствовать законодательству). Если Меркурий неидеальна, а по факту не доработана(признают и сами сотрудники РСХН + думаю даже на этом форуме часть пользователей согласятся со мной): как разработчик интеграционного решения имею представление - почему контролирующие органы не обращают на это внимание? И сюдя по Вашему сообщению можно еще и судиться, но зачем создавать всю эту цепочку событий - непонятно.

Сделать обязательным указание сырья, как раз таки можно. Как-то же решили вопрос с регионализацией: есть продукция и известно каким условиям она должна соответствовать. Так и тут, если есть кефир, то явно что в качестве сырья на каком то этапе производства в любом случае выступает молоко => требовать заполнение сырья. Не будут же производить кефир из кирпича, хотя формально можно и так сделать, что вообще полный абсурд.

PS: Если есть система Меркурий, значит должно быть где-то руководство использования данной системой, иначе это не соответствие вообще ГОСТу разработки ПО. Кто нибудь знает где можно взять это руководство?
Про Ветис.API молчу)))) Там вообще изначально сказали, что есть методы и никакой рекомендации по использованию. Описание методов тоже не всегда соответствует действительности.

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

Даже если обыграть данный пример изощренными методами, то а для чего тогда инвентаризация? Сейчас нельзя изменить журнал продукции с 0 количеством. И нельзя добавить новую запись с привязкой к исходной записи журнала продукции. Разве это сложно реализовать?

Основной вопрос связан именно с указанием сырья. Если такая партия(произведена без сырья) - фасльсификат. Почему проходят такие транзакции? Добавьте сырье обязательным параметром раз по законодательству это так. Или это сделано специально, чтобы ловить организации на этом, наживаться на штрафах и за счет штрафов дорабатывать систему и только потом будет сделано все по уму?

nmzn1 wrote:

kuzmin wrote:Как грамотно оформить указанный пример в системе Меркурий?

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

1. недостающих 9000
2. продукция не просрочена
3. подтянув новое сырье получается, что по факту 9000 произведены из молока поставщика1, а по документам может быть из любого другого - по факту это фальсификат и продавать такую продукцию нельзя, опять таки вся эта прослеживаемость стает неверной.
даже если подтянуть новое сырье то увеличивается сырье на производство 1 единицы продукции. Формально можно будет произвести и по меркурию новую партию, а по факту указанный объем сырья будет лежать на складе и что, его выливать? Если сливать 1л или 2л - не вопрос, а если реально большие объемы?

1. Является ли фальсификатом производство вырабатываемой продукции без указания используемого сырья?

2. При транзакции оформления производственной партии есть возможность указать используемое сырье, а вот при добавлении новой записи журнала продукции через инвентаризацию(вырабатываемая продукция) не указывается сырье.
Россельхознадзор гарантирует, что продукция на прилавках полностью отслеживается на всех этапах. Как же она может отслеживаться, если есть возможность произвести продукцию/провести инвентаризацию(чисто физически нельзя указать) без сырья?

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

В РСХН перевели на вет. врача: вет. врач подтвердил, что данный функционал доступен в Меркурии, но он не соответствует законодательству и посоветовала вообще не использовать данный метод добавления. Сослались вообще, что система Меркурий на текущий момент не доработанная система.

Получается, что есть РСХН(законодательство), система Меркурий (программный продукт), где явно видно, что каждый живет своей жизнью и по факту есть функционал Меркурия, который не соответствует законодательству. То есть грубо говоря, есть функционал, который искусственно создает неправильно сформированные партии, чем и пользуются контролирующие органы.

Практический пример:
Произвели продукцию 10000 штук и списано сырье, а оператор допустил опечатку и внес в Меркурий 1000 => 9000 валяются на складе без учета в Меркурии но со списанным сырьем по всем правилам.
Далее данную партию всю продали => транспортный ВСД => запись журнала продукции имеет кол-во 0.
В конце месяца обнаружили эти 9000(срок годности еще не истек) и встает вопрос, как их занести в Меркурий?:
- в РСХН посоветовали произвести, но произвести нельзя, потому что на них уже было списано сырье, произвести без сырья - не соответствует законодательству
- инвентаризация, да, она тут как раз таки подходит, но нету никакой связи с сырьем которое было списано при производстве, ни с записью журналом продукции. Откорректировать данные исходной записи нет возможности, так как там уже все списано в 0.
Как грамотно оформить указанный пример в системе Меркурий?

Здравствуйте.

1. Когда появится возможность получения справочника упаковок через соответствующий метод Ветис.API, которого почему-то просто не существует?
Да, можно пойти обходным путем и загружать данный справочник через парсинг html страницы(пришлось поступать именно так) http://help.vetrf.ru/wiki/PackingType_v2.0 ведь иного способа получить GUID и UUID упаковок нет.

2. В техподдержке сообщили, что данный справочник основан и соответствует "Классификатор видов груза, упаковки и упаковочных материалов" разработанный ЕЭК. Удалось найти указанный классификатор из метода http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0

Сравнение двух справочников было основано на том, что при загрузке справочника Ветис.API насторожили позиции с одинаковым наименованием(разные коды). И действительно, видимо это норма. Но так же было обнаружено следующее:
a. в справочнике Ветис.API есть позиция, которая отсутствует в справочнике ЕЭК =>
guid: 0e254eeb-d882-425d-85cf-ae68b8e50980
uuid: 32dfdafc-ea6b-4793-8b70-a8858e69ab50
Наименование: Нет сведений
Код: NA
b. в справочнике ЕЭК есть позиция, которая отсутствует в справочнике Ветис.API =>
Наименование: Мешок полиэтиленовый
Код: 44
c. В справочнике ЕЭК есть английское наименование и это спасает в случае одинакового русского наименования. Может быть есть смысл подтянуть английское наименование в справочник Ветис.API?(Не думаю, что кладовщик будет знать все 364 кода на память, и в случае необходимости искать справочник ЕЭК при наличии перед собой аналогичный справочник только от Ветис.API)
d. Не понятно, почему часть позиций в справочнике Ветис.API в наименовании содержит "", чего нет в первоисточнике.

PS: Справочник ЕЭК дает возможность экспорта в файл, который так же легко можно использовать для импорта в любую учетную систему. Если нет желания добавлять метод в Ветис.API, то сделайте хотя бы схожий функционал на сайте.
Конечно, различие одной позиции не влечет за собой ничего серьезного, и в пределах РФ проблем вообще возможно не будет, а вот при импорте и экспорте может возникнуть ситуация, что фактической упаковки просто не будет для выбора в системе.

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

Тестовый контур.
Как верно поступить в таком случае? - запрос списка ВСД. Пример партии во входящем ВСД:
<ns5:batch>
<ns5:productType>5</ns5:productType>
<ns5:product>
<ns4:uuid>31c94ff1-a217-f38d-6005-1aa5ca67e146</ns4:uuid>
<ns4:guid>d34504bb-7a93-e1c8-4859-339eafd97c6c</ns4:guid>
</ns5:product>
<ns5:subProduct>
<ns4:uuid>47751a40-18ac-36c7-0bfb-d9c48b4e1f79</ns4:uuid>
<ns4:guid>8563650a-c1e1-11e8-e641-179e41a60918</ns4:guid>
</ns5:subProduct>
<ns5:productItem>
<ns6:name>йогурт (0403)</ns6:name>
</ns5:productItem>
<ns5:volume>13.0</ns5:volume>
<ns5:unit>
<ns4:uuid>069792f0-053d-11e1-99b4-d8d385fbc9e8</ns4:uuid>
<ns4:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</ns4:guid>
</ns5:unit>

В случае, если в справочнике учетной системы еще нет таких идентификаторов, приходится запрашивать все отдельно, иначе получается, что имеем только uuid и guid - пользователю системы это ничего не даст.
Аналогично и с другими справочными данными: Отправитель, Получатель, то есть ХС+обслуживаемые предприятия - соответствующие методы. В итоге получается, что только при обработке 1-го нового ВСД от нового поставщика имеем ряд каскадных вызовов методов.

Как быть с актуальностью данных?:
Так как данные справочники хранятся в учетной системе, то с какой периодичностью необходимо их обновлять или можно в исключительных случаях подтягивать актуальные данные непосредственно при получении ВСД?

Как быть с такой продукцией?, - отсутствует UUID:
<ns5:productItem>
<ns6:name>йогурт (0403)</ns6:name>
</ns5:productItem>

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

Здравствуйте.

http://help.vetrf.ru/wiki/GetVetDocumentListOperation_v2.0
В данном методе есть возможность поиска ВСД по интервалу дат(тип xs:dateTime):
<vd:issueDateInterval>
<bs:beginDate>2017-07-07T00:00:00</bs:beginDate>
<bs:endDate>2017-07-25T00:00:00</bs:endDate>
</vd:issueDateInterval>

В самом же ВСД дата имеет тип xs:date, что подтверждается и на практике:
<ns3:getVetDocumentListResponse xsi:type="ns3:GetVetDocumentListResponse" xmlns

si="http://www.w3.org/2001/XMLSchema-instance">
<ns5:vetDocumentList count="15" total="15" offset="0">
<ns5:vetDocument>
<ns4:uuid>*****</ns4:uuid>
<ns5:issueDate>2019-05-14</ns5:issueDate>

При проверке https://t2-mercury.vetrf.ru/pub/operatorui?_action=findVetDocumentFormByUuid&uuid=**** выдается Дата и Время.

Почему разные типы данных как в рамках данного метода, так и в самом ВСД(Ветис.API <> Web сервису Меркурий)?

Здравствуйте.
Аналогичная проблема с ns0, только помимо указанного выше метода(методы Журнала Продукции), проявляется еще и на методе GetVetDocumentByUuidOperation:
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns0:submitApplicationRequest xmlns:ns0="http://api.vetrf.ru/schema/cdm/application/ws-definitions" xmlns:ns2="http://api.vetrf.ru/schema/cdm/application">
<ns0:apiKey>*****</ns0:apiKey>
<ns2:application xmlns:ns1="http://api.vetrf.ru/schema/cdm/base" xmlns:ns6="http://api.vetrf.ru/schema/cdm/base/ws-definitions" xmlns:ns5="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
<ns2:serviceId>mercury-g2b.service</ns2:serviceId>
<ns2:issuerId>*****</ns2:issuerId>
<ns2:issueDate>2019-07-05T17:05:38.046+03:00</ns2:issueDate>
<ns2:data>
<ns4:getVetDocumentByUuidRequest xmlns:ns4="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" xmlns:ns3="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<ns4:localTransactionId>*****</ns4:localTransactionId>
<ns4:initiator>
<ns5:login>*****</ns5:login>
</ns4:initiator>
<ns1:uuid>*****</ns1:uuid>
<ns3:enterpriseGuid>*****</ns3:enterpriseGuid>
</ns4:getVetDocumentByUuidRequest>
</ns2:data>
</ns2:application>
</ns0:submitApplicationRequest>
</S:Body>
</S:Envelope>

Ответ:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>*****</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>*****</issuerId>
<issueDate>2019-07-05T17:05:38+03:00</issueDate>
<rcvDate>2019-07-09T11:41:43+03:00</rcvDate>
<prdcRsltDate>2019-07-09T11:41:44+03:00</prdcRsltDate>
<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC29222">Идентификатор ветеринарно-сопроводительного документа (UUID) обязателен для заполнения.</apl:error>
</apl:errors>
</application>
</receiveApplicationResultResponse>
</soap:Body>
</soap:Envelope>

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

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

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

Вопрос с решением ns0 крайне важен, так как общем случае, уверен, что большинство разработчиков не берут на себя ответственность за сам механизм формирования и отправки запроса на сервер - используют необходимые библиотеки предназначенные для этого. В моем случае JAXWS, где значительно упрощается работа с протоколом SOAP.

PS:
Как долго будет обрабатываться инцидент?
Почему бы не поставить в известность техподдержку о существующей проблеме? Чтобы не создавать инцидентов по каждому обращению, а они, я так понимаю, - есть.
Конечно, есть и положительные моменты, особенно в работающих методах, при чем, как ни странно в них проходит ns0.