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

Уполномоченный ХС wrote:Могу сказать точно, что от первого субъекта к третьему не может быть одно ВСД.
Теперь подробнее. При передачи от первого субъекта ко второму происходит продажа, а значит меняется владелец продукции. Значит ВСД идет от первого владельца ООО Говядина к покупателю Мяспрод, при подписании всех бухгалтерских документов, ООО Мяспрод становится новым владельцем, как по ВСД так и по бухгалтерским документам. Далее Мяспрод выписывает свой бухгалтерский документ на Розницу и СВОЙ ВСД и ни как иначе. Да и посредником Мяспрод не является, он не ТК. А значит должен быть в Меркурии обязательно.
Но тут другое интересно, как не имея холодильника Мяспрод продает Рознице? Как так получается, что машина приехала на офис, ни кто ни чего не проверив отправил ее дальше, а что она там везет, как можно брать на себя такую ответственность.

Вот тут как раз вопрос интересов логистики и нормальной логики и бюрократических проволочек с ВСД. у Мяспрода вполне может быть свой склад на другом конце города, и свой вет врач. Но вопрос что если работать через вет врача Мяспрода, то он просто не видит физически продукции. И при этом он должен погасить ВСД от ООО Говядина и выписать на ООО Розница. При всём при этом ООО Мяспрод часть продукции везет и выгружает на своих складах, а потом уже отгружает своим покупателям (т.е. пригнал 5тонник на склад, загрузился, привез к себе, проверил, поставил на склад со склада развозит в смешке с другой продукцией к покупателям оформляя ВСД. Но часть продукции он может отгружать сетям, более крупными партиями. И ему нет никакого смысла гнать груженную машину на другой конец города, разгружаться, выделяя погрузчики, персонал и места хранения/перегрузки. Естественно проще гнать машину напрямую, т.е. пригнал аля газельку или микрогрузовик, загрузил, увёз сразу покупателю.

Если мы берем трехступенчатую схему Выписал Погасил Выписал, то получается что в случае несоответствия продукции при приемке у ООО "Розница" данным указанным в ВСД (ошибку допустили), аннулировать можно будет только ВСД с Мяспрода на Розницу. И таким образом у Мяспрода зависает ошибочная партия, а у ООО Говядина висит "пересорт" до тех пор пока не будет выполнен возврат партии от ООО Мяспрод и при этом Мяспрод должен будет именно выписывать ручками этот возврат как "транспортную партию" и эта же партия "пересорта" встанет на приход как новая позиция в журнале продукции.

Второй момент в этой схеме, это работа вет врача Мяспрода. Т.е. по факту это выглядить будет так: Мяспрод дает заявку дайте стейки 500 кг. Мяспрод понятия не имеет с какими номерами заводов, с какими сроками или маркировкой ООО Говядина загрузит ей продукции, т.е. у ООО Говядины свой складской учет, то что ближе было на момент приезда машины, то и загружает. Мяспрод понятия не имеет какой номер товарной накладной будет выписана от ООО Говядина, т.к. документы оформляются после загрузки машины. В бухгалтерских документах никто до маркировки с GTINами и т.п. разбивать не будет. Машина приехала на склад, загрузилась, Вет врач ООО "Говядина" выписал ВСД. Допустим менеджер звонит Мяспроду, сообщает по каким номерам всд прошла отгрузка. Дальше менеджер гасит ВСД. Оформляет в вэбе заявки на ВСД и звонит вет врачу "Бросай всё, утверди срочно, у меня машина у поставщика стоит", а если там интеграция то "Бросай всё, срочно выписывай такую то продукцию". И не факт что не получит ответ "В очередь уважаемый". А тем временем машина будет стоять и никуда не ехать.

Соловьёв Станислав wrote:
Так это мультимодальная перевозка. ООО Говядина указывает получателем ООО Розница с пунктом перегрузки ООО Мяспрод.

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

Соловьёв Станислав wrote:
Бухгалтерские документы ООО Говядина выписывает на ООО Розница и соответственно их и указывает в ВСД.

С какого перепуга? у ООО Говядина нет никаких договорных отношений с ООО Розница на поставку продукции. Они не ведут меж собой взаиморасчеты и у них нет никаких обязательств друг перед другом. у ООО Розница договор с ООО Мяспрод, который ей в рамках поставки может еще кучу продукции поставлять включая трусы и колготки, со своими условиями и т.д. У ООО Говядина контракт на поставку определенного объема продукции для ООО Мяспрод в течении установленного периода с самовывозом.

Соловьёв Станислав wrote:Указание номера машины от ООО Мяспрод, при гашении, пришедшей на ООО Розница, зона ответственности принимающей стороны.

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

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

Соловьёв Станислав wrote:
непроизводители мне предоставляют данные от производителя. и да гуиды сходятся. и я бы не стал оценивать работу системы по работе в тестовой среде. у меня в тесте, то же чёрт ногу сломит. насоздавали кто во что горазд. В боевом всё нормально.

ОК. В боевой тестить не могу, ибо она боевая. А вот в тестовой такую особенность получила. Оприходовала я партию через ВЭБ и взяла я забитую ранее позицию из справочника "Наименование продукции" без GTINа. Получаю я через АПИ партии, разворачиваю результат по созданной записи. Вижу ProductItem, только инфа не полная внутри, по производителю нет инфы, по владельцу. Делаю запрос к шлюзу GetProductItemByGuid, а он мне в ответ ошибку, "GTIN Не соответствует фасету максимальной длинны = 8". Т.е. хочешь нормальной работы через шлюз, тогда бери указывай и GTIN в обязаловку.

Непроизвоидтели выгружаются по справочнику "Наименования продукции" и у вас все ГУИДы сходятся?
Т.к. я увидев подобный список не могу идентифицировать какой гуид я сейчас выбрала и я ли вносила этот элемент и предоставила сети или же его параллельно занес другой оптовик или сам производитель где и гуид естественно не совпадет с тем что был отдан мною сети. Я даже не могу понять при подборе кто производитель этой продукции в справочнике наименования. Более того, если набрать в тестовой базе в качестве наименования Свинина, и полистать список до конца, то там даже сортировки нет, т.е. дубли разбросаны (2 позиции "Свинина" в середине общего списка, 1 позиция "Свинина" в конце списка). И даже после выбора из списка не видна эта информация.

Соловьёв Станислав wrote:
Наша сеть запрашивает только GUID-ы номенклатуры.

А смысл? Когда по ним все равно практически невозможно отгрузиться через вэб. Это игра в угадайку.

Должен ли ХС заполнять справочник Наименования продукции со всеми GTIN и т.п. если он не является производителем продукции, а просто оптовик?
ХС работает через ВЭб интерфейс. В тестовой попробовал заполнить через ВЭБ пару позиций, как итог найти нужную в списке не может, т.к. при оформлении транзакции на отгрузку и выборе Наименования по нужной партии он получает огромнейший список номенклатуры которой у него в справочнике нет. А ту что есть нельзя никак идентифицировать при подборе (т.е. наименование он должен всё равно вбивать вручную и при этом забив "баранина охлажденная" получит кучу записей и не понять кто там производитель, какой у нее GTIN и какой у нее ГУИД).
Фактически требования сетей "Предоставьте список наименований с гуидами и GTINами" и "Отгружать продукцию в соответствии с предоставленным списком" на деле абсолютно не выполнимы при работе через Вэб.
Про трудоёмкость у оптовиков внесения всей этой детализации что дана в справочнике "Наименование продукции", вообще молчу. Так же в вэбе отсутствует возможность удаления ошибочно внесенной записи или дубля в справочнике Наименований продукции. (Смотрим интерфейс ГВЭ)
Идентифицировать фирму производителя опираясь только на маркировку товара, тоже по факту нереально, т.к. это подбор из справочника ХС где указан ИНН. А его попросту нет на большей части маркировки. Т.е. это по каждой продукции нужно искать обзванивая производителей или раскапывая данные через налоговые реестры и тд и так по каждому SKU.

Mak_VET wrote:еще один момент мне не понятен:
если сегодня уже известен номер ТТН, почему его не сделать сегодняшним числом, а отгружать завтра или хоть всю неделю?

Потому-что в нормальных учетных системах на этих датах еще и завязаны взаиморасчеты контрагентов и сроки исполнения заказов. Со всякими стоп-отгрузками при просрочке платежей, штрафами за недопоставки в установленные сроки, маршрутными листами для водителей и т.д. и т.п. Да и контроль остатков на складе тоже на этом завязан. Товар по факту на складе лежит, а по базе его уже нет, от воруй не хочу. Доводилось в свое время делать дописки из-за несоответсвия дат в связи с разницей часовых поясов, когда в момент выписки в системе менялась дата на Московскую (пока разрабы не сделали указание 2х дат со временем на ВСД, местное + московское), всё это в момент отправки ВСД через АПИ. Но и то клиент тогда пожертвовал вопросом оперативного контроля дебиторки, плюс допил неслабый был под формирования маршрутных листов для водителей не по дате документа, а по отдельному реквизиту. И еще много всяких вещей подправить пришлось из-за "Мы не примем ваш товар, у вас дата ВСД раньше, чем дата накладной".

UP
Ребят, кто-нибудь скиньте ГУИД Наименования продукции (ProdactItem) из рабочего шлюза. Проверить на сколько в рабочем отрабатывает getProductByGuid

nselezneva wrote:

El_Djo wrote:А поподробнее про маркировки и 4 уровня упаковки продукции можно сослаться (как на сами требования так и сами регламенты?).

Добрый день.
У меня такой же вопрос, можно подробнее о требованиях? Зачем это указывать в ВСД?
Где о них можно прочитать?

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

Затем чтобы детализация была, что за продукция. Свинина мороженная "что?" шея, лопатка, щека и т.д. 2й момент, не особо приятный для поставщиков, чтобы сеть одним кликом мышки могла быстро загрузить данные о поступлении в свою учетную систему. Если раньше просто настраивался функционал выгрузки накладных из учетной системы поставщика, отдельные обработочки писались под каждую сеть, были каталоги сопоставления этой продукции в системе. То теперь загрузки на уровне накладных недостаточно некоторым, еще и на уровне меркурия все эти выгрузки допиливать и разруливать.

anig99 wrote:
Одно дело маркировка под 2.0, другое обязательная передача упаковки в ВСД + 4 уровень продукции.

И это еще цветочки, по сравнению с тем, что озвучиваются определенные требования по укладке товара на палеты. С учетом подгонки наименований продукции под каждую сеть и формирования партий и этих самых единиц под каждую сеть. А иначе нет приема, возвраты груза, постановка в конец очереди, плата за переклейку штрих-кодов и т.п. То что партия для последующих отгрузок формируется не всегда отправителем, а попадает ХСу от другого поставщика путем гашения ЭВСД и что нет в Меркурии функционала разбивки партии или выписки этой партии под произвольным наименованием в процессе отгрузки, никто из вопрошающих не учитывает. Иногда слушаешь всю эту ахинею с "А мы хотим так" и понимаешь, что они Меркурий даже не открывали, и вообще представления не имеют как там все работает и зачем.
Один вопрос напрашивается, а как же сети жили раньше, когда товар приходил по бумажным ВСД в виде "братских могил". Ведь ничего, нормально принимали. А тут перешли на электронные и на те, не примем, перемаркировывайте все производители свои старые складские запасы и не важно 10 у вас палетомест или тысячи. ИМХО рано стали все эти приблуды под сети делать, тем более зачастую это конечное звено товародвижения. Если со всей этой перемаркировкой производитель еще как-то может решить вопрос, то у оптовиков подстройка под требования каждой сети это огромная головная боль для склада и вет. врачей. Не допиливали бы под все эти приблуды с GTINами, глядишь и запустились бы нормально. Лучше бы решили вопросы производственников и оптовиков и допилили для них весь необходимый функционал. Да работа через API с заявками на ВСД. А потом глядишь и хотелками сетей можно было заняться. А тут всё задом на перед. Хотели как лучше, а получилось... что получилось.
А запускаться ИМХО надо уже начинать сейчас, будет отсрочка или нет, как минимум приводить в порядок весь учет и сопоставлять справочники, т.к. в процессе запуска много веселых вещей вылазить начинает, на устранение которых можно 2мя месяцами не обойтись. Как минимум пару ЭВСД хотя-бы через вэб пооформлять, и провести аудит учетной системы и бизнес-процессов организации, чтобы выявить узкие места и успеть навести порядок.

мы немного отошли от темы товарищи. А кто-нибудь может мне кинуть ГУИД ProdactItem из рабочего шлюза. Проверить на сколько в рабочем отрабатывает getProductByGuid

Владимир Игнатов wrote:
Миллионы элементов - да, на лету - нет. Глядя на "скорость" тестового сервера могу только повторить за Крыловым: "рожденный ползать - летать не может". Можно иногда урезать базу, выкидывая не активные записи, древнее какого-то срока.

Периодическое пополнение мне не понятно. Как? Спросил у Меркурия "по текущей потребности", получил сейчас актуальные данные. Дальше что? Хранить их? И если снова потребуются - что?
1. Брать из базы? А если за это время изменились?
2. Переспрашивать заново? Тогда в чем периодическое пополнение?
3. Иногда переспрашивать всех, кто уже накоплен как "часто используемые". И использовать данные этой актуализации. Да, возможно. При увеличении базы своих контрагентов может стать менее выгодно (по времени), чем получать изменения. Более того, все, кто к SQL-серверу за чем-нибудь обращались, знают, что 500 запросов по 1 строке (вариант переопроса для актуализации своих накопленных) будут работать куда медленнее, чем 1 запрос на 500 строк (вариант получения изменений с предыдущего такого же запроса).

Сомнительная затея. Вопрос на сколько вы в своей оптимизации учли что вам каждый раз выборки придется строить по всем этим миллионам, чтобы сформировать 1ВСД или подтянуть нужную ссылку производителя. Но опять же вопрос на чем вы работаете. Прямые у вас запросы к скулю или это запросы из 1С и ей подобных. Хозяин барин. Как на продакшене эту схемку будите запускать, маякните хоть, а то даже интересно стало.

Владимир Игнатов wrote:
Да, именно так. Иногда актуализируя, пару раз в день (для предприятий). Вряд ли сегодня построенный завод мне сегодня же что-то отгрузит. Даже сегодня зарегистрированный.
Да и хранить-то там... Наших несколько сотен тысяч, иностранных меньше. Меркурий где-то хранит? Ну вот.

это не факт что юридически завод, это пункт перегрузки может быть и это уже новый элемент BusinessEntity. адрес получателя (ФИЗ ЛИЦА) туда же. Это не только производители, это все участники оборота. Несколько миллионов записей, на чем вы их крутить собрались, не на 1С надеюсь файловой

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

Проверила ваш запрос на боевой. Та же фигня, пустой результат.