|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: ANIT
Индекс форума » Профиль для ANIT » Сообщения, отправленные пользователем ANIT
Автор Сообщение
Пол года работы над проектом коту под хвост.
В конце декабря, после долгих мучений и переговоров по вопросам "там не работает, тут не работает", проект мы запустили. Одно, но, пока решали технические проблемы, остатки по партиям в меркурии, стали не актуальными, т.к. приход по партиям начали отражать еще в конце октября, а расход смогли только в конце декабря.
Отправили машину с мясом на межгород, с электронным ВСД, проба пера так сказать. При забивке куча производственных партий на нужную продукцию, сроки годности одинаковые (т.к. установлены по сырью), а даты выработки естественно разные. При этом меркурий такие производственные партии объединять не дает, объединить можно только входящие. Ну что делать, взяли последний выпуск. Водитель, преодолев 400 с лишним км. доставил товар на склад покупателя, а покупатель взять его отказался, т.к. дата выработки указанная на коробке и в ВСД разнилась на пару дней. И машину с товаром, благополучно развернули обратно, со всеми вытекающими последствиями, типа штрафы и неустойки за недопоставку товара и срыву сроков поставки. Подробно почему нельзя нормально наладить учет на складах заморозки, я отпишусь в отдельной теме.
После данного инцидента, было принято решение о заморозке проекта, до тех пор, пока не будет проведена полная инвентаризация на складе в разрезе дат выработки и сроков годности и не будет соответствия начальных остатков в меркурии и на складе. Персонал, включая административный, на новогодние праздники облочился в теплые спецовки и руковицы и два дня лопатил коробки заморозки переписывая маркировки и подсчитывая точный вес и количество коробок по каждому виду продукции, по каждому производителю в разрезе сроков годности и дат выработки. По результату, был в 1С сформирован документ Заявка ВСД на инвентаризацию и передан в систему Меркурий.
И тут началось, самое интересное! После того, как документ попал в систему со ВСЕХ партий исчезла информация о Номерах и датах бумажных входящих ВСД, о Разрешениях на ввоз продукции на территорию РФ и Маркировке продукции. Т.е. мало того, что через шлюз при вводе остатков невозможно передать эти сведения из учетной системы, мало того, что ее пришлось вносить через уродливый интерфейс, выискивая в журнале нужную партию, лопатя огромные папки с ВСД и эксельку вет врача для получения информации по каким ВСД эта продукция попала на склад и вообще на территорию РФ и еще при записи каждый раз описывая причину зачем мы корректируем партию, так еще и затереть все это к чертям собачьим одним кликом мышки?
Т.е. всё, отгружать без этих данных, НЕЛЬЗЯ!
Обратились в тех. поддержку интегратора, тот в свою очередь в тех. поддержку меркурия, ответ "Исправим в следующем релизе", это так же как с датами ВСД "в следующем году"? Одним словом "когда-нибудь, может быть"?
На этом шоу, не закончилось!
Дабы хоть как-то работать, повздыхав и вдоволь выматерившись, со словами "блин, ну чтож делать", решили пусть партии зависают на остатках, про инвентаризацию забыть на неопределенный срок и ОПЯТЬ несколько дней лопатить все папки с бумажными ВСД и вносить все недостающие данные заново! Перелопатили часть и собрались вносить. Но не тут то было! Когда мы полезли с вет врачом в журнал продукции, от туда волшебным образом исчезла кнопочка "Редактировать". Пощелкав по позициям, выяснилось, что она исчезла по всем партиям, которые попали под инвентаризацию. При этом все новые партии были доступны для редактирования. Побродив еще по ссылкам Меркурия ГВЭ, нашли, что если зайти в загруженный Акт несоответствия и войти в него, то будет доступна ссылка на нужную партию и там будет доступна заветная кнопка и можно отредактировать поля Входящее ВСД, Разрешение на ввоз, Маркировка. Но и это не все! при попытке внести затертые сведения и записать элемент, система шлёт врача куда подальше, доводя до его сведения, что у него НЕДОСТАТОЧНО ПРАВ НА ВЫПОЛНЕНИЕ ДАННОЙ ОПЕРАЦИИ!
ФИНИШ!!!
Система при простой операции массово убивает важные данные, без которых нельзя отгружать товар, устранять ошибку никто не спешит, а вы работаете как хотите. Подумаешь груз не примут, подумаешь груз арестуют и оштрафуют предприятие. Мелочи!
Николай Власов wrote:Ни чего нового: работники Россельхознадзора, например, работают на пунктах пропуска в том режиме, в котором работает пункт пропуска. В основном - это 24х7. И ничего: не разваливаемся как-то ...

