Collaborate on Down Payment Invoice Sample for Technical Support with Ease Using airSlate SignNow

Down payment invoice sample for Technical Support

Hello and welcome everyone to today's TechTalk on customer prepayment Invoice. My name is Mathieu Binaisse and I will be moderating this session. To present the session, I'm being joined by my colleague Sunit Acharya, Senior Product Manager. Bhavna Jakhetia, Senior Engineering Manager. and Severing Bock, Senior R&D Solution Architect. To get us started, I will now hand over to Sunit. Thanks, Mathieu. Hi everyone. I'm Sunit Acharya, a Senior Product Manager at the Dynamics 365 product group. And today I'm excited to share details of this new feature that we are calling Customer Prepayment Invoice with you all. So let's go ahead and review the agenda for this TechTalk. So today we'll talk about the customer prepayment invoices and then move on to discussing the various types of prepayment processes that exist today. And after that, we'll go ahead and show you the steps to enable the feature, followed by a quick demo of how you can use this feature that we are rolling out. After that, we'll go ahead and share our roadmap that we have for this feature and then we'll finally move on to the Q&A. So let's get started. So to understand further, right in the overall order to cash cycle, this is where the customer prepayments sit, which is between creating and managing sales orders and before you deliver your goods and services. That's when the prepayment functionality comes in. And now let's talk about what a customer prepayment invoice is. So there are business scenarios, right, where you as a seller often request a deposit or an advance payment from your buyer to secure some financial commitment before you deliver your goods and services. And this is not just the only upside to having a prepayment or a deposit taken from your buyer. So other things that it will help you with is to upfront is to get some upfront funds to cover the initial costs, reduce your financial risk as a seller, and also ensure that your buyer is fully committed to this transaction. Right. And now as we move on to look at the different types of prepayment processes, so we have two scenarios that we have outlined here. Scenario one and scenario two. We'll explain in detail further on what these are. And scenario one is what we support today. So let's talk about that. Scenario one is prepayment as a deposit. So what we are saying here is we are imagining this scenario where our customers only want a final invoice for a particular transaction. And it will have the total sales order value of that particular order. So they don't want two separate legal invoices in this case. So what we'll do is we'll have a deposit that's either a percentage or a fixed amount of the total sales order, and that must be paid before we sell or deliver the goods or services. This is scenario one, and this is what we support today. And scenario two is where we send out two legal tax invoices to our customers, where the first invoice or the prepayment invoice that we'll share will only contain the prepayment amount that we have received from our customer. And the second one that we'll send, the final invoice will only have the remaining outstanding or the open amount for our customers sent out. So we'll talk about this more in a very detailed manner. So let's start with the scenario one. So this is a flow diagram that we have created to explain how the customer prepayment invoice works today. As you can see, we have separated this out into parties, contracts on non posting transactions, invoices and payments. So we will start off with a customer and then we move on to create a sales order. And this is where the procurement functionality will start. So the blue block that you see on the right hand side is, are the different types of documents that will be available to you once you enable this feature. So from the sales order, we start off with a prepayment proposal. And in this scenario we have a sales order of $5,000. And then we have created a proposal for a prepayment of $1,000. So once we have created that proposal and the next step here is to move on to creating a prepayment invoice which will be similar to a deposit. Right? So we create a prepayment invoice as a deposit of $1,000, which aligns with our proposal. And then we go ahead and accept the customer payment from the same in the form of a prepayment customer invoice journal. And then once we receive that $1,000, we settle it with the prepayment invoice that we have created in the previous step. Now that this process is done, we move ahead to apply this prepayment that we have received to the sales order. So now this is done, we move ahead to create the invoice or the full amount of the sales order. As you can see, the sales order invoice has been created, which is also of $5,000. And then the next step here is to receive the payment against this invoice. And when we go ahead to receive the payment for this invoice, you would see the payment journal is created only for the $4,000, which is the outstanding amount. And once we receive this outstanding amount, we can now settle this with the sales order invoice, as the prepayment invoice was already applied, the prepayment amount was already applied to this invoice while we were creating it. Moving on to the future scope, which is scenario two, the difference here is that the moment you create a sales order and then move ahead to the proposal, and then when you create a prepayment invoice here, this prepayment invoice will be similar in structure to a tax invoice or a legal invoice, let's put it that way. And similarly, there's $1,000 prepayment invoice, and then we receive a prepayment journal for $1,000, which is accepting the payment. And then we settle it with this invoice. Now that this is done, we will apply it to the sales order. And here, as you can see, is the difference where we create the invoice for the remaining amount, which is $4,000 in this case and not $5,000, and then we move ahead to accept the payment for $4,000 and then we settle it. So in this case, what happens is our customers are only getting an invoice of the remaining outstanding amount and not the full amount of the sales order. So, moving on to the accounting impacts of the prepayment invoice, this is how it looks like. It's pretty similar to how any other invoice would be like, apart from the fact that the account type here would be a prepayment or a deposit account. And this is how the accounting impact of the final customer invoice looks like. And as you can see, the customer should pay only the open amount, which is 4000. Sorry, 5000 minus $1000, which becomes a total of $4000. Now that we have this understanding, let's go ahead and check out how to set the prepayment Invoice feature up in Dynamics 365. Hello and welcome to the walkthrough and setup for the customer prepayment invoice feature. First off, we'll start with Feature Management. Go into the all tab and find Prepayment Customer Invoice feature and enable it. Once enabled, we will move ahead to the Inventory Management tab and within Inventory Management, under Setup, Find Posting, then go into Customer Preparment. So here we choose the default ledger account for posting of a customer prepayment. Here I selected my main account to be a bank account in USD and you can choose as per your requirement based on all table or group. I will save and move ahead to Accounts Receivable parameters once we are in Accounts Receivable parameters on the Updates tab. Within the Invoice Fast tab there would be a prepayment section which asks us for a preference on the mandatory sales order confirmation. Once enabled, we will need the sales order to be confirmed before we can post a PPM invoice. For now we will have this enabled moving on to Ledger and Sales Tax tab and within the General Fast tab there would be a prepayment invoice section which asks our preference of the prepayment application policy and you would see two options here which are Notification and Automatic. If you select Notification which is the default preference, prepayments will have to be applied manually. If you go ahead and choose automatic, prepayments are automatically applied to the sales order if full payment is received and it settles the prepayment invoice. Moving on, we would go to number sequences. We have to set up the number sequences for prepayment invoice, invoice voucher, invoice reversal and the invoice reversal voucher. I have set up the invoice and the invoice voucher numbering sequences here. You can choose this as per your liking. And for the final step in the setup we go into system administration and then move into the process automations. It's important to note that the prepayment settlement posting is a background process today and our recommendation is to make sure that the prepayment settlement posting process once you find it from this list, click on Edit. Please make sure that you change the default execution interval to one minute and save it. And that completes our setup for the customer preparment invoice feature. Now that we have looked into the setup, let's go and check out how it works today on the system. As our setup is now complete for the customer prepayment invoice feature, let's go ahead and see it in action. We will start off with a sales order. Let's create a new one with our demo customer adding the line items. If you recall, during our setup process there was a preference within AR parameters which let us choose if we want the sales order to be confirmed mandatorily before we proceed to create a prepayment invoice. In our case we had turned that on, so we'll go ahead and confirm our Sales order before moving on to the next step. Now the confirmation is complete. If we go on to the Invoice tab, you can see a new prepayment section here that has the proposal invoice and the Apply prepayment functions. So we will start with the proposal. As you can see there are options for percentages and fixed amounts. If you do have it on the customer level, it can auto populate this from that preference, but you can also change it as you go. So we are going to do $1,000 fixed amount equivalent. Sales category is mandatory, so we'll go ahead and choose something from this list. Click on save and you can now see the prepayment invoice option has enabled and once you move into it you can see it has populated the values from the proposal itself. In case you want to add taxes to this line, you can also do that from the sales tax group and the item sales tax group here. And when you do so, the total amount that you have chosen as your prepayment amount will be a tax inclusive amount. Now this looks good. Click on Save and then click on post. As you can see our invoice number 8 has been posted following the numbering sequence that we set it up. Now let's go ahead and accept a payment for this prepayment invoice. Click on new and lines, choose our Demo customer account and our prepayment invoice number 8 and an offset account operating account USD is what I'm going to go ahead with. Everything looks good. We hit save and hit post. Now that our payment is posted, let's go ahead to the sales order and as you can see the Apply prepayment option is now enabled. If you go into the prepayment invoice, you can see the prepayment status is now received. Right, let's go back and apply the prepayment. So the $1,000 prepayment is showing up here and we apply it. Now that we have applied the prepayment, let's go ahead and generate the invoice against the sales order. And if you scroll down you can see the applied amount of $1,000 of the prepayment invoice that we created earlier and the invoice has now been generated. Let's go ahead and accept our customer payment for the same. Now we'll create a new payment journal. Lines shows our demo customer and as you can see the 19,000 invoice that we originally created is now only accepting 18,000. That's $1,000 minus the $19,000. So the difference is now 18,000. So that's what we'll be accepting. And we also have to add in an offset account. And now that this looks good, we can go ahead and post this. Let's go back to the sales order. And as you can now see, this is invoiced and the prepayment invoice can be viewed from here. And the status is now settled. And now that everything is settled, we can check out the prepayment reversal entries by going into the customer account transactions. And as you can see, the thousand dollar prepayment invoice on number eight has the prepayment invoice entry and the reversal entry here. And with that we complete the whole cycle for the prepayment, applying the prepayment to the sales order and also generating the invoice and collecting the difference amount against the invoice and settle it. So now we are ready to move ahead to the resources and recommendations slide. So this feature is in public preview today and we're looking forward to get some great feedback from you all. And we encourage you to come up to our yammer channels and look up the feature on Microsoft Learn and try it out yourself. Now let's move on to our roadmap that we have planned. As you can see, the first one itself is the procurement invoice as a tax invoice that we explained which was scenario two. And some of the top highlights or top priority items that we have in mind are multiline prepayment invoices, multiple prevent invoices against a single invoice and then prepayment invoicing, support for free text invoices which is not supported today, and multiple prepayment invoices against the single invoice along with canceling the prepayment invoice if not settled. So now that we have gone through our roadmap, I think we are at a good point to start our Q and A. Yes. So with that we now have time for Q and A. So let me pick the first one. Is there any form where we can check all open prepayment invoices? So in the customer balances or sorry in the customer transactions you can filter the prepayment invoices type so that you can view only the prepayment invoices that are in that you have issued for a particular customer. I'm assuming that question is still related to a particular customer and not every prepayment invoice that you have today. Next question. So our sales teaming will be updated. Which order with prepayment can be delivered so Today we have the functionality where you have to or you can choose if you want to confirm a sales order before you want to create a prepayment invoice. But today we don't have that functionality where we can mandate our customers from holding the shipment or holding the delivery of services before the prepayment has been settled. So, yeah, that's a future scope for us. Sounds well the answer. Next question. What if the customer only pays part of the prepayment invoice? Let's say 800. What happens to the remaining 200? They can pay the prepayment partially on a particular sale order, and one prepayment can be applied to multiple sales order. Next question. Can you show the electronic reporting prepayment invoice form that the customer would be sent to prepay from? From my previous testing, there is limited information on it and it's not clear on what the customer is preparing for. It's missing some basic details such as sales order numbers. Yeah, Bhavna, do you want to take that? I think this is a formatting question. Maybe we can update the documentation to give more details on how prepayment invoice form can be customized to add more details while printing of a prepayment invoice. Yes. Yep, we'll take that up as an action item. Do you have the chance to consider prepayment invoice when I have made an error upon creating the invoice? So today we cannot cancel. I think we can delete. I mean, if you have not accepted the payment, I think we can update the values on it, but you cannot cancel. So cancellation is also a future scope for us where we'll allow canceling of prepayment invoices. Thanks, Sunit. Next question. Can we post payment via general journals instead of payment journal payment? Okay. General Journal instead of a payment journal. I guess we'll have to have the customer account linked, but for prepayment. Bhavna, do you want to correct me here? I believe we can do this today. Or does it have to be a prepayment invoice? It has to be done with the payment journal, you know, to set up the previous payment invoice. So here it's a list of questions. So is this feature Mira image of through purchase order prepayment? I say no. Yeah, because for the purchase order prepayment. Yeah. So it was there for many, many years for this prepayment customer prepayment invoice. So I think historically there was some localization feature in, I think Europe, but the functionality is very limited to several countries and for this sales customer prepayment invoice we try to cover broad scope. As Sonet explained in the beginning, the two scenarios and for AP it also doesn't support the second scenario. So in the end I would say for AP AR we are targeting at unified behavior for prepayment but currently AP and AR I don't. I think they are not complete. Yeah. So a simple answer to your question. No Zian, not the thing but our target is we will try to provide the full scope. Thank you for this answer. Will your future scope. So scenario two replace scenario one. Yep. So we plan on keeping both but given the feedback that we get from this release, we will keep you guys updated on what we are doing in the future. But our initial plan is to support both the scenarios because both are valid business cases and they need to be supported. Thanks Sunit. Next question. How is the customer prepayment radio button different than the revenue button in the inventory post form? Okay, yeah, no, these are different functionalities. This is related to a payment that we receive for a prepayment or an advance that we receive against a sales order and not really related to an inventory posting. Can prevent policy be auto apply based on customer accounts. For example, 50% prepayment required. Yes. So today we support two options. So you can have a fixed amount or fixed amount which will be a fixed dollar value or a percentage amount. Like in this case, as you mentioned, 50% of the amount has to be prepaid. So you can set that up in your customer account itself and that will flow into the prepayment proposal and the invoices as you create them. Next question. Why do I need to choose a sales category when generating the prepayment invoice? So this is something that required from GL point of view which is why this had to be mandatory. But Bhavna do feel free to add in anything on this Next question. When you post a prepayment invoice you explain that it will it will post to a country syllable. It is possible to use a different posting profile to not show if it is receivable. Yes, I think a different posting profile would be allowed. But it is at the end of the day a receivable. So our best practice would be to have a receivable account set up. Yeah. And at the moment, yeah. So as a default posting profile it just inherits the sales order invoice posting profile. But user can manually change the posting profile in the repayment invoice hider. So in future yeah, we will provide a Configuration for user to define the default posting profile for repayment invoice as well. Next question. From testing the process, it looks like the final invoice is simply a full invoice without reference to a portion already having been paid. This will certainly cause confusion and the customer is expecting a net invoice and can easily end up paying the sales order invoice in full Soup like this will be addressed in scenario two. Yeah. And that is correct. That's what scenario two is for. Yep. Okay. Any plans to have copilot agent creating prepayment proposal invoice? Good question. Yep, good question. Not at this point, but do feel free to add this as an idea on the portal so that we can take it up. Next question. How to make a reversal? For example, the customer did not pay the amount of the prepai payment invoice or pay a different amount. Yeah. So reversal is not supported today. So this scenario would not be supported. But this will be coming up in our feature release. As we've already shown in the roadmap, can prepayment invoice be issued and payment collected before order confirmation? If not, how we stop the order from being released to warehouse before prepayment invoice is paid? Yes. So today we have a preference where you can say that you have to have the sales order to be confirmed mandatorily before you can create a procurement invoice. Right. So depending on how your business is set up today, you can opt ingly. How are the prepayments working with credit unit functionality? Can I post the prepayment in your voice even if the customer has not enough credit? So. Yes. So the credit management functionality. Right. Would only look into the sales order value. Right. So depending on where you have set up your credit management checkpoint, the check will happen at those specific checkpoints. And let's say if you have your checkpoint with sales order confirmation, the sales order would be on hold right then and there. So you would not be able to proceed to create a preponderant invoice. Next question. This feature is right now as a preview. We are not planning, we are not implementing features instead of preview when it would be standard feature. So when would be the JDate? So I guess this is something that maybe I'll pass on. Yeah, maybe I can take it. Yeah. So currently, as you noticed, this feature is in preview phase. And also that's why the purpose we have this kind of tech talk meeting. And also as Sonit shown, we have the Viva Engagement channel. Yeah. The Yammer previous Yammer group. Yeah. Created to Collect feedback. So we will evaluate the feedback we collected today and also offline and also you can see the roadmap we created for this feature. So we will try to continue working on this feature in next one or two releases. So once the feature covers more scope and also the stability is, let's say, verified, I think we will announce the GA. Yeah, so that means we are targeting the GA in V1 2025. As you selected the bank account for the prepayment receipt, why did you have to set up the bank account in the inventory posting setup and where the accounting process is the inventory posting accounts setup used? So the posting profile setup is what we did for the customer prepayment invoice. And the bank account was basically the receivable account that we have set up for the prepayment account. And that is why we had to go through this step to clarify. So a request for a payment is not receivable because no good services have been delivered and no cash received yet. So this is just to be excluded from IR in the balance sheet. Also deposit. I'm sorry, Also deposit must be not be done shown. Sorry, again, resource deposit must not be shown as long as no cash was received. How it is handled? Okay, so the scenario that we had in mind while we were designing this is the deposit that you receive, or the deposit will be a receivable. Right. It's a portion of the net receivable that you had for your sales order, similar to how you would generate an invoice against a sales order. This is a one step ahead of that, where you take a partial payment of that overall amount that you signed up for. So that is something that is receivable. At the end of the day, you might not have received the payment for it, but the moment you have agreed with your customer that they are going to pay you in advance, it is receivable on your books. And you create a payment journal whenever you receive the payment from your customer. And that's how you close this cycle. Your question about Pope, can you make the input of the prepayment proposal dependent on the payment term settings? Yeah, I think what the question means is will it kind of align with the prepayment. Oh, sorry. Will it align with the payment terms that you have already set up for this customer on the customer account? And the answer to that is yes. When you try to create a pro payment invoice, it adheres to the payment term that you already have on file for that particular customer. Be it net 30, net 40, it'll update the due dates and the payment term fields on the header level as ingly as we don't see any, I would say new questions that are popping up. So this concludes today's live event. I will thank you for this presentation.