insodaПолучается, все эти проводки должны быть в единой системе, так как их аналитика во многом одинаковая. То есть автоматизация управленческого и фискального учета в единой системе – это поддержка сложных схем оформления сделок. Белый учет в единой системе будет посложнее черного в отдельных системах. Можно ли как-нибудь упростить учет?Про аналитики - совсем не такой простой вопрос, как может показаться на первый взгляд. По приведенной ситуации я каких-то существенных проблем не вижу, но ведь это частный случай, не так ли?

Я уже говорил о двух подводных камнях, на которые может наткнуться объединенная система, расскажу еще и о третьем, раз речь зашла о возможности объединения аналитик двух учетов.

Давайте вспомним о том, что информация в аналитических справочниках (раз уж речь зашла именно о них) не просто лежмя лежит, она туда иногда добавляется и она там модифицируется. И вот этот небольшой нюанс может попортить много нервов. Сначала вспомним о том, что моменты управленческой и фискальной проводок могут не совпадать. Как правило, в управленческом учете, они делаются раньше, но в общем случае может возникать и противоположная ситуация - когда в фискальном учете требуется выполнить проводки, не представляющие интереса для управленческого или когда в управленческом учете они уже нашли отражение, но ДРУГОЕ (с другим составом аналитик). Так вот, подводный камень, о котором я говорю - это определение места формирования аналитической информации для обоих учетов. Работники, задействованные в разных учетах, существенно по-разному могут воспринимать значимость некоторой информации. Разберем такой простейший пример, как необходимость сослаться на какую-то запись в справочнике контрагентов, которой пока еще в этом справочнике нет. Сотруднику сначала необходимо удостовериться в том, что ее там нет - и получение однозначного ответа на этот вопрос совсем не так прост как может показаться. Если у сотрудника не будет эффективного механизма ответа на такой вопрос, если он не будет достаточно мотивирован, чтобы найти ПРАВИЛЬНЫЙ ответ на этот вопрос, он наверняка будет добавлять новые записи, аналогичные уже существующим в справочнике, в нем появятся задвоенные, затроенные, задесятеренные записи, и через некоторое время все станут автоматически добавлять в справочник новую запись, не интересуясь, есть ли в нем то, на что можно сослаться - в особенности, если трудоемкость поиска выше трудоемкости добавления новой записи. Аналитическая информация в таком случае в обоих учетах расползется по разным аналитикам, которые в реальности являются одними и теми же, и перестанет быть понятной и представлять какую-либо ценность в обоих учетах.

Понятно, что записи, сооответствующие одному контрагенту, вводить в справочник нельзя. Но это еще не всё. Существуют весьма противоречивые требования к оперативности ввода информации, ее достоверности и полноте. На участке, где наиболее важна оперативность (обычно он связан с УУ), скорее всего, не станут заморачиваться над розыском дополнительной атрибутики, интересной другим подразделениям, а в особенности для другого вида учета. Введут только ту информацию, которая известна на момент выполнения операции - потому что операцию нужно выполнить БЫСТРО . И, возможно, это будет одно только наименование (без ИНН, КПП, банковских реквизитов, юридического и почтового адреса, контактных лиц и моря всего остального).
На этом этапе нам стало понятно, что в справочнике не только могут отсутствовать записи, они могут там быть, но у них могут быть указаны не все атрибуты, необходимые для других участков и, прежде всего, для другого учета. Таким образом, если на один и тот же справочник делаются ссылки в разных местах, то необходимо не только проверять простое наличие/отсутствие записи в справочнике перед тем, как сделать на нее ссылку. Необходимо еще проверить и ПОЛНОТУ информации, которая уже находится в справочнике и обнаружена. Таким образом, для ссылки на запись справочника сотрудник на некотором рабочем месте должен совершить действия над каждой записью справоника, на которую он ссылается, и трудоемкость этих действий сравнима с трудоемкостью добавления новой записи.

Хочу обратить внимание, что такая простая оценка как просто наличие/отсутствие необходимых дополнительных атрибутов записи аналитического справочника - это далеко не всегда выход из рассмотренной ситуации. Например, если речь идет об участке, на котором вводится информация о счетах-фактурах, то КАЖДОЕ значение КАЖДОГО дополнительного атрибута должно быть ПЕРЕПРОВЕРЕНО перед тем, как сделать ссылку на запись о контрагенте. И если в одной счет-фактуре указаны одни реквизиты орагнизации, а в другой другие (представьте себе - такое очень часто бывает!), то в фискальном учете, содержащем книгу покупок и книгу продаж эти различия должны найти отражение!

