Последний выдох ГПЖколичество же не с потолка списывается, а с конкретной партии. следовательно по ней общей остаток (списана она уже в ноль или нет) известен. и что с ней будет при изменении прихода - тоже понятно будет

Да забыли про партии. Представим что их нет, только товары.

Вопрос в другом. Можно распровести документ прихода, если после его распроведения остаток станет < 0? Как я понимаю у 1Са какая архитектура, изначально есть только обработка проведения, которая пишет в регистры и помечает для этих записей этот документ в качестве регистратора. При распроведении все эти записи удаляются. При проведении заново выполняется обработка проведения. Как в такой идеологии идет проверка остатка >0 при изменении приходов? Я видимо просто чего то не знаю.

Другими словами как вообще в 1С обычно обрабатывается изменение документов?

MironicoNitro_Junkie,

Если не ставить проверок то уходит в минус.

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

Программист 1сNitro_Junkieпропущено...

200 проверок я имел ввиду все - создание агрегированных объектов (например строка накладной создает партию, позицию расценки, позицию поставки, так как в постсовке invoice'ы объединены с shipment'ами, штук 10 записей в регистрах и т.п.), перерасчет агрегированных показателей (вроде тех же сумм по регистрам + агрегаций для оперативной работы), записи логов (всего и вся, в сложной системе без этого никак, все друг на друга начинают валить). Ну и куча всяких мелких проверок \ трансформаций - вроде приведений к регистрам серий, номеров, или проверки что везде все задано, и всякая херня типа: 'Розничная сумма для строки поступления на цех должна совпадать с розничной суммой строки перемещения на цех', 'Покупатель строки основания должен соответствовать Организации склада списания' (таких я насчитал > 30)Итого 10 проверок так и осталось, а пока Вы говорите только отговорки про логи и прочее.

Еще раз спрошу - где 200 проверок?

Даже в этом предложении уже их >10. Я могу вам список все кинуть. Но вы на каждую скажете, что она не нужна. Хотя каждая из них конкретный change request заказчиков.

Программист 1сNitro_Junkieпропущено...

А в чем разница? Особенно с сервером, или 1Са денех мало нормальный сервер взять. На том же ovh за 1000 баксов в месяц?Вы в курсе на каком сервере и сколько одновременно крутится баз, при демо веб запросе? Или Вы просто болтаете?

В курсе. 11 баз. Их легко потянет скажем три BHG сервера https://www.ovh.ie/dedicated_servers/HG/. Еще раз у 1Са нет 1500евро в месяц на сервер. Чтобы когда потенциальный клиент заходил в демо, у него не возникал вопрос, какого лешего она так тормозит на демо базе? Что же будет в продакшне...

Программист 1сNitro_Junkieпропущено...


Вот это первая деталь. Потому как в таком случае нахрена вообще 1С или любой другой ORM фреймворк. То есть да можно делать все чисто в SQL парадигме, но с точки зрения поддержки и разработки это песец, причем фееричный. Причем ладно если еще можно сделать чтобы для ОДНОЙ операции был 1 запрос для ВСЕХ объектов (хотя даже это на ORM / 1С уже редкий геморрой, так как все же основные варианты использования это For и Документ.Цена=Товар.Цена, то есть ОДНА операция/ОДИН объект). Но для ВСЕХ операций и ВСЕХ объектов - 1 запрос, это очень дорого и не удобно. Если вы видели код систем, которые стремятся к этому, то не знаю как у вас, а у меня чуть кровь из глаз не лилась.

А вторая деталь, что делать с изменениями данных. Проверки скажем на остаток >0 при оперативном проведении это прекрасно. А вот что делать при изменении уже введенных документов, это куда веселее. Там нужна туча проверок на конкурентный доступ (скажем чтобы 2 человека одновременно не меняли одни и те же данные), но при этом желательно чтобы одновременно могли менять одни люди цены, а вторые скажем сертификаты.

В 1Се для изменений придумали проведение \ распроведение. Но вот тут я честно говоря вот чего не понимаю. Если у меня был приход на 5, расход на 5, а я меняю приход на 4. Что в этой идеологии будет? Она ругнется на распроведении (но тогда и 6 на 5 изменить нельзя будет) ? Или при проведении (но тогда непонятно, по идее она будет видеть что мы с -5 меняем на -1 и должна пустить). Может кто из местных 1Сцев подскажет?

Ну и тоже самое непонятно, что делать с теми же партиями (в идеологии проведение \ распроведение). Понятно, что сам 1С предлагают РАУЗ (типа вы просто "неправильно его держите"), но скажем в Беларуси в опте ОБЯЗАТЕЛЕН партионный учет. Ни один бухгалтер не согласится на его отсутствие, более того многие устраивают панику если по какой-то партии остаток <0.1. И в чем писец? Неумение выносить данные которые нужны для расчетов в таблицы, из которых удобно делать запросы?
Или неумение пользоваться пакетом запросов? Элементарно и легко используется. Или Вы рассказываете Ген диру - как Вам ПЕСЕЦ как сложно что-то делать?

2. Куча "туева" проверок не нужна. Глупость это.

3. С партиями тоже все замечательно, если подойти и подумать.

1. Нет. Вопрос нафига мне тогда 1С. Лучше уж тогда на голом PL/SQL'е писать.

Вы же в курсе что даже типовые как вы говорите не пишут (во всяком случае абсолютное большинство)

2. Естественно. А то что пользователи хотят, это их проблемы.

