[ОТВЕТИТЬ]
12.08.2011 13:37
AndreyZh
 
Добрый день!

Как (из-за чего) развиваются системы "КИС 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
AndreyZh
 
На данном уважаемом форуме сейчас обсуждается "засада" СуперМаг, связанная со сложностями оформления первички https://olegon.ru/showthread.php?t=8763 ,если это "успокоит", то данная проблема существует для всех популярных программ, кроме "КИС Lack"/"УС Land" конечно !

Когда маленький и неизвестный, то приходится подстраиваться по любые, в том числе глупые требования заказчиков и их потребителей. Обсуждаемая выше проблема (различие реквизитов покупателя/продавца и грузополучателя/грузоотправителя в счетах-фактурах, товарной накладной ТОРГ-12 и товарно-транспортной накладной 1Т) решена в 2006 году следующим образом:

1. В карточке клиента (контрагента) есть поля с банковскими реквизитами, ИНН, КПП, ..., юридический адрес, а так же "фактический адрес". Каждый клиент может иметь обособленные торговые подразделения, имеющие свои адресные и прочие реквизиты. Это же относится и к "своим фирмам".

2. В режиме "специализированной печати документа" можно оставить по умолчанию или изменить продавца, покупателя и груз-лей.

3. Каждый пользователь в настройке определяет свою политику (позицию) по правилам печати "первички" - обработка умолчаний (пустых реквизитов печати):

а. Только юридические реквизиты
б. Только фактические атрибуты (адреса)
в. юридические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки
г. фактические реквизиты, но при наличии, заменяющиеся реквизитами адреса погрузки/разгрузки.

4. Конечно можно "в лоб" задать клиента под атрибут документа и однозначно они могут быть одноименные (имя не может быть уникальным идентификатором). В этом случае программа берёт только юридические реквизиты.

P.S. В товарной накладной может быть ещё "хлеще": реквизиты покупателя одни, часть реквизитов грузополучателя (ИНН, КПП) другие, а адрес должен браться "третий". Причем адреса груз-лей в накладной и счете-фактуре различаются. Глупость? - Нет документы на магазины Лукойл и ТНК.
02.11.2011 21:12
AndreyZh
 
Ох и скучная, как погляжу система КИС Lack... подумалось, прочитав тему (выгрузка из СМ в 1ц). Вот уже десяток лет, как данный вопрос с одноэсниками (бухгалтерами) решается единообразно и быстро:

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
Mtirt
 
Ну такой способ в Супермаге работает с 2000 года, а то и с версии 2.6.
И честно говоря подход устарел.
Бухгалтера хотят получать
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
03.11.2011 19:06
AndreyZh
 
Цитата:
Mtirt Ну такой способ в Супермаге работает с 2000 года, а то и с версии 2.6. И честно говоря подход устарел.
Не возражаю о наличии такой возможности, ни об "устаревании"... просто показалось, что обсуждался именно такой подход. КИС/УС ориентированы на мелкий бизнес, хотя зачастую с большим числом ежедневных документов, например нормально от 100 счетов фактур в смену. В таких фирмах бухгалтерия является всего лишь одним из центров затрат, выполняющих важную, но совсем "не нужную" для бизнеса функцию. Кроме этого, как правило вся первичка в начале вводится на торговой точке в режиме on-line, а лишь затем в отчетный период обрабатывается бухгалтерией.

Цитата:
Mtirt Бухгалтера хотят получать
- не список операций, а документы
- в реальном времени создания в Супермаге
- с возможностью редактирования с 1С и обратной корректировки в Супермаге
- и всё это в версии 8.2, которая больше любит XML, чем DBF.
- конечно они получают документы - и одноэс_программисты делают доработки

- это вообще странно... Даже грамотные бухи работают над получением "красивых" цифр в отчетности. Если разговор, например об дебиторках/кредиторках или актах сверок, то этим занимаются торговые отделы?

- конечно это интересная (супер) задачка для программистов, но довольно сложно реализуемая, да и организовать такой процесс довольно сложно. Иногда "всплывают" задачки типа: из клиент-банка закачать в бухию и из неё в торговую систему. На памяти фирма легко соглашающаяся на траты по поддержке 1ц отказалась от неё когда 1с_ники запросили 80тыр за конфу, обрабатывающую закачку из любых клиент-банков.
14.10.2014 17:19
AndreyZh
 
