Solved

Import Scenario triggered from Business Event - can I create one from many?

  • 12 August 2022
  • 9 replies
  • 590 views
M
Rank
Userlevel 3
Badge

I’d like to do a similar thing in a couple of places, but right now I have a Business Event that fires whenever I make an inventory Transfer.  That Business Event then triggers an Import Scenario that reads the lines from the Transfer and creates a Project Transaction (in this case, it creates a transaction with two lines, as I need to update the “From” Project/Task and the “To” Project/Task).

 

My problem is I get a new Project Transaction for every line on the Transfer.  Ideally I’d like to have a 1:1 correlation between the underlying Transfer and my created Project Transaction. 

Is this doable?  I guess I’m essentially trying to loop/iterate within the import scenario.  But because I need to create two lines from every input line, I’m not sure how to make it work.

 

Import Scenario looks like this:

 

Thanks!

-Matt

icon

Best answer by matthewbeebe 20 August 2022, 03:03

View original

9 replies

Laura02
Rank
Badge +18

Hello @matthewbeebe ,

I don’t have an answer about your Business Event & Import, but I feel very curious about the business need & your process of updating inventory on the projects, transferring inventory between projects via imports. 

When we transfer inventory between projects in the IN Issues screen, Acumatica creates the related PM Transactions and updates the inventory quantity and cost to the projects, as in this example. Will your import duplicate the Acumatica transfer transactions on the projects? 

Do you mind providing a couple of sentences about your process for my learning benefit?  Is your solution possibly related to project-specific inventory features (which my customer is not using)?  Thank you.

Laura ~ Klear Systems, Inc. Irvine, CA. ~ Please remember to "Mark Best Answer" to help those who are facing the same problem.~
M
Rank
Userlevel 3
Badge

@laura01 thanks for your thoughts… our system does not create the related Project Transaction. So yes, if the system worked as I would have anticipated, it would be duplicative.  We’ve been going back and forth with Acumatica support for almost a month now, and haven’t made any progress with that route. 

I’d love to not need this step, as it’s just one more point of potential problems.  But I DO currently need the same methodology elsewhere because the integration with Acumatica Manufacturing and Projects is rather <ahem> *incomplete* at the moment. (e.g. Material issues to/from WIP don’t hit the project ledger, so if you want to have a Project Balance that accurately reflects direct material, WIP material, and finished/produced inventory, you have to do something: we’re doing a combination of allocations and business-event-driven-import-scenario dark arts)

 

I don’t know if this occurs because Project-Specific Inventory (which, as you surmised we are using) creates an inconsistency in Acumatica’s business logic around Transfers generally, or it’s because we’re using a single 1-step Transfer (which we need to do for other reasons) instead of the return/issue sequence you appear to be using.

If you or anyone else thinks this DOES work in a Project-Specific Inventory scenario with 1-step Transfers, please let me know, as I’d love to be wrong here.

K
Rank
Userlevel 3
Badge

I think the problem with the 1-step transfer may be that it doesn’t create a journal entry.  My understanding is that a project transaction is generated when a transaction hits a GL account that is included in an Account Group.  Since the 1-step transfer doesn’t create a journal, nothing hits the GL to trigger the creation of a project transaction.

Maybe try using the Issue/Receipt options instead?  It may also be helpful to use a reason code for these transactions so the journals post to a relevant GL account included in an Account Group.  

M
Rank
Userlevel 3
Badge

@KristenSchneider

 

No, the 1-Step Transfer links to the GL batch automatically…  from as far as I can tell, all the GL entries get made in the right places (even with all the Manufacuring stuff), but Project entries aren’t consistently made across all actions in all modules.

 

 

And to clarify, all GL accounts involved DO have Account Groups assigned… so it isn’t that. There just seems to be missing functionality (as far as I can tell) or a misconfiguration on our end (which doesn’t appear to be the case).

K
Rank
Userlevel 3
Badge

Ok. I stand corrected.  All the documentation says that a 1-step transfer doesn’t create a journal entry.  Sorry.

M
Rank
Userlevel 3
Badge

Ok. I stand corrected.  All the documentation says that a 1-step transfer doesn’t create a journal entry.  Sorry.

Ohhh… that’s really interesting… I didn’t see where it said that.

 

@KristenSchneider No apologies necessary!!  I do appreciate you chiming in -- I’ve been working this pretty significantly for awhile, so I’m reasonably certain about what I’m observing, but I’m definitely smart enough to know that there are nuances and slight misconfigurations that manifest in weird ways around here.

For clarity, I’m on  Acumatica 2021 R2 Build 21.216.0034

K
Rank
Userlevel 3
Badge

Interesting… I can see that it is creating a journal, but I notice that the journal produced doesn’t have the project codes on it (note the project column just is ‘X’).  So, assuming that the project codes were used on the transfer transaction, it appears that they aren’t getting passed to the journal.  

So, I’m wondering if the problem isn’t still related to the journal entry.  It seems logical that if the project code was included in the journal, and the journal is hitting accounts included in account groups, then a project transaction would get created.   I noticed that when I create an Issue to a project, the project code is passed to the journal, and the project transaction is generated.  

 

 

From the Acumatica help:

 

M
Rank
Userlevel 3
Badge

 

Interesting… I can see that it is creating a journal, but I notice that the journal produced doesn’t have the project codes on it (note the project column just is ‘X’).  So, assuming that the project codes were used on the transfer transaction, it appears that they aren’t getting passed to the journal.  

 

@KristenSchneider Exactly.  I think it’s an oversight and something they need to support.  The idea that they don’t create GL transactions from “one location to another within the same warehouse” makes sense without project-specific inventory (you wouldn’t want a bunch of literal net-zero transactions cluttering up the journal). 

 

But with project-specific inventory enabled, they have to make sure the GL updates accordingly (which they do), since it matters from a cost standpoint.  It is inexplicable why they’re not updating the project as well here.  That’s why I think it’s an oversight or a misconfiguration.  But Acumatica support has thus far said it’s intended behavior.  

 

At any rate, my workaround gets me the transactions I need, I just need to see if I can do them more efficiently upon import.  

M
Rank
Userlevel 3
Badge

Well, I guess I should post the solution now that I figured it out..

 

First, you need to have the Business Event raise the event for “Group of Records” and determine the group by according to your circumstance.  In my case the records come in as a single batch that corresponds to the transfer that is being done, so I want INRegister.RefNbr.  As shown here:

 

 

Then in the Import Scenario, you need to change from inserting a new record to adding an action type <Key: External> and set that Source Value to the same field you’re grouping by. (I left the insert line there for clarity, but it’s inactive)

 

 

This then iterates through the records and adds them all as lines to a single Project Transaction record.  (Or, more accurately, if you have multiple groups being fed from your GI, it will create a Project Transaction for each one).  NOTE: I also had to take the commit off the final <Action: Save> line.

 

 

Anyway, I hope this helps someone else out at some point.  Let me know if it did!

 

-Matt

 

Reply


Terms & ConditionsCookie settings
About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved