| Time |
Nick |
Message |
| 00:30 |
|
malexander joined #evergreen |
| 04:03 |
|
malexander joined #evergreen |
| 04:46 |
|
khuckins joined #evergreen |
| 05:09 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 07:26 |
|
collum joined #evergreen |
| 07:35 |
|
malexander joined #evergreen |
| 07:56 |
|
sandbergja_ joined #evergreen |
| 08:09 |
|
mantis1 joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 09:08 |
Bmagic |
It seems that Evergreen will show that an Purchase Order is "activatable" even when the lineitem_detail doesn't specifiy a barcode and call number? |
| 09:27 |
|
Cocopuff2018 joined #evergreen |
| 09:41 |
|
jvwoolf joined #evergreen |
| 09:52 |
|
malexander joined #evergreen |
| 10:05 |
berick |
Bmagic: those will be auto-generated |
| 10:05 |
Bmagic |
even if the library settings are null? |
| 10:06 |
berick |
Bmagic: yep, they both default to 'ACQ' |
| 10:06 |
Bmagic |
ok, thanks! |
| 10:08 |
Bmagic |
I think I knew that. I think I forget more things than I remember these days. |
| 10:10 |
|
Dyrcona joined #evergreen |
| 10:37 |
Bmagic |
berick: I'm troubleshooting another thing. The same thing from a month ago or so. These EDI invocies keep matching a PO from 2013. It's the most bizzare thing I've seen. The edi_message table records the correct PO in the purchase_order column. But the acq.invoice_entry lines are for a 8 year old PO. |
| 10:37 |
Bmagic |
I think I'm going to create a new provider and a new edi account because I think this one is "haunted" |
| 10:38 |
Bmagic |
This behavior started after* the edi account was converted to use_attrs |
| 10:40 |
Dyrcona |
Bmagic: Does that 8-year-old PO have any similar identifiers? |
| 10:40 |
Bmagic |
nothing that I can see |
| 10:41 |
Bmagic |
the PO ID is 105. The edi_account is ID 104 but those two numbers should* not be connected to eachother |
| 10:42 |
Dyrcona |
I was thinking of something like a vendor supplied ID for the PO. |
| 10:42 |
Bmagic |
It's true, that the PO from 2013 has a status of "on-order" - and presumabely if the status were "received" it wouldn't target it |
| 10:43 |
Bmagic |
The EDI message from the vendor makes no mention of PO 105 |
| 10:44 |
Dyrcona |
Well, close out the 2013 PO. Nothing that old should be on order. |
| 10:45 |
Bmagic |
for sure I will do that. But IIRC, last month, it was PO 104 with the same problem for the same provider/edi account |
| 10:45 |
Dyrcona |
In fact, I'd just close out anything older than a year or so, if it were me. |
| 10:45 |
Dyrcona |
Is this provider one of the special ones with limited numbers of characters in their line item or other ids? |
| 10:46 |
Dyrcona |
Or PO names or whatever? |
| 10:46 |
Bmagic |
The limitation was for the metadata for shelving location (if you are referring to another question I had) - unrelated to this |
| 10:47 |
Bmagic |
greping all five of the invoice edi messages - none have the sequence of "105" anywhere in the edi coded message |
| 10:47 |
Dyrcona |
Eh, no, some vendor (B&T?) has a limit on PO names or what ever, and if they truncate it, it could match a more than 1 entry in your database. |
| 10:47 |
Dyrcona |
Bmagic: It's not matching on the #, but the name or whatever the field is. |
| 10:48 |
Bmagic |
the PO ID 105 has a name "(migrated) 11501" - also not mentioned in the edi message |
| 10:49 |
Dyrcona |
There's something in the EDI message that the 2013 order has in common. |
| 10:49 |
Dyrcona |
I'm not the expert on this. I'm pretty sure that berick knows better than I. |
| 10:49 |
Bmagic |
it sure seems like that would have to be the case... I'll keep digging around the data to find a match |
| 10:50 |
Dyrcona |
I'd start with the Perl code that processes the responses. |
| 10:50 |
Dyrcona |
That should tell you what is being used to match on POs. |
| 10:55 |
Bmagic |
right |
| 11:05 |
|
dbwells joined #evergreen |
| 11:06 |
Bmagic |
something is happening in this block if (defined($vendcode) and ($orig_acct->vendcode ne $vendcode)) { |
| 11:06 |
Bmagic |
I have some logs that with "changing edi_account from 104 to 104 based on vendacct 'xxxxx' (1 match(es)) |
| 11:07 |
Bmagic |
and the mentioned edi message ID matches the ID's of the ones in question |
| 11:36 |
|
sandbergja__ joined #evergreen |
| 11:37 |
|
mmorgan1 joined #evergreen |
| 11:44 |
Bmagic |
Is it a problem when two providers have the same vendcode for the same org unit? |
| 11:45 |
Dyrcona |
I suspect it would be. |
| 11:45 |
Bmagic |
provider/edi_account I mean |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:04 |
|
Dyrcona joined #evergreen |
| 12:24 |
|
khuckins joined #evergreen |
| 12:30 |
|
khuckins joined #evergreen |
| 12:34 |
|
malexander_ joined #evergreen |
| 12:52 |
|
tlittle joined #evergreen |
| 13:24 |
Bmagic |
I'm getting the vendcode and vendacct confused. vendacct is the important one and the "code" is the "sub designator"? https://docs.evergreen-ils.org/eg/docs/latest/installation/edi_setup.html#_configuring_providers |
| 13:24 |
Bmagic |
The phrase "Can be used with or without the Vendor Account Number." makes me think that the account number can be empty |
| 13:25 |
tlittle |
Bmagic I learned this the other day--"account" is used as a login to their FTP server. Some vendors ignore when I put it in there, and some don't. So I've stopped putting in "account". Vendacct is like the suffix (if it's B&T) |
| 13:25 |
tlittle |
Or..."account" is an arg to the login |
| 13:25 |
Bmagic |
this column is related to the EDI message |
| 13:25 |
tlittle |
They should be sending back stuff with SAN+vendacct (if using) |
| 13:26 |
tlittle |
Or...drat. Now have I gotten them confused as well? Yes, I did. Vendcode is the suffix |
| 13:27 |
Bmagic |
SAN+vendacct+vendcode for those orders associated with a "sub" code |
| 13:27 |
tlittle |
What vendor is this, out of curiosity? |
| 13:27 |
Bmagic |
in other words: vendcode is less used. vendacct is the "main" thing. Assigned to the library by the vendor. Reading the code in EDI.pm has me confused (again) |
| 13:28 |
tlittle |
I found out the other day that the way Midwest is sending us stuff means that it's connecting to the wrong EDI account and apparently has been for awhile, so that's why I was curious about the vendor |
| 13:29 |
Bmagic |
tlittle: I'm looking at two edi accounts. Both with the same vendcode but different vendacct. I think the library put them in backwards. midwest and ingram |
| 13:31 |
Bmagic |
vendcode gets assigned from buyer_code my $vendcode = $msg_hash->{buyer_code}; |
| 13:32 |
tlittle |
Yeah, like our setups for B&T have the same vendacct across all EDI accounts, but they all have different vendcodes |
| 13:33 |
tlittle |
Well..the same vendacct for that org unit. Not across the whole consortium :) |
| 13:33 |
Bmagic |
which is defined in the EDI message as "RFF+API" |
| 13:36 |
tlittle |
For B&T they send it in the NAD+BY::91. Like SAN+vendcode. |
| 13:36 |
Bmagic |
tlittle: that helps! Thanks for confirming |
| 13:36 |
tlittle |
Sure thing. Don't know if I helped or not, but yeah, np :) |
| 13:37 |
tlittle |
I have two EDI not matching things I'm working on and I'm in an EDI-hating mood lately so glad to join in |
| 13:38 |
Bmagic |
I still don't know how or why Evergreen would connect these Invoices back to a PO from 2013 but at least I think I found the vendacct/vendcode's are swapped. And maybe, just maybe, that IS the reason. I can't find code to support that theory though |
| 13:51 |
|
khuckins joined #evergreen |
| 14:48 |
|
jihpringle joined #evergreen |
| 15:09 |
|
khuckins left #evergreen |
| 15:34 |
|
mantis1 left #evergreen |
| 15:40 |
csharp |
back to cstore/drone exhaustion :-( |
| 15:40 |
csharp |
actually... might be a PG-level problem |
| 15:43 |
csharp |
actually - looks like an attempt at SQL injection |
| 15:45 |
csharp |
no - just out of memory looks like - I'll need to do more digging |
| 15:51 |
|
tlittle joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:22 |
Bmagic |
And for something completely different: authority control. Reading this code: authority_control_fields.pl - it seems to me that the authority records are required to have a "003" ? This line: my $cni = $auth_marc->field('003')->data(); dies quite often and throws errors |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:11 |
|
Cocopuff2018 joined #evergreen |
| 18:42 |
|
malexander_ joined #evergreen |
| 20:34 |
|
mrisher joined #evergreen |
