В последнее время, с выходом последних обновлений БУС, стало поступать очень много сообщений о том, что обмен с 1С работает некорректно, не поддерживаются многие кейсы использования.
Можете пошагово описать кейсы, которые Вы используете в обмене между 1С и БУС?
Эти кейсы нужны для: 1) Разработчикам БУС, чтобы понимать глубину проблемы и реализовывать недостающие кейсы 2) Тестировщикам, чтобы тестировать обмен по этим кейсам 3) Юзабилистам, чтобы в дальнейшем сделать настройки обмена по кейсам(выбрал кейс и в БУС и 1С нужные настройки сами установились):
Только кейсы. Остальные сообщения будут удаляться.
Наш случай: 1. В БУС оформляется заказ. 2. Оператор работает только в 1С, при поступлении заказа (в статусе "к согласованию") согласовывает с клиентом дату доставки, указывает её в реквизите заказа "Отгружать одной датой", заполняет обеспечение (резервирует товар), меняет статус заказа на "к выполнению". При этом, отсутствующий товар в заказе отменяется установкой соответствующей галочки. В случае отказа клиента от заказа отменяет все строки заказа, в комментарии указывается причина отказа. 3. В 1С, в день доставки, оформляется оплата (ПКО на основании заказа). 4. В 1С, в день доставки, оформляется отгрузка (РТУ на основании заказа). 5. Отправляется машина для доставки с кассовым чеком и товаром. Клиент расплачивается в момент получения товар 6. По возвращению машины, если деньги за заказ получены кассиром - устанавливается статус РТУ "Реализовано". Если нет - в 1С документы ПКО, РТУ помечаются на удаление, в заказе отменяет все строки заказа, в комментарии указывается причина отказа.
Простые кейсы (варианты отмены- здесь не рассматриваются)(внутренние документы по ордерной схеме 1С не обменивающиеся с сайтом не рассматриваются)
1С УТ11.3 последняя
Кейс№1 "оплата на сайте-доставка клиенту" 1. В БУС оформляется заказ. (далее на любом этапе независимо от оплаты Он может поменяться на сайте. многое: адрес доставки, желаемая дата доставки, некоторые дополнительные реквизиты заказа которые я добавлял) 2. Там же он оплачивается.Автоматически разрешается доставка 3. После обмена в 1С попадают данные этого заказа(если разрешена доставка): Сам проведенный заказ(который резервирует товар), Непроведенная Расходная накладная, Проведенная эквайринговая операция. Сразу же при обмене печатается чек на онлайн-кассе. Оплата соответственно на сайте уже "Оплачено" 4.1 между оплатой заказа и его доставкой может пройти какое-то время 4.2 При выдаче товара клиенту: Проводится Расходная Накладная(у которой дата может быть изменена на реальную дату ) в статусе Реализовано ("отгрузка-отгружена" в терминах БУС) 5. При следующем обмене Расходная накладная попадает на сайт где Собственно отгрузка так же фиксируется. Заказ на обеих сторонах принимает статус Выполнен
Кейс№2 "оплата на пункте выдачи-самовывоз клиентом" 1. В БУС оформляется заказ. (далее на любом этапе независимо от оплаты Он может поменяться на сайте. многое: адрес доставки, желаемая дата доставки, некоторые дополнительные реквизиты заказа которые я добавлял) 2. Клиент при заказе указывает предпочтительную форму оплаты-нал/безнал. 3.Менеджер на сайте принимает решение и разрешает доставку 3. После обмена в 1С попадают данные этого заказа(если разрешена доставка): Сам проведенный заказ(который резервирует товар), Непроведенная Расходная накладная, Непроведенная эквайринговая операция.(ИЛИ если клиент выбрал предпочтительный вариант Оплаты наличными- тогда непроведенный ПКО). 4.При выдаче товара клиенту: 4.1 Если клиент Хочет оплатить указанной ранее в заказе формой оплаты. Тогда проводиться уже загруженная эквайринговая операция. Печатается чек ККМ средствами 1с 4.2 Если же клиент хочет оплатить наличными загруженная непроведенная эквайринговая операция помечается на удаление. И на стороне 1С создается ПКО.далее аналогично п 4.1
4.2 Через несколько минут 10-15 (это важно поскольку в этот момент данные об оплате уже при обмене могут попасть в БУС) клиент получает на товар и проводится Расходная Накладная(у которой дата может быть изменена на реальную дату ) в статусе Реализовано
5. При следующем обмене Расходная накладная попадает на сайт где Собственно отгрузка так же фиксируется. Заказ на обеих сторонах принимает статус Выполнен
более подробные кейсы со всеми возможными вариантами готов предоставить в формате Excel (делал как бизнес процессы с обеих сторон БУС и 1С одновременно). Пишите на почту тогда.vlad_r@mail.ru Не знаю как тут файл прицепить
Вот наш вариант БУС + УНФ 1.6 Вся учетная информация ведется в 1с.
Вариант 1. Розничные покупатели из других регионов. В данном случае возможна оплата только платежной системой. 1) На сайте оформлен заказ "Принят, Ожидается оплата" выгрузился в 1с со статусом "Загружен". 2) Как только человек оплачивает заказ, например через яндекс кассу, в бус приходит галка оплаты, -> печатается чек ккм. Нам в свою очередь выписка с платежами. Менеджер отгружает заказ в 1с, меняет статус на "В работе". Выгружаем из 1с док отгрузки, оплаты и сам заказ покупателя с необходимыми правками. На сайте заказ должен быть в нужном статусе, отгружен и оплачен, без каких-либо "проблем с заказом".
Вариант 2. Оптовые покупатели, разрешена покупка в долг. 1) На сайте оформлен заказ "Принят, Ожидается оплата" выгрузился в 1с со статусом "Загружен". Мы в свою очередь в 1с меняем статус заказа на "В работе", проводим док реализации, оплату не ставим, в бус должен уйти заказ покупателя, с измененным статусом, с отгрузкой, но без оплаты, и никаких проблем с заказом в данном случае опять таки нет. Не нужно удалять документ оплаты из бус. Возможность оплаты заказа, до самого факта его оплаты должна оставаться всегда.
чтоб не получилось в этом случае звонки менеджеру а по какому заказу сколько я должен, зашел - увидел - оплатил.
Через неделю покупатель вносит n-ую сумму денег, и мы закрываем задолженности по этим заказам. Они должны иметь возможность быть оплаченными, даже если уже отгружены, и тем более находясь в финальном статусе. В 1с ведь этот заказ уже закрыт, просто не оплачен. (Кстати, расчет ведь из регистра берется?)
Вариант 3. Продажу в розницу в своем регионе. На сайте оформлен заказ "Принят, Ожидается оплата" выгрузился в 1с со статусом "Загружен". Ждем клиента непосредственно в офисе, он вносит оплату, мы меняем статус документа, проводим оплату, отгрузку. На сайте все отгружено, оплачено, без проблем в нужном статусе.
На данный момент, у меня стоит запрет загрузок документов оплаты из бус. Когда я создаю в 1с новый документ оплаты, он прекрасно уходит в бус, при этом там никаких проблем с заказом нет, и ничего не удаляется. Просто создается второй документ оплаты. Да и черт с ним, заказ ведь оплачен. С отгрузками же иначе, там всегда проблема с заказом. Значит дело в отгрузках. Кстати, как временной решение можно выключить загрузку отгрузок в 1с. В бусе в момент обмена документами родные оплата и отгрузка будут удаляться, а нормальные выгружаться из 1с. https://marketplace.1c-bitrix.ru/solutions/sns.tools1c/#tab-log-link плагин нашел, который за 15 000 решает эту проблему в последних версиях добавили функционал. Надо чтобы было "как то так", но только из коробки)
Александр написал: Наш случай: 1. В БУС оформляется заказ. 2. Оператор работает только в 1С, при поступлении заказа (в статусе "к согласованию") согласовывает с клиентом дату доставки, указывает её в реквизите заказа "Отгружать одной датой", заполняет обеспечение (резервирует товар), меняет статус заказа на "к выполнению". При этом, отсутствующий товар в заказе отменяется установкой соответствующей галочки. В случае отказа клиента от заказа отменяет все строки заказа, в комментарии указывается причина отказа. 3. В 1С, в день доставки, оформляется оплата (ПКО на основании заказа). 4. В 1С, в день доставки, оформляется отгрузка (РТУ на основании заказа). 5. Отправляется машина для доставки с кассовым чеком и товаром. Клиент расплачивается в момент получения товар 6. По возвращению машины, если деньги за заказ получены кассиром - устанавливается статус РТУ "Реализовано". Если нет - в 1С документы ПКО, РТУ помечаются на удаление, в заказе отменяет все строки заказа, в комментарии указывается причина отказа.
1С УТ для Казахстана, версия последняя, 3.1.3.5.
У нас такая же схема работы за исключением того, что документы ПКО мы оформляем по возвращению машины, когда курьер сдает деньги кассиру. Товар заказывается через механизм обеспечения потребностей с конкретным назначение под клиента. Услуга доставки включается в РТУ, акты о выполенных услугах не создаем. 1с УТ 10.3.
На данный момент имеем проблемы с обменом реализаций (отгрузок). После выгрузки реализаций в битрикс на сайте создается новая отгрузка, при этом остается старая, в которой удаляются отгруженные товары, но остается стоимость доставки. Как результат имеем на сайте две отгрузки, в каждой прописана стоимость, что увеличивает стоимость заказа на стоимость отгрузки.
Кейс№1 "оплата на сайте-доставка клиенту" 1. В БУС оформляется заказ. (далее на любом этапе независимо от оплаты Он может поменяться на сайте. многое: адрес доставки, желаемая дата доставки, некоторые дополнительные реквизиты заказа которые я добавлял) 2. Там же он оплачивается.Автоматически разрешается доставка 3. После обмена в 1С попадают данные этого заказа(если разрешена доставка): Сам проведенный заказ(который резервирует товар), Непроведенная Расходная накладная, Проведенная эквайринговая операция. Сразу же при обмене печатается чек на онлайн-кассе. Оплата соответственно на сайте уже "Оплачено" 4.1 между оплатой заказа и его доставкой может пройти какое-то время 4.2 При выдаче товара клиенту: Проводится Расходная Накладная(у которой дата может быть изменена на реальную дату ) в статусе Реализовано ("отгрузка-отгружена" в терминах БУС) 5. При следующем обмене Расходная накладная попадает на сайт где Собственно отгрузка так же фиксируется. Заказ на обеих сторонах принимает статус Выполнен
Кейс№1 "оплата на сайте-доставка клиенту почтой России" 1. В БУС оформляется заказ. 2. Загружается рилтайм в 1С, чтобы товар встал в резерв. Загружаются только эквайринговые оплаты, чтобы сразу проводились (ну и не исчезали с сайта...) (далее может поменяться стоимость товара (предоставление ручной скидки), добавиться товар, удалиться товар или поменяться, измениться способ доставки и ее стоимость) Сейчас в этот момент, если не загружать-выгружать реализацию, то исчезает доставка с ее стоимостью с сайта. Поэтому клиент не может заказ оплатить полностью. 3. Оплачивается на сайте. Автоматически разрешается доставка. Чек печатается с БУС 4. При отгрузке создаем реализацию. Хотелось бы, чтобы на этом моменте она меняла отгрузку в БУС со статусом отгружено.
По сути нужно: если никакая реализация из 1С не выгружается, то на сайте ее не удаляем, если выгружается, то заменяем ту что на сайте из 1С.
Кейс№2 "оплата по квитанции-доставка клиенту почтой России" 1. В БУС оформляется заказ. 2. Загружается рилтайм в 1С, чтобы товар встал в резерв. Загружаются только эквайринговые оплаты, чтобы сразу проводились (ну и не исчезали с сайта...) (далее может поменяться стоимость товара (предоставление ручной скидки), добавиться товар, удалиться товар или поменяться, измениться способ доставки и ее стоимость) Сейчас в этот момент, если не загружать-выгружать реализацию, то исчезает доставка с ее стоимостью с сайта. Поэтому клиент не может заказ оплатить полностью. Сейчас в этот момент удаляется и оплата, клиент не может получить квитанцию с сайта.
3. Оплачивается на сайте. Автоматически разрешается доставка. Чек печатается с БУС 4. При отгрузке создаем реализацию. Хотелось бы, чтобы на этом моменте она меняла отгрузку в БУС со статусом отгружено.
По сути нужно: если никакая реализация из 1С не выгружается, то на сайте ее не удаляем, если выгружается, то заменяем ту что на сайте из 1С. По сути нужно: если никакая оплата из 1С не выгружается, то на сайте ее не удаляем, если выгружается, то заменяем ту что на сайте из 1С.
Самый простой кейс: 1. Клиент оформляет заказ на сайте. При этом заполняет поля: - "Выбор местоположения" (регион - город - населенный пункт) - Индекс - адрес доставки (в адресе доставки, клиент не указывает город и индекс, т.к. это уже сделано) 2. Оператор работает только в 1с. Он согласовывает дату доставки, заполняет обеспечение..., проводит заказ и создает реализацию. 3. Оператору нужно распечатать для службы доставки накладную и задание на перевозку (типовые из 1с), где (по требованию службы доставки) должны присуствовать: Индекс, формализованные данные о нас. пункте в виде: Страна-Регион-Город и далее адрес в свободной форме. 4. После отчета службы доставки создается ПКО и заказ закрывается.
Сложность в адресе доставки, в который попадают данные только из поля "Адрес доставки" из БУС (при этом ведь местоположение и индекс попадают в адрес Контрагента, но не в адрес доставки).
Вот кейс БУС + УТ: 1) Заказ оформляется клиентом в БУС. 2) Менеджер отзванивается клиенту и подтверждает заказ, а также в комментарии к заказу указывает какая организация будет заниматься этим заказом, а также выставляя способ оплаты с реквизитами нужной организации (меняет платёжную систему). 3) Заказ выгружается в 1С по факту присвоения статуса "Подтверждён". 4) Менеджер из указанного города меняет соглашение по заказу на соглашение своей организации и резервирует товар на своём складе. В процессе могут быть изменены служба доставки и способ оплаты. 5) Заказ оплачивается пользователем - квитанция или интернет-эквайринг. 6) По факту поступления денег - бухгалтер производит зачёт оплаты путём создания документа поступления безнала. 7) Менеджер отправляет товар и делает реализацию.