Комментарии 24
Стать архитектором с помощью курсов невозможно априори.
Мне кажется описаны рассуждения аналитика, а не архитектора. Архитектор продумывает реализацию под конкретное ТЗ. Если в аналитик в ТЗ указал, что нужен контроль отрицательных остатков, то он должен быть.
Разрешать минусовые остатки можно только на кассах, где покупатель стоит с товаром. В других случаях (опт) нельзя. Например в резерве по Контрагент1 стоит предоплаченный товар. Пришел Контрагент2 и менеджер продал ему этот товар. Реализация провелась в минус, но менеджеру на это все равно, ему главное продать и получить свой процент. Далее пришел Контрагент1 за своим оплаченным товаром, а его нет. (и следующая поставка через полгода....)
Немного не так. Вы оперируете понятием свободный остаток (разность всего остатка и резерва). Так вот если вы включили резервирование, то надо включать и контроль отрицательных остатков. А опт или розница уже неважно. Приведу реальный пример:
Компания решила открыть склад-филиал. До этого она работала через резервирование. И эту схему тоже включили. Здесь же решили устроить магазин для клиентов-продавцов. Предприниматель ходит по залу и набирает нужный товар. В общем почти обычный магазин, но торговля только по договору с ИП и юр. лицами. Так вот он приходит с товаром на кассу, а тот зарезервирован. Вывод - не надо смешивать схемы. А если резервируйте, то оставляйте товар из зала продаж, если успеете.
Архитектор 1С не занимается расследованием. Он занимается проектированием инфраструктуры под потребности внедрения и разработки системы как набора ПО.
При разработке всё равно приходиться всё анализировать. Бездумно писать код, как-то не по "феншую". Хотя встречал таких, что говорили у нас этого не будет, а потом всё таки случалось и приходилось переписывать код и каким-то образом исправлять возникавшие в последствии ошибки, но уже в рабочем продукте.
Ситуация была такая (не в 1С, но пути переплетались, т.к. там система была написана под менеджеров и закупку в начале развития из организации в корпорацию), до ругани мне доказывали, что не будет организация менять ИНН и не будет валют кроме USD и RUB, как итог, все остались при своём мнение, но через год им пришлось дописывать/переписывать код. Ну таких ситуаций было много и всё равно люди не прислушивались.
Я так-то получается в "одном флаконе" аналитик, архитектор, разработчик и тестировщик.
Есть наблюдение из жизни (фактически - правило): "Если менеджеры заявляют, что такого события никогда не будет - значит, такое событие обязательно произойдет, и в достаточно скором времени".
Да, и еще из часто попадающегося: "у нас всё одинаково и единообразно, по единому правилу для всех, и никаких исключений из правила нет. Кроме одного. И еще одного."
Из-за того, что в платформе 1С косяк, что он не может нормально без нормальных блокировок обрабатывать контроль отрицательных остатков (а в 1С еще много и других таких своеобразных косяков), то роль архитектора в том, чтобы придумать основание почему это не надо и сделать костыль ? Интересный подход.
Да, если есть внешние кассы, то включение контроля отрицательных остатков не имеет особого смысла. Но если касс нет вообще ? Или есть кассы, но работают в онлайне. У нас есть клиенты, у которых включен контроль отрицательных остатков на кассе (!!), и работают уже как-то несколько лет. И никаких проблем не было - ни одного отрицательного остатка, а бухгалтера счастливы. Да, я сам лично понимаю, что у подхода есть свои недостатки, но если клиент хочет, то не надо прикрывать кривость платформы 1С, а просто сделать, как он хочет, под его ответственность.
Нет в платформе косяков с обработкой отрицательных остатков. Контроль отрицательных остатков - это прикладной уровень, "уровень конфигурации". "Счастье бухгалтеров" - это одно, а адекватное отражение в учете (по всем разрезам)- совсем другое.
Косяк платформы в том, что нельзя легко, прозрачно и, главное, надежно сделать контроль отрицательных остатков (причем это маленький частный случай, контроли могут понадобится значительно сложнее). В том же lsFusion это делается одной командой CONSTRAINT, и работает как часы самостоятельно решая все вопросы с блокировками (а точнее с повторение транзакции в случае CONFLICT UPDATE). Причем в lsFusion нет регистров на уровне платформы, а сама логика регистров делается легко на "уровне конфигурации".
CONSTRAINT balance(Stock st, Sku sk) < 0
MESSAGE 'Остаток по товару на складе должен быть положительным';"Счастье бухгалтеров" - это одно, а адекватное отражение в учете (по всем разрезам)- совсем другое.
Какое отношения ограничение имеет к адекватному отражению в учете ? Это просто запрет на сохранение изменений, приводящих к отрицательным остаткам.
Такое. У меня физически с одного склада идет розничная и оптовая торговля. формально - по требованиям государства, я обязан торговать с разных складов (и по разным правилам). поэтому на розничном у меня отрицательные остатки разрешены, а контролируются остатки по совокупности складов.
В вашей фузине® реализована лишь одна модель, которую вы когда-то впервые увидели. а реальность - она шире
В фузине никакие остатки не реализованы. Это делается на прикладном уровне. И в зависимости от того как там сделать, так и будет.
Контролируются остатки по совокупности складов
То есть Вы все таки реализовали то, что предлагал разработчик, но отверг архитектор 1С ? И каким же образом ? Вешаете блокировки на каждый товар перед проведением ?
В фузине никакие остатки не реализованы. Это делается на прикладном уровне. И в зависимости от того как там сделать, так и будет.
Значит, критических преимуществ фузины по сравнению с 1с нет.
То есть Вы все таки реализовали то, что предлагал разработчик, но отверг архитектор 1С
Архитекторы конфигурации сделали возможность реализовать большинство задач параметрической настройкой (а кодеры реализовали) , кодинга потребовалось совсем немного
Архитекторы какой конфигурации что реализовали ? Почему вообще тогда разработчика привлекали, если можно просто настройкой включить и все ? И даже если в этой конфигурации не было реализовано, то почему просто не взять код из типовой и скопировать (ну с небольшими изменениями). Зачем вообще привлекать архитектора тогда ? Ничего не понятно, но очень интересно...
Значит, критических преимуществ фузины по сравнению с 1с нет.
Критических преимуществ просто огромное количество. Все они описаны в статье "Почему lsFusion, а не 1С". Но одно из главных, что lsFusion - открыт и бесплатен.
Реализовали - архитекторы типовой КА. "Настройкой" решили основную часть. Кодом - оставшуюся, очень небольшую. никакого дополнительного архитектора не привлекали.
Критических преимуществ просто огромное количество.
Это вы считаете их критическими преимуществами. А не те, кто использует. Ну а уж бесплатность для программ для коммерческого применения как критическое преимущество - вообще смешно.
Интересно, а как не блокируя данные, ваши транзакции защищены от неповторяющегося чтения и других аномалий?
Ну собственно версионными СУБД (и update conflict'ами в частности), то есть СУБД все записи читает на момент начала транзакции. А в момент записи СУБД проверяет версию записи, если она изменилась, кидает update conflict, который платформа ловит и просто заново проводит транзакцию. С phantom read проблема решается или материализацией (которая в платформе прозрачна, тут немного про это), ну или "true serializable" в Postgres.
Так а в чем преимущество? Стратегия другая, но суть одна - изменять данные остатков можно только последовательно.
Оптимистичных блокировок по сравнению с пессимистичными? Более высокая масштабируемость, надежность и т.п. То есть если вы начнете проводить инвентаризацию (или запустите большой отчет, хотя это иногда решают делая версионный режим тольк для отчетов) у вас вся база не ляжет. Ну и накладные расходы меньше, так как обычно данные неконкурентны (если у вас не биржевая торговля ограниченных позиций например).
Ну да. Просто вся очередь документов отменит транзакцию и начнет снова. Для юзера думаю будет выглядеть это одинаково.
Кстати, если вы думаете, что 1с блокирует таблицы в начале транзакции, то это не так. Для контроля остатков достаточно заблокировать данные в конце. И только по тем наборам измерений, которые меняются. А вот если вы "на лету" себестоимость считаете, то все печальнее. Но к счастью 1с отказалась от такой методики в современных конфигурациях. И для расчета таких данных версионирование записи не спасёт. Придется блокировать
Архитектор 1С - это ещё один миф, в большом "тазу" одноразовых конфигураций. Как только Аналитику 1С (которых всё меньше и меньше) становится скучно от рутины, по своей природе он начинает придумывать: кубики, принципы, стрелочки, должности всякие, направления и прочее "ляля-тополя", а результат один и тот же, как была ФИФА/ЛИФА так и осталась. А в действительности надо "тупо" наделать скринов и пару слов "было так, надо вот так".
На мой взгляд вся причина в скудности 1С, на дворе 21век, а мы всё топчемся вокруг стандартных принципов 1С(старый друг(77) лучше новых двух), где ООП? а где Framework-и? ну и остальное недоделанное, а то куда не ткнись все пишут dll-ку.
Автору респект, идея хорошая, но не для 1С это точно:)
Я настолько старый, что помню как уборщиц переименовали в менеджеров по клинингу.
Теперь боги маркетинга взялись за 1С.
Непонятно только почему опять заимствования.
Гораздо приятнее звучит курс: Титулярный советник 1С или Коллежский ассесор 1С
Так же непонятно чем он занимается, зато как гордо звучит
Зачем нужен архитектор 1С