Letyshops

STR: Приложение для бухгалтера

Тодд Бойл
Система тройной бухгалтерии | Система тройной бухгалтерии (продолжение) | "Межфирменный счет" | Теоретическая база STR

Рассмотрим варианты. Совместное хранилище данных о сделках можно получить, используя любую мощную систему учета для нескольких компаний. Такая Главная книга для каждого участника позволяет вести классическую двойную бухгалтерию (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 намного проще. Она моделирует событие только на стадии завершения или исполнения сделки. Эта модель хранит сумму и иные атрибуты в том виде, в каком их согласовали обе стороны, и, естественно, хранит их лишь в одном экземпляре, а не в двух книгах, в отличие от книги для нескольких компаний.

<<предыдущая [1][2][3][4] следующая>>
[вид для печати]
© Тодд Бойл

 

 

Реклама: