Payer determination In Billing document.

[former_member372321]

Hello All,

we have special business scenario where we need to determine different payer for Proforma Invoice and different payer for Commercial invoice. Is there any way to determine the payer based on business requirement.

Please let me know if you have any idea to determine payer based on business requirement.

Thanks,

Srinivas .

[VeselinaPeykova]

Please explain your business process in greater detail and the logic behind the requirement to have different payers for the proforma and for the final billing document.

The proforma invoice does not generate financial postings in the standard system - what would be the benefit in using a different payer - is it just to print/send some document or you intend to manipulate other data?

In the way you describe the requirement - it may be considered as an illegal practice, so please ensure that the process is officially approved and would not cause problems during audit.

[former_member372321]

As per the business requirement we need to combine orders based on plant irrespective of sold to party /payer or any other parameters. Just we need to create pro forma invoice based on plant from that we need to generate the report and send to Distribution Centre for validation from operations perspective.

Based on this, I thought of create new partner function same as Payer and that will assign to customer master record. During the creation of Pro forma invoice system is going to combine invoice document based on this payer and generate pro forma invoice.  I will define every distribution plan as customer number.

Regards,

Srinivas.

[VeselinaPeykova]

What kind of information (other than materials/quantities/dates, transportation zone) would the distribution centre need to have from operations perspective?

It looks a bit like some sort of transportation cross-docking process (consolidate the products for the day from the production location onto a shipment, receive them in the distribution centre, then reload on smaller trucks as per original delivery requirement and deliver to the end customers).

Is this what you aim to get as a result?

If yes, then maybe an alternative approach could be:

1. create orders for the day for a specific plant with delivery block (ensure to have a cross-dock partner distribution centre assigned).

2. generate a report for the orders with this partner and from it create delivery without preceding document for the complete quantity. It may be a good idea to create multiple deliveries for several big trucks.

3. Dispatch onto trucks, pick/load/goods issue.

4. Receive the products in the DC (a z-program for GR considering big delivery quantity would be nice to have).

5. Remove delivery blocks and change the delivering plant for the original orders and generate deliveries in the DC.

6. Create shipments, pick/load, GI, etc.

In case you do not need consolidated deliveries from the production plant and would not execute repackaging in the DC, but you need to inform the DC transportation planners and the warehouse for the required trucks and arrival time:

There is a standard functionality - Transportation cross-docking (it requires EWM, but a similar approach can be used also without WMS with custom development).

A third possible scenario I can think of, is a 3rd party acting as a wholeseller delivering on behalf of the company (in this case it may not be necessary to plan the transportation of products from the production facility to the DC or from the DC to the end customer, but you need to inform the wholeseller of the quantities to be delivered to each end customer and dates/times). In this case you can simply send output based on a z-partner function and generate the final/real documents after the wholeseller confirms the actually delivered products per customer order via EDI for example.

[former_member372321]

Thanks for your detailed information.

But we need to have to create pro forma invoice for returns not for the sales process. Distribution centre would like to have report based on commodity,quantity ,receiving plant and price. we have special designed return process to our client.

As per the current process, retailer has to send material information to us which they want to return the goods back to DC, based on we will create return order and see what are materials can accepted by the client. Later we will send the approved details information to retailers. Based on this retailer will return the goods distribution centre.

As per my knowledge I hope they would like to know, how many materials that are returning goods and cost of the material at commodity level . (They used call it as Consolidation Pro Forma Invoice at Plant level)

Regards,

Srinivas .

[VeselinaPeykova]

I find it somewhat difficult to understand your explanation of the business scenario (language barriers, structuring).

In case I got it completely wrong, please re-phrase it, so that it could be easily understood by non-native English speakers without prior knowledge of your client's business processes.

Your customer wishes to return some products, but before deciding what are the exact quantities to be returned physically to the plant, you have some quality inspection or approval process - is this correct? So this looks like a variation of advanced returns process.

From your explanation I understand that the DC just needs some report for authorized returns per product/location/price for KPI.

Why don't you simply create a simple report for the DC instead of trying to issue proformas etc. For now I see no reason why you would need that document. If you aim to capture the correct prices, creating a dummy billing with different payer for all returns in the plant may also produce inaccurate results. If you use ARM you can easily capture the correct quantities and prices for each separate order item (in case the standard ARM reports do not fulfill the business requirement).

Even if your client does not use ARM, he can still get the desired information via a report.

It could be that the company used the so-called consolidation proforma, because of the limited capabilities of their legacy system.

In the case of wholeseller return process - you can still get the needed data from the customer order items if you need it to issue credit memos for services to a wholeseller.

[former_member372321]

Your understanding is correct.

I need to go back to business and understand why they want insisting us to generate consolidated pro-form invoice . Based on that, i will decide whether we are going to right direction or not .

Thanks for your help.

Regards,

Srinivas.