Заимствование чужих идей для улучшения систем : КИС Lack & УС Land

Привет.

Андрей, перенос остатков между местами хранения одна из стандартных задача на заполнение складских документов. Например, в Купце создаем накладную на перемещение, указываем откуда и куда, жмем Обработка-Заполнить по остаткам, ОК, Утвердить документ. И все.

Тот подход, который ты описал и если я все правильно понял, является очень удобным инструментом, но применяется в несколько других контекстах, обычно при создании документов на основании каких-либо сводных отчетов. Наиболее распространенный случай - это подготовка заказов поставщикам. Формируем итоги по движению и остаткам товаров, закупавшимся у нужного поставщика, дополняя их общими итогами, т.к. товар может закупаться у нескольких разных поставщиков. Затем напротив каждого товара вводим, сколько хотим заказать. Или вначале формируем автозаказ, а затем корректируем, если нужно. Проверяем, жмем Создать документ заказа.

Добрый день Вячеслав!

Что'ж более простое решение, чем есть у меня... Но в "чистом" виде данная задача встречается крайне редко за исключением извращений с передачей товара в прилавочной торговле, но у меня это отдельная операция. Если обратили внимание, то описал стандартизованную технику при помощи которой по произвольным складам и отобранным товарам можно создать товарные операции любого типа (в частности межсклад)

Ну в УС Лэнд нет операций (документов) типа "заказ у поставщика" и тем более отслеживание прохождения заказа - всё же ориентируюсь на малый бизнес, где это без надобности?

А помошники заказчика - построение табличек с уходом, остатком, факультативно приходами за период... заполнение колонки заказ с пересчетом сумму, веса, объема заявки и просто печать данной "бумажки", в крайнем случае сохранения её в txt OR pdf

Изначально документ заказ поставщику был введен для оптовки. Когда оператор выписывает товары, то в отдельной колонке видит дату планируемого прихода товара. Щелкает по ней, видит все заказы (дату заказа, дату планируемого прихода, плановую цену закупки) и может информировать покупателя.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.

