█ 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 ➤ Честно пытаюсь понять - в чём идея и - не понимаю...
Часовой пояс GMT +3, время: 18:56.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.