Импорт истории продаж номенклатуры

[Sirius]

Здравтсвуйте.

Возникла задача импорта истории продаж номенклатуры в Аксапту из другой программы..

Может кто-нить этим занимался..
Куда копать?

Достаточно с импортировать информацию о дате и цене закупки и о датах и ценах продаж

[YVAS]

Вам нужен именно механизм импорта? И что это за другая программа?

[Sirius]

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

"другая программа" - это программа которая сейчас используется на предприятии (самописная)

[mazzy]

импорт здесь
http://axapta.mazzy.ru/hints/import/
http://axapta.mazzy.ru/hints/inventimport/

про импорт проводок без программирования здесь
http://axapta.mazzy.ru/hints/easyimport/

про импорт проводок с программированием...
надо писать. Но суть ничем не отличается от обычного импорта. Только надо следить за нумераторами.

[YVAS]

Цитата:

вернее куда все это надо импортировать?

Хм...что то не пойму тогда, кто же Вам задание дал...

По поводу импорта. Есть два пути:
1 - через текстовый файл с разделителями
2 - через файл Excel.

И в том и в другом случае Вам нужно из вашей программы выгружать данные. В вашем случае еще легче. Вы можете выгрузить данные в файл любой конструкции. А импорт произвести стандарными средствами Ax.

[Sirius]

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

мне вот теперь интересно в какие таблицы нужно грузить данные о покупках и продажах и как лучше это делать..

клавиатурные макросы выглядят заманчивыми...

[mazzy]

а... тут я пожалуй пока пас. это длинный вопрос.

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

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

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

Спросите конкретнее.

[Sirius]

так я попробую сформулировать что нам надо..

история продажи нам нужна для анализа продаж (сорри за тавтологию) номенклатуры.

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

задолженности и предоплат клиентов сейчас не надо (и я тихо надеюсь что не понадобится )

на данный момент важен сам факт отгрузки товара.. остатки на складе нужно тоже сгрузить...

[mazzy]

тогда навскидку
inventTrans
inventTransPosting
inventSettlement

затем пересчитать inventSum.

Естественно, что надо подготовить все таблицы, ссылки на которые упоминаются в данных таблицах. Например, сам inventTable, inventTableModule и т.п., inventDim со всеми складами, партиями, серийными номерами, ГТД, цветами, размерами и т.п, нужно подготовить vaucher и ledgerTrans, чтобы не было мучительно больно переходить в нормальную работу с проводками по главной книге.

Может еще что-то вспомогательное. Но главное - это.

На самом деле, хорошо бы все же информацию по клиентам тоже закачать, чтобы отчеты можно было человеческие делать, а не только по складу. Тогда нужны SalesTable, SalesLine, хотя бы CustInvoiceJour, CustInvoiceTrans. Желательно проанализировать необходимость других Cust-таблиц. Все же я бы не отказывался от импорта CustTrans... Но если вы начнете импортировать CustTrans, то надо думать о сопоставлениях продаж и оплат...

Накладные расходы будут? Тогда нужны MarkupTrans. И тогда надо очень внимательно относится к inventSettlement.

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

Для начала, разберитесь с invent-таблицами.

[BOAL]

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

к ним нужно строить дополнительно CustInvoiceTrans (Jour) и VendInvoiceTrans (Jour)
Вот тогда можно анализировать реальное положение дел (токо стандартных средств такого анализа нет - пишите свое)

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

Если есть доступ к коду, то проблема решается довольно быстро.

Похожая процедура была проделана при переходе с XAL на Axapta одного клиента .
Но там переносились схлопнутые исторические остатки по ФИФО.... для дальнейшего анализа ценообразования по партиям и запасов.
Ну и доступ к коду XAL, очевидно, был.

[Sirius]

выгрузить то данные не проблема...

пока что проблема их корректно загрузить

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

[glibs]

Цитата:

Изначально опубликовано Sirius
...результатом анализа должно стать определение группа ABC по скорости реализации и доходности от продажи номенклатуры.. исходя из этих данных нужно будет планировать закупки новых товаров...

задолженности и предоплат клиентов сейчас не надо (и я тихо надеюсь что не понадобится )

на данный момент важен сам факт отгрузки товара.. остатки на складе нужно тоже сгрузить...

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

Если надумаете качать... Я не знаю, из каких таблиц берутся данные для АБС анализа, но думаю, что вам понадобятся и inventTrans и CustInvoiceJour/Trans (эти то точно).

Самый правильный способ импортировать транзакции в Аксапту — внести данные в журнал и сделать разноску. История продаж в вашем случае не является исключением. Журналом для регистрации операций продажи номенклатуры является Заказ. Т.е. вам придется научиться импортировать данные в таблицу с заказами. Я такого пока еще не далал, но, судя по всему, должен сработать обычный импорт заголовков заказов и строк. Если не получится — пишите, что-то еще придумаем.

Затем заказы нужно разнести. Несколько заказов за один раз стандартными средствами разнести не проблема... Но система при этом подставляет текущую системную дату в инвойс. Как автоматизировать ввод даты разноски у меня идей пока нет. Точнее есть какие-то экстремальные (не программированием, но и не штатными средствами), но я их не тестировал и лучше промолчу по поводу них.

Я бы, по крайней мере, развивал эту идею.

Только учтите при этом следующее.

1. Остатки по номенклатуре вам все равно нужно будет ввести с сохранением истории (даже до того момента, с которого вы решите перенести историю продаж). Иначе у вас некорректно рассчитается АБС классификация по сроку хранения номенклатуры.

2. После "Даты Х" (с которой вы начнете регистрацию продаж) вам придется отразить и все приходы номенклатуры (закупки... и не только, ВСЕ приходы). Иначе опять же вы как минимум некорректно рассчитаете АБС классификацию по срокам хранения. Правда, тут легче. Сами закупки можно не вводить, а отделаться строками складских журналов (импортировать и разносить это будет на порядки проще).

3. Довольно высока вероятность того, что алгоритм расчета себестоимости в Аксапте и в программе-предшественице могут различаться (особенно если речь идет о средней с/с или LIFO). Если на "Дату Х" вы введете корректное сальдо, то к текущему моменту в каждой из программ вы можете получить разные данные по себестоимости. Как минимум, за счет округлений. Эту проблему решить можно учетной политикой в рамках перехода, но все равно неприятно.

4. Вам нужно будет закрывать склад для корректного расчета с/с. Делается это как известно, очень мягко говоря, не быстро. Для сведения затрат на закрытие к разумным, закрытие необходимо делать не реже раза в месяц (если у вас не три операции в месяц). При этом будут генериться финансовые проводки на последнюю дату закрываемого месяца. Вероятность того, что у вас разойдутся финансы при этом крайне высока. Тоже придется делать коррекции при переходе.

5. С разнесенными (в ГК) приходами и продажами придется что-то делать (списывать суммы со счетов доходов и расходов на балансовые счета, возможно, бороться с начисленными налогами).

6. Если после перехода вы хотите использовать функциональность управления складом, то вам либо придется склад настроить сразу и на порядок больше мучиться при разноске операций, либо после ввода истории перенастраивать систему для работы со складом. Что-то мне подсказывает, что это будет неприятным занятием.

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

Может еще что забыл...

В общем, Sirius, я вам рекомендую хорошо подумать над тем, чтобы не импортировать историю в Аксапту, а помучиться некоторое время, рассчитывая АБС анализ в MS Excel и перенося данные затем в Аксапту для дальнейшей работы.

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

[Sirius]

Хм.. очень интересный вариант.. Обязательно его рассмотрим. Спасибо glibs