pavlabor

С какого перепугу мужики в кирзовых сапогах, решили что они в состоянии разруливать юридические вопросы, создавать юридические фирмы и считать эти потуги реальными и не утопичными? Не проще ли обратится в юридическую контору? Или вынести свой вопрос на СПЕЦИАЛИЗИРОВАННЫЕ ресурсы, например вот этот http://openlex.com.ua/ Тут, если чел считает что его вопрос сто пудово выигрышный, можно привлечь спонсоров которые помогут в расходах по судебным тяжбам, претендуют на процент от материальной компенсации.

Тебя как и нехочуху никто не задалбливает, то что вам нравится долбацца это сугубо ваше желание.

Каждый получит ровно то что желает получить. Если система не может предложить, или желающий не может получить то что хочет, ему этот проект не интересе. Количество того что может предложить система зависит от того что будет реализовано. Система должна быть не прибыльной. Это не принудиловка, не рейдерство, по собственному желанию как зашел так и вышел. Если у тебя есть предложения, заявка, пожелание, выкладывай, но не забывай - любой каприз ЗА ВАШИ ДЕНЬГИ. Поэтому выложив предложение, заявку, пожелание, засучивай рукава и внедряй. В каждом городе были пионэры, мерились письками, я говорил вы тундуки, придут серьезные дядьки и пойдете вы лесом. Никто этого не слушал, зашла Воля и расставила приоритеты по своему, 40% операторов вылетело в трубу, потом зашел Триолан, Киевстар и остались самые упоротые, но мерятся письками продолжают. Через год два, сюда зайдут игроки, для который Воля, Триолан, Киевстар будут пионерами, а про всяких нехочух речь вообще идти не будет.

Нехочуха ты определись это бред собачачий или "должен был объяснить. А он хочет, но не может". Потому как со одной стороны вроде и грамотные все, а с другой ну Бл# мы такие тупые, такие тупые. Так вот для тупых. Данный проект это точка опоры. Каждый может вносить свое видение и предлагать. Но в любом случае должен быть какой то реестр страждущих, счет с прямым доступом и контролем, тогда в него можно собирать бабулети и на АМ-мов и на зачетов. Безусловно все это можно фиксировать на рулоне туалетной бумаги, или здесь на локале... Но если кого то поставить возле счета, то это зрада (с) Нехочуха на каждом угле. А про третейские суды для писюнов пусть Алекс-Е раскажет, все это сто раз схавано и высрано.