Т.е. вет управления должны просто перейти на режим работы 24х7?
Николай Власов wrote:
ХСы, полагаю, не хотят, чтобы ветврач работал по 24 часа в сутки. Они хотят, чтобы ветупр так организовал работу (а ее надо организовать совершенно на новой методологии) своих специалистов, чтобы отправки без нарушения законодательства можно было осуществлять 24 часа в сутки.
Мы этот период уже прошли и он тоже был не простой. Через пару лет ветупры тоже поймут преимущества новых подходов. Поймут, привыкнут к ним и не будут понимать как без этого могли работать.

А вот с этого места поподробнее... как ветупры должны организовать свою работу чтоб ХС мог отгружать 24 часа в сутки, что за новая методология?
gni wrote:1С у нас УПП.
А вот второй вопрос ("На каком ПО собрались интеграцию делать, уже купили или ещё определяетесь с выбором?") не понял.
С 1С хотим интегрировать...

В УПП сейчас готовых модулей нет. Чтобы УПП работала с Меркурием, ее или нужно дописывать, нанимая разработчиков (дорого и высокие требования к квалификации) или второй вариант, докупается ПО из категории 1С:Совместимо. Сейчас на рынке интеграторов пока раскручено два, компания Визард и АСБК. Визард модуль под УТ 10.3 и УПП написала, которое ставится поверх вашей конфигурации, АСБК отдельно стоящий продукт (1С:Управление ветеринарным сертификатами), который существует в виде отдельной базы и данные из учетного ПО в него выгружаются. Но там пока обмен только с УТ11 и ERP, на сколько мне известно. А с УТ 10.3 и УПП обещают в начале года (судя по семинару).
Николай Власов wrote:Будет. Вскоре после НГ.

Спасибо за ответ.
Прошу извинить меня за столь резкую риторику, но на то есть свои причины.
Николай Анатольевич, у меня огромная просьба к Вам и к модератору форума. Сделайте две темы с запретом создавать комментарии (чтоб не захламляли). Первая, это нормативно-справочная документация по ЭВСД. Найти что-либо нормальное на сайте Россельхознадзора практически не реально. Опять же, часть приказов вообще Минсельхозовские. Чтобы понять, на какую НСИ операться, необходимо перерыть кучу документации, выяснить а действует ли она на данный момент, или давно уже отменена, давно уже другая редакция. Лучше таких две темы, одна "ДЕЙСТВУЮЩИЕ НСИ", вторая "ПРОЕКТ". Без каких-либо мегапояснений, просто, название приказа/постановления/правил/закона, ссылка на него. В идеале размещать там же местные приказы и постановления, т.е. то что выпустили на уровне субъектов. По проектам, кратко, на какой стадии проект, у кого проект на рассмотрении, когда подали, если есть сроки рассмотрения на том или ином уровне, так же указать.
Вторая закрытая тема, от разработчиков шлюза и меркурия. Увидели на форуме или на почте описание проблемы, приняли к работе, указали в данном разделе, что такая проблема имеет место быть и решена она будет в таких то числах, в таких то релизах, пояснения, что поменяется для пользователей или разработчиков интеграционного ПО.
А то получается сидим как слепые котята, то ли нас услышали, то ли нас культурно послали со всеми проблемами. Что клиенту отвечать, давайте перепишем за вас счет кучу модулей, чтобы вы могли работать, или давайте подождете недельку, разработчики меркурия пообещали исправить проблему? Сейчас же по телефону поговорили, на форуме поговорили и глухо.
Я понимаю, что ни у Вас ни у разработчиков Меркурия, нет времени постоянно торчать на форуме и отвечать всем и каждому, у Вас и без того дел по горло. Но вот такие две ключевых темы, уже снимут большую часть вопросов. Одно дело отвечать и читать переписку с почты с одним и тем же вопросом от десятков, тратя на это рабочее время. Совсем другое дело открыто говорить о проблемах системы и давать хоть какую-то информацию пользователям о сроках ее решения. Пример тому сайт тех. поддержки 1С. У них к каждому релизу есть раздел ОШИБКИ РЕЛИЗА, там список ошибок которые приняли на рассмотрение разработчики, краткое решении ("обход") проблемы или сроки и номера релизов в которых эта ошибка будет исправлена. Задал клиент вопрос "а у меня тут какая-то ерунда происходит", посмотрела я в этот раздел, увидела, что ни у одного него проблема, голову не ломаю и в тех. поддержку уже не пишу. Если проблема критичная и срочная, пробуем исправить самостоятельно, если нет, ждем релиз, но мы хотя бы примерно знаем, когда его ждать.
gni wrote:
А вот еще пара вопросов:
Допустим ХС автоматизировал подачу заявок. Но, как я понял, пока вет врач не примет решение мы все-равно не получим ВС и не сможем отгрузить продукцию. А если вет врач это делает вручную да еще у него 8 часовой рабочий день - вообще отгрузка выглядит проблематично. Т.е. для нормальной работы ХС в этом случае необходимо еще и автоматизировать работу ветврача. А кто в этом случае должен давать заявку на доступ к API? Вет управление?

