Сообщения, отправленные пользователем: dk

nmzn1 wrote:

dk wrote:Для чего дано время до 01.04.2019 по готовой молочке, чтобы все смогли наладить свои бизнес-процессы. А то потом как обычно 01.04.2019 все вдруг осознают, что у них работа не налажена, персонал необучен, людей не хватает, всё пропало

неа, не так время дано, чтобы разработчики наладили свою систему (шлюз мерка), а на 01.07.18 - неготова оказалась именно она

Сейчас шлюз работает более менее нормально, по крайне мере взаимодействие веб - шлюз наладилось, теперь если ошибка, то она и в вебе и на шлюзе.
ВСД выписанные в вебе, стали нормально гасится через шлюз.

Очень боюсь сглазить

Со старыми ВСД оформленными до обновления 6.5 ещё могут быть проблемы.

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

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

Пуговица wrote:Дело в том, что это может быть не единичным случаем. То есть не так, что инвентаризация проведена в меркурии и по факту и всё совпало, а потом расхождений не будет , и не во внимательности или ошибках. Когда большое производство, в одну продукцию идут до 10 номенклатур разных поставщиков , в десятках тоннах по весу, расхождение по инвентаризации по факту всегда, как по мне, будут иметь место. Вопрос в том, правильно ли добавлять продукцию через инвентаризацию , если она поступила по ВСД

Укажите при добавлении в описании в акте о несоответствии, что продукция добавляется на основании такого-то входящего ВСД (лучше UUID) и всё. Юридически всё будет чисто.

nmzn1 wrote:

СВЕТЛАНА29 wrote:Вообще то по этому вопросу у нас в Мерке проблем нет Прежде чем что-то сделать надо подумать

как раньше то безо всяких мерков все работали и продукция в СССР была отменного качества, вопрос

Отступление:
Раньше земля была плоская и стояла на 3х китах

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

По теме:
Это обычная ситуация, когда смешивают точный меркурий, где всё нужно делать по факту (гасить входящий, делать производственный и транспортный ВСД с фактическим объёмом) и бух. учёт, который не требует такой точности и оперативности.

Спасибо за отзыв.

oleg-x wrote:Ну придет проверка, попросит показать документы на товар, по которым принимали. Открою меркурий и посмотрят, сколько по меркурию прошло. и тут выяснится что по меркурию прошло одно количество, а по факту другое.

Тут всё просто: нужно по меркурию принимать то, что пришло по факту

То, что я пытался донести, сейчас, в основном, все осуществляют приёмку по накладным, а не по факту, а надо по факту, тогда и склады не поедут.

Den4ik322 wrote:Здравствуйте,подскажите как аннулировать входящий не погашенный ВСД,поставщик отправил не на тот адрес!

Входящий нельзя аннулировать. Аннулировать должен отправитель(поставщик).

anyman wrote:Хорошо, спасибо!

http://меркурий.рус - можно легко создать новую площадку, если есть данные Ветис.API

Vladimir2017 wrote:

dk wrote:Так точно. Нет смысла смешивать бух. учёт и меркурий.

Вот уж поверьте - стоит.

Что стоит

Чем помогает связь бух. учёта и меркурия решению описанных выше проблем?

Vladimir2017 wrote:Сначала ваша интеграция попробует создать ТВСД из продукции которой уже нет.

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

Vladimir2017 wrote:А потом вы узнаете что партия списанная под ноль инвентаризации не подлежит.

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

Vladimir2017 wrote:А потом узнаете про то, что на партию, созданную через инвентаризацию нужны новые лаб. исследования.

Тоже логично. Инвентаризация - это не рабочий инструмент, это инструмент для исправления ошибок и неточностей.

Vladimir2017 wrote:А потом придет проверка и округлит глаза. Ну и так далее. "О сколько нам открытий чудных..." (с)

«Чушь, компот и какие-то бумажки» Медведев Д.А.©
Какая связь между бух. учётом, меркурием, интеграцией и проверкой? Тем более, что проверки по бух учёту и меркурию разные.

zlatmoloko wrote:

dk wrote:Так точно. Нет смысла смешивать бух. учёт и меркурий.

Насчет приемки сырья и производства - согласна, у нас например в 1с и нет точных, а тем более оперативных документов на этот счет (бухгалтера могут завести их и через неделю или в конце месяца).
Но отгрузка продукции оформляется в 1с УТ11, работают посменно 4 человека, без выходных и набирать еще раз все накладные в Меркурии не хочется, да и некому.
Если брать дополнительные кадры, то для работы без выходных - еще хотя бы 2 сотрудника, да и то пик работы придется чуть ли не на ночь, чтобы к утру перед отгрузкой были оформлены все ВСД.

Вы делаете накладную в 1с УТ11 и без дополнительных трудозатрат оформляете исходящий(транспортный) ВСД?
А как же производственные ВСД, кто их оформляет?

Den1s0N wrote:

dk wrote:

Vladimir2017 wrote:

dk wrote:На крупном молочном заводе в лен области разделили бухгалтерскую приёмку в 1с и меркурии, т.к. фактически принятый объём знает только приёмщик, только после приёмки, и он гасит входящие ВСД в меркурии с фактическим объёмом.

А через три месяца будут бегать с выпученными глазами, выдергивая волосы на голове, с воплями "Склады поехали!1"

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

А разве не физ.вес в меркурии, а в бух. учете вообще базисный вес приходуется.

Так точно. Нет смысла смешивать бух. учёт и меркурий.

Vladimir2017 wrote:

dk wrote:На крупном молочном заводе в лен области разделили бухгалтерскую приёмку в 1с и меркурии, т.к. фактически принятый объём знает только приёмщик, только после приёмки, и он гасит входящие ВСД в меркурии с фактическим объёмом.

А через три месяца будут бегать с выпученными глазами, выдергивая волосы на голове, с воплями "Склады поехали!1"

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

https://aplms.vetrf.ru/pub/
Там на 2 шаге можно выбрать ХС, который вы хотите подхватить.
А GTIN нужно у каждого продукта придётся менять.

А вообще почему просто не поменять данные ХС, чтобы не получать новые доступ?

На крупном молочном заводе в лен области разделили бухгалтерскую приёмку в 1с и меркурии, т.к. фактически принятый объём знает только приёмщик, только после приёмки, и он гасит входящие ВСД в меркурии с фактическим объёмом.

nmzn1 wrote:

BFT wrote:А 3.0 то вообще будет?
Маркировка, ЕГАИС, 1 апреля, 22 апреля, вообще ничего не понятно.

3.0 хотели на новый год замутить - тут ещё поверю
1 апреля (22 апреля, 1 июля...) - маркировка, общий егаис, старт готовой молочки - никогда не поверю

Когда запустят API 3.0, отключат API v1.4, думаю из-за 1.4 проблемы с совместимостью портала меркурий и API 2.1
В API 1.4 были возможности прописывать даты строкой и т.п.