Собственно это стандартная задача "SQL для начинающих. Часть 3" Связь многие ко многим В некоторых случаях требуется многочисленные связи по обе стороны отношений. Например, каждый заказ может содержать множество товаров. И каждый товар может присутствовать во многих заказах. Для такой связи нам потребуется создать дополнительную таблицу: Если мы читаем доку на юбиллинг то видим - Да, можно сделать для филиала сколько угодно администраторов, либо передать администратору под управление сколько угодно филиалов. То есть такие связки в базе существуют на уровнях "филиал - администратор" и т.д. CREATE TABLE `branchesadmins` ( `id` int(11) NOT NULL AUTO_INCREMENT, `branchid` int(11) NOT NULL, `admin` varchar(40) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8; CREATE TABLE `branchescities` ( `id` int(11) NOT NULL AUTO_INCREMENT, `branchid` int(11) NOT NULL, `cityid` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; CREATE TABLE `branchesservices` ( `id` int(11) NOT NULL AUTO_INCREMENT, `branchid` int(11) NOT NULL, `serviceid` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `branchestariffs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `branchid` int(11) NOT NULL, `tariff` varchar(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `branchesusers` ( `id` int(11) NOT NULL AUTO_INCREMENT, `branchid` int(11) NOT NULL, `login` varchar(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; Но такой связки я не вижу на уровне "филиал - филиал". Наличие двух таких таблиц позволяет создавать не одноуровневую схему "дирекция - филиалы", а масштабируемую, многоуровневую схему "дирекция - филиалы - филиалы". На уровне модулей это позволит получать выборки по фильтрам - только для себя, - только для себя и моих филиалов. и ставить ограничение на просмотр активов с других филиалов. Самый практичный вариант это как написано в уроке "потребуется создать дополнительную таблицу", на уровне запросов, процедур, и прочей серверной приблуды, это сорвет крышу. Я хочу донести идею, возможно что не так выразился, нет проблем уточню.

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

Это самое правильное определение моей главной хотелки.

Возможно я чего то не понимаю, но принцип ACID реализован по крайней мере в PostgreSQL давным давно на уровне БД. Это автоматическое отслеживание целостности базы, авто индексы и т.д. Но это никаким образом не гарантирует сто процентной защиты от работы многопользовательской среды. Вот это Гарантия что не будет работать. API, HTTP отдельные процессы распределенные во времени и не блокированные в БД. Отсюда два менеджера будут вносить деньги одному и тому же пользователю, и деньги благополучно зачислятся, счетчики отработают, но сума не будет соответствовать действительности. Механизм решения данной проблемы, блокировка записи на момент обработки, модель MVCC (Multiversion Concurrency Control, Многоверсионное управление конкурентным доступом). Когда я писал свой биллинг в 2000-ных, не все было кучерявенько. Проконсультировавшись с програмерами которые писали учет для магазинов со ста тысячу транзакций в сутки, которые мне сказали "забей", я не стал заморачиваться. И что то мне чуйка подсказывает что на текущий момент это не актуально - сдох попугай, купим другого. Во первых, не вижу решения этой проблемы. А если где то и глюконет, ну пофиксят челу оплату менеджеры. По поводу проектирования структуры БД, это ответственная задача и некогда она не решалась с первого раза. Но это и никогда не было проблемой. Перелить базу на новый движок, это решаемо. Основное в биллинге на мой взгляд это модульная обвязка, ubilling вылизанная система. Хотелось бы поковыряться в базах данных olsasha, что там такое, что требует переписывать биллинг с нуля. Если там добавлено пару полей, подпилен интерфейс модуля и выборки перестроены по другому, то это ревизия модуля а не всего биллинга. Поэтому на мой взгляд стоит посмотреть что имеем, собрать докучи и подточить под текущие задачи и запускаться. Параллельно вести ревизию как оно работает, проектировать новую базу, и строить параллельный стенд, от текущей работы, до импорта баз данных. Дальше в одну прекрасную ночь все можно перелить в новый флакон. Еще раз, со всего что я ставил за свою жизнь, ubilling не вызвал ни одной проблемы. Вру, "мс" пересобрал. В 2000-ном, PostgreSQL уже дышал Oracl-у в спину.

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

Как по мне, это через чур глобально. ubilling написан поверх "RCMS Framework 1.2.12", сейчас на сайте есть "ReloadCMS 1.5.1 WebSat, version from 15.01.2013" но не качается, возможно что тоже помер. Взять к сведению это на сколько я понимаю это решается на уровне процедур базы данных, потянет ли это мускуль, вопрос открытый, свой биллинг писал на PostgreSQL. Далее делать ревизию и портировать модули с ubilling-а. Координатором брать nightfly, с последующей передачей ему всего депозитария. Это самый широкий и дешевый вариант. Но по любасу денег это может затянуть даже не на соточку гривен. Мне l1ght предложил открыть ветку обсуждения на https://github.com/nightflyza/Ubilling, но почему то мне кажется что на локале это эффективней решится. Нужно заценить объемы, выйти на сумму, открыть счет и после сбора определенной сумы запилить новый биллинг. Без бодрого финансирования, такой глобальный проект за три месяца утоптать сложно. Извиняю и готов сотрудничать.

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

Наверно расширенная "матрица прав и доступа" больше подойдет к разделу "Права, введение расширенной настройки прав" Здесь может правильней назвать "строитель дерева". Работает он как связка адреса "город + улица + дом". Задача работа филиалов. Когда есть дирекция, ей подчиняется пять филиалов, которые могут также создать по несколько филиалов, а те тоже могут создать филиалы и так бесконечно. При этом каждая ветка филиалов, позволит например просматривать исключительно свой склад и склады филиалов. Практическое решение. Есть оператор у которого есть сети в нескольких городах, при чем в каждом городе по несколько районов и там свой филиал, более того руководство районного филиала решило в качестве стимулирования работников отдать сетки на Аутсо́рсинг мастерам с отчислением не зарплаты а процента от оборота. При этом данная таблица позволяет организовать контроль за активами только свои и всех нижестоящих филиалов. При этом филиал не сможет смотреть активы дирекции и чужих филиалов, а будет просматривать только свои активы и активы своих филиалов. Последний филиал, будет видеть только свои активы.

Безусловно так и нужно. Но Stargazer не решает проблему одновременного обращения к полю, скажем при работе с одной карточкой двумя менеджерами горбыль гарантирован. Насколько я понял, основная проблема Stargazer-а в непредсказуемости работы с насами.

Где искать? Сначала нужно собрать инфу, потом анализ - что можно сделать, а дальше смотреть какие получатся объемы работ.

У нас досы просели на 90%.

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

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

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

Права, введение расширенной настройки прав. Предлагаю рассмотреть формирование и в перспективе реализации расширения следующих прав. Имеется, структурированное управление правами, которое не совсем закрывает потребность. Имеется. Объекты. - Модуль. - Позиция в модуле, юнит. Юзатели. - Филиалы. - Администраторы. Администраторы. - Стажер(демо). - Специалист. - Эксперт. Действия. - Просмотр. - Создание. - Редактирование. - Удаление. Собственно идея в чем. В оператора, или при создании филиала, администраторам могут быть переданы права на работу с модулем. В текущий момент, не имеется сквозной политики на права, поэтому они предоставляются выборочно и не совсем понятно по какой системе, по все вероятности "так получилось", как следствие, например. При создании филиала и передачи ему права на роботу с модулем город, то админ филиала может удалить город, изменить название, что может привести к проблеме у других филиалах и материнской структуре. При реализации единой политики, появляется необсуждаемая возможность и требование к модулям по правам. В связи с этим, определенный модуль можно делегировать/не делегировать филиалу, с определенными ограничениями, например филиал может просматривать, вносить города, но не может их редактировать или удалять. Внутри филиала, появляется возможность создавать профили уровней сотрудников не беспокоясь о состоянии базы, например создаеются - Стажер(демо). - Специалист 3 категории. - Специалист 2 категории. - Специалист 1 категории. - Эксперт. Взяли на работу чела, дали ему уровень стажера и пусть листает базу пока не прозреет, прозрел, дается профиль Специалиста 3 категории, и т.д. То же самое и с филиалами. Как админ филиала может завести пользователя, а выносить мозг дирекции тоже не каширно, вот и даются оговоренные права что админ филиала пользователя может завести, но редактировать и удалять не может, если другое не оговорено. Параллельно возникает вопрос с пользователями другого филиала, но этот вопрос будет рассмотрен в разделе "Требуется внесение таблицы "все-ко-всем". Приветствуется любая критика и предложения, помощь в консультации и программировании. Спонсирование заинтересованных сторон, приветствуется.

+ с твоего билинга каки-то образом получать данные в ERP "Firstprov". Именно ERP, а не классический биллинг для провайдеров... Прокурил тему ERP, биллингов, собственно такая картина. Первое - что такое БИЛЛИНГ и с какого перепугу его хотят стратифицировать? Примерный ответ - ноги растут от стандартизации и метрологии, типа "Вы же предоставляете определенные объемы в разрезе услуги нужно проходить сертификацию, поверки и т.д., без нашей бумажки ни как". И тут возникает вопрос. Первый. Есть Облэнерго который отгружает услугу электроэнергию, да там стоит узел учета который проходит проверку, но никто не требует от Облэнерго сертифицировать 1с бухгалтерию. Та же фигня и в магазинах, там есть весы, которые подлежат поверке, кассовые аппараты которые регятся в налоговой, но никому нет дела до формы бух учета. Тогда с какого перепугу НКРЗИ пытается выносить мозг операторам и провайдерам. Второй. Банальный бух учет на современном уровне перешел в систему управления предприятием и любой билинг есть определенная реализация управления предприятия на определенном уровне интеграции задач. Все оно перешло под бренд ERP. Если решать вопрос фундаментально, то стоит посмотреть в сторону готовых продуктов, например Топ 10 ERP систем для Украины. Пообщавшись с несколькими крупными и не особо операторами картина вырисовалась следующая ситуация - "чтобы не выбрал, все равно точить под себя". Отсюда, выбор коммерческого биллинга это подсадка на иглу. Так как коммерческие билинги как правило закрыты и не позволяют самостоятельно влезть в код, отсюда, оператор обречен работать именно с выбранной конторой, монополия и стоимость сапорта выше неба. Поэтому было проанализировано несколько ERP, установлено и протестировано, остановился на двух открытых ERP, https://www.odoo.com/ и http://ubilling.net.ua/ odoo, амбициозная система, имеется модуль "Менеджер ISP", но на версию 8.0 Версия 8.0 переходящая, с 9.0 и дальше поменяна вся архитектура системы и миграция от до 8.0, к 9.0 и далее обходится ни много ни мало 1000 евро за 1000 строк. Накатил 8.0, подтянул модуль ISP, покурил. По всей вероятности понимание учета у нас и у них кардинально разное, поэтому мозги вынесло наизнанку. Накатил 11.0, покурил. Функционал потрясающий, но что с ним делать не совсем понятно, перевод машинно-логическо-ручной, может поставить жирный крест от миграции стажера к специалисту. Накатил ubilling, если с odoo убил два дня и после нажатия на очередную кнопку оказывалось что нет той и иной библиотеки, то на ubilling реально ушло 10 минут. По функционалу, все доступно и интуитивно понятно. Коды открытые, имеется социальная поддержка в лице операторов которые юзают систему. После изучения вопросов по форумах и хотелок, вырисовалось несколько пунктов которые все же придется перетачивать, но в целом проект может быть взят за основу. Как следствие остановился на ubilling. Теперь по хотелкам пока их три, для обсуждения вопросов открыл темы. 1. Права, введение расширенной настройки прав 2. Требуется внесение таблицы "все-ко-всем" 3. Требуется эмулятор StarGazerа.

Вот взял первое что в голову взбрело, а получается даже прикольно... я бы сказал передает

Муж. - НЕ БУДИ ВО МНЕ ЗВЕРЯ! Жена. - Да не боюсь я твоего хомячка.

Шо за тема? А то может, "мужики и не знают!" (с) Олександр Жаров: Роскомнадзор погрожує заблокувати facebook