Сейчас только прочитал и вспомнил. Не переносите в другой раздел!!! Много лет назад такие задачи пачками "перли" по разным фирмам и пришлось выдумывать технику работы с товаром (оформление операций любого типа) "всё наоборот".

Как выписывается документ (оформляется операция) "обычно"? - Определяем шапку документа (общие реквизиты операции), затем определяем список товаров для неё следуя неким ограничителям, замем сохраняем (проводим) документ. Здесь как минимум сложно оформлять операции пачками или "придумывать" какую-либо технологическую экзотику.

Как работает оформление операций любого типа - "всё наоборот"? Мы задаем склады (любое число) по которым желаем сделать операции. Программа строит табличку с остатками по этим складам. Проставляем у товаров количество, а можно всё под остаток на конкретном складе. Задаем тип документа, который хотим создать и сохраняем (проводим) документ...

Что заставило это вспомнить? Диалог:

Цитата:
BotMan начальство решило объединить два отдела в магазине(всего их два) физически ну и программно. у нас в супермаге два места хранения. звонил в С+ там посоветовали сделать это через инвентаризацию. Есть у кого соображения или опыт в таком случае.
Цитата:
Mtirt В любом случае это Расход из одного МХ и Приход в другой. А как вы его делать будете - вам решать. Можно просто взять расход, заполнить остатками товара, а потом экспортировать его в приход. Только, я бы на месте продавцов на это не пошла. Так что, инвентаризация, возможно, лучший выбор.
Как бы это было произведено в "УС Лэнд":

1. Программа администратор/прочие задачи/групповые операции по группе товаров группы складов.

2. Запускаем, "звездим" обнуляемое МХ - строится по нему таблица остатков.

3. Встаем в колонку с количествами и нажимаем F9 - отобрать под остаток.

4. Нажимаем F8 - создать операцию и в форме выбираем "междускладское перемещение"

5. Заполняем шапку накладной... ну и сохраняем её.

6. В "оперативной программе/накладные/межсклад/Ctrl+PgDown" - встаем на созданную накладную и печатаем "бумажки" для продавцов для контроля передаваемого количества (любые типы накладных, в любых ценах или по схеме раскладки товаров).

P.S. Сразу проверил по тестовой реальной базе. Объединение мест хранения, т.е. проведение всех операций с печатью документов заняло 2 минуты.
14.10.2014 17:30
OlegON
 
Дело не в минутах, а в том, что в разных МХ, как правило, разные материально ответственные люди... И никто из них не согласится взять чужие остатки просто по бумажке.
14.10.2014 17:38
AndreyZh
 
Цитата:
OlegON Дело не в минутах, а в том, что в разных МХ, как правило, разные материально ответственные люди... И никто из них не согласится взять чужие остатки просто по бумажке.
Ясень-пень! О чём особо отметил в своём сообщении:

Цитата:
AndreyZh ...В "оперативной программе/накладные/межсклад/Ctrl+PgDown" - встаем на созданную накладную и печатаем "бумажки" для продавцов для контроля передаваемого количества (любые типы накладных, в любых ценах или по схеме раскладки товаров)...
Тема в СМ просто всколыхнула "глубины памяти"
14.10.2014 19:04
KirillHome
 
Честно пытаюсь понять - в чём идея и - не понимаю...
Внутреннее перемещение - стандартная операция.
Перемещение "под остаток" на основании остатка определённого товара (товаров), определённой подгруппы (подгрупп), определённой группы (групп), всего товара - так же стандартная операция.
"Нестандарт" проявляется при разных товарных справочниках (да, иногда учёт ведётся в разных базах :)). При определённых договорённостях (к примеру - сначала ищем товар по штрихкоду, потом - по артикулу, потом - по наименованию) - так же решаема (хотя не без вопросов).
14.10.2014 21:23
AndreyZh
 
