Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

Что интересно, в отечественных системах часто один справочник – «контрагенты», а в большинстве зарубежных – и «поставщики», и «подрядчики, и „перевозчики“, и т. п. Как следствие, ответ на вопрос „«кто сколько нам должен?“«получается не совсем очевидным… – Д. К.

Бухгалтерский учет—термин используется как для метода учета, описанного еще Пачоли и использующего двойную запись, так и для части учета, предназначенной для демонстрации налоговой службе, в противоположность управленческому учету . Как разработчики используют последний термин, тоже нужно разбирать особо. Во всяком случае фраза «Управленческий учет построен по принципам бухгалтерского учета» оказалась для некоторых разработчиков не такой ясной, какой представлялось мне.

А вот это исключительно наше изобретение. Во всех остальных странах управленческий учет – это не «черная касса», а просто более детализированный учет (в основном учет затрат и доходов). Управленческий учет в западном его понимании совсем не противоречит финансовому. – Д. К.

Кроме отдельных понятий оказывается смазанным также и смысл целых предложений. Высказывание «В системе поддерживаются стандарты бухгалтерского учета РСУ, IAS, GAAP» может означать:

1) что учет возможно организовать по любому из стандартов, но ровно по одному;

2) что, используя счета и проводки, сделанные по российским правилам, можно сваять отчет по IAS или какому-нибудь из GAAP;

3) что для одного из GAAP или для IAS используются свои счета и свои типовые хозяйственные операции.

Нет такого стандарта, как GAAP. То есть совсем нет. Многие страны именуют свои правила учета «общепринятыми» (то есть generally accepted, или GAAP), поэтому аббревиатура бессмысленна без указания страны, откуда родом стандарт (например, US GAAP). – Д. К.

Вот еще пример: пункт меню под названием «Распечатать жирорасчет по счетам-фактурам на заказ». До сих пор не знаю, что имелось в виду. Вообще, перевод, выполненный лингвистами, не владеющими основными понятиями из предметной области, приводит иногда и к очень серьезным последствиям.

Пример из той же Axapta. В свое время термин invoice разработчик перевел (что характерно для западных систем) как «счет-фактура». Беда заключалась в том, что в те времена в законодательстве не существовало определенного срока, в течение которого нужно было выдавать эту фактуру, и были возможны ситуации, когда ее либо не существовало вовсе, либо она выдавалась со значительными задержками сразу на много поставок. В результате – либо в системе не следовало формировать фактуру до момента ее поступления (результатом чего становилась неучтенная задолженность), либо формировать (и получить косяк с формированием отчетности по НДС, в которой операция не считалась таковой без нужных бумажек). – Д. К.

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

Когда разработчик приводит примеры успешного использования, нужно выяснить, предлагается вам та же версия системы или один софт связан с другим только торговой маркой.

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

Даже ответам «Этим мы не занимались» и «Этого мы не предусматривали» нельзя слишком доверять: они могут характеризовать уровень знаний отвечающего, а не саму систему.

Но если вы услышите фразу: «Мы как раз сейчас разрабатываем версию системы, которая в точности удовлетворяет вашим потребностям», – улыбнитесь как можно лучезарнее и скажите: «Замечательно! Дайте мне знать, когда эта версия будет готова», – и бегите, бегите из того места, где вам это сказали!

Итак, вопросы.

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

2. Идеология: от финансов, от документов, от товаров etc. (Разработчики обычно любят разглагольствовать на эту тему, однако смысл того, что они говорят, не всегда уловим. Иногда прояснить ситуацию позволяет простой вопрос: какой из модулей написан первым. Конечно, система «от склада» или «от бухгалтерии» звучит не так романтично и идеологично, зато дает определенное представление о том, как повернуты мозги разработчиков. Отрадно отметить, что сейчас на рынке появились системы, которые продумывались при проектировании целиком.)

Еще любопытный момент: делалась система «от процессов» или «от структуры данных». Опыт подсказывает, что вторая система будет более жизнеспособной, так как при совершенно разных процессах данные, необходимые участникам, отличаются не так значительно.

К сожалению, большинство зарубежных систем – процессоориентированные (то есть будут хорошо поддерживать разграничение ответственности при прохождении процессов, но доставят немало головной боли при попытке модифицировать процесс либо получить из системы нестандартный отчет). – Д. К.

3. Поддержка разработчиком изменений в законодательстве. (Не стесняйтесь спрашивать: «Что произойдет, когда Госкомстат заменит форму ТОРГ12 на ТОРГ13?» – в ответ иногда можно услышать и правду: «Сами исправите или нам денег заплатите».)

И еще уровни прохождения заявки. То есть: сначала попугай внедренца, потом консультант внедренца, потом программист внедренца, затем (если ошибка глубоко) попугай поставщика системы, затем старший попугай поставщика системы, затем консультант поставщика системы… и так до двадцати человек, пока мы не узнаем, что наша ошибка исправлена не будет или будет исправлена в новой версии в следующем году. – Д. К.

4. Авторское сопровождение системы (нет, есть: бесплатно или платно). Его уровень (hot line, консультации у разработчика, консультации на месте, исправление обнаруженных ошибок, возможность модификаций, не связанных с ошибками, по запросу клиента)

5. Организация рабочего места (АРМ).