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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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