Начну с конца.
А кто в этом случае должен давать заявку на доступ к API? Вет управление?
Заявку подает ХС на своем фирменном бланке с печатью и подписью ген дира, а может и вет. управление. Подробно тут: http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API#.D0.9F.D1.80.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B4.D0.BE.D1.81.D1.82.D1.83.D0.BF.D0.B0
Если вет. врач штатный, то от лица ХС отсылаете.
Доступ вам дадут только на тестовый шлюз. На рабочий вы получите только после адекватного теста, когда набор безошибочных транзакций будет на тестовом шлюзе достаточный. Т.е. отправить 1-2 заявки и подать запрос на рабочий шлюз, не вариант, заявок нужно прогнать штук 20. С тестовым шлюзом работайте В КОПИИ 1Ски. В любом случае копия будет у вас на долго, т.к. нужно проверять корректность релизов Меркурия, корректность релизов интеграционного продукта который вы внедрять будите и делать всякие эксперименты.
Второй момент: Допустим ХС автоматизировал подачу заявок. Но, как я понял, пока вет врач не примет решение мы все-равно не получим ВС и не сможем отгрузить продукцию.
Не совсем так. Если вы работаете через ВЕТИС.API, то заявку должен отсылать вет. врач под своим логином. УВЫ И АХ. Это еще один существенный недочет системы. Ветис.API почему-то не умеет работать через 2х ступенчатую систему, как это работает в ВЭБ интерфейсе. Т.е. ХС сделал заявку, а врач через ГВЭ жмет кнопочку Принять или Отклонить. Через API ваш Вет.врач должен будет работать в 1Ске и из нее отправлять ветки в Меркурий. И это огромная головная боль для внедренцев и ХС, мои коллеги с другой фирмы уже столкнулись с нею, на проекте где вет. врач не штатник. Четыре месяца работы, вышли на этап "продакшена", в рабочей версии состыковали все справочники и стопорнулись на пару недель, пока решали вопрос, что вет врач из вет. управления обязан будет работать в 1Ске. Хоть и со скандалом, но вопрос благо урегулировали и вет. управление все же пошло на встречу в такой ситуации. Я пока с клиентами по интеграции, где штатника нет, стараюсь дел не иметь. Но в любом случае я нарвусь на эту проблему, когда штатники пойдут в отпуска или на больничные, т.к. в таком случае будут привлекаться к работе приходящие специалисты из вет. управлений. Когда этот недочет шлюза будет решен, не известно. Поэтому перед тем как вбухивать деньги в интеграционный проект, в первую очередь поинтересуйтесь вопросом, готовы ли "приходящие" специалисты, если они есть, отправлять ВСД из 1Ски?
По хорошему механизм Ветис.API должен иметь обе схемы работы. И схема когда ВСД влетает со статусом "Оформлена" и с подписью отправившего с 1Ски вет врача (т.е. текущая схема) и схема работы в два этапа (как в ВЭБ интерфейсе). Но когда разработчики это реализуют, БООООЛЬШОЙ вопрос.
С текущей схемой работы через шлюз есть еще один весомый затык. Как только ВСД влетело в Меркурий, ничего вы поправить там руками уже не можете. Не все реквизиты влетают корректно, какие-то недочеты есть в работе разработчиков интеграционных решений, какие-то у разработчиков ШЛЮЗА (методов нет для заполнения реквизитов). Как итог через ВЭБ вы оформить корректно ветку можете, а через шлюз нет, можно только аннулировать. Если бы Ветка влетала и она была бы доступна для редактирования, то это бы сняло целый ряд проблем.
gni wrote:А если вет врач это делает вручную да еще у него 8 часовой рабочий день - вообще отгрузка выглядит проблематично.

