Работы по синхронизации данных с RetailCRM

Парсер статусов Чекаута

1. Читаем почту checkout@istrading.ru на яндексе, пароль *****
Пример парсера почты: /b2c/csv2db.php

2. Парсим по очередности (по мере поступления и непрочитанные) новые письма.

Из писем нам нужны два параметра:
а) Номер отправления по версии СД: joxi.ru/823jREoHwvX5mO
Обычно приходит один раз в одном из первых писем.

б) Статус доставки
в) Дата статуса
joxi.ru/p27LXvPTZaD7A7

Нужны те параметры, которые не зачеркнуты в письме, т.е. новые.

3. Номер самого заказа.
В чекаут передается штука которая называется slug
joxi.ru/RmzgLNZTVBdE2O

В различных случаях формирования заказа она либо частично совпадает с externalID, либо с id.
(в первом случае, если заказ был создан на сайте, во втором – если в самой CRM).
При этом, если заказ для магазина создан в CRM, то его номер потом меняется, появляется externalID, но в чекауте он все равно будет числится под старым номером.

Т.о. делаем следующее.

а) Читаем собственно номер под которым заказ числится в чекауте: joxi.ru/n2Yzqvxt0NRYA6
В зависимости от первых значений номера символьный код магазина:
s2: rps
s4: mp
s37: mn
s39: lend-tea-1
s40: lend-tea-2

Если номер выглядит как c-xxxxx, то заказ создан в админке и хрен знает к какому магазину он по номеру принадлежит.

Собственно принадлежность к магазину нужна нам для формирования запросов.
Можно использовать универсальный ключ АПИ: *****
и добавлять к нему с какого магазина искать заказы, например:
reprisa.retailcrm.ru/api/...

Т.о. если в номере заказа есть указание на магазин (номер формата s**), то при выборке заказа в CRM
мы используем
а) exteranalID (т.к. такой номер может быть присвоен только, если заказ попалв  CRM по апи с сайтов)
б) Собственно сам номер заказа после "s**-"
в) В запросе можем четко указать на то, какого магазина данный заказ.

Если же номер "внутренний", т.е. формата c-***** или иного, то придется делать перебор, я иных вариантов пока не вижу.
Нам не известно под каким ID числится данный номер (внутренний или внешний) и не известно к какому магазину он относится.

Видимо в данном случае придется делать поиск заказа перебором, подставляя в запрос значения внутреннего или внешнего ID и комбинируя их с различными магазинами (site=).
Когда запрос "срабатывает" запоминаем сочетание и уже используем при обновлении данных.
По приоритетам выборке для таких неопределенных заказов: магазины – tea-lend-1, rps, mn, mp, tea-lend-2. Т.е. сейчас почти все "нонэйм заказы" это первый магазин.

4. Собственно передаем в CRM значения для заказа.
Данные добавлять в пользовательские поля:
Номер отправления по версии СД: number_sd
Дата статуса: data_sd
Статус доставки: status_sd


Перевод лендинга по чаям с коллектора на АПИ

Доступ к фтп:
mlnruser.myjino.ru
mlnruser_chai
p********s

theawesomeshop.ru/monchai...

Сейчас заявки с формы падают в ЦРМ через демон Collector.

Нужно переделать на добавление их через АПИ.
Ключ для данного магазина: *****

И сделать нумерацию данных заказов (собственно ради чего все делается, чтобы не было бардака с одинаковым форматом номеров):
51ХХХХ

Счетчик последнего заказа, я думаю, стоит просто вести в текстовом файле. 

******************************
Уважаемые коллеги! В предложении указывайте вашу цену (за проект или час) 
Предложения из серии "от 3 дней от 10000 рублей", молча удаляются, т.к. объем работ мне прекрасно известен.