Андрей Николаев, имелось ввиду "ошибка" в необходимости ставить палгины на браузеры, отказ от мобильного приложения. Все это вполне будет работать. Просто поправить одну строчку в коде виртуальной атс. Не больше, не меньше. Если бы АТС была бы на php то строчка выглядела бы так:
Просто нужен специалист, который найдет где идет инициализация звонка и вставит подобный код на языке, что написана АТС. Хотя... на другом языке возможно это не одна строчка :)
Ошибаетесь. Сейчас лиды передаются по API с сайтов, соцсетей, партнерки и т.д. в облачный битрикс. Никто не мешает в скрипте добавить замену телефонов на +7 000 000 00 01, где последняя цифра - ID во внутренней БД, а какая-то телефония с открытым кодом перед совершением звонка будет подменять телефон на тот, что будет извлекать из БД. Логи, записи разговоров и другая информация так же останется в битриксе и телефонии с номером +7 000 000 00 01.
Нужен совет какое ПО переписать и кто этим смог бы занятся (какой стек), чтобы выставить ТЗ на бирже.
На vc видел эту статью уже давно, но она для коробки, у нас облако. Там ничего не поменяешь. В целом идея с подменными хорошая, но нужно переделывать атс, которая будет их адекватно конвертировать. А к чему подключаются эти атс, что вы предложили, как в конечном итоге они выходят на мобильную связь?
file1.php
<?php
if (a=1) incluide 'file2.php';
incluide 'file3.php';
file3.php
<?php
debug_backtrace();
в этом случае я не увижу в трассировке file2.php
если написать скрипт, который пройдется по всем файлам из выдачи debug_backtrace и соберет там все incluide то скрипт не сможет корректно интерпретировать их в файлы, т.к. в названии будут переменные и не сможет узнать какие запускаются исходя из функций/условий/переменных которые стоят перед ними.
d-stream,
Было ТЗ о необходимости видеть остатки в разрезе по номенклатуре от многих пользователей.
И функции складского учёта добавились в текущую CRM
d-stream,
может мне сохраняя продажу нужно находить в некой буферной таблице(ах) партионного учёта последнюю партию закупки по каждой из номенклатур в текущей продаже и генерить новые строки с новыми объединениями в партии покупок, начиная с последней учтеной и текущей продажей?
А уже на странице генерации остатков обращаться только к одной\двум таблице партий и считать по ней\ним
1. 2. Остатки считаются партионно циклом по каждой номенклатуре. Способ проще пока не удалось найти. Т.е. если в магазине 100 видов товаров, то будет 100 запров к таблице продаж и 100 к таблице закупок.
Ну и если остальные страницы генерятся делая 10 запросов, не сложно предположить, что 200 запросов - узкое место. Замеров пока не делал, т.к. что тут что-то не так с кодом очевидно, но упростить его пока не получилось.
3. Пока работает в тестовом режиме, поэтому не могу предсказать реальные нагрузки после начала продаж. Поэтому и хочу на этом этапе архитектуру сделать нормальную.
5. Индексы есть.
Пересчет планировался делать не сложением остатков по каждому месяцу, а просто взять остаток на последний рассчитанный месяц (накопительный с начала времён) и добавить за текущий не полный. Большинство запросов на текущую дату. Ну а если попадется запрос на старую дату, то пустить по текущему коду.
d-stream, как я понимаю запрос считает по некой incomes.price
Скорее всего это не цена только последних партий в количестве остатков, включая неполную пограничную партию.
Как я понимаю посчитается не остаток количества * цену каждой оставшейся партии, а разница между суммами закупки и продажи в разрезе номенклатуры.
Для подсчёта количества мне это идеально бы подошло, сейчас делаю циклом по номенклатуре, а ваш запрос позволяет уйти от него.
Как я понимаю посчитается не остаток количества * цену каждой оставшейся партии, а разница между суммами закупки и продажи в разрезе номенклатуры.
Для подсчёта количества мне это идеально бы подошло, сейчас делаю циклом по номенклатуре, а ваш запрос позволяет уйти от него.
Хотелось бы партионный учёт, но в голову приходит только вариант с мнооожеством sql запросами в цикле
Select nomenclarure_id по приходу
Далее в цикле по каждой номенклатуре находить количество расхода
далее делать запрос на выборку последних партий из прихода на остаток, складывать в цикле все партии кроме последней умножая количество на сумму,
Последнюю партию, т.к. она может быть не целой считать пропорционально остатку.
Получается количество SQL запросов минимум = количество номенклатуры * 2. Хотелось бы меньше...
У маленького магазинчика 100 товаров, это уже 200 запросов. Придется городить Ajax, чтобы не вылететь по таймауту
Gansterito,
Личный кабинет у провайдера есть?
нет
Прямой договор с провайдером есть?
да
Звонки хотите получить напрямую от провайдера или можно через Битрикс?
непринципиально
Константин Цветков, нет - к шапке
03.01.2000 яблоко 1 шт 10р = 10р, оплата 50р
03.01.2000 груша 2 шт 20р = 40р, оплата 50р
поэтому в этой строке в цикле выводится одинаковая оплата (общая)
в центральном офисе админ сливает воедино дампы БД принесенные на флешках с филиалов в единую БД и заливает им обратно уже объединенные и они с ними едут домой и там объединяют со своими, чтобы новая номенклатура/контрагенты были общими...
1. так отключение перехода должно было бы быть только в случае успешного выполнение условия и e.preventDefault(); добавлено внутри if
2. код с e.preventDefault(); вначале функции - так же не работает. просто осуществляется переход по ссылке.
Просто нужен специалист, который найдет где идет инициализация звонка и вставит подобный код на языке, что написана АТС. Хотя... на другом языке возможно это не одна строчка :)