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

nifor wrote:

Doc18 wrote:

nifor wrote:Только начал изучать документацию. Если руками создавать транзакцию получается можно указать сколь угодно получателей.

В физическом плане да, можно указать сколько угодно, а вот в соответствии с ветеринарным законодательством нет. Потому что получится, что к этим всем получателям (100, 200, 300, 1000...) продукция поставляется на одной машине.

Я как пример привёл количество. У нас допустим в одном большом рефрежераторе может ехать клиентов 30. Всё-таки можно ли посредством API создать транзакцию на перемещение со сменой владельца в которой будет 30 получателей ?

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

nifor wrote:Добрый день коллеги !!! Подскажите пожалуйста возможно ли при оформлении транспортной партии через API указывать список получателей ?

разве по описанию не видно что нельзя? один получатель - одна транзакция, а если по документам охлаждёнка и заморозка - две транзакции

E_Letov wrote:

Doc18 wrote:Это фантазия. Там есть ограничения.

Это мнение технически более грамотного человека. А что вы ещё знаете об ограничениях, кроме того, что они есть?

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

VS-ХС wrote:
Многие пользователи уже смирились с таким положением, что "поезд уже идёт и тормозить и переформировать вагоны поздно".
"Работаем с тем, что есть". По принципу - фигня война, главное манёвры.
Но при таком подходе – в победу при таких "манёврах" некоторые уже не верят.

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

Semerenko wrote:
Причины две: 1. Они до поры не понимают, что происходит. В программе и ее работе опять же не разбираются от слова "совсем"
2. Когда возникает проблема - недовольный ветврач получателя - они шевелятся, идут на уступки, стараются замять скандал, но при этом БОЯТСЯ. Это основная причина. Страх. На крупных предприятиях ветврач очень зависим от руководства. Боятся потерять работу, боятся что их во всем обвинят. Да всего боятся!

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

Semerenko wrote:
К ТЦ Южный с адресом привязать ХС-тов - да без проблем, а вот к тупо АДРЕСУ - щас же!
Доступ ХС, кстати, получает не к ИНН-у, а к ПРЕДПРИЯТИЮ, которое с адресом. Поэтому продукцию ТЦ Южный будет видеть ХС-т ТЦ Южный. Что может не как и плохо)

я не уверен, что все ХС получающие ВСД по этому адресу будут рады поделиться конфиденциальной информацией

E_Letov wrote:

Semerenko wrote:Ни один нормальный админ не привяжет эти "адреса" к врачам. На этом адресе может быть и 40 фирм (база) или 5 арендаторов (склад).

Весь товар в одном журнале, если ХС получает реквизиты доступа (банально захочет гасить) - он видит что сколько и у кого, как я понимаю. А не только свой товар. И это не удобно для врача, но ему откуда знать, что можно сделать иначе?

А вот этот трэш у меня в голове не укладывается... Чисто технически модуль интеграции Хозяйствующего субъекта может вытащить подробную информацию по всем транзакциям прочих Хозяйствующих субъектов привязанных к тому же Предприятию..
Безопасность? Нет, не слышал.

Semerenko wrote:Ни один нормальный админ не привяжет эти "адреса" к врачам. На этом адресе может быть и 40 фирм (база) или 5 арендаторов (склад). Пойди -пойми "что хотел иностранец?"....
Еще раз обращаю Ваше внимание на название темы: "Выписка по одной [b] кнопке"! Для редактирования надо ДВЕ КНОПКИ
ДА и коллеги подтверждают.
Очень самостоятельная программа у них - сама все делает (связывается с базой 1С, Меркурия, формирует СВД с накладных), а врач только ПОДПИСЫВАЕТ эти ВСД, нажимая кнопку. Некий аналог ЭЦП. Казалось бы почти "гениально", но..........Сами видите.
за формулировку "пинать разработчика" - отдельное спасибо. даже как-то легче стало.

