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

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

ppa32 wrote:
Дело в том, что это не наша продукция. Соответственно, мы ее менять не можем. При открытии по "изменить" она выглядит так:
https://dropmefiles.com/xBZio

Чуть "Раздвиньте" окно и Вам откроется "Изменить"

а вообще, если уже зашли в редактирование, то просто достаточно "Далее" -> "Готово" и Продукция сама "подтянет" данные из Меркурия.

ppa32 wrote:Добрый день, уважаемые коллеги

1С УТ 11.4. Отправляю запрос на списание товара, возвращается ошибка "MERC24033: Указанное наименование продукции относится к другому виду продукции"

Можете подсказать, что не так?

Изменили принадлежность Продукции Ветис к Группе справочника, т.е в ВЭБе поменяли. Необходимо "прокликать" продукцию в документе (нажать кнопку "Изменить" -> "Далее" -> "Готово").

YaAnna wrote:
Спасибо! пока, так понимаю, какого-то конкретного решения проблемы никто не даст.
А есть еще у нас одна проблема, это отгрузка продукции по записям складского журнала для достижения необходимой прослеживаемости. Был, например, сегодня приход продукции 100кг с датой выработки с датой выработки 05.10.2018, мы ее поставили на приход и ей присвоилась одна запись. Завтра к нам от этой даты выработки приходит еще 100кг, мы также ставим ее на приход, но это уже другая запись. При отгрузке продукции с этой датой выработки в количестве 150кг выходит дефицит, так как в одной записи складского учета всего 100кг. И опять беда...

Нужно оформить "Объединение записей складского журнала ВетИС".

natalismp wrote:Управление Ветеринарными сертификатами. Вот сегодня к примеру из 11 заявок 5- "Успешно обработаны", 6 - отклонены. Какая-то часть остатков 1С синхронизирована с Меркурием, а другая, получается, нет?

Я думаю, что проблема та-же, что и с дублями. Т.е. "строго" оформлять в одного ветеринара (с отключенным регламентным заданием) и последовательно по 1-му документу... Хотя и не фак

что не будет дубля.

Предварительная информация - дублей пока нет!!! УРА!

З.Ы. Программу - не обновляли.

(Зачеркнуто)

Нет, всё в порядке, есть дубли...(правда, очень мало, так, что всё-равно ура!)

sergmerk wrote:

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

К сожалению наш объём не позволяет работать в ВЭБе (не банке). 7-8К ветеринарных свидетельств не один разумный штат не потянет...

christoffelsymbols wrote:

MishaJ wrote:

christoffelsymbols wrote:
Запрос на оформление явно отправлен 2 раза...

Судя по Протоколу со стороны 1С один исходящий, а вот входящих - два:

Вот именно это и подтверждает, что 1с один и тот же запрос отправила 2 раза и получила 2 ответа.

P.s.
Попробуем написать в техподдержку 1с.

Давайте попробуем разобрать пример с точки зрения формальной логики.

Все элементы таблицы принадлежат учетной системе, сортировка по убыванию.

Что видно на картинке? Четко прослеживается пара - запрос (Исходящий)/ответНаЗапрос (Входящий). Судя по колонке "Идентификатор запроса", в этом поле можно однозначно определить какой идентификатор соответствует своей паре. В этой картине есть элемент, у которого значение поля "Идентификатор запроса" - уникален для всего журнала (я проверял)

, т.е. "Запроса" с таким идентификатором - нет, есть только ответ, отсюда можно сделать предположение, что запрос на этот ответ был порождён не в недрах нашей учётной системы. Всё это по моему скромному мнению. И ещё раз хочу повторить то, что дубли появились только после 24.10, база была обновлена - 18.10.

christoffelsymbols wrote:
Запрос на оформление явно отправлен 2 раза...

Судя по Протоколу со стороны 1С один исходящий, а вот входящих - два:

christoffelsymbols wrote:
Запрос на оформление явно отправлен 2 раза.
У вас регл. задание включено?

Отредактируйте, пожалуйста, Ваш ответ, или уберите цитирование.

christoffelsymbols wrote:
У вас регл. задание включено?

Да. Раз в час.

До 24.10 дублей не было.

christoffelsymbols wrote:
У вас при оформлении исходящих всд создаются дубли?
В протоколе обмена что видите?

