Форум по программам и оборудованию > > >

Разрешите посоветоваться по развитию и изменению технологий системы УС Лэнд

22.05.2018 1:45


[ОТВЕТИТЬ]
15.06.2015 17:21
AndreyZh
 
Как-то недавно начал глобальное "перепахивание" системы с изменением структуры базы данных, как следствие сплошным изменением экранных и отчетных форм, а так же некоторых интерфейсных элементов.

Всё началось с анализом не очень важных (ситуации встречались крайне редко и пользователи о них более не "вспоминали") замечаний и пожеланий реальных пользователей. Так же захотелось реализовать некогда подсмотренные идеи из других систем, конечно адаптировав их под интерфейсные и технологические приёмы УС Land.

Увы, дабы не оставить себе "путей отступления" уже систему на 90% безвозвратно перепахал в свете ряда, захватывающих большинство модуле изменений:

1. Увеличение поля номер_документа с 12 до 19 знаков. Замечания были из-за чудотворцев при 1С, забавляющихся префиксами у номеров, а так же чудотворцев при государстве, требующих абсолютно точного соответствия номеров документов поставщиков/покупателей в алкогольных декларация и декларации по НДС.

2. Увеличение поля адреса с 100 до 200 знаков во всех рабочих таблицах, в частности юридического адреса контрагента и его торговых точек (удаленных подразделений), как следствие переделка "всего и вся".

3. Куча изменений и добавлений полей под будущие, уже более локальные изменения... то есть пути назад у меня уже нет

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

I. Уже 30% сделано. Подсистема "любимые отчеты". Как руководители (в силу их загруженности), так и новички поголовно жалуются и ругаются на громоздкость, сложность и запутанность отчетного контура системы... типа им нужно в реале 5-10 отчетов, а они "разбросаны везде", да и постоянно забывается "для чего они им нужны".

Что`ж в настройке появился режим - определения необходимых для конкретного пользователя отчетов. Это примерно выглядит так:



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

Подскажите!!! Пока ещё только в начале создания этой подсистемы.
15.06.2015 18:12
OlegON
 
Настоятельно рекомендую обзавестись системой контроля версий (мне больше всего по душе Mercurial), чтобы не сжигать мосты, что называется. И сразу закоммититься.
15.06.2015 18:55
FinSoft
 
Ну, могу сказать, как я к этому вопросу подхожу.

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

Для каждой роли можно сделать динамическую настройку меню путем скрытия неиспользуемых строк и разделов. Это может сделать сам пользователь.

Имеется дополнительный инструмент "Меню пользователя". В него каждый пользователь может выбрать наиболее часто используемые пункты из основного меню, задать краткое название и порядок следования. Меню пользователя либо всегда доступно в виде плавающего окна со списком поверх других окон (toolbox), либо через специальную стандартную кнопку на тулбаре (если разрешение экрана не позволяет комфортно разместить плавающее окно). Можно также задать пункт меню, который автоматически стартует после входа пользователя в программу.

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

Еще одна интерфейсная фишка с меню, которую я тоже не стал реализовывать - это история переходов. По сути, аналог описанного выше меню пользователя, но с автоматическим заполнением. Выглядит удобно, но может быть восстребовано только на начальном этапе работы с программой.
15.06.2015 21:14
AndreyZh
 
Цитата:
OlegON Настоятельно рекомендую обзавестись системой контроля версий (мне больше всего по душе Mercurial), чтобы не сжигать мосты, что называется. И сразу закоммититься.
Это конечно условно сказал про сжигание мостов... Предыдущая система с полными исходниками осталась, да и вообще:

1. Сохраняется отлаженная версия
2. Начинаю создавать новую

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

Цитата:
FinSoft Ну, могу сказать, как я к этому вопросу подхожу.

В программе на этапе разработки заложено несколько вариантов меню. Вариант определяется по роли пользователя после авторизации. Это некий базовый уровень. Обычно используется одно основное меню...
Спасибо! Увы, изначально была жесткая архитектура интерфейса приложения, конечно прорабатывался вопрос зависимости структуры систем меню от прав пользователя, но не "срослось"... хотя когда-нибудь - может быть, для этого нужно придумать новый "движок" систем меню. Но чуток другая идея - упростить "лицам принимающим решения" пользования "их режимами" и упростить механизм "ограничения доступа к анализу".

Про "историю переходов" - интересно и совсем не сложно, хотя и четкое структурирование режимов "оперативного персонала" и их "простота" в рамках идеологии УС Лэнд... вроде бы никогда это не "напрягало"
15.06.2015 22:00
OlegON
 
Дело не в самописке... Банальное удобство контроля изменений. По себе знаю, что изменения больше трех месяцев назад или больше 1000 строк назад в другом проекте - серьезная проблема для памяти. А тут - комментарий на каждый коммит, все в одной куче...
16.06.2015 10:28
AndreyZh
 
Цитата:
OlegON Дело не в самописке...
Это мной чой-то вспомнилась дискуссия Является ли УС Лэнд самопиской и какие критерии самописок?

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

1. В течении длительного времени задачка крутится в голове в поисках оптимального или легкого решения;
2. После его обнаружения набрасывается краткое схематичное описание решения и откладывается до готовности его реализовать;
3. Реализация. Смотрю схему решения и реализую её фрагменты последовательно делая заметки на листочках типа, показанного ниже и подробно в тексте описываю алгоритмы. Если происходит изменение, то сохраняется в "мусорке" старый модуль, изменение просто описывается на листочках, а в исходниках делаются краткие примечания. Пример описания разрабатываемого модуля:



4. Все листочки, связанные с версией скрепляются, прилагается к ним инструкция по версии и всё это складируется последовательно в архиве, т.е. если нужно будет вспомнить (нужды, как правило не возникает - достаточно описание в исходниках) - достаю из архива комплект по версии и "вспоминаю"...
16.06.2015 10:38
OlegON
 
Мне кажется, что тут просто надо попробовать :) Искать по бумажкам трудно, а составлять список различий (diff) еще труднее... Но не буду настаивать, я просто от листочков уже давно ушел, т.е. обдумывание идет в голове, все остальное - в электронном виде.
16.06.2015 15:04
FinSoft
 
Использование подобных систем контроля версий не всегда дает эффект. У меня тоже не прижилось, хотя одно время изучал данный вопрос. Когда нужно внести какие-то серьезные изменения (что сейчас бывает крайне редко), то да, делается резервная копия всего проекта с помощью простого bat-ка. А вот потребность что-то сравнивать с предыдущей версией за много лет можно по пальцам руки посчитать.

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

P.S. На бумажке я тоже любил порисовать, пока система функционально не насытилась. Причем с помощью карандаша и стерки. Олд-скул
16.06.2015 16:33
AndreyZh
 
Ух! - Закончил...

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

Как описано в первом сообщении для пользователя или через "размножение" - (F9) для пользователей определяется список постоянно, используемых отчетов с описанием понятным себе языком их предназначения. Добавилось только контроль на их максимальное число - 19 штук, иначе это не "любовь", а "блуд".

Как это работает - используется? После запуска аналитической программы Вам станет доступно (полная) стандартная система меню блока отчетов. Конечно Вы сможете строить отчет, если у Вас есть соответствующие права и конечно попытка его построить фиксируется в базе "шпионе" контроля за действиями пользователей. Это примерно выглядит так:



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



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

Скоро, для обсуждения и предложений презентую другую, более глобальную подсистему, к которой могу приступить не раннее, чем через пару недель - нужно "вылизать" уже созданное и начать устанавливать у части реальных пользователей
19.06.2015 14:59
AndreyZh
 
Продолжим`с... Возможно и будут замечания и советы?

В системе УС Лэнд имеется довольно развитый контур "производства", частично описанный и обсуждаемый в теме: Автоматизация производства при помощи универсальных учетных систем. Конечно сейчас он более развился и как следствие усложнился...

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

Технология комплектования/комплекта/сборки.

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

1. Молнееносное определение максимально возможных количеств О-И;
2. Молнееносное (доли секунды) производства требуемого количества О-К.
3. Отгрузка О-К или товаров его определяющих.

Поведение О-К зависит от наличия товара-шаблона для данного О-К:

I. НЕТ шаблона для О-К. При попытке создать операцию "производства" программа сие действо запретит. При выборе О-К при создании отгрузочной накладной вместо одного О-К программа "выпишет" составляющие его товары в требуемом количестве.

II. Есть товар-шаблон для О-К. Операция производства произведет необходимое изделие в требуемом количестве с расчетом его себестоимости. При выборе О-К при создании отгрузочной накладной программа произведёт необходимое количество изделий по шаблону и внесет в накладную изделие соответствующее О-К в требуемых количествах.

Цена реализации. Программа просчитает сумму цен продажи по составляющим О-К и предложит её, а в случае её изменения пересчитает цены для товаров составляющих О-К.

Дополнительно предполагаются режимы:

1. Автоматическое преобразование существующей технологической карты с единственным "приходящим" изделием (полуфабрикатом) в объект-комплект.

2. Автоматическое, так же в систему добавлен набор таблиц использование товаров-заменителей при продаже и производстве.

К созданию этих технологий "руки дойдут" наверное только в июле, а посему будет время внимательно выслушать замечания к данным технологиям?
19.06.2015 22:58
OlegON
 
А как производится учет, например, создания изделий с плавающей техкартой? Вот готовим мы, например, салат. Бабахнули вчера 1 кг картошки и пакет майонеза. А сегодня картошка была с гнильцой, а повар перебрал с солью и на такое же количество выхода продукта бабахнул 1.5кг картошки и полтора пакета майонеза. И как это отражается?
19.06.2015 23:27
AndreyZh
 
Цитата:
OlegON А как производится учет, например, создания изделий с плавающей техкартой? Вот готовим мы, например, салат. Бабахнули вчера 1 кг картошки и пакет майонеза. А сегодня картошка была с гнильцой, а повар перебрал с солью и на такое же количество выхода продукта бабахнул 1.5кг картошки и полтора пакета майонеза. И как это отражается?
Что не спится? Я фильм "Зори здесь тихие 2015" посмотрел и приводил флэшки в порядок...

По новым технологиям см. ниже, а по старым можно постфактум менять техкарты, но в общем разумнее задачку решать так:

1. Производить согласно техкартам - это рассчитанные технологами выкладки;
2. В конце смены или периода производить ревизию остатков, делать операцию инвентаризации и формировать ведомость расхождения.

Новая техника комплектации предназначена для серьёзного упрощения и ускорения процесса стандартизированного производства, а точнее сборки и изготовления, а так же совмещения процесса производства и реализации. Кроме того реализация механизма "комплектации" в терминах "1с"
20.06.2015 09:47
FinSoft
 
Цитата:
OlegON А как производится учет, например, создания изделий с плавающей техкартой? Вот готовим мы, например, салат. Бабахнули вчера 1 кг картошки и пакет майонеза. А сегодня картошка была с гнильцой, а повар перебрал с солью и на такое же количество выхода продукта бабахнул 1.5кг картошки и полтора пакета майонеза. И как это отражается?
Олег, в производстве всегда надо различать план и факт. Техкарта (или нормы) - это инструмент для сравнительного анализа и планирования. Он не имеет прямого отношения к фактическому расходу сырья.

На примере салата в упрощенном случае.
1. Сырье передается в цех со склада, это фиксируется документально. Случай, когда склад и цех в одном лице - это частный случай.
2. Производство обычно происходит по сменам. Мастер первой смены передает остатки сырья в цехе (незавершенку) мастеру другой смены. Это тоже регистрируется документально, т.к. каждый из них материально-ответственный.
3. Выпуск готовой продукции (салатов) регистрируется документально на складе готовой продукции.
4. Готовая продукция отгружается со склада покупателям (в магазины).

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

Вопрос обычно состоит в том, что на момент отгрузки не известна фактическая себестоимость изделий. Поэтому начальную расценку делают по учетным ценам. В простых случаях с учетом по сырьевой себестоимости, это может быть цена предыдущего прихода. Затем, когда посчитали фактический расход сырья, запускаем обработку, которая во всех приходах готовой продукции на склад за период меняет учетную себестоимость на фактическую.

На крупных фабриках, где считали полную себестоимость (кроме сырья включали зарплату основных рабочих, общецеховые, общехозяйственные расходы, плановую амортизацию оборудования, плановую норму прибыли и т.п.), этим занимался специальный отдел экономистов, которые составляли так называемую плановую калькуляцию. Отгрузка готовой продукции делалась по плановым учетным ценам с использованием 43 счета в бухгалтерии. После того, как подбивали итоги по калькуляции фактической себестоимости (прямые затраты из производственных отчетов цехов, косвенные путем пропорционального распределения по сырьевой составляющей или зарплате основных рабочих), формировался 40 счет. Дельту между 43 и 40 счетом пропорционально списывали на себестоимость отгруженной продукции.