А это судя по всему уже проблемы индейцев. Увы и ах.

gni wrote:
1. Обязательно ли печатать вет свидетельство? Сделал пробную транзакцию на перевозку продукции и распечатал. Получилось на каждую позицию в накладной по 1 свидетельству. А у нас нередко бывает, что в одной накладной по 50-70 позиций. Тогда к накладной еще полпачки бумаги в виде ветсвидетельств прикладывать придется?


Айболит163 wrote:Выбор в каком виде будет ВСД остается за ХС (но "согласовать" с гос.врачами нужно), вы имеете право выбора .
ВСД можно распечатать в сжатой форме (штрих коды)


Увы не факт. Тут нужно будет под каждого покупателя индивидуально думать какой бланк ему оформить. Местные вет. врачи которые активно у нас работают с вэб интерфейсом, рекомендовали печатать именно полные бланки, т.к. в обязательном порядке ЭВСД вступает в силу только с 2018 года, а в сжатых формах бланков отсутствует полная информация по отгружаемой продукции. Если вы обращали внимание, там в частности отсутствует информация о Целях реализации, о благополучии местности, о ВСЭ, о входящих ВСД, о разрешениях на ввоз продукции (актуально для импортной продукции). Вся эта информация есть только на полных бланках и доступна при проверке через Меркурий.Паспорт. Если у клиента нет доступа в интернет, то проверить ЭВСД он толком не сможет и полную информацию из сжатого бланка он не получит, ему тоже не интересно бодаться с инспекцией. Следовательно с каждым клиентом необходимо обговаривать вопрос, нужно ли им везти полный бланк ВСД или достаточно будет сжатого и при необходимости клиент готов распечатывать его на своей стороне. Поэтому закупаем побольше бумаги и тонера!
Более того, не исключен вариант печати всех этих отгрузок на защищенном бланке! А в этом случае вполне возможно вы сталкиваетесь с вариантом 50-70 бланков на накладную, при выписке через меркурий, вместо ранее выписываемых вами 5-7 вручную на ту же накладную Защищенные бланки у вас может затребовать покупатель, потому что они так привыкли, и вы им или даете разноцветный бланк или они уходят к конкурентам (если полистаете форум, увидите, такие прецеденты имеют место). Второй вариант когда вам, возможно, придется распечатывать меркурьевский ВСД на цветном защищенном бланке, это междугородние перевозки, т.к. нет никакой гарантии, что при проверке груза не попадется проверяющий с пулей в голове, который будет требовать от вас красненький бланк, т.к. у него нет интернета и он не может проверить достоверность вашей распечатки или "он так привык". Можно конечно попытаться доказать ему, что он не прав, накатать жалобу и т.д. и т.п., одно НО, простой машины, штрафные санкции от покупателя по договору за срывы сроков поставок, а может и испорченный груз (увы такое тоже бывает, и тема на этом форуме или на форуме Россельхознадзора поднималась. Произвол проверяющих увы тоже имеет место, пока искала нормативно правовую документацию по ВСД наткнулась на занимательное видео четырехлетней давности, где вскрыли без представителя контейнер с красной икрой, порвали половину этикеток при разгрузке и выставили груз на солнце. Легальная она была или нет, обоснован досмотр был или нет, не мне судить, показали только часть, но то что нарушение температурных режимов при досмотре груза было, это и обывателю понятно. Груз после таких досмотров, только закопать. И ясно дело, никому не охото давать лишний повод для срыва пломб и вскрытия реф. контейнеров, особенно в теплый период всем и в мороз для охлажденки. Поэтому ХС стараются перестраховываться и не давать лишнего повода для придирок. Во всяком случае пока не будет четкой нормативки по всем надзорным ведомствам.)\
На сколько я понимаю, вот эта вещь так и осталась проектом. http://www.garant.ru/products/ipo/prime/doc/56554094/ Там есть моменты которые мне в этом проекте не особо нравятся, но там был ключевой и очень важный пункт:

11. В случае, если ВСД оформлен в электронной форме, лица, уполномоченные на проведение в Российской Федерации ветеринарного контроля (надзора), не в праве требовать от владельца (перевозчика) подконтрольного товара предъявления ВСД на бумажном носителе. При этом владелец (перевозчик) подконтрольного товара обязан по своему выбору или предоставить номер электронного ВСД, оформленного на товар, или предъявить соответствующий этому ВСД двумерный матричный штриховой код, сформированный ФГИС, или предоставить распечатку формы для печати оформленного в электронной форме ВСД.

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

В действующем 281м, увы я его не наблюдаю.

gni wrote:
А вот еще пара вопросов:
через часик напишу, сейчас не совсем удобно, в дороге. Уточнить прошу два момента:
1. Ветврач штатник или приходящий?
2. На каком ПО собрались интеграцию делать, уже купили или ещё определяетесь с выбором?
3. 1Ска какая конфигурация? Упп, erp, УТ 10.3, УТ 11, БП?
Айболит163 wrote:
Обратитесь к ANIT она в теме. А может ANIT он, без обид
оно, Агентство АНИТ аббревиатура, сокращенное наименование фирмы в которой работаю а так всё верно, ОНА в теме, я девушка
Айболит163 wrote:
Все интереснее.
При создании транзакции на последнем этапе нужно нажать "оформить", но можно нажать это и через день, и через два, а распечатать сейчас

Ага, если бы все так было просто. При работе через шлюз Ветис.API, все всд в него влетают как оформленные! Ничего исправить в них нельзя после этого. Поэтому пришлось придумывать извращение с автоматическим переносом даты документов реализаций и фактур при отправке ВСД в период с полуночи до 7 утра. Учётную систему вгоняем в ...пу из-за пофигизма разработчиков Меркурия.
Тема вообще умерла! Будет изменение по часовым поясам? не будет? сроки? нифига, всем пофиг! Внедряйте нашу замечательную систему, а кто против, те воры и провокаторы! Чё нам, под всех заМКАДышей подстраиваться? пусть переводят стрелки часов на московское! Москва и есть вся Россия!
Айболит163 wrote:Есть уже умельцы, которые могут напечатать ВСД в Меркурии на защищенном бланке хоть завтрашним хоть на 2 дня вперед датой. Способ интересный в два этапа.

