Необходимы новые методы

[Inkognito]

Для интеграции предприятий, необходимы новые методы:

1) Проверка доступности ЭДО для контрагента. Возвращать истину/ложь.
Причина: необходимо проверить контрагента перед передачей документа в Sender.
Использование: если ЭДО невозможен, то смысла добавлять и вызывать отправку нет, - все равно получим сообщение о невозможности отправить.

2) Получить текущую схему регистрации налоговых документов. Пусть возвращает некоторое значение.
Причина: необходимо проверить схему перед передачей документа в Sender.
Использование: если схема предусматривает только "РегистрациюНН", бесполезно вообще использовать Sender(0) - отправку контрагенту, - все равно получим сообщение о невозможности отправить.

3) Получить CharCode документа по его ExDocID.
Причина: 1 документ может иметь несколько Бланков (БланкUA, БланкRU, БланкEN). Соответствующие бланки реализованы в Медке.
Использование: оператор иногда ошибается, указав не тот бланк для передачи бланков. Бухгалтеру приходится иногда тратить много лишних телодвижений, чтобы выяснить это. Например, Предприятие1 получило БланкEN, хотя там англоязычный бланк и даром не нужен. В то же время Предприятие2 очень хотело получить документ БланкEN, а получило БланкUA (на украинском).

Все указанные методы необходимы для автоматизации ЭДО на крупном международном предприятии. От реализации новых методов зависит репутация Медка. Техническое воплощение методов в корпоративной среде ЭДО остается за мной. Не подведите.

[vademchuk]

Полностью поддерживаю

Позволю добавить:

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

2. Метод GetPrimaryReestr().
- Необходимо все-таки исправить (о чем неоднократно было озвучено на этом форуме). Сейчас независимо от указанного периода, метод возвращает РК ЗА МЕСЯЦ и кучу "мусора" из корзины и прочих загадочных мест.
- После 26 обновления метод стал крайне нестабильно работать на клиентах с ХР (лицензия), при этом более-менее работая под Вин7 (Медок сетевой, Оракл). Т.е. на ХР-клиентах 80% попыток получить реестр за 2дня (чуть больше 1000 вх.) заканчивается падением клиента медка. При этом на вин7 - около 1% сбоев. Тестирования и эксперименты проведены разносторонне - проблема реально существует. По факту закрытия января в моей группе компаний с огромным количеством НН, работа с Медком превратилась в сплошную истерику: App.DocumentsDataSet - теперь нельзя в запросе выбрать только входящие документы, а GetPrimaryReestr ложит Медок... Кстати, раньше можно было методом App.DocumentsDataSet с параметром FLAGS >0 получить все входящие за период, теперь же (после появления в НН/РК реквизита ЕДРПОУ) у документов с пустым ЕДРПОУ FLAGS = 0. Соответственно никакими другими параметрами ограничить выборку нельзя. Это не проблема когда документов до 1000, ну а когда их 15838 шт. за январь и еще два дня регистрации впереди ?????

3. Проблема сопоставления входящих документов. Сделав загрузку документа из Медка в УС логично сохранить идентификатор, по которому можно потом идентифицировать этот документ (и факт его загрузки в УС). Более года у нас это был code. Теперь при перезагрузке/обновлении документов (в частности и получении вытяга с импортом документов) code обновляется..... Если его нельзя не трогать, то для налоговых документов логично использовать SEND_DPA_RN (код регистрации в реестре), но тогда этот реквизит должен появиться в датасетах методов GetPrimaryReestr и App.DocumentsDataSet

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

4. Очень бы хотелось, чтобы Разработчик отреагировал на эту ветку.....
и словом и делом.

Дали буде.

[Inkognito]

В продолжение:

1) ОЧЕНЬ ВАЖНО, присоединяюсь!

2. Метод GetPrimaryReestr().