Таким образом, простое делание ссылок на одни и те же справочники в двух учетах может быть связано с проблемами, к которым нужно быть заранее быть готовым. Многие из этих проблем решаются систематизацией нормативно-справочной информации (НСИ), разработкой регламентов, четким обозначением источников формирования информации, назначением ответственных за ее различные части. Но, все-таки, не все. Особенно, если на предприятии присутствует существенная доля предварительно несистематизируемых операций (а существенной может оказаться и 1%).

В общем, вопрос отчасти творческий - решается по месту... :)

insodaКакие реквизиты? Как это должно отразиться в книгах покупок и продаж?Я не совсем точно выразился. Имелись в виду все реквизиты, отображаемые как в самих счетах-фактурах, так и в книгах покупок и продаж и в журналах регистрации счетов-фактур выданных и полученных. Изменяются юрадрес, организационно-правовая форма, наименование... В моей практике было также два случая, когда одна и та же организация предоставила документы с разным ИНН, и это не было ошибкой. Есть еще один нюанс. При изменении этих реквизитов недостаточно их просто "исправить" на новые. Потому что такое измененние автоматически приведет к искажению той корректной информации, которая была введена в предшествующих периодах. Чаще всего также недопустимо при изменении реквизитов просто добавить в справочник новую запись и иметь в нем одновременно две записи - одна со старыми, другая с новыми реквизитами - если система считает эти записи соответствующими разным организациям, то она не закроет остатки, не свернет обороты, пользователей при ссылке на организацию возникнут дополнительные проблемы - они должны будут не только обнаружить запись в справочнике, но и определить, какая из обнаруженных N записей актуальна на сегодня.

Валентин КФормально нужно создать нового контрагента и работать уже с ним, а предыдущего отправить в архив...Этот подход имеет недостатки, о которых я уже выше сказал. Если за старым контрагентом висят "хвосты", то у нового контрагента этих "хвостов" уже не будет, и вообще вместо одного контрагента, который и есть в природе один, вы получите столько контрагентов, сколько раз он изменял реквизиты. У каждого из них будут свои обороты и остатки, и они не будут никак соотноситься друг с другом. Такие вещи, как автомтический расчет скидки по истории взаимоотношений также будет работать некорректно.

Просто изменив реквизиты, вы измените их также для ранее проведенных документов - то есть намеренно внесете в них ошибку. Если когда-нибудь понадобится распечатать старый документ, то вы обнаружите в нем расхождения с тем, что было на самом деле в этом периоде.

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

insodaПрезентация это хорошо, только непонятно. Нет ли у Вас текста доклада?К сожалению, текста доклада нет. Звук не писался...


insodaПохоже, то, что Вы называете "свойства", реализовано в 1С:Предприятии 8.0 и называется характеристики .Да, действительно, похоже. Только когда делался этот доклад, версии 8.0 еще не было в природе. И еще есть несколько нюансов. 1С-овские "характеристики", насколько я понимаю, ориентированы на использование "числового" типа, например, для задания мощности. В моем случае для этого используется тип "измеряемая величина", для которого обязательно еще задается базовая единица измерения . В используемом мной приложении автоматически ватты в киловатты (и наоборот) еще не преобразовывались, но такое преобразование предполагалось.
Далее, кроме характеристики "цвет", на практике иногда требуется использовать такую характеристику как "области применения". Областей применения насоса определенной марки может быть несколько - отопление, водоснабжение, перекачка сточных вод. Таким образом, для подобной характеристики невозможно задействовать ее таким же образом, как характеристику "цвет". Для характеристики "цвет" я использовал тип "список" или "ссылка на справочник" (вся разница между ними - для "списка" создавался скрытый локальный справочник, который не мог более нигде использоваться), а для характеристики "область применения" - "множество" или "множество записей справочника". Для "списка" можно было из комбобокса выбрать одно значение. Для "множества" - поставить галочки напротив одновременно нескольких значений (либо ни одного).

