█ 12.08.2011 13:37
Добрый день!
Как (из-за чего) развиваются системы "КИС Lack" и "УС land"? От куда берутся идеи по их развитию?
I. иногда не "даёт скучать" государство, изменяя законодательство.
II. пользователи просят внести новую возможность.
III. появляется новый класс задач, который требует внести изменения во многие подсистемы пакетов.
IV. Специально или случайно нахожу идеи на форумах или на сайтах производителей программ для бизнеса, которые считаю, что могут быть полезны для большинства пользователей моих универсальных учетных систем.
В данной теме предполагается размещение описаний реализаций данных идей - может быть "воруя" идеи поступаю нехорошо, но это один из путей современного развития. Желающие могут покритиковать идеи, их пользу или подход к реализации, а так же высказать своё "фи" по данному подходу в развитии систем.
Начали... На данном уважаемом форуме был задан вопрос https://olegon.ru/showthread.php?t=10677 о выявлении сочетаемости товаров.
Задача может быть интересной для:
- формирования рекламных акций типа "с товаром покупают ещё ...." или "купи ххх - получи ууу в подарок"
- определения товаров прикассовой зоны
- оптимизации размещения товара на складе или торговом зале
- планирования закупок группы товаров у поставщиков и так далее...
Алгоритм формирования данной статистики в принципе очевиден - последовательно сканируем все кассовые чеки и формируем табличку "сочетаемости":
[Товар-1][Товар-Х][число совместных покупок]
Так сейчас (с версии сентября.2011 года) и у меня появился режим "Администратор / задачи / произвести анализ совместных покупок ассортиментов за период". Где указываем период, например для выделения "сезонности" и строится данная табличка.
Использование информации:
Пока ограничился режимом, вызываемым через меню дополнительных задач при использовании справочника товаров и спр. товаров на складе - строится справка, которую затем (при желании) легко засунуть в Excel и как-то проанализировать. В дальнейшем (при возникновении реальных потребностей) подсистему можно будет усложнить и "углубить" или выкинуть из комплекса при отсутствии к ней интереса. Пример результата:
Как (из-за чего) развиваются системы "КИС Lack" и "УС land"? От куда берутся идеи по их развитию?
I. иногда не "даёт скучать" государство, изменяя законодательство.
II. пользователи просят внести новую возможность.
III. появляется новый класс задач, который требует внести изменения во многие подсистемы пакетов.
IV. Специально или случайно нахожу идеи на форумах или на сайтах производителей программ для бизнеса, которые считаю, что могут быть полезны для большинства пользователей моих универсальных учетных систем.
В данной теме предполагается размещение описаний реализаций данных идей - может быть "воруя" идеи поступаю нехорошо, но это один из путей современного развития. Желающие могут покритиковать идеи, их пользу или подход к реализации, а так же высказать своё "фи" по данному подходу в развитии систем.
Начали... На данном уважаемом форуме был задан вопрос https://olegon.ru/showthread.php?t=10677 о выявлении сочетаемости товаров.
Задача может быть интересной для:
- формирования рекламных акций типа "с товаром покупают ещё ...." или "купи ххх - получи ууу в подарок"
- определения товаров прикассовой зоны
- оптимизации размещения товара на складе или торговом зале
- планирования закупок группы товаров у поставщиков и так далее...
Алгоритм формирования данной статистики в принципе очевиден - последовательно сканируем все кассовые чеки и формируем табличку "сочетаемости":
[Товар-1][Товар-Х][число совместных покупок]
Так сейчас (с версии сентября.2011 года) и у меня появился режим "Администратор / задачи / произвести анализ совместных покупок ассортиментов за период". Где указываем период, например для выделения "сезонности" и строится данная табличка.
Использование информации:
Пока ограничился режимом, вызываемым через меню дополнительных задач при использовании справочника товаров и спр. товаров на складе - строится справка, которую затем (при желании) легко засунуть в Excel и как-то проанализировать. В дальнейшем (при возникновении реальных потребностей) подсистему можно будет усложнить и "углубить" или выкинуть из комплекса при отсутствии к ней интереса. Пример результата:
Код:
Покупают с Абсент Жак Сено Грин 70% 0.7л (0DFI)
56 Белая лошадь 0.5л виски 0CK4
34 Капитан морган черный 0.5л ром 0217
27 Хеннесси 0.35л всоп п/у коньяк 090K
23 Смирновъ №21 0.5л 40% водка 0A5E
23 Хеннесси 0.5л всоп коньяк 00XH
20 Белая лошадь 0.7л п/у виски 0FUM
18 Ольмеко серебр. 0.7л алкогольный напиток 0ECQ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Азов Русский Азов бел п/сух 0.75л игр.вино 0EHJ
1 Азов Каберне кр.сух.0.7л вино 0DRA █ 28.10.2011 14:24
На данном уважаемом форуме сейчас обсуждается "засада" СуперМаг, связанная со сложностями оформления первички https://olegon.ru/showthread.php?t=8763 ,если это "успокоит", то данная проблема существует для всех популярных программ, кроме "КИС Lack"/"УС Land" конечно 
!
Когда маленький и неизвестный, то приходится подстраиваться по любые, в том числе глупые требования заказчиков и их потребителей. Обсуждаемая выше проблема (различие реквизитов покупателя/продавца и грузополучателя/грузоотправителя в счетах-фактурах, товарной накладной ТОРГ-12 и товарно-транспортной накладной 1Т) решена в 2006 году следующим образом:
1. В карточке клиента (контрагента) есть поля с банковскими реквизитами, ИНН, КПП, ..., юридический адрес, а так же "фактический адрес". Каждый клиент может иметь обособленные торговые подразделения, имеющие свои адресные и прочие реквизиты. Это же относится и к "своим фирмам".
2. В режиме "специализированной печати документа" можно оставить по умолчанию или изменить продавца, покупателя и груз-лей.
3. Каждый пользователь в настройке определяет свою политику (позицию) по правилам печати "первички" - обработка умолчаний (пустых реквизитов печати):
а. Только юридические реквизиты
б. Только фактические атрибуты (адреса)
в. юридические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки
г. фактические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки.
4. Конечно можно "в лоб" задать клиента под атрибут документа и однозначно они могут быть одноименные (имя не может быть уникальным идентификатором). В этом случае программа берёт только юридические реквизиты.
P.S. В товарной накладной может быть ещё "хлеще": реквизиты покупателя одни, часть реквизитов грузополучателя (ИНН, КПП) другие, а адрес должен браться "третий". Причем адреса груз-лей в накладной и счете-фактуре различаются. Глупость? - Нет документы на магазины Лукойл и ТНК.
!Когда маленький и неизвестный, то приходится подстраиваться по любые, в том числе глупые требования заказчиков и их потребителей. Обсуждаемая выше проблема (различие реквизитов покупателя/продавца и грузополучателя/грузоотправителя в счетах-фактурах, товарной накладной ТОРГ-12 и товарно-транспортной накладной 1Т) решена в 2006 году следующим образом:
1. В карточке клиента (контрагента) есть поля с банковскими реквизитами, ИНН, КПП, ..., юридический адрес, а так же "фактический адрес". Каждый клиент может иметь обособленные торговые подразделения, имеющие свои адресные и прочие реквизиты. Это же относится и к "своим фирмам".
2. В режиме "специализированной печати документа" можно оставить по умолчанию или изменить продавца, покупателя и груз-лей.
3. Каждый пользователь в настройке определяет свою политику (позицию) по правилам печати "первички" - обработка умолчаний (пустых реквизитов печати):
а. Только юридические реквизиты
б. Только фактические атрибуты (адреса)
в. юридические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки
г. фактические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки.
4. Конечно можно "в лоб" задать клиента под атрибут документа и однозначно они могут быть одноименные (имя не может быть уникальным идентификатором). В этом случае программа берёт только юридические реквизиты.
P.S. В товарной накладной может быть ещё "хлеще": реквизиты покупателя одни, часть реквизитов грузополучателя (ИНН, КПП) другие, а адрес должен браться "третий". Причем адреса груз-лей в накладной и счете-фактуре различаются. Глупость? - Нет документы на магазины Лукойл и ТНК.
█ 02.11.2011 21:12
Ох и скучная, как погляжу система КИС Lack... подумалось, прочитав тему (выгрузка из СМ в 1ц). Вот уже десяток лет, как данный вопрос с одноэсниками (бухгалтерами) решается единообразно и быстро:
1. Бухгалтер, озвучивает данную "хотелку"
2. Звоню спецу по 1ц или созваниваюсь с "придворным" программистом
3. Пересылаю ему файл выгрузки и описалово интерфейса 1c.doc полей из документации.
4. Через неделю он приносит обрабоку беря от 2тыр до 4тыр за один вид операции
Программа администратор/бухгалтерия/экспорт документов L в бухгалтерию 1с. Настраиваем параметры выгрузки:
1. Период времени
2. Тип операции (документа) - приход и возврат поставщикам, исходящие сч.ф, входящие сч.ф., операции по расчетному счету, операции по кассе, списания.
3. Белые, черные или все документы
4. Документы с номерами, без или все
5. Тип "второй" цены, например продажи для приходных накладных или закупа для отгрузочных
6. Коеф. умножения цены (например в бухгалтерии её завышают/занижают)
7. Анализ виртуальности документа, например выгрузка по конкретному юр.лицу из БД, где ведутся несколько (или банк по определенному р/с)
8. Имя файла обмена.
Программа формирует файл в формате dBase III (желающие средствами офиса могут перкодировать в любой ПК формат), а одинэсникам он наиболее удобен. Формат файла экспорта:
1. Бухгалтер, озвучивает данную "хотелку"
2. Звоню спецу по 1ц или созваниваюсь с "придворным" программистом
3. Пересылаю ему файл выгрузки и описалово интерфейса 1c.doc полей из документации.
4. Через неделю он приносит обрабоку беря от 2тыр до 4тыр за один вид операции
Программа администратор/бухгалтерия/экспорт документов L в бухгалтерию 1с. Настраиваем параметры выгрузки:
1. Период времени
2. Тип операции (документа) - приход и возврат поставщикам, исходящие сч.ф, входящие сч.ф., операции по расчетному счету, операции по кассе, списания.
3. Белые, черные или все документы
4. Документы с номерами, без или все
5. Тип "второй" цены, например продажи для приходных накладных или закупа для отгрузочных
6. Коеф. умножения цены (например в бухгалтерии её завышают/занижают)
7. Анализ виртуальности документа, например выгрузка по конкретному юр.лицу из БД, где ведутся несколько (или банк по определенному р/с)
8. Имя файла обмена.
Программа формирует файл в формате dBase III (желающие средствами офиса могут перкодировать в любой ПК формат), а одинэсникам он наиболее удобен. Формат файла экспорта:
Код:
Имя поля Ret_ttn l признак возврата Nomdoc c 5номер документа Datedoc d 8дата документа Kaname c 35имя клиента Tovname c 35наименование товара Kol n 12.3количество Sum n 12.2сумма документа Nds n 6.2ндс в цене товара Cost n 12.2основная цена Endcost n 12.2вторая цена Codwares c 4код товара Reason c 150основание документа Coddoc c 4код документа Client c 4код клиента
█ 03.11.2011 08:50
Ну такой способ в Супермаге работает с 2000 года, а то и с версии 2.6.
И честно говоря подход устарел.
Бухгалтера хотят получать
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
И честно говоря подход устарел.
Бухгалтера хотят получать
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
█ 03.11.2011 19:06
Цитата:
Не возражаю о наличии такой возможности, ни об "устаревании"... просто показалось, что обсуждался именно такой подход. КИС/УС ориентированы на мелкий бизнес, хотя зачастую с большим числом ежедневных документов, например нормально от 100 счетов фактур в смену. В таких фирмах бухгалтерия является всего лишь одним из центров затрат, выполняющих важную, но совсем "не нужную" для бизнеса функцию. Кроме этого, как правило вся первичка в начале вводится на торговой точке в режиме on-line, а лишь затем в отчетный период обрабатывается бухгалтерией. Mtirt ➤ Ну такой способ в Супермаге работает с 2000 года, а то и с версии 2.6. И честно говоря подход устарел.
Цитата:
- конечно они получают документы - и одноэс_программисты делают доработки Mtirt ➤ Бухгалтера хотят получать
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
- это вообще странно... Даже грамотные бухи работают над получением "красивых" цифр в отчетности. Если разговор, например об дебиторках/кредиторках или актах сверок, то этим занимаются торговые отделы?
- конечно это интересная (супер) задачка для программистов, но довольно сложно реализуемая, да и организовать такой процесс довольно сложно. Иногда "всплывают" задачки типа: из клиент-банка закачать в бухию и из неё в торговую систему. На памяти фирма легко соглашающаяся на траты по поддержке 1ц отказалась от неё когда 1с_ники запросили 80тыр за конфу, обрабатывающую закачку из любых клиент-банков.
█ 14.10.2014 17:19
Сейчас только прочитал и вспомнил. Не переносите в другой раздел!!! Много лет назад такие задачи пачками "перли" по разным фирмам и пришлось выдумывать технику работы с товаром (оформление операций любого типа) "всё наоборот".
Как выписывается документ (оформляется операция) "обычно"? - Определяем шапку документа (общие реквизиты операции), затем определяем список товаров для неё следуя неким ограничителям, замем сохраняем (проводим) документ. Здесь как минимум сложно оформлять операции пачками или "придумывать" какую-либо технологическую экзотику.
Как работает оформление операций любого типа - "всё наоборот"? Мы задаем склады (любое число) по которым желаем сделать операции. Программа строит табличку с остатками по этим складам. Проставляем у товаров количество, а можно всё под остаток на конкретном складе. Задаем тип документа, который хотим создать и сохраняем (проводим) документ...
Что заставило это вспомнить? Диалог:
1. Программа администратор/прочие задачи/групповые операции по группе товаров группы складов.
2. Запускаем, "звездим" обнуляемое МХ - строится по нему таблица остатков.
3. Встаем в колонку с количествами и нажимаем F9 - отобрать под остаток.
4. Нажимаем F8 - создать операцию и в форме выбираем "междускладское перемещение"
5. Заполняем шапку накладной... ну и сохраняем её.
6. В "оперативной программе/накладные/межсклад/Ctrl+PgDown" - встаем на созданную накладную и печатаем "бумажки" для продавцов для контроля передаваемого количества (любые типы накладных, в любых ценах или по схеме раскладки товаров).
P.S. Сразу проверил по тестовой реальной базе. Объединение мест хранения, т.е. проведение всех операций с печатью документов заняло 2 минуты.
Как выписывается документ (оформляется операция) "обычно"? - Определяем шапку документа (общие реквизиты операции), затем определяем список товаров для неё следуя неким ограничителям, замем сохраняем (проводим) документ. Здесь как минимум сложно оформлять операции пачками или "придумывать" какую-либо технологическую экзотику.
Как работает оформление операций любого типа - "всё наоборот"? Мы задаем склады (любое число) по которым желаем сделать операции. Программа строит табличку с остатками по этим складам. Проставляем у товаров количество, а можно всё под остаток на конкретном складе. Задаем тип документа, который хотим создать и сохраняем (проводим) документ...
Что заставило это вспомнить? Диалог:
Цитата:
BotMan ➤ начальство решило объединить два отдела в магазине(всего их два) физически ну и программно. у нас в супермаге два места хранения. звонил в С+ там посоветовали сделать это через инвентаризацию. Есть у кого соображения или опыт в таком случае.
Цитата:
Как бы это было произведено в "УС Лэнд": Mtirt ➤ В любом случае это Расход из одного МХ и Приход в другой. А как вы его делать будете - вам решать. Можно просто взять расход, заполнить остатками товара, а потом экспортировать его в приход. Только, я бы на месте продавцов на это не пошла. Так что, инвентаризация, возможно, лучший выбор.
1. Программа администратор/прочие задачи/групповые операции по группе товаров группы складов.
2. Запускаем, "звездим" обнуляемое МХ - строится по нему таблица остатков.
3. Встаем в колонку с количествами и нажимаем F9 - отобрать под остаток.
4. Нажимаем F8 - создать операцию и в форме выбираем "междускладское перемещение"
5. Заполняем шапку накладной... ну и сохраняем её.
6. В "оперативной программе/накладные/межсклад/Ctrl+PgDown" - встаем на созданную накладную и печатаем "бумажки" для продавцов для контроля передаваемого количества (любые типы накладных, в любых ценах или по схеме раскладки товаров).
P.S. Сразу проверил по тестовой реальной базе. Объединение мест хранения, т.е. проведение всех операций с печатью документов заняло 2 минуты.
█ 14.10.2014 17:30
Дело не в минутах, а в том, что в разных МХ, как правило, разные материально ответственные люди... И никто из них не согласится взять чужие остатки просто по бумажке.
█ 14.10.2014 17:38
Цитата:
Ясень-пень! О чём особо отметил в своём сообщении: OlegON ➤ Дело не в минутах, а в том, что в разных МХ, как правило, разные материально ответственные люди... И никто из них не согласится взять чужие остатки просто по бумажке.
Цитата:
Тема в СМ просто всколыхнула "глубины памяти" AndreyZh ➤ ...В "оперативной программе/накладные/межсклад/Ctrl+PgDown" - встаем на созданную накладную и печатаем "бумажки" для продавцов для контроля передаваемого количества (любые типы накладных, в любых ценах или по схеме раскладки товаров)...
█ 14.10.2014 19:04
Честно пытаюсь понять - в чём идея и - не понимаю...
Внутреннее перемещение - стандартная операция.
Перемещение "под остаток" на основании остатка определённого товара (товаров), определённой подгруппы (подгрупп), определённой группы (групп), всего товара - так же стандартная операция.
"Нестандарт" проявляется при разных товарных справочниках (да, иногда учёт ведётся в разных базах :)). При определённых договорённостях (к примеру - сначала ищем товар по штрихкоду, потом - по артикулу, потом - по наименованию) - так же решаема (хотя не без вопросов).
Внутреннее перемещение - стандартная операция.
Перемещение "под остаток" на основании остатка определённого товара (товаров), определённой подгруппы (подгрупп), определённой группы (групп), всего товара - так же стандартная операция.
"Нестандарт" проявляется при разных товарных справочниках (да, иногда учёт ведётся в разных базах :)). При определённых договорённостях (к примеру - сначала ищем товар по штрихкоду, потом - по артикулу, потом - по наименованию) - так же решаема (хотя не без вопросов).
█ 14.10.2014 21:23
Цитата:
Я пользуясь случаем вспомнил и рассказал ещё об одной технологии "УС Land"... а вообще "проблему" народ обсуждает в теме объединение двух мест хранения KirillHome ➤ Честно пытаюсь понять - в чём идея и - не понимаю...
█ 15.10.2014 11:33
Привет.
Андрей, перенос остатков между местами хранения одна из стандартных задача на заполнение складских документов. Например, в Купце создаем накладную на перемещение, указываем откуда и куда, жмем Обработка-Заполнить по остаткам, ОК, Утвердить документ. И все.
Тот подход, который ты описал и если я все правильно понял, является очень удобным инструментом, но применяется в несколько других контекстах, обычно при создании документов на основании каких-либо сводных отчетов. Наиболее распространенный случай - это подготовка заказов поставщикам. Формируем итоги по движению и остаткам товаров, закупавшимся у нужного поставщика, дополняя их общими итогами, т.к. товар может закупаться у нескольких разных поставщиков. Затем напротив каждого товара вводим, сколько хотим заказать. Или вначале формируем автозаказ, а затем корректируем, если нужно. Проверяем, жмем Создать документ заказа.
Андрей, перенос остатков между местами хранения одна из стандартных задача на заполнение складских документов. Например, в Купце создаем накладную на перемещение, указываем откуда и куда, жмем Обработка-Заполнить по остаткам, ОК, Утвердить документ. И все.
Тот подход, который ты описал и если я все правильно понял, является очень удобным инструментом, но применяется в несколько других контекстах, обычно при создании документов на основании каких-либо сводных отчетов. Наиболее распространенный случай - это подготовка заказов поставщикам. Формируем итоги по движению и остаткам товаров, закупавшимся у нужного поставщика, дополняя их общими итогами, т.к. товар может закупаться у нескольких разных поставщиков. Затем напротив каждого товара вводим, сколько хотим заказать. Или вначале формируем автозаказ, а затем корректируем, если нужно. Проверяем, жмем Создать документ заказа.
█ 15.10.2014 17:20
Добрый день Вячеслав!
А помошники заказчика - построение табличек с уходом, остатком, факультативно приходами за период... заполнение колонки заказ с пересчетом сумму, веса, объема заявки и просто печать данной "бумажки", в крайнем случае сохранения её в txt OR pdf
Цитата:
Что'ж более простое решение, чем есть у меня... Но в "чистом" виде данная задача встречается крайне редко за исключением извращений с передачей товара в прилавочной торговле, но у меня это отдельная операция. Если обратили внимание, то описал стандартизованную технику при помощи которой по произвольным складам и отобранным товарам можно создать товарные операции любого типа (в частности межсклад) FinSoft ➤ Андрей, перенос остатков между местами хранения одна из стандартных задача на заполнение складских документов. Например, в Купце создаем накладную на перемещение, указываем откуда и куда, жмем Обработка-Заполнить по остаткам, ОК, Утвердить документ. И все.
Цитата:
Ну в УС Лэнд нет операций (документов) типа "заказ у поставщика" и тем более отслеживание прохождения заказа - всё же ориентируюсь на малый бизнес, где это без надобности? FinSoft ➤ Тот подход, который ты описал и если я все правильно понял, является очень удобным инструментом, но применяется в несколько других контекстах, обычно при создании документов на основании каких-либо сводных отчетов. Наиболее распространенный случай - это подготовка заказов поставщикам. Формируем итоги по движению и остаткам товаров, закупавшимся у нужного поставщика, дополняя их общими итогами, т.к. товар может закупаться у нескольких разных поставщиков. Затем напротив каждого товара вводим, сколько хотим заказать. Или вначале формируем автозаказ, а затем корректируем, если нужно. Проверяем, жмем Создать документ заказа.
А помошники заказчика - построение табличек с уходом, остатком, факультативно приходами за период... заполнение колонки заказ с пересчетом сумму, веса, объема заявки и просто печать данной "бумажки", в крайнем случае сохранения её в txt OR pdf
█ 15.10.2014 21:52
Изначально документ заказ поставщику был введен для оптовки. Когда оператор выписывает товары, то в отдельной колонке видит дату планируемого прихода товара. Щелкает по ней, видит все заказы (дату заказа, дату планируемого прихода, плановую цену закупки) и может информировать покупателя.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.
█ 17.10.2014 13:11
Извини Вячеслав (=
Сейчас проходит "алкогольный" дурдом и просто физически нет времени разговаривать до 21.10. Мысли у тебя очень интересные, но и у меня по этим вопросам есть "своё" решение... но познее...
Сейчас проходит "алкогольный" дурдом и просто физически нет времени разговаривать до 21.10. Мысли у тебя очень интересные, но и у меня по этим вопросам есть "своё" решение... но познее...
█ 24.10.2014 10:35
Цитата:
Добрый день Вячеслав! FinSoft ➤ Изначально документ заказ поставщику был введен для оптовки. Когда оператор выписывает товары, то в отдельной колонке видит дату планируемого прихода товара. Щелкает по ней, видит все заказы (дату заказа, дату планируемого прихода, плановую цену закупки) и может информировать покупателя.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Примитивизм - кредо системы "УС Land"! Как следствие так же решается и данная задача.
Для этого используется "хранилище виртуальных объектов", а попросту информация в основании или системной метке приходной накладной - пометки: товар в пути и заказанный товар, а так же особенность приходных накладных - пока она не распределена на склад нет операций и изменений в "расчетах" (когда распределится - появятся реальные остатки программа эти маркеры будет игнорировать).
Есть отчет "аналитика/специализированные/глобальные остатки на текущий момент". Появляется форма запроса для извлечения нужной инфы и анализу маркеров:
Строится отчет, где одновременно отражены "остатки" товаров: реальные, в пути, заказанные с пометками о сроках доставки.
Цитата:
Это ИМХО узкоспециализированная задача, которую решить конечно можно, но реальных заказчиков на схожие задачи не было. Отмечу, что мебельное производство действительно сложное для автоматизации, зная об этом даже на уровне продажи мебели... а там только комплектация/разукомплектация... и отмечу, что для "Купца" это действительно реальное конкурентное преимущество!!! FinSoft ➤ Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.
█ 24.10.2014 13:37
Модуль для мебельного производства в Купце присутствует чисто из политических соображений. Я не планирую его дальнейшее развитие. Чтобы получить конкурентную систему в этой области, нужно встраивать элементы кад (раскрой и визуальное проектирование интерьера). Год назад я провел экспериментальные работы в этом направлении, в результате которых был разработан ряд библиотек. Но затем заморозил, т.к. перспективы тиражирования невелики, а необходимый объем инвестиций от действующих клиентов привлечь не получается. Сейчас этим модулем пользуется одна фабрика (примерно 50 рабочих мест, включая салоны). Работаем в режиме поддержки, иногда что-то заказывают дополнительно.
Кроме мебели, в Купце есть функционал для продуктового производства, многопередельного швейного производства и позаказного производства натяжных потолков. Они также мало развиваются, но хорошо вписываются в общую систему, логически закончены и компактны (в отличии от мебели).
Основное направление в Купце - это оптово-розничная торговля. Тема довольно обширная, исторически специализация - товары для дома (хозяйственные товары, отделочные материалы и т.п.) и продукты питания (бакалея, мясопродукты и т.п.).
Кроме мебели, в Купце есть функционал для продуктового производства, многопередельного швейного производства и позаказного производства натяжных потолков. Они также мало развиваются, но хорошо вписываются в общую систему, логически закончены и компактны (в отличии от мебели).
Основное направление в Купце - это оптово-розничная торговля. Тема довольно обширная, исторически специализация - товары для дома (хозяйственные товары, отделочные материалы и т.п.) и продукты питания (бакалея, мясопродукты и т.п.).
█ 07.04.2015 15:11
Цитата:
Вот "свежайшее" например... В ответ на презентацию возможностей системы в плане контроля ведения атрибутов товаров и клиентов Проверки реквизитов для и не только уважаемый KirillHome задал "невинный" вопрос AndreyZh ➤ Как (из-за чего) развиваются системы "КИС Lack" и "УС land"? От куда берутся идеи по их развитию?
Цитата:
В принципе данные проверки появились недавно, да и совсем "не по ГТД"... Правильность занесения данного атрибута товара тоже никого "не парила" - ну вводили операторы набор цифорок из счетов-фактур поставщиков, ну переносились эти цифорки в отгрузочные/возвратные накладные - всех устраивало. А какова проверка на правильность ГТД (если не секрет, конечно)?
Почему-то захотелось разобраться в данной "теме" - какова структура номера ГТД? Нашел вариант, реализовал тестирование в программе, вывалилось куча ошибок пользователей, начал копать дальше - вроде бы разобрался... подробнее в упомянутой теме.
Проверил - есть, правда мало ошибок, но во всех доступных мне базах. Решил проверить в доступной мне 1С:Бухгалтерия 8.2 - пропускает ГТД неверной структуры.
В общем внес данный функционал (проверки корректности структуры ГТД) в систему, авось когда-нибудь, кому-нибудь он и сгодится?
█ 17.06.2015 13:38
Мы писали, мы писали, наши паль....
Ещё раз прочитал тему: Супермаг состав товара в ценнике и подумал, а чё? Ситуаций когда требуется вести и отражать некую информацию о товаре, в частности состав товара/изделия возникает во множествах бизнесов, а УС Лэнд данной техники (в упрощенном виде) не имеет - непорядок. Замечу, что в свете начального вопроса всё давно решено.
Подумал, как можно сделать данную технику наиболее универсальной, а учитывая, что всё равно "сломал" всю структуру базы системы - полем больше или меньше, без разницы... Приступив сегодня к переделке программы "ценники" вспомнил об этой задачке, подумал маленько и чего-то "наделал":
1. В прогу перевода версий добавил ещё один обработчик; в настройках полей экранных форм справочника товаров добавил исключение;
2. В форму добавления/изменения справочника товаров добавил ведение этого нового поля с примечанием по его заполнению: блоки разделенные (;) должны отражаться на отдельных строках. Получилось:
3. Внес изменения в программу ценников: ведение нового поля, обработчик его импорта для разделения по строкам, добавил (пока) новый 31 формат ценников, который выглядит:
В каких случаях эта хрень может быть полезна?
1. Конечно ценники общепита с перечислением продуктов, каллорийности и т.д.;
2. Одежда для отражения состава тканей;
3. Сложная бытовая техника и компьютеры для отражения конфигурации;
4. Для предупреждения о чём-то покупателей, что частенько понуждается госорганами регулирования... и куча других нюансов... Ждите версию 1507 - когда-нибудь она будет доделана
Ещё раз прочитал тему: Супермаг состав товара в ценнике и подумал, а чё? Ситуаций когда требуется вести и отражать некую информацию о товаре, в частности состав товара/изделия возникает во множествах бизнесов, а УС Лэнд данной техники (в упрощенном виде) не имеет - непорядок. Замечу, что в свете начального вопроса всё давно решено.
Подумал, как можно сделать данную технику наиболее универсальной, а учитывая, что всё равно "сломал" всю структуру базы системы - полем больше или меньше, без разницы... Приступив сегодня к переделке программы "ценники" вспомнил об этой задачке, подумал маленько и чего-то "наделал":
1. В прогу перевода версий добавил ещё один обработчик; в настройках полей экранных форм справочника товаров добавил исключение;
2. В форму добавления/изменения справочника товаров добавил ведение этого нового поля с примечанием по его заполнению: блоки разделенные (;) должны отражаться на отдельных строках. Получилось:
3. Внес изменения в программу ценников: ведение нового поля, обработчик его импорта для разделения по строкам, добавил (пока) новый 31 формат ценников, который выглядит:
В каких случаях эта хрень может быть полезна?
1. Конечно ценники общепита с перечислением продуктов, каллорийности и т.д.;
2. Одежда для отражения состава тканей;
3. Сложная бытовая техника и компьютеры для отражения конфигурации;
4. Для предупреждения о чём-то покупателей, что частенько понуждается госорганами регулирования... и куча других нюансов... Ждите версию 1507 - когда-нибудь она будет доделана
█ 12.03.2016 10:53
Сейчас посмотрев блог разработчика наткнулся на тему: http://olegon.ru/showthread.php?t=23997 и не понял "в чем проблема"?... и особенно для программы заточенной под опт и производство...
Продажа в "под запись" или "в рассрочку" - элементарно в "УС Лэнд": просто на чеке (накладной) указываете отсрочку платежа и гасите его в течении длительного периода любыми суммами, а программа контролирует этапы (платежи) и текущие, в том числе просроченные долги покупателей
Продажа в "под запись" или "в рассрочку" - элементарно в "УС Лэнд": просто на чеке (накладной) указываете отсрочку платежа и гасите его в течении длительного периода любыми суммами, а программа контролирует этапы (платежи) и текущие, в том числе просроченные долги покупателей
█ 12.03.2016 12:14
Привет, Андрей.
В блоге речь шла про программу ФинСофт:Магазин. Это старая программа для организации розничных продаж в территориально удаленных местах. Основная ее фишка в том, что все максимально упрощено и продавцы что-то сломать или накосячить практически не могут. То есть что-то напоминающее УКМ, но с несколько иной заточкой функционала. Работает в связке с бэком, в котором реализуется полноценный учет.
В Купце, конечно, есть весь функционал и можно работать напрямую через удаленные подключения через интернет. Но бывает не всегда удобно. Для таких ситуаций и приспособлено - в точке продаж запускаем небольшую не убиваемую программу и обмениваемся с ней данными на уровне простых текстовых файлов. В этом случае КупецЪ выступает как бэк.
В блоге речь шла про программу ФинСофт:Магазин. Это старая программа для организации розничных продаж в территориально удаленных местах. Основная ее фишка в том, что все максимально упрощено и продавцы что-то сломать или накосячить практически не могут. То есть что-то напоминающее УКМ, но с несколько иной заточкой функционала. Работает в связке с бэком, в котором реализуется полноценный учет.
В Купце, конечно, есть весь функционал и можно работать напрямую через удаленные подключения через интернет. Но бывает не всегда удобно. Для таких ситуаций и приспособлено - в точке продаж запускаем небольшую не убиваемую программу и обмениваемся с ней данными на уровне простых текстовых файлов. В этом случае КупецЪ выступает как бэк.
█ 12.03.2016 13:46
Привет Вячеслав!
Во первых в теме не обсуждалась "старая маленькая программа", а задавался конкретный вопрос по решению бизнес задачи. Во вторых, извини - особо не вникал... просто в режиме "простоя" полазил по форуму...
Ну, а в третьих! Я же удивился... не уже ли это не решается в Купце - не может быть!
Во первых в теме не обсуждалась "старая маленькая программа", а задавался конкретный вопрос по решению бизнес задачи. Во вторых, извини - особо не вникал... просто в режиме "простоя" полазил по форуму...
Ну, а в третьих! Я же удивился... не уже ли это не решается в Купце - не может быть!
█ 16.10.2017 16:01
Сделал "большое" - можно пописать, т.к. на сегодня хватит!
Система "УС Лэнд:ЕГАИС" в силу её, как системы автоматизации примитивной модели бизнеса, более полезна мне, как полигон для отработки новых компьютерных приёмов и очень сильно обогатила мой арсенал в разработке основной системы "УС Land".
Суть их (автоматов) довольно простая - задаётся некий набор управленческих констант и последовательно вызывается набор существующих в системе режимов, где в "автоматическом" состоянии отключаются интерфейсные блоки, т.е. все диалоги с пользователем. При этом "значения", которые должен вводить пользователь заменяются предопределенными константами.
Операторы по каждому направлению развоза передают на склад список отгруженных на эту дату накладных для их контроля с фактическим вывозом. Таких направлений (маршрутов) может быть до 40 шт. в день. Как это сейчас реализовано:
Появился новый сервис в режиме "отгрузочных накладных":
Выбрав его оператор определяет дату развоза (накладных):
По дате, а точнее "дню недели" программа определяет список маршрутов развоза на этот день:
Далее в режиме "автомата" запускается построение "совершенно" стороннего отчета с результатом вида:
Помечается маршрут, как "напечатанный" (обработанный). Как поступали раньше и что делает программа в автоматическом режиме?
Вызывался отчет:
Операторы изменяли необходимые атрибуты его настройки. Помечены изменяемые поля настройки отчета:
и так по 40 раз ежедневно ручками вводя всё
Система "УС Лэнд:ЕГАИС" в силу её, как системы автоматизации примитивной модели бизнеса, более полезна мне, как полигон для отработки новых компьютерных приёмов и очень сильно обогатила мой арсенал в разработке основной системы "УС Land".
Например подсистемы "автоматов"
Суть их (автоматов) довольно простая - задаётся некий набор управленческих констант и последовательно вызывается набор существующих в системе режимов, где в "автоматическом" состоянии отключаются интерфейсные блоки, т.е. все диалоги с пользователем. При этом "значения", которые должен вводить пользователь заменяются предопределенными константами.
Свежий пример использования данной техники в "УС Land"
Операторы по каждому направлению развоза передают на склад список отгруженных на эту дату накладных для их контроля с фактическим вывозом. Таких направлений (маршрутов) может быть до 40 шт. в день. Как это сейчас реализовано:
Появился новый сервис в режиме "отгрузочных накладных":
Выбрав его оператор определяет дату развоза (накладных):
По дате, а точнее "дню недели" программа определяет список маршрутов развоза на этот день:
Далее в режиме "автомата" запускается построение "совершенно" стороннего отчета с результатом вида:
Код:
Свод по товарным накладным (НСП учтен в заголовке накладных) выписанным за период с 05.10.17 по 05.10.17 Стр. 1
----------------------------------------------------------------------------------------------------------------------------------
КодН|ТипН.|Ее дата|Номер |Отср.| Наименование клиента (склада) |СумСоСкид.|Опл.ПоНак.| СуммаНДС | Кол-во
----------------------------------------------------------------------------------------------------------------------------------
D6KA Отгр. 05.10.17 71039 19.10 АО "Тандер" ММ 1293.92 197.38 10
.....
D6NE Отгр. 05.10.17 71151 19.10 АО "Тандер" ГМ 8734.62 1332.40 78
----------------------------------------------------------------------------------------------------------------------------------
НДС 11157.55 Скидка 0.00 Сумма 73143.91 Оплачено 0.00 К-во 766.000 Вес 462.2 Об. 3.3503 Лт. 0.000
Усредненная статистика: ТТН 30 Сумма 2438.13 Наименов. 9.100 Вес 15.406 Об. 0.11168 Отср. 14
Вызывался отчет:
Операторы изменяли необходимые атрибуты его настройки. Помечены изменяемые поля настройки отчета:
и так по 40 раз ежедневно ручками вводя всё
█ 06.01.2018 07:58
Очередная помощь от "УСЕга"...
Занимаясь там списаниями случайно нажал буквенную клавишу и программа вылетела по ошибке - вообще "мотор" "УС Land" работает так, что в списках можно искать требуемую запись, набирая первые знаки индекса, как правило "наименования".
Выяснение причины вылета в "УСЕга" вывело на недокументированное поведение инструмента разработки - при отключении индексации по таблице, а точнее указание нулевого порядка индексации используемые функции дают ошибки выполнения.
Конечно, так, как я делал - никто не делает, а вдруг? Переписал режимы поиска, что данные ошибки не допускается в "УС Лэнд:ЕГАИС", но так, как "мотор" один для систем, то и данная потенциальная проблема убрана и из "УС Land"
Занимаясь там списаниями случайно нажал буквенную клавишу и программа вылетела по ошибке - вообще "мотор" "УС Land" работает так, что в списках можно искать требуемую запись, набирая первые знаки индекса, как правило "наименования".
Выяснение причины вылета в "УСЕга" вывело на недокументированное поведение инструмента разработки - при отключении индексации по таблице, а точнее указание нулевого порядка индексации используемые функции дают ошибки выполнения.
Конечно, так, как я делал - никто не делает, а вдруг? Переписал режимы поиска, что данные ошибки не допускается в "УС Лэнд:ЕГАИС", но так, как "мотор" один для систем, то и данная потенциальная проблема убрана и из "УС Land"