Отрицательные килограммы на стоке

Добрый день!
В пятницу обнаружили проблему, у некоторых партий через веб-интерфейс отображаются отрицательные остатки. Начал разбираться, взял одну из записей складского журнала и прошелся по ней. Обнаружил, что в двух случаях оформления транспортных ЭВСД количество коробок не менялось. В итоге:
1) количество коробок неверное как при запросе стока через API, так и в веб-интерфейсе
2) количество штук верное везде
3) объем продукции через api верный, через web-отрицательный
При этом, если идти по порядку по всем ВСД, оформленным из этой партии, они все корректные. Нет таких эвсд, где при оформлении указано неверное количество коробок.

С утра написал в техподдержку, но ответа пока нет.
Кто-нибудь сталкивался с этим? В чем причина такого явления? Как предотвратить и как исправить?

В общем, понятно, что из стока иногда не списываются коробки. То есть, в ЭВСД количество штук и коробок верное. После оформления, сток уменьшается на количество оформленных штук, а количество коробок может остаться прежним.
Может, я что-то упустил и в ноябре появились какие-то дополнительные требования?
Где ошибка в описании упаковки при оформлении? Если ошибки нет, почему штуки списываются, а коробки нет?

<vd:consignment id="id2">
<vd:productItem>
<bs:guid>46898242-f479-4ffd-9857-de56e1deb223</bs:guid>
<dt:globalID>3838975566811</dt:globalID>
<dt:name>Паштет новый дизайн "Argeta" Junior куриный 95 г.</dt:name>
<dt:code/>
</vd:productItem>
<vd:volume>51.300</vd:volume>
<vd:unit>
<bs:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</bs:guid>
</vd:unit>
<vd:packageList>
<dt:package>
<dt:level>2</dt:level>
<dt:packingType>
<bs:guid>fedf422e-053c-11e1-99b4-d8d385fbc9e8</bs:guid>
</dt:packingType>
<dt:quantity>540</dt:quantity>
<dt:productMarks class="EAN13">3838975566811</dt:productMarks>
</dt:package>
<dt:package>
<dt:level>4</dt:level>
<dt:packingType>
<bs:guid>fedf4328-053c-11e1-99b4-d8d385fbc9e8</bs:guid>
</dt:packingType>
<dt:quantity>45</dt:quantity>
<dt:productMarks class="EAN13">3838471028264</dt:productMarks>
<dt:productMarks class="EAN128">(01)3838471028264(11)190822(10)220822</dt:productMarks>
</dt:package>
</vd:packageList>
<vd:sourceStockEntry>
<bs:guid>c9678fa9-9377-425a-82e1-3d9dbad519d1</bs:guid>
</vd:sourceStockEntry>

У вас какая версия ветис.API?

Подключаемся к https://api.vetrf.ru/platform/services/2.1/ApplicationManagementService
В запросе передаём <apl:serviceId>mercury-g2b.service:2.0</apl:serviceId>

strider944 wrote:Подключаемся к https://api.vetrf.ru/platform/services/2.1/ApplicationManagementService
В запросе передаём <apl:serviceId>mercury-g2b.service:2.0</apl:serviceId>

В версии 2.0 и выше не обязательного учёта и списания упаковки, можете задавать любые значения или можете вообще не указывать этот раздел, если его не требует получатель.

Ситуация такая - покупатели требуют указывать эти уровни, мы их указываем.
После оформления транспортного ЭВСД коробки могут не пересчитаться - так и должно быть? До ноября списывалось столько, сколько указано при оформлении.

Или как лучше - вести учет на стоке только в килограммах, а при оформлении указывать штуки и упаковки?

strider944 wrote:Ситуация такая - покупатели требуют указывать эти уровни, мы их указываем.
После оформления транспортного ЭВСД коробки могут не пересчитаться - так и должно быть? До ноября списывалось столько, сколько указано при оформлении.

Может быть в вашей программе был учёт и списание, а не в Меркурии?
У нас не ведётся учёт упаковки, при отправке можно задать любые значения. Надо теперь проверять есть ли автоматическое списание в Меркурии))

strider944 wrote:Или как лучше - вести учет на стоке только в килограммах, а при оформлении указывать штуки и упаковки?

А Меркурии точно идёт списание объёма(volume) при отправке, а вот списание упаковки надо проверять теперь.

Может быть в вашей программе был учёт и списание, а не в Меркурии?

Что имелось в виду? Что вот это не учёт в Меркурии? Я через soap ui вручную разбираю ошибки.
Сток до выполнения prepareOutgoingConsignmentRequest

Сток после выполнения запроса

При том, что в запросе явно всё прописано.

Килограммы уменьшились, штуки уменьшились, коробки не уменьшились. Раньше всё работало. Что изменилось, не могу понять.

strider944 wrote:

Может быть в вашей программе был учёт и списание, а не в Меркурии?

Что имелось в виду? Что вот это не учёт в Меркурии? Я через soap ui вручную разбираю ошибки.
Сток до выполнения prepareOutgoingConsignmentRequest
<vd:volume>84.36</vd:volume> <dt:globalID>TN</dt:globalID> <dt:quantity>888</dt:quantity> <dt:globalID>CT</dt:globalID> <dt:quantity>74</dt:quantity>
Сток после выполнения запроса
<vd:volume>33.06</vd:volume> <dt:globalID>TN</dt:globalID> <dt:quantity>348</dt:quantity> <dt:globalID>CT</dt:globalID> <dt:quantity>74</dt:quantity>

При том, что в запросе явно всё прописано.
<vd:volume>51.300</vd:volume> <dt:quantity>540</dt:quantity> <dt:quantity>45</dt:quantity>

Килограммы уменьшились, штуки уменьшились, коробки не уменьшились. Раньше всё работало. Что изменилось, не могу понять.

Не полагайтесь на учёт упаковки в Меркурии, ведите учёт в своей системе. У него и без учёта упаковки глюков больше, чем достаточно.

Если у кого-то будет такая же проблема, вот описание, как она решилась у меня.

В стоке было

А при отправке запроса

Т.е. один нолик потерялся, из-за ошибки в WMS.
Раньше Меркурий на это не обращал внимание. А в какой-то момент начал проверять, из-за этого коробки перестали считаться. Из-за этого "плыл" сток в веб-интерфейсе и при офомрлении транзакции через веб, отображался отрицательный остаток.
Провели инвентаризацию, стали жестко контролировать мастерданные, проблема решена.