Цитата:
KirillHome Честно пытаюсь понять - в чём идея и - не понимаю...
Я пользуясь случаем вспомнил и рассказал ещё об одной технологии "УС Land"... а вообще "проблему" народ обсуждает в теме объединение двух мест хранения
15.10.2014 11:33
FinSoft
 
Привет.

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

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

Цитата:
FinSoft Андрей, перенос остатков между местами хранения одна из стандартных задача на заполнение складских документов. Например, в Купце создаем накладную на перемещение, указываем откуда и куда, жмем Обработка-Заполнить по остаткам, ОК, Утвердить документ. И все.
Что'ж более простое решение, чем есть у меня... Но в "чистом" виде данная задача встречается крайне редко за исключением извращений с передачей товара в прилавочной торговле, но у меня это отдельная операция. Если обратили внимание, то описал стандартизованную технику при помощи которой по произвольным складам и отобранным товарам можно создать товарные операции любого типа (в частности межсклад)

Цитата:
FinSoft Тот подход, который ты описал и если я все правильно понял, является очень удобным инструментом, но применяется в несколько других контекстах, обычно при создании документов на основании каких-либо сводных отчетов. Наиболее распространенный случай - это подготовка заказов поставщикам. Формируем итоги по движению и остаткам товаров, закупавшимся у нужного поставщика, дополняя их общими итогами, т.к. товар может закупаться у нескольких разных поставщиков. Затем напротив каждого товара вводим, сколько хотим заказать. Или вначале формируем автозаказ, а затем корректируем, если нужно. Проверяем, жмем Создать документ заказа.
Ну в УС Лэнд нет операций (документов) типа "заказ у поставщика" и тем более отслеживание прохождения заказа - всё же ориентируюсь на малый бизнес, где это без надобности?

А помошники заказчика - построение табличек с уходом, остатком, факультативно приходами за период... заполнение колонки заказ с пересчетом сумму, веса, объема заявки и просто печать данной "бумажки", в крайнем случае сохранения её в txt OR pdf
15.10.2014 21:52
FinSoft
 
Изначально документ заказ поставщику был введен для оптовки. Когда оператор выписывает товары, то в отдельной колонке видит дату планируемого прихода товара. Щелкает по ней, видит все заказы (дату заказа, дату планируемого прихода, плановую цену закупки) и может информировать покупателя.
Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.
17.10.2014 13:11
AndreyZh
 
