Здравствуйте, pagid_, Вы писали:


_>>>Правильно понимаю, что разговор про товарные документы и подбор партий с которых идет списание? Что мешало сделать транзакции по строчкам документа (наименованиям/товарным позициям или как они там у вас называются)
S>>То есть не читатель
S>>

S>>Затем сделали только контроль по количеству, а по всем регистрам проводили по ночам или сливали в другую базу где проводили скопом.

_>Читатель. И писатель. Но я не знаком с вашей терминологией и что такое "регистры" могу только догадываться.
_>Метод проведения ночью мне известен, но это очень-очень вынужденное решение приводящее к последующему геморрою, уж тем более, если в другой базе. А за вот эти "другие базы" включая штатные — складской учет, з/п, бухгалтерия 1С как раз и ненавидят имевшие возможность работать с другими решениями.
Еще раз. Можешь делать все в одной конфигурации. Есть ERP, комплексные итд. Как хочешь, так и организуй учет.
Главное, что бы все было быстро!

S>> Но как правило нужно еще учет по складам, местам хранения, резервам, взаиморасчетам.
_>Взаиморасчеты совершенно отдельная проблема, она не по товарам, а по документам.
Но зависит от того, как ты провел. Ты же хочешь что бы было в транзакции по строкам. Конечно можно провести взаиморасчеты в концею
Но по другим учетным регистам это надо сделать.

S>> Набивают документы и сотрудники, и клиенты делают заказы через вэб интерфейс и апи. Контроль нужен по всему документу.
S>>Можно конечно схемы придумать, что если нет на остатках то корректировать в момент проведения.
_>Разве заказы должны вызвать проведение документов? Там же вопрос только в остатке по резерву.
Конечно. Это счет резервирование товаров.

S>>Но построчно делать транзакции это более ресурсоемко, так как в итоге придется сделать больше запросов вместо одного по номенклатуре документа (остатки, резервы), придется по каждой строке документа.
_>Зато транзакции короче, да и иначе все точно те же запросы все равно придется делать построчно, но в рамках одной транзакции.
Ну и, что что короче? Если ты блокируешь регистры только по определенным товарам, то вероятность того что они конфликтуют с другими транзакциями небольшая.
Вернее можно оценить вероятность конфликта по статистике выписке товаров. Возможно стоит сделать проведение редко используемых скопом, а часто используемых отдельно.
Еще раз все зависит от скорости проведения. И возможность проведения построчно есть.

S>> В любом случае так можно сделать. Любой каприз.
S>> Можно делать записи в регистры вне модуля проведения.
_>Понятно, что можно. Но у меня вопрос из чистого любопытства, все делается на 1С-ном языке, или платформа берет на себя выполнение некоторых операций в стандартном варианте?
Это все в стандартном. Куча различных конфигураций. Как я НС писал

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

S>> Угу. Он просто не сталкивался с нормальным учетом.
_>Ну я сталкивался, но не в 1С. потому и любопытно.

S>> Например в бухгалтерии один план счетов в котором у каждого счета различный набор субконто и все это хранится в одной таблице.
S>> С точки зрения программирования это тип Object или как в TS тип который может принимать несколько типов.
_>С точки зрения программиста это запись в таблице "План счетов", разный набор аналитик, обеспечивается структурой БД. Удобство работы с ними средствами имеющимися во встроенном языке.

S>> Поэтому как правило все сливается в определенные конфигурации с Бух учетом зарплатой итд.
_>Выше про это уже писал.


S>> А так в 1С есть различные регистры с которыми можно быстро работать.
_>часто употребление этого термина, а так же упоминание того, что информацию нужно разносить по множеству "регистров" как раз и вызвало сомнение в эффективности решений использованных в 1С
Регистр это таблицы содержащие остатки, движения по измерениям
https://artemvm.info/information/uchebnye-stati/1s-predpriyatie/chto-takoe-registry-i-zachem-oni-nuzhny/

Если тебе не нужны остатки и движения, то использутся регистры сведений. В отличие от справочников, там легко удалять, добавлять наборы по индексам (измерениям)
Каков смысл в провенедении документа? Он должен не только записаться, но и изменить учет.

Не хочешь ничего менять не меняй.Все завист от того, что тебе нужно.
Раз тебя это тема заинтересовала, значит у тебя есть опыт в учетных системах. Главное слово "учет". Все зависит от того что ты собираешься учитывать.

S>> Да в 1С надо избегать подписок при изменении регистров.
_>Да, да. Штирлиц достал из сейфа за писку Бормана. Борман дико сопротивлялся.

Ну это некоторые тонкости. Извини, что потратил на тебя время

Здравствуйте, pagid_, Вы писали:


_>>>Правильно понимаю, что разговор про товарные документы и подбор партий с которых идет списание? Что мешало сделать транзакции по строчкам документа (наименованиям/товарным позициям или как они там у вас называются)
S>>То есть не читатель
S>>

S>>Затем сделали только контроль по количеству, а по всем регистрам проводили по ночам или сливали в другую базу где проводили скопом.

_>Читатель. И писатель. Но я не знаком с вашей терминологией и что такое "регистры" могу только догадываться.
_>Метод проведения ночью мне известен, но это очень-очень вынужденное решение приводящее к последующему геморрою, уж тем более, если в другой базе. А за вот эти "другие базы" включая штатные — складской учет, з/п, бухгалтерия 1С как раз и ненавидят имевшие возможность работать с другими решениями.
Еще раз. Можешь делать все в одной конфигурации. Есть ERP, комплексные итд. Как хочешь, так и организуй учет.
Главное, что бы все было быстро!

S>> Но как правило нужно еще учет по складам, местам хранения, резервам, взаиморасчетам.
_>Взаиморасчеты совершенно отдельная проблема, она не по товарам, а по документам.
Но зависит от того, как ты провел. Ты же хочешь что бы было в транзакции по строкам. Конечно можно провести взаиморасчеты в концею
Но по другим учетным регистам это надо сделать.

S>> Набивают документы и сотрудники, и клиенты делают заказы через вэб интерфейс и апи. Контроль нужен по всему документу.
S>>Можно конечно схемы придумать, что если нет на остатках то корректировать в момент проведения.
_>Разве заказы должны вызвать проведение документов? Там же вопрос только в остатке по резерву.
Конечно. Это счет резервирование товаров.

S>>Но построчно делать транзакции это более ресурсоемко, так как в итоге придется сделать больше запросов вместо одного по номенклатуре документа (остатки, резервы), придется по каждой строке документа.
_>Зато транзакции короче, да и иначе все точно те же запросы все равно придется делать построчно, но в рамках одной транзакции.
Ну и, что что короче? Если ты блокируешь регистры только по определенным товарам, то вероятность того что они конфликтуют с другими транзакциями небольшая.
Вернее можно оценить вероятность конфликта по статистике выписке товаров. Возможно стоит сделать проведение редко используемых скопом, а часто используемых отдельно.
Еще раз все зависит от скорости проведения. И возможность проведения построчно есть.

S>> В любом случае так можно сделать. Любой каприз.
S>> Можно делать записи в регистры вне модуля проведения.
_>Понятно, что можно. Но у меня вопрос из чистого любопытства, все делается на 1С-ном языке, или платформа берет на себя выполнение некоторых операций в стандартном варианте?
Это все в стандартном. Куча различных конфигураций. Причем куча 1Сников могут адаптировать стандартную конфигурацию, под твои требования. Любой каприз!
И не дорого. Так как конкуренция, и простота языка и учетных классов (справочники, регистры, документы итд).

Как я НС писал

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

S>> Угу. Он просто не сталкивался с нормальным учетом.
_>Ну я сталкивался, но не в 1С. потому и любопытно.

S>> Например в бухгалтерии один план счетов в котором у каждого счета различный набор субконто и все это хранится в одной таблице.
S>> С точки зрения программирования это тип Object или как в TS тип который может принимать несколько типов.
_>С точки зрения программиста это запись в таблице "План счетов", разный набор аналитик, обеспечивается структурой БД. Удобство работы с ними средствами имеющимися во встроенном языке.

S>> Поэтому как правило все сливается в определенные конфигурации с Бух учетом зарплатой итд.
_>Выше про это уже писал.


S>> А так в 1С есть различные регистры с которыми можно быстро работать.
_>часто употребление этого термина, а так же упоминание того, что информацию нужно разносить по множеству "регистров" как раз и вызвало сомнение в эффективности решений использованных в 1С
Регистр это таблицы содержащие остатки, движения по измерениям
https://artemvm.info/information/uchebnye-stati/1s-predpriyatie/chto-takoe-registry-i-zachem-oni-nuzhny/

Если тебе не нужны остатки и движения, то использутся регистры сведений. В отличие от справочников, там легко удалять, добавлять наборы по индексам (измерениям)
Каков смысл в провенедении документа? Он должен не только записаться, но и изменить учет.

Не хочешь ничего менять не меняй.Все завист от того, что тебе нужно.
Раз тебя это тема заинтересовала, значит у тебя есть опыт в учетных системах. Главное слово "учет". Все зависит от того что ты собираешься учитывать.

S>> Да в 1С надо избегать подписок при изменении регистров.
_>Да, да. Штирлиц достал из сейфа за писку Бормана. Борман дико сопротивлялся.

Ну это некоторые тонкости. Извини, что потратил на тебя время