Извини Вячеслав (=

Сейчас проходит "алкогольный" дурдом и просто физически нет времени разговаривать до 21.10. Мысли у тебя очень интересные, но и у меня по этим вопросам есть "своё" решение... но познее...

Добрый день Вячеслав!

Примитивизм - кредо системы "УС Land"! Как следствие так же решается и данная задача.

Для этого используется "хранилище виртуальных объектов", а попросту информация в основании или системной метке приходной накладной - пометки: товар в пути и заказанный товар, а так же особенность приходных накладных - пока она не распределена на склад нет операций и изменений в "расчетах" (когда распределится - появятся реальные остатки программа эти маркеры будет игнорировать).

Есть отчет "аналитика/специализированные/глобальные остатки на текущий момент". Появляется форма запроса для извлечения нужной инфы и анализу маркеров:



Строится отчет, где одновременно отражены "остатки" товаров: реальные, в пути, заказанные с пометками о сроках доставки.

Это ИМХО узкоспециализированная задача, которую решить конечно можно, но реальных заказчиков на схожие задачи не было. Отмечу, что мебельное производство действительно сложное для автоматизации, зная об этом даже на уровне продажи мебели... а там только комплектация/разукомплектация... и отмечу, что для "Купца" это действительно реальное конкурентное преимущество!!!

Модуль для мебельного производства в Купце присутствует чисто из политических соображений. Я не планирую его дальнейшее развитие. Чтобы получить конкурентную систему в этой области, нужно встраивать элементы кад (раскрой и визуальное проектирование интерьера). Год назад я провел экспериментальные работы в этом направлении, в результате которых был разработан ряд библиотек. Но затем заморозил, т.к. перспективы тиражирования невелики, а необходимый объем инвестиций от действующих клиентов привлечь не получается. Сейчас этим модулем пользуется одна фабрика (примерно 50 рабочих мест, включая салоны). Работаем в режиме поддержки, иногда что-то заказывают дополнительно.
Кроме мебели, в Купце есть функционал для продуктового производства, многопередельного швейного производства и позаказного производства натяжных потолков. Они также мало развиваются, но хорошо вписываются в общую систему, логически закончены и компактны (в отличии от мебели).
Основное направление в Купце - это оптово-розничная торговля. Тема довольно обширная, исторически специализация - товары для дома (хозяйственные товары, отделочные материалы и т.п.) и продукты питания (бакалея, мясопродукты и т.п.).

Вот "свежайшее" например... В ответ на презентацию возможностей системы в плане контроля ведения атрибутов товаров и клиентов Проверки реквизитов для и не только уважаемый KirillHome задал "невинный" вопрос В принципе данные проверки появились недавно, да и совсем "не по ГТД"... Правильность занесения данного атрибута товара тоже никого "не парила" - ну вводили операторы набор цифорок из счетов-фактур поставщиков, ну переносились эти цифорки в отгрузочные/возвратные накладные - всех устраивало.

Почему-то захотелось разобраться в данной "теме" - какова структура номера ГТД? Нашел вариант, реализовал тестирование в программе, вывалилось куча ошибок пользователей, начал копать дальше - вроде бы разобрался... подробнее в упомянутой теме.

Проверил - есть, правда мало ошибок, но во всех доступных мне базах. Решил проверить в доступной мне 1С:Бухгалтерия 8.2 - пропускает ГТД неверной структуры.

В общем внес данный функционал (проверки корректности структуры ГТД) в систему, авось когда-нибудь, кому-нибудь он и сгодится?

Мы писали, мы писали, наши паль....

Ещё раз прочитал тему: Супермаг состав товара в ценнике и подумал, а чё? Ситуаций когда требуется вести и отражать некую информацию о товаре, в частности состав товара/изделия возникает во множествах бизнесов, а УС Лэнд данной техники (в упрощенном виде) не имеет - непорядок. Замечу, что в свете начального вопроса всё давно решено.

Подумал, как можно сделать данную технику наиболее универсальной, а учитывая, что всё равно "сломал" всю структуру базы системы - полем больше или меньше, без разницы... Приступив сегодня к переделке программы "ценники" вспомнил об этой задачке, подумал маленько и чего-то "наделал":

1. В прогу перевода версий добавил ещё один обработчик; в настройках полей экранных форм справочника товаров добавил исключение;

2. В форму добавления/изменения справочника товаров добавил ведение этого нового поля с примечанием по его заполнению: блоки разделенные (;) должны отражаться на отдельных строках. Получилось:



3. Внес изменения в программу ценников: ведение нового поля, обработчик его импорта для разделения по строкам, добавил (пока) новый 31 формат ценников, который выглядит:



В каких случаях эта хрень может быть полезна?

1. Конечно ценники общепита с перечислением продуктов, каллорийности и т.д.;
2. Одежда для отражения состава тканей;
3. Сложная бытовая техника и компьютеры для отражения конфигурации;
4. Для предупреждения о чём-то покупателей, что частенько понуждается госорганами регулирования... и куча других нюансов... Ждите версию 1507 - когда-нибудь она будет доделана

Сейчас посмотрев блог разработчика наткнулся на тему: http://olegon.ru/showthread.php?t=23997 и не понял "в чем проблема"?... и особенно для программы заточенной под опт и производство...

Продажа в "под запись" или "в рассрочку" - элементарно в "УС Лэнд": просто на чеке (накладной) указываете отсрочку платежа и гасите его в течении длительного периода любыми суммами, а программа контролирует этапы (платежи) и текущие, в том числе просроченные долги покупателей

Привет, Андрей.
В блоге речь шла про программу ФинСофт:Магазин. Это старая программа для организации розничных продаж в территориально удаленных местах. Основная ее фишка в том, что все максимально упрощено и продавцы что-то сломать или накосячить практически не могут. То есть что-то напоминающее УКМ, но с несколько иной заточкой функционала. Работает в связке с бэком, в котором реализуется полноценный учет.
В Купце, конечно, есть весь функционал и можно работать напрямую через удаленные подключения через интернет. Но бывает не всегда удобно. Для таких ситуаций и приспособлено - в точке продаж запускаем небольшую не убиваемую программу и обмениваемся с ней данными на уровне простых текстовых файлов. В этом случае КупецЪ выступает как бэк.