insodaВаше учетное время похоже на оперативную отметку времени Там весь фикус не в том, что учетное время есть , а в том, что времен - ДВА - учетное и текущее. 1С устанавливает "оперативную отметку времени" только на документах и в регистрах. В моем случае вообще любая информация получает одновременно две метки времени. Самый интересный эффект наблюдается на справочниках. Одна и та же запись может оказаться множество раз отредактированной и иметь ровно одно значение на любой момент учетного времени. Заглянув в историю по оси календарного времени, можно посмотреть журнал ее модификации - кто модифицировал, каким именно образом, с какой рабочей станции, когда. Можно также восстановить одну из старых редакций, вытолкнув в журнал (в "историю") текущую редакцию. Эта новая редакция появится во всех старых документах, во всех новых и во всех будущих, которые на эту запись ссылались, сслыаются и будут ссылаться. То есть, на оси календарного времени не может быть двух разных действующих записей.
По оси же учетного времени они могут быть. Если организация изменила реквизиты, причем, этот факт стал известен с опозданием на полтора месяца, то на оси учетного времени заводится новый "клон" текущей записи. Старый "клон" появляется в старых документах, новый - в новых. Причем, система знает, что это одна и та же организация. Заглянув в параметры двух времен одновременно, можно увидеть, что информация о "клоне" введена таким образом, чтобы новые реквизиты появлялись вместо старых, допустим с 01.06.2006, но введена реально эта информация была на оси календарного времени 15.07.2006 сотрудником Сидоровой, которая при этом сидела не за своим компьютером, а за компьютером Петрова, да еще в 3 часа ночи (что позволяет кое над чем задуматься). "Клонов" по оси учетного времени может быть множество, каждый из "клонов" может многократно правиться на оси календарного времени (имеет свой собственный журнал модификации). Удаленные записи физически не удаляются, и могут быть просмотрены - кто и когда их удалил. Причем, найти удаленную записб может любой имеющий на это право пользователь, не обращаясь к сисадмину.

insodaТо для чего Вы предлагаете использовать суррогатные ключи в терминах Сергея Нуралиева называется "прикладные данные, имеющие объектную природу"То, для чего я предлагаю использовать суррогатные ключи (обратите внимание, их ТРИ (!), причем каждый имеет тип uniqueidentifier), позволяет не только отслеживать модификацию объектов по двум осям времени, но и осуществлять бесконфликтную двустороннюю репликацию данных между множеством серверов. Точнее, конфликты репликации не возникают ФИЗИЧЕСКИ, поскольку отсутствует операции модификации записей - только добавление и удаление. Такая схема работы позволяет обнаруживать конфликт репликации на более высоком уровне бизнес-логики и обрабатывать его унифицированным образом, не привлекая для этого DBA. Конфликты устраняются теми пользователями, которые этот конфликт создали.

Ну, про все нюансы и нюансики рассказывать действительно долго. Тот граф, на который Вы обратили внимание, разъясняет технологию обработки событий в рамках концепции "детерминированного времени". Эта концепция предполагает взаимосвязь некоторых событий во времени, причем, некоторые события в будущем как бы " уже произошли ". То есть, допустим, к вам с егодня поступил платеж за товар. Что делать, если за товаром никто не приедет? Не приедет не просто через три дня, но даже через три года... Вы должны списать невостребованную задолженность на внереализационные доходы, вот что вы должны сделать! Что вам известно на секгодняшний момент? На сегодняшний момент вам известно, что от клиента поступили деньги, но он за товаром НЕ ПРИЕХАЛ . Если вдруг приедет - возникнет событие , которое изменит текущую картину движения на протяжении многих участков учетного времени. Пока же он не приехал, производится обработка только тех событий, которые известны системе на момент возникновения этих событий с учетом послендовательности их возникновения. Причем, что очень важно, обработка затрагиват движения по регистрам не только в момент возниковения события и не только на учетную дату возникновения первичного документа, но и в будущем - с учетом той картины событий, которая уже произошла, в будущем генерятся (синтезируются) документы, напоминания, движения по регистрам и т.д. и т.п. с учетом того, что более никаких событий к тому времени не произойдет.
Такой подход позволяет избежать применения JOB-ов, которые отслеживают какие-то таймауты. В ядре системы единообразно отслеживается сгенерированное в будущее учетное время некоторая информация, которая по мере достижения текущим (календарным) временем этого будущего ее актуализирует (ктивизирует, например, отправку сообщения-напоминания, которое заранее в это "будущее" уже было "отправлено"). Насколько мне известно, в 1С подобные подходы не реализованы.