|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevСчитаете это подколкой? Боюсь, вы не поняли о чем речь идет. А идет она о кассовых сессиях: есть чеки оплаченные наличными, есть - по банковской карте. Все учитывается раздельно. Это понимаю! При этом в "УС" кассовые документы автоматически оплачиваются, а банковские нет. sobolevPS. 1993 год - не ко мне. Тогда я занимался другими вопросами. Просто заказчик привёз с выставки несколько программ, в том числе Папирус и сказал посмотри, что мне подходит и сделай аналогичный функционал. P.S. Что шуток не понимаете? - Больше не буду!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 14:48 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevВ частности, если вдруг ставка НДС станет прогрессивной либо регрессивной, мы создадим новый справочник (назвав его "Шкала НДС") со значениями ставок и базами, для которых они должны применяться, и введем в формулы начисления НДС соответствующие корректировки с динамическим вычислением накопленной базы, сравнением полученного значения с указанной базой в шкале и применением соответствующей ставки. Такое исправление по всей совокупности настроек может быть сделано буквально за 1 день без обращения в ИНФИН. Garya, вы не погорячились? Суммы являющиеся в этом случае фактором налогообложения, дробятся. Как вы будете остатки с НДС (без НДС) считать?Не погорячился. В ИНФИНе (и в 1С, кстати, тоже, правда, корректировкой конфигурации) есть возможность это считать двумя разными способами. 1. "На ходу" при выполнении хозяйственной операции. Вычисляется оборот нарастающим итогом с начала года по базе, с которой должен в общем и целом начисляться НДС, включая ту транзакцию, которая обрабатывается в данный момент времени. Вычисляются части налогооблагаемой базы, по которым должны быть применены различные ставки налогообложения и на этой основе определяется размер налога (рассчитанный сразу по нескольким ставкам шкалы), который должен быть в итоге уплачен по факту фиксации транзакции. Далее вычисляется сумма ранее фактически начисленного налога (тоже нарастающим итогом с начала года), после чего вычисляется разница между первым и вторым, которая и выводиртся в сумму начисляемого налога в конкретной транзакции. 2. "По итогам месяца". В процессе выполнения проводок по реализации начисление НДС не производится. В конце месяца запускается "автоматическая операция" (что то вроде "обработки" 1С), которая формирует по всему массиву реализаций начисление НДС скопом. Алгоритм примерно такой же, как в п.1, только отрабатывает по всему массиву транзакций, последовательно выбирая документы, которые должны быть обработаны и постепенно включая их в расчет базы. Вот, например, настройка автоматической операции (настройка произведена буквально за 2-3 часа), которая рассчитывает закрытие счета 6611 "Краткосрочные кредиты банков" по разным ставкам, которые в зависимости от периодов возникновения задолженности и периода расчета должны рассчитываться по разным ставкам (в последнее время лимиты по кредитам банков изменялись несколько раз): Автоматическая проводка №1 расчет базы процентов по кредитам (по проценту производится расчет суммы, на который он начислен, методом обратного счета): МОКт(сч=6611; кор=9102; А1=все; А2=все; А3=2; А4=все и А4<>2; А5=все)/АН4КТ(1).ПроцентПоДог*100 Проводка №2 по превышению лимита, которая относится на специальную аналитику счета 9102, не облагаемую налогом на прибыль: Макс(МОКт(сч=6611; кор=9102; КА1=4; А1=все; А2=все; А3=2; А5=все)-МОДт(сч=6611; А1=все; А2=все; А3=2; А4=2; А5=все и А5<>1)/100*#СтавкаРеф*Ан5Кт(1).Коэфф_став_ЦБ;0) Продвока №3 сторнирование превышения лимита с облагаемой налогом на прибыль аналитики счета 9102: -МОКт(сч=6611; кор=9102; КА1=46; А1=все; А2=все; А3=2; А4=1; А5=все) Проводка №4 сторнирование проводки №1, в которой выполнен расчет базы: -МОКт(сч=6611; кор=6611; КА4=2; А1=все; А2=все; А3=2; А4=все и А4<>2; А5=все) Все 4 проводки входят в одну автоматическую операцию и выполняются "потоком" по всей совокупности кредитных договоров, ставок по договору (которые могли меняться). Счет 6611 - рублевый, поэтому по нему не используются нюансы изменения методов расчета по валютным ставкам. Не хочу загромождать сообщение формулами расчета еще и для валютных субсчетов 66 и 67, но главное, что во всех этих расчетах используется справочник, управляющий изменением методики расчета в зависимости как от учетного периода, так и от параметров договора. Вот его содержимое: № Наименование Коэффициент ставки ЦБ для рублевых кредитов Фиксированная валютная ставка Коээфициент ставки ЦБ для валютных кредитов1 До 01.11.2009 (действует до 30.06.2010 в новой редакции) 2 15 Null2 С 01.11.2009 по 30.06.10 (в старой редакции) 1.1 15 Null3 С 30.06.10 1.1 15 Null4 До 01.11.2009 (действует в старой редакции с 07/2010) 1.1 15 Null5 С 01.01.2010 (в ред.229-ФЗ от 27.07.10 действ.с 02.09.10) 1.8 15 Null6 С 01.01.2011 (в ред.229-ФЗ от 27.07.10 действ.с 02.09.10) 1.8 Null 0.8 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 16:02 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
ViPRosGarya, А ИНФИН быстро работает? Как создается контекст для скрипта? Т.е., как связан какой-то элемент с каким-то атрибутом сущности и и кто актуализирует эту сущность в видимости ко времени расчетов? Система или прогер?Про это очень долго и много рассказывать... :) Если в двух словах, у ИНФИНа имеется что-то вроде "прекомпиляции", на которой он производит синтаксический разбор формул и предварительную обработку (на этой фазе, например, подготавливаются временные таблицы, в которых формируются данные вложенных циклов). На окончательном этапе производится генерация проводок. Автоматические операции генерят сразу "пул" проводок, который отрабатывает на стороне SQL Server-а. Работает всё достаточно живо (по крайней мере, по сравнению с 1С, так просто летает). Стандартные операции предоставляют больше гибкости и возможностей (именно с их помощью, например, производится обработка "цепочек" учетных процессов, в которой можно перемежать документы и проводки в произвольных последовательностях). Однако, в "стандартных операциях" производится отдельная обработка каждой строчки с подстановкой данных текущих параметров, вычисляемых на стороне клиента. Поэтому эти операции отрабатывают уже существенно медленнее, чем автоматические. У кастомизатора есть выбор, что и для каких целей использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 16:20 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Garya, не разу не сомневаюсь, что валовую сумму по полной транзакции вы рассчитаете. Я о другом. Транзакции дробятся. Простой пример - счет-фактура. Если вы рассчитаете сумму НДС по всему документу, вам, вероятно, придется распластать эту сумму по строчкам. То же самое со всякими отчетами. Оприходовали материалов на 1000000. Через месяц надо посчитать остаток по каждой группе, сложить результат, прибавить израсходованное количество (в суммовом выражении) и неплохо бы выйти на оригинальное значение (рассчитанной изначально суммы налога). Коль скоро сумма налога является функцией суммы оригинальной транзакции, на каждой итерации придется вычислять какую-то пропорцию с первоначальным доком. А это уже не входит в концепцию неизменного программного кода. Или ИНФИН это учел? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 16:44 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevFinSoftПо ходу вопрос к Антону Соболеву - что у Вас с портацией проекта на Oracle, заглохло или продолжаете двигать? Нет не заглохло. Традиционная проблема последней мили. Практически все работает, но из-за текущих задач не удается довести до коммерческого финиша. Кстати, нам удалось совместить навигационную модель доступа с SQL. Правда пришлось юзать Oracle на самом низком уровне (OCI) и перетряхивать все кишки системе. А каковы замеры производительности работы системы в двух версиях? Я тоже пробовал портировать систему, только на postgreSQL. Если без переделки кода, то скорость локальной работы упала на порядок. Это при том, что postgreSQL имеет механизмы для иммитации работы с flat-базами. Основная проблема была в том, что в приложении используется много точечных чтений записей по первичному ключу. Например, если строится отчет, то в выборку (массив данных в ОЗУ) заносятся только итоговые значения, ссылки и значения, необходимые для сортировки и группировки - минимальный объем. Все остальное (длинные наименования и и т.п.) подтягиваются в процессе просмотра данных по первичному индексу. В sql такой подход очень неэффективен. Нужно либо формировать полную выборку (но это дополнительный расход озу, усложнение запросов различными джоинами и ухудшение структурирования бизнес-логики), либо кэшировать справочники (после чего встает вопрос об их синхронизации, да и держать такие копии на каждого клиента не здорово), либо делать трехзвенку (что утяжеляет все приложение). В общем, бросил я эту затею. Видел, что интерфейс в Папирусе изначально sql-дружелюбен. Например, журнал накладных открывается не сразу, а вначале запрашиваются условия отбора. Тут интересен вопрос - Вы закачиваете всю информацию по условиям, или выводите ограниченную часть записей, а затем подкачиваете в фоне/по кнопке? И как Вы решаете вопросы, описанные выше? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 16:56 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Производительность конечно хуже. Не на порядок, но 1.5..2-х кратное замедление имеет место. Но думаю на финишной доработке разрыв можно будет сократить. По выборкам: если запрашивается большой объем данных и не требуется временная таблица то извлекаются первые сколько-то записей (только что гарантированно экран заполнить) а дальше, если юзер попросит, то и подкачать можно. Таблицы (гриды, в смысле) реверсивные. То есть, если пользователь поднял выборку документов, в которой на самом деле этих доков под миллион и хочет перейти к последнему документу из выборки, то все произойдет моментом. Программа просто начнет отсчитывать записи с конца в соответствии с критериями фильтрации. Oracle я вроде научил это делать, но, блин, когда взад вперед ходить начинаешь позиционирование сбоит. По точечным чтениям: мы, честно сказать, почти все что можно кэшировать - кэшируем. То есть, здесь падения производительности нет. sql используем в сильно редуцированном виде. То есть, сложные запросы к нескольким таблицам не применяются. Я много-много лет назад въехал в декартовы произведения, и построил что-то вроде собственного языка запросов, интегрированного в c++. Не хочу сказать, что он - супер, но работает хорошо (кстати, там и оптимизатор есть). Вот пример. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Ну и решил не менять его на родной SQL, ибо, думаю, что только хуже будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 17:20 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolev По точечным чтениям: мы, честно сказать, почти все что можно кэшировать - кэшируем. То есть, здесь падения производительности нет. sql используем в сильно редуцированном виде. То есть, сложные запросы к нескольким таблицам не применяются. А как синхронизируется кэш с основной базой данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 17:43 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
FinSoftsobolev По точечным чтениям: мы, честно сказать, почти все что можно кэшировать - кэшируем. То есть, здесь падения производительности нет. sql используем в сильно редуцированном виде. То есть, сложные запросы к нескольким таблицам не применяются. А как синхронизируется кэш с основной базой данных? По системному журналу. Все значимые события пишутся в системный журнал. Нотификатор регулярно опрашивает системный журнал за период с момента последнего опроса и все объекты, которые были изменены или удалены помечаются как dirty. Ну и, соответственно, при запросе к такому объекту кэш обратиться к базе данных. Так как гарантии актуальности элемента, извлеченного из кэша нет, то правило для программирование такое: смотреть - кэш, транзакция - база. Если интересно, то кэш для объектов значительной мощности (документы или товары) ассоциативный. Как в CPU. Работает здорово. Довольно трудная задача - разрулить кэши в многопоточном сервере, так как он может работать одновременно с несколькими базами, а кэш должен быть один на все потоки, работающие с одной базой. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 17:54 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevКоль скоро сумма налога является функцией суммы оригинальной транзакции, на каждой итерации придется вычислять какую-то пропорцию с первоначальным доком. А это уже не входит в концепцию неизменного программного кода. Или ИНФИН это учел?Да, учел. Приведу конкретный пример. Имеется сумма НДС по поставкам активов, используемых сразу в разных видах деятельности - облагаемых НДС и не облагаемых НДС. Сумма НДС от поставщиков по таким видам активов относится на специальный субсчет счета 19. В конце квартала производится расчет пропорции расходов по видам деятельности и, если расходы за квартал по видам деятельности, не облагаемым НДС, окажутся менее 5% от общей суммы расходов по всем видам деятельности, то суммы НДС с этого субсчета автоматически целиком и полностью будут взяты в зачет (в соответствии с НК в этом случае это можно делать). Если же доля расходов по видам деятельности, не облагаемым НДС, превысила 5%, то расчитывается новая пропорция - не по расходам, а уже по выручке в разрезе видов деятельности. И в зачет по каждому документу, по которому НДС был отнесен на соответствующий субсчет счета 19 берется в зачет только та доля НДС, которая соответствует доле выручки по видам деятельности, облагаемым НДС. При всём при этом производится контроль, были ли закачены в систему данные по филиалам (если нет, то расчет долей производить нельзя), и если документы с данным по филиалам были загружены, то производит расчет долей с учетом расходов и выручки по разным видам деятельности еще и филиалов. Вот формулы проводок автоматических проводок, которые были настроены по закрытию счета 1917 и которые были настроены лично мною "врукопашную": Доля НЕ зачитываемого НДС (Д4417 К1917): ЕСЛИ((КОТДТ(сч=9002;А1=22,33,45,46,48;кор<>4504,4500,4543)+КОТДт(сч=9090;А1=50)+КОТДТ(сч=9102;А1=1,38,72,77,78)+КОТДТ(сч=4500;А3=10,11,12)+КОТДТ(сч=4543;А3<>1000)+ДокументСум(ЖУРНАЛ = 700).РасхПоНеоблВД)/(КОТДТ(сч=9002;А1<>10,46,12,48,50;кор<>4504,4500,4543)+КОТДТ(сч=9102;А1=1,38,25,35,34,72,77,78)+КОТДТ(сч=9090;А1=50)+КОТДТ(сч=4504,4500,4543)+ДокументСум(ЖУРНАЛ = 700).ОбщСумРасх)<0.05; 0; СКМДТ(сч=1917;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=все;А5=все)*((КОТКТ(сч=9001;А1=22,33,45)+КОТКт(сч=9101;А1=1,57,72,77,78,85)+КОТКт(сч=9090;А1=50)+ДокументСум(ЖУРНАЛ = 700).ВыручПоНеоблВД)/(КОТКТ(сч=9001;А1<>10,12,46,48,50)-КОТДТ(сч=9003;А1<>10,12,50)+КОТКТ(сч=9090;А1=50)+КОТКТ(сч=9101;А1=1,6,25,34,35,38,57,72,77,78,83)-КОТДТ(сч=9102;А1=6,8,9,32,36,37,39,74,83)+КОТДт(сч=7655; А6=26)/НДС+КОТДТ(сч=1145)+ДокументСум(ЖУРНАЛ = 700).ОбщСумВыручСНДС-ДокументСум(ЖУРНАЛ = 700).НДССОбщСумВыруч))) Зачитывается то, что осталось на счете 1917 после выполнения проводки по выше указанной формуле. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 17:54 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolev FinSoftпропущено... А как синхронизируется кэш с основной базой данных? По системному журналу. Понятно, спасибо. sobolev Довольно трудная задача - разрулить кэши в многопоточном сервере, так как он может работать одновременно с несколькими базами, а кэш должен быть один на все потоки, работающие с одной базой. Тут не понятно. Кэш делается на клиентской машине или у Вас трехзвенка получилась? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 18:07 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
FinSoft Тут не понятно. Кэш делается на клиентской машине или у Вас трехзвенка получилась? Мы опционально продает т.н. JobServer. Он умеет по расписанию задачи выполнять и может работать как сервер приложения. Клиентская сессия работает автономно, но, если есть сервер, то использует его для сложных отчетов. Ну и плюс к тому, сервер интенсивно используется терминалами сбора данных и агентскими КПК. Беда в том, что сервер стоит относительно дорого (москвичам просьба не хихикать) и его далеко не все клиенты покупают. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 18:14 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevFinSoft Тут не понятно. Кэш делается на клиентской машине или у Вас трехзвенка получилась? Мы опционально продает т.н. JobServer. Он умеет по расписанию задачи выполнять и может работать как сервер приложения. Клиентская сессия работает автономно, но, если есть сервер, то использует его для сложных отчетов. Ну и плюс к тому, сервер интенсивно используется терминалами сбора данных и агентскими КПК. Беда в том, что сервер стоит относительно дорого (москвичам просьба не хихикать) и его далеко не все клиенты покупают. Т.е. отдельно кэш на сервере для JobServer и отдельно на каждом клиенте? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 18:17 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Garya, я сообразил о чем вы. Собственно, все о чем вы говорите, работает через счета, агрегируя их (возможно, по аналитике) и на основе этих агрегаций выполняет заданные формулами расчеты. Мы похожий подход практикуем в части бухгалтерии, но это - не совсем то, о чем я говорил, хотя часть проблем снимает. Как пример, дескриптор счета применяемый для таких расчетов (в т.ч. проводок по документу): Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 18:21 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
FinSoftsobolevпропущено... Мы опционально продает т.н. JobServer. Он умеет по расписанию задачи выполнять и может работать как сервер приложения. Клиентская сессия работает автономно, но, если есть сервер, то использует его для сложных отчетов. Ну и плюс к тому, сервер интенсивно используется терминалами сбора данных и агентскими КПК. Беда в том, что сервер стоит относительно дорого (москвичам просьба не хихикать) и его далеко не все клиенты покупают. Т.е. отдельно кэш на сервере для JobServer и отдельно на каждом клиенте? Да. Ибо автономность от опционального сервера - жизненная необходимость. На сервере он только значительно больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 18:35 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Добрый вечер! Вопросов на сегодня надеюсь уже не будет... Хотя и "обещал" только отвечать, но вспышки теоретических споров вынуждают высказать крамольную мысль, о том, что в первую очередь нужно смотреть на какого пользователя ориентирована та или иная система ? Вызывает сомнение например, что "ИНФИН" ориентирован на реальный бизнес, наблюдая с каким "наслаждением" обсуждаются возможности его программной адаптации... Несомненно в нём достигается высокая гибкость приложения без вмешательства программистов "от разработчиков", но требуется высокий уровень программистов "от заказчика", а какой смысл от всего этого микро бизнесу? ИМХО только увеличение затратной составляющей. С ваего позволения "вброшу" ещё пару "изюминок" УС Land, которая кажется сможет вызвать новую волну обсуждений вопроса учёта бизнес процессов: Учет «чистой» прибыли . Доход определяется как разность между товарооборотом в ценах продажи и себестоимостью , которую в программе можно задавать как цену закупа, так и цену с учетом транспортных или иных затрат. Программа позволяет считать затраты как по работе фирмы или любого ее подразделения (центры затрат) так и по каждому товару (изделию) в отдельности (что касает-ся «дохода», то он рассчитывается во всех аналитических отчетах). В результате можем полу-чить «прибыль» как разность между доходом и суммой затрат . Данная величина анализируется во многих отчетах программы. Если оптовая фирма имеет сеть розничных торговых точек , то не всегда разумно считать доходность точки исходя из цены закупа (себестоимости), а разумнее считать закупочной ценой для точки оптовую цену продажи при расчете дохода. Программа позволяет делать это, то есть брать в качестве закупочной любую из фиксированных цен продажи (их 11 штук) или цен закупа. Попутно программа позволяет рассчитывать прибыли и убытки от «дисконтной» политики фирмы (уже было описано). Кроме этого на основе данной технологии и некоторых других технологий программа может рассчитывать «рентабельность» произвольных объектов учета , например торговых агентов, поставщиков, покупателей, работников предприятия, официальных торговых операций и так далее. Возможен анализ фондоотдачи предприятия т.е. количественные (вес, объем, количество) и суммовые (товарооборот, доход) показатели эффективности использования квадратного метра площади (кубометра объема, например холодильной камеры) общей/полезной площади предприятия, склада, торговой полки. ABC технология . Известно, что 30% номенклатуры товаров дают 70% товарооборота. Иногда необходимо разбить всю номенклатуры товаров на группы по даваемой ими выручке и производить как совместный анализ по всей номенклатуре, так и по каждой из групп. Что касается товаров, то данный анализ производится во множестве тиражных программ. Программа "УС Land" позволяет производить ABC (не 3, а от 2 до 9 групп) анализ по любым товарным объектам (товары, поставщики, покупатели, разделы учета, склады и т.д.), в различных срезах (товарооборот, доход относительно любой цены закупа, количество, вес, объем и т.д.). Позволяет использовать любые комбинации ABC критериев при построении отчетов и в оперативной работе с документами. XYZ технология . Это вариант ABC анализа, но оценивается частота покупок , что позволяет оптимизировать хранение товаров на складах или выкладку товаров на полках магазинов. Совокупность ABC/XYZ показателей позволяет анализировать привлекательность товаров (покупателей, поставщиков, групп товаров и прочих объектов учёта) для фирмы, расположив объекты в «академической» сводной таблице, что также программа умеет делать (понятия часто и много определяются при проведении ABC/XYZ анализа товарных объектов). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 20:45 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Андрей Ж.Известно, что 30% номенклатуры товаров дают 70% товарооборота. Парето поперхнулся ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 21:01 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Андрей Ж.Вызывает сомнение например, что "ИНФИН" ориентирован на реальный бизнес, наблюдая с каким "наслаждением" обсуждаются возможности его программной адаптации... именно этого требует реальный бизнес. Когда будет 50 тыс клиентов а не 50, думаю это поймете. Естественно желаю достижения этой цифры. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 21:06 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
самая важная персональная информация в интернет - номер и код доступа к вашей карте. Но даже ее вводите сознательно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 22:05 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
извините, последнее сообщение относится совсем к другому разделу этого форума. С тем, как я до такого дошел - уже разбираются. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2010, 22:08 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Добрый день! Правило Парето по версии ВиКи гласит: Правило Парето, правило 20/80 — эмпирическое правило, введённое социологом Вильфредо Парето, в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата». Может использоваться как базовый принцип для оптимизации какой-либо деятельности: правильно выбрав минимум самых важных действий, можно быстро получить значительную часть от планируемого полного результата, причём дальнейшие улучшения не всегда оправданы (см. Кривая Парето). Приводимые в законе цифры нельзя считать безусловно точными — это скорее просто мнемоническое правило, нежели реальные ориентиры. В действительности для каждой задачи следует проводить соответствующую математическую обработку. Попробуем в нём убедиться в режиме on-line (результат мне пока неизвестен) по данным примера к "УС Land" - реального мелкого магазина самообслуживания. Строю отчёт, вывожу в excel (дабы точно всё просчитать)... Отчёт по товарообороту даёт значения: 1. Наименование ассортимента (номенклатура) 2. Сумма продаж за почти 3 месяца 3. Доля конкретного наименования в общей сумме продаж Отчёт позволяет так ранжировать поставщиков, покупателей, разделы прайса, торговые точки, номенклатуру по измерителям товарооборот, доход или штучки... Один из самых примитивных... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 12:33 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
И так - всего 1182 позиции, даёт 70% всего т/о 263 позиции, что составляет 22.25% всей номенклатуры, но 80% т/о даёт 388 позиций (или 33% номенклатуры)... Т/е в разрезе "розничной троговли" мои оценки (взятые из "воздуха") более корректны. Но вообще, как Вы поняли система не заставляет делить на ABC группы, а вполне допускает AB или ABCDE разделение... Так же отдельно выделяется группа 0 (Z) - объекты анализа по которым вообще не было продаж. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 12:49 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
iscrafmАндрей Ж.Вызывает сомнение например, что "ИНФИН" ориентирован на реальный бизнес, наблюдая с каким "наслаждением" обсуждаются возможности его программной адаптации... именно этого требует реальный бизнес. Когда будет 50 тыс клиентов а не 50, думаю это поймете. Естественно желаю достижения этой цифры. Что есть реальный бизнес? По версии спецов обсуждающих теоретичекие проблемы "кастомизации" - это сложно организованные холдинги, но где их в России 50 000 "накопать". По версии "УС" - это легион "ларёчников" (явно больше 50 000), в основном ИП или в крайнем случае УСНО и где вопросы "схем начисления НДС" или "настраиваемых алгоритмов амортизации" даже не обсуждаются... "Как далеки они от народа" (С) Но и даже для серьёзного бизнеса. "Что то с памятью моей стало" - Когда последний раз менялись ставки налогов НДС? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 12:56 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
Никогда не мог понять зачем программисты издеваются над пользователями, заставляя их вводить период двумя датами. Сделайте одно текстовое поле и напишите тупейший разборщик того, что пользователь ввел. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Не забудьте, что запятую следует интерпретировать как точку, иначе на русской раскладке будет рука сбивается. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 12:59 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
sobolevНикогда не мог понять зачем программисты издеваются над пользователями, заставляя их вводить период двумя датами. Сделайте одно текстовое поле и напишите тупейший разборщик того, что пользователь ввел. Самое смешное, что я тоже этого не понимаю... Чесслово проводил многочисленные эксперименты на мышами пользователями различных интерфейсов ввода дат, но они все вызывали отторжение... Народ (не операторы, которых это вообще не парит - нажать Enter) работает будущими и прошлыми периодами постоянно, в то же время в пределах месяца достаточно ввести 2 цифры и нажать Enter... Приведённый же Вами код (впрочим спасибо за подсказку) на слабых ПК вызовет задержку примерно 0.3 секунды, что уже вызывает раздражение операторов. По ABC/XYZ всё таки покажу скрин вызова анализа и генерации ABC/XYZ по всем объектам и измерителям - для тестового примера строится (записывается инфа) за 44 секунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 13:11 |
|
Универсальная учётная система МП «УС Land». Вопрос-ответ
|
|||
---|---|---|---|
#18+
на слабых ПК вызовет задержку примерно 0.3 секунды, что уже вызывает раздражение операторов. Я это с 1996 года практикую (тогда тож под DOS'ом было). О каких 0.3сек вы говорите? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2010, 13:23 |
|
|
start [/forum/search_topic.php?author=Alexandr1&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
191ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
others: | 443ms |
total: | 774ms |
0 / 0 |