Андрей, я бы крайне не рекомендовал использовать списание сырья по нормам с последующим выравниванием по инвентаризации.
20.06.2015 11:29
KirillHome
 
Цитата:
FinSoft ....
На примере салата в упрощенном случае.
1. Сырье передается в цех со склада, это фиксируется документально. Случай, когда склад и цех в одном лице - это частный случай.
2. Производство обычно происходит по сменам. Мастер первой смены передает остатки сырья в цехе (незавершенку) мастеру другой смены. Это тоже регистрируется документально, т.к. каждый из них материально-ответственный.
3. Выпуск готовой продукции (салатов) регистрируется документально на складе готовой продукции.
4. Готовая продукция отгружается со склада покупателям (в магазины).

Незавершенный остаток сырья предыдущей смены, плюс сколько взяли сырья в текущую смену, минус сколько передали сырья следующей смене дают фактический расход сырья за смену. Сколько сдали готовой подукции на склад дает выпуск.
Теперь можно взять выпуск и нормы, получить плановый расход сырья и сравнить с фактическим. Чтобы посчитать фактическую сырьевую себестоимость, берем выпуск и нормы, фактический расход пропорционально распределяем по тем изделиям, в которые входят потраченные ингридиенты. По выпуску и нормам считаем плановую себестоимость изделий и сравниваем.
...
Те небольшие производства при магазинах, с которыми мне доводилось работать, к сожалению, выдавали только два показателя:
1) Количество полученного сырья (как со склада, так и от поставщиков - мясо в полутушах, майонез в вёдрах и т.п).
2) Количество произведённых "салатов" (котлет, блинов и т.п.)

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

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

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

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

И есть у меня ещё одна крамольная мысль - о том, что выход произведённой продукции (в цехах при магазине, конечно же) надо считать по продаже через кассу, а не через "подачу из цеха"
20.06.2015 14:16
FinSoft
 
Чтобы получить себестоимость конкретного блюда, достаточно знать общий расход сырья. Остальное раскручивается по нормам.
Вообще говоря, фактическая себестоимость, как и нормы, штука приблизительная. Их используют в паре, чтобы регулировать производственный процесс.

Когда производство маленькое, собственник рассуждает так. Вот столько денег я в этом месяце потратил, столько заработал, столько моя маржа. Маржа устраивает, нафик нужно заморачиваться с план-факторным анализом. Когда не устраивает, начинается разговор - с какой периодичностью делать инвентаризацию, кого и за что назначить материально-ответственным и т.д. Если говорить про борьбу с воровством (одну из сторон регулирования производства), то некоторые предпочитают просто занизить зарплату, с учетом того, что разницу "доворуют".
20.06.2015 23:14
AndreyZh
 
Добрый вечер!

В начале "поплачусь"! Сегодня даже для Саратова тепло: днём в тени по термометру 42 градуса, на огороде вяли огурчики и меня поставили на полив, чем и занимался несколько часов перебегая от грядок к тени деревьев... Потом не выдержал и спал в домике до медведевской ночи, т.е. 20:00 - когда наступает темень... в надежде домой ехать по "холодку". Только сейчас он наступил - всего 32 градуса, правда мозги не соображают, но ответить попробую...


Частота ревизий не обязательно ежедневная и производство - не торговля, здесь нет широкого спектра сырья и как следствие посчитать остатки, а выработка итак посчитана при передаче на склад хранения не представляет сложностей.

Инвентаризация в УС Лэнд - нормальная "затратная" операция в бизнес процессах производства, а с основанием например "расхождение с технологией" позволяет оценить правильность техкарт.

Себестоимость, как в "старой" (сложной) технологии, так и в новой считается "точно", но она "плановая". При желании (ни у кого не возникало) можно скорректировать на "фактическую" автоматически просчитав "приращение цены закупа".

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

Конечно я увидел и надеюсь прочитают производственники ряд ценных замечаний по учету процессов производства, но всё это есть в старых сложных техниках, а "народ" требует ближе к себе и упрощения этого всего... вот и выдумалось упрощение.
09.07.2015 17:05
AndreyZh
 
Когда появятся новые версии и дистрибутивы? - ХЗ!

