AP Invoice before goods receipt

(0) Share

Report

Posted on by Anita75

1,161

Hi All,

I have seem some old threads on this but couldn't find a definitive answer. We have a client who imports from overseas suppliers and they send the AP invoice before the goods receipt/delivery arrives. How do we record this in BC and still achieve 3 way matching?

So the process I'm looking should be:

1. Purchase order

2. AP Invoice

3. Goods Receipt

**Payment can happen before or after AP Invoice

Thanks

I have the same question (0)

All responses (10)

Answers (1)

Verified answer

RustyAustralis 202 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Only thing I can say is that this is an annoying weakness that I suspect stems from how they do posting's which is very old and archaic.

Yes SAP B1 has Reserve Invoices. NetSuite has Incoming Shipments.

As yet the only way to do this in Business Central is an extremely cumbersome transfer order process. However, this itself creates a lot of additional complications in terms of availability planning, reservations and usability. So no good simple answers. Even the modules which exist in this area just usually hide that underlying complexity.

Assuming the AP Invoice isn't due until after receipt, we add them to incoming documents and then post them on the date of receipt, but adjust document date to be invoice date so that due date is at least correct. At least that way you have a record, if not the timely and accurate representation of accounts payable.

I can't find an idea related to it, not sure if others have spotted one.

Was this reply helpful? Yes No
Suggested answer

Marco Mels on at

Like (1)

Report

RE: AP Invoice before goods receipt

Hello,

If this a very wanted feature, then raise it to the product group via https://aka.ms/bcideas . These ideas are triaged and some of them end up in the SaaS product which can then be backported / copied to the OnPrem product.

Thanks.

Was this reply helpful? Yes No
Daniel Rimmelzwaan 3,485 on at

Like (1)

Report

RE: AP Invoice before goods receipt

Check out the pre-payment functionality.

Was this reply helpful? Yes No
RustyAustralis 202 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Daniel,

I’m aware of prepayments and use in certain situations where deposit is required. However for almost all importers this is not about prepayment. In import scenarios it is very common for invoice to be issued at time goods leave facility of exporter or at bill of lading. This is not a prepayment, there is no additional invoice. It’s a straight forward example of design flaw where coders didn’t understand full business process and assumed constraints of receipt always being before invoice. The ledger entries are straight forward for alternative combinations. So much pain and suffering by customers could be fixed by rethinking this - but I understand the challenges of touching posting routines.

Was this reply helpful? Yes No
Daniel Rimmelzwaan 3,485 on at

Like (0)

Report

RE: AP Invoice before goods receipt

You know Rusty, I understand that you are trying to sell something and you think that making the other guy look bad will be successful, but you can't just throw a difference in functionality under the category of "they don't understand what they are doing". It works the way it works because that's how it was developed. If they had had the requirement of having to invoice before shipping/receiving, they would have implemented a process for it.

Trying to make the other guy look bad only makes you look weak yourself.

Was this reply helpful? Yes No
RustyAustralis 202 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Look I’m new to the community and if I wrote it in a way that was interpreted as offensive that was not my intent. But the community also needs to be much much more open to outside ideas and feedback. There are many areas of the product that are amazing, but lots of areas that have fallen behind competitors. This is one of them. It’s not about an individual, it’s about a systemic need for improvement in product design. I’ve got nothing to sell. I’m a customer, not a consultant or ISV.

Was this reply helpful? Yes No
Anita75 1,161 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Rusty, I like your reply a lot because it clearly communicates the need for the feature and it also puts it in perspective compared to competitors offerings. So clearly I'd consider this a big gap considering the product positioning.

Now, in terms of the way you post on the forum it's better than most answers because you are not sugar-coating the issue and say as you see it. Open honest communication is what we need to improve the product

Was this reply helpful? Yes No
Daniel Rimmelzwaan 3,485 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Well Rusty I don't like the way you try to make yourself look good by making other people look bad. Instead of answering the question, you give us something about how bad the functionality is, how they don't understand, how it's not usable and cumbersome. It doesn't answer any of the questions, you are making the other look bad and you are not providing ANY alternatives. Then when I call you on it, you describe me as not having an open mind, not by addressing me but by saying "the community needs to be more open" but by saying that as a result of what I said, you are CLEARLY talking about me.