Я не агитирую за привязку такого "чисто адреса", я говорю о технической возможности.
"Самостоятельная программа" - это конечно хорошо для рекламы ПО и разработчика, но такой режим работы - конечно мрак.
Но я не буду оригинален и задам вопрос: почему вет.врачи, под учётными записями которых оформляются транзакции - молчат?
Что мешает им обратиться к руководству Хозяйствующего субъекта, объяснить ситуацию и приостановить оформление ВСД через интеграцию? Поверьте - это замечательный стимул для скорейшего назначения виноватых и исправления ситуации, ответ разработчика "так работает программа" - не принимается.
Не надо всё валить на программу и разработчиков - человеческий фактор всегда первичен.

Semerenko wrote:
Вот тут скобочки и скрины. И название предприятия, на котором внедрял ПО автор данной темы. Он признался.
http://vetrf.ru/vetrf-forum/posts/list/405/6633.page
[Post New] Agnostik 24/04/2017 06:11:50

а, вот где скриншот - не в этой теме, ну это идиотия в чистом виде, кто ж спорит?

E_Letov wrote:

lalex23, это норма? И получатель сможет погасить такой ВСД, ведь по GUID имеется синхронность?

конечно это не нормально, если штамповка таких Предприятий поставлена на поток - надо в первую очередь хватать за хобот интегратора ПО, во вторую - вет.врача, а может и наоборот
Такой ВСД смогут погасить при условии что это новоиспечённое предприятие будет привязано к вет.врачу получателю

Повторюсь: если в интеграционном ПО предусмотрено редактирование реквизитов Предприятия или Хозяйствующего субъекта перед отправкой заявки на регистрацию - это вопрос к вет.врачу инициировавшему регистрацию, после регистрации Предприятия и оформления транзакции он не может не видеть что Предприятие зарегистрировано некорректно. Если в ПО такой возможности нет - надо пинать разработчика.

Semerenko wrote:
А вы не задавались вопросом, почему в документе, выложенным коллегой, в поле для внесения наименования предприятия адрес указан дважды (второй раз в скобках)?

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

Semerenko wrote:
программисты подсунули это сырое ПО и они реально нажимают на кнопку. А дубли плодит ПО! Тот ветврач, с которым я общалась, в меркурии двух шагов сделать не мог! Не то чтобы целенаправленно создавать дубли, да еще с неверным названием.

а вот это уже вопрос не к ПО, это вопрос к процессу обучения вет.врачей на этапе адаптации в плане использования ПО, а так же добросовестности самих вет.врачей - куда как проще бахнуть по кнопке создания Предприятия, чем поиском перелопачивать не одну сотню Тандеров или Пятёрочек полученных при поиске по наименованию Предприятия

Semerenko wrote:
Вы не понимаете сути проблемы, потому что с ней не сталкивались.

к сожалению сталкивался, поскольку такие проблемные случаи приходится пока разруливать мне лично: отвязка некорректно синхронизированных Предприятий с Адресами доставки в 1С - для вет. врачей это операция не тривиальная и пока слабо автоматизированная

Semerenko wrote:
А принтскрине - табличке, выложенной автором темы, в столбике НАИМЕНОВАНИЕ указаны АДРЕСА. Не смутила неувязочка?

это Наименование точки доставки в учётной системе Хозяйствующего субъекта: там её хоть Пеньками, хоть Валенками назовите - неважно, важно что отправляя продукцию в Пень - вет.врач должен быть уверен что продукция придёт на правильное Предприятие и будет погашена вет.врачём в ведении которого этот Пень находится

Господа вет.врачи и разработчики интеграционного ПО, у меня складывается впечатление, что одни пытаются всю вину за дубли свалить на других, а вторые не могут толком объяснить свою точку зрения, а третьи с удовольствием участвуют в свалке - поочерёдно пиная и тех и других.