Печатать или выписывать? Если вы имеете ввиду сохранение и редактирование макета, то это тоже не совсем гуд. Т.к. при проверке такой ветки через Меркурий.Паспорт будет несовпадение дат на бланке и в системе!
Пару слов про Стахановцев. Проблема сбора статистики и ее актуальности. Не могу пока найти и пересмотреть запись вэбинара, но там мне кажется говорилось о 800 в день, а не в час, хотя могу ошибаться. Если это в час, то там интеграционный проект. Т.е. создание ВСД в системе может быть и автоматическое, а такая статистика, только за счет разового нажатия кнопки "отправить" когда сотни веток летят в меркурий за подписью вет врача. Готовить их может и десяток операторов. И то очень сомнительно выглядит, это надо иметь мегаскоростной канал, чтоб запрос так быстро обработался. Сегодня в рабочей базе сделали первую отправку ВСД на реализацию, в среднем система секунд 5-10 висела на отправке, и примерно столько же при получении pdf бланков печати.а тут в среднем 4,5 секунды на 1 ВСД вместе с оформлением, какая-то не реальная цифра даже для интеграционных решений. Учетной системе еще нужно успеть собрать данные и сформировать пакет документов для отправки. Если все это в рамках однопоточных транзакций за 4,5 секунды, то я просто приклоняюсь перед теми мега админами и программистами которые добились таких показателей производительности своих СУБД, прикладного ПО, серверов и сети. Просто ухожу нервно курить в сторонку.
Опять же, это ВСД или Транзакций меркурия, т.к. в одной транзакции (отгрузке) может быть несколько ВСД, вот вам уже 1 превращается в 10. И в реальности там уже не 800 веток/отгрузок, а 80. А как подсчет идет? Только исходящие ветки или все телодвижения включая заведения новой номенклатуры и контрагента, включая транзакцию по изменению данных в журнале продукции? Вот уже не 10, а 20.
Кривая статистика номер два, это сбор ее на основании обработки ВСД ветврачем, в Меркурий.ГВЭ, когда ее уже набили сотрудники ХС в Меркурии.ХС. Одно дело забить ВСД, другое дело нажать Принять или Отклонить.
Третье, это "Да ребят, реально по 1000 в день оформлять через Вэб. Интерфейс!". НО!!! Если у вас маааааленький ассортимент, да еще и собственного изготовдения, без сложных производственных процессов. Одно дело птицефабрика с 10 позициями, и другое дело конечные звенья оптовиков которые торгуют всем чем можно и где 1000 позиций не предел. Сегодняшняя отгрузка была на 7 коробок, 7 разных позиций в накладной по 1й коробке, итого 7ВСД на 1 отгрузку и то, смогли оформить только 5, т.к. забыли внести остатки по двум позициям, как итог поехал груз с 5 электронными и 2мя бумажными ветками. При малом ассортименте, в вэб интерфейсе, вариант создал шаблончик и шуруй под копирку отлично работает, с большим ассортиментом и кучей партий, этот шаблончик, что мертвому припарки. Вариант вести "свернуто", по видам номенклатуры, тоже не совсем рабочий, т.к. многих вещей в справочнике виды продукции нет, они слишком укрупняют. С записью типа "свинина", не понять мороженная, на кости, не на кости, шея, щека? Да и верно соорентироваться в том какую партию взять при укрупнении почти не реально. У вас по накладной зашла Свинина шея от 12.12.16 и Свинина щека от 12.12.16, вы забили это как " свинина", шею отдали в лабораторию, а теперь вопрос, как определить партию к которой привязывать результаты? Вы начинаете оформлять отгрузку, вопрос как определить где шея? А там на вашей ВСД еще указывается информация по входящей ВСД и если импорт разрешение на ввоз. Возьмете партию что была на щеку, при отгрузке шеи. Потом сделают запрос по входящей ВСД, а там щека, все, продукция переходит по факту в статус нелегальной?
Да и то что касается зарубежных производителей, они в 1Ске заводятся за несколько щелчков мышки, там эти танцы с бубнами по поиску реквизитьв организации и занесению контрагентов, не требуется. Продукция легальная, завод будет. Пока проблем с поиском зарубежных в 1С не возникало.
Chex wrote:
ANIT а в чем проблема для вас поставить на приход отечественную продукцию?
Вы об этом постоянно пишите. Если нет производителя в системе его запросто можно указать, при добавлении входящего ВСД в программу, через графу «Ввести информацию о производителе вручню