С очень давнего времени копились пожелания, требующие изменения структур баз данных - вот и поменял, да так, что сам уже ожидаю отладочный гемор в процессе внедрения версий с сопутствующими исправлениями ошибок в реальном времени. Сейчас основная "отладочная" площадка готовится к сдаче алкогольной декларации, а там более 20 баз данных разбросанных по всему городу, а все программы комплекса слишком взаимоувязаны. Надеюсь, что после 20.07 начнется авральная установка, отладка, исправление ошибок... а дальнейшее зависит от их количества - думаю, что до конца августа все "клопы" будут отловлены. Дальше зависит от желания, пока нет куда-нибудь съездить на пару недель... Будем надеяться, что к концу сентября всё будет доделано и отлажено.

А пока... занимаюсь дальнейшим "усложнением" системы добавляя в неё новые технологические изменения. Сейчас приступил к реально необходимым и по которым идут постоянным потоком требования, но раньше, не трогая структур не мог их удовлетворить... Кроме того хотелось придумать более удобные механизмы (подходы, технологии), чем вшитые в логику (алгоритмы) системы.

Приступил к технике контроля цен в процессе продажи. В принципе механизмы частично имелись, но они настраивались в справочнике товаров (партий) и... как следствие использовались через матюки только в оптовках. Сейчас, собрав все пожелания внёс эти механизмы в описание номенклатуры (ассортиментов в терминах системы).



Обведено некрасивой толстой рамкой... Уже сделал универсальный очень быстрый обработчик (анализатор) цен и даже отладил его в режиме экспресс выписки - один из десятка способов формирования отгрузки. Рассмотрим ограничители:

Напомню, что значение 0 или много 9 отключает технологию (ограничители) в любых подсистемах...


1. Минимальная цена продажи. При выписке и сохранении (могут "играть" скидками) накладной программа проверяет и ИСПРАВЛЯЕТ цену товара до минимальной. Например при торговле алкоголем или при разрешении продавцам торговать ниже прайса.

2. Максимальная цена продажи.

3. Минимальная наценка на товар относительно себестоимости = цена_закупа + добавочная_цена.

4. Максимальная наценка на товар.

5. Точная цена продажи. Безусловная, которую нельзя менять ни какими программными приемами (ухищрениями), вне зависимости от прав пользователя. Например при торговле сигаретами или по точным ценам по договору с поставщиком.

Замечание: Условий на контроль цен может быть несколько, но процесс (порядок) контроля и изменения цен происходит, как вышеуказано.

Так же будет режим верификации партий (товаров) с остатками на описанные (для номенклатуры, где включены технологии) на правильность цен.
31.07.2015 10:56
AndreyZh
 
В общем и целом все изменения баз данных, думаю, в перспективе года на 3 произвел... Основные воспрошаемые изменения так же внес в систему и на следующей неделе, если опять не будет "тормозков" буду пробовать "всё это" устанавливать у реальных пользователей, что конечно выявит множество косяков и при объяснениях появится "горка" новых пожеланий.

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

Так, что есть надежда в ближайшие месяцы выложить новые дистрибутивы и обновления системы
14.10.2015 11:24
AndreyZh
 
Сейчас отвлекли звонком по "алкоголю в общепите" Алкоголь в общепите: учет, декларирование, журнал, ЕГАИС - пришлось переключиться... и сразу "встал вопрос"? Правда сам пока по нему не задумывался, но может подскажите идеи по его реализации "малой кровью" и не усложняя жизнь буфетчицам?

1. Приходуем в общепит бутылками (0.5), но желательно с позиции "разливухи" в миллилитрах (500)
2. Наливая в стакан сразу списывается его емкость, например (0.2) 100 мл

... то есть можно продавать как целыми, так и дробными значениями и для всего анализа это безразлично. Любые "порции" корректно отражаются при использовании сканера ШК.

Однако есть "засада": В журнал учета производится запись по продаже "алкоголя в потребительской таре" в момент её открытия, т.е. как только бутылка открыта - эту инфу надо прописать в журнал, как продажу всей бутылки и как Вы можете предложить "выкрутиться"?
15.10.2015 11:59
MWWRuza
 
А в чем собственно проблема? Открыли бутылку - списали ее в ЕГАИС полностью. То, что Вы ее по граммам потом еще месяц разливать будете, это их не волнует, это дело Ваше, Вашей товароучетной системы. Были где-то комментарии ФСРАР именно на эту тему, уже давно, тогда, когда только первый проект "журнала" появился, можно поискать, даже по моему здесь на форуме проскакивало.
15.10.2015 15:54
AndreyZh
 
