В последнее время, с выходом последних обновлений БУС, стало поступать очень много сообщений о том, что обмен с 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) Менеджер отправляет товар и делает реализацию.
БУС + УНФ 1.6 Во всех вариантах 1С главная и продавец работает в ней, по крайней мере большую часть. Что-то на данный момент, к сожалению, приходится делать через сайт (касательно трек номеров=идентификатор отправления, отмены заказа и блокировки статусов, оплаты, отгрузки)
1 вариант 1) покупатель оформляет заказ на сайте с забором в розничном магазине 2) заказ попадает в магазин, в 1с меняется статус, что готов забирайте 3) покупатель приходит в розничный магазин 4) продавец отменяет расходную накладную, пробивает чек ккм, меняет статус заказа на завершен
2 вариант 1) покупатель оформляет заказ с доставкой в пункт выдачи (оплачивает на сайте в 1с это приходит или потом при получении) 2) продавец передает заказ в курьерскую службу, которая присваивает ему свой номер (трек номер) и отвозит на пункт выдачи 3) заказ попадает в пункт выдачи, в 1с меняется статус, что готов забирайте и отправляет трек-номер 4) покупатель приходит в пункт выдачи, называет трек номер службы доставки и оплачивает, если он не был оплачен 5) продавец видит выполненный заказ в ЛК службы доставки и меняет заказ на завершенный. Если был оплачен при получении делает у накладной поступление на счет, т.к. курьерская служба переведет деньги на счет
3 вариант 1) покупатель оформляет заказ с курьерской доставкой (оплачивает на сайте в 1с это приходит или потом при получении) 2) продавец передает заказ в курьерскую службу, которая доставляет заказ покупателю 3) продавец в 1с меняется статус - доставляется 4) курьерская служба доставляет заказ, покупатель оплачивает, если он не был оплачен 5) продавец видит выполненный заказ в ЛК службы доставки и меняет заказ на завершенный. Если заказ был оплачен при получении делает у накладной поступление на счет, т.к. курьерская служба переведет деньги на счет
4 вариант 1) покупатель оформляет заказ с доставкой почтой россии и оплачивает заказ 2) продавец передает заказ в курьерскую службу, она отвозит на почту, где присваетвается трек номер 3) продавец меняет статус заказа на "доставляется" и вводит трек номер чтобы покупатель мог отслеживать номер 4) через какое-то время продавец сам отслеживает трек-номер почты и когда заказ получен, ставит завершен в 1с
5 вариант 1) покупатель оформил заказ 2) продавец оформил это в 1с 3) покупатель не забрал заказ в магазине в указанные сроки или не получил его службой доставки 4) продавец отменяет расходную накладную и ставил в 1с отмену заказа
Сейчас 2017 год, время замены людей роботами или максимальной автоматизации и эффективности. Поэтому у нас в компании нет отдельной девочки бухгалтера. Этот тренд будет усиливаться. Весь учет в 1С, который нужен только в управленческом виде, ведет большей частью менеджер по продажам по своему направлению. В том числе по этой причине он мобильный, постоянно на встречах и основным инструментом является не ПК, а смартфон. При этом каждый принимает в день больше 10 заказов по своему направлению и организовывает их отгрузку. Каждый клиент у нас ожидается стать постоянным и уровень сервиса обслуживания высокий. Мы даже значительно доработали мобильное приложение для УНФ, чтобы большинство операций происходило без использования ПК. На поддержку этого подхода мы работаем исключительно в электронном виде и избегая дублирования действий, в том числе на почте при отгрузках - вся информация берется прямиком с 1С или сайта, также поддерживаем автоматизацию смены статусов заказов и корректную и актуальную информацию в кабинетах пользователей на сайте. Однако, т.к. есть риски синхронизации (например, одновременно с мобильного и БУСа что-то приходит, еще и от разных пользователей), то видим самым безопасным сценарием работы с мобильного приложения БУСа - например менять статусы поступивших на карточку оплат или совершенных отгрузок, а также самовывозов в разных гео местах. В связи с этим мы не можем принять так активно навязываемый подход в вебинарах от Юрия Волошина - 1С всегда "папа". Сайт БУСа более mobile-friendly чем 1С в браузере или оставшиеся ограничения мобильного приложения УНФ . Кроме того личные кабинеты пользователей можно поддерживать в порядке только меняя информацию в БУСе. В связи с этим, наш Кейс следующий: 1. Покупатель оставляет заказ на сайте и выбирает форму оплаты: а) Наличными при самовывозе; б) картой на сайте по эквайрингу; в) вне сайта перевод на карту или оплата на электронный кошелек - биткоины, вебмани... г) оплата наложенным платежом при получении товара на почте. 2. Заказ попадает в 1С и в любом случае резервирует товар до момента отмены заказа менеджером, если факт устанавливается во время звонка покупателю. 3. При оплате заказа способами 1. в) Менеджер меняет в БУСе статус Разрешен к отгрузке и создает с проведением документ оплаты с синхронизаций этих действий в 1С. Это может произойти не возле ПК, и должна быть возможность выполнения этих действий с мобильного. 4. Отгрузка а) В конце дня после отгрузки с соответствующим статусом заказов создаются прямо на почте документы Отгрузки в БУС с синхронизацией в 1С. Автоматически меняются статусы заказов и покупателям отправляются трек-номеры для посылок. б) при самовывозе или доставке силами менеджера создаются тотчас же в смартфоне документы Отгрузки и получения Оплаты в БУС с синхронизацией в 1С. 5. Если ранее отгрузка была совершена наложенным платежом, то в момент получения денег на почте или на расчетный счет от почтовой службы, проводятся документы получения Оплаты в БУСе с синхронизацией в 1С. Везде статус переводится в Завершен - в 1С и в заказе для отображения в ЛК покупателей.
Это главное, без отягощения отменами, возвратами, изменениями и дроблениями заказов, программами лояльности и скидками.
Соответствие состояний заказа в 1С и статусов заказа на сайте
Александр Денисюк, практика требует, чтобы на один статус заказа с сайта могло быть назначено несколько состояний заказа в 1С.
Например, 1. "Принят, ожидается оплата" <--> "Ожидается аванс (до обеспечения)" ИЛИ "Ожидается предоплата (до отгрузки)" 2. "Отправлен" <--> "Готов к закрытию" ИЛИ "Ожидается предоплата (до отгрузки)"
Сейчас такое соответствие задать невозможно. Чтобы как-то выкрутиться из положения, можно дублировать статусы (создать новый статус БУС с тем же именем). и задавать им нужные состояния. Но это неправильно и неудобно.
Александр Денисюк, В БУС у заказа есть ответственный. Требуется при обмене передавать на сайт из 1С имя менеджера, который работает с заказом в учетной системе.
Понимаете, люди запускают не только новые проекты, но и делают синхронизацию на уже существующем сайте. В последнем случае нет надобности загружать все имеющиеся (неактуальные) заказы в 1С. Уже есть настройка актуальности выгрузки заказов, но почему-то нет настройки актуальности загрузки заказов с сайта.
Последовательная выгрузка документов отгрузки и оплаты на сайт
Александр Денисюк, В модуле есть возможность Не загружать отгрузку и оплату в 1С. Предполагается, что они будут созданы в 1С и затем переданы на сайт. Но пользоваться этим невозможно.
На практике эти документы создаются не сразу вместе при первом редактировании заказа. Сначала может появиться реализация, а документ оплаты много позже. Тогда мы получаем, что после обмена документ оплаты на сайте исчезнет. И появится он только, когда в базе проведут оплату, а это на практике может происходить до 3 дней и более. А если нет документа реализации при обмене, исчезает отгрузка со стоимостью доставки, что приводит к изменению суммы заказа - это вообще недопустимо.
Поймите, что в жизни документы проводятся последовательно ( с большой разницей во времени), а не все вместе и сразу. Зачем давать возможность Не загружать документы оплаты и отгрузки, если использовать этот режим не удается? Пожалуйста, не трогайте документы заказа на сайте, если в файле обмена их нет. Удаляйте и изменяйте эти документы, когда они появляются в обмене.
Ярослав Лопатин написал: Точка актуальности загрузки заказов
Понимаете, люди запускают не только новые проекты, но и делают синхронизацию на уже существующем сайте. В последнем случае нет надобности загружать все имеющиеся (неактуальные) заказы в 1С. Уже есть настройка актуальности выгрузки заказов, но почему-то нет настройки актуальности загрузки заказов с сайта.
А я вот не пойму. Пока не сделаем Приходный Кассовый Ордер ошибку дает:
Импорт счета и его документов контейнера не возможен по причине отсутствия информации по оплате. Проверьте настройки модуля 1С. Оплата должна выгружаться.
Битрикс24 Облако 1С УТ 11.3.4.103
Это у нас Кредитная схема, то есть когда отправляем наложенным платежом, у нас приходный кассовый ордер создается после получения денег нами.
Ярослав Лопатин написал: Соответствие состояний заказа в 1С и статусов заказа на сайте
Александр Денисюк , практика требует, чтобы на один статус заказа с сайта могло быть назначено несколько состояний заказа в 1С.
Например, 1. "Принят, ожидается оплата" <--> "Ожидается аванс (до обеспечения)" ИЛИ "Ожидается предоплата (до отгрузки)" 2. "Отправлен" <--> "Готов к закрытию" ИЛИ "Ожидается предоплата (до отгрузки)"
Сейчас такое соответствие задать невозможно. Чтобы как-то выкрутиться из положения, можно дублировать статусы (создать новый статус БУС с тем же именем). и задавать им нужные состояния. Но это неправильно и неудобно.
Нужна связть 1 к 1, Иначе при синхронизации документов непонятно будет какой статус подставлять(например из 1С выгружается заказ с статусом "Принят", а у него сопоставление с бусовскими "Принят" и "Обработан", какой для БУСа статус указывать??)
Цитата
Ярослав Лопатин написал: Последовательная выгрузка документов отгрузки и оплаты на сайт Александр Денисюк , В модуле есть возможность Не загружать отгрузку и оплату в 1С. Предполагается, что они будут созданы в 1С и затем переданы на сайт. Но пользоваться этим невозможно. На практике эти документы создаются не сразу вместе при первом редактировании заказа. Сначала может появиться реализация, а документ оплаты много позже. Тогда мы получаем, что после обмена документ оплаты на сайте исчезнет. И появится он только, когда в базе проведут оплату, а это на практике может происходить до 3 дней и более. А если нет документа реализации при обмене, исчезает отгрузка со стоимостью доставки, что приводит к изменению суммы заказа - это вообще недопустимо. Поймите, что в жизни документы проводятся последовательно ( с большой разницей во времени), а не все вместе и сразу.Зачем давать возможность Не загружать документы оплаты и отгрузки, если использовать этот режим не удается?Пожалуйста, не трогайте документы заказа на сайте, если в файле обмена их нет. Удаляйте и изменяйте эти документы, когда они появляются в обмене.
Понимаю о чем вы. Не так давно было выпущено обновление которое исправляет ошибку, когда сумма доставки пропадала, когда из 1С приходит только заказ. По поводу оплат - выгружайте оплаты в 1С, тогда они не будут удаляться на сайте.
Ярослав Лопатин написал: Назначение ответственного заказа и отгрузки Александр Денисюк , В БУС у заказа есть ответственный. Требуется при обмене передавать на сайт из 1С имя менеджера, который работает с заказом в учетной системе.
Вы спокойно можете привязать через свойства заказов в БУС. Т.е. создаете свойство в БУС "Ответсвтенный", делаете список значений = наименованию пользователей в 1С. В настройках 1С указываете, что поле ответственный заполняется по наименованию свойства(имя свойства в БУС). Тогда когда будет приходить заказ с БУС, то будет смотреться значение указанного свойства заказа и по наименованию подставляться ответственный в указанный реквизит заказа.
Александр Денисюк написал: Нужна связть 1 к 1, Иначе при синхронизации документов непонятно будет какой статус подставлять(например из 1С выгружается заказ с статусом "Принят", а у него сопоставление с бусовскими "Принят" и "Обработан", какой для БУСа статус указывать??)
Александр Денисюк написал: Вы спокойно можете привязать через свойства заказов в БУС. Т.е. создаете свойство в БУС "Ответсвтенный", делаете список значений = наименованию пользователей в 1С. В настройках 1С указываете, что поле ответственный заполняется по наименованию свойства(имя свойства в БУС). Тогда когда будет приходить заказ с БУС, то будет смотреться значение указанного свойства заказа и по наименованию подставляться ответственный в указанный реквизит заказа.
В БУС в заказе уже есть поле Ответственный с определенной механикой. Зачем создавать дополнительное поле, если можно использовать заготовленное?
Александр Денисюк написал: Нужна связть 1 к 1, Иначе при синхронизации документов непонятно будет какой статус подставлять(например из 1С выгружается заказ с статусом "Принят", а у него сопоставление с бусовскими "Принят" и "Обработан", какой для БУСа статус указывать??)
Поддерживаю. Т.к. в 1с "состояние заказа" - это динамическая вещь, которая определяется состоянием обеспечения (есть ли на складе, заказано, не заказано, пришло уже на склад..) и типом оплаты (аванс до обеспечения, предоплата до отгрузки, кредит), то по сути значение статуса заказа приходящее из битрикса менять состояние заказа в 1с не должно. А вот в обратную сторону отправлять это значение из 1с в БУС имеет смысл и в этом случае реализовать подобную схему как на картинке выше вполне возможно. Это очень упростило бы работу менеджеров, была бы нормальная актуализация статуса заказа для клиента.