Цитата:Я так понимаю решения для моего вопроса в ТЦУ нету потому никто и не отвечает?
Будьте терпеливы. Вам не отвечали по той простой причине, что мы сейчас загружены по пилотному запуску TCU Mobile 3 под Android, это всегда самый сложный период, идет куча мелких доработок.
Мы стараемся отвечать на все вопросы.
Начну с того, что мне понятно, и соответственно, на что проще ответить.
Цитата:4) И еще один вопрос: у нас используется "депозитная" система: клиент может внести энную сумму себе на "счет", и забирать товар по цене со скидкой пока не закончится сумма депозита. Как правильно это организовать? Просто сделать приходный кассовый ордер на сумму депозита? А для расходных накладных получается оплата не нужна будет? Или нужно их оплачивать формально с суммой "0" ?
В карточке клиента поставьте галку ограничение задолженностри по сумме и сумму пропишите нулевую. Если вдруг вы допускаете, что клиент может несколько перебрать товар и уйти из состояния депозита в состояние кредита, значит поставьте ту допустимую сумму кредита, которую сочтете нужным.
Цитата:5) Не совсем понял - после создания расходной накладной на основании заказа и оплаты ее - сам заказ разве не удаляется автоматически? То есть как в списке заказов видеть какие заказы уже отгружены, а какие нет?
Цитата:Блин, и заказы по которым уже созданы расходные накладные и за них уже расчитались - никак не отличаются от только что созданных (забронированных) заказов?
Растолкуйте, пожалуйста, почему заказу автоматически не ставится статус обработан или отгружен или оплачен и почему это даже вручную сделать нельзя?
1. Как я уже писал, заказ нельзя оплатить. Заказ декларативный документ. А оплатить можно только документ, отражающий передачу ценностей, в нашем случае расходную накладную.
2. Заказ никак не привязывается к накладной. Наоборот, накладная которая создана из заказа имеет на него внутреннюю ссылку. Но эта ссылка носит исключительно информативный характер.
После того, как в ТЦУ1 мы реализовали систему отслеживания заказов и убедились в ее практической непригодности ввиду сложности взаимодействия с оператором, в ТЦУ2 и ТЦУ3 решено было ограничить функционал только сохранением заказов и постановкой товаров по заказам в резерв.
Объясню, какие трудности вас подстерегают, если бы такой функционал существовал.
Опишем типичные ситуации.
1. Товар в заказ принят, но товар отгрузить не смогли (по разным причинам, например, подвел поставщик).
2. Товар в заказ принят, но потом передоговорились и в накладную включили товар-замену.
3. Товар в заказе не отражен, но в накладную был включен (по результатам последующей договоренности (в общем-то частный случай пункта 2).
4. Клиент отказался от части товаров из заказа, и в накладную попали не все товары.
5. Цена товара изменилась, и вы не можете обеспечить цену, указанную в заказе.
6. Один заказ, а удовлетворялся несколькими накладными.
7. Несколько заказов отгружены по одной, объединенной накладной.
В каждой ситуации сумма накладной может отличаться от суммы заказа. Как в этом случае осуществлять привязку?
Как отслеживать цепочки?
Это просто нереальная задача. Пользователь, конечно же, хочет иметь такой классный и универсальный инструментарий. Но его практическая реализация упирается в огромное количество формальных правил, которыми этот функционал описывается. Практической пользы от такого сложного инструмента немного. Поигравшись, пользователь его забросит.
Мне кажется, что при работе с заказами нужно отталкиваться не от заказанных товаров, а от реально отгруженных. Мало ли что клиент может заказывать. Вы не всегда сможете ему эти товары обеспечить.