Цитата:
MWWRuza А в чем собственно проблема?
Основная, что "УС Лэнд" и бэк, и фронт, и отчетность перед налоговыми и государственными органами... и всё это, как правило ведётся в одной базе локальных сетей. Мелочь, но "фонит" - с прогами (одними режимами) работают аналитики (программаторы бизнес-процессов), бухгалтера, операторы и ... продавцы "с улицы"... и все они хотят интерфейсного комфорта для под своё "развитие"

Далее технические проблемы, но отмечу, что кажется знаю (?), как они решаемы небольшим "допиливанием" системы:

Цитата:
MWWRuza Открыли бутылку - списали ее в ЕГАИС
Преимущество общепита - не предполагаются фиксации продаж в ЕГАИС

Цитата:
MWWRuza списали полностью.
Это только для "журнала учета реализации" в единицах потребительской тары, а для декларации учет по фактическому расходу в "граммах". Для бизнеса, учитывая стоимость напитков (от 3000 за бутылку) актуальны продажи и остатки с точностью "грамма", тем более, что процесса заказов и расчетов с поставщиками "там" давно находятся в "ведении" системы, а учитывая "грамотность" буфетчиц - продажи исключительно по ШК
20.02.2016 13:10
AndreyZh
 
Добрый, сегодня у меня день вопросов, а работать как в "понедельник" не дают день!

Озадачили очередной программисткой задачкой: Первая её часть - имеем кучку почтовых ящиков (хост, имя, пароль). Нужно просмотреть все, желательно программой непрочитанные письма, выявить входящие письма по "маске" адресата и сохранить файлы определенного типа из вложения в некий каталог под некими именами... ну затем эти файлики нужно пропарсить и записать/провести в программе документы определенного типа.

Как обычно решаются такие задачки?
20.02.2016 13:24
konst
 
Я бы поставил почтового клиента. В настройках включил бы фильтры на адресатов +действия :сохранить прикрепленные файлы. В
А уж с файлами бы разбирался отдельно.
20.02.2016 13:40
AndreyZh
 
Цитата:
konst Я бы поставил почтового клиента. В настройках включил бы фильтры на адресатов +действия :сохранить прикрепленные файлы. А уж с файлами бы разбирался отдельно.
Оооочень интересно!!! Так, как системы разработки плохо умеет работать с интернет ресурсами...

Какой почтовый клиент, какому почтовому клиенту можно задать сценарии, что бы он автоматически сваливал, пусть все вложенные файлы в некий каталог (и), а уж разобраться, что мне надо сканируя их структуру - для меня легкая задача.
20.02.2016 14:05
konst
 
очень удобно все делать в TheBat! - но он платный
чуть сложнее - но тоже все работает в Thunderbird - для сохранения прикрепленных файлов надо установить плагин attachmentextractor.
когда то решали похожую задачу - при внедрении автозаказа.
20.02.2016 14:20
AndreyZh
 
Цитата:
konst чуть сложнее - но тоже все работает в Thunderbird - для сохранения прикрепленных файлов надо установить плагин attachmentextractor. когда то решали похожую задачу - при внедрении автозаказа.
Так получилось, что его пользуем на работе... Посмотрел описание - вроде бы есть, у себя - нет. Возможно старая версия... Главное "направление" есть - спасибо за подсказку и возможно это легче, чем изобретать лисапед?
20.02.2016 14:26
konst
 
Чего нет?
1. скачиваем и устанавливаем плагин attachmentextractor
2. инструменты - фильтры сообщений - создаем правила - можно несколько - при выполнении условий "присвоить сообщению метку" - "AE AutoExtract"
3. в настройках attachmentextractor - указываем каталог куда сохранять и что сохранять - письма отмеченные меткой которую присвоили в п.2
20.02.2016 17:17
AndreyZh
 
СПАСИБО!!!

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

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

Цитата:
konst Чего нет?
1. скачиваем и устанавливаем плагин attachmentextractor
2. инструменты - фильтры сообщений - создаем правила - можно несколько - при выполнении условий "присвоить сообщению метку" - "AE AutoExtract"
3. в настройках attachmentextractor - указываем каталог куда сохранять и что сохранять - письма отмеченные меткой которую присвоили в п.2
Ещё раз большое спасибо! Ваши рекомендации никуда с форума не денутся, да и на "листочки" их прописал - дойдет очередь до этой задачи, тогда и буду глубоко "проникаться" ей.


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


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

 

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