AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.06.2017, 21:55   #21  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,678 / 529 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
...
Нет универсальных вариантов как делать что-то определенное. Все эти паттерны, принципы не говорят что нужно делать только так, а никак иначе. Они просто предлагают, что есть вот такие возможности, а какими именно из них нужно следовать уже зависит от задачи. Только вот чтобы решить использовать ли эти вещи или эффективнее в определенных ситуациях их игнорировать, нужно простое правило - разработчик/архитектор все таки их должен знать.
Именно что инструментарий.

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

Да, можно сделать так чтобы это разбиение было интуитивно и обоснованно, но мало кто так может, будут нормализовывать код до размазни и думать об абстрактной красоте, а не о практичности использования. Поэтому пусть эти 2000 строк там и останутся.

То ООП которое есть оно делает систему монолитной и запутанной. По большей части именно потому что за дублирование кода сжигают на костре. А паттерны там где они абсолютно бесполезны - приветствуют.
Старый 24.06.2017, 22:58   #22  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,678 / 529 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?
причем это касается, и аксапты, и навижина, и, насколько я понимаю, MS CRM.

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

подключение нового инструментария? пусть так.
но почему этот инструментарий не распространяется на всю экосистему?

=================
и еще. пусть эксперименты.
а каков механизм избавления от этих экспериментов?

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

в программировании это рефакторинг legacy-систем. есть много холиваров на эту тему.
но МС код вообще не рефакторит.
...
какие еще примеры экспериментов и Оver-engineering в программных продуктах можно привести?
есть ли примеры успешного преодоления последствий?
какие еще механизмы есть в программировании для борьбы со сложностью и устаревшим кодом? есть ли примеры-аналоги?
Как Groupon мигрировал от монолитного Rails приложения к новой Node.js инфраструктуре
https://habrahabr.ru/post/200906/
Цитата:
Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.
Старый 25.06.2017, 05:19   #23  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Если бы Жаба программировала человека, то для рта и ануса она бы создала РотАнус, с общими функциями/свойствами
сжать - разжать, туда-сюда, молчит - говорит.
Ну и супер-предка - Отверстие.
Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.
__________________
Isn't it nice when things just work?
Старый 25.06.2017, 16:35   #24  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,678 / 529 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от macklakov Посмотреть сообщение
Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.
Мысль о том что прослойка между GUI и DB слишком много о себе вообразила - крайне интересна.
Это стоит подумать.

Цитата:
Сообщение от macklakov Посмотреть сообщение
Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.
Старый 25.06.2017, 19:33   #25  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,678 / 529 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?
Хороший пойнт. Разные источники данных.
Можно и сказать что и GUI - главное. Но если смотреть в корень технической реализации то скорее таки база данных. Все остальное оболочка ввода и вывода.
Востребованная функциональность - это да. Но не важно как она реализована через простое ООП, сложное ООП или без ООП.

По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.

Последний раз редактировалось ax_mct; 25.06.2017 в 19:49.
Старый 26.06.2017, 23:16   #26  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,985 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
> Никому не нужна общность отверстий кроме программистского мозга.

Я знаю одно выражение, использующее общность отверстий. Там прямо квантор всеобщности и просторечное выражение обозначающее отверстия (но по контексту ясно что не имеются ввиду прорехи в одежды).

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

Я бы стал извлекать сведения из доменного специалиста или книжки, но мне влом.

В википедии:

"The anus (from Latin anus meaning "ring", "circle") is an opening at the opposite end of an animal's digestive tract from the mouth."

"In biological anatomy, commonly referred to as the mouth, under formal names such as the oral cavity, buccal cavity, or in Latin cavum oris,[1] is the opening through which many animals take in food and issue vocal sounds."

"Some animal phyla, including vertebrates, have a complete digestive system, with a mouth at one end and an anus at the other. Which end forms first in ontogeny is a criterion used to classify animals into protostome and deuterostome."

То есть у тех, у кого есть пищеварительная система на одном конце есть отверстие рот, на другом анус. Как эксплуатируется эта общность явно выраженная в википедии, фиг знает.

