Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Те, кто сталкивался с международными транспортными перевозками, знают, что для учета там пользуются 2 документами на товар. Для тех кто не знает: “Invoice” содержит полную информацию в формате: 1. Товар 2. Количество 3. Сумма 4. вес нетто/брутто 5. кол-во грузомест (коробок) “Packing-list” содержит в себе только упаковочную информацию: 1. № Паллеты 2. Товар 3. Кол-во коробок 4. шт. в коробке 5. вес нетто/брутто * паллета – место где лежит товар, в одном документе может быть ~ 24 паллеты и в каждой лежать один и тот же товар. Эти два документа всегда ходят парой (как товарная накладная и с/ф) и всегда совпадают товар-количество, но один описывает деньги, другой упаковку. И то и то нужно учитывать. При проектировании БД никак не могут в голове уложиться структуры этих документов и их связь. Дураку понятно, что от инвойса нужно оставить только товар, сумму, а в пакинг-листе учитывать все остальное. Но как сделать так, чтобы номенклатуры документов не расходились, т.е. нельзя было завести в инвойс один товар, а в пакинг лист– другой, и при этом не нужно было бына против каждой группы паллета-товар ставить часть общий суммы? Поясню на примере: Invoice ТОВАР Шт. Сумма Товар 1 100000 50000 Товар 2 6000 1000 Товар 3 50000 4000 Packing № ПАЛ. ТОВАР ШТ. 1_______Товар 1 20000 1_______Товар 3 30000 1_______Товар 2 1000 2_______Товар 1 50000 3_______Товар 1 30000 3_______Товар 2 5000 3_______Товар 3 20000 И как все это хранить? Попутно кто-нибудь может меня научить рисовать нормальные таблички тут =) а то я не умею =( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 15:50 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
авторНо как сделать так, чтобы номенклатуры документов не расходились1. Сделать интерфейс приложения так, чтобы пользователь не мог раскладывать по паллетам товар, которого нет в инвойсе. 2. Если это сделано на сервере БД, то в процедуре или триггере не позволять этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 16:29 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Это не очень красивый выход, я уже думал об этом. Может кто-то встречался с уже реализованной такой системой? Сначала создается packing, потом инвойс, а ногда важнее наоборот, еще как вариант в такой системе можно изменить invoice, не изменив paking и тогда вообще документы нарушатся =(. Их нужно как-то одновременно заносить, синхронно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 16:36 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Например "Invoice" ( InvID PK,....); "InvoiceLine" ( 0. InvID 1. Товар, 1а. Единица измерения количества 2. Количество 3. Сумма 4. вес нетто/брутто 5. кол-во грузомест ) UNIQUE (InvID, Товар) FK (InvID) References "Invoice"(InvID); У вас пример противоречит правилу авторв одном документе может быть ~ 24 паллеты и в каждой лежать один и тот же товар.Основываясь на примере товаров в палете несколько, примерно так: “Packing-list” ( 0. InvID 1. № Паллеты 2. Товар 3. Кол-во коробок 4. шт. в коробке 5. вес нетто/брутто) UNIQUE (InvID, Товар, № Паллеты) FK (InvID, Товар) References "InvoiceLine" (InvID,Товар); Похоже, что в "InvoiceLine" поля 4. вес нетто/брутто 5. кол-во грузомест вычисляемые, тогда их можно убрать. Количество товара для цены может измеряться в единицах, отличных от объема и веса груза, например кабель в метрах. Естественно его оставить. Успехов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 16:46 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
А в таком случае, если packing будет ссылаться на InvID+товар не будет ли ситуация, когда 1. в таблице инвойса товар будет, а в пакинг-листе его, например забудут внести?т.к. если он будет в инвойсе, то по нему должна быть хоть какая-то информация, пусть он даже не в паллете, но он же весит, и кол-во упаковок имеет. (Забыл совсем, а еще бывает так, что товар не паллетирован, просто навален кучей поверх паллет) 2. или, что еще хуже в пакинг листе кор*шт. в кор = 5000 а в инвойсе их будет 10000? Это ведь тоже надо контролировать. Мне бы не хотелось все-таки изобретать велосипед, а хотелось бы взглянуть на пример, как это реализованно где-нить. может видел кто? ну а если не видели, то авайте думать дальше. Я пока от безвыходности додумался до того, чтобы всю информацию хранить в 1 таблице и следить за суммами вручную, но это крайне неудобно. может найдется гений... p.s. вернусь завтра.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 17:05 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
автореще как вариант в такой системе можно изменить invoice, не изменив paking и тогда вообще документы нарушатсяДокументы "рушатся" или не "рушатся" не сами собой, а процедурами и триггерами, которые сделал разработчик. Как сделаешь, так и будет. Вариантов реализации массу можно придумать, это дело вкуса и возможностей разработчика. Такую систему я реализовывал. Но у меня отдельно инвойс и пак-лист не существовали. Все это было в накладной. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 17:10 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Можно такой вариант (схематично): Две сущностит - Invoice и Packing-list. Отношение - Один ко многим. В каждой сущности есть атрибут - Статус, имеющий возможные значения "Корректно"/"Некорректно" (или другие названия по вкусу) Во всех отчетах участвуют только записи у которых этот атрибут имеет значение "Корректно". Пользователь явно править этот атрибут не может. При вставке или редактировании записи этот атрибут автоматически устанавливается в "Некорректно" (в приложении или табличном триггере не суть важно). После завершения манипуляций с записями пользователь жмет кнопку "Проверить Invoice". При этом запускается процедура, которая для данного Invoice и связанных с ним Packing-list проверяет их правильность и непротиворечивость. Если все нормально, то устанавливает статус "Корректно" для всех связанных записей. Если нет, то выдает соответствующие сообщения. PS: Примерно таким образом реализован ввод счетов-фактур поставщиков в OEBS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 17:28 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
> додумался до того, чтобы всю информацию хранить в 1 таблице Хороший вариант. Добавьте еще сущность (в Вашей терминологии - таблицу), где и описывайте отгружаемую партию. Таблицы Invoice и Packing-list будут ссылаться на эту таблицу. Подойдет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 18:02 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Статус это правильно. Плюс разграничение доступа. Если документ приобрел высокий статус, то только высокое должностное лицо может его понизить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 18:02 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Блин, про статус это и в прямь классно, только не в тему. и оч. сложно и геморно в реализации, надеялся на что-то более простое и логичное, я же не 1С строю =) Спасибо тяп-ляпу, но, на сколько я понимаю, для каждого док. pakiD должен начинаться с 1 (0), тогда в таблицу pack нужно включить DockID, что собственно я и придумал, но тогда цену (а значит и вес и шт. в коробке и т.д. и т.п. храним для кажной группы DokID+PackID, а это ручные расчеты или программный разнос суммы из инвойса, где товар посчитан кучей (без packID) я понял, что проще всего разносить суммы, так наверное и сделаем. вся информация будет так: Ключи: InvID PackID и там инфа для каждой записи сумма, веса, коробки. Интерфейс только геморный... сначала заводим packing, без сумм, но со всеми данными (коробки, веса) Затем на его основании строим запрос с группировкой по номенклатуре (данные формы) и проставляем общие суммы из полученного инвойса, нажимаем кнопочку "разнести суммы" и программа их разносит пропорционально по количеству товара в группе InvID+PackID. Вот. По другому никак проще не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 12:14 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
автордля каждого док. pakiD должен начинаться с 1 (0) прошу прощения, ошибся, уточняю: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. PackNo - это номер места отгрузки, нумеруется функцией для каждой накладной, начиная с 1 при создании места отгрузки авторв таблицу pack нужно включить DockIDЭто лишнее авторразнос суммы из инвойса Зачем вообще в строках документа хранить сумму? Она для каждой строки есть Qty * Price и всегда "разнесена" по строкам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 12:28 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Прошу прощения, может я тупой и не умею объяснять. Я для себя уже все понял, спасибо за помощь, но даже последний вариант не катит, т.к. В 2 паллетах из одного документа может лежать один и тот же товар в разных колличествах. а в вашей модели количества указываются в инвойсе. в этом и есть основная беда. но это уже не важно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 13:59 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
> в этом и есть основная беда. но это уже не важно Нет здесь беды. Счета и пр. документы - производные. Опишите сделку (отгрузку, заказ или как там это у Вас называется) отдельно (в отдельной таблице), а потом заполняйте все остальные документы. Ничего сложного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 15:07 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
авторВ 2 паллетах из одного документа может лежать один и тот же товар в разных колличествах. а в вашей модели количества указываются в инвойсе. в этом и есть основная беда Пускай лежит в каких угодно количествах и где угодно или вообще нигде пока не лежит. Чему это может помешать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 16:15 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Зависит еще и от самого процесса создания документов. У нас на предприятии складом создаются Packing List, затем они компонуются в один инвойс. Соответственно Packing List еще и связан с расходом по складу. Соотношение Invoice-> Packing list как один к многим. В Packing List может быть несколько позиций продукта. Есть таблица PackListheader (ID, дата, количество палеттов и ID инвойса). Таблица PackList_details (ID Packing list header, ID Артикля, количество, вес нетто - вес брутто, цена, тип упаковки....). Invoice (ID, имя, тип оплаты доставки, код сделки, валюта...). При создании инвойса пользователь видит те PackingList, ID Invoice которых Null - то есть необработанные. Само создание инвойса - это создание шапки + "закидывание" необработанных Packing List в него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2005, 10:41 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
О! как бывает. а склад не парится вводить цены для каждого товара в каждой паллете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2005, 11:02 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
PafluntiyО! как бывает. а склад не парится вводить цены для каждого товара в каждой паллете? ИМХО склад в таких вопросах вообще не долже париться - он должем вбить артикул товара или идентификатор места хранения и указать количество - цена подтягивается из справочников ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2005, 11:13 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Именно. Цена (продажная) сформирована ранее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2005, 11:15 |
|
||
|
реализация учета фактур (invoice) и упаковочных (Packing) документов
|
|||
|---|---|---|---|
|
#18+
Это учет не исходищих, а входящих документов. и цены постоянно меняющиеся (в зависимости от цены на медь и латунь на международном рынке, но прямой зависимости нет) поэтому, даже есл составить справочник и обновлять его хоть каждый день особой помощи от этого не будет, все равно цену нужно будет проверять. =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2005, 09:25 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=148&tid=1545645]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 267ms |
| total: | 402ms |

| 0 / 0 |
