Цитата:
Сообщение от
Bega
Нам пришлось делать доработки, чтобы не было проводок через транзитный счет, в переносе остается только одна проводка ГК, которая генерится для расходной складской проводки. Это касалось у нас только журналов переносов, в заказах на перемещения слава Богу не пришлось делать.
Поскольку я в АНДшные времена сделал этот профиль разноски, я тут пожалуй что поясню некоторые тонкости. В моем варианте, я тоже задавил этот промежуточный счет, но дорогой ценой. В классической разноске модуля логистики, всегда (эээ - за вычетом разноски закупок) участвуют два счета - складской и коррсчет. Поскольку перенос состоит из одной приходной и одной расходной проводки, по каждой создается по паре постингов. Я в своем варианте, просто задавил постинги по приходной проводке, а по расходной проводке начал делать разноску между двумя СКЛАДСКИМИ счетами, складским счетом из расходной проводки и складским счетом из приходной проводки. Все это работало, но в принципе приводило к некоторому развалу целостности данных. В стандарте можно написать отчет, который считает сальдо и обороты по номенклатуре в разрезе складских счетов ГК. (Поскольку inventTrans и inventTransPosting связаны однозначно). В моем же варианте, данные по приходной части inventTransPosting были малость туфтовыми, поэтому подобная оборотка, местами разъезжалась бы с данными ГК. Когда локализаторы делали эту функциональность, я с ними обсуждал эту проблему и, вероятно, именно из за этого они мой подход использовать не стали. (Кстати не уверен что я бы на их месте сам стал бы использовать мой старый подход. Все таки это затычка была).
Кроме того, когда я этот профиль разноски делал, я в него закладывал два параллельных (но связаных) подхода. Во первых - это чисто бухгалтерский механизм для подстановки счетов ГК в проводку. Во вторых - это все-таки некоторое отражение реальной жизни для разделения склада по, гм, видам хранимого товара/материала. При этом профиль разноски по складу из складской аналитики ВСЕГДА первичен. Я предполагал что если тебе нужно чтобы разные профили подставлялись в зависимости от склада, клиента или еще какой-нить новой аналитики, то ты всегда сможешь написать какую-то приблуду, которая будет этот профиль подставлять в аналитику соответствующего складского документа. (Поэтому я сделал отдельную аналитику - профиль, а не стал завязывать разноску напрямую на сочетание значимых аналитик (типа склада).)
Локализаторы тоже пошли этому пути; в их варианте профиль автоматически подставляется по ряду условий (каких - не помню, я за локализацией года с 2009ого толком не слежу).
Конечно, некоторые связи подхода в локализации с моим профилем разноски есть, но говорить что он 'скопирован' из АНДшного приложения - неверно.
Да еще для протокола: Первая версия функционала была написана в ноябре 2002 года для поддержки 15ого счета, а не для разделения давальческого и недавальческого.
Хотя, конечно, о такой возможности я тоже думал...