Всякие вендоры, кастомеры и контрагенты как понятие не являются элементом реальности. С моей точки зрения. Они уже предмет какой-то классификации с какой-то точки зрения. Даже то, что вот эти два оранжевых кругляшка классифицированы как апельсины - уже результат анализа.

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

Соответственно пример со ртом и анусом мне непонятен и почему вендор - взят из реальности, а контрагент - нет тоже.

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

Плохо придумывать свои термины, когда есть готовые, надо смотреть что люди уже успели наклассифицировать, но из-за ограничения скопа и ограничений формальных языков иногда полезно.
Старый 27.06.2017, 00:08   #27  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,678 / 529 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от belugin Посмотреть сообщение
тем более, что непонятен контекст - хочет жаба лечить человека, препарировать его или кормить.
...
Еще следует учесть, что формальные языки отличаются от естественных: что-то может подразумеваться по контексту, что-то быть сформулированно выражением, так что вполне может появится класс РотИлиАнус или типа того.
...
Плохо придумывать свои термины, когда есть готовые, надо смотреть что люди уже успели наклассифицировать, но из-за ограничения скопа и ограничений формальных языков иногда полезно.
Ход мысли понятен. Моя ход в том что жаба не понимает что такое лечить или кормить. Ей просто надо разложить на части, в разные баночки по общности признаков.

Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.
Старый 27.06.2017, 05:00   #28  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от belugin Посмотреть сообщение
Соответственно пример со ртом и анусом мне непонятен и почему вендор - взят из реальности, а контрагент - нет тоже
В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто. И в это понятие совершенно естественным образом попадают и сотрудники и арендаторы и даже банки.
Есди продолжать проводить аналогии с биологической классификацией, то oris и anus объединили по каким-то общим признакам, а вот нос, желудок, верхние и средние разделы кишечника, протоки желез в эту классификацию почему-то не попали. При этом физиологически они сделаны разными, а вот перифирийная нервная система из одного узла активируется.
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 07:50   #29  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,985 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от macklakov Посмотреть сообщение
В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто.
Цитата:
Сообщение от macklakov Посмотреть сообщение
Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию.
Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?
Старый 27.06.2017, 07:53   #30  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,985 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Ход мысли понятен. Моя ход в том что жаба не понимает что такое лечить или кормить. Ей просто надо разложить на части, в разные баночки по общности признаков.
Тут мне ниже говорят, что в случае custvend общность признков-так есть и она полезна. И в исходном треде полно специалистов которые как мне кажется пришли к такому выводу

Цитата:
Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.
Что такое ООП-общность и чем она отличается от других видов общности?
Что такое "Кросс-модульная организация кода"?
Старый 27.06.2017, 08:34   #31  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от belugin Посмотреть сообщение
Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?
Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger.
И вот в системе у нас ГК, которая делает CustTrans, VendTrans ненужными. Но и CustVendTrans тоже никуда не неделись. При этом TaxTrans почему-то в эту чудесную иерархию не попадают. И payroll тоже. И даже для банков у нас какой-то причудливый reconciliation, который, по сути дела, тот же settlement, только чудовищно кривой.
Т.е. как раз дублирования в коде и функционале выше крыши. И чтобы это дублирование поддерживать, приходится писать всякие феерические reconciliation reports. Количество дублирования только нарастает. Но при этом произвольные куски вдруг покрыты иерархиями. В то время как другие вполне себе отдельно живут.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 27.06.2017 в 09:26.
Старый 27.06.2017, 10:53   #32  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,295 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger
Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же, в ГК ? А что, мне нравится. А то понапридумывают фреймворков-шмеймфорков непонятных
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: macklakov (1).
Старый 27.06.2017, 11:35   #33  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же
Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR. Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?
И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 13:03   #34  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,295 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR
Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)
Цитата:
И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?
Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?
Цитата:
Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?
Вы делаете глобального характера выводы на основе своих, достаточно частных и порой спорных, экспириенсов. Это их сильно девальвирует (да простят меня читающие за англицизмы)
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: EVGL (1).
Старый 27.06.2017, 13:06   #35  
Pavel is offline
Pavel
SAP
SAP
 
2,730 / 235 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.
Поддерживаю. Надо было апдейтить ядро, совершенствуя технологии и оставить в покое бизнес-логику и БД, написанную на 4GL.
Старый 27.06.2017, 13:23   #36  
Pavel is offline
Pavel
SAP
SAP
 