3. Но даже про проведение \ перепроведение и остаток >0 никто толком не ответил. Про партии это вообще отдельная тема, потому как в 1Се, не совсем понятно в какой момент вообще они должны создаваться. При проведении? Тогда как их перепроводить. Локально при вводе, тогда кто будет чистить мусор, если документ удалится, не проведется, и вообще если ее сдуру используют.

[quot Программист 1с]Nitro_JunkieУважаемый Nitro_Junkie.

Ваш язык "ПЕСЕЦ как сложно", "Туева Куча" и тд и тп. несомненно говорят о Вас, как крутом спеце. (а не в коем случае не в желании самому понять хотя бы на бумажке что и как изменять, если менять задним число, и уж тем более не о лени)


Но все Ваши проблемы слишком мелкие и скучные, наймите спеца и он(а) Вам разъяснит как и что. А лучше поставьте Сап (дельфи, c++) - там все проблемы точно решены, и нет ни каких рид коммит.


ps Правильный вопрос содержит уже половину ответа.

Я то как раз все вопросы по существу задаю. Мне реально интересно, может на 1С перейти, но если даже на форуме никто на простой вопрос, не может толком ответить, то боюсь представить, что будет если столкнусь с более серьезной проблемой.

kihorNitro_JunkieВопрос в другом. Можно распровести документ прихода, если после его распроведения остаток станет < 0? Как я понимаю у 1Са какая архитектура, изначально есть только обработка проведения, которая пишет в регистры и помечает для этих записей этот документ в качестве регистратора. При распроведении все эти записи удаляются. При проведении заново выполняется обработка проведения. Как в такой идеологии идет проверка остатка >0 при изменении приходов? Я видимо просто чего то не знаю.

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

Ну во-первых, все очень зависит от специфики торговли.Если речь идет о штрихкодированном легкоразличимом товаре с не очень широким ассортиментом, то тут да проблем меньше (в аптеках так вообще если отгрузишь не то - сесть можно). Но я учавствовал в автоматизации крупной торговли рыбой, вот там проблема была очень острой (там очень непросто отличить одну рыбу от другой ну и весовой товар). Плюс там бухгалтерия очень ревностно относилось к отрицательным остаткам, так как формально это нарушение и может закончится крупным штрафом (во всяком случае в Беларуси). Еще больший бардак я наблюдал на торговле фруктами, но там уже проблема была не только с отрицательными остатками, а с тем что себестоимость была не средневзвешенная а партионная, и после акций типа 2 по цене 1 регулярно возникали скандалы, а чего это мы так сильно в минус наторговали (нам тоже прилетало за это).

Во-вторых. Я знаю, что автоматизация бардака приводит к автоматизированному бардаку. Но "устранение бардака", это все равно что "наведение порядка в стране", вроде все знают что надо сделать, но оно как-то не получается. В этом смысле внедрение в виде, давайте наставим ограничений, потом там где будут возникать проблемы, их будем немного ослаблять \ видоизменять и на выходе получим пусть автоматизированный, но управляемый бардак. Дальше постепенно подкручивая те или иные ограничения можно упорядочить бизнес с учетом его специфики и тем самым получить IT-систему именно как хороший инструмент управления бизнесом, а не его автоматизации.

VolochkovaMironico,

Может это конечно прозвучит как бред :-)
Берем что то типа Кристал Сет. И пишем обмен с кассами.
Приходы - если даже связь упадет можно и позднее внести.
Касса - там и сканер и платежный терминал уже включены и работают даже в офлайне ибо сервер Кристалла стоит на стороне клиента.
А в боевую базу тянуть продажи с какой то задержкой + выгрузка цен в Кристалл - но на сколько я помню, у Кристалла это реализовано.
Кубы у Кристалла есть, Инфо киоск так же есть. Может еще что то уже доделали.
Гибкая система скидок была, опять же карточки с дисконтом, накопительные - уже в комплекте.

Не являюсь представителем данного ПО. Не реклама.

Ну у наших клиентов аптек у всех строгий партионный учет (очень важны сроки годности). Поэтому на практике процесс такой, идет сканирование штрих-кода, а дальше выбор на экране партии с нужным сроком годности из тех что есть на остатках (они как правило всегда актуальные, у аптек инвентаризация если на 50$ уже очень редкая ситуация). У кристала такой функциональности нет. Конечно можно полностью все перемаркировывать, но это очень затратный с точки зрения времени процесс.

Программист 1сХарактеристики сервера и количество одновременных демо запусков Вы не указали.

Также рекомендую отправить письмо Нуралиеву за его безобразную рекламу.


Какого сервера? Каких одновременных демо-запусков? В ссылке есть характеристики сервера. Такой сервер должен выдержать минимум 400 ОДНОВРЕМЕННЫХ подключений. Вы думаете их там больше?

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

Программист 1сНесомненно на Ваши вопросы никто не ответит, ввиду непонимания Вами процессов. А чтобы рассказать Вами процессы - необходимо чтобы Вы знали 1с.

Интересно, как же эти процессы существовали до появления 1С. Или как они существуют за пределами СНГ, где про никакой 1С даже не слышали. Вы сами понимаете, какой бред пишете.

Программист 1сps Извините - ушел заниматься более серьезными проблемами на 1с.

Куда уж серьезнее, чем когда под конец месяца бухгалтерия в панике, когда у них несколько сотен отрицательных по партиям и они не знают что с ними делать?

Последний выдох ГПЖNitro_JunkieВопрос нафига мне тогда 1С. Лучше уж тогда на голом PL/SQL'е писать.

можно. но долго

Так и выносить все во временные таблицы и пакетами запросы обрабатывать (а не просто в циклах обращаться к объектам А.b) тоже долго. Но вот Программист 1С так предлагает решать вопросы производительности.