Данный метод нужно доработать, добавив параметры:
- Корзина (Да, Нет, НеУчитывать)
- Архив (Да, Нет, НеУчитывать)
Дайте нам возможность самим управлять, что нам выбирать!

2) Метод фильтрации РеестраПД:
RunModule.ApplyFilter() по DocType - НЕ работает!

3) Почему предусмотрели получение DataSet только для НН/Додаток2 --- GetPrimaryReestr()?
Где методы получения первичных документов по типу (Акт-Счет- и прочие)?
Где метод получения различных справок из раздела "Информационная справка"?

С уважением, Ваши клиенты, внедряющие настоящий ЭДО в крупной компании, на проблемы которой Вы успешно забили.

[Inkognito]

Продолжаем:

1) Поле "Status" (которое возвращает метод GetPrimaryReestr())
Как это понимать?



В Медке статус одинаков, а метод возвращает разные коды статусов?

2) Поле "Doc_vd" (которое возвращает метод GetPrimaryReestr())
В описании лаконично назван "вид діяльності". Что это за вид деятельности такой? КВЕД, спецрежим?
Во всех входящих документах 0.
UPD: пункт2 не актуален, это спецрежим. Просьба к разработчикам, - называйте поля читабельными названиями.

3) Поле Patrner_IPN ( опечатку надеемся исправите, или так и будет висеть это недоразумение? )
Вместо того, чтобы увидеть ИНН партнера (очевидно из названия), - отображается ИНН нашей организации.
Бухгалтеру что, интересно смотреть на свой ИНН в 1000 накладных? Сделайте нормальную выбору ИНН партнера, как следует из названия.

[brainplus]

А я не согласна с проверкой доступности эдо для контрагентов. Если у контрагета есть сертификат, значит зашифровать и отправить можно. "Лежат" и "ждут" своих хозяев документы на сдо зашифрованные, и почитать их может, только их получатель, и это правильно. Как показывает практика, мы любим работать вечером, рано утром и вообще любим работать, и неизвестно, в какое время суток Ваш контрагентов захочет "поковыиять" ,например, медок онлайн, и там ему такая пачка лежит. Вот радости то будет! Возможно, это станет причиной перехода такого контрагента на полноценное эдо, что упростит всем маршрутизацию.

[Inkognito]

В том-то и дело, что Медок контролирует возможность отправки по этому признаку.
А передаются документы в Sender - без контроля "возможности ЭДО".
Возникает ситуация (буквально на этой неделе), - бухгалтер выделил 500 накладных, пытается отправить (из обработки, используя этот метод), и тут через одного сообщения "Невозможно отправить..." Бухгалтер был "очень счастлив" нажимать около 250 раз "ОК", и в очередной раз рассказать все что она думает о Медке. Благо мы в хороших отношениях

Соответственно:
1) или нужно убрать из Медка такую проверку (сомнительно, правда? Это идет в разрез с политикой компании в области ЭДО)
2) или сделать аналогичный метод проверки для API (самый простой способ, потому и заявленный. Это обычное чтение таблицы и поля Медка, в котором хранится значение, которое отображается сейчас пользователю галочкой).
3) или доработать сам метод Sender, например добавив ему параметр "ПроверятьДоступностьЭДО" (Истина/Ложь), - если истина, пусть сам проверяет, если ложь, - пусть добавляет как сейчас без проверки.
Судя по тому, что реакция разработчиков нулевая, - вспоминается хорошее выражение "Проблемы индейцев шерифа не интересуют".

[Inkognito]

Продолжаем:
Необходимо или создать новый метод (или доработать существующий метод GetPrimaryReestr()), который позволит получать DataSet не по дате документа, а по дате его регистрации. По аналогии с существующим отбором в "Реестре первичных документов".

[Inkognito]

Продолжаем:
метод GetPrimaryReestr()), необходимо возвращать также ExDocID.
Применение: планируется использовать для проверок и открытия документа в Медке (GetSendSTTByExDocID, GetDocStatus, ShowDocument).
Временный костыль конечно найден, но он неправильный. Необходима реализация со стороны разработчика.

[Белокопытов Геннадий]

Inkognito
Тема с описанными методами передана на рассмотрение и обсуждение в отдел разработки, для внесения необходимых доработок.

[Inkognito]

Продолжаем:
Необходим метод, который присвоит и сохранит ExDocID входящему документу, параметром может выступать Dic_ID датасета GetPrimaryReestr(). Очередной костыль найден в виде чтения/записи таблицы CARD, но он работает нестабильно на больших базах, и в сетевой среде. Необходима реализация со стороны разработчика.

| Показать

П.С. можно напомнить разработчикам о таких достижениях науки и техники, как Skype, личка, телефон, Viber, фейсбук. Вопросы решаются гораздо быстрее и качественнее, когда они обсуждаются и существует feedback (обратная связь). Уже прошло много времени, а обратной связи не было еще ни с одним из моих виртуальных коллег-автоматизаторов 1С, которые обращались с вопросами/предложениями (да, мы держим руку на пульсе современных разработок и делимся опытом постоянно).
А чтобы в бочку дягтя добавить ложку Меда (да-да, вам не послышалось), - лично обещаю большую мясную пицуу и ящик пива тому специалисту-разработчику, который наконец-то займется интеграцией 1С + мое радушие на просторах соцсетей

[Inkognito]

Продолжим:
Необходим метод получения даты отправки документа (выделено зеленым):


Будет использоваться так:
если контрагент не прореагировал на отправленный первичный документ (Акт, Счет) в течении Х дней (разница текущей даты и полученной новым методом), - извещаем пользователя и принимаем организационные меры для недопущения повторения ситуации. Как видим, двое контрагентов подтвердили (скажу больше, - в течении 10 минут после нашей отправки документов), а другие несколько дней не могут кнопку нажать.

| Показать

П.С. автоматизация в Украине происходит не благодаря разработчикам Медка, а вопреки. "И все же она вертится!" (с)
Интересно, сколько будет продолжаться такое отношение к своим клиентам? Вчера общался с коллегой из Америки, говорит у них бы уволили за такое отношение к своей работе. А у нас как в том анекдоте про инженеров, разрабатывающих Запорожец - "Говорил я тебе, что место гиблое, а ты мне - .... "
Ты разработчика видишь? - Нет! - А он есть! (с)

[Inkognito]

Продолжим:

Необходимо доработать метод GetPrimaryReestr(), который возвратит поле даты "Отримано".
Необходимо для корректного перенесения этой даты в 1С:

[Inkognito]

Геннадий, напомните пожалуста специалисту, что проблем из-за некорректных методов, или неполного их описания, - очень много.
Сегодня 20е, я с главбухом ищем среди тысяч НН причину, почему выгрузка с медка не работает. Одной из причин является дублирование.
Два одинаковых документа имеют код статуса=0, а в Медке статус пишется "Відхилено" и "Отриманий". Вопрос открытый: нужна расшифровка этих кодов. Сейчас создается впечатление, что или разработчик неправильно определяет статус, или неправильно назвал поле. В любом случае это ненормально.
П.С. на конференцию записался.
Ой потираю руки когда спросят в конце о Вопросах... Надеюсь она будет двусторонней.
Их есть у меня вагон и маленькая тележка....

[fruckt]

Продолжим:

Необходимо доработать метод GetPrimaryReestr(), который возвратит поле даты "Отримано".
Необходимо для корректного перенесения этой даты в 1С:

Поддерживаю 100%. В инструкции "Взаємозв’язок облікових систем і M.E.DOC IS за допомогою методів COM" указано, что "У відповідь повертається об’єкт таблиця із полями. <Тип документа> = Reestr.Fields.Item("Receptdate ").Value;", но такого поля как "Receptdate" нет - соответственно ошибки обработки.