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