Логи:
1)

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:apl="http://api.vetrf.ru/schema/cdm/application"
    xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
    xmlns:bs="http://api.vetrf.ru/schema/cdm/base"
    xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"
    xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
    <apldef:submitApplicationRequest>
      <apldef:apiKey>911</apldef:apiKey>
      <apl:application>
        <apl:serviceId>mercury-g2b.service:2.1</apl:serviceId>
        <apl:issuerId>911</apl:issuerId>
        <apl:issueDate>2018-10-26T01:40:50+03:00</apl:issueDate>
        <apl:data>
          <merc:prepareOutgoingConsignmentRequest>
            <merc:localTransactionId>fdeb2975-5c6d-4cb8-bd24-7f3ed3b114b9</merc:localTransactionId>
            <merc:initiator>
              <vd:login>___</vd:login>
            </merc:initiator>
            <merc:delivery>
              <vd:deliveryDate>2018-10-25T21:16:06+03:00</vd:deliveryDate>
              <vd:consignor>
                <dt:businessEntity>
                  <bs:guid>fccfd991-218a-11e2-a69b-b499babae7ea</bs:guid>
                </dt:businessEntity>
                <dt:enterprise>
                  <bs:guid>79c37fb4-28d5-42d9-a6b9-0c722e1e00e6</bs:guid>
                </dt:enterprise>
              </vd:consignor>
              <vd:consignee>
                <dt:businessEntity>
                  <bs:guid>89860a37-72bb-4ccb-bca5-17817cf6b754</bs:guid>
                </dt:businessEntity>
                <dt:enterprise>
                  <bs:guid>181a5b9b-a358-4556-a5ae-9885523786a9</bs:guid>
                </dt:enterprise>
              </vd:consignee>
              <vd:consignment id="id1">
                <vd:productType>5</vd:productType>
                <vd:product>
                  <bs:guid>e9fa27c7-c0e0-2f64-308c-c6409de238ae</bs:guid>
                </vd:product>
                <vd:subProduct>
                  <bs:guid>7da301dd-d0d0-4180-5bc4-ce0a4111afcd</bs:guid>
                </vd:subProduct>
                <vd:productItem>
                  <bs:guid>17cab821-5075-468a-ae54-38a9683124c1</bs:guid>
                  <dt:name>Холодец домашний варёный охл., (вак/уп 0,5 кг)</dt:name>
                </vd:productItem>
                <vd:volume>19.834</vd:volume>
                <vd:unit>
                  <bs:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</bs:guid>
                </vd:unit>
                <vd:perishable>false</vd:perishable>
                <vd:lowGradeCargo>false</vd:lowGradeCargo>
                <vd:packageList>
                  <dt:package>
                    <dt:level>6</dt:level>
                    <dt:packingType>
                      <dt:globalID>BX</dt:globalID>
                    </dt:packingType>
                    <dt:productMarks class="UNDEFINED">ООО «Мясокомбинат Бобровский», Овальное клеймо 15-02-01</dt:productMarks>
                  </dt:package>
                </vd:packageList>
                <vd:sourceStockEntry>
                  <bs:guid>6dc88716-2db1-465f-8df0-752561b3973b</bs:guid>
                </vd:sourceStockEntry>
              </vd:consignment>
              <vd:broker/>
              <vd:transportInfo>
                <vd:transportType>1</vd:transportType>
                <vd:transportNumber>
                  <vd:vehicleNumber>Газель</vd:vehicleNumber>
                </vd:transportNumber>
              </vd:transportInfo>
              <vd:transportStorageType>CHILLED</vd:transportStorageType>
              <vd:accompanyingForms>
                <vd:waybill>
                  <vd:issueNumber>2083056    </vd:issueNumber>
                  <vd:issueDate>2018-10-26</vd:issueDate>
                  <vd:type>5</vd:type>
                </vd:waybill>
                <vd:vetCertificate for="id1">
                  <vd:authentication>
                    <vd:purpose>
                      <bs:guid>0778b8cb-f49d-4ed9-88b9-5f70af00a211</bs:guid>
                    </vd:purpose>
                    <vd:cargoInspected>true</vd:cargoInspected>
                    <vd:cargoExpertized>VSERAW</vd:cargoExpertized>
                    <vd:locationProsperity>Местность благополучна по заразным болезням животных</vd:locationProsperity>
                  </vd:authentication>
                </vd:vetCertificate>
              </vd:accompanyingForms>
            </merc:delivery>
          </merc:prepareOutgoingConsignmentRequest>
        </apl:data>
      </apl:application>
    </apldef:submitApplicationRequest>
  </soapenv:Body>
</soapenv:Envelope>

2)

3)

Вынужден констатировать, Меркурий побеждает с разгромным счетом. Дубли как создавались, так и создаются не зависимо от настроек 1С. Браво!

Shadasp wrote:

MishaJ wrote:У нас "Ад и Израиль" по дублям ветеринарок... С 24.10 началось массовое задвоение. Обращение в тех. поддержку оставило тяжёлое впечатление. Нас обвиняют в ошибках запросов нашей Учетной системы. Доводы, что 24.10 мы свою программу не меняли - не слышат. По факту, обновление прошло 18.10... В общем, даже не знаю, как пояснить, что проблема не с нашей стороны.

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

Если у вас есть такой механизм конечно.

Убрал чекбокс здесь, посмотрим, повлияет ли...

У нас "Ад и Израиль" по дублям ветеринарок... С 24.10 началось массовое задвоение. Обращение в тех. поддержку оставило тяжёлое впечатление. Нас обвиняют в ошибках запросов нашей Учетной системы. Доводы, что 24.10 мы свою программу не меняли - не слышат. По факту, обновление прошло 18.10... В общем, даже не знаю, как пояснить, что проблема не с нашей стороны.