Тяжелее всего у нас закрывается месяц. Бухгалтер садится сверять отгрузки, оплаты и то, что показывает сайт, и каждый раз находит десятки мелких расхождений: заказ есть в магазине и его нет в учёте, товар давно списан, а на витрине он ещё продаётся, деньги пришли, а отметки об оплате нигде нет. Разбираем это неделю, и половина времени уходит не на исправление, а на выяснение, где именно потерялась строка.
Поэтому прошу построить обмен между магазином и учётной системой. Из магазина должны уходить заказы целиком — позиции, количества, цены и сведения о покупателе, достаточные, чтобы оформить документ, не дозваниваясь до клиента. Навстречу должны приходить остатки и цены, чтобы витрина показывала склад, а не вчерашнее представление о нём. Статусы оплаты и отгрузки нужно возвращать на заказ: это снимает половину обращений в поддержку. Номенклатуру сводим по артикулу, и всё, что не свелось, должно попадать в отдельный перечень с причиной — такие случаи я готов разбирать руками, но хочу видеть их списком сразу, а не узнавать о них при закрытии месяца.
Отдельно оговорю условия, которые считаю обязательными. Обмен работает по расписанию и с проверкой целостности: недогруженный пакет не применяется частично, иначе учёт разъедется, а найти потом точку расхождения будет уже нечем. Доступы к учётной системе лежат вне кода, и в журнал не попадают ни ключи, ни персональные данные покупателей. Запуску предшествует обкатка на копии базы и ручная сверка за один день: пока результат этого дня не сойдётся строка в строку, на боевые данные мы не переходим.
Состав работ, как я его вижу:
— передача заказов с полным составом, суммами и данными покупателя;
— приём остатков и цен на сайт с понятным правилом обновления;
— возврат статусов оплаты и отгрузки в карточку заказа;
— сопоставление по артикулу и перечень позиций без пары;
— правила на случай расхождений и явный отказ там, где решать должен человек;
— журнал обмена, по которому видно, что за пакет, когда и чем закончился;
— кнопка повтора неудачной операции, безопасная к повторному запуску;
— месячный отчёт для бухгалтерии по итогам обмена.
Поэтому прошу построить обмен между магазином и учётной системой. Из магазина должны уходить заказы целиком — позиции, количества, цены и сведения о покупателе, достаточные, чтобы оформить документ, не дозваниваясь до клиента. Навстречу должны приходить остатки и цены, чтобы витрина показывала склад, а не вчерашнее представление о нём. Статусы оплаты и отгрузки нужно возвращать на заказ: это снимает половину обращений в поддержку. Номенклатуру сводим по артикулу, и всё, что не свелось, должно попадать в отдельный перечень с причиной — такие случаи я готов разбирать руками, но хочу видеть их списком сразу, а не узнавать о них при закрытии месяца.
Отдельно оговорю условия, которые считаю обязательными. Обмен работает по расписанию и с проверкой целостности: недогруженный пакет не применяется частично, иначе учёт разъедется, а найти потом точку расхождения будет уже нечем. Доступы к учётной системе лежат вне кода, и в журнал не попадают ни ключи, ни персональные данные покупателей. Запуску предшествует обкатка на копии базы и ручная сверка за один день: пока результат этого дня не сойдётся строка в строку, на боевые данные мы не переходим.
Состав работ, как я его вижу:
— передача заказов с полным составом, суммами и данными покупателя;
— приём остатков и цен на сайт с понятным правилом обновления;
— возврат статусов оплаты и отгрузки в карточку заказа;
— сопоставление по артикулу и перечень позиций без пары;
— правила на случай расхождений и явный отказ там, где решать должен человек;
— журнал обмена, по которому видно, что за пакет, когда и чем закончился;
— кнопка повтора неудачной операции, безопасная к повторному запуску;
— месячный отчёт для бухгалтерии по итогам обмена.
