Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Основная статья находится по адресу:
Перейти к публикации
Нужно писать — для 1С 7.7
(1)
Может быть, можно придраться к отдельным словам или фразам статьи, но с основной мыслью автора полностью согласен. Насколько легче было бы жить, если бы журналы документов и регистры допускали секционирование или вынесение старых данных в архив! Не путем допиливания конфигурации, а как штатная возможность платформы.
Да, если используем Microsoft SQL-сервер Enterprize Edition, секционирование таблиц можно сделать средствами SQL-сервера. Но это придется делать вручную для каждой такой таблицы, и заботиться, не случится ли что при обновлениях и т.п.
Вспомним, как работал бухгалтер без компьютера: он, в частности, вел журналы документов в специальных тетрадях. А заполненные тетради складывал в папки по годам. У него всегда под рукой был архив журналов за весь период, в течение которого законодательством предписывалось хранить журналы. Но этот архив не мешал ему делать текущую работу.
А разработчики большинства программ, ориентированных на «решение учетно/отчетных задач», положившись на безграничные мощность процессора, объем памяти и диска, решили, что архивы, неотделенные от текущих данных, не будут мешать эти текущие данные обрабатывать. Это ошибка, я считаю.
(4)
Александр (kapustinag).
Если рассуждать от достигнутого, что — есть объект АвтоМехАнизации под название «Документ», то — да. Суть «секционирование таблиц» можно (и желательно) «вставлять» в платформу.
Но, я в своей статейке пытаюсь, еще продвинуть «мысль», что не документами описывается предметная область. Хотя, это и мало отношения имеет к текущей версии 1С-ов.
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную «бухгалтерию» по сбору документов. И жить по правилам «бухгалтерии». Нет в реальной жизни никаких журналов документов и регистров. Для «образования» этих понятий в том месте, где они действительно используются (учет) — уже достаточно технических средств «сбора» информации из тех точек «бизнес процессов» где она возникает. Т.е. не документ имеет движение, а — материальная ценность и деньги двигаются между точками их применения. 😉 Очень хорошо это укладывается в сетевую (иерархическую, объектную) модель баз данных. И многие вопрос уходят на второй план. Например, такие как: блокировки, размеры БД, искусственное преобразование структур данных туды-сюды, модульность подсистем, интеграция данных, постепенное внедрение, «паразитные» структуры данных типа — регистр и т.д.
(2) Противник словесности?
Вообще говоря, статья не о СУБД, конечно, а о жизни. Точнее, об отражении жизненных реалий техническими средствами. О том, что техника отображения (моделирования) зависит от текущих потребностей «моделиста». И на самом деле, по модели можно судить не только (и даже не столько) об объекте моделирования, но и о субъекте.
Вспомним, откуда взялась (выросла) 1С. Расплодившимся в конце 80-х мелким лавочникам потребовалось средство, чтобы отбиваться от государственного рэкета, в котором, в отличие от рэкета криминального, размер платежей исчисляется, исходя не из реального финансового состояния, а из документально оформленного. Именно поэтому «Документ» стал «священной коровой» одноэсных продуктов.
Надо сказать, что в этом то ли 1С попала «в струю», то ли тенденции автоматизации бизнеса попали под влияние 1С — так или иначе, за что ни возьмись — вместо реалий упираешься в документооборот. Примеров тому великое множество, приведу один модный термин: бизнес-процесс. Копни его — и увидишь, что это не что иное, как документооборот, сопровождающий некий хозяйственный цикл.
Другой пример «повернутости» на документы в противовес реалиям. При анкетировании в рамках исследования должностей я указал в качестве своей функции «формирование и реализация технической политики предприятия в сфере компьютеризации учета». И сразу же получил вопрос от анкетирующих о существовании документа с нименованием «техническая политика предприятия». А его как раз и не существует — но политика-то есть! Выходит, цель анкетирования — не описание должности, а описание входящих/исходящих документов…
Мое глубокое убеждение — документооборот (и Документооборот в смысле 1С) описывает жизнь не просто некорректно, а извращенно с особым цинизмом. Под чем и подписуюсь.
(7) ага, а потом появляются такие статьи
Интересная тема:
1) Кажется, не стоит противопоставлять концепции построения АСУП и конкретные технические решения для конкретной СУБД. — Это совершенно разный уровень проблем. О чем тут спорить? Практикам интересны конкретные технические решения, применимые здесь и сейчас, для конкретной версии 1С. Есть плюсы (быстродействие) и минусы (надежность), — прием не бесспорный, это очевидно. Зато читатели узнали о спектре возможностей настройки СУБД. За это знание и плюсы в статье;
2) Теперь о концепции построения АСУП. — Сколько их уже было! СУБД — это инструмент хранения. Сетевая, иерархическая, реляционная — какая разница? У АСУП должна быть более глубокая парадигма. 1С доказала устойчивость своей парадигмы и менять ее не собирается. А зачем? В чем проблемы? Не нравится слово «документ»?
Кстати, у западных систем, по-моему, вообще еще меньше стройности и концептуальности. Там нет крупных кирпичиков — почти что одни таблицы. Гибкости при разработке больше, а трудность и цена кастомизации выше.
В общем, предлагайте парадигму вместо «документ». Иначе критика выглядит неконструктивной.
появилось много статей на темы всяких ERP-APS, но не пойму в целом, а чего все спорят, поэтому не могу корректно «влезть» в перепалку 🙂
но тем не менее
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную «бухгалтерию» по сбору документов.
скажу вот что (на примере из жизни): в целом, грамотные люди на уровнях среднего управляющего звена готовы и хотят автоматизироваться. Хотят получать актуальную инфу по щелчку мыши, хотят и могут в какой-то степени пересматривать свои бизнес-процессы. И автоматизации таких подразделений обычно более-менее нормально проходят.
Проблемы начинаются, когда:
— вот всех этих ПДО, экономистов, технологов, конструкторов необходимо влить в общий информационный поток. Тут возможны более серьёзные изменения бизнес-процессов, на которые не все готовы. Тут начинается непосредственная и мгновенная зависимость одних отделов от других — любой лаг тут же виден всем. Тут возможно изменение схемы сфер влияния (а это имеет огромное значение на наших производствах), тут начинается политика и религия;
— и из всего этого вытекает еще более глобальная проблема — высшему руководству часто тупо наплевать на всё это, ему не нужна эта 1С в компьютере, оно не готово заниматься каким-то планированием, анализом, смотреть какие-то графики и пр. Там всё распилено, цены на продукцию уже обозначены заранее и строго секретны, там мерседесы и порше и т.д. и т.п.
Ей богу, проще сравнять бульдозерами, пригласить иносранцев и тупо построить завод заново с информационной системой в комплекте.
P.S. после n лет разработки и внедрения была как-то презентация отчета, считающего себестоимость изделия, финдиректору. Слушал молча, внимательно, нахмурившись. После подробного рассказа и показа общего листа отчета тыкает в цифры стоимостей и спрашивает:
— всё ок, но кто вот бьёт эти цифры?
— ээээ… никто не бьёт… программа сама посчитала, мы же вот тут вам рассказали..
— не, это я понял, но вот тут, например, литье — столько-то рублей, материалы — столько-то. Вот кто забивает эти цифры в систему?
— да никто не забивает, программа сама считает, начиная с каждого болтика, шайбочки и детальки..
— как так?? Не морочте мне голову!! Как так у вас всё считается?? Этим цифрам нельзя доверять..
и т.д.
(7)(10) Про «Документ»: Как всегда, чем короче слово, тем шире понятие и возможности неоднозначной интерпретации. Мне кажется, что понимать «документ» следует так:
Есть предприятие как система. Ее состояние определяется набором параметров. В определенное время состояние меняется (приходят деньги на расчетный счет, отгружается товар, регистрируется выпуск продукции, списываются материалы на выпуск, проходят через проходную сотрудники). Во многих случаях длительность самого изменения невелика или несущественна, поэтому его можно считать «мгновенным». Это изменение регистрируется в системе. Для этого вручную (или автоматически) формируется объект в базе данных с параметрами, характеризующими время изменения и его характеристики. Этот объект «проводится», то есть записывается так, что меняются параметры системы (ресурсы регистров) и определен факт изменения.
Это очень широкая концепция, позволяющая моделировать очень многие процессы. Чем Вы предлагаете заменить документ-событие?
Предложите! Можете назвать сети Петри, конечные автоматы, сетевые графики, блок-схемы, таблицы решений, структурные схемы, иерархические схемы, фреймы и прочее. Что Вам больше нравится, что шире, удобнее, выразительнее? Модель должна иметь стержень, ключевую метафору. А иначе получите «действующую модель паровоза в натуральную величину». ООП + паттерны? Попробуйте пофантазировать! А так получается, что «что-то другое, а не документ», но что именно?
(11)
Роман (romansun).
Всё верно Вы написали.
Только:
1) Не «ERP-APS»,а «ERP+APS» мы пытаемся делать.
2) И кода «необходимо влить в общий информационный поток», то это не означает «серьёзные изменения бизнес-процессов»(с).
Системы (задачи, функции, алгоритмы т.д.) не складываются. Они могут лишь «встраиваться» (интегрироваться) и базироваться на нечто общем. Это общее — исходные данные общие для всех задач. Для успешного встраивания должна проводится четкая систематизации информации без привязки (но с учетом) к алгоритмам последующего их использования. И чем больше в исходных данных присутствует элементов направленных на решение конкретной (частной) задачи тем меньше шансов (и сложнее) обобщить другие задачи.
Для такого подхода в построении ИС и придуманы «БнД=БД+СУБД+Администрирование».(очень давно придумали!!!). С очень важным дополнением — описание схемы базы данных должна быть открытой и общей для всех задач имеющих отношение к хранимой (и собираемой) информации в базе данных.
Ну и лозунг должен быть, примерно, таким: 😉
«Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.
Разместить бизнес-решение там, где вам удобно: внутри компании или у хостинг-партнера.
Выбрать модель внедрения, оптимальную по сочетанию рисков, затрат, сроков и ресурсов.»(с)
Продукты от 1С не соответствуют принципам построения БнД и не могут служит платформой для АСУПа. Вот, так грубо скажу…
(12)
Сергей.
Ваше сообщение адресовано двум собеседникам.
Я подожду ответа от Другого Вашего собеседника. 😉
Лады?
Ну и лозунг должен быть, примерно, таким: 😉
«Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.
Круто конечно и, наверное, правильно… Только нереально )) Почему? Потому как часто на предприятиях, схему работы которых придумывали и внедряли в 70-80гг всякие НИИ — за прошедшее время часто 2+2=5, а 2*3=7, а операция деления вообще отменена еще при старом
режимедиректоре.Там почти что априори приходится выправлять и 2+2 и 2*3, иначе просто код не пишется.
Может и не на всех так, но где я имел возможность работать — было и есть так.
А вот изначальные схемы и бизнес-процессы были круты, да! Но изменились с тех пор до неузнаваемости, как в кривых зеркалах.
(12) согласен, +1
хоть сети Петри (услышал знакомое институтское слово), хоть графы — всё равно событийная модель на основе таблиц.
Ррраааз — появилась запись в таблице, ррраз — еще одна. Всё на справочниках можно построить. Но с документами проще проектировать и возможно использовать регистры..
———
На мой взгляд, про документоориентированность 1С стоит говорить в том контексте, что весь 1С-учет (бухучет, в частности) у нас часто построен не для отражения реальных ситуаций на предприятии, а тупо для сдачи отчетностей. В отличии, кстати, от западного софта. Поэтому у нас можно ковыряться в закрытых периодах (а как же?? мне ведь надо чтоб в нонешних цифрах всё сошлось), а в западных — нет (позвольте, зачем вам править в прошлых данных, у вас же поплывут настоящие цифры и вы не увидите своих косяков???)
И всё это, опять же, упирается в людей. Стройную и прозрачную схему работы в реале можно и в экселе автоматизировать — работать будет только в путь. В противном случае, никакие системы, методики и теории не помогают, к сожалению.
(15)
Роман (romansun).
Согласен. И лозунг привел специально. 😉
Я же не первый десяток лет в АСУПе. 🙁
Но 2+2=5 это не бизнес процесс. Это его отсутствие.
Ну, а дальше классика…
Надо научить людей пользоваться пипкми компьютера и обеспечить ему продвинутую пишущую машинку с калькулятором. И это уже очень много! А если бумажные документы не будут теряться пачками — отлично. Только, тогда давайте не будем говорить о всяких названиях из трех букв.
Помню, как много лет назад делили машинное время между пользователями при использовании нашего аналога IBM/370. Все бегали с собственными дисками с персональной операционной системой и в каждой лаборатории занимались разработкой собственно банка данных под управлением личной СУБД.
Потом появились персональные ЭВМ. Рассосалось. Разбежались по углам. Машинное время перестали делить со скандалами. И тут от НИХ приползла зараза — сети… И опять, по кругу…
Ну чего сказать? Да, 2+2=5… 🙂
(16)
Роман (romansun).
Вы написали: «что весь 1С-учет (бухучет, в частности)»(с)
Стоп!
А АвтоМехАнизация — это только учет?
Тогда и разговора нету.
Начинаем перечитывать мою статейку и комментарии темы заново.
(15)
Роман (romansun).
Эх. Понесло меня на примитивные тексты… 🙂
Извините.
Химия. НИИ. Все проводят исследования, анализы, утилизацию реактивов и т.д.
Ну, сделайте сначала, чтобы потребитель реактива мог на «компьютере» выбрать, набрать, заказать необходимые ему реактивы (материалы) для своей работы. Наращивайте описание реактивов, для более качественного выбора. Он же после проведения этапа своей работы делает отчет по затратам этих реактивов по отношению к заказчику (другой лаборатории). Пусть забьёт это в «компьютер». И не в виде «требование на» (и др. т.н. документов), а в понятной ему форме. Его не волнует ни склад, ни НДС. Может в другой лаборатории есть эти реактивы. И покупать не надо. И ждать не надо. Для этого — что? Бизнес процессы ломать придется. Или там есть корпоративные секреты. Воровство спирта — есть. Но это ни для кого, не секрет…
И надо обеспечить достоверность информации (пусть — малой), и доступ к этому компьютеру в режиме 24/7. Без всяких сверток БД и регламентных работ. Иначе, отвратите, изначально, человека от использования эТТого устройства. Компьютер должен помогать пользователю, а не добавлять ему лишнюю работу. Только тогда пользователь будет на Вашей (ИТ-шной) стороне.
Нет, блин, нам сразу подавай систему с названием из трех букв. Покупную, готовую обязательно. И чтобы всё делала сама. Прибыль считала и графики строила. А цифирь мы возьмем из бухгалтерии, т.к. только там достоверная информация. А чтобы она была полная и оперативная — наладим «УУ». Рядышком, чтобы пачки документов далеко не носить от одного компьютера к другому. Типа, механизация труда бухгалтера в вопросе перенося тяжестей…
Ну, сделайте чтобы на складе не наклеивали «собственные» штрих-коды, если «внешние» нормальные (уникальные). Сделайте базу данных разных наименований одного товара для быстрого приема. Или чтобы продавец не мог пробить один товар (дешевый), а выдать (своему другу-покупателю) дорогой. Чтобы остатки на складе сходились не по б.учету на конец прошлого квартала, а на сейчас, когда за товаром приходит оптовый покупатель. И сделайте это не бесконечными обменами между системами с названием из трех букв, а «автоматически» — в одной базе данных. В реальном масштабе времени жизни, а не бухгалтерии.
Может тогда и прибыль будет не только посчитана, но и, просто — будет.
А если Ваш начальник этого не понимает (а Вы — понимаете), то надо сменить начальника.
Для этого есть два способа…
(12)
Двумя руками за! Если документ = событие — все нормально. Однако во-первых, в 1С время документа не совпадает с временем события — это породило гемор с «восстановлением последовательности». Во-вторых, одним документом могут быть зафиксированы два (и более) событития — скажем, факт выписки (продажи) товара и его отгрузки. В-третьих, при проведении (изменении состояния модели предприятия) зачастую результат зависит от момента проведения. Тут уж сплошные парадоксы времени получаются из научной фантастики. В жизни такого не бывает, т.е. концепция (модель), основанная на 1С-Документе нежизненна. Как мне показалось, статья именно об этом…
(20) Во-первых, во-вторых и в-третьих решается простым способом — полным запретом проведения документов задним числом. То есть все, что перечислено — не недостатки модели и концепции, а практики ее применения. То есть Вы говорите — модель «нежизненна». Следует ли понимать так, что жизненная модель должна разрешать помещать в базу данных любые факты, в любом порядке, за любые периоды и сама определять их достоверность и согласованность. Или все же быть своего рода тотальным (видео)регистратором — работать в реальном времени. Я не спорю — я спрашиваю: не встречалось ли Вам удачных идей, концепций, моделей, которые могли бы лечь в основу «хорошей» системы, если 1С такая «плохая» и основанная на порочной концепции система. Что можно в принципе противопоставить подходу 1С? Какой правильный стержень?
Моя мысль в том, что критика бессмысленна в отсутствии более-менее конкретных представлений об идеальной системе. Ведь для управления нужна цель, направление. Здесь, предположим, плохо. Но куда Вы предлагаете двигаться?
(21)
Сергей (ildarovich).
Я подписываюсь под (20) сообщением.
1) А вот Ваше: «Во-первых, во-вторых и в-третьих решается простым способом — полным запретом проведения документов задним числом.»(с) вызывает у меня удивление.
Возможно, приведу не очень удачный пример, но… Просто, очень много таких примеров. Я, даже, теряюсь приводить совсем уж конкретные примеры.
Например, существуют документы от даты которого исчисляется время возможности его использования. А момент конкретного его использования (совершения ХО) фиксируется другой датой. Например, подписями с датой, сторон совершающих ХО. Т.е. одна дата на документе это очень «большое» допущение в вопросе отражения реальных ХО. И если подобный документ заносится в БД, то либо надо иметь возможность изменять его задним числом, либо вносить задним числом сам документ. А по какой дате…? Или подобные документы не надо заносить в БД?
2) «которые могли бы лечь в основу «хорошей» системы»(с)
На данный момент моего понимания, мне представляется «идеальной» моделью системы, где существует возможность «называть» объектами реальные объекты нашей жизни. Т.е. например, товар (объект) осуществляет собственное «движение» между объектами хозяйственной деятельности. А не объект-документ порождает своё движение на регистрах учета 😉
Из реально существующей системы для АСУПа (не в области СУБД — там одна, всем известная) — это «ABACUS Financial (AF7)» в сути её «ABACUS Builder (AB7)». Тут: есть, разбросанные по тексту, файлы PDF. Гляньте их содержание. Обратите внимание на год создания этого продукта. 😉
У меня есть много критики в адрес этого продукта. Но, так красиво уложиться в «SQL-ную» СУБД — это достойно изучения. И запросы там, почти, по делу…
3) «Ведь для управления нужна цель, направление.»(с)
Для управления нужен объект управления. И полные, достоверные, точные данные (информация) о состоянии этого объекта. Этим, в первую очередь, и должна заниматься АСУП-ина. 😉
4) Сергей. Я ужо обмолвился, выше по тексту, про «Графины». Вас не заинтересовала тема — «раздолбать» модель (архитектуру) 1С-продукта «графинами»?
(22)
1) В «тяжелых» случаях документов может быть несколько. Они будут объединены структурой подчиненности. То есть одному печатному документу будет соответствовать несколько модельных документов. А еще есть «стадии» (УТ11), бизнес-процессы. В 8-ке очень много и других готовых объектов.
2) Посмотрю ссылки, спасибо. Идея с объектами, осуществляющими «движения», наверное, правильная. Кажется, разработчики WMS на базе 1С идут по этому пути.
3) Под целью я понимал описание идеальной системы. Вы его дали в п.2.
4) Про «графины» ничего не понял. Наверное, что-то пропустил.
(23)
Сергей (ildarovich).
1) Можно углубиться (вернуться) к теме «первичный документ». 😉
Уже обсуждали на данном ресурсе.
Но, например:
«Документ есть закодированное определенным образом и зафиксированное на специальном носителе информационное сообщение (свидетельство), удостоверяющее, что факт хозяйственной жизни или существует, или совершен, или должен быть совершен.
…
Первичные бухгалтерские документы — письменное свидетельство о совершенной хозяйственной операции или дающее право на ее совершение.»(с)
[ ]
В описании «Управление производственным предприятием»(УПП) от 1С есть текст:
«Средством регистрации хозяйственной операции является документ, причем для ускорения работы широко используются механизмы подстановки данных «по умолчанию», ввод новых документов на основании ранее введенных. «(с)
[ ]
Я, из этих определений, делаю однозначный вывод: «В УПП АвтоМехАнизируется учет документов.». И в 1С-продуктах всё сделано хорошо для ЭТОЙ задачи. Гораздо лучше чем полвека назад. Но суть не изменилась. 🙁 Изменилась только «внешняя» форма. 🙁
2) Интересно, сколько «готовых объектов»(с) будет использоваться в подобных задачах? 🙂
3) Я — молодец. 🙂
4) Тогда — забудем 🙁
Есть несколько нерешенных проблем:
1 — Если база 7.7 — то все немного не так, Большой обьъем данных может быть не в таблицах RG а в RA, и если не включена бістрая обработка движений (нет поля DATE_TIME_IDDOC), то разделить на группы по полю — нет возможности.
2 — Если база растет, то любые изменения в структуре вызывает пересчет данных по измененным таблицам, что при росте БД может вырости в разы. Так добавление новой графы отбора может привести к серьезным пересчетам. Или же удаление реквизита и поиск ссылок (это в 7.7).
3 — Бекапы базы, их ведь надо хранить и если размер не 10 ГБ а 100, то даже при зжатии бекапа надо очень большое хранилище чтобы каждый день хранить полный бекап, хотя бы за пару месяцев.
Так что в предложенном автором механизме реализации есть как плюсы так и минусы, и каждый должен принимать решение исходя из своих соображений и свой ситуации, потому что не может быть здесь одного универсального решения.
(25) pvase,
Причем тут 7.7? Тут речь идет об основах построения БД 1С8 — концепции и насколько она оправдана.
А не хранения таблиц документов в SQL в 7.7.
(26) AlexO, Извините, из статьи не видно что речь идет исключительно об 8-ке. Напротив речь идет об свертке базы 1С и зачем это делать.
А концепция построения БД в 1С 8 — это немного другая тема, и в заголовке статьи и в самой статье об этом не нашел упоминания.
И поскольку все манипуляции производятся на SQL Server минуя 1С то эта технология применима к любым базам на MS SQL 2005 и выше.
(27) pvase,
это вы просто невнимательно читали 🙂
Большая часть, прочитав название темы, к которой мы сейчас пишем комменты «Приложение к публикации: «Давайте забудем о свертке БД?», сразу заинтересуется — а что это за исходная тема такая? Я че — буду читать какое-то «приложение» к непонятно чему, а на «исходную» статью даже и не взгляну?! И перейдет по ссылке .
А там, в статье «Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL», ниже заголовка написано, что «Алгоритм для 1С: Предприятие 8.0; 1С: Предприятие 8.1; 1С: Предприятие 8.2; Windows».
Т.е., четко и ясно 🙂
Никаких 7.7 и прочих «прямых доступов к SQL».
Мне кажется автор не затронул другую проблему.
А именно проблему работы «задним числом».
Во многих западных системах работать задним числом просто запрещено. Для этого у них есть документы корректировки. 1С бухгалтера любят в основном за это, за возможность работать задним числом. Но на базу в целом это влияет негативно. От сюда и вытекает основная идея свертки базы от айтишников. Если оставить только итоги,а прошлые документы убрать, то вероятность того, что бухгалтерия опять, что то поменяет задним числом, приближается к 0.