Работа с Меркурием

finsoftrz

Нет, речь именно про 4 уровень. Третий всегда было обязательно указывать. Я про 2019 год неверно написал. Где-то писали, засело в голове. По факту сейчас разрешают и с 3, и с 4. Постепенно, по мере "готовности рынка", перейдут к обязательности 4 уровня.

http://yandex.ru/clck/jsredir?bu=5nq0&f ... ime=268685

Игорь Столяров

finsoftrz писал(а): ↑07 Август 2019, 15:48Нет, речь именно про 4 уровень.

Читал я интервью этого дядьки с пугалками и угрозами … но ведь речь идёт именно о классификации продукции.
Из-за того, что система росла культурными слоями, тут ещё та терминология классификации:

1 УРОВЕНЬ: ТИП ПРОДУКЦИИ (ProductType)
2 УРОВЕНЬ: ПРОДУКЦИЯ (Product)
3 УРОВЕНЬ: ВИД ПРОДУКЦИИ (SubProduct)
4 УРОВЕНЬ: ПРОДУКТ (ProductItem = GUID / NAME / GTIN)

И судя по различиям в версиях API добавили сейчас они именно уточняющий SubProduct (который называют 4-тым уровнем классификации), а комплект ProductItem как был, так и остался.

finsoftrz

SubProduct - это 3 уровень. Во всяком случае, он уже давно, мы год, наверно, уже гасим. ProductItem - это 4 уровень. В нем guid может быть, а может и не быть. Присваивать его должны сами предприятия, производящие продукцию. В отличии от 1-3, которые стандартные. Я так понимаю.

Игорь Столяров

finsoftrz писал(а): ↑07 Август 2019, 17:05мы год, наверно, уже гасим

Ну так, а ProductItem был ещё до Адама … Четыре уровня иерархии продукции в Меркурии стало в версии 2.0 - где-то 2-3 года назад.

Игорь Столяров

Есть ещё один интересный вопрос по фишкам и прибамбасам для работы с Меркурий …

Как-то все делают получение уведомлений о наличии новых событий и в частности входящих ВСД.
Судя по всему, получают эту информацию из системы быстро, а значит без асинхронного запроса ...
Не сталкивались с таким ? P/S: В Google сразу не посылать - был я там.

finsoftrz

Я не сталкивался. А какой в этом практический смысл? Гасят все равно при фактическом приходе товара.
Сегодня послали несколько всд реальным поставщикам из учетной системы. По задуманной технологической цепочки, на основании отгрузочных накладных. Завтра повезут товар, поставщики будут гасить. Привязку партий пока вручную корректируют, так как на остатках висят старые пробные партии, которые надо зачистить инвентаризацией. Пока сомневаюсь, есть ли смысл ее реализовывать через апи.

Игорь Столяров

finsoftrz писал(а): ↑08 Август 2019, 21:49Я не сталкивался. А какой в этом практический смысл?

Ну я вот смотрю по описанию 1C и Контура. Запускается программа и сразу написано "У Вас 10 новых входящих ВСД".
Оператору понятно, что нужно открыть журнал входящих ВСД и выполнить обмен. Необязательная фишка - но полезная.

finsoftrz

Если почитать описание настройки Ветис в 1С, то там можно увидеть расписание, по которому программа автоматически обменивается с сервером. То есть они просто пинают сервер, скажем, раз в час, а затем, если есть непогашенные всд, выдают сообщение подписанным пользователям.
Как по мне, пользы практически никакой, а нагрузка на сервера Ветис возрастает, если все организации будут их таким образом пинать. Где-то читал, что у Ветиса есть защита от частых обращений. Если с какого-то ip его слишком часто начинают дергать, то он на время блокирует такие ip адреса.
В общем, я такое у себя делать вряд ли буду.

Игорь Столяров

finsoftrz писал(а): ↑09 Август 2019, 10:51В общем, я такое у себя делать вряд ли буду.

- "А Ленин за какую партию ?" спросил Чапаев
- "За большевиков !" ответил Фурманов
- "Тогда и я за большевиков" вздохнул Чапаев.

Игорь Столяров писал(а): ↑09 Август 2019, 11:05"Тогда и я за большевиков" вздохнул Чапаев.

Он плохо кончил.

kreator

И я влезу. Дёргать Ветисовский сервер должен сервер конкретной конторы, а не каждая рабочая станция. Их сервер от этого не развалится.

Игорь Столяров

kreator писал(а): ↑09 Август 2019, 13:35Их сервер от этого не развалится.

Я всё-таки подозреваю, что очевидно решение с дёрганьем сервера - не совсем верное.
Дело в том, что отправив запрос на ВСД - мы получаем в ответ ПАКЕТ с ВСД.
А сотня-другая добре ВСД - это может быть XML файл размером под 10-15 MByte.
Вряд ли такие операции кто-то додумался поставить на циклический опрос.

finsoftrz

kreator писал(а): ↑09 Август 2019, 13:35И я влезу. Дёргать Ветисовский сервер должен сервер конкретной конторы, а не каждая рабочая станция. Их сервер от этого не развалится.

Как я понимаю, так оно и есть. Дергает сервер конторы сервер ветиса. Если учетная система в многопользовательском режиме. Но таких контор дофига по стране. И Игорь правильно написал, что в ответ могут прилетать большие xml файлы. По скрину у 1с я заметил, что по умолчанию предлагается делать опрос раз в час. Но можно и раз в день, например.

finsoftrz

Сейчас удаленно наблюдал за работой с Ветис из своей учетной системы. В общем, автоматическое привязывание партий, видимо, не получается. То есть, получается, но приходится править. Так как на складе при отгрузке определяют по сроку выпуска, и отдают оператору.
А один сыр вообще потеряли... Успели отгрузить вчера, записали дату выпуска и срок годности, а в ветисе на остатках такого нет. И откуда взялось, непонятно. Решили звонить водителю, чтобы вытащил из коробки и не отдавал покупателю. Типа недовоз.

Игорь Столяров

finsoftrz писал(а): ↑09 Август 2019, 14:10В общем, автоматическое привязывание партий, видимо, не получается.

Тут скорее вопрос в том, что задача не имеет чёткого и простого алгоритмического решения.
Пример. Товар "Труп куры в полиэтилене", 40 шт. в коробе. Клиент купил короб.
В складском журнале, в порядке очерёдности (FIFO или просрочка вперёд !) предлагаются сначала какие-то штучные остатки.
Бог с ними с остатками - можно свалить в один короб и заклеить скотчем - но ещё клиент получит к нему пяток ВСД.
Никто так не делает, отдаётся конечно целый короб "вне очереди", с общими сроками и одним ВСД ...