Для Компании нужно создать суммирующий Счет за месяц в котором будут суммироваться отдельно оплаченные и неоплаченные Счета, подтягиваться Товары с этих Счетов и выводится долг Компании. Затем с этого суммирующего Счета создаем Документ с подтяжкой всех этих данных и высылаем клиенту. Классно да... Подскажите как это сделать ?
Многоходовочка. Смотря в чем, в облаке или в коробке. В коробке наверное и вопроса бы не было, по расписанию, раз в месяц запускаем задание, лезем в базу и вытягиваем все необходимое. В облаке чуть извилистее путь. Если тариф максимальных, то есть бизнесс-процессы с циклами, потому что без них никак. Если тариф стандратный то есть роботы и умные сценарии.. я бы даже не пытался строить все на действиях роботов стандартного тарифа, а сразу бы запустил локальное приложение и в нем отработал встраиваемые роботы или исходящие вэбхуки. Есть инструмент, с помощью которого можно поддерживать репликацию отдельных сущностей (счет новая версия я так понимаю у вас) и быть свободным в решении вопроса, как рыба в воде.. есть варианты, но они зависят от условий
написал: хотелось бы больше конкретики, если она есть...
ваша задача тянет минимум на 8 часов. То есть вы ищите кого то, кто потратит один день и выложит вам готовый конкретный код? Если вы продвинулись в решении задачи на несколько шагов и застряли на конкретном шаге, то то помощь конечно оказать будет не трудно. Но вы еще даже не продвинулись в вопросе, в каком месте интерфейса вы будете выбирать компанию, для которой нужно провести все необходимое... я могу ошибаться, и извините конечно, но сейчас со стороны самым конкретным вопросом видится такой: " ищу специалиста в написании детального ТЗ к задаче в топике...". И вам обязательно придется провести одну или две конференции с этим специалистом минут по 30 каждая, чтобы уточнить желаемый сценарий реализации ТЗ. Видится со стороны, что все остальное пока преждевременно.
Известно что в "Продажах" битрикс существует два элемента: Предложения и Счета - это здорово.
Предложения - выступают в роли ProForma, и это не бухгалтерский документ. Счет - это уже бухгдок, который создадим и отправим, когда клиент оплатит.
Так вот: - если Предложение одно в месяц, то все ок. Тогда будет и один Счет, который и проводит бухгалтер. Это битрикс умеет. - но если клиенту выставляется несколько Предложений и он их оплачивает (больше десятка у нас), то нужно создать один Счет (суммирующий).
В битрикс не реализовано создание одного Счета по нескольким Предложениям - и это НЕ здорово Похоже писатели не особо консультировались с бухгалтерами... а ведь это основы основ продаж.. зачем клиенту куча счетов в месяц? зачем грузить бухгалтерию лишней работой? итд..
Или быть может я ошибаюсь, и все таки можно как то получить один суммирующий счет ? Подскажите знатоки пожалуйста, ну очень нужно..
в моем облачном битрикс на данный момент через пень-колоду работает так:
- передаю ID Счетов "В работе" и "Оплачен" в соответствующее поле Компании (командой "Изменение компании" БП при создании Счета дописывает его ID, БП при изменении Счета проверяет кучу условий и если действительно Счет перешел на стадию "Оплачено", то "удаляет" его ID из поля "В работе", и дописывает в поле "Оплаченные" (удаления из множественного поля в облачном битрикс не нашел, по-видимому нет такового, потому приходиться перезаписывать итератором старые данные из поля в тоже поле проверяя на совпадение ID. Если ID действительно оплачен, то условие не дает ему перезаписаться в поле.
- менеджер в конце месяца запускает БП из Компании, (указав период в параметрах) который перебирает все ее ID счетов, и создает две Сделки. В одну копирует Товары с оплаченных Счетов, в другую - Товары неоплаченные. Также вписывает номера Счетов в отдельное поле.
- менеджер в каждой Сделке создает Документ типа "Счет на неоплаченные ProForma за месяц" и "Счет на оплаченные ProForma за месяц". В этих документах таким образом есть и суммы, и все товары, и номера ProForma ранее полученные клиентом.
p.s. - да, можно и не передавать ID Счетов в Компанию, но тогда перебор всех Счетов займет прилично времени (у нас их уже 500 за месяц тестирования БП, а как вам известно облачная битрикс циклирует до 1000), да и создавать массив Счетов все равно где то нужно, ведь как указать для БП что ему нужно перебирать... (обратно же нужно еще тот цикл придумать чтоб отрабатывал каждую 1000 по 1000 и затем еще по 1000 итд...) - две Сделки чтоб формировать Документ "Счетов за месяц.." также можно было не создавать вроде как, а создавать в Счетах эти суммирующие Счета. Но тогда выйдет путаница для менеджера - где сам счет ProForma а где суммирующий. Да и старые процессы в Счетах, не правильно работать.
В общем все это муторно и некрасиво и имеет кучу подводных камней (нужно выводить лишние ID из оплаченных, так как будут накапливаться и тормозить БП, нужно учесть все возможности чтоб юзер не сломал работу БП итд..)
Это должно быть стандартным функционалом битрикс как я писал и о чем спрашивал. Создав тему - надеялся что хоть кто то подскажет иной вариант, или функционал, которого я не вижу.
Как же все таки красиво и понятно получить итоговый Счет ??
написал: Предложения - выступают в роли ProForma, и это не бухгалтерский документ.Счет - это уже бухгдок, который создадим и отправим, когда клиент оплатит
Российская практика документооборота немного другая. отдел продаж использует коммерческие Предложения (ProForma) как самостоятельный документ, не входящий в бухгалтерский учет. Он печатает их и "сеет" как хочет. Учета не требует. Счет выписывается, когда возникает реальная возможность продажи. Является бухгалтерским документом, требует учета, выписывается заранее и служит основанием к оплате у покупателя. Естественно и нормально, что 90% счетов могут остаться неоплаченными Счет-фактура выписывается по факту продажи, является бухгалтерским документом, очень важным, поскольку на его основе ведется начисление НДС к уплате.
Судя по описанию, вы используете счет как счет-фактуру. Почему бы нет, так можно, но (!) Описанная вами задача не является проблемой отдела продаж, это проблема бухгалтерского учета и решаться она должна в бухгалтерской программе (1С и прочее). И там в 1С все уже сделано для этого и программировать ничего не надо (ну или совсем чуть чуть). Но тем не менее - CRM не предназначена для решения специфических задач бухучета.
Вы уверены, что выбрали нужное место для решения задачи? Если уверены, то нет ничего странного в тех сложностях, которые вы обнаружили. Будет костыль на костыле. Предполагаю, что у вашей Битрикс максимальный тариф, поскольку встречается слово БП - бизнес-процесс, а он есть только на максимальном тарифе. Вы хотите решить задачу исключительно в интерфейсе Бизнес-процессов, то есть без программирования на node, php etc? Если да, то создавать сделку только для того, чтобы разделить оплаченные и неоплаченные товары - это плохое решение. Если уж совсем никак - создавать эти мнимые сделки нужно в отдельном направлении - "Служебные".
Я вижу такое решение (с программированием):
Идеологически - вся работа со счетами одного клиента ведется из одной сделки. Тогда 1 клиент - одна сделка и в ней много выписанных счетов.
1. У вас есть сайт, значит наверняка есть хостинг. Я развернул бы на нем свое локальное приложение. 2. В качестве предложения для оплаты использовал бы Счет, потому что Bitrix24 дает возможность работать со счетами через АПИ. 3. Используя Lumen + bitrix24api настроил бы репликацию счетов в свою отдельную базу данных. 4. В списке Контактов или компаний или Сделок сделал бы встраивание в меню с вызовом своего локальнгого приложения ИЛИ в карточке Сделки настроил бы вызов умного сценария, который вызывает исходящий вэб хук локального приложения. 5. Средствами php в своем локальном приложении и своей локальной базе счетов выполнил бы все необходимые вычисления и сформировал бы итоговые счета: с оплаченными и неоплаченными позициями, указал бы это в названии счета.
недостаток - счета и итоговый счет будут иметь общую сквозную нумерацию. И это может не устроить бухгалтерию. преимущества - не надо создавать дополнительные служебные сделки и дополнительные служебные поля.