Если очень уж интересно, откликайтесь на заявки хендхантеров из 1С, изучите бэклог, увольтесь по результатам испытательного срока — минимум действий, а получите инсайды настолько секретные, что их запрещено разглашать на ежегодных встречах в Космосе (содержимое которых тоже запрещено разглашать)
Кстати, если бы я админил сервера 1С, то сделал бы автоматический форвардинг с RU на UA и EU — раз «на верху» приняли решение не пересекать национальные поддержки, но оставить единый сервер.
А меня больше волнует вопрос: почему пользователей ИТС так ненавидите? В интернете полно ссылок на ИТС-статьи (и сами представители 1С любят такие давать на партнерсе), но при попытке перейти на нее получаешь — «Доступ к данному материалу ограничен». Далее нужно менять домен с RU на UA и лишь после этого шаманства можно читать статью. Зачем? Ведь содержимое ИТС в технических разделах идентичное до последнего знака препинания. И сервер один и тот же, что позволяет авторизироваться на обоих порталах под одной учеткой.
Слова не специалиста, а обиженного пользователя.
(от куда вы вообще узнали такие умные слова как «платформе 8.3»?)
На практике в режиме конфигуратора для справочников выставляются настройки — «нужен ли список последних указанных в поле ввода элементов?», «можно ли разрешить создание новых элементов при вводе?». Далее разработчик прикладного решения сам решает какое поведение системы будет более удобным для пользователей его продукта.
Эффективность данного предложения очень сомнительная скорее отрицательная.
Двойной или тройной стук мышкой (даже если и клавиатурой сначала Tab потом F4) по одному реквизиту это уже не эффективно.
Новый документ — новая жизнь! Для чего эта история выпадающего списка из 10 последних?
Я поддерживаю старые конфигурации на обычных формах и меня иногда просят реализовать подобные «списки историй» — потому что это удобно и экономит людям время.
Вы запутались. Еще раз по полочкам:
1) Если внутри открытой транзакции происходит ошибка, то происходит откат ранее записанного и прерывание выполнения (без использования попыток мы вообще не попадем на «В данной транзакции уже происходили ошибки»)
2) Не очень знаком с неявными транзакциями «попыток» (они явно не полноценные, так как если в попытке сделать запись нескольких элементов и на одном из них получить ошибку, то предыдущие останутся записанными в базу), но хорошо, что они закрываются и не выходят за рамки блока try-catch. А тем временем у нас «сверху» все еще есть активная транзакция.
3) Использование «попытки» внутри активной транзакции позволяет продолжить выполнение кода после «пойманной» ошибки, но каждая попытка продолжить работу с СУБД (даже чтение) будет генерировать новую ошибку (вышеозвученную), пока транзакцию программно не закроют (или не прекратится выполнение кода, но тогда произойдет откат).
Саентологов с разными уровнями ОТ на просторах СНГ еще больше чем свидетелей Иеговы (90-е давно в прошлом). И это если не упоминать про скрытую саентологию, которую преподносят как админтехнологию Хаббарда для эффективного бизнеса (WISE). А еще вспоминаем, что реклама их Дианетики весит в каждом вагоне метро…
Но ничего принципиально не мешает нагенерить себе свой нужный набор тайлов и использовать его как угодно.
Тоже этот момент резанул в статье и далее в комментах. Можно же написать бота, который за пару недель выкачает всю детализированную Польшу и верхние уровни остального мира. Ложим все это на собственный сервер и указываем его адрес в лефлетовском или опенлееровском скрипте. И никаких затрат больше нет.
Современные автомобили — это по сути те же брички и колесницы, на которых ездили тысячу лет назад. Где новые технологии? Машины с автопилотами они выпускают…
Поздравляю с тем, что вам удалось ваши теоретические наработки реализовать на практике. Хотя немного смущает тот факт, что они лежали на полочке шесть лет с момента выхода в печать в 2012 году (ДМК Пресс). Слышали анекдот про «неуловимого Джо»?
Далее немного замечаний:
1) структура данных 1С, попросту этого не позволившая,
Чем же структура данных 1С хуже/лучше любой другой структуры поверх реляционных баз данных? Не все доступно «из коробки» (как и всюду), но при желании можно реализовать любое архитектурное пожелание.
Товары характеризуются номенклатурой, а деньги не имеют такого свойства, и т.д.
Так ведь характеризуются валютой! :)
Хотя представление товаров вместе с деньгами – например, в рамках заказа, – было бы более наглядным.
Некоторые заказчики просят — делаем.
благодаря справочнику условных единиц, типовому в 1С
Вы бы хоть уточнили с какой конфигурацией работали. В тех типовых, с которыми я работал, такого справочника не было — только справочник валют. Может какие-то «управление корпоративными финансами»?
Когда дата просмотра отодвигается в прошлое, параметры остаются текущими, что не дает возможности получить корректный взгляд из прошлого. Допустим, срок погашения обязательства поменялся. Вытянуть из 1С эту информацию для размещения в отчете оказалось проблематично
Печально слышать, что для программиста, который работал с вами на проекте, такая ерунда составила неразрешимую проблему.
Хорошо жить в России и делать вид, что всего остального СНГ не существует. К примеру, у нас в Украине все до сих пор сидят на старой бухе, так как на управляемых формах вышла относительно недавно и большая часть людей, которые пытались на нее переходить, вернулись к предыдущей стабильной версии. Та же ERP для Украины вышла буквально на днях — 20 декабря 2017 года. Во всяких Киргизтанах, Таджикистанах, Грузиях и Армениях дела обстаят еще хуже.
Но ведь в торговых точках все тоже самое :) Адресное хранение — торговые агенты (у более богатых поставщиков мерчи) проверяют наличие своего товара на определенной полочке в определенном порядке. В сигаретных отделах каждая пачка буквально в своей ячейке и опытный продавец берет товар не глядя. Ограничение отпуска — продажа алкоголя при наличии паспорта или водительских прав. Требования к ценообразованию — в продаже табачной и алкогольной продукции нельзя указывать цены с потолка, они регулируются законодательно (гуглите МРЦ). Сертификаты качества и сроки годности (партионный учет) — архиважные элементы при торговле скоропортом таким как молочка и мясные изделия. Это вам не активированный уголь с вьетнамской звездочкой :)
А что в этом хорошего? Если бы покупаемые товары и услуги существовали исключительно в блокчейне Биткойна (это же у нас все таки платежное средство, инструмент обмена), то откат транзакций некоторого кластера сети из-за расхождения в консенсусе с другими узлами сети не был бы проблемой. Но текущее решение «по консенсусу» будет воровать деньги из кармана продавцов, которые уже отгрузили товары и выполнили свои услуги. Получается, что продавцам нужно регулярно проверять историю своего кошелька, сверять с предыдущими состояниями, что бы вовремя заметить «пропажу», связываться с покупателями и выпрашивать повторение платежа. Существуют как бы единые «деньги», но несколько параллельных виртуальных реальностей их траты; и ты заранее не угадаешь повезло тебе или нет.
Напомню историю — в 2008 году Египет на день остался без интернета из-за обрыва кабеля в Средиземном море, а в 2011 Армения на 12 часов лишилась доступа в общий интернет, из-за охотников за драгметалами. А еще помним что просто гигантское количество майнеров и держателей биткойна живут в Китае за их великим «фаерволом» и ждут решения генсека о своем отключении. Т.е. внутри некоторой територии продолжает существовать своя экосистема биткойна — продавцы на местных сайтах по прежнему продают, покупатели покупают, майнеры майнят..., а потом бах и все пропало из-за починки доступа в остальной мир :(
Спасибо за результаты интересной работы. Чувствуется знание внутренней кухни Мисты и трепетное продолжительное отслеживание истории общения ее пользователей. Но историю форума можно было рассказать и без результатов данных изысканий, жаль что исследование ушло в степь «кто кого троллил» и «за что забанили»…
Когда мне рассказывали про корпусную лингвистику, я мысленно крутил пальцем у виска — тысячам лингвистов нефиг делать как изучать частоту встречи словосочетаний в привязке к историческим событиям и прочие синтетические ресерчи. А вот на таком датасете столько всего интересного можно было бы выжать — как изменялась частота вопросов «о взломе», «сбросе паролей», «установке на линуксе» и прочих типовых вопросов при переходе между 8.0, 8.1, 8.2, 8.3. Как изменялись вопросы связанные с вебом, после выхода 8.2; как изменились вопросы связанные с мобильной разработкой после выхода 8.3. Как повлияло на частоту вопросов по построителю отчетов появление механизма компоновки. Как изменялось соотношение вопросов управляемого и обычного интерфейса после выхода типовых на управляемых формах. И так далее…
После 20 запросов GET запросов форум переставал отвечать. В веб-бекэнде не силен, но подозреваю, что частые запросы с одного ИП отслеживались и на все, что было не похоже на запросы от обычного пользователя, ставился бан. Куча перебранных скачивалок и грабберов сайтов натыкались на те же грабли и шли в корзину. Нужна была свежая идея.
(от куда вы вообще узнали такие умные слова как «платформе 8.3»?)
На практике в режиме конфигуратора для справочников выставляются настройки — «нужен ли список последних указанных в поле ввода элементов?», «можно ли разрешить создание новых элементов при вводе?». Далее разработчик прикладного решения сам решает какое поведение системы будет более удобным для пользователей его продукта.
Я поддерживаю старые конфигурации на обычных формах и меня иногда просят реализовать подобные «списки историй» — потому что это удобно и экономит людям время.
1) Если внутри открытой транзакции происходит ошибка, то происходит откат ранее записанного и прерывание выполнения (без использования попыток мы вообще не попадем на «В данной транзакции уже происходили ошибки»)
2) Не очень знаком с неявными транзакциями «попыток» (они явно не полноценные, так как если в попытке сделать запись нескольких элементов и на одном из них получить ошибку, то предыдущие останутся записанными в базу), но хорошо, что они закрываются и не выходят за рамки блока try-catch. А тем временем у нас «сверху» все еще есть активная транзакция.
3) Использование «попытки» внутри активной транзакции позволяет продолжить выполнение кода после «пойманной» ошибки, но каждая попытка продолжить работу с СУБД (даже чтение) будет генерировать новую ошибку (вышеозвученную), пока транзакцию программно не закроют (или не прекратится выполнение кода, но тогда произойдет откат).
Тоже этот момент резанул в статье и далее в комментах. Можно же написать бота, который за пару недель выкачает всю детализированную Польшу и верхние уровни остального мира. Ложим все это на собственный сервер и указываем его адрес в лефлетовском или опенлееровском скрипте. И никаких затрат больше нет.
Далее немного замечаний:
Чем же структура данных 1С хуже/лучше любой другой структуры поверх реляционных баз данных? Не все доступно «из коробки» (как и всюду), но при желании можно реализовать любое архитектурное пожелание.
Так ведь характеризуются валютой! :)
Некоторые заказчики просят — делаем.
Вы бы хоть уточнили с какой конфигурацией работали. В тех типовых, с которыми я работал, такого справочника не было — только справочник валют. Может какие-то «управление корпоративными финансами»?
Печально слышать, что для программиста, который работал с вами на проекте, такая ерунда составила неразрешимую проблему.
Адресное хранение — торговые агенты (у более богатых поставщиков мерчи) проверяют наличие своего товара на определенной полочке в определенном порядке. В сигаретных отделах каждая пачка буквально в своей ячейке и опытный продавец берет товар не глядя.
Ограничение отпуска — продажа алкоголя при наличии паспорта или водительских прав.
Требования к ценообразованию — в продаже табачной и алкогольной продукции нельзя указывать цены с потолка, они регулируются законодательно (гуглите МРЦ).
Сертификаты качества и сроки годности (партионный учет) — архиважные элементы при торговле скоропортом таким как молочка и мясные изделия. Это вам не активированный уголь с вьетнамской звездочкой :)
Напомню историю — в 2008 году Египет на день остался без интернета из-за обрыва кабеля в Средиземном море, а в 2011 Армения на 12 часов лишилась доступа в общий интернет, из-за охотников за драгметалами. А еще помним что просто гигантское количество майнеров и держателей биткойна живут в Китае за их великим «фаерволом» и ждут решения генсека о своем отключении. Т.е. внутри некоторой територии продолжает существовать своя экосистема биткойна — продавцы на местных сайтах по прежнему продают, покупатели покупают, майнеры майнят..., а потом бах и все пропало из-за починки доступа в остальной мир :(
Когда мне рассказывали про корпусную лингвистику, я мысленно крутил пальцем у виска — тысячам лингвистов нефиг делать как изучать частоту встречи словосочетаний в привязке к историческим событиям и прочие синтетические ресерчи. А вот на таком датасете столько всего интересного можно было бы выжать — как изменялась частота вопросов «о взломе», «сбросе паролей», «установке на линуксе» и прочих типовых вопросов при переходе между 8.0, 8.1, 8.2, 8.3. Как изменялись вопросы связанные с вебом, после выхода 8.2; как изменились вопросы связанные с мобильной разработкой после выхода 8.3. Как повлияло на частоту вопросов по построителю отчетов появление механизма компоновки. Как изменялось соотношение вопросов управляемого и обычного интерфейса после выхода типовых на управляемых формах. И так далее…
Корреляция примерна такая же как между результатом подбрасывания монетки и количеством вспышек на солнце за прошлую неделю.