Извини Вячеслав (=

Сейчас проходит "алкогольный" дурдом и просто физически нет времени разговаривать до 21.10. Мысли у тебя очень интересные, но и у меня по этим вопросам есть "своё" решение... но познее...
24.10.2014 10:35
AndreyZh
 
Цитата:
FinSoft Изначально документ заказ поставщику был введен для оптовки. Когда оператор выписывает товары, то в отдельной колонке видит дату планируемого прихода товара. Щелкает по ней, видит все заказы (дату заказа, дату планируемого прихода, плановую цену закупки) и может информировать покупателя.

Я не мониторил, кто сейчас пользуется этой функцией. Знаю, что некоторые действительно просто сохраняют заказ в форме excel и отправляют по электронной почте.
Добрый день Вячеслав!

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

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

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



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

Цитата:
FinSoft Точно используют мебельщики. Но это очень специфичный бизнес. Используют для двух тем. Первая - контролируют приход комплектующих. Там фасады заказываются обычно у смежников, и надо, чтобы фасады для конкретного изделия (скажем, кухни) пришли за некоторое время до срока его сдачи, чтобы успеть прилепить к корпусам. Вторая - заказы используются при подсчете цен для прайса элементов (шкафов, тумбочек и т.п.). В двух словах, программа просматривает список элементов, включаемых в прайс, просматривает стандартный размерный ряд, для каждого размера по нормам берет материалы (нормы формульные и зависят от размеров), помножает их на плановую цену закупки, определяет себестоимость, помножает на процент покрытия косвенных издержек и на процент плановой прибыли, получает прайсовую цену. Плановая цена материала в этой цепочке определяется по ближайшему документу одного из трех типов - приходной накладной, заказу поставщику или специальному документу установки плановой цены закупки материала.
Это ИМХО узкоспециализированная задача, которую решить конечно можно, но реальных заказчиков на схожие задачи не было. Отмечу, что мебельное производство действительно сложное для автоматизации, зная об этом даже на уровне продажи мебели... а там только комплектация/разукомплектация... и отмечу, что для "Купца" это действительно реальное конкурентное преимущество!!!
24.10.2014 13:37
FinSoft
 
Модуль для мебельного производства в Купце присутствует чисто из политических соображений. Я не планирую его дальнейшее развитие. Чтобы получить конкурентную систему в этой области, нужно встраивать элементы кад (раскрой и визуальное проектирование интерьера). Год назад я провел экспериментальные работы в этом направлении, в результате которых был разработан ряд библиотек. Но затем заморозил, т.к. перспективы тиражирования невелики, а необходимый объем инвестиций от действующих клиентов привлечь не получается. Сейчас этим модулем пользуется одна фабрика (примерно 50 рабочих мест, включая салоны). Работаем в режиме поддержки, иногда что-то заказывают дополнительно.
Кроме мебели, в Купце есть функционал для продуктового производства, многопередельного швейного производства и позаказного производства натяжных потолков. Они также мало развиваются, но хорошо вписываются в общую систему, логически закончены и компактны (в отличии от мебели).
Основное направление в Купце - это оптово-розничная торговля. Тема довольно обширная, исторически специализация - товары для дома (хозяйственные товары, отделочные материалы и т.п.) и продукты питания (бакалея, мясопродукты и т.п.).
07.04.2015 15:11
AndreyZh
 
Цитата:
AndreyZh Как (из-за чего) развиваются системы "КИС Lack" и "УС land"? От куда берутся идеи по их развитию?
Вот "свежайшее" например... В ответ на презентацию возможностей системы в плане контроля ведения атрибутов товаров и клиентов Проверки реквизитов для и не только уважаемый KirillHome задал "невинный" вопрос
Цитата:
А какова проверка на правильность ГТД (если не секрет, конечно)?
В принципе данные проверки появились недавно, да и совсем "не по ГТД"... Правильность занесения данного атрибута товара тоже никого "не парила" - ну вводили операторы набор цифорок из счетов-фактур поставщиков, ну переносились эти цифорки в отгрузочные/возвратные накладные - всех устраивало.

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

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

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

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

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

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

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



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



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

1. Конечно ценники общепита с перечислением продуктов, каллорийности и т.д.;
2. Одежда для отражения состава тканей;
3. Сложная бытовая техника и компьютеры для отражения конфигурации;
4. Для предупреждения о чём-то покупателей, что частенько понуждается госорганами регулирования... и куча других нюансов... Ждите версию 1507 - когда-нибудь она будет доделана
12.03.2016 10:53
AndreyZh
 
Сейчас посмотрев блог разработчика наткнулся на тему: http://olegon.ru/showthread.php?t=23997 и не понял "в чем проблема"?... и особенно для программы заточенной под опт и производство...

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

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

Ну, а в третьих! Я же удивился... не уже ли это не решается в Купце - не может быть!
16.10.2017 16:01
AndreyZh
 
Сделал "большое" - можно пописать, т.к. на сегодня хватит!

Система "УС Лэнд:ЕГАИС" в силу её, как системы автоматизации примитивной модели бизнеса, более полезна мне, как полигон для отработки новых компьютерных приёмов и очень сильно обогатила мой арсенал в разработке основной системы "УС 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
AndreyZh
 
Очередная помощь от "УСЕга"...

Занимаясь там списаниями случайно нажал буквенную клавишу и программа вылетела по ошибке - вообще "мотор" "УС Land" работает так, что в списках можно искать требуемую запись, набирая первые знаки индекса, как правило "наименования".

Выяснение причины вылета в "УСЕга" вывело на недокументированное поведение инструмента разработки - при отключении индексации по таблице, а точнее указание нулевого порядка индексации используемые функции дают ошибки выполнения.

Конечно, так, как я делал - никто не делает, а вдруг? Переписал режимы поиска, что данные ошибки не допускается в "УС Лэнд:ЕГАИС", но так, как "мотор" один для систем, то и данная потенциальная проблема убрана и из "УС Land"
Опции темы


Часовой пояс GMT +3, время: 19:34.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.