You don't know me, you don't know how open I am about things. All I am trying to do is help someone who is asking about paying invoices out of the regular order in BC, and pre-payments is one way to do it. All I did was say "check out pre-payments", meaning see if that meets the requirements. Could be that it doesn't, could be that it does, could be that it does only partially. Who knows, because there is almost no description of the actual requirements.

You say you didn't mean it like that but what else does it mean when you say "its a design flaw" and "coders didnt understand full business process". That's like saying that they are too stupid to put a proper process in place. If there were a need for that particular process when the product was developed, there would have been a proper process for it. We can argue whether any ERP should have this capability, and I might even agree that it should, but to go negative is just uncalled for. If you don't see that that is what it was, then you need to work on some self-awareness.

Was this reply helpful? Yes No
RustyAustralis 202 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Okay. This is my last posting. I just want to say I really don't understand why you are being so aggressive. I was not just talking about you. The product community in general often doesn't seem to know about best practice in other solutions, which matters more as BC tries to win new customers against competitors and seems to discount questions from new customers about limitations.

I didn't call anyone names and I talked about process. The original person who asked the question found my answer useful.

I really think Daniel that you need to first understand if someone is coming from a constructive viewpoint wanting to improve a product or a negative one where they just want to attack. If you had asked questions, tried to understand why we are frustrated and been curious it could have been such a constructive conversation. Please don't attack and assume people have a negative or malicious intent.

I have no doubt that the BC team would understand that, but operates under many constraints that aren't always visible to us. There are many experts who know the history of the product better than me who could comment. I was just suggesting I had same frustration and gave constructive advice to use a 'workaround' that i have done around incoming documents.

Was this reply helpful? Yes No
Daniel Rimmelzwaan 3,485 on at

Like (0)

Report

RE: AP Invoice before goods receipt

Well first of all, you addressed me directly. See the screenshot? That's my name right there at the top. You were clearly talking to me, so don't pretend like you weren't.

What bothers me is your utter dismissal of some people that are frankly some of the best software developers in the world, and I do take that personally.

Here's what I mean:

"design flaw" means that they did not properly address the requirement, which can mean one of two things: 1 - they are too stupid to understand a simple business requirement, or 2 - they do understand but they are SO INCOMPETENT that they are not capable of adequately designing a solution for it. "coders did not understand full business process" means two things: 1 - they are too stupid to understand a business process or 2 - they do but they are SO INCOMPETENT that they can't even code for it.

And no you didn't call anybody names, but you did say what you said. No matter how you explain it, it is just INCREDIBLY insulting, and incredibly ignorant.

Here's what really happened: a TEAM of software developers (business analysts, designers, developers, Q&A people, etcetera) defined the requirement, and they developed a solution that meets that requirement. Is it what YOU or Anita need? Apparently not, but that does NOT make it either a design flaw or 'coders' not understanding a business process. Different business process, different solution. See how that works? I'm sure you have a list of things where SAP or Netsuite does things differently than your company. Design flaw? Is the definition of a "design flaw" really "something that does not meet Rusty's requirement"? 'Coders not understanding business processes'? Come on man, listen to yourself and think, prove me wrong and show some self awareness.

You have to understand that there are like a million different industries that do business a million different ways, and when you develop an ERP solution, you make a compromise and implement the biggest common denominator. Whether they get it "right" or "wrong"depends entirely on whether the solution meets the end user's requirement. The fact that you don't agree with how they implemented this one I really have no problem with. That's why we are in this business, to help companies meet THEIR requirements by modifying (or extending these days) the software to suit their processes.

Now if you had stuck to "I think that is an outdated requirement, and ERP software in 2020 should be able to blah blah blah, I would have had no issue with that. In fact, I might even agree with you on this particular one. But no, you had to throw out the "design flaw" and "developers are too stupid to do a good job".

Normally I ignore things like these (I see them every day, it's really not worth getting upset about, I'm actually more upset with myself at this point for not letting it go) but you had to use my name.

Don't stay away on my account, you're more than welcome to be part of our community. The more opinions, the merrier, and like you said the OP really liked your response. Use my name again though, and I will probably say something back.

Was this reply helpful? Yes No