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

oleg-x wrote:1) Прежде чем кого то обвинять, разберитесь, почему это произошло.
2) Надо следить за обновлениями и ситуацией (по край не мере на данном этапе).
Ситуация с GTIN-ами такова, ни кто не добавлял нового функционала, он всегда был. Баг, потому что не просто взяли и добавили проверку, а она была с момента ввода. Но только при гашение, а вот при отправке не было.
И получалась такая ситуация. Поставщик отправил, а клиент не может погасить, так как GTIN не корректный.
Во второй половине июля, было сборище с разработчиками и представителями сетей и об это проблеме они говорили. Пообещали исправить и вот спустя месяц все поправили.

И немного из справки:
Тип для представления Global Trade Identification Number всех форматов: GTIN-8, GTIN-12, GTIN-13, GTIN-14
Наследуется от xs:string. Ограничение по длине: минимум 8 символов, максимум 14 символов.

Это к тому, что не стоит использовать реквизиты не по назначению, ведь в любой момент они могут быть исправлены как "баг" и получится ситуация как у Вас.

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

тут дело даже не в формате этого GTIN, формирование доработали под текущие условия Меркурия. (с расчетом контрольной суммы)
Проблема в том что с сетями согласован определенный GTIN и если мы указываем другой в эВСД соотв могут быть проблемы в приемке товара.
Вот это основная проблема!
Все движение товаров где указан не соотв GTIN тоже в ступоре на данный момент, т.е. необходимы его изменения.

trilogia wrote:Меркурий работает отлично, просто замечательно.
Остатки продукции только по вебке вижу, через апи ничего нет.
2 недели пытаюсь уже пересчитать складской журнал. APLM0012 задолбал уже.

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

Ониж все умные там, лучше всех знают как лучше вам и нам работать.

Дорогие разработчики, у вас все в порядке с головой?

Ребята настолько круты что теперь проверяют наличие корректного контрольного символа!
Кто вас просил? Верните все обратно пока вас на вилы не подняли.
Без предупреждения, без какой либо информации взяли и за..ячили, идиоты!

На весовой товар по требованиям "сетей" в GTIN контрольный символ не указывается, да и вообще какого?
Вы можете лучше ничего не делать чем делать такую херню?

Как с оной формулировкой оформить через api? Возможно ли это вообще? (Транспортный эВСД)
или я туплю и это необходимо в производственном серте как то указывать?

nmzn1 wrote:

sup wrote:Да понятно, получается единственный способ корректировать кол-во по товарам это добавить через инвентаризацию соотв продукт.

или добавить или изменть

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

Вопрос в том как правильно исправить ошибку в производственной транзакции, допустим случайно произвели +1т продукции. Реально ее нет но изменить это кол-во можно только после завершения производства и ...
Как то не совсем правильно.

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

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

Думаю что сами осматривает и соотв отвечаете за достоверность сведений.

Опыт ЕГАИС смыли в унитаз видимо. Ошибки все теже.

Своей слабой реализацией они добились того что нагрузка на базу идет паразитная (без конечного результат), которой могло бы и не быть.
Я гарантирую что если я буду делать 1 запрос в день у меня он не отработает, даже 2 запроса в день, где балансер в этом случае находится?
Прально нигде ибо его нет.
А то что мы во всем виноваты это конечно, у них 20 кратный запас прочности был а в итоге и в 2 раза не смогли увеличить поток документов.

Так оно и есть, не зависимо ни от чего оно либо работает либо нет.

TWAIN wrote:Не было такого. Там другой смысл был. Рабочая рекомендация была и есть одна, сканировать на входе qr код и по нему запрашивать. А там говорили что списки надо запрашивать реже. Окна запрашивать последовательно, между запросами паузы.

Реже не реже, запрашиваю пока не получу ответа т.к. первые 10 запросов а то и более могут с ошибкой вывалить сразу и это после простоя 3х-8и часового.
Окна так и так последовательно, паузы есть но это не влияет особо т.к. отлупы получаешь спонтанно.

Предложить можно только сдвигать период на основе уже полученных данных. (наложением периодов)