| Рассмотрим варианты. Совместное хранилище данных о сделках можно получить, используя любую мощную систему учета для нескольких компаний. Такая Главная книга для каждого участника позволяет вести классическую двойную бухгалтерию (CDEA). Рассмотрим пример, в котором Филиал А оплачивает затраты Филиала В посредством "межфирменного счета" ("the intercompany account"). | Главная книга - Филиал A | Июль, 2000 | | Книга№ | Дата | Строка№ | Счет | Сумма | | 4441 | 22/7/2000 | 531 10100 | Средства в банке | Кт -400 | | 4441 | 22/7/2000 | 532 19000 | К оплате между фирмами | Дт 400 | | Главная книга - Филиал В | Июль, 2000 | | Книга№ | Дата | Строка№ | Счет | Сумма | | 73821 | 2000/7/31 | 2355 525300 | Обслуживание транспортных средств - Нью-Йорк | Дт 400 | | 73821 | 2000/7/31 | 2355 250000 | К оплате между фирмами - Нью-Йорк | Кт -400 | Это классический межфирменный учет - так можно делать и сегодня. Установите любой крупный пакет ПО средней мощности с интерфейсом браузера типа Great Plains или Lawson. Продайте подписку ряду компаний. Создайте бизнес-объекты, чтобы заносить в соответствующую книгу каждое событие сделок между компаниями-подписчиками. Средства к оплате или получению между фирмами всегда будут сверены, если оба участника сделки - ваши абоненты. Возможно, некоторые компании, нуждающиеся в сильной интеграции, подпишутся на ваши услуги как, скажем, участника цепи снабжения. Однако книги CDEA для нескольких компаний не работают, потому что: - они навязывают ряд ненужных структур участникам и ограничивают их выбор ПО общей платформой;
- "доверенная третья сторона" получает слишком большой доступ к вашим данным;
- обработка внешних сделок связывает руки, например, требует блокировки ваших таблиц, когда вы работаете с третьей стороной;
- модель классической книги для нескольких компаний содержит намного больше информации, чем те данные, которые действительно являются общими для партнеров. У каждой компании есть планы счетов и другие таблицы, которые не нужны на общем сервере;
- бизнес-процесс слишком сложен. Чтобы создать правильные строки двойной записи для каждой отдельной компании, нужны знания, которые есть только в компаниях, а не на ASP;
- компьютерная обработка данных для всей системы ERP средней мощности слишком велика и не целесообразна из-за аппаратных затрат;
- очень сложно добавлять новые компании, каждая требует чрезмерных системных ресурсов;
- нет надежды, что модель станет общепринятой.
Схема для STR намного проще. Она моделирует событие только на стадии завершения или исполнения сделки. Эта модель хранит сумму и иные атрибуты в том виде, в каком их согласовали обе стороны, и, естественно, хранит их лишь в одном экземпляре, а не в двух книгах, в отличие от книги для нескольких компаний. |
