Модуль интеграции 1С: СДЭК, IML и почта России

Когда бизнес использует различные службы доставки – это хорошо. Современно, клиентоориентированно, надежно. Доставка работает, клиенты радуются удачной покупке, прибывшей вовремя с приветливым курьером.

Но чем это оборачивается бизнесу? Давайте взглянем на это с обратной стороны.

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

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

Кто-то может принимать деньги за товар – иной такой возможности не имеет. У каждого свои требования к маркировке и сопровождаемой документации. Есть различия в личных кабинетах, особенности оформления грузов и предоставляемой отчетности, и много-много всего остального. Кстати, возвраты также никто не отменял. И с ними тоже надо работать: принять товар, распаковать, положить на полку и оформить в базе.

Уследить за требованиями курьерок и прочих доставщиков исключительно силами сотрудников нереально. А еще и малоэффективно. Благо, все это можно автоматизировать.

Модуль интеграции 1С

Был сделан специальный модуль 1С для клиента. В нем объединена интеграция с такими популярными сервисами как СДЭК, IML – это служба доставки для интернет-магазинов – и почтой России.

Давайте посмотрим как подойти к процессу производства решения:

1. Завести специальную электронную почту. Раздать ее всем службам доставки и только им, чтобы исключить любую возможность спама.
2. Договориться, что именно на эту почту будут направляться документы по обработанным доставкам.
3. Научить 1С автоматически «смотреть» эту почту на предмет поступающей информации, различать эту информацию и автоматически загружать в базу правильным образом.

Всего три пункта автоматизации, а какая экономия трудовых ресурсов!

Как устроен бизнес-процесс доставки?

Все доставщики работали с клиентом по агентской схеме. То есть за счет заказчика и по его поручению оказывали услуги по доставке товара третьим лицам – клиентам заказчика. Агентов было три: Почта, СДЭК и IML. Выполнив заказ, они присылали клиенту отчет о проделанной работе, с указанием своего вознаграждения, которое надо учесть при совместных взаиморасчетах. У каждого, естественно, свой формат отчета.

Вот, например, кусок отчета от СДЭКа:

А вот отчет от IML:

Разные данные, разные форматы, разная структура – вот что их объединяет.

Почта вообще шлет данные в формате *.DBF :)

Про интеграцию 1С с почтой России стоит рассказать отдельно

Заказы через почту отправляются через стороннее лицо, которое упаковывает заказы и отправляет их на почту. Далее подготавливает отчет об отправленных заказах, с присвоением каждому из них номера отправления в базе почты (ШПИ).

В данном отчете важными реквизитами, являются:

• №счета – это № заказа в 1С;
• ШПИ – номер отправления в базе почты.

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

Отчеты от почты, как я уже писал, приходят в формате DBF. В них представлена информация о передаче товара клиенту. Основная информация из этого отчета, это:

• MSG – ШПИ или номер отправления по базе почты.
• PAYSUM – сумма наложенного платежа.

Получается, что за счет номера ШПИ можно из одного отчета получить номер заказа, а из другого – сумму, оплаченную по нему.

Данный отчет нужен, чтобы раскидать поступившую сумму в 1С, согласно заказам. И все это, по условиям агентской схемы, должно загружаться в документ «Взаимозачет задолженности», в следующем формате:

В поле «Объект расчетов» необходимо найти и подставить заказ клиента, в графу "сумма взаиморасчетов» – сумму оплаты, "валюта взаиморасчетов" по умолчанию RUB, а реквизиты «Сумма (регл.)» и «Сумма (упр.)» – аналогично сумме оплаты.

Бывают случаи, когда ШПИ (MSG) на стороне отчета почты не заполнен или обрезан как-либо, что не позволяет сопоставить его. Тогда, все равно, надо создавать строку в документе «Взаимозачеты задолженности» с пустым значением в графе «объект расчетов», но с заполненным значением суммы. Чтобы выходила ошибка при проведении, о том, что платеж не сопоставлен.

Также есть ШПИ (MSG) без приставки "RPO =", но с верным номером, в таких случаях заказ надо все равно находить.

Про СДЭК и IML

Заказы через СДЭК отправляются напрямую – сопоставлять, как с почтой, ничего не надо, но есть другой нюанс. В этих отчетах иногда проходят сторнированные суммы. Они не влияют на сумму платежа, но сначала операция полностью минусуется, а потом снова плюсуется с другими данными услуг СДЭК.

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

В случае СДЭК и IML данные просто загружаются в документ «Взаимозачет задолженности», а 1С как-то для себя отмечает, что уже загрузила данное письмо и повторно его грузить не надо.

У IML тоже возможны сторнированные суммы. Ну и, конечно, у них свой формат файла.

Как должен работать модуль интеграции 1С?

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

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

Как это должно происходить:

• Админ открывает специальную обработку, и видит список необработанных ошибок.
• В описании он видит документ, письмо и загружаемый файл. Открывает их и проверяет, что там не так.
• Сопоставляет руками данные и нажимает на ошибке «Обработано».
• После этого ошибка перемещается на закладку обработанных.

Что надо было учесть?

1. 1С должна понимать, что за агент ей написал. Делать это надо по почте отправителя. Настройки эти, для удобства, должны быть в обработке, чтобы их можно было менять. У одного доставщика может быть много почт.
2. Если агента определить не получилось, надо выдавать ошибку и тоже отправлять письмо админу. Почта админа тоже должна быть в настройках.
3. В целом надо было сделать красиво и удобно, чтобы, в идеале, про эту обработку не вспоминали никогда, а только видели новые взаимозачеты и радовались.
4. Нужна возможность вручную файл загрузить, если у фонового задания что-то пошло не так. Для этого понадобится ручной выбор платежного агента на форме.

Как в итоге выглядит модуль интеграции в 1С?

Написали обработку, которая умеет работать «по кнопке» и по расписанию:

По кнопке обработка выглядит так:

Можно зайти в историю и посмотреть ошибки загрузки. 1С помнит их.

Ручную загрузку тоже сделали, но особо она не пригодилась. Мы больше использовали ее для тестов, но решили оставить на всякий случай и для клиента.

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

На электронный адрес администратора отправляются все ошибки по загрузке. Выглядит это примерно так:

• Учетная запись отправки почты – это учетная запись 1С, которая будет отправлять письма администратору.
• Интервал проверки (дней) задает количество дней, за которые анализируются письма. Нужен для того, чтобы не загрузить из почты файлы с момента заведения этой почты. Писем старше указанного количества дней для обработки не существует.
• Данные для заполнения документов – реквизиты, которые подставляются во взаимозачеты задолженности.
• В табличной части указываются адреса электронной почты, по которым мы понимаем, какая из служб доставки нам написала и номера колонок для загрузки.

Все обработанные входящие письма помечаются:

Если вдруг требуется повторно загрузить письмо – просто ставится значение «Нет».

Созданные взаимозачеты:

Взаимозачет внутри:

Вы можете заказать такой же или похожий модуль интеграции для себя

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