2,730 / 235 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от ax_mct Посмотреть сообщение
По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.
Хмм... содержательная у вас тут дискуссия.)
Иногда заглядываю, что обсуждают кодеры в первых топиках и прихожу в ужас. Такая 'эволюция', просто как с навигатором по GPS в сортир дома ходить... а когда пропадает сигнал, 'забыв обо всем', решать вопросы со спутниками и коммуникациями.

Если отвлечься от 'бытовухи' и чисто ради 'академического интереса' задаться вопросом: насколько ООП сочетается/противоречит технологии слоев (своего рода полиморфизм) или системным номерам таблиц и полей (выделение диапазонов для ядра и доработки)? - то становится интересно мнение творцов этого синтеза.)

ООП это все не нужно, как самодостоточной технологии.
За это сообщение автора поблагодарили: 6a6kin (1).
Старый 27.06.2017, 13:59   #37  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,563 / 3388 (170) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Computer, open pen
https://www.youtube.com/watch?v=nY7i7kj2jO4
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
За это сообщение автора поблагодарили: macklakov (1), Bobkov (1), ax_mct (2).
Старый 27.06.2017, 14:53   #38  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)
скидки по оплате и aging? можешь описать как и зачем?
Цитата:
Сообщение от Vadik Посмотреть сообщение
Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?
Зачем такие аналитики нужны? Я вот видел системы где счета через черточку и AR это буквальным образом счет accounts receivable в ГК и один из сегментов это именно клиент. Очень сильно напоминает эти самые entity backed. И еще очень характерная технология это journal transfer. Т.е. проводки пишутся журналами и лишь потом, отдельной операцией, переносятся в ГК. Ничего не напоминает?
Т.к. мы заменяли эту замечательную систему на AX, нам даже требование впендюрили, наладить периодический перенос журналов. Что было с легкостью реализованно ибо у нас теперь есть синхронная, асинхронная и batch разноска. Вы все еще думаете это великий замысел, с целью разгрузить сервера? Такой великий замысел что пришлось покрыть каждый модуль reconciliation reports, чтобы проводки между модулями и ГК не слишком сильно расходились.
Цитата:
Сообщение от Vadik Посмотреть сообщение
Вы делаете глобального характера выводы на основе своих, достаточно частных и порой спорных, экспириенсов. Это их сильно девальвирует (да простят меня читающие за англицизмы)
Это правда, мой опыт в последние годы ограничен диковатой колонией и несколькими варварскими странами.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 27.06.2017 в 15:02.
Старый 27.06.2017, 15:12   #39  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 872 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Мне вся эта ситуация с новой ГК видится вот как. Купил мужик на ebay 2 велика:


И сделал из них один. Переднее колесо от первого, а заднее от второго. Получилась универсальное средство передвижения. Можно как в старину, крутить педали на большом колесе, а можно по ново-модному, через цепную передачу. Мысль была в том, что и дед будет доволен и дочка.
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 15:46   #40  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2015
Лучший по профессии 2014
 
3,518 / 1996 (74) ++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от macklakov Посмотреть сообщение
скидки по оплате и aging? можешь описать как и зачем?
Легко. В пересчете на год процент скидки по оплате обычно заведомо превышает ставку рефинансирования, поэтому экономически выгодно платить поставщику в последний день действия скидки по оплате если последняя предоставляется. Такую стратегию можно выбрать в предложениях по оплате.

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Похоже "Лучший по ..." превращается в "филькину грамоту". Что сделать, чтобы не превращалась? mazzy Обсуждение форума 47 18.10.2013 21:21
"Эти ваши интернеты": Прянишников "нокаутировал" Плющева mazzy Курилка 2 20.10.2011 10:56
Call of Duty: "No Russian" или "Ни слова по-русски" EVGL Курилка 30 01.02.2010 11:28
"Выделить все" и "Отменить выделение всех" Gustav Курилка 5 18.09.2009 14:40
"Счастливый кроха" в фильме "Бригада" Gustav Детская 14 01.06.2007 11:53
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:53.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.