Почему Диадок списывает документы по тарифам EDI и как это исправить?

Программист IT и автоматизация бизнеса
← На главную

При работе с экосистемой "Контур" можно столкнуться с неприятной и неочевидной ситуацией: вы отправляете документы контрагенту через API "Контур.Диадок", но в счете видите, что тарификация прошла по завышенным ценам "Контур.EDI". Оказывается, это может произойти, если у вашего контрагента есть личный кабинет в EDI, даже если вы не обмениваетесь с ним EDI-сообщениями. Первая мысль — попытаться автоматически определять таких контрагентов, чтобы прогнозировать расходы. Однако, как показывает практика, корень проблемы лежит совсем в другой плоскости.

В этой статье разберем, почему попытка решить задачу через API обречена на провал и в чем заключается настоящее, административное решение этой проблемы.

Попытка технического решения: идентификация контрагента через API

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

Идея заключалась в следующем:

  1. С помощью API Диадока получить идентификатор организации контрагента. Для этого можно использовать методы GetOrganization (по ID ящика) или GetOrganizationsByInnKpp (по ИНН/КПП). Эти методы возвращают внутренний идентификатор участника ЭДО в системе Диадок, часто называемый BoxID.
  2. Далее, используя полученный ID, обратиться к API Контур.EDI, а именно к методу GetPartyInfo, чтобы получить информацию об участнике в EDI-системе.

К сожалению, этот путь ведет в тупик. Как выяснил автор исходного вопроса, идентификаторы в "Диадоке" и "Контур.EDI" — это разные, не связанные напрямую сущности. BoxID из "Диадока" не будет найден в системе EDI, так как там используется своя система идентификаторов (например, GLN, но не только).

Причину этого несоответствия легко понять, если вспомнить о назначении систем:

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

Настоящая причина и правильное решение: настройка основного лицевого счета

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

Разберем ситуацию по шагам. Когда организация подключает и "Диадок", и "Контур.EDI", для нее могут быть созданы два отдельных лицевых счета для оплаты услуг:

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

Решение, к счастью, очень простое, хотя и не очевидное:

  1. Свяжитесь с технической поддержкой "СКБ Контур". Не пытайтесь найти настройку в личном кабинете — скорее всего, у вас не будет к ней доступа.
  2. Опишите проблему: "При отправке документов через Диадок некоторым контрагентам происходит списание средств по тарифам EDI. Просим проверить настройки наших лицевых счетов".
  3. Попросите установить лицевой счет "Диадока" в качестве основного. Специалист поддержки должен понять вашу просьбу и выполнить необходимую настройку на стороне "Контура".

После того как лицевой счет "Диадока" будет установлен как основной, все документы, отправленные из "Диадока" (через веб-интерфейс, модуль 1С или API), будут корректно тарифицироваться в соответствии с вашим тарифным планом "Диадока", независимо от того, есть ли у получателя аккаунт в "Контур.EDI".

Эта ситуация — яркий пример того, как сложная техническая проблема на самом деле оказывается следствием простой административной недоработки. Прежде чем вкладывать ресурсы в разработку сложных обходных путей, всегда стоит сначала обратиться в поддержку и уточнить все детали, связанные с тарифами и настройками аккаунта.

← На главную