О системах планирования ресурсов предприятия Scala, iScala
38 subscribers
3 photos
46 links
пользователям ERP систем Scala 5.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2, iScala 3.3, iScala 3.4, iScala 3.5 (и так далее)
Download Telegram
Сегодня позвонил хедхантер:
- Вы директор компании?
- Я, вот только компания ликвидирована
- Это ничего, может быть вы новую зарегистрируете, а мы вам бесплатно разместим вакансию и найдём сотрудников
- Не сможете вы мне найти сотрудников, очень узкая специализация, обычно, наоборот, ко мне обращаются, чтобы я кого-то посоветовал
Но звонящая сотрудница не слушает и продолжает пытаться убедить меня зарегистрировать личный кабинет. Смешно... Пришлось повесить трубку.
Пожалуйста, не звоните мне с предложением найти специалиста. Всех специалистов по iScala в СНГ и окрестностях я сам знаю. А если кого не знаю, то он не специалист.
Гора родила мышь
Ещё раз убедился в убогости всего, что делает Фейсбук (или как его там? запрещён в России и слава богу!). Даже украсть идею у Telegram и то не смог по-человечески, слепил в своём WhatsApp’е не аналог канала Telegram, а какое-то не пойми что. Я давно бы с WhatsApp'ом расстался, как это сделал со Skype, но пока ещё есть те, кто продолжает им пользоваться и не открыл для себя Telegram, например 😊
https://scala.org.ru/gora-rodila-mysh/
Аудиторы не доверяют «внешним» отчётам, запросили «родные» отчёты из системы. С одной стороны, подход абсолютно правильный. Информация, выгруженная в Эксель не заслуживает доверия. Непонятно, как она выгружена, непонятно, редактировалась ли она после выгрузки и т.п. В этом отношении отчёт, полученный непосредственно из системы, заслуживает гораздо большего доверия. А, с другой стороны, этот подход в какой степени разумен, в такой же и ущербен 😊
https://scala.org.ru/auditory-ne-doverjajut-vneshnim-otchjotam-zaprosili-rodnye-otchjoty-iz-sistemy/
Сегодня в Пушкине состоялась встреча узкого круга бывших сотрудников офиса Эпикор в Санкт-Петербурге. Встреча прошла в теплой дружеской обстановке 🙂
Можно по-разному назначать права сотрудникам, вводящим в систему операцию по перемещению между складами, но на мой взгляд, самое главное - это соблюсти принцип "сдал - принял", когда в процессе участвуют обе стороны. А если это не соблюдается, то все эти разговоры про какие-то супер-пупер права - это просто "надувание щёк", какой-то голимый пиар, прости Господи 😕
https://scala.org.ru/neispovedimy-puti-piara-prosti-gospodi/
И снится вам сон: будто вы должны пройти по канату, натянутому над пропастью, без страховки и без тренировки. Вы не помните, как ступили на этот канат, не помните, как удалось пройти половину пути, но нутром чуете, что оставшуюся часть пути пройти не сможете. А назад уже нельзя, туда ровно столько же, что и на другую сторону. Вы замираете, с ужасом пытаетесь держать равновесие, ноги подкашиваются, голова кружится, шаг вперёд, вы теряете равновесие и начинаете падать, судорожно пытаясь схватиться то ли за проплывающий мимо канат, то ли за воздух и летите вниз. И тут вы просыпаетесь в холодном поту и понимаете, что на какой-то момент отключились прямо на совещании по переходу на новую систему. «Мы не можем пройти без страховки», — бормочете вы. «Что с вами?», — спрашивают вас коллеги. «Вы побледнели, может открыть окно?». «Мы не сможем без страховки, мы упадём!»
https://scala.org.ru/strashnyj-son-kanatohodca-novichka/
Ну, вот, наконец-то 😁
Как давно я жду, когда появятся новые материалы новых авторов. Читайте статью Рустама Алиева на тему внешнего вида списка отчётов сервера отчётности SQL Server Reporting Services:
https://scala.org.ru/nemnogo-jestetiki-v-ssrs/
Я никогда ранее не смешивал свои политические взгляды и профессиональную деятельность. Но не в этот раз. Поводом послужило обращение одного из моих коллег из международной компании, прекратившей свою деятельность на территории России
Когда то мы наивно верили в то, чему нас учили. В частности, одна из книг 4-го курса была посвящена дискриминации. Ну, все же знают, что дискриминация - это зло. По любым основаниям: религиозным, расовым, половым, возрастным и так далее. Спустя некоторое время пришло осознание того, что любая идея, доведённая до абсолюта, дурно пахнет. Так и в этой области стремление обеспечить права меньшинств приводит иногда к ущемлению прав представителей большинства. А далее, мы узнали и другую реальность, что можно (и нужно) подвергать остракизму представителей "неправильной" страны. Я давно уже понял, что всё, чему нас учили в Школе Бизнеса Открытого Университета - это враньё...
https://scala.org.ru/diskriminacija-dopustima-v-sovremennom-mire/
Который раз возникают мысли о возможности воспроизведения функциональности iScala средствами SQL сервера. Мой коллега Игорь Чанышев уже давно с помощью своего RM2 дорабатывает или фактически переписывает то, что в iScala работает не самым оптимальным образом или отсутствует, а может быть и работает наилучшим образом, но у клиента отсутствует соответствующая лицензионная опция или версия настолько старая, что её трудно совместить с современными требованиями. Впрочем, какая разница, давайте просто поразмышляем, что бы я оставил, что выкинул, а что усовершенствовал 😄
https://scala.org.ru/esli-by-ja-popytalsja-vosproizvesti-funkcionalnost-modulja-upravlenie-zapasami-iscala-chto-by-ja-usovershenstvoval/
Ранее пользовался недокументированной утилитой xp_dirtree, но недавно столкнулся со сложностями её использования. Сначала она не хотела работать без всякого объяснения причин с расшаренной подпапкой вида \\ИМЯСЕРВЕРА\ИМЯРАСШАРЕННОЙПАПКИ\ИМЯПОДПАПКИ\ИМЯЕЩЁОДНОЙПОДПАПКИ. Как оказалось позже проблема оказалась в том, что пользователю, от имени которого работает сервис SQL сервера, были предоставлены права на конечную подпапку, но не были предоставлены права на вышележащую. С правами разобрались, хранимая процедура заработала, но спустя некоторое время возникла задача получения не просто списка файлов, а ещё и дат их создания, а эту информацию xp_dirtree не предоставляет. Пришлось воспользоваться процедурой xp_cmdshell и досовской командой dir. Вполне возможно, что вам это тоже пригодится
https://scala.org.ru/kak-iz-sql-zaprosa-prochitat-spisok-fajlov-v-vybrannoj-papke-i-otsortirovat-po-date-sozdanija/
Помните что я писал в феврале 2019 года на тему сильных и слабых сторон iScala? Тогда я говорил, что сильные или слабые стороны могут быть только в сравнении с чем-то другим, с какой-то другой системой. Возможно, сейчас это покажется смешным, так как «другая система» победила, но победила вопреки, несмотря на то, что является убогой в некоторых очень важных вопросах, и я хочу на них сейчас остановиться.
https://scala.org.ru/v-poiskah-idealnoj-erp-sistemy-2-0/
Продолжение темы «В поисках идеальной ERP системы 2.0»…
Клиент переходит на «новую систему», в которой настраиваются все те же самые интеграции, что и в iScala, но не предусмотрен процесс «утверждения». То есть либо всё делается автоматически, либо вы должны файлы получать вручную и импортировать их в систему также вручную. Причём визуализация поступивших файлов тоже не производится, как это было сделано на базе монитора задач в iScala. В результате мы сейчас обсуждаем «обходной путь» как бы нам получить то, что требуется
https://scala.org.ru/v-poiskah-idealnoj-erp-sistemy-2-01/
Недавно один мой знакомый спросил меня, а почему же на моём сайте нет предложения каких-то услуг для клиентов, ведь обычно сайты преследуют цель в том числе и продать что-то, получить новых клиентов и так далее 😊 И что? Думаете, хоть одна собака удосужилась поинтересоваться, что это ей такое тут предлагают красными буквами? Нет, конечно! Смешно... Или, может быть грустно? Вот и не знаю, как на это реагировать. На этот "игнор" так сказать. Может вы подскажете? 😂
https://scala.org.ru/not-in-husky-happiness-2-0/
Коллеги со стороны клиента сожалеют, что скоро нам предстоит расстаться, они уже полностью перешли на одинэс, мои услуги им больше не нужны, предлагают мне разобраться в одинэс и помочь им его усовершенствовать. А я говорю, что «это» невозможно усовершенствовать. Нет такой возможности. Технологический тупик, неправильный выбор лет этак 25 назад. Это «здание» можно только полностью снести и построить что-то абсолютно новое. Причём строители должны быть другие, свободные от дурных подходов проектирования предыдущего «здания»
https://scala.org.ru/v-poiskah-idealnoj-erp-sistemy-2-1/
Коллеги, я почитал энное количество статей на счет замены западных ERP систем после их ухода из России российскими продуктами, но так ничего и не понял, в смысле, есть ли у нас какая-то собственная достойная система (1С не предлагать!) или система с открытым исходным кодом, которую можно было бы взять за основу. Все статьи написаны одинэсниками, поэтому об объективности речи не идёт. Можете поделиться своими мыслями, где мы окажемся, когда всё большему количеству компаний станет очевидно, что однабуква-однацифра - это путь в тупик?
Прошло 20 лет с тех пор, как 14.09.2004 был запущен проект «Для «Scalaлазов»» в виде форума для общения пользователей ERP систем семейства Scala/iScala на русском языке. Незадолго до этого Epicor приобрел компанию Scala и, как в большинстве подобных случаев, начались изменения, сопровождавшиеся, в том числе, и «исходом» из компании опытных сотрудников в компании-партнёры, компании-клиенты и т.д. И нам нужно было где-то общаться. Так и появился «Форум пользователей ERP систем Scala, iScala» как попытка собрания материалов по Scala/iScala, опыта, мнений и предложений его участников. Точнее, 20 лет исполнится завтра. Но завтра выходной, поэтому пишу сегодня 🙂
https://scala.org.ru/20-let-proektu/
Независимо от того, кто обслуживает Ваши ИТ системы и/или кто обслуживает конкретную систему (например, ERP), установленные на ваших локальных или арендованных серверах, собственником установки системы являетесь вы, а те, кто её обслуживают - это просто нанятые организации, которые не могут узурпировать права на доступ к ней!
https://scala.org.ru/o-vzaimootnoshenijah-s-kompanijami-obsluzhivajushhimi-vashi-it-sistemy/
Помните, сколько было сломано копьев (или копий? 😁) с "разнесением" многострочных проводок? Только благодаря Рушану в тех, компаниях, где количество проводок было не запредельным, хоть что-то удавалось преобразовать в привычный для наших бухгалтеров вид дебет, кредит, сумма и построить разного рода "шахматки". Потом R&D этим озаботился, но вместо того, чтобы посоветоваться с Рушаном, они, как всегда, наваяли что-то запредельное, а конвертор из рушановской таблицы RG_MEMORY в новые "билинейные проводки" так и не сделали. В итоге так никто и не перешёл.