PDA

View Full Version : Proof of Delivery Document in XML


Robtyketto
27th October 2007, 19:10
Greetings,

I’m a student working on an assignment to upgrade a paper based proof of delivery (POD) system to using e-commerce.

Then general process is as follows:-

* European Customer orders goods (Not required to know how)
* Company picks goods from their only warehouse
* Company (assume at end of every 8hr or so shift) sends XML file over to courier firm database with all order details
* Courier firm uploads data from their database to a pda, customer receives and signs on pda as proof of delivery
* Courier firm uploads only SUCCESSFUL deliveries to companies database via XML file.


So Ive been tasked to produce an XML schema and XML file, from a sample POD I then made a list of possible elements to be included (See list below)

Company
=======
CompanyName
CompnayAddressLine1
CompnayAddressLine2
CompnayAddressLine3
CompanyCounty
CompanyPostcode
CompanyCountry
CompanyTelephone
CompanyEmail
CompanyFax
CompanyVat
CompanyRegistration

Delivery
========
DeliveryNoteNo
DeliveryDate
DeliveryDriverName
DeliveryDriverSignature

Customer
========
CompanyName
CompnayAddressLine1
CompnayAddressLine2
CompnayAddressLine3
CompanyCounty
CompanyPostcode
CompanyCountry
CustomerSignature

order
=====
ItemDescription
ItemCustomerRef
ItemQty


Im trying to find other example PODs, hours spent on Google didn’t find much.

Where my confusion comes from I was advised not to include currency details?? I.e. ItemPrice and CustomerCurrency(GBP or EUR).

Also It was suggested that an acknowledgement element which would details if the goods were delivered or not, and if not why not wasn’t required.
Which seems mad to me else how does the courier communicate to the company the reasons for the goods be dropped back off to the warehouse.

I alos thought about having a ItemWeight field.

So can anyone suggest any other elements that could be included? Or provide example PODS for me to examine or links to where I can browse some?

Hope this makes sense and sorry for the long email.

Cheers
Rob W

ken_uk
27th October 2007, 20:25
If its just a proof of delivery, then why would you need any other details other than a reference and the proof of delivery details?

Robtyketto
27th October 2007, 20:47
Thanks for the reply, I wasnt sure if prices or weight values were included on most proof of delivery documents.

Also part of the assignment is to allow customer to view the proof of delivery documents on the web, formatting the XML file using XSL stylesheet and I would think the customer would like to see the cost of the items.

As for my reasoning for including details of if the delivery was successfully sent or returned was in my opinon seemed the most efficent way for the courier firm to communicate back to the company.

I couldnt see the reasoning why the assignment stated the courier firm would only upload data for the successfully signed off documents.

Im struggling to find real life proof of delivery documents to examine the level of detail included.

Cheers
Rob

DuaneJackson
27th October 2007, 20:51
All the info you have above seems fine. I'd just add delivery time and name of person who signed for it.

Pricing isn't included as this is nothing to do with the delivery.

Delivery and pricing info are often kept seperatley (if you buy someone a book for a pressie via amazon you don't always want them to know what it cost).

Also, if you were to include pricing info, and for whatever reason the original invoice/pricing info changed, then it'd be incorrect. No pointhaving mutliple places to store the same data if it can be avoided.

glencooley.com
28th October 2007, 10:41
Have a look at the UPS/Fedex API's for business to get a feel for what they do, most of them use xml based webservices

Astaroth
28th October 2007, 17:31
Again, wouldnt have the quantity or item description in a delivery company sent file given again if you say it is something high value there is a greater risk of theft.

What would be important also potentially is the number of parcels as a single order could be split over a number of parcels (plus name/ time of the person signing for it) - Could also possibly need a left code if the item doesnt need signiture or if the delivery person left it with a neighbour rather than the addressee etc.

The only other comment would be on the need to ensure timezone info is included on all time/ dates as you say this is a pan Europe solution.

Robtyketto
29th October 2007, 19:47
Thanks for all the feedback, given me plenty to think about.

I didnt mention the company supplies automobile parts so I was wondering if including a weight element would be a good idea?

Within the assignment proposed business solution it details only signed goods should be uploaded, should I scrap this idea about having a return reason element?

The assignment states only to produce ONE schema and example data file.

Thanks again
Rob

Robtyketto
1st November 2007, 00:06
Bump.

Does anyone think that the weight elements is a good idea?

Cheers
Rob

ken_uk
1st November 2007, 00:53
Thinking about it logically, what is the realistic chances of company A the supplier being able to be in a position to dictate to company B the courrier firm what format to use for the POD?


Unless they are a huge customer, the supplier would have to make their system fit around what the courier already has in place, as its unlikely a courier is going to custom code for each customer.

Assuming that for some reason the two companies are actually willing to work together, which is usually not the case, then as their is already a paper based system (which one would assume is working, but needs upgrading to a more modern system) the best place to start would be by looking at the existing data on the paper based system, and asking the people who do the job on a daily basis (at both the suppliers and the courier firm) what is actually missing from it, and what never gets used.

I would go back to your lecturer, and ask him for the paper based info, and for answers to the hypothetical questions, as to design a truly useful bespoke solution, its the best way ;)