Как всё просто
Как это выглядит у нас сейчас в реальности на интеграционном проекте. Начинаем ставить продукцию на приход, выясняется, что производителя нет. Поднимает толмут со сканами входящих маркировок с пришедшего товара, смотрим внимательно полную инфу по заводу, адреса, цеха и т.п. Лезим в интернет и гуглим реквизиты предприятия производителя, точнее юр лица которому это производство принадлежит ИНН КПП ОГРН Юр адрес ибо ни в ветках, ни на этикетках такой информации нет! Передаем данные в бухгалтерию. Сотрудник с доступом на создание контрагентов, в папке Производители, заводит нового контрагента. После этого, этот контрагент синхронизируется с меркурием, если он есть, то подцепляется ГУИД существующего ХС, иначе этот ХС создается в меркурии с указанныими нами параметрами. На следующем шаге подгружаем из меркурия в 1с все заведенные на него предприятия. Ищим нужное нам предприятие из списка. Если находим, то указываем его в качестве производителя для нашей номенклатуры и оприходуем продукцию, иначе заводим для этого ХС предприятие с указанными на этикетке и в ветке реквизитами, опираясь больше на этикетку чем на ветку, т.к в ветке обычно не полная информация, в частности адреса производителя вообще нет, только название. Пытаемся дальше еще привязать предприятие к ХС, в очередной раз вздыхаем при ругани системы на чужой субьект и довольствуемся тем чем есть, предприятие непревязанное берем в качестве производителя, впринципе тут хоть сняли блокировку. С поставщиком уже такой фокус не прокатит. А что касается указания производителя не через справочник, а строкой, увы и ах, такие партии в 1ску просто не прогружаются. У нас такая зависла с вет. Пробами. Оформил ее врач с другого субьекта, теперь партия висит мертвым грузом, ни завод корректно не перевыбрать, ни отгрузить ее через 1с, еще и за счет такой самодеятельности остатки по сути задвоили, одна запись журнала забита правельно нами при оприходовании, но к ней нет лабораторных исследований и эта же по факту партия заведена некорректно вет врачем другого субьекта и к ней привязаны эти самые лабораторные исследлвания. И причем завод зарубежный и причину почему завели строкой, хотя есть справочник, я вполне понимаю. Попробовала я через интерфейс этот завод найти, это та еще задачка скажу я вам. Когда один и тот же брэнд имеет с десяток заводов раскиданных по стране по разным адресам, т.е. имеет разные номера. Начинаю искать, имя допустим bsf ищим по наименованию, в лучшем случае вываливается спислк из 10 таких заводов и нужно угадать, а какой нужен, в худшем за счет фишек интеграции только находим, что в аргусе этот завод заведен как b.s.f. и потому поисковик наименование из бумажной ветки найти и не может. Ок ищим по заводу, матерясь на то что система ничего не нашла, догадываемся, что искать только через кнопочку Расширенный поиск. Ищим, может даже не находим. Вводим номер завода например 12345, а эта фигня говорит, пошли нафиг, нет такого завода. Как так? Продукция легальная, на этикетке тоже такой номер завода. И тут опять же через интеграционные плюшки мы видим, что номера могут быть забиты: "12345" или "12345 sif" или "sif 12345" или "12345_sif" и т.д. и т.п. человек который работает через вэб интерфейс никогда об этом и не узнает. Он сюда щелкнул, нет ничего, туда щелкнул тоже нет и пошел фигачить от руки, а как потом такая ветка дальше обрабатываться будет, его уже не интересует.
Veterinardoctor777 wrote:
Каждые сутки на складе отгружают продукцию в 500(+-50) магазинов по области и соседним областям.
Справки выписываю по шаблону в Excel(4 вет.свидетельства на магазин в среднем).
Примерные цифры по справкам в сутки =500*4=2000 ВСД в сутки в среднем.


По моим примерным подсчетам, если один врач работает 24 часа в сутки, то не прерываясь на прием пищи, кофе и туалет, он должен успеть оформить 1 ВСД на отгрузку в течении 45 секунд, это не считая того, что он все эти партии должен еще на приход поставить
Что там, проверить груз? ага
 
Индекс форума » Профиль для ANIT » Сообщения, отправленные пользователем ANIT
Перейти:   

Powered by JForum 2.1.8 © JForum Team