E_Letov любой объект в Меркурии имеет guid и большинство имеет uuid
Semerenko ну что вы привязались к этому термину "точка доставки"? Ну неудачная для интеграции Меркурия с 1С принята терминология:
Хозяйствующий субъект = Контрагент, а Предприятие = Адрес(точка) доставки,
это ведь не отменяет, что вет.врач перед оформлением ЭВСД должен убедиться что Предприятие и или Хозяйствующий отсутствуют в Меркурии и только после этого создавать новые справочники, то что создана куча новых Предприятий - проблема не в чистом виде разработчика, но и частично вет.врача инициировавшего операцию.
Не воспринимайте при отсутствии синхронизации учётной системы и Меркурия термин "одной кнопкой", как действие генерирующее новые Предприятия и Хозяйствующих субъектов, я более чем уверен что существуют механизмы поиска общие и уточненные, а "одна кнопка" срабатывает только при синхронизированных Хозяйствующем субъекте и Предприятии
з.ы.
я сам разработчик, но не массового решения, а интеграции учётной системы конкретного Хозяйствующего субъекта, мы его не продаём - используется только на нашем предприятии. Неоднократно вет.врачи натыкались на ситуацию, когда продукция отправлена получателю, а он её не видит для гашения - выясняли что или неверно выбрано для синхронизации Предприятие найденное поиском или ошибочно создавалось новое, как правило это происходит в случае когда наименование предприятия внесено как-попало и не отражает своей сущности.
з.ы.ы.
много есть ещё чего сказать, но добавлю одно: попробуйте услышать друг друга и немного снизить уровень ЧСВ - у некоторых он зашкаливает

Regina wrote:Добрый день! Подскажите пожалуйста если работать в Ветис.API, то каждому наименованию одного производителя присваивается код или код присваивается одному наименованию товара любого производителя (например, есть с/м рыба минтай производитель Акрос и с/м рыба минтай производитель Дальморепродукт. Код у товара будет один или у каждого производителя свой?)?

Ситуация чуть более мрачная: конечная продукция производителя создаётся только через шлюз, доступна для изменения только через шлюз и привязывается к Предприятию, а не к Хозяйствующему субъекту.

sytl wrote:Ну допустим когда внедряли ЕГАИС, там было тех описание структуры файлов и сами xcd схемы xml ного формата!
Тут что то похожее есть для интеграции?

Вам же дали ссылку, если быть точнее : Универсальный шлюз Ветис.API

Doc18 wrote:

lalex23 wrote: Можно как-то избежать "лишних" транзакций?

Да принцип оформления Вы правильно поняли, в соответствии с законодательством должно быть так.

а вариантов упростить нет?

Господа разработчики, требуется помощь: есть холдинг, в состав входят предприятия которые осуществляют полный цикл выпуска продукции из мяса птицы (элеватор, инкубатор, племрепродуктор, выпуск готовой продукции), часть предприятий находится на единой производственной площадке, на конечном этапе цикла - готовые колбасные изделия, полуфабрикаты, субпродукты. В данный момент существует одно юр. лицо, осуществляющее выпуск продукции и реализацию мелким, крупным оптовикам, плюс собственная фирменная торговая сеть.
На территории предприятия работают 3-4 вет.врача(некоторые посменно) из вет.управления, которые через механизм интеграции учётной системы на базе 1С оформляют ЭВСД в Меркурии, логика учёта построена "от реализации": на каждую транспортную транзакцию формируется производственная партия и тут же отгружается. Логика выбрана такая, поскольку выпуск продукции идёт круглосуточно и продукция только-что выработанная может через 10-20 минут быть отгружена - онлайновое оформление производственных партий невозможно.
В ближайшее время в целях оптимизации налогообложения планируется организация нового юр. лица, через которое пойдёт вся реализация готовой продукции, а производство останется на том же юр. лице что и в данный момент, теперь в логике Меркурия схема оформления ЭВСД должна выглядеть так:
1. ЮЛ1 - производственный ЭВСД на выпуск продукции
2. ЮЛ1 -> ЮЛ2 - ЭВСД на транзакцию "смена владельца без перевозки"
3. ЮЛ2 -> ЭВСД на транспортную транзакцию со сменой владельца или без(для фирменных торговых точек)
Я правильно понимаю? Можно как-то избежать "лишних" транзакций?

and1024 wrote:

lalex23 wrote:
обновление платформы хотя бы до 8.2.19.130 - первое что приходит в голову, но 5 перифирийных баз, плюс в центральной базе порядка сотни пользователей с режимом работы 24/7 намекают на поиски программных решений проблемы, если конечно не склеится - будем обновлять..

Такая же фигня на 8.2.19.83 на тестовом все пучком, на рабочей "SSL connect error". Завтра попробую платформу обновить.
Как проблема решилась?
А что за сертификат нужно ставить? для тестовой ничего не ставил. В справке ничего не попадалось про сертификат. Где его брать?

обновление помогло